Add s390x iso boot support

[wfeldt]

Task

This pr adds boot support for s390x Live ISOs.

1. new s390x_iso bootloader type
2. mainly implemented in new bootloader/config/s390x_iso.py class
3. it creates s390x related config files and an s390x image file in boot/s390x/loader/

Issues

1. all methods in bootloader/config/ are called before the initrd is created; this makes it tricky to create config files that rely on an existing initrd
2. this issue is similar to creating a uefi boot image, which was handled by calling a _create_embedded_fat_efi_image method in create_live_iso_boot_images
3. here I added an setup_s390x_boot_images method used in the same way
4. it would probably be better to generally add a method to the bootloader config class that is called after the initrd exists and handle the s390x and uefi cases there

Todo

No real unit tests yet.

AI disclaimer

This code was created with the assistence of Gemini.

[schaefi]

Hi, thanks much for working on this topic 👍 Here are my thoughts

New attribute s390_iso

I do not understand why this is needed. If you build a live image (builder/live) or an install image (builder/install) and the architecture is s390, this should be enough information to target BootLoaderS390xIso

all methods in bootloader/config/ are called before the initrd is created; this makes it tricky to create config files that rely on an existing initrd

This is correct. We usually solve this by creating the config parts that do not require direct access to the initrd first and for those parts that require it an extra method is added to the bootloader class and called in the builder at a time where all data required exists. An example can be looked up for "_create_embedded_fat_efi_image" method where we have the same problem. And you solved this by a setup_s390x_boot_images method. If you like to stick with this concept please make it a private method e.g. _setup_s390x_boot_images because it does not exist in the BootLoaderConfig interface and only in the scope of your new class. Thanks

it would probably be better to generally add a method to the bootloader config class that is called after the initrd exists and handle the s390x and uefi cases there

yes and I have no objections if you add such a method to the bootloader/config/base.py base class and call it in the builders. If not implemented it should be a noop. I agree it would also be the better concept for the existing not so nice implementation of e.g. _create_embedded_fat_efi_image. Maybe all this as a refactoring PR after this one completed ?

SUSE specific coding

suse_ins_content, media_suse_ins_content, etc ... These are all suse specific settings and I think only because of the texts and not because of the offsets or files. So to for upstream to accept this, it needs to be changed into a generic solution.

SUSE Linux for IBM z Systems Installation System

This is typically set by the image.displayname attribute

SAY 'LOADING SLES FILES INTO READER...

This can be also a generic information without distro tag, but could also take the image.name attribute

[wfeldt]

s390x_iso

That's indeed a dark area but I see no way around it.

There is for example this code (and also in install.py) (which is wrong, imho):

• https://github.com/OSInside/kiwi/blob/main/kiwi/builder/live.py#L76-L77

It knows only about grub2 and systemd-boot. This prevents you to have any other bootloader, even 'custom' does not work.

s390x iso setup is not grub2 and it makes no sense to inject the code somewhere in the grub2 path as there is also validly a s390x grub2 setup. So imho it's better to have a separate class for it.

[wfeldt]

SUSE branding

Indeed, this needs to be generalized. It's not only strings in files but also file names like suse.ins. These should probably not be created at all but be entirely user-provided.

[schaefi]

That's indeed a dark area but I see no way around it.

I did not question the class, that's all fine. I'm questioning the selection method. You implemented a class
and the factory name for BootLoaderS390xIso is s390x_iso. That's all great and I have no issue with it.
But you also added a new attribute value for bootloader named s390x_iso. This means I have to specify
<bootloader ... name="s390x_iso" ../> in the image description to use it. I question this part because if you are building on s390 a live iso or an install iso there is no other way as to use your new BootLoaderS390xIso, as such I could say something like this in the LiveImageBuilder

if 's390' in self.arch:
    self.bootloader = 's390x_iso'

and something similar in builder/install. So from my perspective no changes to the kiwi schema are required

The bootloader section is an optional one and I think you don't need it for s390 live iso's or are there other attributes that we need to set here ?

