Public bug reported:
I have made a Debian package, that installs a *.cfg file into
/etc/default/grub.d/ with the following contents:
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT
usbcore.authorized_default=0"
The package runs update-grub in its postinst script.
The idea is, of course, to add "usbcore.authorized_default=0" to the
kernel command line without having to edit /etc/default/grub. When the
package gets installed after grub-pc is installed, everything seems to
work as expected at first.
But with every grub-pc update, /etc/default/grub gets changed and every
time "usbcore.authorized_default=0" gets added to the
GRUB_CMDLINE_LINUX_DEFAULT variable in /etc/default/grub, and the
corresponding debconf variable gets updated to this value too. So with
every update of grub-pc new redundant parameters are added to the kernel
command line, and the kernel command line gets longer and longer.
When my package gets installed before grub-pc (during a complete
re-installation of the system), then /etc/default/grub will contain the
following:
GRUB_CMDLINE_LINUX_DEFAULT="usbcore.authorized_default=0"
So in this case, the default value ("quiet splash") gets discarded
completely.
Is this working as intended? I would assume, that grub-pc should leave
the GRUB_CMDLINE_LINUX_DEFAULT variable and the corresponding debconf
variable unchanged.
I also tried a different approach, that is putting a file in
/etc/default/grub.d/ with the following contents:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbcore.authorized_default=0"
With this approach it is not possible to build multiple packages that
each just add a single parameter to the kernel command line. But for my
use-case this would be sufficient, but the value above ("quiet splash
usbcore.authorized_default=0") still gets populated into
/etc/default/grub and the corresponding debconf variable. So, when my
package gets removed, I still have to modify /etc/default/grub and the
debconf variable, to clean everything up, which I think the whole
/etc/default/grub.d/ mechanism should prevent me from having to do.
So this leads me to believe that the /etc/default/grub.d/ mechanism in
grub-pc is broken.
I think the problem is, that the config maintainer script of the package
grub-pc is sourcing /etc/default/grub AND /etc/default/grub.d/*.cfg, when
trying to find a sensible value for GRUB_CMDLINE_LINUX_DEFAULT, and then writes
it back into the debconf database.
I think the config script should only source /etc/default/grub, but not
/etc/default/grub.d/*.cfg.
Looking at the config maintainer script, the problem seems exist in all Ubuntu
versions from Precise (probably even Quantal, haven't checked that, but IMHO
this was when /etc/default/grub.d was introduced) to Wily. I have tested it
myself in Precise and Trusty.
** Affects: grub (Ubuntu)
Importance: Undecided
Status: New
** Summary changed:
- grub-pc gets confused by variables /etc/default/grub.d/*.cfg files
+ grub-pc gets confused by variables in /etc/default/grub.d/*.cfg files
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1543647
Title:
grub-pc gets confused by variables in /etc/default/grub.d/*.cfg files
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub/+bug/1543647/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
