Comment 6 for bug 1993503

Hello Alberto,

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

As an example i did a manual install:
- stick to defaults but:
   - update to subiquity 22.10.1
   - keymap german
   - custom storage layout:
     - use vda and vdb as boot devices
     - raid-1 over vda2 vdb2
     - / on /dev/md0

This leaves /boot on /dev/md0. Within the installer, after install is
finished open a shell:
```
root@ubuntu-server:/# chroot /target/ debconf-show grub-pc | grep
grub-pc/install_devices:
* grub-pc/install_devices: /dev/vda, /dev/vdb
```
Everything looks good.

Reboot after install, in a shell:
```
root@danielk:/home/danielk# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
fd0 2:0 1 4K 0 disk
loop0 7:0 0 62M 1 loop /snap/core20/1587
loop1 7:1 0 47M 1 loop /snap/snapd/16292
loop2 7:2 0 79.9M 1 loop /snap/lxd/22923
sr0 11:0 1 1024M 0 rom
vda 252:0 0 10G 0 disk
├─vda1 252:1 0 1M 0 part
└─vda2 252:2 0 10G 0 part
   └─md0 9:0 0 10G 0 raid1
     └─md0p1 259:0 0 10G 0 part /
vdb 252:16 0 10G 0 disk
├─vdb1 252:17 0 1M 0 part
└─vdb2 252:18 0 10G 0 part
   └─md0 9:0 0 10G 0 raid1
     └─md0p1 259:0 0 10G 0 part /

root@danielk:/home/danielk# debconf-show grub-pc | grep
grub-pc/install_devices:
* grub-pc/install_devices: /dev/disk/by-id/md-name-ubuntu-server:0
root@danielk:/home/danielk# ls -l /dev/disk/by-id/md-name-ubuntu-server\:0
lrwxrwxrwx 1 root root 9 Oct 31 10:35
/dev/disk/by-id/md-name-ubuntu-server:0 -> ../../md0
```
cloud-init changes 'grub-pc/install_devices' to
'/dev/disk/by-id/md-name-ubuntu-server:0' which is a symlink to '/dev/md0'.

> 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
> ```

This is only possible for autoinstall. This bugreport is partly about
why disabling grub_dpkg in user-data better be the default for both
manual- and auto-install. (see
https://bugs.launchpad.net/cloud-init/+bug/1993503/comments/2)

> 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."

 From my point of view it does not work correctly.

> 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.

This is not about producing a bootable system or not. It just sets the
debconf-entry to a wrong device. With the next grub-update debconf let
you choose the correct devices. Running for example 'dpkg-reconfigure
grub-pc' in dialog frontend on the described setup asks to choose a disk
to install grub onto with no device preselected since '/dev/md0' or any
symlink to it is not in the list.
Running an auto-update of grub on the other hand brakes the update:
```
root@danielk:/home/danielk# debconf-show grub-pc | grep
grub-pc/install_devices:
* grub-pc/install_devices: /dev/disk/by-id/md-name-ubuntu-server:0
root@danielk:/home/danielk# dpkg-reconfigure -fnoninteractive grub-pc
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot
Partition; embedding won't be possible.
grub-install: warning: Embedding is not possible. GRUB can only be
installed in this setup by using blocklists. However, blocklists are
UNRELIABLE and their use is discouraged..
grub-install: error: diskfilter writes are not supported.
You must correct your GRUB install devices before proceeding:

   DEBIAN_FRONTEND=dialog dpkg --configure grub-pc
   dpkg --configure -a
```

In this example i had / on a raid-device, but cc_grub_dpkg also doesn't
work correctly if / is in an LVM with no extra partition for /boot as i
showed in https://bugs.launchpad.net/cloud-init/+bug/1993503/comments/3