grub-pc gets confused by variables in /etc/default/grub.d/*.cfg files

[Cs-gon]

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.

[Cs-gon (cs-gon)]

Some additional information that might be helpful:

The affected systems get installed and updated automatically, and to have a defined state regarding the configuration files, we have the following setting in /etc/apt/apt.conf:

DPkg::Options {"--force-confnew";"--force-confmiss";};

So new packages should always install the maintainer version of the configuration file.