Bug#984426: grub suddenly does not boot and ends up with "grub_register_command_lockdown not found"

[Colin Watson]

On Wed, Mar 03, 2021 at 06:24:30PM +0100, Karsten wrote:
> Am 03.03.21 um 18:00 schrieb Colin Watson:
> > Since you're reporting this against grub-pc 2.02+dfsg1-20+deb10u4, and
> > since the mentioned grub_register_command_lockdown symbol was only
> > introduced in that version, then there must have been a system update,
> > because we only released that version yesterday.
> 
> A search shows in /var/log/apt/history.log
> 
> Start-Date: 2021-03-03  09:28:01
> Commandline: /usr/bin/unattended-upgrade
> Upgrade: grub-common:amd64 (2.02+dfsg1-20+deb10u3, 2.02+dfsg1-20+deb10u4), grub2-common:amd64 (2.02+dfsg1-20+deb10u3,
> 2.02+dfsg1-20+deb10u4), grub-pc:amd64 (2.02+dfsg1-20+deb10u3, 2.02+dfsg1-20+deb10u4), grub-pc-bin:amd64
> (2.02+dfsg1-20+deb10u3, 2.02+dfsg1-20+deb10u4)
> End-Date: 2021-03-03  09:28:36
> 
> Start-Date: 2021-03-03  17:03:42
> Reinstall: grub-pc:amd64 (2.02+dfsg1-20+deb10u4)
> End-Date: 2021-03-03  17:04:12
> 
> 
> How can such "unattended-upgrade" be killed?

I can't help you with that, but it shouldn't be too hard to find
documentation.

> > What does "sudo debconf-show grub-pc" say?
[...]
> * grub-pc/install_devices: /dev/disk/by-id/ata-TOSHIBA_DT01ACA200_84H86A0GS

According to the information in your initial report, this is your
/dev/sda.  I strongly suspect that your BIOS is actually loading the
boot loader from one of the other disks in your system, probably
/dev/sdb.  Unfortunately it is more or less impossible to reliably
determine this from the operating system (I tried some years back and
failed).

I would recommend using "sudo dpkg-reconfigure grub-pc" to tell the GRUB
packaging to install the boot loader to the master boot records of *all*
the non-removable disks on your system, which avoids this class of
problem since then it doesn't matter which one the BIOS boots from.

-- 
Colin Watson (he/him)                              [cjwatson at debian.org]