Support zipl bootable device(image) for s390x

[huoqifeng]

I noticed PR https://github.com/systemd/mkosi/pull/2183 to add support for fedora s390x support, this is great! Looks it's suitable qemu only.

On IBM LinuxONE, zipl is used to generate a bootable image, which is described in https://www.ibm.com/docs/en/linux-on-z?topic=usage-boot-device#zipl_image, the zipl tool itself is hosted in https://github.com/ibm-s390-linux/s390-tools/tree/master/zipl.

I'm not sure whether it's right place, I'd like open an issue to talk about our requirement for mkosi to support s390x bootable device.

I created a folder and a mkosi config file mkosi.conf like below

# cat mkosi.conf 
[Content]
Environment=SOURCE_DATE_EPOCH=0
RemoveFiles=/var/log
RemoveFiles=/var/cache

[Output]
OutputDirectory=build

[Distribution]
Distribution=fedora

[Host]
ToolsTree=default

And built the image via command mkosi build and mount the image to a nbd device, check the device and files: device

# qemu-nbd --connect=/dev/nbd0 image.qcow2
# fdisk /dev/nbd0 -l
Disk /dev/nbd0: 257.02 MiB, 269504512 bytes, 526376 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5DD8B74E-CDB8-47C8-A1FF-BCC20EB6BAD8

Device      Start    End Sectors  Size Type
/dev/nbd0p1  2048 526335  524288  256M unknown

files:

# mount /dev/nbd0p1 /mnt/myvm/
# ls /mnt/myvm/
afs  bin  boot  dev  efi  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
# ls /mnt/myvm/boot/
# ls /mnt/myvm/efi/

nothing in /boot and /efi.

Could we add some configure to leverage zipl to generate a bootable device/image for s390x?

[huoqifeng]

I'm not mkosi expert, sorry if I just missed the command parameters or configurations. appreciate if anyone can help on this!

[DaanDeMeyer]

@huoqifeng We want to be able to run in containeres and without needing root privileges in mkosi, so we can't use loop devices or such. From what I can see, zipl always wants to operate on a block device. Unless zipl learns to operate on raw disk image files as well, I don't see us being able to support it in mkosi. Maybe you can work with the zipl maintainers to add support for installing into a raw disk image file? Then we could probably add support for zipl in mkosi.

[huoqifeng]

@DaanDeMeyer thank you very much for the quick response! I'm wondering whether it's doable to achieve it via some post scripts to trigger zipl program after mkosi generates the initrd and image.

[DaanDeMeyer]

@huoqifeng You can run mkosi first to build an image and afterwards run zipl to make it bootable I guess. I have no experience with zipl at all so I can't tell you whether it will work or not.

[DaanDeMeyer]

Note that we only build GPT disk images which I don't know is supported on s390x. It works with qemu direct kernel boot because the bootloader is not involved at all there.

[niklas88]

GPT works on s390x for SCSI, NVMe and virtio-blk disks but not for the classic DASDs which have their own partitioning scheme but those shouldn't be relevant for mkosi. I guess one way to work around having a block device for zipl would be to install zipl, the kernel package and whatever creates the /boot/entries/.. in the image and then make it actually bootable by using QEMU kernel boot once and executing zipl which then installs itself to the MBR and will pick up the /boot/entries/...

[DaanDeMeyer]

@niklas88 Yeah that should work I think. Still, it'd be nice if zipl could install itself on a disk image file instead of a block device. Then we could add official support in mkosi. Anything that involves booting or mounting the image is not something we're willing to support unfortunately.

[niklas88]

@DaanDeMeyer how do you currently access the disk image (e.g. for creating the GPT and filesystems) without root and a loopback device i.e. without mounting it?

[DaanDeMeyer]

We delegate all of this to systemd-repart. I talked about how systemd-repart creates disk images without root or loopback devices: https://media.ccc.de/v/all-systems-go-2023-191-systemd-repart-building-discoverable-disk-images.

In short, most filesystem mkfs tools support some form of --rootdir argument to populate the filesystem with contents without mounting it. We make use of that to avoid ever having to mount the filesystem, which means that by using user namespace, we can build images without ever needing to be root.