If "Boot0000* Linux Boot Manager is still available you should still be able to boot using systemd boot also because you still have the systemd directory still under efi.
BOOT EndeavourOS Linux systemd
In what order did you actually install your dual-boot Windows EndeavourOS setup, what did you select during the EndeavourOS install, just trying to see if I can get your dual-boot setup working in a vm with grub?
I had windows already installed on a separate drive, then did a very default install of endeavour. Never had any issues and windows hasn’t been a part of either boot menu.
So you weren’t able to select between Windows and EndeavourOS when you had the systemd-boot setup, if that is the case that both efi files of both oses were probably on different partition but I actually haven’t dual-booted in years. Were you able to get systemd-boot working again by selecting Linux or something like that as boot device from within your Uefi?
Different harddrives, so definitly. And yes, if I boot into uefi it goes thtough the old systemdboot and works
At least you can boot normally and get to your files, I hope you are still able to boot your Windows install as well. What made you actually want to switch from systemd-boot to grub?
There’s a lot more info out there fir grub and I’d have an easier time customising it. When I was last stuck out my system it was hell trying to get support since systemdboit just isn’t that common.
The EndeavourOS developers made systemd-boot default for a reason, from what I’ve read it’s less likely to break during updates than Grub. So from my understanding there will be plenty of people able to help you here on the forums.
I don’t use EndeavourOS on my setup but I have setup systemd-boot myself but from my short experience with setting it up it seems a lot simpler than grub.
Having a think now, does anyone know what would happen if I were to install a second copy of endeavour to the same drive, this time with grub selected, and then just migrate everything over? I don’t know what takes priority with these things or how it handles duplicates.
Also, do we actually know what’s going wrong here? Obviously we don’t know the exact problem, but I don’t actually know where the problem resides.
I don’t know why it is not working. Grub is much more capable and much more complex than systemd-boot, to the breakage surface is much larger too. I’m having my own problems with grub, but totally different ones, that I will sort out eventually.
My laptop currently has eos ext4, btrfs and 3x zfs at the moment, they all run fine, but they are all running grub, and I want them running grub, eventually in a zfs boot pool. I have a virtual machine with systemd-boot and grub partially installed, having trouble with grub-mkconfig after converting from systemd. I will win that eventually. The grub install does however successfully show a menu for firmware setup and can start it, so that efi boot of grubx64 works.
I don’t see why you can’t install another grub based EOS. Deciding how to share the disk will probably be biggest problem.
The EFI boot partition looks like this;
$ find /efi -type f|grep -v fallback
/efi/EFI/systemd/systemd-bootx64.efi
/efi/EFI/BOOT/BOOTX64.EFI
/efi/EFI/grub/grubx64.efi
/efi/loader/entries/endeavousos-6.1.38-1-lts.conf
/efi/loader/entries/ext4-6.1.38-1-lts.conf
/efi/loader/loader.conf
/efi/loader/random-seed
/efi/loader/entries.srel
/efi/endeavousos/6.1.38-1-lts/initrd
/efi/endeavousos/6.1.38-1-lts/linux
/efi/ext4/6.1.38-1-lts/initrd
/efi/ext4/6.1.38-1-lts/linuxTo boot from UEFI you need the following:
The grub install will use /efi/EFI/grub/grubx64.efi
The systemd-boot will use /efi/EFI/systemd/systemd-bootx64.efi
systemd-boot has the loader .conf for each install, and the initrd and linux as seen in /efi/*/*/{initrd,linux}
grub has it’s configuration file in /boot/grub/grub.cfg, and the partition and boot path is compiled into the grub image in /efi/EFI/grub/grubx64.efi. This depends on you partition structure, but the view from linux is /boot for initrd and linux and /boot/grub/grub.cfg for the configuration for the menus to select what to boot.
So in the EFI partition there is no overlap between the two.
Selection of systemd or grub is at the UEFI level, and systemd seems to use the name ‘Linux Boot Manager’ and by default under EOS grub will select a bootloader-id of EndeavourOS, so there isn’t a conflict there. You can see these names and the ordering by using efibootmgr and you can also reorganize with that too.
Interactive selection of systemd/grub depends on the UEFI on the machine as to how hard/easy it it. My laptop I press F12, and can select which to start, or I can go into BIOS and reorder them too. YMMV.
As I said, deciding how to split up your disk, and implementing that manually or with something like gparted might take more time than the second install. But if you just want to shrink the existing and then make a new one that should be relatively easy simple. Ongoing dual booting more of a problem to organize the layout. If you have an empty partition setup, then you can just select the replace partition option for the second install.
Things can go sideways though, so a backup is always recommended of user data, and I like to have a backup of /etc if I need to pull configuration data, ssh keys, etc
Thanks for the breakdown. I’m not sure I get all that but it’s clear enough I just need to look at it longer. I’ll have to have a think on doing the second install method like you said. Seems like a nice way to make sure it’s clean and working, then just get rid of the old mess.
I just checked my efi boot partition, and it looks a little different. Three main things is it contains a bunch of old versions, grubx64.efi is inside of EndeavourOS instead of grub, and endeavousos is instead just the uuid it’s on. I wonder if any of this might be affecting things? Mostly that second one.
/efi/EFI/systemd/systemd-bootx64.efi
/efi/EFI/BOOT/BOOTX64.EFI
/efi/EFI/EndeavourOS/grubx64.efi
/efi/loader/entries/8c6ddbcf35964d33850a9d32bf6b3565-6.4.4-arch1-1.conf
/efi/loader/loader.conf
/efi/loader/random-seed
/efi/loader/entries.srel
/efi/8c6ddbcf35964d33850a9d32bf6b3565/6.2.6-arch1-1/initrd
/efi/8c6ddbcf35964d33850a9d32bf6b3565/6.2.6-arch1-1/linux
/efi/8c6ddbcf35964d33850a9d32bf6b3565/6.2.8-arch1-1/initrd
/efi/8c6ddbcf35964d33850a9d32bf6b3565/6.2.8-arch1-1/linux
/efi/8c6ddbcf35964d33850a9d32bf6b3565/6.4.4-arch1-1/initrd
/efi/8c6ddbcf35964d33850a9d32bf6b3565/6.4.4-arch1-1/linux
I trimmed mine a bit.
The 8c* entries are just your /etc/machine-id. I told systems to use a name instead, shorter and more meaningful especially when testing lots of installs.
Looks like you only have a loader entry for 6.4.4, so the other older folders need garbage collecting, unless you want o keep them around and manually edit the loader config when booting, or you could construct new loader entries for them, the loader conf are just a simple text files, short an easy to look at.
If by second you mean BOOTX64.EFI? that is just a default boot entry, and is also used for removable media ie ISOs. It is probably a duplicate of an existing entry, check the modify time for a hint, and you can use a checksum to verify the same content.
$ find /efi -type f -ls | grep -i '\.efi$'
$ find /efi -type f | grep -i '\.efi$' | xargs -r md5sumI just checked my VM system and bootx64.efi and systemd-bootx64.efi have the same checksum and modify date.
The thing to remember about the EFI partition is it really isn’t that special. It is just a FAT32 file system with some semantics. If you follow the semantics then things work. I’ve been manually hacking the VM EFI partition lots to clean it up and make it easier to understand.
One question about grub that may be relevant, what is the package version? There were recent issues, and some updates. I’m looking at some other grub issues, and wondering if grub version is involved myself.
By second I meant the second thing mentioned, being the different location for grubx64.efi. Looking around a bit more though I’m not sure that’s actually too unusual. Regardless, I would like to cleanup those old entries. They’re only there because I have screwed up this machine enough times that updates haven’t been a clean process. Not sure how to fully clean though up though.
I also got the latest version of grub, 2:2.12rc1-1.
I ran those two checks and found something interesting. the grub one returns a different number than the other two
$ find /efi -type f -ls | grep -i '\.efi$'
40 92 -rwxr-xr-x 1 root root 92160 Jul 21 05:33 /efi/EFI/systemd/systemd-bootx64.efi
36 92 -rwxr-xr-x 1 root root 92160 Jul 21 05:33 /efi/EFI/BOOT/BOOTX64.EFI
38 136 -rwxr-xr-x 1 root root 139264 Jul 27 13:44 /efi/EFI/EndeavourOS/grubx64.efi
$ find /efi -type f | grep -i '\.efi$' | xargs -r md5sum
91e139c5fb905625ca6d178c3fa19c4d /efi/EFI/systemd/systemd-bootx64.efi
91e139c5fb905625ca6d178c3fa19c4d /efi/EFI/BOOT/BOOTX64.EFI
4b9377fca54342e15630ca013c741688 /efi/EFI/EndeavourOS/grubx64.efi
That is expected, they are very different programs. A good checksum, and md5sum is only average now, too old and weak, is a good way to compare the whole file but just getting one small number to compare for equality, rather than reams of binary data in this case if they were different and we tried to use the diff program. Note also that systemd-boot is smaller, as less capable than grub.
I was just looking at my VM, and upgraded it, it has been a while, so I got latest the grub, then updated:
Grub menu loaded after reboot, and then booted EOS as instructed. So that is one success for systemd-grub conversion. I still have to tweak the package mix to get the automation working, but grub booting the kernel/initrd is working in my books, even if there was a lot of manual setup as I;m learning my way around systemd-boot and arch/EOS.
This doesn’t directly help you of course, but may give you a little more confidence that things can work.
It’s infuriating because I know it’s going to be some small simple thing that needs to be changed, and I have no idea what I’m doing so I just have to wait and hope some other kind user will have the right idea and walk me through it. I’m trying to learn how this all works but I really am in over my head at the moment, so a lot of it - including the steps you just ran through - aren’t making sense to me yet. I’ll be a while quite a while before I can get anywhere with this myself.
Still trying to figure it out with my uefi vm but after switching my vm from systemd-boot to grub, grub is recognized but it doesn’t recognize my virtual disk. So not even getting to the part where you are stuck on.
I got it to work now, now just have to do a fresh install with systemd-boot and convert to grub again to test it out again.
For my testvm I followed the exact steps @dalto mentioned before.
However with my testvm after running the last step when generating the grub menu my kernel image wouldn’t show up in the output. So I reinstalled my kernel.
sudo pacman -S linux
Then I ran grub-mkconfig -o /boot/grub/grub.cfg again and my kernel image showed up in the output. When I then rebooted the grub menu show with both firmware and kernel options. Then it booted straight into my system without hanging trying to load the root filesystem. I know dracut-rebuild generates a new initramfs image and fallback image, but maybe reinstalling the “linux” package triggers something more?
Here’s my exact steps just to share my output:
sudo pacman -R kernel-install-for-dracut
sudo pacman -S eos-dracut grub
cat /etc/kernel/cmdline
sudo vim /etc/default/grub
sudo grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=EndeavourOS
sudo grub-mkconfig -o /boot/grub/grub.cfg
sudo pacman -S linux
sudo grub-mkconfig -o /boot/grub/grub.cfg
sudo reboot
I know my problem with my testvm is a bit different as in the kernel image not getting recognized by grub but maybe it’s worth a try just to see what happens.
IT WORKED! Thank you so so much for spending so long trying to replicate and fix this issue.
Turns out yes, something extra was needed that came from reinstalling the kernel. Don’t know what, but it’s a good reminder to try reinstall what you can just to make sure there’s nothing they need to do left unupdated.