After installing 2.6.22.1-32 on 2 different systems and rebooting them, they both fail to boot with the same errors. Reverting to 2.6.20-1.2962 boots fine. Each system uses different hardware. system1 uses a 3ware RAID card, system2 usees an aacraid card. Each is partitioned the same using labels. Changing grub and fstab to use raw devices instead of labels doesn't change the behavior. /dev/sda1 /boot /dev/sda2 swap /dev/sda3 / Here is what the console reports on both machines (attached are screenshots from each as well): Trying to resume from LABAL=swap Unable to access resume device (LABEL=swap) Creating root device. Mounting root filesystem. mount: could not find filesystem '/dev/root' Setting up other filesystems. Setting up new root fs. setuproot: moving /dev failed: No such file or directory no fstab.sys, mounting internal defaults setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /sys switchroot: mount failed: No such file or directory Kernel panic - not sycning: Attempted to kill init!
Created attachment 161021 [details] system1-mountfailed.png System 1. This has a 3ware IDE RAID controller.
Created attachment 161022 [details] system2-mountfailed.png System 2. This has an aacraid SCSI raid controller.
Okay, this is probably due to the SCSI asyncrhonous scanning being enabled. Fixed in CVS, new kernel is building.
It seems that F7 also has SCSI asynchronous scanning enabled (I just upgraded one of those machines to F7) and it doesn't have any issues finding the root devices and booting up. Is there some userspace script that needs fixing to enable this feature reliably? Perhaps that would be the better fix rather than disabling SCSI_SCAN_ASYNC which can significantly reduce boot times on some systems.
F7 has a new version of mkinitrd and I'm not so sure we want to require that. Async scanning was off in the previous FC6 kernel anyway, so leaving it off isn't a regression.
Test kernel with async SCSI scan disabled is at: http://people.redhat.com/cebbert/kernels/FC6/
Thanks, unfortunately I won't be able to test until Monday - all my home machines are already on F7.
This kernel fixes my booting problem, which was with an aic7892: Ultra160 with a number of luns and the same messages: unmounting old /dev unmounting old /proc unmounting old /sys switchroot: mount failed: No such file or directory Kernel panic - not sycning: Attempted to kill init!
same problem with Adaptec 29160N Ultra160 SCSI adapter; kernel-2.6.22.2-39.fc6 is OK, thanks
Can confirm that kernel-2.6.22.2-39.fc6 fixes the boot issue on the my system which uses a 3ware RAID card. Haven't tested my other system since it has 4GB+ ram and it is using a PAE kernel right now, but I would expect it to work fine, too given the other reports of success.
kernel-2.6.22.2-39.fc6 works fine again with my onboard AIC-7880 controller chip.
Looks like the updated kernel has hit updates-testing, I have successfully booted my other FC6 machine with kernel-PAE-2.6.22.2-39.fc6 and the aacraid driver without issue.
This was fixed in 2.6.22.2-39 but seems to be broken again (same failure mode as 2.6.22.1-32) in 2.6.22.2-42.
(In reply to comment #13) I cannot confirm this regression. Booting 2.6.22.2-42.fc6, all volumes are found and mounted as expected.
Same issue occuring under 2.6.22.2-42 with LSI Logic drivers (under vm). Booting into 2.6.18 lvm shows all groups, yet none are found when booting under default 2.6.22.2-42 (after yum update).
(In reply to comment #13) > This was fixed in 2.6.22.2-39 but seems to be broken again (same failure mode as > 2.6.22.1-32) in 2.6.22.2-42. This bug has been fixed, there may be a different one preventing boot though. Open a new bug if the problem continues.
(In reply to comment #15) > Same issue occuring under 2.6.22.2-42 with LSI Logic drivers (under vm). > Booting into 2.6.18 lvm shows all groups, yet none are found when booting under > default 2.6.22.2-42 (after yum update). Bugs in vm can be fixed by choosing a different controller emulation. This is not a kernel bug -- the vm isn't properly emulating the controller.