Bug 828589
Summary: | 26parse-anaconda-kickstart.sh is unable to handle kickstart argument "ks=cdrom:/ks.cfg", in Ye Olde Times it would scan all optical devices | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andrew S. <astiegmann> |
Component: | anaconda | Assignee: | Will Woods <wwoods> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | aj.werkman, andrew.stiegmann, awilliam, davinib, dracut-maint, g.kaviyarasu, harald, jonathan, marcobillpeter, mlptgml, savjee, vanmeeuwen+fedora |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-12-11 23:19:01 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
Andrew S.
2012-06-04 23:39:34 UTC
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. |