Talk:Unified kernel image

From ArchWiki


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

-- Cvlc (talk) 16:46, 4 December 2021 (UTC)Reply[reply]

I added my blog in the See Also section. That is good enough for me.
Foxboron (talk) 14:52, 5 December 2021 (UTC)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]

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)Reply[reply]

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

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)Reply[reply]

The section on ukify probably has a factual inaccuracy with respect to mkinitcpio

The section contains:

If the initramfs generator already bundles CPU microcode by default such as mkinitcpio, then only specify the initramfs image in Initrd=/boot/initramfs-linux.img.

However, as far as I understand the mkinitcpio documentation, mkinitcpio can only bundle microcode when it produces a UKI itself. Hence, when ukify is used, the microcode never already is provided by mkinitcpio.

Whxvd (talk) 17:37, 28 October 2023 (UTC)Reply[reply]

Yes, you are correct and thanks for pointing that out. The mkinitcpio script does not bundle microcode within the generated image, and this can be confirmed be listing its content using lsinitcpio and ensuring the ALL_microcode option is set in the preset(s). However, it's possible that other generators may bundle microcode so I still left the note. Nu4425 (talk) 17:48, 29 October 2023 (UTC)Reply[reply]
Thank you for confirming and changing the article. According to Help:Discussion#Closing_a_discussion I close this discussion. Whxvd (talk) 11:18, 30 October 2023 (UTC)Reply[reply]

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)Reply[reply]