Bug#982591: marked as done (grub-pc can't be updated non-interactively on debian/buster64)
Your message dated Sun, 28 Feb 2021 15:19:55 +0100
with message-id <20210228141955.GA5558@xanadu.blop.info>
and subject line Re: Bug#982591: grub-pc can't be updated non-interactively on debian/buster64
has caused the Debian Bug report #982591,
regarding grub-pc can't be updated non-interactively on debian/buster64
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
982591: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982591
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: cloud.debian.org
Ohai,
when trying to update a VM based on the debian/buster64 box from 10.4 to
10.8, grub-pc can't be upgraded non-interactively because it doesn't
know which devices to install GRUB to (grub-pc/install_devices debconf
question is empty) and that's a fatal error for GRUB.
In our environment I "fixed" that by setting
grub-pc/install_devices_empty to "true" (AKA "it's okay to not install
GRUB to any devices during upgrade"), as we don't exactly care about the
box being rebootable. However I think this should be
ultimately be fixed inside the box in a nicer way? Maybe a first-boot
script that checks what device the system booted of (sda, vda, whatever)
and sets grub-pc/install_devices to that device?
Thanks a ton for maintaing those boxes!
Evgeni
--- End Message ---
--- Begin Message ---
On 27/02/21 at 21:32 +0000, Evgeni Golov wrote:
>
>
> On February 27, 2021 8:44:44 PM UTC, Lucas Nussbaum <lucas@debian.org> wrote:
> >On 27/02/21 at 15:16 +0100, Evgeni Golov wrote:
> >> On Fri, Feb 26, 2021 at 10:54:32PM +0100, Lucas Nussbaum wrote:
> >> > Tentative patch:
> >> > https://salsa.debian.org/cloud-team/debian-vagrant-images/-/commit/b82d522f65b507767f909b2b9471c5a9ade75e05
> >>
> >> Thanks Lucas! That looks quite like the "first-boot script" I mentioned
> >> in the original report.
> >>
> >> One q tho: isn't `findmnt --noheadings --output SOURCE /` easier to read
> >> than running awk on /proc/mounts? It's in util-linux and that's
> >> essential anyways :)
> >
> >Ah, thanks, I did not know about findmnt. Yes, that would be better.
> >
> >(We would still need to get the disk, not the partition)
>
> lsblk --output PKNAME /dev/sda1 will give you sda :)
> Also from util-linux.
> Might not work reliably when there is lvm/devicemapper in-between, but that shouldn't be a problem in this particular case.
Thanks!
So this is fixed in today's update of the images.
The final fix is
https://salsa.debian.org/cloud-team/debian-vagrant-images/-/commit/ac1f9d47d26148b8615866fbeec3c0ee9f35c1ab
Lucas
--- End Message ---
Reply to: