Yeah, still a newbie – certainly with EndeavourOS and maybe even still with Linux. So, I’m claiming that status. Please bear with me here because this will get to EndeavourOS.
I’ll spare you some of the details but I already had EndeavourOS installed on a Lenovo Flex 3 alongside Manjaro (and the original Windows 10 the laptop came with). All was well (other than a “burp” you all experienced with Deepin a few weeks ago).
Then, over the weekend, I decided to replace Manjaro with Ubuntu Kylin. It was meant to overwrite Manjaro in the same partition but the installer notified me “Partition does not start on physical sector boundary” and suggested I make some sort of change to that partition or delete it and re-create it with the proper “placement” (I have since been told that this notification was not really important). I deleted the partition but then I realized I was out of my comfort zone so I backed up a step or two in the installer and selected Install Alongside.
It turns out that because I back up instead of continuing, the installer never went through with the deletion. As a result, Manjaro still appeared in the GRUB menu. So, I was able to delete the partition then I updated GRUB and re-installed it. With that, Manjaro was no longer in the GRUB menu.
But just this morning I discovered that the primary entry in that menu for EndeavourOS doesn’t do anything but produce a black screen. When I choose Advanced Options for EndeavourOS, the first choice there ("with kernal Linux (on /dev/sda8) also does nothing but take me to a black screen. But the second choice there (fallback initramfs) boots all the way through to the desktop and what appears to be a fully functioning OS.
What do I need to do to update or modify things so that the main choice for EndeavourOS on the GRUB menu works again?
I am very new to EOS but I found this Wiki article that you could use to repair your Grub (if your system is UEFI; there is one article about how to repair Grub for Legacy system too):
But if you can boot into your system, you can try first:
Right, indeed it did! Interesting explanation, too. Thank you!
So…hypothetical situation: if I had, say, Manjaro already installed…and then installed most any flavor of Ubuntu, with “last will be first” resulting in an Ubuntu-generated grub menu…the result would be the same as far as correctly detecting Manjaro boot? Would that be only for Ubuntu distros or would it extend to Ubuntu-derived distros, as well?
Right now, it will be true of most distros that aren’t Arch-based. I think there are only a handful of non-arch based distros that can correctly boot an arch-based distro using grub.
If you want to regularly install a bunch of distros and multi-boot you might consider installing refind as @csteinforth suggested.
I hope by now the majority of my distro hopping (via 3 separate laptops/netbooks) is over and I’ve settled down with what I like! But I’m sure that’s good advice and it’s worth a look-see.
Or, as I seem to have discovered…in a multi-distro situation, always install the Arch-based distro last, right?
That is usually wise. Am alernative is to use separate drives for each. Then only have one drive a a time connected to the system when Installing each distribution. This way you avoid grub issues and although an additional step and not for the lazy, you can select the distribution of choice from the boot menu in the bios.
That wouldn’t matter that much in a UEFI system. You can always get into firmware setup and change the order of the boot devices. Give the first priority to the Arch(-based), boot into that one and update grub. You could have done this now as well. I just missed the fact that you were using Ubuntu’s grub to boot EOS.
You can use your file manager and look inside /boot/efi/EFI folder. There you will find folders from each of your installed systems containing the bootloader. In your system there should be one from EOS and one from Ubuntu.
Well, yeah, it happened again…with nothing more than a fairly extensive update from Ubuntu. When I re-booted (per instructions) to make the update “take hold,” I found myself with Ubuntu Kylin’s grub menu and, as before, for EndeavourOS I have to select the second choice under Advanced Options (fallback initramfs) and from there EndeavourOS runs fine.
Kind of a pain but, hey…[shrug]. If this is going to happen as long as there is an Ubuntu distro sharing this device, I might as well learn to live with the Ubuntu grub menu.
Ubuntu tends to change the boot order in bios when there is an update to it’s grub. You would need to go into bios and change the boot priority and set EnOS first. Reboot into EnOS and update the grub. At next reboot you will get EnOS’ grub menu.
I would look at the BIOS, and see if I could change the ‘boot order’ entry there from the NVRAM. Most of them are accessible from F8, and would allow you to select EndeavourOS as the ‘controlling’ grub to boot from.
There are other ways to change the boot order (research efibootmgr for instance) if required, but try that first…
Edit: Can’t type fast enough!
Edit 2: (insert plug for rEFInd as an alternative to grub fights )
Sounds like you have Ubuntu in charge of booting, right?
To fix this, set EndeavourOS to be in charge of booting. If you have an UEFI machine, that can be done in the BIOS.
@manuel, @freebird54, @pebcak, thank you! I did exactly that: changed the boot order in the BIOS settings of the Lenovo Flex 3.
My lingering question is that earlier in this thread (on the occasion of this happening when I installed Ubuntu Kylin and EnOS was already there (only to get shunted aside in the boot process), I made the comment that my takeaway was than whenever a single device was going to have both an Ubuntu distro and an Arch-based distro, the Arch one should be installed last. And @BONK replied “That is usually wise.” Indeed, an online buddy of mine gave me the same advise (after the fact).
But clearly the installation order is not enough if, as I just saw, an Ubuntu update can be serious enough to put its GRUB first, as if it was re-installed. So, does the change via the BIOS that you all pointed me to make this order permanent? Or is the next serious Ubuntu update going to juggle things again?
I am afraid that this might be the case. I have got Ubuntu on a disk with a couple of other GNU/Linux systems and every time there has been an update to Ubuntu’s Grub, like after an update to a kernel, it tends to change the boot order in Bios. So I have had to mend it “manually”.
Or, as it has been suggested above, you could look at how to useefibootmgr in order to change the boot order in a terminal. Please exercise due caution when using the command line.
That’s a case where, with my low Linux skills, the solution might very well be worse than the problem!
Nah…I’ll just re-set the boot order in BIOS whenever it happens. I mean, since installing EnOS (putting its GRUB into the default) I’m sure I’ve done a half-dozen or more updates of Ubuntu Kylin and I guess they were “lightweight” enough that nothing changed with the GRUB. So (or so it seems), these kinds of massive updates are few and far between.
