[Bug 1635181] Re: Curtin sneaks config into /etc/default/grub.d/
Mathieu Trudel-Lapierre
mathieu.tl at gmail.com
Wed Jan 23 16:53:45 UTC 2019
As an update to this:
I think we agreed (in a short meeting between people involved in curtin,
cloud-init, grub2, etc.) that installers are indeed meant to be
authoritative on writing /etc/default/grub.
One work item that came out of this was to at the very least make it
clear what files are being used to generate grub.cfg. I've uploaded this
to Disco already:
https://launchpad.net/ubuntu/+source/grub2/2.02+dfsg1-5ubuntu9
The same fixes are also being prepared for SRU in 18.04 and 18.10 (they
should be available in -proposed incessantly).
I opened bug 1812863 since I didn't know this one was here --
regardless, there'd still be the question of handling config merging
when grub2 expects to have distro-wide defaults, installers write their
own things, and on top of that users might want to make configuration
changes. This is still an issue we'll have to handle when curtin/cloud-
init do write to /etc/default/grub directly, so this here bug can remain
open with a grub2 task to denote the work that is needed there. We've
already started looking into how to handle it, too.
For the time being, running 'update-grub' will provide additional
information on what files are being sourced to generate the final
grub.cfg configuration file that lands in /boot/grub/grub.cfg:
$ sudo update-grub
[sudo] password for mtrudel:
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/50-curtin-settings.cfg'
Generating grub configuration file ...
[...]
done
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1635181
Title:
Curtin sneaks config into /etc/default/grub.d/
Status in curtin:
New
Status in grub2 package in Ubuntu:
Triaged
Bug description:
Curtin puts content into /etc/default/grub.d/ but doesn't indicate
that anything is wrong with /etc/default/grub
Since curtin is the authoritative installation, it can freely setup
grub the way it believes it should look. At the moment, we end up with
a very misleading picture, because /etc/default/grub looks
authoritative but is completely and invisibly sidelined by
/etc/default/grub.d/
So either just put the desired state into /etc/default/grub (leaving
grub.d/ empty) or replace /etc/default/grub with a file that clearly
indicates that the magic is now in /etc/default/grub.d/
To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1635181/+subscriptions
More information about the foundations-bugs
mailing list