No, that sequence will stay the same. It is safe to put that sequence in loader.conf.
The Arch wiki is using a manual approach where you hand create the conf files when you add or remove kernels.
We use an automated tool called kernel-install that is part of systemd itself. It automatically creates and deletes the conf files as they are needed and it manages the names.
The reason the names contain the machine ID is so that if you are booting multiple distros the entries can be differentiated.
I recently reinstalled EOS on a laptop and noticed that systemd-boot seems to now be the default (i.e. pre-selected) option. My desktop is still using Grub so I started looking into this and found this thread.
At the top, in the update of 12/22/2022, it is stated that:
On the other hand, simplicity comes with limitations:
It only supports UEFI
It doesnât have all the advanced features of grub
Your kernels must be kept inside your efi partition so it needs to be large enough to hold them all
Because of the above, booting directly from btrfs snapshots is not easily achieved
Now, my desktop uses UEFI and has a large EFI partition so the first and third bullet Iâm not worried about. The other two I was hoping to get an update on:
My root file system is BTRFS and I use snapper and grub-btrfs to make my snapshots bootable. Therefore the last bullet is an issue for me. Has any progress been made on that front? I can easily extend the size of my EFI partition as needed, but is it now feasible to have bootable snapshots with systemd?
What âadvanced featuresâ of grub are still missing? Is it something superficial like âthemesâ or is there anything significant missing?
If you want to you can set up a custom.cfg file with Grub to add custom settings, menu entries, scripts, etc which can extend and customize the bootloaderâs behavior beyond what systemd-boot supports. Grub can be configured in kind of a modular way with the /etc/grub.d directory as well, for tying in scripts or other processes with the boot routine.
Grub can also chainload bootloaders; Iâm not sure if systemd-boot supports that. There are also difference with how the two bootloaders handle encrypted setups or rescue mode (Iâm not sure if systemd-boot has a dedicated rescue mode per se).
systemd-boot is in general a much leaner, simpler bootloader so does not have quite as many features available. Features are nice, but many people do not need all the features Grub offers. Plus Grub has a long and storied history of breaking when people do not properly handle its maintenance.
Still: if booting off of Btrfs snapshots is important to you I would recommend you just use Grub.
It isnât really a feature gap, it is just a side effect of the way it works. Since the kernel and initrd are outside the snapshot, it causes a problem if you try to boot off a snapshot tied to an older kernel.
There are workarounds but they add more complexity than they are worth. If you want to boot off snapshots, just use grub.
Lotâs of things. Grub is a substantial piece of software. systemd-bootâs advantages are in itâs simplicity.
Theming
Grub supports submenus and fine grained control of the menus
Grub has built-in filesystem drivers
Grub can boot from multiple physical devices
systemd-boot can chainload. It is trivially easy to configure too.
Is there any actual use-case for grubâs rescue mode on an Arch-based distro?
I would agree itâs probably faster and easier to fix anything that can be fixed from Grubâs rescue environment in a chroot from the live environment instead, if thatâs what you mean. I guess an actual use case would be if you have no USB stick handy?
I did not say it was a very excellent, highly useful featureâI only said it was a feature.
Just a note. That is extreamly bad practice to pipe downloaded script directly to bash. It is alway recommended to download it as a first step, inspect it and then run it.
Althout it may be from a trustworthy source you may never know if it contain something nasty inside.
I think openSUSE might be working on something like that for systemd-boot: sdbootutil
There was this long article a while ago: https://news.opensuse.org/2023/12/20/systemd-fde/ and they mentioned sdbootutil under the systemd-boot sub-heading in the text.
Is it possible to directly install systemd-boot in chroot and donât use grub at all ?
I tried a terminal install and afterwards booted the system with grub.
The conversion worked perfect bit just curious if it is possible to do a terminal install and donât use grub at all
This tutorial was written for people who had old installs before the installer supported systemd-boot. Now you can directly install systemd-boot via the installer.
You can choose âNo bootloaderâ if you donât want to install grub and then install your own, yes.
thanks @dalto
I know i have the option âno bootloaderâ in the installation procedure.
What i actually mean is an installation directly from the iso terminal.
create partitions
make filesystems
make subvols
mount @
make dirs in /mnt
mount efi
mount subvols
do a pacstrap and genfstab
chroot
exit and reboot
I used to grub install in chroot however donât want to use it but where does systemd-boot fit in ?
If you are installing EOS, you should add dracut to your pacstrap. Mount your EFI partition to /efi. The run bootctl install from the chroot. Next install kernel-install-for-dracut. Lastly, reinstall your kernel packages.
echo "nvme_load=YES nowatchdog rw rootflags=subvol=/@" | sudo tee -a /etc/kernel/cmdline
Determine the UUID of the root filesystem
ROOT_PARTITION="/dev/sda2"
ROOT_UUID=$(blkid -s UUID -o value $ROOT_PARTITION)
Add the root UUID to /etc/kernel/cmdline using sed
sudo sed -i "s|subvol=/@|subvol=/@ root=UUID=$ROOT_UUID|" /etc/kernel/cmdline
reinstall-kernels
set entries /efi/loader/loader.conf and adjust files in /efi/loader/entries *.conf
echo "default $machineid*" | sudo tee /efi/loader/loader.conf
echo "timeout 3" | sudo tee -a /efi/loader/loader.conf
echo "console-mode auto" | sudo tee -a /efi/loader/loader.conf
sed -i 's/quiet//g' /efi/loader/entries/*.conf
exit ...
umount -R /mnt;systemctl poweroff
Noticed that is my default eos install the entry rootflags=subvol=/@ UUID occured three times.
No big deal however.
Hopefully one day you write a fresh tutorial systemd-boot for a minimal eos.
These files get replaced every time a kernel updates.
You should make the changes in /etc/kernel/cmdline instead.
That was a bug in an older version of the installer. It wonât hurt anything to leave it but tou can fix it by removing the dups from /etc/kernel/cmdline.
Is this tutorial still covering the current mercury release ?
When i test a minimal mercury install from terminal i noticed no /etc/kernel/cmdline and /proc/cmdline still has grub entries in /boot/@/grub
