Description of problem: Installed F11 with an lvm-on-RAID partition setup and otherwise default selections, then ran dracut --force initrd-2.6.29.4-167.fc11.i686.PAE.img 2.6.29.4-167.fc11.i686.PAE Aside from some firmware warnings, which I've gotten on all tests, it says it worked. Restarted the system, and it refused to boot. Got no further than the blinking _ in the upper corner. The partition setup I used was: /dev/sda1: /boot, 200M /dev/sda2: RAID, 200M /dev/sda3: RAID, 200M /dev/sda4: Extended /dev/sda5: RAID, 200M /dev/sda6: RAID, 200M /dev/sda7: RAID, 9286M /dev/sda8: RAID, 9286M /dev/sda9: RAID, 9286M /dev/sda10: RAID, 9286M sda2 and sda3 were combined to make md0, sda 5 and sda6 are md1, sda7 and sda8 make md2, and sda9 and sda10 are md3. All four mds are LVMs. md0 and md1 were combined into one VG (vg_dhcp98), and md2 and md3 are another VG (vg_dhcp9800). vg_dhcp98 is swap, and vg_dhcp9800 is mounted as /. (After making /boot and swap, I split the remaining space into 4 approximately equal RAIDs for /. I can't imagine the exact size is important.) Version-Release number of selected component (if applicable): dracut-0.4-1.fc11.i586 How reproducible: Uncertain. I can try again if needed. Steps to Reproduce: 1. Default install of anaconda, except for the (admittedly rather complicated) partitioning setup above 2. Reboot, run dracut --force initrd-2.6.29.4-167.fc11.i686.PAE.img 2.6.29.4-167.fc11.i686.PAE (replace numbers with appropriate kernel version as necessary) 3. Reboot Actual results: System refuses to boot, hangs on blinking _ in the upper left corner. Expected results: A bootable kernel. Additional info: This machine is part of the anaconda minilab, so I can retest as needed.
Can you boot with dracut-0.5 add "rdshell" and remove the "quiet" parameter for more information. Add the debug module while creating the image: # dracut -a debug --force initrd-2.6.29.4-167.fc11.i686.PAE.img 2.6.29.4-167.fc11.i686.PAE If you are dropped to a shell in the initrd do: $ dmesg | grep dracut and paste the output here. See also: https://fedoraproject.org/wiki/Dracut/Debugging https://fedoraproject.org/wiki/Dracut
..huh. The test box got wiped with another install, so I tried this again today. Exact same install parameters, but instead of running dracut, I used git to make a test image then moved that into /boot and updated grub.conf. It rebooted just fine this time (though there was some display wackiness while doing so, see attached images). This was dracut 7.2, I think, according to dracut --version, so it looks to me like the bug has been fixed.
Created attachment 354910 [details] wackiness
Created attachment 354911 [details] further wackiness
Yes, I know the display wackiness. Problem with plymouth. I have to file a bug for plymouth.
Failing on my system--LV over raid 5. When creating the image I see many msgs about stripping kernel modules. One of those stripped was raid 456. dracut drops to a shell and I see: /pre-trigger/30parse-md.sh: 27: Bad substitution and mdadm --detail /dev/md0 returns "no devices" I also see a msgs earlier: [drm: radeon_driver_load_kms] *ERROR* Failed to initialize radeon, disabling IOL radeon 0000:01:00.0: PCI INT A disabled radeon: probe of 0000:01:00.0 failed with error -22 then it trys to start plymouth even tho there is no rhgb or rd_plytheme=charge on the cmd line.
plymouth is always started and falls back to text mode for no "rhgb". plymouth is essentially needed for crypto passwords. Thanks for the "/pre-trigger/30parse-md.sh" error! Fixed in git.
not yet fixed in dracut-0.8-1.fc11.x86_64 From serial console capture of dracut msgs: + echo -n md0 + found=1 + [ rd_LVM_VG=vg_p5ewspro = rd_MD_UUID= ] + [ rd_LVM_VG = rd_MD_UUID ] + [ KEYTABLE=us = rd_MD_UUID= ] + [ KEYTABLE = rd_MD_UUID ] + [ SYSFONT=latarcyrheb-sun16 = rd_MD_UUID= ] + [ SYSFONT = rd_MD_UUID ] + [ LANG=en_US.UTF-8 = rd_MD_UUID= ] + [ LANG = rd_MD_UUID ] + [ root=/dev/mapper/vg_p5ewspro-fedora11 = rd_MD_UUID= ] + [ root = rd_MD_UUID ] + [ console=tty0 = rd_MD_UUID= ] + [ console = rd_MD_UUID ] + [ console=ttyS0,9600 = rd_MD_UUID= ] + [ console = rd_MD_UUID ] + [ -n 1 ] + return 0 + MD_UUID=md0 + [ -n md0 ] + [ -e /etc/udev/rules.d/65-md-incremental-imsm.rules ] + mv /etc/udev/rules.d/65-md-incremental-imsm.rules /etc/udev/rules.d/65-md-incremental-imsm.rules.bak + read line /pre-trigger/30parse-md.sh: 1: Bad substitution + emergency_shell Signal caught! Please note that the dracut-gencmdline generates rd_MD_UUID=md0. Shouldn't this be the real UUID of the md? I.e., f6995482:78580fc7:bfe78010:bc810f04.
Please ignore comment #8. Stupid tester had invalid installation of dracut. Now testing with valid installation, but still can't boot where / is on LV over raid 5.
(In reply to comment #8) > Please note that the dracut-gencmdline generates rd_MD_UUID=md0. Shouldn't > this be the real UUID of the md? I.e., f6995482:78580fc7:bfe78010:bc810f04. yes, it should be.
Created attachment 357171 [details] serial console output of attempt to boot with real UUID for raid dracut-gencmdline is generating rd_MD_UUID=md0 for a system that has / on LV over raid 5. It won't boot. This file shows what happens when the real UUID of the MD is used. It still doesn't work. Without the ability to boot LV over raid, dracut cannot be a default initrd for Fedora 12. This should be a blocker. (the rest of the requested information will be in the next file)
Created attachment 357172 [details] fstab, kernel cmd line, mdstat, etc
OK, working in rawhide, HOWEVER, rawhide gencmdline still creating MD_UUID=md0 instead of using the UUID of the md device. Will see if there is a bz on this. My apologies for the noise above. Fedora11 should get the same changes as rawhide to fix this gz.
Created attachment 358952 [details] serial console of drqcut .9-1-fc11 failure LV over raid 5 Not a generic initrd. Console output also includes my shell commands to actually force the boot by entering by hand mdadm --assemble --scan, vgchange -ay, root=/dev/etc etc. At end are fstab, grub.conf /proc/mdstat.
can you retry with dracut >= 001-7 ?
I don't see a F11 version >= 001-7 in koji yet, or does the F12 version work with both distro?
on rawhide, getting this error when trying to test root LV over raid10. Error occurs with dracut invocation, with or without sudo: sudo dracut -f -v -a debug /boot/dracut-$(uname -r) $(uname -r) and the error msg is: E: Failed to install /usr/lib/python2.6/site-packages/bitfrost/__init__.py $ rpm -q bitfrost bitfrost-1.0.1-2.fc12.x86_64 $ sudo ls /usr/lib/python2.6/site-packages/bitfrost ls: cannot access /usr/lib/python2.6/site-packages/bitfrost: No such file or directory $ however since this is an x86_64 rawhide install: $ sudo ls /usr/lib64/python2.6/site-packages/bitfrost contents __init__.py __init__.pyc __init__.pyo leases update util $ (also: Still no f11 versions >= 001-7.)
what is the output of: # rpm -qf /usr/share/dracut/modules.d/*
# rpm -qf /usr/share/dracut/modules.d/* dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-modules-olpc-0.2.1-2.fc12.x86_64 dracut-network-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-network-001-9.git6f0e469d.fc12.noarch dracut-network-001-9.git6f0e469d.fc12.noarch dracut-network-001-9.git6f0e469d.fc12.noarch dracut-network-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch dracut-001-9.git6f0e469d.fc12.noarch
please remove package dracut-modules-olpc and try again
OK, that works and now can boot LV over raid 10 in rawhide; however, suspected that it should have worked anyway since recent rawhide kernels have shipped with the generic initramfs. I did see this tho with F12 dracut-001-9.git6f0e469d.fc12.noarch $ sudo dracut-gencmdline /sbin/dracut-gencmdline: line 214: get_numeric_dev: command not found /sbin/dracut-gencmdline: line 659: /etc/sysconfig/keyboard: No such file or directory SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 root=/dev/mapper/VolGroup00-rawhide rd_plytheme=charge
(In reply to comment #23) > OK, that works and now can boot LV over raid 10 in rawhide; however, suspected > that it should have worked anyway since recent rawhide kernels have shipped > with the generic initramfs. well dracut-modules-olpc is an add-on and _only_ for olpc pc's ... and not shipped by dracut itsself.
Sorry, I wasn't clear. I meant that since the generic initramfs has been working with LV over raid I was sure dracut would. I installed all of the dracut modules a while ago and just got around to spinning my own test for my rawhide installation and now realize that I should have stuck with just the basic package. Now I'm off to see if I can get dracut to work on F11 with LV over raid. Thanks for your work on this!
Here is a new F-11 version to try: http://koji.fedoraproject.org/koji/buildinfo?buildID=132093
dracut-001-9.git4d924752.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/dracut-001-9.git4d924752.fc11
Created attachment 361142 [details] dracut-001-9.git4d924752.fc11 serial console output Sorry, no luck. Here are the dracut programs installed: $ rpm -qa | grep dracut dracut-001-9.git4d924752.fc11.x86_64 dracut-kernel-001-9.git4d924752.fc11.x86_64 dracut-tools-001-9.git4d924752.fc11.x86_64 In the log file attached, you will see where I was dropped to rdshell because no root device was found, but I was able to start the raid PV and then enable the LVs and then boot. dracut-gencmdline no longer gives the rd_MD_UUID=etc, etc paramater so I hand jammed it in the kernel cmd line, but either way, same result. Here is what gencmdline said: $ sudo dracut-gencmdline /sbin/dracut-gencmdline: line 214: get_numeric_dev: command not found /sbin/dracut-gencmdline: line 214: get_numeric_dev: command not found KEYTABLE=us SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 root=/dev/mapper/vg_p5ewspro-fedora11 rd_plytheme=charge Here is grub.conf: default=0 timeout=20 serial --unit=0 --speed=9600 terminal --timeout=20 serial console title Dracut 2.6.30.5-43.fc11.x86_64 root (hd1,4) kernel /vmlinuz-2.6.30.5-43.fc11.x86_64 ro rd_MD_UUID=f6995482:78580fc7:bfe78010:bc810f04 KEYTABLE=us SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 root=/dev/mapper/vg_p5ewspro-fedora11 rd_plytheme=charge rdshell console=tty0 console=ttyS0,9600 initrd /dracut-2.6.30.5-43.fc11.x86_64 title Main Boot Menu No Serial Console root (1,4) configfile=/grub/grub.conf
dracut-001-9.git4d924752.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update dracut'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9689
dracut-001-12.git0f7e10ce.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/dracut-001-12.git0f7e10ce.fc11
dracut-002-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/dracut-002-1.fc11
-002-1.fc11 does not work. During dracut time just before saying root device can't be found, I see about 15-20 pairs of lvm msgs like: scanning all physical devices this may take some time scanning sda5 and sdb2 It turns out that these two devices are the elements of the underlying raid device that the root LV resides on. The raid device has to be started first, then lvm vgchange -ay then mount the root LV. That sequence is not happening. Once in the dracut shell I can issue: mdadm --scan --assemble and the raid device is started. Then, lvm vgchange --ay and the root LV is activated, then, exit and root LV is mounted and init takes over and system comes up. [root@P5E-WSPRO ~]# dracut-gencmdline /sbin/dracut-gencmdline: line 214: get_numeric_dev: command not found /sbin/dracut-gencmdline: line 214: get_numeric_dev: command not found KEYTABLE=us SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 root=/dev/mapper/vg_p5ewspro-fedora11 rd_plytheme=charge Note that rd_MD_UUID=f6995482:78580fc7:bfe78010:bc810f04 is not being generated. Manually adding it to the kernel cmd line doesn't change anything. [root@P5E-WSPRO ~]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 sda5[0] sdb2[1] 102397888 blocks level 5, 64k chunk, algorithm 2 [2/2] [UU] unused devices: <none> [root@P5E-WSPRO ~]# cat /etc/mdadm.conf ARRAY /dev/md0 level=raid5 num-devices=2 UUID=f6995482:78580fc7:bfe78010:bc810f04
dracut-001-12.git0f7e10ce.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update dracut'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9722
dracut-002-1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update dracut'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9789
dracut-002-2.gitc53acc30.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/dracut-002-2.gitc53acc30.fc11
Created attachment 361774 [details] dracut-002-2.gitc53acc30.fc11.x86_64 serial console output Seems like a bit of regression with this verstion in that I have to manually start the raid PV and then exit the shell two times after manual lvm vgchange -ay. dracut-gencmdline is now creating the proper md UUID, however, dracut is still trying to activate the LVs BEFORE the raid PV is started. Note in the shell part of the log file that an initial ls /dev/m* shows no md devices. After mdadm --assemble --scan, the raid device is started and, of course, ls /dev/m* shows a raid device. I am wondering if there is something unique in my setup? I have bios raid which I am not using. I created the raid PV originally using Fedora 11 anaconda.
Just did a fresh rawhide (20090918) install on root LV on same raid PV as the Fedora 11 installation and created a dracut initramfs. Works great except for some kind of spew from dracut-gencmdline. Will bz the spew. Also noticed that the rawhide version of dracut-gencmdline did not generate a raid UUID and the system booted without it. Problem remains with Fedora 11 dracut.
dracut-002-2.gitc53acc30.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
This is NOT FIXED. Appears to be same problem as before. Dracut is trying to activate LVs before the underlying raidset PV is activated. How can you close a bz for non-working dracut on F11 when dracut on F12 (rawhide) works? Same machine, same raid set, only difference is the LV and the distro? I just don't understand.
I think the F-11 version will never work, because udev's vol_id is not as sophisticated as blkid. can you do: on F-11 # for i in $(seq 1 10); do vol_id --export $i;done and on F-12: # for i in $(seq 1 10); do blkid -o udev -p $i;done btw, the bug was closed automatically ... sry for that
of course it should be on F-11 # for i in $(seq 1 10); do vol_id --export /dev/sda$i;done and on F-12: # for i in $(seq 1 10); do blkid -o udev -p /dev/sda$i;done
of course it should be on F-11 # for i in $(seq 1 10); do /lib/udev/vol_id --export /dev/sda$i;done
Created attachment 362519 [details] /dev/sda partition info - as requested As requested.
In view of comment 40, I understand perfectly that if it won't work, that is just the way it is. May I suggest a hack though? Since F11 dracut-gencmdline does find the UUID of the raid set, just put mdadm --assemble --scan in the stream prior to activating the LVs. That is the first thing I do when dropped to the rdshell. This may cause unwanted raid sets to be activated, but perhaps the UUID can also be provided such that the command would be mdadm --assemble --uuid=<some uuid>
No go for: $ rpm -qa | grep dracut dracut-002-9.git99fd62e3.fc11.x86_64 dracut-tools-002-9.git99fd62e3.fc11.x86_64 The underlying md0 PV is still not being activated before LVM starts searching physical devices for VGs/LVs. Instead, the physical partitions making up the raidset are probed over and over (sda5 anc sdb2). When dropped to a shell, I can still mdadm --assemble --scan and activate the raidset. Then exit the shell and dracut finds the root LV, but, strangely, again drops to the shell and then a simple exit then mounts the root LV and continues with init.
well, in fact.. I don't care in this special case about F-11... :-) dracut is for F-12 .. not F-11 and I don't want to rewrite vol_id. You might want to install udev from F-12 with: # yum --disablerepo=* --enablerepo=rawhide update udev and your problem should be solved.
Cute. # yum --disablerepo=* --enablerepo=rawhide update udev leads to: <long list of packages to be installed and updated> Transaction Summary ===================================================================================================== Install 51 Package(s) Upgrade 241 Package(s) Total download size: 288 M Is this ok [y/N]: n Exiting on user Command Complete! With this many F12 pkgs imposed on a F11 installation, who knows what new problems in other areas/pkgs will manifest themselves. Why don't you just abandon F11? And, close this bug as won'tfix? I don't think anyone would complain. I know I won't. It has just become a nuisance anyway to try to get it to work on LV over raid (which is common enough, but mkinitrd happily is available and we have lived nicely with it for a long time). I do admire your persistence tho it trying to come up with a solution.
ok, so it be :) Thx for testing!