Description of problem: Dracut is dropping into its emergency shell with message "Unable to process initqueue". Cause is the handling of the ks kernel command line argument in 26parse-anaconda-kickstart.sh in the dracut hooks. See the code below: #!/bin/bash # parse-anaconda-kickstart.sh: handle kickstart settings # no need to do this twice [ -f /tmp/ks.cfg.done ] && return # inst.ks: provide a "URI" for the kickstart file kickstart="$(getarg ks= inst.ks=)" if [ -z "$kickstart" ]; then getargbool 0 ks inst.ks && kickstart='nfs:auto' fi # no root? the kickstart will probably tell us what our root device is. [ "$kickstart" ] && [ -z "$root" ] && root="anaconda-kickstart" case "${kickstart%%:*}" in http|https|ftp|nfs|nfs4) # network kickstart? set "neednet"! set_neednet ;; file|path) # "file:<path>" - "path:<path>" is accepted but deprecated splitsep ":" "$kickstart" kstype kspath if [ -f "$kspath" ]; then info "anaconda: parsing kickstart $kspath" cp $kspath /tmp/ks.cfg parse_kickstart /tmp/ks.cfg [ "$root" = "anaconda-kickstart" ] && root="" > /tmp/ks.cfg.done else warn "inst.ks='$kickstart'" warn "can't find $kspath!" fi ;; esac export kickstart ... Note that the case statement has no option to handle cdrom (ks=cdrom:/ks.cfg). Hence code goes right past that statement never parsing a kickstart file. Then everything dies after the timeout expires. VMware places the kickstart file on the root of the special CD they create during an Easy Install process. Without support for this parameter Easy Installation of Fedora 17 will not work. I believe this is a regression as this syntax works properly in Fedora 16 and earlier. Version-Release number of selected component (if applicable): Release version of Dracut on Fedora 17 How reproducible: 100% Steps to Reproduce: 1. Create new Fedora 17 VM using Easy install in VMware Workstation 2. Boot. Dracut will drop into shell. 3. Look at /proc/cmdline... notice that ks=cdrom:/ks.cfg Actual results: Drop into emergency shell Expected results: Anaconda starts and creates a VM. Additional info: See above.
Experiencing this same issue with "ks=cdrom:". Would like to know of workarounds and would be willing to help test the fix. KS works fine if uploaded to a FTP site and the parameter changed to match.
One workaround is to use: ks=cdrom:/dev/cdrom:/ks.cfg Found this documented somewhere but not sure where it was (can't find it now). This definitely seems like a regression and not documented as such in any of the fedora documentation at: http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/s1-kickstart2-startinginstall.html http://docs.fedoraproject.org/en-US/Fedora/14/html/Installation_Guide/s1-kickstart2-startinginstall.html http://docs.fedoraproject.org/en-US/Fedora/15/html/Installation_Guide/s1-kickstart2-startinginstall.html http://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/s1-kickstart2-startinginstall.html http://docs.fedoraproject.org/en-US/Fedora/17/html/Installation_Guide/s1-kickstart2-startinginstall.html
*** Bug 828971 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > One workaround is to use: > > ks=cdrom:/dev/cdrom:/ks.cfg Will that work. See the option parsing code above in the initial comment... That won't hit the case statement will it? Anything that begins with "cdrom" is a dud. If it began with "file" or "path" then it would stand a chance maybe.
may not be right but it does work.
/me tips his hat. Thanks Steven: that seems to solve my problem.
Agreed. Workaround works for me as well. Thanks!
(In reply to comment #0) > Dracut is dropping into its emergency shell with message "Unable to process > initqueue". Cause is the handling of the ks kernel command line argument in > 26parse-anaconda-kickstart.sh in the dracut hooks. See the code below: [snip] > Note that the case statement has no option to handle cdrom > (ks=cdrom:/ks.cfg). Hence code goes right past that statement never parsing > a kickstart file. Sorry, you're not quite right. Scripts in the 'cmdline' hook (i.e. all the parse-anaconda-*.sh scripts) run *before* udev starts; there are no block or network devices available at this point. This is why there also isn't a case statement for ks={hd,http,ftp,etc.} The code you're looking for is in kickstart-genrules.sh: case "${kickstart%%:*}" in http|https|ftp|nfs) # handled by fetch-kickstart-net in the online hook wait_for_kickstart ;; cdrom|hd|bd) # cdrom:<dev>, hd:<dev>:<path>, bd:<dev>:<path> splitsep ":" "$kickstart" kstype ksdev kspath ksdev=$(disk_to_dev_path $ksdev) if [ "$kstype" = "bd" ]; then # TODO FIXME: no biospart support yet warn "inst.ks='$kickstart'" warn "can't get kickstart: biospart isn't supported yet" ksdev="" else when_diskdev_appears $ksdev \ fetch-kickstart-disk \$env{DEVNAME} $kspath wait_for_kickstart fi ;; esac As you've found, though, the "ks=cdrom" case is not handled correctly - $ksdev ends up empty and when_diskdev_appears won't do the right thing. If $ksdev is set, it'll work OK - which is why the workaround from comment #2 works[1]. "ks=cdrom:/dev/cdrom" should also work - the path defaults to "/ks.cfg" if unset. You'll need to keep using this workaround for F17, since we can't update the contents of the initramfs using 'updates=...', but it'll get fixed in the git repo for later releases. [1] as long as you only have one CDROM device, anyway.
(In reply to comment #8) Thanks for the explanation Will. I created and applied a patch on our end to special case Fedora 17.
Patch applied to master git branch (commit 665f01f).
*** Bug 834536 has been marked as a duplicate of this bug. ***
During an F18 beta install on a Vmware Fusion hypervisor I got the same error messages. Is it possible that this old problem still exists in F18? marco
(In reply to comment #12) > During an F18 beta install on a Vmware Fusion hypervisor I got the same > error messages. Is it possible that this old problem still exists in F18? > > marco Unfortunately, yes, this problem still exists in F18. I'm hesitant to patch it on VMware's side until we see F18 GA. However, if they do GA on the 1/15 as planned, I think it is likely it will be fixed with the next release of VMware Tools. In the interim, the workaround is the same as discussed above.
Setting back to ASSIGNED in light of the above; the fix did make the F18 branch and F18 builds long after June were still displaying the problem. However, it would be useful if someone could verify this is still the case with F19 Alpha (or F19 Beta TC3). Thanks!
*** Bug 963003 has been marked as a duplicate of this bug. ***
I have been attempting to do kickstart based installs on boxes with both physical CD and Virtual CD and facing failures with Fedora 19 (Alpha/Beta/RC). I reported 963003 regarding this and with help from Samantha in debugging it, I reached here. The issue is with the fix done for 828589, passing ks:cdrom:/ks.cfg has stopped working. The workaround suggested was ks:cdrom::/ks.cfg. This only works if the install is started on first CD device of a box having multiple CD devices. In my case where I am attempting an install through virtual CD by mounting ISO, the virtual CD is not first CD device and installer drops me to a prompt saying it could not find ks.cfg, as it looked for it on first CD device. (see screenshot). This issue is also mentioned in comment 8 above "[1] as long as you only have one CDROM device, anyway." Having the functionality of "ks:cdrom:/ks.cfg" was very useful as the installer would scan all possible CD devices to find ks.cfg. Without such functionality, user will be forced to spin multiple images each one specific to where the ks.cfg might reside for particular configuration. "ks:cdrom::/ks.cfg" is a good workaround, it would be perfect if mimicked what "ks:cdrom:/ks.cfg" did. I understand FC19 window is closed or about to close. It would be helpful if this functionality is put back in future.
Created attachment 765344 [details] FC19 install failure with ks:cdrom::/ks.cfg on box with multiple cdrom devices
As this is more or less a feature request at this point, let's mark it as such.
Created attachment 765740 [details] 0001-Make-ks-cdrom-scan-all-optical-media-828589.patch This patch (which I haven't tested) would probably do what you'd expect. (Note that "inst.ks=cdrom", "inst.ks=cdrom::", and "inst.ks=cdrom::/ks.cfg" are all equivalent.) You could test this by either booting with 'rd.break=cmdline' and editing the file by hand, or by rebuilding the CD with a patched initrd.img. Since I don't know exactly which initrd.img you're using, I can't provide a patched image, but you can modify it yourself like so: mkdir -p initrd && cd initrd xz -dc $MOUNTED_CDROM/images/pxeboot/initrd.img | sudo cpio -iumd vi lib/dracut/hooks/pre-trigger/50-kickstart-genrules.sh ## copy-and-paste the code from the patch into place sudo bash -c 'find . | cpio -co | xz -9' > ../initrd-828589.img cd .. ..and then you replace images/pxeboot/initrd.img with initrd-828589.img when you rebuild your .iso to include the ks.cfg.
Thanks for the patch. I applied it in the initrd and tried a rebuilt ISO. Although I still get dropped to dracut prompt, it *does not* show the message where it was looking at wrong device for ks.cfg. I am attaching the screen shot and sosreport.
Created attachment 765858 [details] Screenshot when booted with patched initrd
Created attachment 765859 [details] sosreport on patched initrd
+ cat /proc/cmdline initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019\x20x86_64 ks=cdrom:/ks.cfg ^^^^^^^^^^^^^^^^ I'm pretty sure your ks=... argument is incorrect. The syntax is: inst.ks=cdrom[:<device>[:<path>]] If <device> is absent or empty, anaconda will probe all optical media it finds. If <path> is absent or empty, '/ks.cfg' is assumed. So what you probably meant is "inst.ks=cdrom::/ks.cfg" - or just "inst.ks=cdrom". (Note that we still accept arguments without 'inst.' for now, but that may change eventually...) Docs: https://fedoraproject.org/wiki/Anaconda_Boot_Options#ks https://git.fedorahosted.org/cgit/anaconda.git/tree/docs/boot-options.txt#n43
You are correct, changing to inst.ks=cdrom along with the earlier patch has made it work on 3 out of 4 boxes. Two of these have multiple cdroms(Physical + Virtual CD) and one has just one cdrom(Virtual CD only) The last box where it is failing, it just freezes saying "Started System Logging Service", not sure what to make of it. This box just has the Virtual CD. Same failing box works if I use the unpatched initrd. Any pointers on how to get some debug output of this box would be helpful. Thanks for your help so far.
Is this still an active issue, or issue that might need some code change?
I think this got fixed. At least, https://bugzilla.redhat.com/show_bug.cgi?id=1042500 showed up a while later for RHEL, and the fix went to anaconda master so it'll be in all supported Fedoras at this point. There was also https://bugzilla.redhat.com/show_bug.cgi?id=1049237 and https://bugzilla.redhat.com/show_bug.cgi?id=1168902 in the same area. Between those bugs I'm gonna say this one was fixed; of course this functionality might have broken again later, but if so, it should probably be filed anew.