Comment 17 for bug 2060695

@Mate thanks for the patch suggestion and triage work here.

While this approach will work for live-server/live-desktop and or Ubuntu cloudimage which have downstream grub2 deb fixes for handling the 'new' grub-pc/cloud_style_intialization debconf setting, are we missing other use-cases that will fall over if cloud-init never attempts to detect the proper boot device on image launch?

Does this issue also affect debian upstream too which may not set grub-pc/cloud_style_initialization? - I'm not seeing the comparable changes in upstream debug grub2 that'd take care of properly determining the boot device based on the debconf grub-pc/cloud_style_installation boolean.

This bug feels like it is reminiscent of LP: 1993503 which affects live server(subiquity/curtin based) installs which are perfoming that disk setup in the first place.

I'm concerned about complete removal of cloud-init's grub_dpkg module as a solution because it's a big hammer.
Without cloud-init's cc_grub_dpkg module, cloud-init may not find the right boot devices if grub2 doesn't support the grub-pc/cloud_style_installation boolean or if subiquity wasn't involved in the initial disk setup.

An additional concern is image creation tools like packer currently rely on cloud-init's behavior to detect and correct debconf grub-pc/install_devices values in 'first boot' scenerios to ensure the boot device is found https://bugs.launchpad.net/cloud-init/+bug/1993503/comments/6. Dropping the module completely from cloud.cfg prevents any workaround in user-data or vendor-data to re-enable this module for some unsatisfied corner-cases.

If we were to change anything in cloud-init's behavior of related to grub2, maybe we limit this changeset to setting the default of the "grub_dpkg" config module[1] to "enabled: false" so it makes no changes by default. This would still permit users or platforms the ability to provide "grub_dpkg: {enabled: true}" in either #cloud-config userdata or cloud vendor-data if the default behavior was insufficient.

[1] https://github.com/canonical/cloud-init/blob/24.1/cloudinit/config/cc_grub_dpkg.py#L148

From live installer(subiquity/curtin) derived images which are performing disk setup, it would be possible for those images to provide /etc/cloud/cloud.cfg.d/ configuration snippet to disable cloud-init's cc_grub_dpkg configuration module which would prevent this specific issue in the first place as cloud-init would not attempt to use grub probe to provide debconf selections to grub-pc in when it encourters this config.

grub_dpkg:
  enabled: false