Bug 1085952 - kernel 3.13.9-200 does not boot on intel BIOS RAID
Summary: kernel 3.13.9-200 does not boot on intel BIOS RAID
Keywords:
Status: CLOSED DUPLICATE of bug 1084766
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 20
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-09 17:55 UTC by Kriton Kyrimis
Modified: 2014-04-17 17:36 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-04-17 17:36:00 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Kriton Kyrimis 2014-04-09 17:55:26 UTC
Description of problem:
The latest kernel, 3.13.9-200, does not boot on my computer, which has an Intel Core 2 Duo E8600 processor, with the system disk on a BIOS RAID 0 volume. At boot time, the Plymouth screen appears, progressing slowly, but the disk is not accessed at all. If I press escape, I see very little output, but no errors. The last message printed is "Reached target Basic System."

Version-Release number of selected component (if applicable):
3.13.8-200.fc20.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Boot the computer

Actual results:
The computer stays stuck on the Plymouth screen.

Expected results:
The computer should boot.

Additional info:
Kernels up to 3.13.8-200.fc20.x86_64 booted fine.

The problem did not appear on a VirtualBox VM running Fedora 20.

Removing "quiet rhgb" from the kernel command line produced some additional output during boot, with messages about mounting storage devices, again without any obvious (to me) error messages. This, coupled with the lack of disk activity, suggests to me that the system disk is not recognized by the kernel, which is unable to proceed. This is why I suspect that the problem lies with mounting the RAID volume.

If more information is required, to identify the problem, I will be happy to provide it.

Comment 1 Josh Boyer 2014-04-09 18:13:06 UTC
What version of dracut do you have installed?  This might be a duplicate of bug 1084766

Comment 2 Kriton Kyrimis 2014-04-09 18:22:41 UTC
dracut-037-10.git20140402.fc20.x86_64

Comment 3 Josh Boyer 2014-04-09 18:25:56 UTC
OK, that is the version impacted by the bug I referenced.  Harald can reassign if necessary.

Comment 4 Kriton Kyrimis 2014-04-09 18:43:58 UTC
I can confirm that downgrading dracut and reinstalling the kernel caused the problem to disappear.

Comment 5 Bill Perkins 2014-04-09 23:21:47 UTC
I have three Dell Optiplex GX620 (x86_64) systems that I purchased at a surplus store back in 2012.  All three of them are running up-to-date Fedora 20 installations.  The only differences are amounts of memory and the disk subsystem configurations.

