Created attachment 812136 [details] sosreport.txt Description of problem: I cannot boot successfully with an initramfs created using "dracut -N" for --no-hostonly mode. I came across this problem when installing Fedora 19 into a chroot hosted inside Fedora 14. In that environment, when I run chroot, I get these messages: dracut -f /boot/initramfs-3.10.11-200.fc19.x86_64.img 3.10.11-200.fc19.x86_64 W: Turning off host-only mode: '/run' is not mounted! W: Turning off host-only mode: udev database not found! I had to boot into a Fedora 19 rescue shell in order to run dracut again to get a working initramfs (in usual hostonly mode). I subsequently tested that running "dracut -N" in a working Fedora 19 system does not generate a bootable initramfs. Version-Release number of selected component (if applicable): dracut-029-2.fc19.x86_64 How reproducible: On a Fedora 19 system, run "dracut -N /boot/initramfs.nohostonly `uname -r`" and then try to boot using that initramfs. Steps to Reproduce: 1. Run "dracut -N /boot/initramfs.nohostonly `uname -r`" 2. Edit grub.cfg or extlinux.conf to add an entry using the new initramfs 3. Actual results: System should boot Expected results: It does not boot. Additional info: I am using MD raid 1 on this system: sh-4.2# cat /proc/mdstat Personalities : [raid1] md125 : active raid1 sdb3[1] sda3[0] 150872384 blocks super 1.2 [2/2] [UU] md126 : active (auto-read-only) raid1 sdb2[1] sda2[0] 4191168 blocks super 1.2 [2/2] [UU] md127 : active raid1 sdb1[1] sda1[0] 1049536 blocks super 1.0 [2/2] [UU] unused devices: <none> sh-4.2# pvs PV VG Fmt Attr PSize PFree /dev/md125 vg_sys lvm2 a-- 143.88g 95.25g sh-4.2# lvs LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert extra_disk vg_sys -wi-ao--- 23.38g root vg_sys -wi-ao--- 1.62g usr vg_sys -wi-ao--- 22.00g var vg_sys -wi-ao--- 1.62g sh-4.2# cat /etc/fstab UUID=a46c4049-d7cd-4f65-ae66-f127edb2ab6c / ext4 defaults,noatime 1 1 UUID=818abaaa-3e66-4df1-bb91-cb259947b17f /boot ext4 defaults,noatime 1 2 UUID=bdda7f59-d3fb-4ad6-b25c-5f496bdad07c /extra_disk xfs defaults,nobarrier 1 2 UUID=aafa645a-2608-46ae-ab0a-2336f503ac08 /usr ext4 defaults,noatime 1 2 UUID=115c3cad-2f9b-4722-82fe-50ba69192a7b /var ext4 defaults 1 2 UUID=38240737-c431-4e2d-b1b9-55cf50c4f930 swap swap defaults 0 0 The /boot partition is on /dev/md127, and the other partitions are logical volumes.
(In reply to Andrew J. Schorr from comment #0) > Description of problem: I cannot boot successfully with an initramfs created > using "dracut -N" for --no-hostonly mode. In "no-hostonly"/generic mode, you have to tell dracut how to assemble your devices. You can either add "rd.auto=1" to the kernel command line and dracut tries to assemble everything it finds, or you can specify exactly which devices dracut should assemble. In your case you would have to add to the kernel command line: "rd.md.uuid=<MD_UUID_1> rd.md.uuid=<MD_UUID_2> rd.lvm.vg=vg_sys" With MD_UUID_1 MD_UUID_2 being the MD UUIDs of your raids: # /sbin/mdadm --examine --export /dev/md125 | grep MD_UUID # /sbin/mdadm --examine --export /dev/md126 | grep MD_UUID
Thanks. That is very helpful. I tested one machine, and adding "rd.auto" to the kernel command line seems to fix the problem. This leaves me with 2 questions: 1. Is there any reason one would not want to include rd.auto on the kernel command line? 2. Wouldn't it make sense for the dracut man page to mention that rd.auto is required when the -N option is used? Or is this required only because I am using MD arrays? The warning messages from dracut also do not give a proper sense of impending doom: W: Turning off host-only mode: '/run' is not mounted! W: Turning off host-only mode: udev database not found! It would be nice if they warned that the system might not be bootable unless rd.auto is passed to the kernel. Thanks, Andy
(In reply to Andrew J. Schorr from comment #2) > Thanks. That is very helpful. I tested one machine, and adding "rd.auto" to > the kernel command line seems to fix the problem. > > This leaves me with 2 questions: > > 1. Is there any reason one would not want to include rd.auto on the kernel > command line? yes, rd.auto only works for very simple setups. For machines with multiple raids, lvms, etc. you don't want to assemble "everything", because you might actually not need it. And assembling mostly modifies timestamps, etc. You only want to assemble as much as you need to get to the root device. > > 2. Wouldn't it make sense for the dracut man page to mention that rd.auto > is required when the -N option is used? Or is this required only because > I am using MD arrays? The warning messages from dracut also do not > give a proper sense of impending doom: > > W: Turning off host-only mode: '/run' is not mounted! > W: Turning off host-only mode: udev database not found! Well, if you run in a chroot, make sure you present a proper chroot environment with /run /dev /sys /proc mounted (maybe bind mounted from the outside). > > It would be nice if they warned that the system might not be bootable > unless rd.auto is passed to the kernel. dracut does not know the kernel command line you will be using and rd.auto is only the last resort, if you don't know your setup.
Thanks for the clarifications. I wish the man page made it clear that non-host-only mode may not boot unless the appropriate kernel parameters are provided. There is currently a big warning about the default (-H) mode, but no warnings about -N. If you were to read the man page, you would conclude that -N is safer than -H, whereas the opposite is the case. It would also be nice if the runtime warnings were to indicate that special kernel arguments may be required for booting. Thanks, Andy
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.