No boot entries after update

Support System Updates
,
1

Hello, I have a huge problem.
I installed the latest update yesterday. I used “pamac-manager” to do so. The update removed the 6.19 kernel and installed the 7.0 kernel. The updater then asked me to restart so that all the updates would take effect.
After restarting, all boot entries have disappeared. The only option available is the EFI firmware interface.
I then booted a live system and switched to the existing system using “manjaro-chroot -a”.
After a few attempts, I discovered that mkinitcpio -P can no longer create kernel images.
I receive an error message for which I can find no information online.

[manjaro efi]# sudo mkinitcpio -P -v
==> Building image from preset: /etc/mkinitcpio.d/linux618.preset: 'default'
==> Using configuration file: '/etc/mkinitcpio.conf'
  -> -v -k /efi/24ba410fa0004699934f8288629b0df4/6.18.26-1-MANJARO/linux -c /etc/mkinitcpio.conf -g /efi/24ba4
10fa0004699934f8288629b0df4/6.18.26-1-MANJARO/initrd
==> ERROR: Invalid option -k -- '/efi/24ba410fa0004699934f8288629b0df4/6.18.26-1-MANJARO/linux' must be readab
le
==> Building image from preset: /etc/mkinitcpio.d/linux618.preset: 'fallback'
==> Using configuration file: '/etc/mkinitcpio.conf'
  -> -v -k /efi/24ba410fa0004699934f8288629b0df4/6.18.26-1-MANJARO/linux -c /etc/mkinitcpio.conf -g /efi/24ba4
10fa0004699934f8288629b0df4/6.18.26-1-MANJARO/initrd-fallback -S autodetect
==> ERROR: Invalid option -k -- '/efi/24ba410fa0004699934f8288629b0df4/6.18.26-1-MANJARO/linux' must be readable
==> Building image from preset: /etc/mkinitcpio.d/linux70.preset: 'default'
==> Using configuration file: '/etc/mkinitcpio.conf'
  -> -v -k /efi/24ba410fa0004699934f8288629b0df4/7.0.3-1-MANJARO/linux -c /etc/mkinitcpio.conf -g /efi/24ba410
fa0004699934f8288629b0df4/7.0.3-1-MANJARO/initrd
==> ERROR: Invalid option -k -- '/efi/24ba410fa0004699934f8288629b0df4/7.0.3-1-MANJARO/linux' must be readable
==> Building image from preset: /etc/mkinitcpio.d/linux70.preset: 'fallback'
==> Using configuration file: '/etc/mkinitcpio.conf'
  -> -v -k /efi/24ba410fa0004699934f8288629b0df4/7.0.3-1-MANJARO/linux -c /etc/mkinitcpio.conf -g /efi/24ba410
fa0004699934f8288629b0df4/7.0.3-1-MANJARO/initrd-fallback -S autodetect
==> ERROR: Invalid option -k -- '/efi/24ba410fa0004699934f8288629b0df4/7.0.3-1-MANJARO/linux' must be readable

The system starts with systemd-boot. I have an EFI partition and no boot partition.
bootctl status shows no entries.

mkinitcpio can’t create an image. All failed with the error message above,

Can anyone help me? Does anyone have any ideas? I really don’t feel like reinstalling the system. I’ve made so many changes over the years that I can hardly remember them all. They’d all be lost.

Mod edit: Screenshot removed and replaced with code-formatted text.

2

You are already chROOT, you do not need sudo.
Otherwise, If this was grub, i would say a simple update-grub would be the simplest to try, but you have tagged systemd-boot which i do not really know how it works/is configured. Let’s wait the others.

3

Please copy/paste the terminal content - instead of pictures.

This will ensure it is searchable - thus others may be able to find this topic.

It is not clear how your rescue mission has been started - you must ensure it is UEFI - but it seems your $esp has not been mounted.

manjaro-chroot -a expects the bootloader to be grub - so manjaro-chroot -a will not work.

So when using systemd-boot you will need to mount $root and $esp manually.

Your mkinitcpio.conf points to /efi as the mountpoint for your $esp partition.

Example (using the first nvme device) - boot your rescue iso - then switch to root context

sudo su

