Bug 1286464 - Can not boot from mdraid with LVM on top of it
Summary: Can not boot from mdraid with LVM on top of it
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-29 19:09 UTC by Adam Pribyl
Modified: 2015-12-01 12:58 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-01 12:58:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Adam Pribyl 2015-11-29 19:09:06 UTC
Description of problem:
I can not boot any F22 kernel generated with F22 dracut on the system with mdraid with LVM on top of it. Old F21 kernel works OK (but initramfs was generated with different dracut version).

After I am dropped into dracut shell I found in the log:
dracut-pre-trigger[238]: rd.md=0: removing MD RAID activation

blkid shows devices just fine.

/etc/default/grub:
GRUB_CMDLINE_LINUX="rd_NO_LUKS"

grub.cfg commandline
 linux   /vmlinuz-4.2.6-200.fc22.i686+PAE root=/dev/VolGroup00/LogVol00 rd_NO_LUKS rw rd.info rd.convertfs SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us

 lsinitrd /boot/initramfs-4.2.6-200.fc22.i686+PAE.img | grep mdadm
-rw-r--r--   1 root     root          275 Jun 19  2014 etc/mdadm.conf
-rwxr-xr-x   1 root     root       579592 Nov 27 13:24 usr/sbin/mdadm

..../usr/lib/dracut/hooks/pre-trigger/30-parse-md.sh 
if ( ! [ -n "$MD_UUID" ] && ! getargbool 0 rd.auto ) || ! getargbool 1 rd.md -d -n rd_NO_MD; then

dracut --print-cmdline
 rd.lvm.lv=VolGroup00/LogVol01 
 rd.lvm.lv=VolGroup00/LogVol00 
 rd.md.uuid=3daa99a8:51a9bbe9:1e73ef99:ce2f1c1b  rd.md.uuid=6e7106c3:1a4c0e00:3b660688:164223d9  resume=/dev/mapper/VolGroup00-LogVol01 root=/dev/mapper/VolGroup00-LogVol00 rootflags=rw,relatime,seclabel,data=ordered rootfstype=ext4


It seems to me, like dracut no more initializes mdraid when there is /etc/mdadm.conf and requires the rd.md argument to be present somewhere. But I thought it should be generated by kernel install the ways that it works.

Version-Release number of selected component (if applicable):
dracut-041-14.fc22.i686

How reproducible:
always

Steps to Reproduce:
1. install kernel
2. try to boot it


Actual results:
dracut shell

Expected results:
boot

Additional info:
Seems similar to:
https://bugzilla.redhat.com/show_bug.cgi?id=1084766
but probably has a different cause.

Comment 1 Harald Hoyer 2015-11-30 09:58:29 UTC
dracut does not hardcode the md config in the initrd anymore. So you have to specify the rd.md.uuid's on the kernel cmdline or add "rd.auto=1".

Comment 2 Adam Pribyl 2015-12-01 10:43:59 UTC
1. mdadm.conf is there, just it is not used for anything probably. In past it was used in 30-parse-md.sh to detect there is a raid that needs initialization.

2. what is the correct way to automatically get the rd.md of rd.auto options to kernel command line? I thought this should be done during kernel install (initramfs creation), otherwise it renders system unbootable with new kernel.

Of course I can put rd.auto in /etc/default/grub manually, but it seems weird to me, that default kernel installation method is not detecting raid.

If this is OK, that it needs manual intervention, then close please.

Comment 3 Harald Hoyer 2015-12-01 12:58:10 UTC
(In reply to Adam Pribyl from comment #2)
> 1. mdadm.conf is there, just it is not used for anything probably. In past
> it was used in 30-parse-md.sh to detect there is a raid that needs
> initialization.
> 
> 2. what is the correct way to automatically get the rd.md of rd.auto options
> to kernel command line? I thought this should be done during kernel install
> (initramfs creation), otherwise it renders system unbootable with new kernel.

# dracut --print-cmdline
for a hint, then edit your grub config by hand

Sorry, anaconda puts this in there by default on new installations. The upgrade path missed this.

> 
> Of course I can put rd.auto in /etc/default/grub manually, but it seems
> weird to me, that default kernel installation method is not detecting raid.
> 
> If this is OK, that it needs manual intervention, then close please.

Yes, it needs manual intervention. Sorry for the inconvenience.


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