UX: changing GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub has no effect in cloud images

[Robie Basak]

I need to modify the kernel command line, such as to work around bug 1573095. I edit GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub and rerun update-grub but this has no effect.

The reason is that this is redefined in /etc/default/grub.d/50-cloudimg-settings.cfg and that one overrides /etc/default/grub. I was misled by the comment in /etc/default/grub and information widely available on the Internet that editing /etc/default/grub is sufficient, and looked no further.

I understand the reason for not modifying /etc/default/grub in cloud image builds (to avoid future conffile prompts) and I'm not suggesting that it should be modified. To fix this UX issue properly I think the grub package needs to provide a mechanism that allows cloud image builds to override the default without dropping in an overriding file (or for that override file to be the sole place that users need to look).

This affects grub2 2.02-2ubuntu8.9 from Bionic cloud image build 20190114 for example.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mate Kukri (mkukri)]

Hmm, I am not sure if there is much we can do here.

Maybe a comment could be added at the top of /etc/default/grub to remind the user of grub.d's existence, but I can't think of much more.

[Éric St-Jean (esj)]

comment might help indeed in main grub config
i don't think there's much that can be done on the cloud image side as all that's done is add the cloudimg-settings file

[Robie Basak (racb)]

I was going to say that you could use debconf to provide a setting that allows the user to change this, and then have cloud images do that instead of using the .d/ directory.

Then I looked and found some code to do that already, in grub-efi-amd64.config, using the grub2/linux_cmdline_default debconf key.

I'm not sure how that relates to cloud images in general, but that's a clear path forward I think?

> i don't think there's much that can be done on the cloud image side as all that's done is add the cloudimg-settings file

Well, the point is, don't do that, since that's what creates the problem :-)

[John Chittum (jchittum)]

I disagree racb -- using the `.d` directory is generally the approach CPC has used for all configuration. that way users can easily see what is package maintained and what is changed in the build process. I don't think the suggestion that CPC change that general guidance because grub.d is less well known that other `.d` directories is a strong rationale. It seems fairly "normal" for Ubuntu packages to have $PACKAGE_CONF.d directories to add additional configuration.

I think mkukri has the correct solution. we should add a comment to the top level file, and ensure all man pages correctly state how the grub handles the `.d` directory. And any official Ubuntu docs should be updated. we can't change the history of everyone that's posted online about every version of Ubuntu, but changing how we configure things because information online isn't strictly correct (because it predates grub.d, posters didn't know about grub.d, etc) doesn't seem like strong reason.

[Robie Basak (racb)]

> I don't think the suggestion that CPC change that general guidance because grub.d is less well known that other `.d` directories is a strong rationale.

While .d directories are a common pattern and CPC should use them where these are provided, that fundamentally has to be considered on a package-by-package basis. You must adapt to the packaging provided and cannot simply expect or demand to use .d where that causes issues and refuse to budge otherwise.

In the general case, .d directories would override things that are default because the underlying implementation makes them the default. In contrast, using .d directories to override what is specified in other configuration files in /etc by default makes for confusion and should be avoided. We've already seen that with sshd_config.d/, where file ordering collides with configuration syntax rules making some .d-based overrides impossible (that case will hopefully be resolved by moving more things into .d over time).

In this case, grub packaging provides a default in /etc/default/grub leads to confusing duplication when overridden by .d, and I can't see that changing.

In this case, the precise mechanism we need looks like it's already provided using a well-established debconf mechanism, and if not, appears to be able to be trivially extended to do so. That would resolve this bug and all user confusion. Let's not use dogmatic adherence to one specific pattern to excuse fixing the issue with the appropriate mechanism.

[Julian Andres Klode (juliank)]

Robie, debconf is not a database and any setting in there needs to be read to a configuration file and any changes in the configuration file need to be filled back into debconf. The integration for default cmdline with /etc/default/grub is very complex and already broke a bunch of times.

Drop-in units are the standard mechanism to override this in many projects. We specifically added the mechanism to allow overrides, and that is used in various places to set grub defaults for images, OEM kernels, and plenty of other things I can't possibly remember. It is the preferred place to store such overrides.

Of course it's preferable to have overrides that only append items, I don't recall if that works correctly, after all the files are parsed by C code in grub-install I believe.

[Julian Andres Klode (juliank)]

Yes I forgot the option existed and didn't have the context while writing the comment, but generally speaking debconf is a bit of a mess and while it is there and it makes sense to use it accordingly, we certainly should try to avoid introducing more of it.

The file here is a mess, so it's a conffile and the I believe preinst merges the previously configured value into the new file such that you only get promoted about differences in other options, very annoying, and highly fragile.

You can easily see this doesn't scale to every possible grub option.

Presumably we should introduce /usr/lib/grub/default.d and implement the whole drop in logic with /usr directories which is a goal certainly for all our packages.

Then again it is 2024, and people now are highly used to settings made in foo being overriden by settings in foo.d as that's the standard semantic for a wide range of packages, most prominently systemd, so I don't think this is as much of a concern as it was 5 years ago.

That being said, of course not mentioning that grub.d exists and overrides settings in the default configuration file is an oversight that certainly should be fixed.