You can always run kernel-install manually if you would like to.
I suppose a hook could also be created for ucode update/install.
i am not sure ⌠are the ucode packages getting updated without the kernel?
edit:
i do not think so i may got it confused with firmware packages⌠intel ucode is:
Last Updated: 2022-05-11 15:10 UTC
kernel:
Last Updated: 2022-06-17 16:21 UTC
It looks like the hook currently looks for kernel and mkinitcpio changes. You could change it to also include ucode updates.
I think it would work because if the script is triggered by something that isnât a kernel it runs kernel-install for all kernels.
1 Like
i still use the same systemd-boot setup from when you created the package files never had a single issue with it ⌠but indeed if ucode gets updated it should get into the boot process directlyâŚ
1 Like
and another question 
if i set a custom default kernel to load here: /efi/loader/loader.conf it seems the entry is looks like this: 281fea1d4656566a7ff0fe639cf67b6-5.18.8-arch1-1.conf but it do not change if kernel updates?
I add my loaders in /efi/loader/entries.
EX.
/efi/loader/entries/arch-gnome-zen.conf
title Arch-Gnome-zen
linux /arch-gnome/vmlinuz-linux-zen
initrd /arch-gnome/intel-ucode.img
initrd /arch-gnome/initramfs-linux-zen.img
options rw root=UUID=1d9646ea-0edf-423b-85a7-88a429c6314b rootflags=subvol=@arch-gnome-root resume=UUID=204b749a-eb7e-4b61-850e-f7a82da8c988 lsm=landlock,lockdown,yama,apparmor,bpf nowatchdog zswap.enabled=0
Then for making it default, you could choose one of the followings:
-
In the systemd boot menu, choose the loader you want and press d
-
From command line, run
bootctl list
to get a list of all your boot entries. Choose the ID for the boot entry you want to make default and:
bootctl set-default ID
This would remain the same with kernel updates.
Note: /arch-gnome is a folder in my /efi. You need to give the path to where your kernel resides relative to your /efi.
1 Like
i use the automatic way so i am not creating the entries manually, question is if i mad something wrong with it or it need to change the way it creates the path names and entry namesâŚ
Alright. I have never done it automatically so I am not familiar with the process.
I better keep silent and watch to learn 
oh no sorry ! i wanted not to shut you up
1 Like
A note to myself 
Updates wonât automatically change your loader.conf. It honors whatever you have set.
However, loader.conf supports wildcards so if you want the mainline kernel to always be the primary you would use something like:
default 281fea1d4656566a7ff0fe639cf67b6*-arch1-*
2 Likes
that solves my issue !
1 Like
for the next install i use like this currently just using /boot 
1 Like
/boot is fine too⌠and follows the same logicâŚ
you could use /ringostar too i think
i dont know 
was just easier to change the fstab to /boot rest copypaste & wiki
I added eos-systemd-boot to the AUR as kernel-install-mkinitcpio which should make it easier to install and maintain.
Of course, the old PKGBUILD is still available if you would prefer the package to be called eos-systemd-boot 
1 Like
Is this the same thing?
Then it probably needs an update?
Or even better, change the PKGBUILD to use your upstream url instead.
It is the same thing. However, I donât think that package is actually being built.
I tried the tudorial on a test system which was installed with luks and btrfs.
Trying the kernel-install things worked ok till I tried the Special handling for LUKS section.
Here sudo mkinitcpio -P didnât work because the presets in /etc/mkinitcpio.d pointed to /boot. As I wasnât sure what is best I just uninstalled and re-installed the kernels. Then the pointers in the preset files were ok.
The only error I get now during startup is something about the [openswap] hook where a mount command reports bad usage. I just removed this hook which seems to be fine
One question I have. On my real system I have a second SSD which is LUKS envrypted.
I am not sure but assume it is best to keep the keyfile for the second disk. Is this correct?