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: anacondaAssignee: Will Woods <wwoods>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: rawhideCC: aj.werkman, andrew.stiegmann, awilliam, davinib, dracut-maint, g.kaviyarasu, harald, jonathan, jpazdziora, 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: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
FC19 install failure with ks:cdrom::/ks.cfg on box with multiple cdrom devices
none
0001-Make-ks-cdrom-scan-all-optical-media-828589.patch
none
Screenshot when booted with patched initrd
none
sosreport on patched initrd none

Description Andrew S. 2012-06-04 19:39:34 EDT
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.
Comment 1 Phillip T. George 2012-06-05 09:17:25 EDT
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.
Comment 3 Steven Dake 2012-06-07 16:38:25 EDT
*** Bug 828971 has been marked as a duplicate of this bug. ***
Comment 4 Andrew S. 2012-06-07 17:47:23 EDT
(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.
Comment 5 Steven Dake 2012-06-07 18:20:11 EDT
may not be right but it does work.
Comment 6 Andrew S. 2012-06-07 18:42:21 EDT
/me tips his hat.  Thanks Steven: that seems to solve my problem.
Comment 7 Phillip T. George 2012-06-08 09:48:25 EDT
Agreed.  Workaround works for me as well.  Thanks!
Comment 8 Will Woods 2012-06-09 14:46:50 EDT
(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.
Comment 9 Andrew Stiegmann 2012-06-09 18:01:05 EDT
(In reply to comment #8)
Thanks for the explanation Will.  I created and applied a patch on our end to special case Fedora 17.
Comment 10 Will Woods 2012-06-13 16:25:06 EDT
Patch applied to master git branch (commit 665f01f).
Comment 11 Chris Lumens 2012-06-28 22:48:58 EDT
*** Bug 834536 has been marked as a duplicate of this bug. ***
Comment 12 Marco Bill-Peter 2012-12-03 14:53:55 EST
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
Comment 13 Ben Davini 2013-01-08 16:49:19 EST
(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.
Comment 14 Adam Williamson 2013-05-10 00:13:48 EDT
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!
Comment 15 Samantha N. Bueno 2013-06-25 11:39:51 EDT
*** Bug 963003 has been marked as a duplicate of this bug. ***
Comment 16 Jeevan Savant 2013-06-25 20:47:08 EDT
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.
Comment 17 Jeevan Savant 2013-06-25 20:52:02 EDT
Created attachment 765344 [details]
FC19 install failure with ks:cdrom::/ks.cfg on box with multiple cdrom devices
Comment 18 Adam Williamson 2013-06-25 20:59:57 EDT
As this is more or less a feature request at this point, let's mark it as such.
Comment 19 Will Woods 2013-06-26 14:50:19 EDT
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.
Comment 20 Jeevan Savant 2013-06-26 20:23:24 EDT
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.
Comment 21 Jeevan Savant 2013-06-26 20:24:02 EDT
Created attachment 765858 [details]
Screenshot when booted with patched initrd
Comment 22 Jeevan Savant 2013-06-26 20:24:50 EDT
Created attachment 765859 [details]
sosreport on patched initrd
Comment 23 Will Woods 2013-06-27 12:57:28 EDT
+ 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
Comment 24 Jeevan Savant 2013-06-27 21:10:30 EDT
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.