Why another machine does not boot on the same disk with EFI and Ubuntu?

Question

I have an external hard disk containing an EFI system partition, a Ubuntu 20.10 partition and some other partitions, including Mac OS X, so it works as dual boot.

I have two Macbook Pros: v 5,5 Intel Core 2 Duo RAM 8G year 2009 and v8,1 Intel Core i5 RAM 16G year 2011. Any of them can run the same binaries and Mac OS X El Capitan.

When it comes to Ubuntu, both machines begin similarly: in the firmware menu, I select the hard disk EFI system partition, then appear the GRUB menu, the long list of messages, including the Ubuntu 20.10 welcome.

However, the older machine fails on

[ TIME ] Timed out waiting for device /dev/disk/by-uuid/71E2-6200

See the photograph:

71E2-6200 is the UUID of the EFI system partition.

I also see this a few lines down:

[  103.625925] blk_update_request: I/O error, dev sdb, sector 6368 op 0x0:(READ) flags 0x8

where the sector number can change.

Running fsck on the EFI system partition and Ubuntu partition shows no problem.

Do you have any idea why the older machine fails whereas the newer succeeds?

Information obtained (after booting on the newer machine):

mac2011-linux% cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda4 during installation
UUID=1ce2a9e1-0d15-4c20-9f53-32fc9c47b525 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
#UUID=71E2-6200  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0
# for NFS
/home/alba    /export/alba   none    bind  0  0
# /dev/disk/by-label/EFI /mnt/EFI auto nosuid,nodev,nofail,noauto,x-gvfs-show 0 0
#UUID=71E2-6200  /boot/efi       vfat    defaults      0       1
#UUID=71E2-6200  /boot/efi       vfat    defaults      0       1
UUID=71E2-6200  /boot/efi       vfat    defaults      0       1
mac2011-linux% sudo blkid
[sudo] password for alba: 
/dev/sdb4: LABEL="Ubuntu backup" UUID="1ce2a9e1-0d15-4c20-9f53-32fc9c47b525" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Ubuntu backup" PARTUUID="98872d9f-9d11-4c9e-8acb-fb1d0c0ccb9a"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/loop7: TYPE="squashfs"
/dev/sda1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="67E3-17ED" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="05bdacf6-78ff-451d-8c4d-bb812fd68e83"
/dev/sda2: UUID="0492d65c-8b14-356a-9d3d-337f44e8d58a" BLOCK_SIZE="4096" LABEL="SSD 1T" TYPE="hfsplus" PARTLABEL="MacOS_El_Capitan" PARTUUID="10b29023-d982-4be8-8ceb-226c04893a8b"
/dev/sda3: UUID="87867aee-1d5c-3c9e-ae36-8d2df5c162f1" BLOCK_SIZE="4096" LABEL="Recovery HD" TYPE="hfsplus" PARTLABEL="Recovery HD" PARTUUID="895fd6af-7b68-4873-bec1-6dc154aece4f"
/dev/sda4: LABEL="Ubuntu" UUID="dc68435c-f80c-4beb-a09b-69015ad516e6" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Ubuntu" PARTUUID="4c1d9c0a-978e-46fd-9ae0-b49c6ed27037"
/dev/sdb1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="71E2-6200" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="2c99fbe4-96f8-465b-b528-d03c40083bd7"
/dev/sdb2: UUID="e490c4f5-2f3d-3996-8db7-6e45050c8636" BLOCK_SIZE="4096" LABEL="El Capitan" TYPE="hfsplus" PARTLABEL="HGST 1 TB" PARTUUID="1a198393-f3db-4c36-bfed-7a07e4c43520"
/dev/sdb3: UUID="47af6fd5-545e-3b2b-a9f9-f537efe3354b" BLOCK_SIZE="4096" LABEL="Recovery HD" TYPE="hfsplus" PARTLABEL="Recovery HD" PARTUUID="d00d1e40-ec70-4cc7-a97a-3f29a763011e"
/dev/loop8: TYPE="squashfs"
/dev/loop9: TYPE="squashfs"
/dev/loop10: TYPE="squashfs"
/dev/loop11: TYPE="squashfs"
/dev/loop12: TYPE="squashfs"
/dev/loop13: TYPE="squashfs"
/dev/loop14: TYPE="squashfs"
/dev/loop15: TYPE="squashfs"
/dev/loop16: TYPE="squashfs"
/dev/loop17: TYPE="squashfs"
/dev/loop18: TYPE="squashfs"

I have the outputs of journalctl in the booting and non booting cases.

Notable lines in the non booting case :

Apr 24 19:38:28 mac2011-linux kernel: ACPI: BIOS bug: multiple APIC/MADT found, using 0

Apr 24 19:38:28 mac2011-linux kernel: PCI: MMCONFIG for 0000 [bus00-3f] at [mem 0xf0000000-0xf3ffffff] (base 0xf0000000) (size reduced!)
Apr 24 19:38:28 mac2011-linux kernel: PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug

Apr 24 19:38:28 mac2011-linux kernel: tsc: Marking TSC unstable due to clocksource watchdog
Apr 24 19:38:28 mac2011-linux kernel: TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
Apr 24 19:38:28 mac2011-linux kernel: sched_clock: Marking unstable (1164224651, 840043)<-(1171542672, -6477987)

Apr 24 19:38:28 mac2011-linux kernel: Unstable clock detected, switching default tracing clock to "global"
                                      If you want to keep using the local clock, then add:
                                        "trace_clock=local"
                                      on the kernel command line

Apr 24 19:38:28 mac2011-linux blkmapd[290]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory

blkmapd is related to NFS. The blkmapd is also is the log of the booting case so it can't cause non booting. Same for use "pci=nocrs" and report a bug.

Older machine:

Apr 24 19:38:28 mac2011-linux kernel: DMI: Apple Inc. MacBookPro5,5/Mac-F2268AC8, BIOS    MBP55.88Z.00AC.B03.0906151708 06/15/09

00AC.B03 is up to date.

Newer machine:

Apr 24 19:42:40 mac2011-linux kernel: DMI: Apple Inc. MacBookPro8,1/Mac-94245B3640C91C81, BIOS    MBP81.88Z.0050.B00.1804101331 04/10/18

The Ubuntu 20.04LTS live installer works on the older machine USB. This shows that the older machine is compatible with Ubuntu 20.04LTS.

I have a SSD clone of the hard disk. The SSD clone behaves similarly, although some boot messages are different. This shows that the cause of the problem is not a dying disk.

Any more idea?

Answer 1

For starting the older machine with Ubuntu 20.04LTS on USB, I used a micro SD card in a USB card reader. I could not see it in the Mac boot menu, until I disconnected the internal SSD.

I also routinely modified a few files of the external hard disk (that I use for backup) and tried again to boot on the newer machine. It only worked after running fsck manually.

I tried again to start the older machine on the external hard disk, still with its internal SSD disconnected, and it worked. After reconnecting the internal SSD, it did not work.

I have a SSD clone of the hard disk. The SSD clone behaves similarly, although some boot messages are different. This shows that the cause of the problem is not a dying disk.

I have tried again with the clone and the behavior is identical. This confirms that the file system corruption is just an incident.

So all this boils down to the fact that the older machine Macbook pro 5,5 needs the internal device to be disconnected while the newer does not.

In Ubuntu /boot/grub/grub.cfg, GRUB is always configured to look for hd0 whatever the real starting device number is (and it is normally >= 1). I have tried to replace hd0 by hd1 (as is already in /boot/efi/EFI/ubuntu/grub.cfg) but this does not help.

No more recent firmware is available for the Macbook pro 5,5.