Talk:Unified kernel image

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)

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)

why would I want systemd-ukify to be used?

Currently the mkinitcpio section only says `mkinitcpio will use systemd-ukify for UKI generation if it is installed, if not, mkinitcpio will create UKIs itself.` however it does not say why one would actually need systemd-ukify to be installed or how the final image will be different.

I'm currently using mkinitcpio and the systemd hook. It builds and boots just fine and it looks like it is also using systemd-boot because of that.

Could someone please extend that section with one or two sentences elaborating this? Agowa338 (talk) 14:03, 14 September 2024 (UTC)

After discussion in IRC, and checking the man pages of both ukify, and mkinitcpio as well as the change log of mkinitcpio it turns out the answer is the devs of mkinitcpio recommend using ukify and in fact state NOT using ukify is "not recommended".

I changed the wiki to reflect this. It now indicates that even though systemd-ukify is not required to build an UKI with mkinitcpio it is the recommended way of doing it. Agowa338 (talk) 15:47, 14 September 2024 (UTC)

Hi @Nl6720 I noticed your last edit, you removed the "not recommended" part of my edit. Did I misunderstand the part in mkinitcpio's man pages then?

https://man.archlinux.org/man/mkinitcpio.8

> --no-ukify

> Do not use ukify to build UKIs even if it is available. This is not recommended

Agowa338 (talk) 09:54, 15 September 2024 (UTC)

I removed it because, IMO, the phrase could be easily misunderstood. Having mkinitcpio generate UKIs itself, without having systemd-ukify installed, is fully supported. It is only not recommended to avoid the use of ukify when it is installed. -- nl6720 (talk) 06:27, 16 September 2024 (UTC)

Why EFI/Linux/arch-linux.efi instead of efi/boot/bootx64.efi ?

As I posted here https://bbs.archlinux.org/viewtopic.php?id=302669 it's possible to name the UKI to efi/boot/bootx64.efi (bootia32.efi for 32-bit BIOS UEFI) in the ESP, instead of EFI/Linux/arch-linux.efi or other, in general efi/boot/bootx64.efi (& bootia32.efi) in the ESP is auto detected by the BIOS UEFI (not legacy: MBR & PBR), directly available to boot, no need to create a boot entry by efibootmgr or a boot loader (I did it it works https://bbs.archlinux.org/viewtopic.php?id=302717). Jebez (talk) 08:55, 25 January 2025 (UTC)

I don't think it is good to have EFI/boot/bootx64.efi set as default since people don't always want to boot straight to a EFI stub. I think most people still use GRUB or systemd-boot to allow multibooting or boot-time snapshot switch, and these bootloader will occupy the default EFI binary location. Mkinitcpio/ukify does not want to overwrite them, and adding detection & switch mechanism is not worth it because users can configure themselves.

Shanoaice (talk) Shanoaice (talk) 18:19, 29 April 2025 (UTC)

Well I finally edited the page, now it's https://wiki.archlinux.org/index.php?title=Unified_kernel_image&oldid=827048.

By pressing F12, multibooting is possible on my PC, I can boot e.g. Windows 11. Jebez (talk) 21:37, 29 April 2025 (UTC)

The BIOS boot menu (I can't edit my previous post...). Jebez (talk) 06:26, 8 May 2025 (UTC)

kernel-install

The chapters 1.1 to 1.5 each descripe alternative options, but 1.2 kernel install seems to belong to chapter 1.1 ?!

Could someone please clarify where the kernel-install part is supposed to belong to? Bramble (talk) 17:41, 9 March 2025 (UTC)

kernel-install is not needed when you use UKI via mkinitcpio. kernel-install normally is not used in an Arch Linux installation, except when you explicitly choose to use it, e.g., if you want to manage different versions of different kernels on the system. The purposes of kernel-install and mkinitcpio overlap for some parts. When you use kernel-install, you probably still use mkinitcpio for initrd generation. But normally, kernel-install is not necessary.

So 1.1 (mkinitcpio) and 1.2 (kernel-install) in that sense are indeed alternative options. 1.2 (kernel-install) definitely is not needed for 1.1 (mkinitcpio), even though with kernel-install you usually still need an initrd image generator like mkinitcpio or dracut.

In case of confusion, I would recommend to just stick to the 1.1 (mkinitcpio) method. That is the simplest and most canonical way on Arch Linux. Whxvd (talk) 22:35, 9 March 2025 (UTC)

Thank you, that explains it. Perhaps the chapter 1.2 should get an overhaul to make this more clear. I am still not even sure what kernel-install really is and does so other may also be confused. Bramble (talk) 11:13, 10 March 2025 (UTC)

One more issue in chapter 1.2 is the link to kernel-install which points to a chapter that only contains a link back to this page, creating a loop of hyperlinks without explaining anything. Bramble (talk) 11:22, 10 March 2025 (UTC)

I tried to address this somewhat by adding a sentence about the origin. Bramble (talk) 11:27, 10 March 2025 (UTC)

About removing btrfs kernel cmdline notices

I am the contributor who added the notice about setting rootflags=subvol=xxx mount flags for Btrfs layout that has a subvolume as root, and I agree this is duplicate with Kernel parameters#Parameter list. However I think it is worth mentioning somewhere in the wiki in addition to that page, since I think not every people installing in Btrfs with such subvolume layout will notice that page. However, I find it inappropriate to simply stuff it in Installation guide since the relevant partitioning chapter only mentions Ext4.

Shanoaice (talk) Shanoaice (talk) 00:40, 30 April 2025 (UTC)

I flagged the tip for removal because I didn't think that having root on a non-default subvolume is that common. Only some boot loader pages even mention it. Perhaps we could make the tip slightly more generic by basically copying the rootflags description from Kernel parameters#Parameter list. Then the same tip could be added to all boot loader pages. -- nl6720 (talk) 08:09, 30 April 2025 (UTC)