Hi all
Is it possible to install EndeavourOS using BTRFS and snapper and systemd-boot? If so, can someone please explain how to do this?
Thanks
You can install using systemd-boot with btrfs in the installer. You can then install snapper and setup snapshots.
However, you can’t setup snapshot booting with systemd-boot.
You can first install systemd-boot in the installer.
If you’re looking for a Snapper boot solution without Grub, Limine bootloader in combination with two extra tools limine-snapper-sync and limine-dracut-support-git, provides this functionality.
This Limine setup can be compatible with some parts of the EOS pre-config of systemd boot.
Both systemd-boot and Limine follow a similar philosophy, avoiding the inclusion of many bloated drivers, unlike Grub.
2 Likes
I only had the option to install grub or ‘no bootloader’
Does your device use BIOS legacy instead of UEFI?
That means you legacy booted the ISO.
Make sure you boot in UEFI mode.
I’m currently using GRUB, as it is default for BTRFS after EOS installation.
You mentioned that Limine can support booting the immutable system, now I’m curious to try it out.
Can I switch directly from GRUB to Limine, or do I have to install Systemd-boot first before switching to Limine?
default set on installer is always systemd-boot on efi installs… only in case you are running older Bios system or boot system in legacy CSM mode it will default to grub… and only grub there no related to used filesystem.
Read here:
https://discovery.endeavouros.com/installation/live-iso-tricks-tips/2021/03/
That’s not what I saw.
During the EOS installation I was given a choice: GRUB for BTRFS snapshots, Systemd-boot or no bootloader. Since Systemd-boot doesn’t support BTRFS snapshots, I chose GRUB as the default for BTRFS snapshots.
It is only about bootable snapshots from bootloader menu, snapshots themself are not related to the bootloader.
Question is if it was only this options shown up for you:
This would indicate what @dalto already mentions about legacy boot … were it will not offer systemd-boot option.
run efibootmgr on ISO livesession terminal will show an error if not in EFI mode.
How large is your grub partition?
The limine setup requires a grub partition larger than 300 MB. However, it allows you to configure a maximum number of bootable snapshots, e.g., 1 or 2.
You don’t need to uninstall grub as Limine allows you to have both bootloaders in the same ESP path /boot/efi without restriction of Limine setup.
If you use EFI mode, here are some steps:
- Install
limine-dracut-supportandlimine-snapper-sync - Edit
/boot/efi/limine.confto add the keyword//Snapshotsto your OS entry block. - Enable the service with
systemctl enable --now limine-snapper-watcher - Reinstall
limine, it will be automatically deployed to the ESP by the tool.
Optional:
If you want to configure your kernel cmdline manually, copy it from /etc/default/grub to /etc/kernel/cmdline and configure it there, then run dracut-rebuild.
If you want to disable kernel fallback to reduce ESP usage, edit /etc/limine-entry-tool.conf to set DRACUT_FALLBACK=no
If you want to limit the maximum number of bootable snapshots, edit /etc/limine-snapper-sync.conf to change LIMIT_NUMBER=8 to your preferred number.
Who still wants to use an legacy BIOS mode in 2024? If so, I think Limine and limine-snapper-sync should support that, but not limine-dracut-support only for UEFI and x86_64.
1 Like
1GB, it was default after EOS installation.
The last three steps worked except for the first step gave me a yay error claiming a conflict with eos-dracut. To resolve it, I had to uninstall eos-dracut.
Now Limine can boot into snapshots very faster than GRUB, thanks! But I notice that it doesn’t prompt me for my password even though I’m using encrypted BTRFS. Why is that? How can I activate the password prompt back?
Do I need to configure the kernel cmdline to activate the password prompt?
Because this is default EOS setting for grub thing.
It puts your key file like your clear password into your initramfs if you chose grub in EOS installer.
This is why the initramfs automatically unlocks your encrypted partition, preventing a second password prompt at boot. This behavior is expected for many grub users who do not want to type the same password twice at every boot.
Remove your key file name from /etc/crypttab and check for any dracut configs in /etc and /etc/dracut.conf.d/ to see if they contain your key file name, then remove it. After that, run dracut-rebuild.
No, it has nothing to do with the kernel cmdline.
1 Like
Ah, I thought Limine had bypassed my encrypted BTRFS, but it turns out it was just the default EOS setting auto unlocking it for GRUB, that is crazy.
Thanks for the clarification!
I deleted all key files in /etc/crypttab and /etc/dracut.conf.d/calamares-luks.conf
Now the password prompt works exactly as I needed.
I am really grateful for your straightforward instructions of Limine. 
It is because the installer placed the initrd in an encrypted location. Grub itself is unlocking the luks partition to access the encrypted file.
If you move the initrd to an unencrypted location, you need to change the config as you discovered.
I have been trying out Limine for 3 days up until now, and it works flawlessly, fully meeting my expectations. It has an easily customizable theme, booting with encrypted BTRFS faster than GRUB and simple one-click snapshot restoration. 
I am looking through the contents of limine.config and trying to understand it. Each boot filename has a long random string of numbers, like this:
kernel_path: boot():/eb7646b9f1f141d1904cae0cc20edb87/linux/vmlinuz-linux#c50ea68cc3142a4fbf96508425bdc01295232ab245321cfe1a51721c09e72668bddd33c8c6f2eac71cf7b39420ab142316fbd273f954e342cc4321d6de901f56
What are these numbers? Is it possible to remove them without causing a crash?
1 Like
That is Blake2 checksum. This is a part of standard coreutils and is automatically generated by limine-dracut-support.
Limine with Blake2 verifies each bootable file before booting, preventing booting your system if a kernel file is corrupted or tampered on ESP with insecure standard FAT32 (FAT32 has no permission, no checksum, and is visible and accessible to all other systems), without needing Secure Boot signing.
You can disable the checksum by ENABLE_VERIFICATION=no in the file /etc/limine-entry-tool.conf.
However, this is not recommended, as a kernel is a critical core of your system.
I can imagine that booting with a corrupted kernel without verification, especially with bit errors, could cause more harm to your system or kill filesystems.
I have not noticed any performance impact when enabling or disabling the checksum on a mid-range CPU during booting.
1 Like
Now I get why the checksum is important, particularly for protecting the system against a damaged kernel on an untrusted ESP during boot.
I leave it enabled by default. Thanks for the explanation!