Only after I fail to boot my system the first time after install, I find that there is no mention in the handbook about how to activate udev. In the bootloader section, there should be a note that the kernel needs the udev argument on boot to activate udev because now udev is the default in kernel-2.6. On top of that, I also feel that the Configuring the kernel section should also hint that udev kernel argument is required for kernel-2.6 with udev. I have scan through the amd64 handbook and find that it also is missing this information. But I can't select more then one hardware platform for this bug report, so I better mention it here. And I suspect it will also applies to all platform that supports udev Reproducible: Always Steps to Reproduce: 1. 2. 3.
Why would you want to add the udev param? It works perfectly well without it on my boxes. Did you compile devfs in your kernel? # cat /boot/grub/grub.conf default 0 timeout 30 title=Gentoo Linux 2.6.11 root (hd0,0) kernel /2.6.11 root=/dev/hdc3 vga=0xf07 # grep -i devfs /usr/src/linux/.config # CONFIG_DEVFS_FS is not set
I believe devfs is compiled though not loaded on boot. However, it is still an issue because I did a vanilla genkernel based on the handbook and that's how genkernel build the kernel. I also don't think it is a genkernel issue because in the book, the kernel config is taken from the installcd. So I think this issue can be solve in 2 area. 1. Change the handbook so it explain the issue better. a. Add a note to say if devfs is enabled in the kernel, the udev argument is required. b. Don't take the config from the installcd but need to make sure genkernel have the correct config set. 2. Make sure the installcd have the kernel config properly. Before your reply, I have no idea that having devfs set in the kernel will cause this problem so I feel that users that follow the handbook by the letter will end up with a system that don't boot without intervention. Though now I know better, the issue remains because it is not just about me. ;)
Handbook explicitely says devfs must not be compiled and that genkernel must be called with --udev. I expect genkernel works with --udev but I haven't tested myself. Can anyone confirm?
I have check. My kernel config file in /etc/kernel says that devfs is not set. However, with that setting, my system does not boot unless I specify udev in the kernel options. I think there might still be a bigger bug lurking somewhere. Maybe a note in the handbook like a "if you system don't boot..." statement?
lets make it clear, this has nothing to do with the linux kernel, just genkernel
Yes, I know it has nothing to do with the kernel (maybe good to mention it for benefit of others). However, I don't think it is genkernel either. After all, my kernel was build with devfs disabled, yet I see this problem. baselayout maybe? Also, I'm not the only one to hit this problem. Posting of this problem is begining to show up in the install forum.
After following the install guide (first time install) using genkernel --udev all I got the error message block device /dev/hda4 is not a valid root device the root block device is unspecified or not detected please specify a device to boot, or "shell" for a shell adding udev to the end of the kernel line in grub.conf solved the problem and now its up and running.
After banging my head on this problem as well I found the "udev" and "devfs" parameters documented here. http://webpages.charter.net/decibelshelp/LinuxHelp_UDEVPrimer.html It's pretty scary that getting udev to work with genkernel is not properly documented in the offical Gentoo documentation.
The symptom was spotted on installcd too. http://forums.gentoo.org/viewtopic.php?p=2247164#2247164 So I think this has further implication then initially thought.
Normally the stable baselayout doesn't need the explicit udev/devfs mentioning: """ if get_bootparam "noudev" || \ [ ! -x /sbin/udev -o -e "/dev/.devfsd" ] || \ [ "$(get_KV)" -lt "$(KV_to_int '2.6.0')" ] then udev="no" fi """ In other words, unless you have passed "noudev", udev isn't installed, /dev/.devfsd is found or your kernel isn't 2.6, udev is used. I am wondering why adding "udev" as a boot parameter would work, since there is nowhere in /sbin/rc that the bootparam "udev" is used, only: nodevfs:noudev:tmpfs:ramfs:noconfigprofile:configprofile udev is a userland application, so "udev" as a kernel parameter should have no effect...
The issue is with genkernel. Not the one 2005.0/networkless users install (that one is patched) but the one in Portage currently. Plasmaroo will commit a fixed version so that users who install Gentoo with an up to date portage (emerge --sync) have the fix as well. Waiting to close until confirmed.
plasmaroo, we still have reports on #gentoo about genkernel users (who ran "emerge --sync") who did use "genkernel --udev all" still needing to add the "udev" boot parameter (or remove the initrd and bluntly use the kernel image alone). Would you mind relooking into genkernel if it is really fixed in arch (not ~arch, we don't care about ~arch here :)?
I think I have found the problem. It seems that the linuxrc that is package into the initrd image has a typo. First, my genkernel is 3.1.5 so it should be the same version. Line 179 should be: [ "${KMAJOR}" -eq 2 -a "${KMINOR}" -ge '6' -a ! "${USE_UDEV_NORMAL}" -eq '0' ] && USE_UDEV_NORMAL=1 In the script, it is checking and setting the USE_UDEV_SUPPORT instead of USE_UDEV_NORMAL.
3.1.6 (in Portage, stabilized) fixes comment #13; testing appreciated.
Confirm! I manage to boot without udev option. Thanks. One additional observation though. I have found that with genkernel-3.1.5, if I follow the handbook and do a 'gunzip < /proc/config.gz > /usr/share/genkernel/x86/kernel-config-2.6' to use the installcd kernel config, the 'udev' problem shows up but if I use the kernel-config-2.6 supply by genkernel, there don't seem to be 'udev' problem.
*** Bug 87635 has been marked as a duplicate of this bug. ***
I've added the information to the guide nevertheless (ETOOMANYREQUESTS).
Well, it's mentioned now. Passing on to tim. Tim, if you feel confident that it's really fixed, just mark it as so.
Yep, bug should be safe to close as FIXED, doing so. Thanks Sven & al.
*** Bug 92880 has been marked as a duplicate of this bug. ***
