I feel like @limotux wrote in a few posta lately: systemd-boot is (for me) simpler than Grub (I didn’t look at rEfind). Following his experience AND @dalto great tutorial I have switched 4 machines to systemd-boot (3 with BTRFS - 2 of them with LUCKS, 1 with Ext4) and I don’t look back.
Very happy with the change. I have lost the option to boot directly in a BTRFS snapshot but as @dalto explained it is not an issue as I always can chroot from a live usb and restore if I get to this.
Just sharing my own experience, and this community is REALLY a gem !
2 Likes
feel like switching to systemd-boot might be a wee bit of a knee jerk reaction to jump ship from grub the first time it stuffs up/ gets improperly tested or (or whatever the case may be)… it was something I hadn’t done before so it was a good excuse & to be fair who knows what the next thing to bork systems will be
Shame I’m seeing people put the blame on endeavour on reddit etc
The guide on the forums worked a treat for me.
3 Likes
looks like you already try some mount so system is in unclean mount state… you best go to reboot into the liveiso session and start over.
Hello there, sadly I cant fix my issue, because I am not able to use chroot like mentioned here.
sudo fdisk -l [...] type
/dev/nvme0n1p1 EFI System
/dev/nvme0n1p2 Linux filesystem
/dev/nvme0n1p3 Linux swap
After sudo mount /dev/nvme0n1p2 /mnt
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
sudo arch-chroot /mnt
I get the following:
mount: /mnt/proc: mount point does not exist.[…]
==> ERROR: failed to setup chroot /mnt
Has anybody a remedy for this issue?
EDIT:
Nvm I have an btrfs installation, I followed the steps and now I was able to chroot. sadly I still got an error using grub-install: error: cannot find EFI directory
EDIT2:
I got it fixed, EFI partition was unmounted for some reason although I just mounted it before chrooting.
Thanks for explanations in this thread!
The manual intervention post worked perfectly for me on my btrfs setup. I might make it a habit of checking the forum while updating because I updated a couple days ago and just got around to rebooting this morning and could have saved myself about 30 minutes by running sudo grub-install prior to rebooting.
ok new grub the -3 is in testing 
1 Like
Just got installed Grub from Testing:
(1/1) upgrading grub [########################################################################################] 100%
:: To use the new features provided in this GRUB update, it is recommended
to install it to the MBR or UEFI. Due to potential configuration
incompatibilities, it is advised to run both, installation and generation
of configuration:
$ grub-install ...
$ grub-mkconfig -o /boot/grub/grub.cfg
I don’t recall having seen this message before when updating Grub. Good it’s there now to avoid future similar issues as we have seen here lately.
4 Likes
It looks like the partition is either mounted or already unlocked. Try rebooting and then following the instructions.
Unfortunately, it seems like the path selected was to add a message that informs people to run grub-install. That is the only change I can see in this package.
better to add grub-install hook in grub-tools for grub upgrade standard of is it dangerous ?
I don’t think so. Blindly running grub-install can break things because we don’t know what the configuration is on the target system.
- Some people aren’t using a different distros grub as the primary so this could break their multi-boot setup
- Some people have more complicated configs like secureboot shims and other complexities
- Some people have the grub package installed for other reasons but aren’t using grub to boot their machines. That would literally overwrite their bootloader every time grub updated.
I am sure there are way more scenarios than that.
It would be different if we were a highly opinionated distro that basically said “Use the distro our way if you want support”, but we aren’t. We are more about giving people a starting point to configure the system however they choose.
1 Like
i have this result .
then a notification is proper ?
That is an unsatisfactory fix. What about people who do new online installs? Does the online installer run grub-install after downloading and installing the grub package?
They aren’t affected. Many of us did test install to verify that.
This issue only happens on existing I installs.
Only user with a previous version of grub are impacted. If i don’t make a mistake, online install is safe but not the offline who install a older version.
Why are you running mount /dev/sdXn /mnt? That is just an example. Didn’t I give you the exact commands to run for your install above?
Proper is in the eye of the beholder I suppose. In my opinion, it depends how the grub devs see this issue. If they see this as a normal part of the way forward for grub then there isn’t much alternative. Unrolling that commit would just create more pain later. On the other hand, if the grub devs are undecided or are planning to revert the change, it would make more sense to revert the commit for now.
Of course, that is all just my personal opinion.
It isn’t a fix at all. 
Of course, the installer has to run grub-install after installing grub.
I followed the instructions for GRUB on my laptop some days ago and it worked fine, but now the command in the post has changed. Is it safe to use? I want to do it on my desktop.
Nvm, it worked.
1 Like
I followed these instructions>>
https://discovery.endeavouros.com/system-rescue/arch-chroot-for-efi-uefi-systems/2021/03/
there are others?