Closed sharkcz closed 2 weeks ago
Do you have an example of a valid zipl configuration that you could share?
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)
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
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)).
yeah, I was hoping that someone who added those target*
vars to the kiwi produced zipl.conf
would know what is going on
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.
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 ?
That seems reasonable, especially with the way zipl works now in Fedora.
yes, the issue occurred when updating the kernel
Problem description
An invalid
/etc/zipl.conf
is created for Fedora cloud images. When processingzipl
complains aboutkeyword 'targetbase' required
.Expected behaviour
bootloader reinstalled
Steps to reproduce the behaviour
Just rerun
zipl
after booting the image.OS and Software information
for full details please see https://koji.fedoraproject.org/koji/taskinfo?taskID=120569240