Comment 2 for bug 1635181

Writing to /etc/default/grub can cause upgrade problems:

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/901600

That includes either updating it to indicate that we've modified
the default configuration to match the environment or writing
out the deployed configuration directly, wholesale replacement.

I had suggested that maybe we could document this in packaged
version of /etc/default/grub in grub2, to indicate that variables
can be overridden by configurations in grub.d

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1569567

In there, Mathieu has some alternatives; but it's not clear that any of
those handle all of the various situations we have.

1) cloud-images include a baked in console=ttyS0 which is highly useful
   for booting the images in VMs where we can have a serial all the time

2) in maas we re-use the cloud-images but real machines may or maynot have a ttyS0
   and so curtin adapted to always updating the grub config based on how
   maas booted the image;

3) to avoid upgrade issues, curtin did not modify /etc/default/grub directly

4) if curtin lets values from /etc/default/grub to be included in the configuration
   it writes (for example appending maas boot params in addition to what's built in
   to grub2) this may present conflicts; and maas/curtin own what that command
   line ought to be. Filtering isn't a solution either, curtin is only involved
   during deployment; if a dist-upgrade of grub2 introduces a new boot parameter
   it might affect the image booting.

Given the above scenarios I still believe my suggestion of documenting in the grub2 package version of /etc/default/grub that 'grub.d' directory may contain configurations that
override the values of /etc/default/grub seems the best course. This directs users who attempt to modify /etc/default/grub to check for contents in /etc/default/grub.d to see if their changes are shadowed, or rather to direct changes to those .d files.