I just installed the latest `system/linux` (version 5.3.8.1-2), and it is missing the kernel image (`/boot/vmlinuz-linux`), thus leaving me with a system without kernel. I was already wonderung, why the update was freeing about 2x MiB of disk space.
Same with `system/linux-lts` version 4.19.81-2.
What was changed, how to get the `/boot/vmlinu-*` back?
Note: The pacman output for the installation is:
# pacman -S linux-lts linux-lts-headers
Package (2) New Version Net Change Download Size
system/linux-lts 4.19.81-2 68.82 MiB 64.51 MiB
system/linux-lts-headers 4.19.81-2 96.63 MiB 16.88 MiB
Total Download Size: 81.39 MiB
Total Installed Size: 165.45 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages...
' linux-lts-4.19.81-2-x86_64 57.3 MiB 661K/s 00:37 [########################################------] 70 linux-lts-4.19.81-2-x86_64 64.5 MiB 304K/s 03:37 [##############################################] 79%
linux-lts-headers-4.19.81-2-x86_64 81.4 MiB 353K/s 03:56 [##############################################] 100%
(2/2) checking keys in keyring [##############################################] 100%
(2/2) checking package integrity [##############################################] 100%
(2/2) loading package files [##############################################] 100%
(2/2) checking for file conflicts [##############################################] 100%
:: Processing package changes...
(1/2) installing linux-lts [##############################################] 100%
Optional dependencies for linux-lts
crda: to set the correct wireless channels of your country [installed]
linux-firmware: firmware images needed for some devices [installed]
(2/2) installing linux-lts-headers [##############################################] 100%
:: Running post-transaction hooks...
(1/2) Install DKMS modules
==> dkms install vboxhost/6.0.12_OSE -k 4.19.81-2-lts
(2/2) Updating EFI kernel images
Updating EFI kernels...
Building toi
objcopy: '/usr/lib/systemd/boot/efi/linuxx64.efi.stub': No such file
objcopy: --change-section-vma .initrd=0x0000000003000000 never used
objcopy: --change-section-vma .linux=0x0000000000040000 never used
objcopy: --change-section-vma .cmdline=0x0000000000030000 never used
objcopy: --change-section-vma .osrel=0x0000000000020000 never used
error: command failed to execute correctly
I am wondering what the `objcopy: '/usr/lib/systemd/boot/efi/linuxx64.efi.stub': No such file` should tell me, and why there is reference to `systemd`, since systemd is not used on Artix Linux.
The `linux`-package has nothing outside `/lib/modules`:
$ pacman -Ql linux | grep -v /lib/modules
linux /usr/
linux /usr/lib/
Same for `linux-lts`.
Is your system converted from arch?
I have no clue where the efi hook on your system comes from.
The kernel image is copied by the mkinitcpio alpm hook to /boot.
Long time ago.
So this is a change, previously the kernel image was part of the package.
I now use `chaotic-aur/linux-tkg-bmq-atom`, which still provides the image in `/boot` within the package.
Can the image be re-included in the package, please? That would make it more failsafe if some hooks fail.
Nope. In fact, the image had been included twice in all previous versions in /usr/lib/modules/<kver>
All the mkinitcpio hook does is copying the vmlinuz image to /boot.
Arch changed this and included the hooks in mkinitcpio rather than previously in the kernel.
This make it easy to eg default to dracut.
I am afraid, you got wait until the AUR catches up or use the default kernel, these changes won't be reverted.
I was trying the default kernel (`system/linux`, as I wrote), thats the thing. (The `chaotic-aur/linux-tkg-bmq-atom` was some workaround to quickly get back to a working system with an up-to-date kernel without compilation of the kernel, the `chaotic-aur/linux-tkg-bmq-atom` still had the image included.)
In which package specifically/ which is the hook?
I am not sure what you are actually asking.
The kernel and mkinitcpio updates work fine, sufficiently tested, kernel modules are present.
Whatever caused this efi hook to fail caused your update to fail is my guess.
As said, this efi hook in your output is not part of any artix package, and my guess is, this efi hook is systemd specific.
It was `aur/arch-efiboot`. Removing it makes the kernel image copying over into `/boot` succeeding.
Thanks for the suggestion!
Only thing that might be of interest to change: If one hook fails, do not abort the whole process but continue with hooks not relying on the failed one.