On Sat, Aug 01, 2020 at 01:23:30AM +0200, MichaIng wrote: > 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.
Indeed. > 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. That's fairly close to one of my suggestions in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966575#102. It's not necessary to move things to the preinst to make this work; it just needs to be checked a bit more thoroughly before the postinst runs grub-install. > 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? In principle it's impossible. In practice it may be possible to do some degree of guesswork; that's one of my other suggestions in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966575#102. :-) We do have to be pretty conservative though, as going overboard is likely to break some multiboot setups. -- Colin Watson (he/him) [cjwat...@debian.org]