Siduction Forum
Siduction Forum => Installation - Support => Topic started by: user78 on 2023/12/02, 18:57:28
-
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:
/dev/vda1 300M vfat /boot/efi
/dev/vda2 1.2G ext4 /boot
/dev/vda3 40G btrfs /
/dev/vda4 20G ext4 /home
the error:
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.
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.
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
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
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!
-
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.
-
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.
-
@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 (https://bbs.archlinux.org/viewtopic.php?pid=1821597#p1821597) 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
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.
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.
# 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
-
Did you test it with the snapper rollback command?
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 "/".
-
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.