... Chromebook. One thing I'm particularly unclear about is the kernel command line. 'dmesg' gives me a 'cros_secure console=tty1 init=sbin/init root=PARTUUID=[UID]/PARTNROFF=1 rootwait rw noinitrd lsm.module_locking=0' when I'm booting the Arch system I set up with the linux-nyan kernel . The [UID] ...

... upon boot. I made some modification, though. Before installing the kernel I looked at src/linux-4.15/cmdline : console=tty0 init=/sbin/init root=PARTUUID=%U/PARTNROFF=1 rootwait rw noinitrd I thought "this cannot work", or where does this root point to? I tried finding an explanation ...

... in the PKGBUILD file. I had success with modifying the line that is echoed into "cmdline", replacing "root=PARTUUID=%U/PARTNROFF=1" with "root=/dev/mmcblk0p7", since my root partition is still on the internal storage only.

... can still find the boot and root partitions (as long as they're in the 1st 2TB of the disk). Yes, and hybrids work. We tested 3.1 with root=PARTUUID=xxxxxxx

I wouldn't have suggested it if I hadn't already tried it myself.

I booted a oxnas from an SSD SATA drive with hybrid so that I could test PARTUUID rootfs decisions.

A booting with a rootfs=LABEL label like that requires an uInitrd so that by-label is capable of being used.

I think PARTUUID might work though. search.php?keywords=PARTUUID

The currently distributed kernel does not directly support UUID. I think I have the ext4 driver built in on the next revision. GPT support is there however. At which point, it is not about the UUID (since that would require an initrd for by-label etc) but the PARTUUID.

$this->bbcode_second_pass_quote('WarheadsSE', 'A')t which point, it is not about the UUID (since that would require an initrd for by-label etc) but the PARTUUID.