@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 downstreams 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 unstatisfied 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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2060695

Title:
  24.04 grub-pc cannot upgrade on mirrored software RAID root disk

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/2060695/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to