The first Dell (#1) has 4 GB of memory and is running LVM on top of software RAID level 1 disks connected internally and externally via the motherboard's Intel Corporation NM10/ICH7 Family SATA Controller.

The second Dell (#2) has 4 GB of memory and is also running LVM on top of a RAID level 1, with this difference: It has a SATA add-on card, a ASMedia Technology Inc. ASM1062 Serial ATA Controller, that is used to drive both the internal and external disks used in the RAID configuration.  The motherboard's SATA controller is used to support the SATA DVD drive that replaced the original IDE drive.

The third Dell (#3) has 2 GB of memory and is not running RAID, but has the LVM configuration on a single disk connected to the motherboard's Intel Corporation NM10/ICH7 Family SATA Controller.

Dell #1 after the update of the kernel to 3.13.9-200.fc20.x86_64 and dracut 037-10.git20140402.fc20.x86_64, a reboot caused the boot process to halt at "Reached target Basic System" and wait several minutes before drop in the dracut prompt.  there were no RAID or LVM devices configured for this boot.  So I executed the following commands at the dracut prompt:
mdadm -A /dev/md0 /dev/sda1 /dev/sdb1
mdadm -A /dev/md1 /dev/sda2 /dev/sdb2
lvm> vgchange -a y
exit (from dracut)

The system (#1) then proceeded to complete the boot process with no other apparent problems.  Downgrading dracut to 034-64.git20131205.fc20.x86_64 did not change the problem.  The only way to get this system to boot correctly was to use an older kernel.  The version of dracut did not seem to matter.

Dells #2 and #3 are currently running the kernel 3.13.9-200.fc20.x86_64 and dracut 037-10.git20140402.fc20.x86_64 without any issues.

Comment 6 Bill Perkins 2014-04-09 23:43:10 UTC
A correction to (In reply to Bill Perkins from comment #5)
> I have three Dell Optiplex GX620 (x86_64) systems that I purchased at a
> surplus store back in 2012.  All three of them are running up-to-date Fedora
> 20 installations.  The only differences are amounts of memory and the disk
> subsystem configurations.
> 
> The first Dell (#1) has 4 GB of memory and is running LVM on top of software
> RAID level 1 disks connected internally and externally via the motherboard's
> Intel Corporation NM10/ICH7 Family SATA Controller.
> 
> The second Dell (#2) has 4 GB of memory and is also running LVM on top of a
> RAID level 1, with this difference: It has a SATA add-on card, a ASMedia
> Technology Inc. ASM1062 Serial ATA Controller, that is used to drive both
> the internal and external disks used in the RAID configuration.  The
> motherboard's SATA controller is used to support the SATA DVD drive that
> replaced the original IDE drive.
> 
> The third Dell (#3) has 2 GB of memory and is not running RAID, but has the
> LVM configuration on a single disk connected to the motherboard's Intel
> Corporation NM10/ICH7 Family SATA Controller.
> 
> Dell #1 after the update of the kernel to 3.13.9-200.fc20.x86_64 and dracut
> 037-10.git20140402.fc20.x86_64, a reboot caused the boot process to halt at
> "Reached target Basic System" and wait several minutes before drop in the
> dracut prompt.  there were no RAID or LVM devices configured for this boot. 
> So I executed the following commands at the dracut prompt:
> mdadm -A /dev/md0 /dev/sda1 /dev/sdb1
> mdadm -A /dev/md1 /dev/sda2 /dev/sdb2
> lvm> vgchange -a y
> exit (from dracut)
> 
> The system (#1) then proceeded to complete the boot process with no other
> apparent problems.  Downgrading dracut to 034-64.git20131205.fc20.x86_64 did
> not change the problem.  The only way to get this system to boot correctly
> was to use an older kernel.  The version of dracut did not seem to matter.
> 
> Dells #2 and #3 are currently running the kernel 3.13.9-200.fc20.x86_64 and
> dracut 037-10.git20140402.fc20.x86_64 without any issues.

One thing I did not do was to remove and reinstall the kernel 3.13.9-200.fc20.x86_64 AFTER downgrading dracut to 034-64.git20131205.fc20.x86_64.  Reinstalling the kernel 3.13.9-200.fc20.x86_64 after doing so caused the system (#1) to boot normally without any problems.

Comment 7 poma 2014-04-11 08:31:28 UTC
037-10.git20140402.fc20 hangs on mirrored/lvm root disk
https://bugzilla.redhat.com/show_bug.cgi?id=1084766

Comment 8 Harald Hoyer 2014-04-11 12:23:52 UTC
see: https://bugzilla.redhat.com/show_bug.cgi?id=1084766

please check, that your kernel command line contains all needed information.

Install new dracut:
# dracut --print-cmdline

Comment 9 poma 2014-04-11 13:19:50 UTC
Would you care to explain what is reasoning for this commit?
http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/modules.d/90mdraid/module-setup.sh?id=ab9457e

Comment 10 Kriton Kyrimis 2014-04-11 16:55:44 UTC
(In reply to Harald Hoyer from comment #8)

> please check, that your kernel command line contains all needed information.
> 
> Install new dracut:
> # dracut --print-cmdline

I don't know to whom this request was addressed, but here is the output on my system:

 rd.lvm.lv=vg_kriton/lv_swap 
 rd.lvm.lv=vg_kriton/lv_root 
 rd.md.uuid=bd95aee2:70e9982d:222d758d:71e22747 resume=/dev/mapper/vg_kriton-lv_swap  root=/dev/mapper/vg_kriton-lv_root rootflags=rw,relatime,stripe=64,data=ordered rootfstype=ext4


Dracut is version 037-10.git20140402. The kernel was installed with dracut 034-64.git20131205.

Comment 11 Adam Williamson 2014-04-17 17:36:00 UTC

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


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