New dual boot fix for EndeavourOS

Announcements and news
1

@manuel has worked on a fix that solves the dual boot problem that Archlinux and its derivatives are plagued by for some time now.

This feature will be shipped by default on the upcoming release, but for running Endeavour systems the feature can be installed from now on.

We have received some good results on it, but keep in mind that it is still not a stable version, so feedback is more than welcome.

To install it do the following:

sudo pacman -Syu
sudo pacman -S grub-tools
sudo pacman -S grub os-prober
sudo grub-mkconfig -o /boot/grub/grub.cfg
reboot

10 Likes
2

I added this new info to the wiki as well: https://endeavouros.com/docs/installation/grub-booting-other-systems/

8 Likes
3

Will this tool automatically be added to an existing install so that it works for everyone who already has an installation of EndeavourOS?

4

It will be added to the next ISO and fixes grub-mkconfig during install.

The instructions above can manually be executed on any existing EndeavourOS install. They need to be executed only once on an existing system.

Hope this answers your question. :slight_smile:

2 Likes
5

I’ve been trying this modification/fix on my multi-boot system, and I have a couple of anomalies to report - or to expose my ignorance with :grin:

I ran the suggested commands above, but some oddities in /boot/grub/grub.cfg resulted:

The first EndeavourOS entry was trying to load up [ linux /boot/vmlinuz-linux.png ] (which is not likely to go well - this is a .png file of the EndeavourOS logo). This same entry contains the dreaded:
[ initrd /boot/amd-ucode.img ] on its own as well. Strangely, the second entry appears to be perfect, including the double initrd entries.
The second entry was for ArcoLinux - and would boot - but does not have amd-code.img mentioned in the initrd line.
The third entry is for an pre-existing Arch - and is perfect, would boot, and includes the amd-ucode.img
The other entries are for debian based systems, and show no sign of trouble.

I then tried the same thing on Arch itself. It worked fine for Arch’s own entries (as it should!) and they include amd-ucode.img where appropriate. However, although ALL entries would boot, neither Arcolinux nor EndeavourOS had any mention of amd-ucode.img in their entries, although they have the file in the boot directory.

So - I am doing something wrong, or something doesn’t quite work, or both! Overall, it strengthens my desire to sidestep and ignore the entire grub ecosystem and use rEFInd. Comments? Enlightenment? Hope I didn’t ruin anyone’s day …

Freebird54

6

Forgot to mention in my previous post that, due to now having timeshift on Arch and EndeavourOS, and the fact that EndeavourOS is easy to re-install :grinning:, I would be perfectly happy to be a ‘remote testing facility’ if such would be useful…

Freebird54

7

rEfind …oooh i don’t think i could ever get used to that? For me i would rather just not have grub altogether and just use UEFI to boot each OS if that was possible. No splash screen or boot menu just a boot sequence that loads and you select your choice. :thinking: Isn’t this kind of already out there? I’ve always thought that grub doesn’t really belong with UEFI. Any thoughts?

8

I tend to agree about grub not fitting in with UEFI. In fact, I really like grub (legacy) back in the day instead of lilo (even had a chainload setup that gave me a boot animation!) but grub 2 has always ended up giving me trouble, despite the improvements.

I use rEFInd because it is so easy, bypasses grub or not (as you wish) and avoids having to reorder and edit UEFI NVRAM all the time - efobootmgr or no - just pick an OS logo and go! It’s even themeable, if you can be bothered (I haven’t).

Freebird54

9

The grub-mkconfig does things in a rather complex way. While generating, it seems to read existing grub.cfg files from the other existing systems. And if they already have some issues, the issues are simply copied to the grub.cfg to be generated.

So I’d try fixing the grub.cfg files on other systems first. Check if they have any issues with the initrd lines and (manually) fix the issues in those systems. And then re-generate grub.cfg in EndeavourOS.

I hope that helps. But as said, grub is rather complex.

10

BTW, I have three systems on this machine: EndeavourOS, Arch, and Antergos.
All of them generate (with this fix) fully working grub.cfg files.

But I have another boot menu generation system as well in use. It creates file /boot/grub/custom.cfg, like on top of grub.cfg.
Because of that I could stop using os-prober altogether. But so far I’m still using it…

11

