Description of problem: I have installed the latest updates, including kernel-2.6.40-4.fc15.x86_64. Booting this kernel stops halfway. If I press the Esc key and look at messages printed during boot, I see the following: Dropping to debug shell sh: can't access tty: job control turned off and a dracut prompt is presented. Version-Release number of selected component (if applicable): kernel-2.6.40-4.fc15.x86_64 dracut-009-12.fc15.noarch How reproducible: Happens every time. Steps to Reproduce: 1. Boot kernel-2.6.40-4.fc15.x86_64 Actual results: The boot stops halfway through and the computer is not usable. Expected results: The boot should continue until the login screen is presented. Additional info: Booting with kernel-2.6.38.8-35.fc15.x86_64 via the Grub menu results in a complete boot. My computer uses Intel BIOS RAID.
Confirm the problem additional information on Steps to Reproduce: 1. Boot kernel vmlinuz-2.6.40-4.fc15.i686 2. Boot kernel vmlinuz-2.6.40-4.fc15.i686.PAE Debug shell: No message after the last: (Started SYSV: Late init script for live image)
I am having the same problem on a Fedora 15 system, booting to kernel-2.6.40-4 stops at: Dropping to debug shell sh: can't access tty: job control turned off dmesg contains a message saying a root device cannot be found. But the kernel was able to boot at the first time, and after using it for a little while, the whole screen started to blur and shake. After that, rebooting into the kernel failed. Booting to kernel 2.6.38.8-35.fc15.x86_64 is ok. Also, my machine has an Intel 82801 SATA RAID Controller set to RAID0. The video card is ATI Raedon HD 5870.
I was unable to boot my machine with kernel 2.6.40-4.fc15.x86_64 or 2.6.38.8-35.fc15.x86_64 after doing the latest yum update. My machine has two hard drives that are using a software mirror (raid1) to create a md device for /boot on one partition. I create another md device on another partition to hold my physical volume for / and other logical volumes. I did finally figure out that I was able to boot from the 2.6.40-4.fc15.x86_64 kernel again after getting dropped to the dracut prompt and manually starting the md devices and activating the logical volumes. dracut:/# mdadm --assemble --scan mdadm: /dev/md0 has been started with 2 drives. mdadm: /dev/md1 has been started with 2 drives. dracut:/# lvm vgscan File descriptor 9 (/.console_lock) leaked on lvm invocation. Parent PID 828: sh Reading all physical volumes. This may take a while... Found volume group "vg0" using metadata type lvm2 dracut:/# lvm vgchange -ay File descriptor 9 (/.console_lock) leaked on lvm invocation. Parent PID 828: sh 5 logical volume(s) in volume group "vg0" now active dracut:/#exit I don't fully understand why the old kernel wouldn't boot, and when dropped into the dracut shell for the old 2.6.38.8-35.fc15.x86_64 kernel, I can only see one of the md devices. dracut:/# mdadm --assemble --scan mdadm: /dev/md0 has been started with 2 drives. dracut:/# lvm vgscan File descriptor 9 (/.console_lock) leaked on lvm invocation. Parent PID 828: sh Reading all physical volumes. This may take a while... No volume groups found This leaves me unable to boot the old kernel anymore. Thankfully, I don't need to reboot this machine often, so I can boot it up manually for now on the new kernel using the above method.
Additional info: dmesg within dracut shell says: No root device found "block:/dev/disk/by-uuid/...b27d" Tried to change the grub command line from "root=UUID=...b27d" to "root=/dev/md126p3", still cannot boot; dmesg says No root device found "block:/dev/md126p3". The kernel 2.6.38.8-35.fc15.x86_64 boots ok with either of the "root" option. Looking into my /dev/disk/by-uuid with the kernel 2.6.38, there are ...b27b; but it doesn't show within the dracut shell. The /etc/mdadm.conf only shows to different uuid: ARRAY /dev/md126 UUID=...f009 ARRAY /dev/md127 UUID=...1da9 dmesg within dracut shell also seemingly implies the assembly of RAID1 was successful before reporting the unfound root devcie: mdadm: Container /dev/md127 has been assembled with 2 devices mdadm: array /dev/md126 now has 2 devcies /dev/md/md-device-map also shows matching information. How to manually find and mount the root device? Thanks!
BTW, not sure whether it's relevant: before dropping into dracut shell, the boot process also says "alg: skcipher: Failed to load transform for ecb-aes-aesni: -2" as reported by Bug 721002: https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=721002 Both kernel 2.6.40 and 2.6.38 show such error message though.
Same here: Dell Dimension 9200 00:1f.2 RAID bus controller: Intel Corporation 82801 SATA RAID Controller (rev 02) ICH8 Family
Same here: ASUS P6T Deluxe v2, running RAID 10 with LVM and root on separate SSD non RAID 00:1f.2 RAID bus controller: Intel Corporation 82801 SATA RAID Controller 00:1f.3 SMBus: Intel Corporation 82801JI (ICH10 Family) SMBus Controller Cannot boot 2.6.40 and drops to dracut, if select 2.6.38 in grub boot as normal
Same, ABIT IP35PRO motherboard, raid 1. However, sometimes it did boot and sometimes dropped to dracut shell. Always had 2.6.38 to fall back on until recent update crashed while updating and wiped boot menu and left me with just 2.6.40.. now have no bootable system at all :(.
Similar symptom to Marty's: The latest update on my system (many packages were updated) wiped out everything from the boot menu...nothing is bootable now :(
PS... high severity issue for us :)
I found this today, which gives some clues about what is happening: https://bbs.archlinux.org/viewtopic.php?id=125808 "How I saved my mdadm RAID setup from Kernel 3.0 and udev"
The referenced blog post sounds like something in udev or the initramfs is keeping mdadm from writing its device-map file. If mdadm can't write a device-map file when doing incremental assembly, it will put each member of an array into different arrays and never assemble them properly. I'll download the latest installer image and see if I can reproduce your issue here.
Following up on this - in our environment, this only happens with kernel > 2.6.40 *AND* the soft array is rebuilding or verifying. If the array is healthy, it will boot without issue. If this matches the behavior described in the 'kernel 3.0 and udev' post above, great.
This problem also reaches me. My RAID0 consist of two Seagate devices united by Gigabyte RAID Controller on motherboad GA-EX58-UD3R. I've updated to Rusian Fedora 15.1 with kernel 2.6.40 and system is now dropping to dracut. I used to boot to old kernel, 2.6.38 but after some update (don't remember which one :( ) system died at all. I thought that is RFRemix failt, but the situation is the same with original Fedora 15 KDE Spin. Now I'm trying to make clean install of Russian Fedora with 2.6.40 kernel, but Anaconda doesn't see my RAID volume at all, exact message: "Disks sda, sdb contain BIOS RAID metadata, but are not part of any recognized BIOS RAID sets. Ignoring disks sda, sdb".
I have been using kernel-2.6.40.6-0.fc15 for a while. I have tried to reboot only when there is not a resync occurring (as per Comment #13). I have found that when I reboot, the array will always start a resync.
*** This bug has been marked as a duplicate of bug 736387 ***