s390x bootloader setup

[ausil]

There are apparently issues with ostree not setting up the bootloader correctly on s390x, I currently do not have the specific issues details but wanted to get a placeholder so that as we investigate we can update here and get things working.

[tuan-hoang1]

I think it's pretty straightforward to make libostree/ostree-bootloader-zipl.c but I'm struggling on how to test the code. Got a tip from @cgwalters about tests/test-admin-deploy-syslinux.sh and looking into it.

[tuan-hoang1]

zipl understands BLS so there are two ways:

• make /boot/loader/zipl.conf by copying content from BLS file (feels like syslinux + uboot do)

  [defaultboot]
  defaultauto
  prompt=1
  timeout=5
  default=linux
  target=/boot
  [linux]
  image=<copy from BLS>
  ramdisk=<copy from BLS>
  parameters="<copy from BLS>"

• keep a "dummy" zipl.conf and invoke $ zipl with -b parameter pointing to BLS file

  [defaultboot]
  defaultauto
  prompt=1
  timeout=5
  target=/boot

[sharkcz]

https://github.com/ibm-s390-tools/s390-tools/issues/64 is a related issue for the bootloader itself

[cgwalters]

keep a "dummy" zipl.conf and invoke $ zipl with -b parameter pointing to BLS file

I'd prefer this - and even better, avoid having to invoke zipl at all from ostree; have it read the BLS snippets directly, like grub does. We are just reaching this point on x86_64: https://github.com/coreos/coreos-assembler/pull/616

[sharkcz]

zipl is like LILO (if you remember the early Linux days :-)), so without chainloading another bootloader you need to update the boot records with the zipl userspace tool.

CC @martinezjavier

[martinezjavier]

zipl is like LILO (if you remember the early Linux days :-)), so without chainloading another bootloader you need to update the boot records with the zipl userspace tool.

That's correct.

[tuan-hoang1]

This seems to be a little bit weird. With or without my zipl changes in ostree (even it does not work yet, /boot/loader/zipl.conf, for example, has not been generated), ostree still manages to get correct /boot/loader/entries/ostree-1-fedora-coreos.conf (with small quirks). So in anaconda I can run zipl with a dummy /etc/zipl.conf pluses above load entries file and FCOS seems to boot.

So the final question is : do we even need zipl code in ostree :D

[tuan-hoang1]

One thing I would like to ask is how grub is triggered to run each time we switch to new ostree deploy, i.e. changes happen in load entries file ? And does trigger executes grub2-mkconfig ? I guess Fedora must have a mechanism to trigger initramfs tools (dracut) to run, then trigger to update bootloader. Because this is exactly something we might need to do for zipl. Not sure doing this in ostree side or in Fedora side.

[cgwalters]

So the final question is : do we even need zipl code in ostree :D

...

One thing I would like to ask is how grub is triggered to run each time we switch to new ostree deploy,

It sounds like we would need a bootloader backend in ostree that simply runs zipl ? Most of the other bootloader backends in ostree read the BLS fragments and generate a bootloader-specific config file, but it sounds like zipl itself reads those now (which is great!) and literally all we need to do is rerun the command to have it update the (boot records? what's the right term)?

[tuan-hoang1]

It sounds like we would need a bootloader backend in ostree that simply runs zipl ?

If for triggering each time the tree is updated with new deploy, then yes. Anaconda only does it once at installation time.

Most of the other bootloader backends in ostree read the BLS fragments and generate a bootloader-specific config file, but it sounds like zipl itself reads those now (which is great!)

Yes, it's great that @martinezjavier added BLS support last year. I believe for this part we don't have to implement for zipl.

and literally all we need to do is rerun the command to have it update the (boot records? what's the right term)?

Yes, rerun the command to update boot records. And a trigger/hook for zipl to run on its own whenever, for example, /boot/loader/entries/*.conf is touch/changed.

[tuan-hoang1]

To summarize current status, and what is still needed to be done:

• We decided we want to have a dummy zipl.conf - instead of re-parsing BLS files to create a big bootloader config file (like syslinux + uboot do). Solved in s390-tools#71.
• We need a zipl backend in ostree to trigger zipl to run each time there is a CoreOS system update. Solved in ostree#1937.
• zipl expects 'title' field to be first line in BLS files, and no blank line too. See s390-tools#64. Solved in ostree#1904.
• zipl does not allow duplicated titles for BLS files. Solved in ostree#1911.

Issues were not mentioned here:

• zipl was not able to handle a lot of BLS files. Solved in s390-tools#73.
• s390-tools#74. Solved.
• zipl is triggered to run at first boot to remove firstboot parameters. Will be solved ignition-dracut#117

Existing issues:

• Anything ?