Bug 1085773

Summary: Fails to boot with software RAID
Product: [Fedora] Fedora Reporter: Enrico Scholz <rh-bugzilla>
Component: dracutAssignee: dracut-maint-list
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 20CC: awilliam, dracut-maint-list, harald, jcarpenter, jonathan
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-17 17:32:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
sosreport none

Description Enrico Scholz 2014-04-09 10:20:38 UTC
Created attachment 884460 [details]
sosreport

Description of problem:

With recent dracut, the system does not boot because software raid devices are not assembled anymore.

Downgrade to dracut-034-64.git20131205.fc20.1.x86_64 and regenerating initramfs fixes it.

The device reported as missing is

| /dev/mapper/vg01-root: UUID="b323fd5a-ab8f-4b7d-bb7f-feee7689cdbc" TYPE="ext4" 

A working setup shows

[    1.054200] random: nonblocking pool is initialized
[    1.058079] usb 2-1: New USB device found, idVendor=8087, idProduct=0024
[    1.058142] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.058346] hub 2-1:1.0: USB hub found
[    1.058452] hub 2-1:1.0: 8 ports detected
[    1.070543] md: bind<sdc1>
[    1.083729] fbcon: inteldrmfb (fb0) is primary device
[    1.093421] md: bind<sdc3>
[    1.098275] md: bind<sda1>
[    1.100377] md: raid1 personality registered for level 1
[    1.100525] md/raid1:md126: active with 2 out of 2 mirrors
[    1.100535] md126: detected capacity change from 0 to 536805376
[    1.105955]  md126: unknown partition table
[    1.115938] md: bind<sda3>
[    1.117727] md/raid1:md127: not clean -- starting background reconstruction
[    1.117728] md/raid1:md127: active with 2 out of 2 mirrors
[    1.117737] md127: detected capacity change from 0 to 1999189770240
[    1.117784] RAID1 conf printout:
[    1.117785]  --- wd:2 rd:2
[    1.117786]  disk 0, wo:0, o:1, dev:sdc3
[    1.117787]  disk 1, wo:0, o:1, dev:sda3
[    1.132694] usb 1-1.2: new high-speed USB device number 3 using ehci-pci
[    1.140957]  md127: unknown partition table
[    1.322643] tsc: Refined TSC clocksource calibration: 3092.973 MHz
[    1.362801] Console: switching to colour frame buffer device 160x64

The 'md' related information are missing with the new dracut.

Size of the new initramfs has been increased by 50% too (from working 12MiB to non-working 18MiB).


Version-Release number of selected component (if applicable):

dracut-037-10.git20140402.fc20


How reproducible:

100%

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

Comment 2 Harald Hoyer 2014-04-11 12:24:01 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 3 Enrico Scholz 2014-04-11 14:02:05 UTC
Kernel options have not been changed and are the same in the working and non working case.  I did a normal update within Fedora 20 (and not something like a major upgrade from Fedora X to Fedora X+1 where I would look for such changes in the release notes) and it is a bug that this upgrade renders the system unbootable.

Comment 4 Adam Williamson 2014-04-17 17:32:02 UTC
His cmdline is in the attachment.

BOOT_IMAGE=/vmlinuz-3.13.9-200.fc20.x86_64 root=UUID=b323fd5a-ab8f-4b7d-bb7f-feee7689cdbc ro rhgb rd_NO_LUKS 8250_core.nr_uarts=16 8250.nr_uarts=16 LANG=de_DE.UTF-8 KEYTABLE=us

pretty likely it's "missing something" (with dracut's new, unacceptably backwards-incompatible behaviour), and so this is yet another case of 1084766.

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