NavigationUser loginSpam?See spam posts on this site? If so, please don't reply to the spam! Instead, just report the URL to the webmaster. Cost of War |
"Waiting for root filesystem" problem with udev 150 on PowerPCAfter upgrading to the 2.6.32.4 kernel, from version 2.6.32.3, my PowerBook G4 would hang with the message "Waiting for root file system". Any subsequent kernel upgrades did nothing to fix it. I've read that this may be a udev issue, or even a kernel bug. I have not tried to downgrade to udev 141. I have a single reiserfs partition that is labeled, as per the recommendations here: http://www.debian.org/releases/5.0/powerpc/release-notes/ch-upgrading.en.html#boot-hangs But none of the suggestions work, not to mention they are centered around GRUB and LILO, rather than the Yaboot I'm using. The udev 150 works fine with my 2.6.32.3 kernel, so what changed? The only thing I can see is that when BusyBox fires up after about three minutes, the reiserfs module is missing from /proc/modules, but it does exist when I'm booted into the 2.6.32.3 kernel. I'll go back and recheck my kernel configuration, but I'm sure that module exists. Thank you for any help! |
Re: "Waiting for root filesystem" problem with udev 150 on PPC
Don't know if lsmod, rmmod, & modprobe work in BusyBox but if they do, you could verify that the reiserfs module is loaded.
Re: "Waiting for root filesystem" problem with udev 150 on PPC
Thanks andmalc,
I tried modprobe reiserfs already to no avail, and lsmod is not available unfortunately. Within BusyBox, the output of dmesg correctly finds hda and hda1, but in /dev there is only hdc (My CD drive). In /dev/disks there exists only the by-id, which contains the ID of my CD drive.
It's really bizarre, but I guess it could be a PowerPC quirk of some kind.
Thanks.
Re: "Waiting for root filesystem" problem with udev
Another thing that is noteworthy is that when I boot into my good kernel (2.6.32.3), there are udev processes running with udevd --daemon, but if I check the udevd processes in BusyBox, they are running with --resolve-names=false. Restarting them seems to do nothing...
Solved
This has been solved now. The CONFIG_SYSFS_DEPRECATED flags needed to be turned off on my running kernel, just like udev warned me about when I first upgraded. Once I did that and rebuilt the kernel, it was fine.
I hope this helps somebody else.