I added a second SATA drive to my system (VIA mboard soft RAID) this week and set up dmraid under kernel 2.6.16-1.2133_FC5; it boots and runs okay. I updated to kernel 2.6.17-1.2139_FC5, and it stops during boot. The initrd init script looks okay; I added extra echos to it and it stopped at "dm partadd". The system isn't hung (I can CTRL-ALT-DEL and it will reboot) but it doesn't get past that point. I don't see any differences between the 2133 and 2139 initrds (except for the module binaries of course, but the same modules are in both initrds).
I have a similar problem: I installed a fresh FC5 and upgraded it. Now, the boot with 2.6.17 (2139) stops at initialising the device mapper, but with the old kernel 2.6.15 it boots perfectly.
I just tried 2.6.17-1.2145_FC5 from udates-testing and still get the same result.
Also tried 2.6.17-1.2339.fc6 from rawhide with the same result.
I also try 2.6.17-1.2145_FC5 but it stop earlier at the very begining rehat nas version... and just stop.
Might this be the same problem as in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196539
It may be related to 196539, but it isn't exactly the same. I don't get any errors or hangs; the boot simply stops at that point (but the system is not hung; the magic keys still work and CTRL-ALT-DEL will reboot). BTW I have tried up to 2.6.17-1.2159_FC5 with the same results.
(In reply to comment #6) It may be related to nash. initrd hangs at the "dm partadd" command. I've inserted some debug output into /bin/nash and saw that nash hangs inside the nashDmCreatePartitions routine somewhere between the nashDmGetUUID and the ped_device_get calls. The strange thing is that theoretically there's nothing important between these calls only ped_exception_set_handler, but ped_exception_set_handler doesn't seem to return.
(In reply to comment #7) Sorry, I was wrong: it's the ped_device_get(...) call which doesn't return. AFAIK ped_device_get(...) is implemented in libparted.a which comes from GNU Parted. Maybe we should upgrade to a recent version from parted-1.6.25-8.
OK, while I'm writing this `uname -a` gives "2.6.17-1.2157_FC5" :) Here's how to do it: - download parted-1.7.1 from http://ftp.gnu.org/gnu/parted/ - rebeuild parted-devel - install parted-devel-1.7.1 (with --nodeps) - download the official mkinitrd-5.0.32-1.src.rpm - rebuild the nash executable - repack your actual initrd-2.6.17-1.2157_FC5.img so that the new one contains the freshly built nash - reboot The mentioned ped_device_get(...) call will succeed and FC5 will boot up just fine. Somebody please inform the Fedora developers that we'll need a relinked /sbin/nash for the 2.6.17 kernels.
Building the RPM using "rpmbuild -tb parted-1.7.1.tar.gz" exits with: 8<----(SNIP) gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DLOCALEDIR=\"/usr/share/locale\" -DLOCALEDIR=\"/usr/share/locale\" -W -Wall -Wno-unused -Wno-switch -Wno-format -Werror -MT linux.lo -MD -MP -MF .deps/linux.Tpo -c arch/linux.c -fPIC -DPIC -o .libs/linux.o cc1: warnings being treated as errors arch/linux.c: In function 'read_device_sysfs_file': arch/linux.c:608: warning: ignoring return value of 'fgets', declared with attribute warn_unused_result arch/linux.c: In function '_probe_proc_partitions': arch/linux.c:1512: warning: ignoring return value of 'fgets', declared with attribute warn_unused_result arch/linux.c:1513: warning: ignoring return value of 'fgets', declared with attribute warn_unused_result make[3]: *** [linux.lo] Error 1 make[3]: Leaving directory `/usr/src/redhat/BUILD/parted-1.7.1/libparted' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/parted-1.7.1/libparted' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/parted-1.7.1' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.33587 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.33587 (%build) 8<----(SNIP) Is anything missing on my system? I use the 2.6.16-1.2133_FC5 kernel of course because the 2.6.17 kernels don't boot. kernel-2.6.17-1.2157_FC5 ist already installed. Thx - Andreas
I updated to mkinitrd-5.1.2-1 from rawhide (which pulled in a new glibc as well of course) on my FC5 system and rebuilt the initrd for kernel-2.6.17-1.2157_FC5. That fixed the problem for me (it appears mkinitrd-5.1.2-1 is built against parted-1.7.1-9.1).
Yup, works!!! In /etc/yum.repos/fedora-development.repo under [development] change "enabled" to "1" # yum -y update mkinitrd ---> updates to mkinitrd-5.1.2-1 # mv /boot/initrd-`uname -r`.img /boot/initrd-`uname -r`.img.old # mkinitrd /boot/initrd-`uname -r`.img `uname -r` Re-change the "enabled" above to "0" and reboot. That's it! Thanks a lot - Andreas
The above method implies that you can boot with the kernel in question, doesn't it? As it uses the *currently running* kernel (uname -r) to (re)generate the initrd, does this work for the affected 2.6.17 kernels or the updatd mkinitrd program should be used to install the newer 2.6.17 kenrel on affected systems, which would solve this?
(In reply to comment #13) Yes, you're right! I've done that procedure with the booted 2.6.16-1.2133_FC5 kernel of course - I worked with the new kernel already when I wrote that. So replace `uname -r` with 2.6.17-1.2157_FC5. Thanks for your hint! Andreas
I've read through the comments and infer that all the contributors thus far are seeing this bug with RAIDed systems. I'll add that it also affects a system containing single SATA drive.
And the problem still persists with 2.6.17-1.2174_FC5
Re: Comment 16 Agreed, Henning. However, Comment 12 contains a workaround that should be successful. Update to the latest development version of mkinitrd and then re-install the kernel. This should resolve your issue. It seems to me that this bug may be misclassified, as it seems more to be related to the way several packages interact (mkinitrd, parted and the kernel) rather than being kernel-specific.
Bad news: mkinitrd-5.1.9-1 doesn't work with kernel-2.6.17-1.2174_FC5 My hacked /sbin/nash (see comment #9) still works with kernel-2.6.17-1.2174_FC5.
(In reply to comment #18) > Bad news: mkinitrd-5.1.9-1 doesn't work with kernel-2.6.17-1.2174_FC5 Here's why: the "mkrootdev ..." command fails to create the /dev/root node if I have "root=LABEL=/" among the kernel parameters. With "root=/dev/mapper/nvidia..." everything works fine.
I've added bug 204260 and prodded bug 189708. Perhaps we'll get some errata for parted and mkinitrd soon.
Rumor has it that parted-1.7.1-15.fc5 has been pushed (bug 204260)... News at 11.
*** This bug has been marked as a duplicate of 189708 ***