On Mon, Feb 13, 2017 at 1:51 PM, Remy Blank <remy.bl...@pobox.com> wrote: > Daniel Frey wrote on 2017-02-13 17:34: >> On 02/13/2017 03:34 AM, Rich Freeman wrote: >>> Anytime you see something like root=UUID=* that is being handled by an >>> initramfs. And of course a UUID is more reliable than a device name, >>> since the latter can change if you add/remove a device, or maybe even >>> if your firmware is having a bad day. Identifying devices by UUID >>> ensures the right one gets found, assuming it is available. If you're >>> using something like mdadm/lvm there are alternatives to UUID, but the >>> point is the same, you're using a logical identifier that is based on >>> what is stored on the disks and not just what port it is connected to. >>> >> >> Are you sure? When I set up my EFI stub kernel on my Surface tablet, I >> did not use an initramfs and I use PARTUUID= in the kernel built in init >> line and it boots. > > Note that Rich wrote "UUID=", but you used "PARTUUID=". The former > requires an initramfs, the latter doesn't. The details why escape me: if > the filesystem code is built into the kernel (as opposed to a module), I > see no practical reason why the FS UUID couldn't be determined by the > kernel directly.
Determining the FS UUID would require scanning all partitions of all attached disks, and invoking filesystem-specific code to parse out the UUID. Determining the PARTUUID only requires scanning the partition table of each drive, and is only supported for GPT and MBR partition tables. It's a much simpler task.