If we need more from <bootloader> I agree with you but I thought this is all done via parmfile

Thoughts ?

[schaefi]

@wfeldt regarding the bootloader attribute I'm fine if you think we need one. In case we need one can you change the name such that it follows the naming layout better ? (not starting with the arch name) e.g. "iso_s390x" as we also have "grub2_s390x_emu"

Thanks

[wfeldt]

So, essentially you want the bootloader decision to happen here:

• https://github.com/OSInside/kiwi/blob/main/kiwi/builder/live.py#L76-L77

This is exactly the point I don't understand.

As the code currently is, it prevents you from having bootloader = custom, for example. Even though you can set this in the kiwi file. Is that intentional?

Also, should there be a way to have no bootloader configured? Seems you cannot do this atm.

My expectation was that these two lines should not be there at all and you always get the bootloader as specified in the kiwi file. But maybe that is not what kiwi users expect...

[schaefi]

@wfeldt

Also, should there be a way to have no bootloader configured? Seems you cannot do this atm.

you can, just do not provide a <bootloader> section at all

So, essentially you want the bootloader decision to happen here:

point is not what I want. My point is: Is a by user selection of a bootloader required in this condition (building an ISO image for s390) yes or no ? meaning is there any choice to made ? and do you expect other attributes of the <bootloader> section to play any role when building an ISO for s390. If we don't need anything from <bootloader> then the simple type definition <type image="iso" ... /> is enough and the decision is clear when this builds on s390x.

Thoughts ?

[wfeldt]

Maybe I'm missing the point, but do you mean <bootloader/> vs. no <bootloader> section?

[schaefi]

Maybe I'm missing the point, but do you mean <bootloader/> vs. no <bootloader> section?

Let's make an example.

To define a live ISO setup a type definition can look like this (x86_64 example)

<type image="iso">
    <bootloader name="grub2" console="serial" timeout="10"/>
</type>

To do the same for s390x, my question is, do we need any information from a <bootloader> ? I mean this works for s390x in a way that we take information from a parmfile and provide data on the ISO itself which is read by an HMC load and IPL (I'm not an expert though, but there is no real loader in place imho). Given we don't need any bootloader information kiwi has everything it needs to know to build a live ISO. As such the following type information would be enough

<type image="iso"/>

If you say this is not true and we need further information as part of a bootloader section you are right and we also need a name for that and the respective schema adaptions.

Does it make more sense now ?

[wfeldt]

If <type image="iso"/> defaults to bootloader iso_s390x then how do you say to configure NO bootloader at all?

[schaefi]

If <type image="iso"/> defaults to bootloader iso_s390x then how do you say to configure NO bootloader at all?

That would be

<type ...>
    <bootloader name="custom"/>
</type>

[schaefi]

and to be more precise if you don't specify any <bootloader> a default is applied depending on architecture and image type. For live ISO's or install ISO's on x86_64 it would be grub2. If you don't want any bootloader specific action to happen then you set "custom" as loader.

[schaefi]

If the only selection for iso_s390x is this name as in

<type image="iso">
    <bootloader name="iso_s390x"/>
</type>

then this is imho a pointless information. However, if we need more from this bootloader, timeout, console, etc etc then it is of course needed

[schaefi]

and if it is needed there might be a followup issue because in a disk type build for s390x it looks like this

<type image="oem" filesystem="xfs" bootpartition="false" kernelcmdline="console=ttyS0" format="qcow2">
    <bootloader name="grub2_s390x_emu" console="serial" timeout="10"/>
</type>

as you can see the loader is our suse zipl2grub thing and assuming you want an install ISO from this disk as well you would add

installiso="true"

which then kicks the ISO building procedure of builder/install.py and if that code evaluates the setting for the bootloader name it will see "grub2_s390x_emu" and you would need to overwrite this by "s390x_iso". However, if s390 ISO building always defaults to one procedure because there is no other way to do this, then you don't need this extra handling