mount the $root partition (assuming it is the second partition)

mount /dev/nvme0n1p2 /mnt

mount the $esp partition (assuming it is the first partition)

mount /dev/nvme0n1p1 /mnt/efi

Then enter chroot

manjaro-chroot /mnt /bin/bash

Then run mkinitcpio

mkinitcpio -P
3 Likes
4

Sorry about the screenshot—I have long passwords and can’t access my password manager on the live system. That’s why I couldn’t post this from the live system.

It may be that manjaro-chroot -a requires GRUB, but the command you’re using seems to be the one you’re suggesting to run manually.

Here is the output:

[manjaro manjaro]# manjaro-chroot -a
grub-probe: error: cannot find a GRUB drive for /dev/sdb1.  Check your device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sdb1.  Check your device.map.
==> Mounting (ManjaroLinux) [/dev/nvme0n1p2]
 --> mount: [/mnt]
 --> mount: [/mnt/efi]
 --> mount: [/mnt/home]
[manjaro /]#

Those are the same mount points, right? Here’s the mtab from the chrooted system:

[manjaro /]# cat /etc/mtab
/dev/nvme0n1p2 / ext4 rw,relatime 0 0
/dev/nvme0n1p1 /efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/sda1 /home ext4 rw,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sys /sys sysfs ro,nosuid,nodev,noexec,relatime 0 0
efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=7955688k,nr_inodes=1988922,mode=755,inode64 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
shm /dev/shm tmpfs rw,nosuid,nodev,relatime,inode64 0 0
run /run tmpfs rw,nosuid,nodev,relatime,mode=755,inode64 0 0
tmp /tmp tmpfs rw,nosuid,nodev,inode64 0 0
overlay /etc/resolv.conf overlay rw,relatime,lowerdir=/run/miso/sfs/livefs:/run/miso/sfs/mhwdfs:/run/miso/sfs/desktopfs:/run/miso/sfs/rootfs,upperdir=/run/miso/overlay_root/upper,workdir=/run/miso/overlay_root/work,index=off,uuid=on,xino=off 0 0

And here the mtab excerpt from the live system:

/dev/nvme0n1p2 /mnt ext4 rw,relatime 0 0
/dev/nvme0n1p1 /mnt/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/sda1 /mnt/home ext4 rw,relatime 0 0
proc /mnt/proc proc rw,nosuid,nodev,noexec,relatime 0 0
sys /mnt/sys sysfs ro,nosuid,nodev,noexec,relatime 0 0
efivarfs /mnt/sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0
udev /mnt/dev devtmpfs rw,nosuid,relatime,size=7955688k,nr_inodes=1988922,mode=755,inode64 0 0
devpts /mnt/dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
shm /mnt/dev/shm tmpfs rw,nosuid,nodev,relatime,inode64 0 0
run /mnt/run tmpfs rw,nosuid,nodev,relatime,mode=755,inode64 0 0
tmp /mnt/tmp tmpfs rw,nosuid,nodev,inode64 0 0
overlay /mnt/etc/resolv.conf overlay rw,relatime,lowerdir=/run/miso/sfs/livefs:/run/miso/sfs/mhwdfs:/run/miso/sfs/desktopfs:/run/miso/sfs/rootfs,upperdir=/run/miso/overlay_root/upper,workdir=/run/miso/overlay_root/work,index=off,uuid=on,xino=off 0 0

I tried it yesterday without the automatic script from manjaro-chroot. I mounted everything according to the instructions in the Arch Wiki. But I got the same result.

mkinitcpio -P -v

makes:

==> ERROR: Invalid option -k -- '/efi/24ba410fa0004699934f8288629b0df4/7.0.3-1-MANJARO/linux' must be readable

Am I missing something?

5

Manjaro normally does not mount the EFI system partition at /efi, but at /boot/efi instead.

2 Likes
6

/boot/efi is a link to /efi

[manjaro /]# ls /boot
efi  intel-ucode.img  linux618-x86_64.kver  linux70-x86_64.kver  memtest86+
[manjaro /]# ls /boot/efi
24ba410fa0004699934f8288629b0df4  EFI  loader
[manjaro /]# ls /efi
24ba410fa0004699934f8288629b0df4  EFI  loader
7

