Comment 6 for bug 1569567

Reopening; I think we need to handle this better and let users actually supplement whatever MAAS, curtin, and other tools do with their own custom, environment-specific configs.

My initial suggestion would be to expect/fix all the other providers of files in that directory to carry on values set previously or explicitly remove options that are explicitly conflicting (and being very clear that they do that).

In other words:
 1) (optionally) fix grub2 to have only GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub and document to users that this is the place they are expected to set their custom values; just for simplicity.
 2) fix providers of files in /etc/default/grub.d to set GRUB_CMDLINUX_LINUX_DEFAULT="${GRUB_CMDLINE_LINUX_DEFAULT} whatever_it_needs"
 3) providers of files in /etc/default/grub.d should explicitly 'GRUB_CMDLINE_LINUX_DEFAULT=$(echo GRUB_CMDLINE_LINUX_DEFAULT | grep -v conflicting_option)' if they explicitly can't work with some option in particular (I expect few cases of this).

This would allow maintaining the expectation of our users that configs being set in /etc/default/grub are taken into account for their deployments. Otherwise, we should move /etc/default/grub to be early in /etc/default/grub.d and update all documentation to make this change obvious, along with clearly documenting that it can be overridden by any subsequent file in the same directory. The issue I have with that is that it potentially means that environment-specific changes will, over time, creep into many of the config files if things are later added/installed that ship their own grub configs.

Thoughts?