Bug#982591: grub-pc can't be updated non-interactively on debian/buster64
On 2/26/21 8:07 PM, Lucas Nussbaum wrote:
> On 14/02/21 at 08:48 +0100, Evgeni Golov wrote:
>> On Sat, Feb 13, 2021 at 11:57:52PM +0100, Thomas Lange wrote:
>>> IMO we cannot know which device name is used by the users virtualisation environment.
>>> So, what is the be setting without knowing the device name?
>>>
>>> Or is /dev/sda used in most enviroments?
>>
>> For VirtualBox sda is a pretty safe bet, for libvirt it'd be either sda
>> or vda (and I think we could set both in debconf, as that's a
>> multiselect). AWS has another one, vxda I think? But this explicit bug
>> is about vagrant (so virtualbox and libvirt) only anyways.
>>
>> The only thing to consider with this approach: it should only be done
>> when preparing images, not installing "real" systems. So in the
>> cloud.d.o context that's safe, but probably not as a generic default in
>> FAI and other tools.
>
> Maybe a better approach (but still hackish) would be to set it at first
> boot, in a way similar to
> https://salsa.debian.org/cloud-team/debian-vagrant-images/-/blob/master/config_space/files/etc/systemd/system/generate-sshd-host-keys.service/VAGRANT
>
> Running Something like:
> echo grub-pc grub-pc/install_devices multiselect $(awk '{ if ($2 == "/") { sub(/1$/, "", $1) ; print $1 } }' /proc/mounts) | debconf-set-selections
>
> Lucas
>
Hi,
I'm not a big fan of such boot-time hack.
Anyways, there's a big problem with the current way grub is attempting
to solve things. Using /dev/<foo> as the device where grub should
install itself is wrong in the first place. These days, the kernel is
discovering block devices in an asynchronous way, and the order of the
block device can be different at each boot of a computer.
I have such type of hardware in production, and I really don't know how
to tell grub that no, I can't tell that grub should be installed in
/dev/sda and /dev/sdb, because these same small SSD I use for the system
can be /dev/sdc and /dev/sde if I reboot...
So grub should adopt a new strategy. Like for example, accepting device
UUIDs or block device serial numbers as identifiers.
This could well be in another bug report, if someone hasn't opened it yet.
Cheers,
Thomas Goirand (zigo)
Reply to: