installer: use lorax s390x templates, allow adding parameters at boot

[tuan-hoang1]

installer: use lorax s390x templates, allow adding parameters at boot

Significant changes include:

• Use a naming convention for kernel and initramfs file, which would
  help for s390x case. The reasoning is that z/VM's CMS files do not allow
  names and extentions more than 8 characters. While we are renaming, lets
  stick with traditional RHEL/Fedora naming so redhat.exec and generic.ins
  don't require changes from lorax templates.

• Allow us to add parameters (ignition, raw image, etc.) at boot time
  for s390x using 'rd.cmdline=ask' dracut parameters. It is
  better to reuse lorax templates rather than adding it on our own.

• generic.ins and redhat.exec from lorax allow us to loop mount the ISO
  image and expose its mount point via FTP, then LPAR and z/VM can fetch
  kernel and initramfs from there to boot, basically the same netboot
  method on RHEL/Fedora, and the same PXE experience on x86.

• We also need to add 'rd.neednet=1 coreos.inst=yes' from zipl.prm so that
  coreos-installer-generator will replace default.target with
  coreos-installer.target, before user adds any parameter at
  dracut-cmdline-ask.

Signed-off-by: Tuan Hoang [email protected]

[tuan-hoang1]

cc Dan @sharkcz for opinions.

[tuan-hoang1]

Please don't merge this right now, I'm checking some issue with it.

[tuan-hoang1]

@martinezjavier : I forgot to hardcode coreos.inst=yes to the default boot parameters, which default isolinux-based ISO uses, which lead to problem we talked about yesterday. So another day another PEBKAC :)

This one is now ready I believe. Will open another PR to coreos-installer soon.

[cgwalters]

Looks like this is failing CI:

+ /usr/bin/isohybrid /srv/tmp/buildpost-installer/fedora-coreos-30.20190905.dev.0-installer.iso

Traceback (most recent call last):

  File "/usr/lib/coreos-assembler/cmd-buildextend-installer", line 276, in <module>

    generate_iso()

  File "/usr/lib/coreos-assembler/cmd-buildextend-installer", line 246, in generate_iso

    shutil.copyfile(os.path.join(tmpisoimages, kernel_name), kernel_file)

UnboundLocalError: local variable 'kernel_name' referenced before assignment

(Also this will conflict with the PXE live PR I think)

[tuan-hoang1]

Yes this one and the zFCP one are conflicted with Benjamin's new PR of live ISO/PXE.

[tuan-hoang1]

Still testing, and not sure if/how to do the live image on s390x.

[bgilbert]

generic.ins and redhat.exec from lorax allow us to loop mount the ISO image and expose its mount point via FTP, then LPAR and z/VM can fetch kernel and initramfs from there to boot

We ship separate netboot artifacts, so it isn't necessary to dig around within the contents of the ISO. Is there any reason to prefer that approach over just using the separate kernel and initramfs images?

Note that in the live image, the ISO initramfs has an extra 256 KB of padding compared to the PXE one. Also note that the plan is to eventually deprecate the installer images in favor of the live images.

[tuan-hoang1]

generic.ins and redhat.exec from lorax allow us to loop mount the ISO image and expose its mount point via FTP, then LPAR and z/VM can fetch kernel and initramfs from there to boot

We ship separate netboot artifacts, so it isn't necessary to dig around within the contents of the ISO. Is there any reason to prefer that approach over just using the separate kernel and initramfs images?

Yes, the reason is we might want to use redhat.exec and generic.ins files, and also *.prm files for parameters (same like when they have to put in their PXE script on x86). If we don't want to dig around the ISO content, we have to ship those files along with kernel + initramfs + iso artifacts, for which I don't think is a good idea.
Also, be aware that, the s390x ISO cannot be directly booted on z/VM + LPAR : they are just there for serving via FTP/HTTP. This remote HTTP endpoint is actually how the Fedora/RHEL ISO tree look like : https://mirrors.dotsrc.org/fedora-buffet/fedora-secondary/releases/30/Server/s390x/os/. For FCOS, we only need/have images/ and generic.ins.

Note that in the live image, the ISO initramfs has an extra 256 KB of padding compared to the PXE one. Also note that the plan is to eventually deprecate the installer images in favor of the live images.

This PR cannot deal with live image scenario. I need to look into more detail to support live image.

[tuan-hoang1]

@cgwalters , @bgilbert : As being said above, this PR will not do live image just yet. I think it's ready now, please review again.
I tested the finditer check real quick with normal python3 code inside the COSA container and it worked, did not test with real setup on x86.

[tuan-hoang1]

cc @sharkcz again for backing up the 8 char thing requirement. Also, I'm not every sure if file without "extension" like vmlinuz would be eligible or not for CMS, Dan ?

[sharkcz]

It's filename + filetype in CMS, so I assume both parts are mandatory, some z/VM docs

[cgwalters]

Looks reasonable to me; needs some small fixes for make check looks like though.

[tuan-hoang1]

@cgwalters

Looks reasonable to me; needs some small fixes for make check looks like though.

Thanks, was not aware of this before, will watch out for future commits. Commit updated.

[tuan-hoang1]

Friendly ping on this one.

[jlebon]

This looks sane to me though I'm not familiar with the details of s390x. Just some minor comments from scanning it.

[jlebon]

LGTM!