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