Comment 5 for bug 1993503

Hello Daniel,

Maybe it is worth fully describing how do you drive the autoinstallation. If you run subiquity manually, describing what steps do you execute.

Additionally, the installer logs might also be useful. They are located under /var/log/installer, make sure to redact any sensible information.

> https://bugs.launchpad.net/cloud-init/+bug/1993503/comments/2

For the cases where grub_dpkg should be detected and it is not, a user can enforce that as workaround by adding the following in the autoinstall.yaml:

```
#cloud-config
autoinstall:
  version: 1
  # ...
  user-data:
    grub_dpkg:
      enabled: False
```

> https://bugs.launchpad.net/cloud-init/+bug/1993503/comments/3
> why not just skip setting the "grub-pc/install_devices" item if it is already set in debconf and there is no "grub-pc/install_devices" given in cc_grub_dpkg config?

That sounds like a reasonable behavior in this case, running an installer where grub was installed either by subiquity or by the user. But, in other scenarios, this might not fit or change how users expect grub_dpkg to behave. Per the docs [1], "This module should work correctly by default without any user configuration."

> It picks the "disk/by-id" item (/dev/disk/by-id/dm-name-vg0-lv_root) and sets the grub-pc debconf item "grub-pc/install_devices" to that. This is in almost any case not a good choice.

I agree, this is probably not a good choice in almost any case, but produces a bootable system. Assuming that, aside the change of behavior, I do not see any actionable point in this bug from cloud-init's perspective.

[1] https://cloudinit.readthedocs.io/en/latest/topics/modules.html#grub-dpkg