Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't unset GRUB_DISABLE_LINUX_UUID=true #1719

Closed
geckolinux opened this issue Jun 7, 2021 · 7 comments
Closed

Can't unset GRUB_DISABLE_LINUX_UUID=true #1719

geckolinux opened this issue Jun 7, 2021 · 7 comments
Labels
bug: downstream Bug exists, but it is created downstream

Comments

@geckolinux
Copy link
Contributor

Hi there, I'm updating my ISOs based on openSUSE Leap (generated with Kiwi), now currently at Leap 15.3. The previous ISOs for Leap 15.2 has Calamares 3.2.15, and now with the Leap 15.3 based ISOs it's Calamares 3.2.36. Both versions use the old KPMcore 3.3.0, but that doesn't seem to be the source of the problem in this case.

There is a new issue with the Leap 15.3 based installations where it is adding GRUB_DISABLE_LINUX_UUID=true to /etc/default/grub, leading to it having a root=/dev/sdxY command in GRUB. This causes issues on my hardware, because my test laptop has buggy firmware or a lazy SCSI bus or something quirky going on, which makes it randomly load the SSD as /dev/sda or /dev/sdb. So often the root= line is the wrong device and it fails to boot.
MVIMG_20210607_084302

This is the correct GRUB configuration that the older Leap 15.2 ISO with Calamares is creating:
IMG_20210607_093355

I hoped to work around this issue by adding GRUB_DISABLE_LINUX_UUID: false under defaults: in Calamares grubcfg.conf, but it doesn't seem to make any difference.

I also tried using the older Calamares 3.2.15 release with my Leap 15.3 test ISO, but it behaves the same, so apparently it's something in Leap 15.3 that I need to work around. So I don't know if this is technically a Calamares issue, but at any rate it would be nice to be able to work around it with Calamares, as the /dev/sdxY scheme for the root device is not good.

Thanks a lot!

@abucodonosor
Copy link
Contributor

This is added by your grub distro package it seems...

If you just copy from live media over, then use some sed line to disable that stuff but on any grub update
from your distribution, it may break again.. IOW, you are better to package your own grub package at some point.

@abucodonosor abucodonosor added the bug: downstream Bug exists, but it is created downstream label Jun 7, 2021
@geckolinux
Copy link
Contributor Author

Thanks @abucodonosor for the response.

The default distro package has this in /etc/default/grub :

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

But under /etc/grub.d/10_linux it has:

# Default to disabling partition uuid support to maintian compatibility with
# older kernels.
GRUB_DISABLE_LINUX_PARTUUID=${GRUB_DISABLE_LINUX_PARTUUID-true}

# btrfs may reside on multiple devices. We cannot pass them as value of root= parameter
# and mounting btrfs requires user space scanning, so force UUID in this case.
if ( [ "x${GRUB_DEVICE_UUID}" = "x" ] && [ "x${GRUB_DEVICE_PARTUUID}" = "x" ] ) \
    || ( [ "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ] \
	&& [ "x${GRUB_DISABLE_LINUX_PARTUUID}" = "xtrue" ] ) \
    || ( ! test -e "/dev/disk/by-uuid/${GRUB_DEVICE_UUID}" \
	&& ! test -e "/dev/disk/by-partuuid/${GRUB_DEVICE_PARTUUID}" ) \
    || ( test -e "${GRUB_DEVICE}" && uses_abstraction "${GRUB_DEVICE}" lvm ); then
  LINUX_ROOT_DEVICE=${GRUB_DEVICE}
elif [ "x${GRUB_DEVICE_UUID}" = "x" ] \
    || [ "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ]; then
  LINUX_ROOT_DEVICE=PARTUUID=${GRUB_DEVICE_PARTUUID}
else
  LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
fi

The weird thing is that the exact same file is present in the older Leap 15.2 base, and in fact all files in /etc/grub.d/ are identical between both versions. So I don't know how the UUID is still getting disabled.

At any rate, my understanding is that Calamares is supposed to go in and edit the final /etc/default/grub file after all that logic is finished, so I'm not sure why it's not adding the GRUB_DISABLE_LINUX_UUID: false default that I specify.

Really the only option for me is to work around this with Calamares, as I don't do custom packages, especially not for something as important as GRUB. I strongly prefer to stick to the upstream packages for that.

@abucodonosor
Copy link
Contributor

I can't really tell you what changes, all I know is Suse has a hell of patches in grub ;).
You can try to start calamares with debug and see what it does..
You need to figure what is adding that and when...

Since you rsync from live media, change /etc/default/grub manually and add this line, if is gone by the end of the installation
some other tool of your distro manipulates the conf too.

Another way to manipulate would be trying to use some script or a wrapper starting calamares...

@geckolinux
Copy link
Contributor Author

You need to figure what is adding that and when...

Right. It must be happening during the Kiwi creation stage, as the live ISO has GRUB_DISABLE_LINUX_UUID=true in its /etc/default/grub.

So from reading the comments in grubcfg.conf it looks like I misunderstood something:

# Create, overwrite or update /etc/default/grub in the target system.`
[...]
# If set to true, always creates /etc/default/grub from scratch even if the file
# already existed. If set to false, edits the existing file instead.
overwrite: false
[...]
# Default entries to write to /etc/default/grub if it does not exist yet or if
# we are overwriting it.
#
defaults:
[...]

So I guess it won't work to add GRUB_DISABLE_LINUX_UUID: false unless I enable overwriting the file, which is another mess I'd prefer not to get into...

@geckolinux
Copy link
Contributor Author

geckolinux commented Jun 8, 2021

OK, so it turns out that Kiwi is responsible for generating the /etc/default/grub file for the live ISO, and something has changed that is now causing it to add the GRUB_DISABLE_LINUX_UUID=true parameter. I did find a workaround in Kiwi though, so this bug is technically invalid. But I'm not sure if you want to leave it open as a feature request, because I do think it would be extremely useful to specify that existing values in /etc/default/grub be replaced with something specified by the distro without Calamares recreating the entire file.

@kkofler
Copy link
Contributor

kkofler commented Jun 14, 2021

Well, IMHO, in decreasing order of preference:

  • get Kiwi fixed to not set this option to begin with,
  • sed the file in your live image creation script, or
  • use the shellprocess module to sed the file from Calamares.

Generally, the idea is that if an /etc/default/grub exists, it is expected to be provided by the distribution and to contain reasonable settings.

@geckolinux
Copy link
Contributor Author

OK, thanks to everyone for their responses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug: downstream Bug exists, but it is created downstream
Projects
None yet
Development

No branches or pull requests

3 participants