invalid /etc/zipl.conf in Fedora images

[sharkcz]

Problem description

An invalid /etc/zipl.conf is created for Fedora cloud images. When processing zipl complains about keyword 'targetbase' required.

[fedora@localhost ssh]$ cat /etc/zipl.conf
[defaultboot]
defaultauto
prompt=1
target=/boot

targettype=SCSI
targetblocksize=512
targetoffset=2048

timeout=1
secure=auto
default=(6.10.0-64.fc41.s390x) 

[fedora@localhost ssh]$ sudo zipl -V
Looking for components in '/lib/s390-tools'
Using config file '/etc/zipl.conf'
Using BLS config file '/boot/loader/entries/12bf46c0e4b74221a8084cacc28780cc-6.10.0-64.fc41.s390x.conf'
Error: Config file '/etc/zipl.conf': Line 6: keyword 'targetbase' required when specifying 'targettype'

Expected behaviour

bootloader reinstalled

Steps to reproduce the behaviour

Just rerun zipl after booting the image.

OS and Software information

• KIWI version: 10.0.24
• Operating system host version: Fedora Rawhide
• Operating system target version: Fedora rawhide
• Open Build Service version (N/A if not using OBS): N/A
• Koji version (N/A if not using Koji): 1.34.1 (Fedora production instance)

for full details please see https://koji.fedoraproject.org/koji/taskinfo?taskID=120569240

[Conan-Kudo]

Do you have an example of a valid zipl configuration that you could share?

[sharkcz]

In our (aka Fedora or RHEL) case we don't include the targettype, targetblocksize and targetoffset lines. zipl.conf(5) talks about these options in the context of logical devices (mean eg. linear device mapper target and as a workaround for not auto-detecting those values), but here we use a single SCSI device for the cloud image, so there is no need for them. I suppose there is a use case that needs those though ...

our normal /etc/zipl.conf is

[defaultboot]
prompt=1
timeout=5
secure=auto
target=/boot
default=(6.10.0-64.fc41.s390x) 

[sharkcz]

And technically /etc/zipl.conf doesn't have to exist at all, because for most cases the default one in /usr/lib/s390-tools/zipl.conf is sufficient.

# This is an example of a minimal zipl.conf file that can be used when the
# sections are defined in BootLoaderSpec fragments files.
#
# See the zipl and zipl.conf man page for more details.
[defaultboot]
defaultauto
prompt=1
timeout=5
secure=auto
target=/boot

[Conan-Kudo]

targetbase in the man page isn't super-helpful...

targetbase = base-device (configuration and menu)

Configuration and menu section:
Specify the device which will be prepared for booting.
This parameter is required when working with logical devices (see zipl(8)).

[sharkcz]

yeah, I was hoping that someone who added those target* vars to the kiwi produced zipl.conf would know what is going on

[sharkcz]

I am also not sure we still need the target* variables at all since there is a device-mapper helper in zipl, that should figure out the needed values.

[schaefi]

Hi, so as explained in the above comments you are all right. All the target* settings are required if you install zipl into a 512/4k mapped loop device. That's why we really need them otherwise the zipl call at build time of the image will fail.

As these target information points to a loop device that does no longer exist after the image got produced we delete this
information from the created /etc/zipl.conf. It was a bit short thinking from my side that the result config that stays in the
system is not sufficient for any subsequent zipl calls, which I guess are issued on e.g a kernel update, correct ?

So from the current state I believe we should not call zipl as

[ 1438s] [ DEBUG   ]: 14:52:28 | EXEC: [chroot /var/tmp/kiwi_mount_manager._p1ep6ut zipl --noninteractive --config /etc/zipl.conf --blsdir /boot/loader/entries --verbose]

but call zipl like this

chroot ... zipl --noninteractive --config /some/temp/config --blsdir /boot/loader/entries --verbose

That way we would not touch /etc/zipl.conf and the distributors could still individually decide how to maintain this file

Thoughts ?

[Conan-Kudo]

That seems reasonable, especially with the way zipl works now in Fedora.

[sharkcz]

yes, the issue occurred when updating the kernel