2

I use EFI booting on a Macbook pro. (I can't use UEFI because the machine is too old.)

On the internal drive, I have Ubuntu Linux 20.04.

I had the unfortunate idea to install Ubuntu Linux 20.04 on an external drive from live USB. (I am trying to make a clone with incremental backup, which apparently no existing software does for Linux.)

When starting with the external drive connected, I see GNU GRUB 2.04 boot menu. By default, the external drive will boot first but I have a choice for booting on the internal drive.

When the external drive is not connected, I fall in the GRUB shell and cannot boot. I have read How to Rescue a Non-booting GRUB 2 on Linux but I always ended up with "end kernel panic... unable to mount root fs...".

Anyway, as long as I can still boot without GRUB shell, I just need to restore the internal drive to boot normally Ubuntu Linux.

This looks very simple.

After booting on the internal drive and disconnecting the external drive, I have tried sudo update-grub but it does not help.

I have tried to change the boot order with sudo efibootmgr but it gets worse, since I always end up in GRUB shell. (Fortunately, the change is reversible.)

If possible, eventually, I would like to get rid of GRUB. The Mac does not need GRUB because when it is started with the alt key pressed, it presents all bootable partitions in a simple graphical menu, so it would be very easy to choose any EFI partition and boot thereon without GRUB.

EDIT after first answer (thanks)

"something has caused the GRUB on the internal disk to be rewritten". YES, it is the live Ubuntu Linux installer, a dangerous thing indeed. I should have been more cautious: unmount the internal drive before installing Ubuntu Linux on the external drive. Indeed I found out that something had changed in /boot/efi on the internal drive. I restored the files exactly as explained in Ubuntu EFI booting fails after Mac OS X booting.

After rebooting, with external drive connected, I discovered a new situation: no GRUB menu, so I was forced to go with GRUB shell, but fortunately I could ls the internal drive (instead of previously the external drive only) and apply this tutorial How to Rescue a Non-booting GRUB 2 on Linux to boot on internal drive.

So now I need to make boot happen automatically and, if possible, keep the option to boot on the external drive.

The grub.cfg on internal drive:

mac2011-linux# pwd      
/boot/efi/EFI
mac2011-linux# more ubuntu/grub.cfg
search.fs_uuid 770e447c-7411-4cc7-bce4-b71504d828c3 root hd2,gpt4 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

As I have no separate boot filesystem, prefix is correct. I can see in blkid that uuid 770e447c-7411-4cc7-bce4-b71504d828c3 is /dev/sdb4 on external drive. This is not correct. How to fix it cleanly?

mac2011-linux# ls
APPLE  BOOT  tools  ubuntu
mac2011-linux# mac2011-linux# ls -l BOOT
total 5367
-rwx------ 1 root root 1677176 mai 25 14:54 bootx64.efi
-rwx------ 1 root root 1334816 mai  8 21:48 BOOTX64.EFI-old
-rwx------ 1 root root 1213032 mai 24 23:04 fbx64.efi
-rwx------ 1 root root 1269496 mai 24 23:04 mmx64.efi
mac2011-linux# ls -l ubuntu
total 4183
-rwx------ 1 root root     108 mai 24 23:04 BOOTX64.CSV
-rwx------ 1 root root     126 mai 24 23:04 grub.cfg
-rwx------ 1 root root 1677176 mai 24 23:04 grubx64.efi
-rwx------ 1 root root 1269496 mai 24 23:04 mmx64.efi
-rwx------ 1 root root 1334816 mai 24 23:04 shimx64.efi

I don't know if the ubuntu directory is actually read. I know that bootx64.efi is read because it is a copy of grubx64.efi installed by myself and making GRUB targeting internal drive.

Now I have GRUB, I keep it at least until I am more familiar with Linux but I would rather not add rEFInd, to avoid additional mess.

I found this ArchLinux article on GRUB in particular the section for UEFI systems. This gave me the idea to check GRUB install. I did sudo apt install grub2-common grub-efi-amd64 and again sudo update-grub and I got a new /boot/efi/EFI/ubuntu/grub.cfg pointing to the correct partition on internal drive. This fixes cleanly reboot on internal drive.

So it appears that GRUB was not correctly installed on my system. This might be a small defect of the Ubuntu Linux 20.04 distribution.

I still have to check if the external drive Ubuntu Linux also works.

2

It may be that something has caused the GRUB on the internal disk to be rewritten so that it now attempts to load its configuration from the external disk.

First, verify that the external disk has a fully-populated EFI System Partition, and that the /etc/fstab correctly mounts the ESP of the external disk to /boot/efi. If something is missing, use grub-install --force-extra-removable /dev/sd<external disk> to reinstall GRUB on the external disk - but first make sure the correct ESP is mounted to /boot/efi.

Reboot and use efibootmgr -v. Check the BootCurrent value and the corresponding boot entry to verify that the system actually did fully boot from the external disk and did not fall back to the bootloader on the internal one. Now you know you have a fully working GRUB on the external disk that should be completely independent of the internal disk.

Then mount the ESP partition of the internal disk (if it is not already mounted), and check the contents of <mountpoint of internal ESP>/EFI/ubuntu/grub.cfg. It should be a small GRUB configuration file with only about three lines, telling where to load the main GRUB configuration file from. It normally refers to the filesystem by UUID. It should be something like this:

serch.fs_uuid <UUID of the filesystem containing /boot> root
set prefix=($root)'/grub'
configfile $prefix/grub.cfg

Yes, even though the first line mentions root, it does not necessarily mean the Linux root filesystem - it refers to GRUB's root, which is the filesystem that contains the main GRUB configuration file and GRUB's module directory. In Debian/Ubuntu, that may be the Linux root filesystem or a separate /boot filesystem (if /boot is a separate filesystem).

If the /boot directory is contained in the Linux root filesystem, then the second line might be set prefix=$(root)'/boot/grub' instead. Once the prefix variable is set correctly, GRUB will be able to auto-load GRUB modules (e.g. support for other filesystem types) from it.

This might be enough to fix the failing GRUB on the internal disk. If that does not help, you might want to boot from the external disk, mount the root filesystem of the internal disk to /mnt, /boot of the internal disk (if it exists as a separate filesystem) to /mnt/boot, the ESP of the internal disk to /mnt/boot/efi, etc. until you have the full filesystem tree of the internal disk mounted under /mnt. Then chroot into it:

mount -o rbind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o rbind /sys /mnt/sys
chroot /mnt /bin/bash

Now you should be able to use grub-install /dev/sd<internal disk> to re-install GRUB on the internal disk. After this, the system should again be bootable with the external disk unplugged.

Getting rid of GRUB is technically possible, but having no boot loader at all (i.e. using the UEFI stub built into the kernel) will make the use of any kernel boot options extremely awkward. You'll first need to boot into something that can edit the UEFI boot entries, add/change the boot options you need, and then boot again into "bootloaderless" Linux. You might want to check out some of the alternative boot loaders instead, like rEFInd or systemd-boot.

| improve this answer | |
  • ESP = EFI system partition, EFI = extensible firmware interface. – Pierre ALBARÈDE Oct 10 at 20:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.