I've noticed recently that when attempting to boot the Linux kernel (5.8.0-55-generic
in a standard Ubuntu 20.04 distribution), if I specify the root drive using root=PARTUUID=.....
and give the ext4 partition UUID in upper case, then the kernel boots, but hangs for 30s during boot (as shown in these lines from /var/log/dmesg
):
[ 2.853379] kernel: input: HID 05ac:820b as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.8/2-1.8.1/2-1.8.1.2/2-1.8.1.2:1.0/0003:05AC:820B.0009/input/input10
[ 2.857488] kernel: hid-generic 0003:05AC:820B.0009: input,hidraw8: USB HID v1.11 Mouse [HID 05ac:820b] on usb-0000:00:1d.0-1.8.1.2/input0
[ 2.938013] kernel: usb 2-1.8.1.3: new full-speed USB device number 8 using ehci-pci
[ 3.057584] kernel: usb 2-1.8.1.3: New USB device found, idVendor=05ac, idProduct=8289, bcdDevice= 1.50
[ 3.067746] kernel: usb 2-1.8.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3.077779] kernel: usb 2-1.8.1.3: Product: Bluetooth USB Host Controller
[ 3.087836] kernel: usb 2-1.8.1.3: Manufacturer: Apple Inc.
[ 32.329915] kernel: EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
[ 32.498137] systemd[1]: Inserted module 'autofs4'
[ 33.091557] systemd[1]: systemd 245.4-4ubuntu3.7 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[ 33.130184] systemd[1]: Detected architecture x86-64.
[ 33.179603] systemd[1]: Set hostname to <michael-MacBookPro>.
[ 33.342145] systemd[1]: Created slice system-modprobe.slice.
[ 33.350600] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[ 33.358792] systemd[1]: Created slice User and Session Slice.
If I specify the exact same PARTUUID in lower case, there is no hang:
[ 2.643019] kernel: input: HID 05ac:820b as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.8/2-1.8.1/2-1.8.1.2/2-1.8.1.2:1.0/0003:05AC:820B.0009/input/input10
[ 2.652851] kernel: hid-generic 0003:05AC:820B.0009: input,hidraw8: USB HID v1.11 Mouse [HID 05ac:820b] on usb-0000:00:1d.0-1.8.1.2/input0
[ 2.685911] kernel: EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
[ 2.733247] kernel: usb 2-1.8.1.3: new full-speed USB device number 8 using ehci-pci
[ 2.852575] kernel: usb 2-1.8.1.3: New USB device found, idVendor=05ac, idProduct=8289, bcdDevice= 1.50
[ 2.860616] kernel: usb 2-1.8.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.867916] kernel: usb 2-1.8.1.3: Product: Bluetooth USB Host Controller
[ 2.875182] kernel: usb 2-1.8.1.3: Manufacturer: Apple Inc.
[ 2.882524] systemd[1]: Inserted module 'autofs4'
[ 3.490681] systemd[1]: systemd 245.4-4ubuntu3.7 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[ 3.529529] systemd[1]: Detected architecture x86-64.
[ 3.585335] systemd[1]: Set hostname to <michael-MacBookPro>.
[ 3.732416] systemd[1]: Created slice system-modprobe.slice.
[ 3.740515] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[ 3.748458] systemd[1]: Created slice User and Session Slice.
(Note, the same 'mounted filesystem' message is in both logs, just a few lines earlier and with no long delay in the fast boot log.)
The upper case version of the PARTUUID is being used, however (not e.g. overridden by something else): if I put in wrong a digit, then after the 30s hang the kernel complains that it cannot find the root file system, as expected.
Can anyone help to explain this? It seems at least that it should not work at all, if the case matters, not that it should work after a 30s delay.
UPDATE 1: The same (behaviour above and similarities to/differences from /etc/fstab
behaviour) applies to root=UUID=...
as well as root=PARTUUID=...
.
UPDATE 2: I think this must be somewhat different from what happens with /etc/fstab
(both because mounting root must happen before /etc/fstab
can be read, and also because - as discussed in comments - /etc/fstab
simply fails with wrong case (PART)UUID, whereas root=...
succeeds, after a 30s pause).
/etc/fstab
just fails if given PARTUUID in the wrong case, whereas as describedroot=
works, after a strange delay. – MikeBeaton Jun 21 '21 at 17:17root=PARTUUID=...
can mount even without an initial ramdisk. I don't know if that has any basis in fact - but if it does it would again seem to make this issue somewhat different from the other one. – MikeBeaton Jun 22 '21 at 06:09UUID=
as it is not a thing – Tom Hale Mar 03 '22 at 10:12