UEFI install strangeness

General system EndeavourOS installation
1

I’m still in the process of getting familiar with setting things up under UEFI instead of CMS. I have a Lenovo T420 which has Windows 10, MX 19.1, and EOS. While testing the new ISO, I installed a second copy of EOS, using the online installer. Used Plasma instead of my normal Xfce. Didn’t like Plasma much, and since I wanted to do a normal Arch install using UEFI boot, I decided to wipe the EOS Plasma install and put a pure Arch install in its place.

Basic install went fine, installed Grub and rebooted. Which is where the strangeness starts…

When the machine rebooted, I got boot options for Win10, and EndevourOS. Nothing for MX or for the new Arch install. When I selected EOS, I ended up in the new Arch install, just to really confuse me. Attempting to rerun grub-mkconfig did nothing except lose me the Windows 10 option.

When I looked at the firmware boot option, I could see entries for Win, Arch, EOS and MX. Both the Arch and EOS entry boot the new Arch install. Booting MX gets me the MX grub, which gives me a working entry for EOS. So I have no idea what is going on…

As a temporary step, I installed reFind, which gives me Win, EOS, MX and a Grub entry. EOS starts the pure Arch install, as does the Grub entry. MX gives me the normal MX grub selections, which does allow me to boot to EOS. So I’m not at all sure that I know what is going on.

I’m just wondering if it is the way I installed grub to the new Arch install that is causing the problem. This is the command I used (pretty well straight from the Arch Wiki):

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB

I’m wondering if the confusion has been caused by my using “GRUB” as the bootloader-id rather than something like “Arch”, though I’m far from sure that could do it. Since the second EOS install seems to have used the existing /boot/efi/EFI/EndevourOS directory, which would have pointed to the partition on which I’ve now installed Arch, could that cause this sort of problem?

