rpm_ostree/installation.py: fix image deployment on s390x

[nikita-dubrovskii]

When user installs OS on s390x using some container image, it fails whith an error:

INFO:program:Running... ostree container image deploy --sysroot=/mnt/sysimage --image=quay.io/fedora/fedora-bootc:41-s390x
INFO:program:Error: Config file '/lib/s390-tools/zipl.conf': Cannot build automenu: no IPL entries available
INFO:program:Using config file '/lib/s390-tools/zipl.conf'

This happens, because ostree doesn't call zipl on installed deployment, but on / (without bubblewrapping).

This PR first sets bootloader to none, so ostree doesn't perform post_bls_sync, and than calls zipl direct from anaconda (similar to what we do in coreos-assembler).

Here is an eaxmple kickstart ostree.ks:

text
lang en_US.UTF-8
keyboard us
timezone --utc Etc/UTC
selinux --enforcing
rootpw --plaintext foobar
network --bootproto=dhcp --device=link --activate --onboot=on
zerombr
clearpart --all --initlabel
autopart --nohome --type=lvm
ostreecontainer --url quay.io/fedora/fedora-bootc:41-s390x
firewall --disabled
services --enabled=sshd
sshkey --username root YOUR_KEY_HERE

Using that config and kargs inst.ks=http://172.23.236.43/ostree.ks inst.sshd injected into Fedora 41 boot.iso,
installation succeeded:

Setting up the installation environment                                                                                    .
Configuring storage
Creating disklabel on /dev/vdb
Creating ext4 on /dev/vdb1
Creating lvmpv on /dev/vdb2
Creating ext4 on /dev/mapper/fedora_fedora-root
.
Running pre-installation scripts
.
Running pre-installation tasks
.
Installing the software
Deployment starting: quay.io/fedora/fedora-bootc:41-s390x
Deployment complete: quay.io/fedora/fedora-bootc:41-s390x
.
Configuring storage
.
Installing boot loader
.
Performing post-installation setup tasks

Issue: https://issues.redhat.com/browse/RHEL-63237

[nikita-dubrovskii]

/cc @cgwalters

[cgwalters]

The positive side of this is it moves what is being done in Anaconda to match what we're doing elsewhere.

The negative is we're also duplicating that logic, and I think medium term what we really want is to get back to having ostree run zipl in all places.

Actually I think what we really want here is to use bootc install-to-filesystem everywhere, and in that scenario bootc/ostree will own zipl.

So we can perhaps just take that cleanup task then.

[cgwalters]

I think this makes sense from the perspective of short-term parity with other pipelines.

I think what should happen eventually though is when we stop using ostree and bootupd individually in anaconda but instead switch to bootc install-to-filesystem this complexity will drop away, because bootc will then be the thing running zipl always.

And note bootc already does the equivalent of this dance internally.

(Of course, this will probably need to manifest as a new payload/bootc or so, but it should at least be significantly simpler and we could deprecate and eventually automatically switch ostreecontainer to call into it too)

[cgwalters]

Procedurally...how about landing this in rawhide, we do some soak testing there and then we can evaluate backports?

[nikita-dubrovskii]

@KKoukiou, mind a review? If this PR gets merged, than i'll close the Bug.

[KKoukiou]

@nikita-dubrovskii Focusing on more 🌶️ items at the moment, sorry for stalling reviewing this. Everyone from the team is occupied with more high priority stuff.