Hi, after a quick compile of 3.3.11c, I discovered I couldn't boot my system up because the kernel with initrd image kept trying to use devfs rather than udev (and I've disabled devfs in my kernel). Upon further investigation it appears that the update from udev-074 to udev-87 had some changes to the Makefile installation mechanism, including no longer installing /sbin/{udev,udevstart,etc.} by default. The generic linuxrc and initrd.scripts both check for and require the presence of /sbin/udev and friends. I'm not sure of the proper procedure for starting udev these days, but it appears both udev and udevstart are no longer classed as necessary binaries by default, so perhaps this will require a major reworking of the genkernel startup procedures to keep it in line with udev? I believe several init scripts rely on the existance of /sbin/udev and co, and the only reason that the gentoo baselayout still works is that the main udev ebuilds don't use the Makefile's installation system, but do the install entirely manually. Anyway, I've marked this as major since this version appears to have been marked as stable immediately, and it should probably be masked with a problem like this in it. If there's any further information I can provide or any testing I can do to help out, please let me know...
Ok, so, the change happened between 081 and 082: Summary of changes from v081 to v082 ============================================ Kay Sievers: ... remove udev, udevstart, udevsend from the default installation ... It doesn't really mention how everything's supposed to be started these days though. The only programs installed by default now are: udevd, udevcontrol, udevmonitor, udevinfo and udevtest (and any EXTRAS) Oh and hotplug now appears to be done through netlink rather than udevsend, but I'm not certain what the kernel version requirements are for that...
(In reply to comment #0) > Upon further investigation it appears > that the update from udev-074 to udev-87 had some changes to the Makefile > installation mechanism, including no longer installing > /sbin/{udev,udevstart,etc.} by default. The generic linuxrc and initrd.scripts > both check for and require the presence of /sbin/udev and friends. just wanted to say: same problem here :-(
(In reply to comment #1) > Ok, so, the change happened between 081 and 082: > > Summary of changes from v081 to v082 > ============================================ > > Kay Sievers: > ... > remove udev, udevstart, udevsend from the default installation > ... > > It doesn't really mention how everything's supposed to be started these days > though. The only programs installed by default now are: > > udevd, udevcontrol, udevmonitor, udevinfo and udevtest (and any EXTRAS) As a (ugly) quick-hack I forced genkernel to use previous udev-077 within /etc/genkernel.conf, downloaded udev-077.tar.bz2 vom kernel.org into /usr/share/genkernel/pkg and rebuild the initrd. <- Results in "Activation udev" ;-) Nevertheless this is not a bugfix only a workaround to get genkernel-3.3.11c generating a initrd with udev-support. BTW: Just for fun I created both initrd's one for 077 and one for 087 version of udev, extraced the usdev-binaries and checked want else has been changed perhabs this information is also helpfull --- /tmp/udev077.lst 2006-04-14 12:03:44.000000000 +0200 +++ /tmp/udev087.lst 2006-04-14 12:03:49.000000000 +0200 @@ -3,9 +3,6 @@ ./etc ./etc/udev ./etc/udev/scripts -./etc/udev/scripts/ide-devfs.sh -./etc/udev/scripts/scsi-devfs.sh -./etc/udev/scripts/raid-devfs.sh ./etc/udev/rules.d ./etc/udev/rules.d/50-udev.rules ./etc/udev/permissions.d @@ -19,11 +16,8 @@ ./lib/udev/create_floppy_devices ./lib/udev/firmware_helper ./sbin -./sbin/udev ./sbin/udevd -./sbin/udevsend ./sbin/udevcontrol -./sbin/udevstart ./sbin/scsi_id ./sbin/vol_id ./sbin/ata_id
Ok, I've put 3.3.11d in the tree and reverted back to udev 077 for that. Please don't forget to etc-update genkernel.conf afterwards. Sorry for any inconvenience caused and please reopen this bug if further issues arise. Thanks!
Well, 3.3.11d might have fixed problems for some but not for me... (to be honest my installation is a bit "bleeding edge") With 3.3.11c, I had exactly the symptom described here (direct use of devfs, no possibility to access my partitions at boot) (ref:http://forums.gentoo.org/viewtopic-t-453716-highlight-.html) I emerge 3.3.11d with hope, ran 'genkernel initrd' but I end up with the following which was my original issue with 3.3.11 ERROR: Failed to compile the "EXTRAS="extras/scsi_id extras/volume_id .... " I am running a brand new 2006.0 build from stage1 where I replaced gcc-3.4.4 by gcc-4.1 and glibc-2.3.4 by glibc-2.4-r2 The kernel I try to build is 2.6.16-r2 Any idea?
Well, sadly this is probably the wrong place to report it. I had been filing my problems under bug 122629. Again, unfortunately, that can't be reopened except by a dev or the bug owner. It would be nice to try and get udev-088 working again though. There are two possible solutions: The first is to jigger the install to include the udev, udevstart, udevsend etc. files (during my last experiments I thought I'd tried that, but I still couldn't /dev populated). The second would be to bring in the guys who do baselayout to offer some pointers on the correct way to integrate udev-088. Perhaps gregkh or uberlord? Personally I'd go for the second everytime, but it's not going to be the quickest solution...
*** Bug 130020 has been marked as a duplicate of this bug. ***
Created attachment 84777 [details, diff] genkernel-3.3.11d-udev-088.patch Right, here's an initial patch to make use of udev-088 in genkernel. It requires the /etc/genkernel.conf to use udev=088+ (since udevtrigger's only present in these versions onwards). And from the looks of /lib/rcscripts/addons/udev-start.sh, it appears it will only work with kernels >=2.6.14. However, I have had it boot my system, and it doesn't require any changes to the compilation method (no extra files added, etc). I might look into putting udevstart back into the scripts (since this is what /sbin/rc falls back to in baselayout) and see if we can't get a generic script that'll work for everyone with the new udev... Please let me whether I should open this bug again, since it wasn't resolved so much as worked around. Thanks... 5:)
Indeed, reopening :)
Typo... 5;)
Right, I did a little digging, and sure enough if you simply try to add udev, udevsend and udevstart to the image and run things the way they always used to work, udevstart segfaults. Unfortunately I've got *no* idea how to go about figuring out why it does that on a busybox/klibc system. It's probably because of gcc-4.1, but I can't test it on any other gcc, so someone else will have to verify that for me. Also if anyone's out there who's got a kernel older than 2.6.14, is there any chance you could test the patch and see whether that is a hard and fast requirement or not? Thanks...
OK... I went ahead and added this patch into CVS, but I haven't had much time to do a lot of testing on it. I'm going to be doing more testing on this in the near future as we really need to get all of this mess resolved as soon as possible.
Please make careful note, that this may very well fail for kernels <=2.6.14, and that it will not fail back to devfs if that's the case. I didn't code in any checks for the exact kernel version. It might be worth either keeping it masked, or putting a huge warning all over it, just so people aren't surprised if/when it goes wrong...
Thanks, this patch works for me with kernel 2.6.16-gentoo-r6 genkernel 3.3.11d + patch + udev-088
(In reply to comment #14) > Thanks, this patch works for me with > > kernel 2.6.16-gentoo-r6 > > genkernel 3.3.11d + patch + udev-088 > Same here, though the kernel is 2.6.16-r7. I also tried udev versions 089,090, and 091. Only udev-088 will build. The rest all fail with that same error: Failed to compile the "EXTRAS="extras/scsi_id extras/volume_id ....
Thanks for the positive report! As to the later udev versions, I'm holding off upgrading this to work with >=udev-089 because at that point udev starts cold-plugging all the modules. Whilst this currently happens if you've got >=udev-89 installed anyway, I'd still rather wait until gregkh gets udev sorted out (see bug 130766)...
*** Bug 122629 has been marked as a duplicate of this bug. ***
Just to add that this still doesn't work for me, patch or otherwise, but with a GCC >4 enabled tarball. I don't know if GCC itself is the issue, but installing with 3.4.4 worked fine. "ERROR: Failed to compile the "EXTRAS="extras/scsi_id extras/volume_id ...." etc is my error, ony GCC 4.1 or alpha 4.2 enabled tarballs. Pity, because it seems a bit pointless installing with GCC3.4.4 when I want 4.1, and such an outcome does seem so close and yet so far.
John, please double check the version strings you're using. You should have klibc="1.2.1" and udev="088". You must then also apply the patch. Anything higher than 088 and you'll get the failure to compile extras, any lower klibc and similar compilation failures will occur. If you're certain you're doing all of that, please attach your genkernel.conf file the tail end of the logs showing the compilation fault. Thanks...
Don't have time to try again right now, but I'm including the tail end of the /var/log/genkernel.log from my first try. http://pastebin.com/739336
Ok, thanks John. Sorry I wasn't around on IRC, but yes, that was me. I hate to ask, but could you please similarly post the genkernel.conf you were using (obviously only when you've got time), to verify the versions of the software flying about. Thanks very much... 5:)
http://pastebin.com/740474 That's the genkernel.conf from the same try as the genkernel.log from earlier. I don't still have the system itself, I just saved some stuff from it. I did try chrooting into the latest attempt from the livecd. Emerging didn't like the size of the above patch, so I synced, then ebuild.sh was broken, so I deleted that and tried to sync again, but the timestamps matched so no go. Meh, I'll give it a proper go over the weekend.
Hi, john, there's a very simple fix for your problem. In your genkernel.conf file, please change line 100 which currently reads: UDEV_VER="077", to reading UDEV_VER="088". This patch *won't* work with older versions of udev, and unfortunately the patch doesn't alter the config file (since I was mostly trying to get it just work first). Once you've made that change, please try recompiling (you may have to download the udev source too and put it in the right location) and then see whether it all works...
Can someone tell me how to apply this patch? I haven't the experience yet to do this on my own. ;-)
If you need help with applying the patch, look at the following: https://forums.gentoo.org/viewtopic-p-3331469.html#3331469
(In reply to comment #25) > If you need help with applying the patch, look at the following: > https://forums.gentoo.org/viewtopic-p-3331469.html#3331469 > Thanks for your help!
(In reply to comment #23) Well, I got it working. It took all night, but finally genkernel doesn't seem to be a problem. Unfortunately, for anyone reading this, my solution was to install, wait 3hrs, see it fail, then fix it and try to finish the install manually. Rather long-winded and tiresome. http://forums.gentoo.org/viewtopic-p-3345148.html#3345148 gives more details on what I did. P.S. When chrooting from a LiveCD, always remember to mount /boot, /, proc and dev. Finding out that I need to do, and how to do, the last two took a while.
OK. I just wanted to inform all of you that genkernel is dropping udev support in favor of mdev support. Anyway, this bug will go away with the next version of genkernel, once we get all the bugs worked out of mdev support.
Chris, are there any resources that specify what the mdev project is? At the moment I've found a post[1] on the busybox mailing list, a hacked up implementation[2] sitting on a gentoo tinderbox and a conversation[3] between solar and someone else concerning it. A homepage, or a definitive link to the source would be good if you have them. My main concerns are with dev-mapper nodes and/or raid drivers/devices, if it can handle those I'd be interested in helping out/testing. Thanks... 5:) [1] http://www.busybox.net/lists/busybox/2005-December/017180.html [2] http://tinderbox.x86.dev.gentoo.org/misc/mdev.c [3] http://purl.rikers.org/%23uclibc/20051108.html.gz
Scratch that, it appears to be built into busybox as of version 1.1.0 (although there's a bug in that version so best using 1.1.1 or above). It's unclear whether it still requires /sbin/hotplug or not, but I guess that's off topic for this bug. I guess we'll all stay tuned, thanks Chris!
Since udev 077 would not compile with gcc 4.1, and genkernel would not build the initrd, I applied the patch for udev 088, but it still did not work: the udev step tool about 6 seconds (a lot!) and it actually did very little: there were almost no devices under /dev, no hda for example... I am using lvm so I can't boot my system since I upgraded gcc... I am using gcc 4.1.1 and glibc 2.4 on amd64. Any suggestion? maybe I'll try 078 and following without this patch.
Andrea, could you please clarify what happened? You applied the patch, and you altered your genkernel.conf to set UDEV_VER="088" (and for completeness KLIBC_VER="1.2.1") and you managed to compile it all, but then it failed during the boot process, is that correct? It should say how many iterations the udev step took (right after "Letting udev process events") If that reads > 30 then udev is taking an *extremely* long time to go about populating all the devices, so it sounds like it's running into some other kinds of problems, which unfortunately you're going to find difficult to diagnose. If you can get to a prompt, could you please look in /dev/.udev/queue and see if there are any devices nodes waiting to be created in there? You might also try completely cleaning out genkernel's cached builds under your arch in /usr/share/genkernel/pkg, then running genkernel again, it should completely rebuild everything. So please get back to me with those answers, and hopefully we can make some headway. Please also note, that once the genkernel team make the swap over to minidev/mdev (the busybox udev implementation) this will all become much less of a problem... 5:)
Just to add that, for me anyway, I'm pretty sure the problem was GCC>4. I reinstalled with no patch on the 2006.0 GCC and everything went fine. Maybe I had a different problem to the OP.
This is sorta-kinda InCVS... I applied this patch, so if someone took the time to uncomment all of the udev stuff in the next version of genkernel, they could use this. However, the next version of genkernel is going to use mdev for 2.6 kernels because, quite simply, it is *so* much nicer to work with...
Fixed (we've switched over to mdev) in 3.4.0_pre1, thanks. Please test and let us know if there are any problems. Thanks!
*** Bug 141372 has been marked as a duplicate of this bug. ***