Not always and not on every machine.

On topic: My gut tells me it is something with improper mounting and thus lack of permission to write but i am still unsure why and how so i will leave the wiser heads to think this one through.

8

Not write permission. The error says
“‘/efi/24ba410fa0004699934f8288629b0df4/7.0.3-1-MANJARO/linux’ must be readable”. But everything is readable.

Does anyone know what “invalid option -k” means?

And what about the last part of the path “/linux”? Is it a file or a folder? If I make a folder named linux mkinitcpio error is: ‘/efi/24ba410fa0004699934f8288629b0df4/7.0.3-1-MANJARO/linux’ must not be a directory,

9 
     -k, --kernel kernelversion
         Use kernelversion, instead of the current running kernel. This may be a path to a kernel image (only supported
         for x86-based architectures), a specific kernel version or the special keyword none. In the  latter  case,  no
         kernel modules are added to the image.

Should be a file. But this random generated path ocurred, i have no idea.

1 Like
10

The -k option specifies the kernel version. When you run sudo mkinitcpio -P, the configurations in /etc/mkinitcpio.d are processed. It seems the preset file for your 7.0.3 kernel isn’t working properly.

It’s also possible that it can’t find what it’s looking for and then outputs this message, but that’s just a guess.

11

For reference, here is how it should look:

[teo@teo-lenovo-v15 ~]$ sudo mkinitcpio -P -v
[sudo] password for teo: 
==> Building image from preset: /etc/mkinitcpio.d/linux618.preset: 'default'
==> Using default configuration file: '/etc/mkinitcpio.conf'
  -> -v -k /boot/vmlinuz-6.18-x86_64 -g /boot/initramfs-6.18-x86_64.img
==> Starting build: '6.18.26-1-MANJARO'
  -> Running build hook: [/usr/lib/initcpio/install/systemd]
    adding module: lz4 (/lib/modules/6.18.26-1-MANJARO/kernel/crypto/lz4.ko.zst)
    adding module: lz4_compress (/lib/modules/6.18.26-1-MANJARO/kernel/lib/lz4/lz4_compress.ko.zst)
    adding file: /usr/bin/modprobe
................

I think it cannot find this (randomly generated?) path…
Is it possible that something is wrong with the conf or presets?

12

In the conf are some two modules, some hooks and a compression defined:

MODULES="crc32c i915"

HOOKS=(base udev autodetect plymouth modconf block keyboard keymap micorcode consolefont filesystems resume fsck)

COMPRESSION="zstd"

This are the two preset files:

[manjaro mkinitcpio.d]# cat linux70.preset
ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/efi/24ba410fa0004699934f8288629b0df4/7.0.3-1-MANJARO/linux"
PRESETS=(default fallback)
default_image="/efi/24ba410fa0004699934f8288629b0df4/7.0.3-1-MANJARO/initrd"
fallback_image="/efi/24ba410fa0004699934f8288629b0df4/7.0.3-1-MANJARO/initrd-fallback"
fallback_options="-S autodetect"

ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/linux"
PRESETS=(default fallback)
default_image="/efi/24ba410fa0004699934f8288629b0df4/6.18.26-1-MANJARO/initrd"
fallback_image="/efi/24ba410fa0004699934f8288629b0df4/6.18.26-1-MANJARO/initrd-fallback"
fallback_options="-S autodetect"

Aren’t they all automatically generated by the system? Including the path. The long number is the machine ID, as far as I know.

I haven’t touched any of these files. I’ve been tinkering with Linux for a while now, but I’m just a hobbyist—not a computer scientist or an IT professional. That’s why I know which things I need to leave alone.
systemd-boot regenerates the kernel images every time there’s an update via a pacman hook. I haven’t had any problems with that in two years. The update must have changed something.

13

I never deep dived into the manjaro-chroot script so I realise this part of my earlier comment is incorrect.

I found the manjaro-chroot script to be searching for the /etc/fstab and mounting the partitions according to the content.

Please accept my apology for the above nonsense.

cat /etc/machine-id will reveal if that assumption is correct.

