Hey guys,
we face the same issue whenever a ready-to-run image has been created
and booted from a different device.
From what we found, the Debian installer (or the grub install/config
scripts) stores the hardware ID of the drive to debconf database, if one
is available. Of course on a different machine this identifier and the
related /dev/disk/by-id/ path is invalid. On VirtualBox and non-virtual
PCs this is usually the case, on VMware on the other hand, ho hardware
identifier exists, hence /dev/sda is stored there which is still valid
when importing the same image to other VMware machines.
Since there is no software ID for non-fs disks like a UUID, the
behaviour to use the hardware ID seems reasonable, to not rely on the
bid unpredictable /dev/sd* path. However that this easily leads to
unbootable systems when doing such trivial thing like booting a disk
image and run some automated package upgrades on a new machine is a
serious issue.
I suggest to do the grub target check on `preinst` and skip/fail with
error code if the debconf entry is invalid. It is better to skip or
break the package upgrade and force admins to check/run manually then
letting them running into a unbootable system.
Otherwise elegant would be a scan to find the matching grub instance,
but not sure how easy this is. At least the bootloader locations are fixed?
Proactive fix, where "/dev/sda" needs to be replaced in case:
-------
debconf-set-selections <<< 'grub-pc grub-pc/install_devices multiselect
/dev/sda'
-------
Or of course use the hardware identifier path found in /dev/disk/by-id/.
Best regards,
Micha
