Skip to main content ↑ ↓
Topic: [solved] `system/linux` version 5.3.8.1-2 misses kernel image. (Read 2246 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[solved] `system/linux` version 5.3.8.1-2 misses kernel image.

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:

Code: [Select]
# 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`:

Code: [Select]
$ pacman -Ql linux | grep -v /lib/modules
linux /usr/
linux /usr/lib/

Same for `linux-lts`.

Re: `system/linux` version 5.3.8.1-2 misses kernel image.

Reply #1 –
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.

Re: `system/linux` version 5.3.8.1-2 misses kernel image.

Reply #2 –
Quote from: artoo – on
Is your system converted from arch?
Long time ago.
Quote
The kernel image is copied by the mkinitcpio alpm hook to /boot.

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.

Re: `system/linux` version 5.3.8.1-2 misses kernel image.

Reply #3 –
Quote from: dreieck – on

Can the image be re-included in the package, please?



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.

Re: `system/linux` version 5.3.8.1-2 misses kernel image.

Reply #4 –
Quote from: artoo – on
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.)

Quote
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.

In which package specifically/ which is the hook?
 

Re: `system/linux` version 5.3.8.1-2 misses kernel image.

Reply #5 –
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.

Re: `system/linux` version 5.3.8.1-2 misses kernel image.

Reply #6 –
Quote from: artoo – on
Whatever caused this efi hook to fail caused your update to fail is my guess.

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.