On Fri, Jul 31, 2020 at 02:06:53PM -0700, Chad Phillips wrote: > This bug appears to affect a standard Vagrant install of Debian Buster as > well. After booting, upgrading, and rebooting, I'm faced with the error. > > The Vagrant base box is a fairly common one: > https://app.vagrantup.com/bento/boxes/debian-10
I can reproduce this, but it only happens if you upgrade grub-pc noninteractively, or if you upgrade it interactively and explicitly choose to ignore the relatively insistent prompts about installing GRUB somewhere. You can see the problem here, after "vagrant init bento/debian-10" and "vagrant up", before running the upgrade: vagrant@debian-10:~$ sudo debconf-show grub-pc | grep grub-pc/install_devices: * grub-pc/install_devices: /dev/disk/by-id/ata-VBOX_HARDDISK_VB9a8a894f-9374ac8c vagrant@debian-10:~$ ls -l /dev/disk/by-id total 0 lrwxrwxrwx 1 root root 9 Jul 31 22:24 ata-VBOX_HARDDISK_VBeefaa213-4b33f182 -> ../../sda lrwxrwxrwx 1 root root 10 Jul 31 22:24 ata-VBOX_HARDDISK_VBeefaa213-4b33f182-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Jul 31 22:24 ata-VBOX_HARDDISK_VBeefaa213-4b33f182-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Jul 31 22:24 ata-VBOX_HARDDISK_VBeefaa213-4b33f182-part5 -> ../../sda5 lrwxrwxrwx 1 root root 10 Jul 31 22:24 dm-name-debian--10--vg-root -> ../../dm-0 lrwxrwxrwx 1 root root 10 Jul 31 22:24 dm-name-debian--10--vg-swap_1 -> ../../dm-1 lrwxrwxrwx 1 root root 10 Jul 31 22:24 dm-uuid-LVM-AHa0Cuw3bi6DXPasmzrqEr387MQdhJrwITlGZz1P8nfxOHl0uLYcTkF0r0sDcIlc -> ../../dm-0 lrwxrwxrwx 1 root root 10 Jul 31 22:24 dm-uuid-LVM-AHa0Cuw3bi6DXPasmzrqEr387MQdhJrwvb35YFl6T9W6Vy8Gh8qyNGl96xAtCwRz -> ../../dm-1 lrwxrwxrwx 1 root root 10 Jul 31 22:24 lvm-pv-uuid-CP04tS-xWMP-4zmQ-WbUt-U8JQ-bIHD-IuGjp0 -> ../../sda5 It looks like the base VM image provided by bento/debian-10 hardcodes some details of how it was built that don't carry over to other systems booting the same image, and this causes problems. debian/buster64 has a similar problem, but with different details. It has: vagrant@buster:~$ sudo debconf-show grub-pc | grep grub-pc/install_devices: * grub-pc/install_devices: /dev/vda But when I booted that in virtualbox, /dev/vda doesn't exist. Upgrading grub-pc suggested that I install to /dev/sda instead. (I suspect /dev/vda would have worked with libvirt; I haven't used vagrant before and haven't yet managed to get its libvirt provider to work with some quirks of the libvirt setup on my laptop.) > I'm using the (admittedly insecure) solution of "sudo apt-mark hold grub*" > shown here: https://askubuntu.com/a/1263204 As several comments there note, a better fix is "sudo dpkg-reconfigure grub-pc". This is in some ways the most interesting subtype of this bug, because it's one we can easily reproduce! It falls into the category of "error in a cloning process"; but it also makes it relatively straightforward to experiment with ways to mitigate the problem further. We could at minimum make this be an upgrade error in the noninteractive case, ensuring that it doesn't touch modules if the target device is just plain missing: the upgrade error might be a bit rough for some people, but it would be better than a boot failure. A refinement of this might be that if the system only has one disk, and that disk appears to have GRUB installed on it (by relatively crude boot sector scanning), then we could assume that this is the common case of a disk having been swapped out and automatically change grub-pc/install_devices to point to that instead. With appropriate guard rails, I think that could help quite a lot of the people affected by this sort of problem. -- Colin Watson (he/him) [cjwat...@debian.org]