I recall that we have a package systemd-boot-manager which maintains systemd-boot entries for Manjaro.

Personally I have moved my laptops to use unified kernel to boot - this eliminates the need for intermediaries such as grub, limine, systemd-boot etc.

14

Pretty sure it has that error if the path to the kernel image is invalid (permissions issue could also do it because invalid path if no access)

Is most likely a GUID of a disk or partition, but I have no idea why it would be trying to use that.

mkinitcpio uses a /etc/mkinitcpio.d/{kernel}.preset file to get the file paths etc. That file in turn is generated by a pacman hook every time a new kernel is installed. My guess is your efi folder was mounted incorrectly prior to the update which caused the hook to generate invalid paths that were perhaps corrected after the update.

You can confirm by reading the contents of /etc/mkinitcpio.d/linux618.preset and /etc/mkinitcpio.d/linux70.preset

Also include your /etc/fstab file.

Edit: forgot the link

15

I am no expert mkinitcpio so looking a little deeper

 $ mkinitcpio -h
mkinitcpio 41
usage: mkinitcpio [options]

  Options:
   -A, --addhooks <hooks>       Add specified hooks, comma separated, to image
   -c, --config <config>        Use alternate config file. (default: /etc/mkinitcpio.conf)
   -g, --generate <path>        Generate cpio image and write to specified path
   -H, --hookhelp <hookname>    Display help for given hook and exit
   -h, --help                   Display this message and exit
   -k, --kernel <kernelver>     Use specified kernel version (default: 7.0.3-2-MANJARO)
   -L, --listhooks              List all available hooks
   -M, --automods               Display modules found via autodetection
   -n, --nocolor                Disable colorized output messages
       --nopost                 Disable post hooks
   -I, --include <paths>        Add a list of files or directories, comma separated, to image.
   -p, --preset <file>          Build specified preset from /etc/mkinitcpio.d
   -P, --allpresets             Process all preset files in /etc/mkinitcpio.d
   -R, --remove                 Remove specified preset images
                                This option can only be used with either '-p|--presets' or '-P|--allpresets'
   -r, --moduleroot <dir>       Root directory for modules (default: /)
   -S, --skiphooks <hooks>      Skip specified hooks, comma-separated, during build
   -s, --save                   Save build directory. (default: no)
   -d, --generatedir <dir>      Write generated image into <dir>
   -t, --builddir <dir>         Use DIR as the temporary build directory
   -D, --hookdir <dir>          Specify where to look for hooks
   -U, --uki <path>             Build a unified kernel image
   -V, --version                Display version information and exit
   -v, --verbose                Verbose output (default: no)
   -z, --compress <program>     Use an alternate compressor on the image (cat, xz, lz4, zstd)

  Options for unified kernel image (-U, --uki):
   --cmdline <path>             Set kernel command line from file or drop-in directory
                                (default: /etc/kernel/cmdline, /etc/cmdline.d or /proc/cmdline)
   --no-cmdline                 Do not embed a kernel command line
   --osrelease <path>           Include os-release (default: /etc/os-release)
   --splash <path>              Include bitmap splash
   --kernelimage <path>         Kernel image
   --uefistub <path>            Location of UEFI stub loader
   --ukiconfig <path>           Location of configuration file for UKIs, used for signing, etc.

As mentioned I am no expert mkinitcpio or the error messages, but it looks like mkinitcpio saying that the path does not exist

'/efi/24ba410fa0004699934f8288629b0df4/6.18.26-1-MANJARO/linux'

If you have the tree package sync’ed, after mounting your devices but before chroot - I would like you to provide the output.

As I recall systemd-boot it expects an entries structure beneath the loader folder - see systemd-boot - ArchWiki

Using sudo because the /mnt/efi may only be accessible by root - this should be compared to the path parts as indicated by the error message

sudo tree /mnt/efi

Another check

