fedora-kiwi-descriptions

#268 UKI change breaks boot on system installed from aarch64 live image in openQA
Closed by kevin. Opened by adamwill.

Closed
Reopen Issue

Since https://pagure.io/fedora-kiwi-descriptions/pull-request/262 landed, openQA live image tests on aarch64 are failing every time. Building the live image works, we can boot and install from it, but booting the installed system dumps us at the UEFI boot menu.

This is likely because we have to change the boot options on aarch64. After install completes, we go to a console and edit /mnt/sysimage/etc/default/grub, then run chroot /mnt/sysimage grub2-mkconfig -o $(readlink -m /etc/grub2.cfg). We have to do this to add console=tty0 quiet to the boot args or else we don't get messages / prompts on vt1 during boot due to a longstanding issue about ACPI SPCR tables.

I know with a full, security-minded UKI setup you're not 'supposed' to change boot options (so if Fedora ever goes to that, we'll have to...figure something out). But my understanding of this change is it wasn't really intended to act that way, we're just (ab)using UKI mechanisms to implement the DTB selection thing. If it prevents modification of boot parameters I think that's a problem.

Can we revert this change for now and figure out how to make it compatible with changing boot args? If I need to change the implementation in openQA I can do that, it's not a problem.

Yeah, I'm okay with reverting this, feel free to send a PR to the F44 branch for this.

FYI: @jwrdegoede

https://pagure.io/fedora-kiwi-descriptions/pull-request/269

Isn't it better to just use grubby instead of regenerating the entire config? But no idea off hand why it broke...

maybe? I doubt it would make a difference, though. in the end the config is going to change, that's the point of what we're doing.

I thought grubby only changes the bls files, where grub2-mkconfig regenerates the entire grub2.cfg. But that may all just be a sidetrack...

Yeah, I'll see what Hans says.

The openQA code actually can do both, but it prefers to edit /etc/default/grub if it can find it. https://forge.fedoraproject.org/quality/os-autoinst-distri-fedora/src/branch/main/tests/_do_install_and_reboot.pm#L218 (note logic is 'reversed' because it's based on exit codes; it only does the boot/loader/entries thing if the etc/default/grub sed fails).

if you use sudo grubby --update-kernel=ALL --args="<args>", everything is updated.

I tested with that (and the test tweaked to checkout fedora-kiwi-descriptions to the commit before this was reverted); it still boots to the UEFI menu. So it apparently doesn't matter how exactly we change the config.

As I mentioned in #Fedora ARM and #Fedora kernel yesterday I've hit this during my own testing yesterday too. The problem is that for some reason there is no /boot/loader/entries entry being generated.

Actually there is no /boot/loader/entries dir at all. If I boot the livedvd again, mount the install on /sysroot (+ mount /proc /sys /dev) and then copy paste the %posttrans script it does generate the /boot/loader/entries. So I'm not entirely sure what is going on. I suspect some anaconda bug.

I was hoping to maybe get some hints on what is going on when I asked on matrix, but I've received no useful feedback. I've gone ahead and filed an anaconda bug for this:
https://bugzilla.redhat.com/show_bug.cgi?id=2440010

Pull request fixing things here: https://github.com/rhinstaller/anaconda/pull/6921

I guess with the updates-testing time it is too late to get this in before the beta freeze, so I'll go and ask for a beta freeze exception in bz2440010 .

I believe this is fixed now and this issue can be closed now?

yes.

Metadata Update from @kevin:
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Related Pull Requests
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.