Yes this is the only issue i have with UEFI and nvram. I use efibootmgr also. I don’t like that part where it keeps a list and it changes order. One of the handy tools i also use on Windows10 is easy uefi which allows you to modify the entries in the efi partition or move the boot order in Windows. This is handy and i have also used it on here to help a user get back up booting in certain situations where grub doesn’t add the entry properly for Windows.

1 Like
12

Just for the sh&^% and giggles, I’ll give that a try. I rather doubt it’ll be that simple though - after all I started the quest for better because every time I put a new system in, it killed access to my Arch setup - presumably because it MISread the (working) grub.cfg in its boot dir. If I could get your fix into all the other systems, then perhaps having it right once would work! It still is a massive PITA to have grub hijacked every time there is a kernel update on ANY of the other systems. Given that 3 of the current set are Arch-based - that’s a LOT of kernel updates! Thank heavens that rEFInd is so easy to get going!! I thought it might be complex, but apart from deciding which of the alternate boot methods it finds you want to use (for instance, most systems you can either bypass grub, or not as you choose). Mostly I direct boot the vmlinuz, and ignore the grub entirely, so it doesn’t matter who THINKS they have control, or what they generated for a grub.

I still worry a bit about grub trying to boot the logo though :grin:

Freebird54

13

Yeah - the way I run the only re-ordering I do is a press of F8 in the BIOS boot screen, and a click and drag for rEFInd to the top of the NVRAM again… Assuming some helpful dev has inserted a new entry in NVRAM when regenerating grub, of course. Or maybe they have to make it work - I haven’t decided on that point yet…

Freebird54

14

@freebird54
Would you be interested in writing a small wiki article about rEFInd in the EndeavourOS context?

15

More willing than able, at this point, I’m afraid. I have no perspective on the things that might go wrong, as so far nothing has. I was expecting far worse than I got from reading the ‘official’ information pages, but the little install script just worked - and the only thing it didn’t pick up was the correct logos for some of the distros (didn’t know Xubuntu from Ubuntu - hadn’t heard of EndeavourOS!) - but that was something that could be worked around. (see comment above about trying to boot a logo - one way of letting rEFInd know about what to display for a given boot file is to provide a graphics file, w correct extension, named to match the boot file’s root.)

I suppose I could try adding it another couple of dual boots I have around, and see if I can come up with a useful commentary. I’ll let you know - but don’t hold your breath!

Freebird54

1 Like
16

Thanks!
Even some real life rEFInd configurations (shown as examples) would be useful for people who wish to try it.
But no hurry, take your time. And if you eventually feel you really don’t want to write it, no problem, we’ll survive! :sweat_smile:

17

I just recently successfully tested dual booting WIndows 8 and EndeavourOS (BTRFSonLuks with an encrypted /boot) with rEFInd on an old Acer laptop.

  • Windows was installed first, followed by EOS and rEFInd.
  • I then changed the UEFI bios boot order to first boot rEFInd.

rEFInd automatically found and allowed booting both installed systems without the need to configure anything!
I haven’t tested adding more (encrypted) installations but can’t imagine rEFInd having any problems with this.

Although rEFInd worked out of the box I then decided to make things prettier by theming rEFInd:

  • installed theme
  • modified /boot/efi/EFI/refind/refind.conf
timeout 5

scanfor external,optical,manual

default_selection "+,2"

menuentry "Windows 8" {
    loader \EFI\Microsoft\Boot\bootmgfw.efi
}

menuentry "EndeavourOS" --class arch {
	icon /EFI/refind/themes/rEFInd-minimal-black/icons/os_arch.png
        loader /EFI/EndeavourOS/grubx64.efi
}

include themes/rEFInd-minimal-black/theme.conf

What these config entries do:

rEFind will now not scan and automatically insert found systems from (internal) hdd/sdd. I therefore added the manual menu entries above simply to force rEFInd to use an Arch logo for EOS.

rEFInd will automatically boot the last chosen system, or if it can’t find that information, the 2nd entry (EOS) after 5 seconds.

3 Likes
18

Thanks! That’s really nice and simple way dual booting with Windows.

Maybe we could collect real life examples from several users into a wiki arcticle?
And add some “official” eEFInd links, then people can understand the examples better and try some at home! :sweat_smile:

2 Likes
19

What’s the easiest way to get some email to you - or the wiki? I have a first pass at something that might work out for you, but would prefer a little more testing first, then a little more refinement too :grinning:

Freebird54

20

The easiest way is to send a private message to me in this forum.

1 Like