We note the -k option is the kernel version (already pointed out).
This is read from the /boot/*.kver files

 $ cat /boot/linux70-x86_64.kver 
7.0.3-2-MANJARO x64

 $ cat /boot/linux618-x86_64.kver 
6.18.26-2-MANJARO x64

tree /mnt/boot -L1

tree /mnt/usr/lib/modules -L1

These should indicate if a kernel version file in /boot is referring to a non-existing kernel /mnt/usr/lib/modules

18

No problem, that’s happened to me before.

It is the machine ID:

[manjaro mkinitcpio.d]# cat /etc/machine-id
24ba410fa0004699934f8288629b0df4

The content of the preset files are posted above. No boot entries after update - #12 by davodego

And here are the output of /etc/mtab from live and chroot system No boot entries after update - #4 by davodego

Ok, without chroot I mounted root and efi to /mnt/ and /mnt/efi
Tree output:

[manjaro@manjaro ~]$ tree /mnt/efi
/mnt/efi
├── 24ba410fa0004699934f8288629b0df4
│   ├── 6.12.85-1-MANJARO.bak
│   ├── 6.18.26-1-MANJARO
│   ├── 6.18.26-1-MANJARO.bak
│   ├── 7.0.3-1-MANJARO
│   └── 7.0.3-1-MANJARO.bak
├── EFI
│   ├── BOOT
│   │   └── BOOTX64.EFI
│   ├── HP
│   │   ├── BIOS
│   │   │   ├── Current
│   │   │   │   └── Q85_013100.bin
│   │   │   ├── New
│   │   │   └── Previous
│   │   │       └── Q85_011500.bin
│   │   └── DEVFW
│   │       └── ME.BIN
│   ├── Linux
│   └── systemd
│       └── systemd-bootx64.efi
└── loader
    ├── entries
    ├── entries.srel
    ├── keys
    ├── loader.conf
    └── random-seed

20 directories, 8 files

[manjaro@manjaro ~]$ tree /mnt/boot -L1
/mnt/boot
├── efi -> /efi
├── intel-ucode.img
├── linux618-x86_64.kver
├── linux70-x86_64.kver
└── memtest86+

2 directories, 4 files

[manjaro@manjaro ~]$ tree /mnt/usr/lib/modules -L1
/mnt/usr/lib/modules
├── 6.18.26-1-MANJARO
├── 6.9.0-1-MANJARO -> 6.9.2-1-MANJARO
└── 7.0.3-1-MANJARO

3 directories, 1 file

Mod edit: Consecutive posts merged.

19

As mentioned, in Manjaro /boot/efi is the mountpoint of the EFI System Partition (ESP) – that is, it links to the $ESP (a partition) and not the /EFI directory, which typically resides within the root of the $ESP.

Although the $ESP often bears a partition label of EFI by default, it is not a directory.

Map from / Map from $ESP
/boot/efi $ESP
/boot/efi/EFI $ESP/EFI
/boot/efi/EFI/Boot $ESP/EFI/Boot
/boot/efi/EFI/Manjaro $ESP/EFI/Manjaro 
sudo ls /boot/efi
sudo ls /boot/efi/efi
sudo ls /boot/efi/efi/boot
sudo ls /boot/efi/efi/manjaro

Note: As the $ESP is typically formatted as a vfat variant (usually fat32, or sometimes fat16) the filesystem is usually case-insensitive.

Trivia: Manjaro shares the general industry adoption of the /boot/efi as the mountpoint to the $ESP; interestingly, Arch (proper) suggests using the /efi mountpoint.

20

If you read my comment more closely, you will see that this is exactly what I was talking about. :grin:

1 Like
21

It was obvious to me, but to the intended recipient, it seems, not so much. :thought_balloon:

1 Like
22

Ahh, sorry I missed them.

I’m not an expert on this, but…

You also haven’t processed a /etc/mkinitcpio.conf.pacnew file from a few updates ago which would have moved you to systemd.

I’m not sure why, but this indicates Boot Loader Specification (BLS) was attempted but seems to have only been partially implemented. Basically it uses the machine-id as a folder on the efi partition to keep the kernels for that particular system. So if you dual boot with another distro for example, that distro will keep the kernel files in a separate folder with a different machine-id.

This behaviour AFAIK is triggered by systemd hooks; so by not moving to systemd boot instead of udev I presume Manjaro has been configured to expect this but your non-systemd boot setup is expecting something else.

Changing to systemd instead of udev may just fix your problem.