[EN] (Solved) System not booting with separate /boot and /boot/efi

[user78]

hello world,

I have difficulities installing siduction with a specific partition layout.
After "successful" installation, the boot screen tells me to load a kernel first.

I tried this with my desktop system which was running Linux Mint. I formatted /, /boot, but not /boot/efi as there is also a Windows on another disk.
At first I thought I was crazy, but after multiple tries and messing around with chroot, I just tried Sparky Linux (based on testing, also with calamares installer) and everything worked as expected. I'm writing from that installaltion right now. I didn't have issues with Mint, either.

To make sure I'm not crazy, I tried it in a VM and it shows the same behavior. Now I'm here and need help to get it working as I'd like to use siduction.

my partition layout:

Code: [Select]

/dev/vda1  300M vfat  /boot/efi
/dev/vda2  1.2G ext4  /boot
/dev/vda3  40G btrfs  /
/dev/vda4  20G ext4  /home
the error:

Code: [Select]

Loading Linux 6.5.2-1-siduction-amd ...
Error: file `/@/boot/vmlinuz-6.5.2-1-siduction-amd64' not found.
Loading initial ramdisk ...
error: you need to load a kernel first.

Press any key to continue... [i](to grub menu)[/i]

If I run the live cd and check with chroot helper if the files are where they should be, everything seems ok. but /boot/efi couldn't be mounted at chroot start cause the boot partition is mounted after the efi partition. If I change the order in fstab, the error is gone in chroot, but the system still does not boot.

Code: [Select]

mount: /boot/efi: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
root@chroot-helper:/#

root@chroot-helper:/# ls -l /boot/
total 47576
-rw-r--r-- 1 root root   289985 Sep  6 22:43 config-6.5.2-1-siduction-amd64
drwxr-xr-x 2 root root     4096 Dec  2 17:22 efi
drwxr-xr-x 5 root root     4096 Dec  2 17:25 grub
-rw-r--r-- 1 root root 36710163 Dec  2 17:25 initrd.img-6.5.2-1-siduction-amd64
drwx------ 2 root root    16384 Dec  2 17:22 lost+found
-rw-r--r-- 1 root root   138712 Aug 19 12:40 memtest86+ia32.bin
-rw-r--r-- 1 root root   139776 Aug 19 12:40 memtest86+ia32.efi
-rw-r--r-- 1 root root   144344 Aug 19 12:40 memtest86+x64.bin
-rw-r--r-- 1 root root   145408 Aug 19 12:40 memtest86+x64.efi
-rw-r--r-- 1 root root  3396215 Sep  6 22:43 System.map-6.5.2-1-siduction-amd64
-rw-r--r-- 1 root root  7712736 Sep  6 22:43 vmlinuz-6.5.2-1-siduction-amd64

root@chroot-helper:/# ls -l /boot/efi/
total 0
here I mounted /boot/efi from outside the chroot.

Code: [Select]

root@chroot-helper:/# ls -l /boot/efi/
total 4
drwxr-xr-x 4 root root 4096 Dec  2  2023 EFI
root@chroot-helper:/# ls -l /boot/efi/EFI/
boot/      siduction/
root@chroot-helper:/# ls -l /boot/efi/EFI/siduction/
total 136
-rwxr-xr-x 1 root root 139264 Dec  2  2023 grubx64.efi

/etc/fstab

Code: [Select]

root@chroot-helper:/# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=94dfceaa-e5b3-42ac-8832-91d71f87094b /boot          ext4    defaults,noatime 0 2
UUID=9D34-76E9                            /boot/efi      vfat    umask=0077 0 2
UUID=ea26634c-dd97-4633-a98b-1b53d507e87a /              btrfs   subvol=/@,defaults,noatime,space_cache=v2,autodefrag,compress=zstd 0 0
UUID=ea26634c-dd97-4633-a98b-1b53d507e87a /.snapshots    btrfs   subvol=/@snapshots,defaults,noatime,space_cache=v2,autodefrag,compress=zstd 0 0
UUID=ea26634c-dd97-4633-a98b-1b53d507e87a /root          btrfs   subvol=/@root,defaults,noatime,space_cache=v2,autodefrag,compress=zstd 0 0
UUID=ea26634c-dd97-4633-a98b-1b53d507e87a /var/log       btrfs   subvol=/@var@log,defaults,noatime,space_cache=v2,autodefrag,compress=zstd 0 0
UUID=c61ad6d0-2d22-4cf4-ba10-31f8affdfdd4 /home          ext4    defaults,noatime 0 2
root@chroot-helper:/#

After changing the order of /boot and /boot/efi in fstab, I just tried another grub-install and update-grub

Code: [Select]

root@chroot-helper:/# grub-install
Installing for x86_64-efi platform.
Installation finished. No error reported.
root@chroot-helper:/# update-grub
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/giants/theme.txt
Found linux image: /boot/vmlinuz-6.5.2-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.5.2-1-siduction-amd64
Found memtest86+ 64bit EFI image: /memtest86+x64.efi
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Adding boot menu entry for UEFI Firmware Settings ...
Detecting snapshots ...
No snapshots found.
If you think an error has occurred , please file a bug report at " https://github.com/Antynea/grub-btrfs "
Unmount /tmp/grub-btrfs.1zS5arZJdq .. Success
done
root@chroot-helper:/#btw Memtest is loading.

The reason for the partition layout is that I want to use GRUB_DEFAULT=saved to remember the last choice in grub.
That wasn't possible with btrfs when I made the descision for the partition layout some years ago.

Maybe someone has an idea.

Cheers!

[eriefisher]

I can't comment on your partitioning scheme as I don't use it but I had similar boot issues recently and here is what worked in the end for me.
https://forum.siduction.org/index.php?topic=9161.msg72687#msg72687

As it says, I just copied all the instances of grubx64.efi to bootx64.efi so both were in the directories and ran update grub(don't know if it matters) then rebooted and it worked.

[user78]

that doesn't help, thanks.
but good to now how to create a new menu entry for EFI!

my error happens a step further down the line. EFi is loaded, but after selecting the Siduction entry in Grub the kernel is not found. I do believe it has someting to do with mount order in grub or something is wrong with subvolume mounting with btrfs.

[user78]

@eriefisher thanks for the input, it brought me on the right track.

the issue is the grub.cfg. According to this thread at the Arch forums I just found, paths need to be relative when using subvolumes. So I removed parts of the absolute path of the kernel image and it booted.

this is the grub entry created by the installer

Code: [Select]

        echo    'Loading Linux 6.5.2-1-siduction-amd64 ...'
        linux   /@/boot/vmlinuz-6.5.2-1-siduction-amd64 root=UUID=ea26634c-dd97-4633-a98b-1b53d507e87a ro rootflags=subvol=@  quiet systemd.show_status=1
        echo    'Loading initial ramdisk ...'
        initrd  /@/boot/initrd.img-6.5.2-1-siduction-amd64

and this is what it needs to look like, so that the system boots.

Code: [Select]

        echo    'Loading Linux 6.5.2-1-siduction-amd64 ...'
        linux   /vmlinuz-6.5.2-1-siduction-amd64 root=UUID=ea26634c-dd97-4633-a98b-1b53d507e87a ro rootflags=subvol=@  quiet systemd.show_status=1
        echo    'Loading initial ramdisk ...'
        initrd  /initrd.img-6.5.2-1-siduction-amd64

maybe I find the right spot in /etc/grub.d/09_siduction-btrfs to fix this?!


edit:
I changed line 32 in /etc/grub.d/09_siduction-btrfs and the vm survives and is booting after update-grub.
This solves my issue and I'll probably lock the version of siduction-btrfs package for now and see what happens there.

Code: [Select]

# Run if the root filesystem is Btrfs.
 21 if [ "x${GRUB_FS}" = "xbtrfs" ]; then
 22     if [ -x /etc/grub.d/10_linux ]; then
 23         chmod -x /etc/grub.d/10_linux
 24     fi
 25     btrfs_default="$(btrfs subvolume get-default /)"
 26     btrfs_default_path=$(echo "${btrfs_default}" | sed -E 's,[^@]*@?,@,')
 27     if [ "x${btrfs_default_path}" = "x${btrfs_default}" ] || [ "x${btrfs_default_path}" = "x@" ]; then
 28         GRUB_CMDLINE_LINUX="rootflags=subvol=@ ${GRUB_CMDLINE_LINUX}"
 29         btrfs_default_path=""
 30         subvol_default="subvolume @"
 31         dirname="/boot"
 32         rel_dirname=""
 33 #        rel_dirname="/@${dirname}"
 34     else
 35         GRUB_CMDLINE_LINUX="rootflags=subvol=${btrfs_default_path} ${GRUB_CMDLINE_LINUX}"
 36         rel_dirname="/${btrfs_default_path}/boot"
 37         btrfs_default_path=$(echo "${btrfs_default_path}" | sed -e 's,@,\.,')
 38         subvol_default=$(echo "${btrfs_default}" | sed -e 's,.*ts/,snapshot ,' -e 's,/.*,,')
 39         dirname="${btrfs_default_path}/boot"
 40     fi


[scholle1]

Did you test it with the snapper rollback command?

Code: [Select]

snapper --ambit classic rollback [nr]
siduction uses snapper rollback. The handling is different from the rollback in arch or suse.
The file "09_siduction-btrfs" is adapted to this and requires a partition layout in which the directory "/boot" is located in the subvolume of "/".

[user78]

that snapper command broke the vm. After reboot, no kernel was available in Grub.
Basically everyting from /boot was gone, only memtest was available which sits in /

that doesn't bother me tho as I'm used to timeshift and that's available and working as I expect it.
edit: removing snapper also removes the siduction-btrfs package. If snapper is the only reason for the package, I should be fine now.