Talk:Unified kernel image

mkinitcpio

All mkinitcpio info was ruthlessly copied from [1] Not sure how to reference this.

-- Cvlc (talk) 16:46, 4 December 2021 (UTC)

I added my blog in the See Also section. That is good enough for me.

Foxboron (talk) 14:52, 5 December 2021 (UTC)

Mkinitcpio still also creates regular initramfs

The linux.preset file leaves both the regular initramfs files and the .efi binary. Might need adapting so that only the .efi file is left in the end, but not sure about that.

-- Cvlc (talk) 17:23, 4 December 2021 (UTC)

Now you can use kernel-install (with layout=uki mode) instead of mkinitpcio and that will only generate .efi files. I have added a section about this. 05storm26 (talk) 10:09, 12 December 2022 (UTC)

I saw your edit, however kernel-install is not yet mentioned anywhere else in the wiki, guess there should be guidance elsewhere on how to use it properly (hooks, command-line etc...) because just mentioning it here only does not seem sufficient.

-- Cvlc (talk) 13:09, 13 December 2022 (UTC)

-- I think it is an error to disable initramfs creation else it is not created and included in UKI. I have modiffied the example linux.preset accordingly solsTiCe (talk) 12:58, 15 March 2024 (UTC)

That's wrong. Run mkinitcpio with -v/--verbose and you'll see that an initramfs image is still generated under /tmp/. It is simply not retained after the UKI is generated. -- nl6720 (talk) 13:29, 15 March 2024 (UTC)

Keep sbctl pacman hook with kernel install?

The kernel-install section stubs out the sbctl pacman hook. Is this a good idea? The kernel-install plugins only sign the kernel after all, so presumably folks would still use sbctl to keep their boot loader signed, at least. Disabling the hook could perhaps silently render systems unbootable under secure boot, because an unsigned bootloader copy ends up on /efi.

--swsnr (talk) 19:11, 19 December 2022 (UTC)

oops, yes I think you are correct. 05storm26 (talk) 19:26, 11 January 2023 (UTC)

ukify needs an experimental warning?

At the very top of man ukify there is a warning

Note: this command is experimental for now. While it is intended to become a regular component of systemd, it might still change in behaviour and interface.

This warning should be mentioned in the ukify section, as such a change will break the solution given there.

--PBS (talk) 00:54, 24 August 2023 (UTC)

As of systemd 255, ukify is no longer experimental. Nu4425 (talk) 20:38, 11 December 2023 (UTC)

Automatic update of ukify-generated images via systemd path units is unreliable

The section on ukify shows a way to use systemd path units to automatically trigger rebuilding the UKI when microcode or initramfs changes. However, that does not work reliably. I do not know exactly why. But probably ukify in some situations gets triggered at times when either the new microcode of the new initramfs is not yet completely written. Then it probably creates a UKI with, e.g., half of an initramfs. The effect is that the system becomes unbootable. Whxvd (talk) 17:44, 28 October 2023 (UTC)

Yes, exactly the same happened to me recently. And I think you are right, run_ukify.service is started before mkinitcpio is totally done. According to the systemd.path man page "PathChanged= (...) is not activated on every write to the watched file but it is activated if the file which was open for writing gets closed." Is it possible that mkinitcpio closes the file at some point before finishing writing the image? Iyanmv (talk) 15:44, 11 December 2023 (UTC)

What about adding this workaround to run_ukify.service: ExecStartPre=/bin/sleep 10? Iyanmv (talk) 16:03, 11 December 2023 (UTC)

Alternatively, a pacman hook similar to Unified kernel image#pacman hook can be used. Also, there's an official kernel-install plugin available for ukify. Nu4425 (talk) 20:39, 11 December 2023 (UTC)

I tried to come up with a pacman hook. As far as I remember, I encountered the following problem: The hook would need to be run when (a) new microcode arrived, and/or (b) when a new initrd has been built. The case (c) of a new kernel image is subsumed by (b), because new kernel images always trigger mkinitcpio.

However, (b) would require a way to trigger a pacman hook when another hook (the mkinitcpio hook) has been run. I did not find a way to accomplish that, and concluded that pacman does not support triggering hooks by other hooks.

I did not know about kernel-install. Maybe that will become handy in the future.

For now, I have another solution that works well for me, but depends on my personal workflow. Whxvd (talk) 21:25, 11 December 2023 (UTC)

Have you tried using the pacman hook provided in Unified kernel image#pacman hook? It takes effect in microcode code or kernel updates, and IIUC the job is a post-dependent transaction of mkinitcpio. Personally, I haven't noticed or see any problems with this hook and if you use it, just be sure to modify the Exec line accordingly.

Also to run pacman hooks deterministically, I believe it depends on the number and executes in ascending order. For example, 10-ucode.hook executes first followed by 20-ucode.hook, etc. Correct me if I am wrong, but, presumably, you've already tried that? Nu4425 (talk) 03:49, 14 December 2023 (UTC)

Pacman hooks are executed in lexicographical order so I've named mine zz_ukify.hook and it always runs after 60-mkinitcpio.hook, sbctl uses a similar method. I based my hook on the mkinitcpio hook with added Package triggers for systemd: https://bbs.archlinux.org/viewtopic.php?pid=2138907#p2138907 Head on a Stick (talk) 00:32, 26 December 2023 (UTC)

Adding a delay probably works in nearly all cases. Maybe even always. But "probably", "nearly", and "maybe" is not good enough IMO. Whxvd (talk) 21:02, 11 December 2023 (UTC)

sbctl pacman hook doesn't trigger with mkinitcpio

If you follow the mkinitcpio instructions, the pacman sbctl hook doesn't seem to trigger, and I can't figure out why. Is this an issue with the hook or should I add a post mkinicpio hook to sign the uki? Update: of course it doesn't trigger, nothing is getting installed to /boot or /efi. I can add a small mkinitcpio hook to sign, unless I'm missing something. Wsduvall (talk) 13:46, 14 January 2024 (UTC)

The structure of this page is confusing (to me)

The procedure to build and install an UKI seemed to be prohibitively complicated until I realized that maybe I don't understand that subsections 1.1 through 1.6 are alternatives, and that it is enough to follow only one of these? If that is true (Im not 100% sure) it would probably be a good idea to add a paragraph to that effect under section 1, as well as a brief explanation as to why one might prefer one over the other. And sorry for multiple change submissions until I got the metadata right. Thanks! Musbur (talk) 10:24, 15 January 2024 (UTC)

I agree, each subheading of Preparing a unified kernel image should probably be made a top level heading. Its super confusing as it stands and I was baffled by it when I set up UKI. Wsduvall (talk) 11:16, 17 January 2024 (UTC)

I have added a disclamer that you need to choose only one. 05storm26 (talk) 11:17, 17 January 2024 (UTC)

Thank you, you fixed it literally as I was entering my comment. Wsduvall (talk) 11:18, 17 January 2024 (UTC)