Re: [gentoo-user] Re: Kernel modules: initramfs vs. /lib/modules
On 02/13/2017 10:51 AM, Remy Blank 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. > >> I thought I was going to have to use an initramfs but I tried without it >> and it boots with no issues. > > Yes, but I [incorrectly, apparently] assumed that UUID and PARTUUID would work the same way. Now I'm curious as to why it doesn't, I'm going to look it up later. Dan
Re: [gentoo-user] Re: Kernel modules: initramfs vs. /lib/modules
On Mon, Feb 13, 2017 at 1:51 PM, Remy Blank 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.
[gentoo-user] Re: Kernel modules: initramfs vs. /lib/modules
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. > I thought I was going to have to use an initramfs but I tried without it > and it boots with no issues.
