Bug 727696 - booting of kernel-2.6.40 stops at dracut shell
Summary: booting of kernel-2.6.40 stops at dracut shell
Status: CLOSED DUPLICATE of bug 736387
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 15
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-02 22:14 UTC by Aram Agajanian
Modified: 2011-10-21 17:25 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-10-21 16:01:26 UTC

Attachments (Terms of Use)

Description Aram Agajanian 2011-08-02 22:14:38 UTC
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):

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- via the Grub menu results in a complete boot.

My computer uses Intel BIOS RAID.

Comment 1 Cyrus Sazi 2011-08-03 12:16:20 UTC
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)

Comment 2 Fun Xue 2011-08-03 12:42:04 UTC
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 is ok.

Also, my machine has an Intel 82801 SATA RAID Controller set to RAID0.
The video card is ATI Raedon HD 5870.

Comment 3 Charles J. Gruener 2011-08-03 15:11:10 UTC
I was unable to boot my machine with kernel 2.6.40-4.fc15.x86_64 or 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

I don't fully understand why the old kernel wouldn't boot, and when dropped into the dracut shell for the old 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.

Comment 4 Fun Xue 2011-08-05 06:17:16 UTC
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 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!

Comment 5 Fun Xue 2011-08-05 06:24:26 UTC
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.

Comment 6 Serge Droz 2011-08-05 12:58:18 UTC
Same here:

Dell Dimension 9200
00:1f.2 RAID bus controller: Intel Corporation 82801 SATA RAID Controller (rev 02)
ICH8 Family

Comment 7 James Hobbs 2011-08-13 21:43:52 UTC
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

Comment 8 Marty 2011-08-25 09:07:31 UTC
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 :(.

Comment 9 Fun Xue 2011-09-02 07:35:24 UTC
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 :(

Comment 10 Marty 2011-09-02 11:32:42 UTC
PS... high severity issue for us :)

Comment 11 Chuck Ebbert 2011-09-14 08:25:24 UTC
I found this today, which gives some clues about what is happening:

"How I saved my mdadm RAID setup from Kernel 3.0 and udev"

Comment 12 Doug Ledford 2011-09-14 14:47:11 UTC
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.

Comment 13 Jeff 2011-09-14 21:39:58 UTC
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.

Comment 14 letishnick 2011-09-17 07:41:10 UTC
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".

Comment 15 Aram Agajanian 2011-10-10 19:16:27 UTC
I have been using kernel- 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.

Comment 16 Aram Agajanian 2011-10-21 16:01:26 UTC

*** This bug has been marked as a duplicate of bug 736387 ***

Note You need to log in before you can comment on or make changes to this bug.