As another question, is there a safe way to delete the copy of Grub that I installed for Arch (so I can reinstall it using Arch as the bootloader-id? In the past I’ve had some problems removing boot entries from NVRAM after making changes to Grub installations in a UEFI environment.

:slight_smile: I guess its one way of learning, but it is taking a bit more time than I’d hoped…

2

Hello @toothandnail
Welcome. Were all your previous installs Win10, MX, and EOS done as UEFI installs and are they all on the same disc?

Edit: Did you run the sudo grub-mkconfig -o /boot/grub/grub.cfg after install of grub? EndeavourOS has grub-tools and os-prober so if you boot into the original EOS you had installed and check that these packages are installed you could run it there and it should pick up the installed OS and add it to the grub.cfg. CSM is a compatibility support module that allows booting and installation of BIOS method if you were doing that. If you change UEFI setting to UEFI only that wouldn’t matter if everything is installed in UEFI mode using GPT partitioning.

Edit2: Hopefully you have secure boot and fast boot disabled in UEFI? The reason i ask is because if you change settings in UEFI sometimes it gets turned back on. Also in Windows 10 you should have fast startup turned off which is a feature of Windows that uses hiberfil. It doesn’t work too well booting with Linux.

3

Hello Rick

Yes. I installed the latest firmware for the T420, set it to boot UEFI first, created the EFI partition from a live boot, installed Win10, then MX, then EOS. When the latest iso came out, I had some problems with the live installer on my main laptop, so I tried another EOS install using the live installer (Plasma DE). When I went to do the standard Arch install, I used the EOS-Plasma partition (first time I’ve tried anything KDE related in quite a while, didn’t like it much…). Which is where all the fun started…

Yes, at the end of the base Arch install, after installing Grub with the command I mentioned, I ran grub-mkconfig -o /boot/grub/grub.cfg from the arch-chroot. First time through, it booted without problems, but only showed EOS and Win10, even though the boot wasn’t too EOS, it was to the new Arch base install. Out of curiosity, I will try booting back to the EOS install and run grub-mkconfig from there, see if it does anything different.

I’ve never had secure boot enabled on that machine, and have checked that the updated firmware didn’t enable it. I’ve also cross checked, since I have known Windows updates to re-enable the idiotic MS “fast boot”. When I checked the firmware, I notice that I have disabled legacy mode completely - UEFI only.

I suspect that some if not all of the oddities come from the fact that I used Grub as the bootloader-id. If I can work out a safe way of removing the grub install from the new Arch install and clearing it out of NVRAM, I will try a new Grub install, but using a bootloader-id of Arch instead of Grub, see if that makes any difference.

4

To clear entries in nvram you can use efibootmgr if you can boot into EndeavourOS. To see entries sudo efibootmgr. To remove an entry.

sudo efibootmgr -b xxxx -B

You can also set the boot order.

sudo efibootmgr -o xxxx

5

Thanks Rick. I was just about to say I’ve fixed it…

First I tried booting to EOS (via the MX grub menu) and running grub-mkconfig -o /mnt/arch/boot/grub/grub.cfg That wasn’t a very good idea - the Arch entry wouldn’t boot at all, just left me with a blinking cursor and an otherwise blank screen.

So I cheated - booted from the arch usb, mounted the Arch install under /mnt, used arch-chroot to get into it. I had copied the grub-tools package from the EOS install, so I installed it (and found at the same time that I’d lost os-prober from the Arch install somehow - don’t know where it went, the command log I’ve got from the original install clearly shows it was installed, but…). I then generated a new /boot/grub/grub.cfg and rebooted. At which point, even though reFind was still showing an EOS entry, I got the Arch grub menu (which also appeared under a “Grub” entry, presumably due to the bootloader-id I used when I installed grub under Arch.

I’ve now used efibootmgr to make the Grub entry the first in the boot order list, which means I’m back to a working grub menu which allows me to select Arch, Windows, EOS and MX. And they all work, though I did have to manually edit the Arch /boot/grub/grub.cfg entry for EOS, since even with grub-tools installed, grub-mkconfig had generated a faulty entry for it - only had the intel-ucode listed under initramfs.

So it all works now and I’ve learnt a bit more about how UEFI works. I’m still not sure why the initial grub menu pointed the Arch install while naming it Endevour, but I’m not going to worry about that.

So thanks, I’ve now got it working.

1 Like
6

The reason grub-tools and os-prober is on EndeavourOS is because a lot of Arch based distro’s don’t place nice together setting up grub. Most of the time it works when you are installing EndeavourOS and others are already installed. I know it doesn’t work with An Anarchy Arch install. I usually get Anarchy booting only.

7

I’m just guessing, but would you happen to have several EFI partitions on your disk(s)?

If so, could you show the output of commands:

lsblk -fm
sudo fdisk -l

In principal, it is a good idea to have EndeavourOS in control of booting, because of the issues @ricklinux already mentioned, and because grub-tools in EndeavourOS should help create a grub.cfg that can boot all Arch based systems on your disk(s).

And sorry about the long sentence… :wink:

8

No, single 1 TiB SSHD, single EFI partition:

[arch@cygnus ~]$ lsblk -fm
NAME   FSTYPE FSVER LABEL    UUID                                 FSAVAIL FSUSE% MOUNTPOINT   SIZE OWNER GROUP   MODE
sda                                                                                         931.5G root  disk    brw-rw----
├─sda1 vfat   FAT32          420D-16B7                             170.6M    13% /boot/efi    200M root  disk    brw-rw----
├─sda2                                                                                         16M root  disk    brw-rw----
├─sda3 ntfs                  284897B048977B70                      223.2G    11% /mnt/win   250.2G root  disk    brw-rw----
├─sda4 swap   1              193d623b-40b4-41dd-b3ae-9888bce51799                [SWAP]        12G root  disk    brw-rw----
├─sda5 ext4   1.0            40f17ac9-5d31-4c9b-a097-0c5fffe8712e  277.1G     1% /home        300G root  disk    brw-rw----
├─sda6 ext4   1.0            ddc47069-c592-4e94-92b1-1dd2bd8a7c0d   16.6G    38% /mnt/eos      30G root  disk    brw-rw----
├─sda7 ext4   1.0   rootMX19 46e9fa40-f43f-4a23-933b-4d5a7f48a4e2   21.8G    21% /mnt/mx       30G root  disk    brw-rw----
└─sda8 ext4   1.0            ba8f0ded-2801-4d0d-b59a-faebc1e74a8b   19.1G    30% /             30G root  disk    brw-rw----
sr0

[arch@cygnus ~]$ sudo fdisk -l
[sudo] password for arch: 
Disk /dev/sda: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: ST1000LX001-1EM1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: DBBF3A22-F2FF-4F54-92B6-53D730B39FAD

Device          Start        End   Sectors   Size Type
/dev/sda1        2048     411647    409600   200M EFI System
/dev/sda2      411648     444415     32768    16M Microsoft reserved
/dev/sda3      444416  525211647 524767232 250.2G Microsoft basic data
/dev/sda4   525211648  550377471  25165824    12G Linux swap
/dev/sda5   550377472 1179523071 629145600   300G Linux filesystem
/dev/sda6  1179523072 1242437631  62914560    30G Linux filesystem
/dev/sda7  1242437632 1305352191  62914560    30G Linux root (x86)
/dev/sda8  1305352192 1368266751  62914560    30G Linux filesystem

EOS is installed on /dev/sda6, /dev/sda5 is /home, shared between all three distros. Arch was the latest install, so it’s grub install is the main boot control. When I finally got everything working, I had installed grub-tools to the Arch install, hoping that it would save me from manually fixing the initramfs line in the EOS grub entry. It didn’t. Still, easy enough to fix manually.

9

I will let @manuel give give you his expertise on this but you could let EndeavourOS control the boot with grub and that would require that you have os-prober and grub-tools installed from the endeavouros repo on the EndeavourOS installation. Then run sudo grub-mkconfig -o /boot/grub/grub.cfg

I think grub-tools includes os-prober as a dependency?
My only other comment i would make is that your EFI partition is a bit on the small side. I wouldn’t worry about it unless you ever run into a problem. Most distros create the EFI 300M but the experts on EFI say 512-550M is the way to go. Just my 2 cents! I don’t see anything wrong with your setup other than recommending EndeavourOS control the boot. But that’s up to you as i know you have it currently bootable. This is what is being recommended here at EndeavourOS. I hope you enjoy using it and we are always happy to lend a hand if we can.