Re: [GRUB PARTUUID PATCH 2/2] Update grub script template files

[Nick Vinson]

On 07/26/2016 10:01 PM, Andrei Borzenkov wrote:
> 20.06.2016 04:37, Nicholas Vinson пишет:
>> Update grub-mkconfig.in and 10_linux.in to support grub-probe's new
>> partuuid target.
>>
>> Signed-off-by: Nicholas Vinson <address@hidden>
>> ---
>>  util/grub-mkconfig.in   |  2 ++
>>  util/grub.d/10_linux.in | 11 +++++++++--
>>  2 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
>> index f8496d2..fc42462 100644
>> --- a/util/grub-mkconfig.in
>> +++ b/util/grub-mkconfig.in
>> @@ -134,6 +134,7 @@ fi
>>  # Device containing our userland.  Typically used for root= parameter.
>>  GRUB_DEVICE="`${grub_probe} --target=device /`"
>>  GRUB_DEVICE_UUID="`${grub_probe} --device ${GRUB_DEVICE} --target=fs_uuid 
>> 2> /dev/null`" || true
>> +GRUB_DEVICE_PARTUUID="`${grub_probe} --device ${GRUB_DEVICE} 
>> --target=partuuid 2> /dev/null`" || true
>>  
>>  # Device containing our /boot partition.  Usually the same as GRUB_DEVICE.
>>  GRUB_DEVICE_BOOT="`${grub_probe} --target=device /boot`"
>> @@ -182,6 +183,7 @@ if [ "x${GRUB_ACTUAL_DEFAULT}" = "xsaved" ] ; then 
>> GRUB_ACTUAL_DEFAULT="`"${grub
>>  # override them.
>>  export GRUB_DEVICE \
>>    GRUB_DEVICE_UUID \
>> +  GRUB_DEVICE_PARTUUID \
>>    GRUB_DEVICE_BOOT \
>>    GRUB_DEVICE_BOOT_UUID \
>>    GRUB_FS \
>> diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
>> index de9044c..8081fdb 100644
>> --- a/util/grub.d/10_linux.in
>> +++ b/util/grub.d/10_linux.in
>> @@ -220,8 +220,15 @@ while [ "x$list" != "x" ] ; do
>>      gettext_printf "Found initrd image: %s\n" "${dirname}/${initrd}" >&2
>>    elif test -z "${initramfs}" ; then
>>      # "UUID=" and "ZFS=" magic is parsed by initrd or initramfs.  Since 
>> there's
>> -    # no initrd or builtin initramfs, it can't work here.
>> -    linux_root_device_thisversion=${GRUB_DEVICE}
>> +    # no initrd or builtin initramfs, it can't work here.  However, if
>> +    # GRUB_DEVICE_PARTUUID is not empty we can use that here if
>> +    # GRUD_DISABLE_LINUX_UUID is not set to true.
>> +    if [ "x${GRUB_DISABLE_LINUX_UUID}" != "xtrue" ]
>> +        && [ "x${GRUB_DEVICE_PARTUUID}" != "x" ]; then
>> +        linux_root_device_thisversion="PARTUUID=${GRUB_DEVICE_PARTUUID}"
> 
> Well, PARTUUID appeared first in 2.6.37 and MSDOS "UUID" in 3.10.
> Unfortunately we have no way to check for it, even as fragile as stored
> kernel config. So I am not sure we should do it by default. And if we
> add some extra knob to turn it on, as you mentioned yourself, you can
> simply add root=PARTUUID=xxx to stored kernel command line.

I've done that using /etc/default/grub and it works, but you end up with
two root=... entries in your kernel command line.  I could have gone
back and edited the grub.cfg to clean up the command-line.

I will adjust the logic so that using PARTUUID is an opt-in feature
instead of an opt-out feature.  Downstream distributions would then be
able to adjust GRUB's defaults in their own packaging and turn this
feature on by default if it made sense for them to do so.

> 
> One more consideration is that reinstalling in existing partition will
> invalidate FS UUID stored in grub.cfg which is arguably the right thing
> because you now have something different there, but PARTUUID will most
> likely remain the same.

I am sorry, but I am not sure I understand the issue you are raising here.

If I boot Linux without an initramfs, I must specify where the root
partition (or device, if the device has no partitions) is.  GRUB
currently does this by setting root to something like '/dev/sda3'.  That
said, this is a Linux limitation not GRUB's.  Linux is unable to use the
FS UUID this early in the boot process.

If I have an initramfs, I *may* be able to use the FS UUID.  In this
case, it all depends on the implementation of my initramfs.  However,
GRUB's current behavior is to assume that all initramfs implementations
understand how to handle UUIDs, that the UUID is the FS UUID, and are
able to mount rootfs properly.

I have no interest in debating if that behavior is correct or not, nor
do I have any interest in changing it.  As currently written, my patch
should favor the FS UUID when an initramfs is detected, the PARTUUID
when it is not, and the Linux device naming scheme when the UUID feature
is disabled or the PARTUUID could not be found.

The rationale for favoring PARTUUID over the linux device name is
because the PARTUUID would allow a system to boot if the device with the
root partition is ever renamed.  In other words, if the device was sda
when grub.cfg was created, but somehow became sdb (or the other way
around), the system would sill be able to boot because the kernel would
still be able to find /sbin/init.  Whereas with the linux device name,
the boot would fail because it would be looking at the wrong device for
/sbin/init (FS UUID provides the same protections, but in theory allows
use to reorder partitions on a single device and still boot successfully
without having to regenerate the grub.cfg).

If there is something I am missing, let me know, so I can address it.

Thanks,
Nicholas Vinson

> 
>> +    else
>> +        linux_root_device_thisversion=${GRUB_DEVICE}
>> +    fi
>>    fi
>>  
>>    if [ "x$is_top_level" = xtrue ] && [ "x${GRUB_DISABLE_SUBMENU}" != xy ]; 
>> then
>>
>

signature.asc
Description: OpenPGP digital signature