2

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).

MikeBeaton
  • 129
  • 1
    https://superuser.com/questions/529361/why-linux-etc-fstab-uuids-are-case-sensitive – Artem S. Tashkinov Jun 21 '21 at 17:14
  • Thanks - I have seen that, I do think they are different questions, not least that both things need to be set correctly to get boot to work, and each can specify the same drive a different way (e.g. one using LABEL and one using UUID or PARTUUID). Also, /etc/fstab just fails if given PARTUUID in the wrong case, whereas as described root= works, after a strange delay. – MikeBeaton Jun 21 '21 at 17:17
  • 1
    How are they different exactly? Linux uses the UUIDs to create objects in /dev/disk/by-uuid. Like any "file" on Linux, the name is case sensitive. Hence when referring to disks by UUID, the comparison is done as a file-name comparison on the hex strings rather than a binary comparison on the data represented by said strings. – Artem S. Tashkinov Jun 21 '21 at 17:45
  • That answer was marked by the asnwerer as speculation, and it doesn't answer the question of why it works after 30 seconds but fails initially. – plugwash Jun 21 '21 at 20:07
  • It might continue to boot using the previous configuration or some kind of failsafe. We are not talking about the Linux kernel here, we're talking about systemd/initrd and a lot of boilerplate code from the distro. – Artem S. Tashkinov Jun 21 '21 at 21:44
  • I don't think it is using a previous configuration. See my point about what happens if I intentionally change a digit of the uppercase value - it then doesn't boot. So the correct (but uppercase) value is behaving differently from a plain incorrect value. – MikeBeaton Jun 22 '21 at 06:06
  • I found a quote elsewhere claiming that root=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:09
  • Also, @ArtemSTashkinov the log line which is different, the one which happens after 30s, is prefixed with "kernel:". – MikeBeaton Jun 22 '21 at 06:12
  • The OP obfuscated logs and hid the necessary info and asks for comments. That's all kinda sad. – Artem S. Tashkinov Jun 22 '21 at 08:33
  • Added much more context. I am not trying to obfuscate anything! – MikeBeaton Jun 22 '21 at 11:09
  • @ArtemSTashkinov Apologies if I didn't provide enough context before, but also nothing that's so far been discussed was 'obfuscated' (or, rather, elided to try to avoid irrelevant info) in any version of this post, so still not quite sure why you think I deserved that comment. – MikeBeaton Jun 22 '21 at 22:25
  • Please edit your question to remove UUID= as it is not a thing – Tom Hale Mar 03 '22 at 10:12
  • What is the reference for your statement in your own answer which you have linked to? UUID= is definitely 'a thing' as in it is a syntax which exists, and does something comprehensible. (It looks clear from the other answers related to yours that UUID= only works with initramfs, which is fine, useful to know, but doesn't stop it being 'a thing', since it does work with initramfs.) – MikeBeaton Mar 03 '22 at 13:45

0 Answers0