Hello, there was no system update or an installation. It booted perfect. I simply switched the PC off and the next time it does not boot any more! Every entry of the boot menu ends up with the attached screenshot. To recover the PC i had to boot an Debian 10 installation from SD-Card and select recover of grub. I have no idea if this is reproducible and the search for such an error is empty. So i report it here, if someone has the same error. Cheers karsten
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. What does "sudo debconf-show grub-pc" say?
Am 03.03.21 um 18:00 schrieb Colin Watson: 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? An upgrade on an other partition to Debian 11 (Testing) failed, so it is not an good idea to use grub on an failed installation. grub-pc/install_devices_empty: false grub2/device_map_regenerated: grub2/kfreebsd_cmdline_default: quiet grub-pc/disk_description: grub2/force_efi_extra_removable: false grub2/update_nvram: true grub-pc/install_devices_failed_upgrade: true * grub-pc/install_devices: /dev/disk/by-id/ata-TOSHIBA_DT01ACA200_84H86A0GS * grub2/linux_cmdline: grub-pc/partition_description: grub-pc/hidden_timeout: false grub-pc/install_devices_failed: false grub-pc/timeout: 5 grub2/kfreebsd_cmdline: grub-pc/kopt_extracted: false grub-pc/mixed_legacy_and_grub2: true grub-pc/chainload_from_menu.lst: true grub-pc/postrm_purge_boot_grub: false * grub-pc/install_devices_disks_changed: /dev/disk/by-id/ata-TOSHIBA_DT01ACA200_84H86A0GS-part3 * grub2/linux_cmdline_default: quiet
I can't help you with that, but it shouldn't be too hard to find documentation. [...] 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.
Hello folks -- +1 here, same problem, same solution.
Hello Colin, Am 03.03.21 um 19:03 schrieb Colin Watson: I just purged the package unattended-upgrades now. I have not altered anything all the time. Yesterday the error appears and has gone after the manual installation, without altering the BIOS settings (see screenshots). So this is the configuration all the time: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1,8T 0 disk ├─sda1 8:1 0 10G 0 part ├─sda2 8:2 0 40G 0 part ├─sda3 8:3 0 40G 0 part ├─sda4 8:4 0 1K 0 part ├─sda5 8:5 0 256M 0 part [SWAP] ├─sda6 8:6 0 40G 0 part /win └─sda7 8:7 0 1,7T 0 part /srv sdb 8:16 0 119,2G 0 disk ├─sdb1 8:17 0 40G 0 part / ├─sdb2 8:18 0 40G 0 part /P2 └─sdb3 8:19 0 39,2G 0 part A general question: It's not possible that grub work independent from the BIOS? The BIOS is doing more and more things the user does not want. I understand what you want to avoid with this, but if the SSD fails, it make no sense to boot a wrong grub according to the installed OS on the HDD. Cheers karsten
I have the same error message after the update to grub2/2.02+dfsg1- 20+deb10u4, but with grub-efi-amd64* instead of grub-pc. After pressing the "arbitrary key", Debian boots but fails to start lightdm. Should I report a new bug? Marco
Anything involving UEFI is distinct from this bug, so please report it separately with full details.
Hey, I can confirm this bug. After apt-get upgrade from deb10u3 to deb10u4 and reboot, system boot hangs und grub must be reinstalled via rescue-system. Seems to be the SAME bug as a during the last failed upgrade a few months ago. Regards, Bernd
It happens during auto-upgrade on systems with more than one disk (here raid1 /dev/md*) and due to inconsistent installation information in grub-pc: root@gkmonitor:~# debconf-show grub-pc | grep /install_devices: * grub-pc/install_devices: /dev/disk/by-id/ata-ST2000DM001-1ER164_Z4Z3JAP0 with: root@gkmonitor:~# ls -l /dev/disk/by-id/ insgesamt 0 lrwxrwxrwx 1 root root 9 Mär 5 09:37 ata-ST2000DM001-1ER164_Z4Z3JAP0 -> ../../sdb lrwxrwxrwx 1 root root 9 Mär 5 09:37 ata-ST2000DM001-1ER164_Z4Z3JBQN -> ../../sda lrwxrwxrwx 1 root root 9 Mär 5 09:37 md-name-gkmonitor:0 -> ../../md0 lrwxrwxrwx 1 root root 9 Mär 5 09:37 md-name-gkmonitor:1 -> ../../md1 So automatic upgrade will do grub-install into /dev/sdb and not /dev/sda. Booting from /dev/sda via BIOS will result in error. Fixing it with grub-install /dev/sda. dpkg-reconfigure grub-pc will give the option to select all disks, resulting in: root@gkmonitor:~# debconf-show grub-pc | grep /install_devices: * grub-pc/install_devices: /dev/disk/by-id/ata-ST2000DM001-1ER164_Z4Z3JBQN, /dev/disk/by-id/ata-ST2000DM001-1ER164_Z4Z3JAP0 On next upgrade, the grub-install script will hopefully upgrade all disk MBRs Regards, Bernd
affected system was misconfigured at that time), how is it that you didn't fix the configuration at that point? (I'm genuinely curious about how people would run into the same class of failure twice on the same system, since once you've fixed grub-pc/install_devices you should be good for future upgrades.)
The last time I just fixed it via the rescue grub-install and did not made a bug report neither looked up the bug investigating for the reason. So this second time I looked up wtf could be the reason and found the missing uuid in the configuration - well I am not a guru, just a user ;-) Am 05.03.21 um 12:30 schrieb Colin Watson:
I also hit this today with the latest upgrade. On a system that has
been upgraded many times in the past. It's 2.02+dfsg1-20+deb10u4
upgrade this week caused it to fail to boot. It's was installed in
2014 and upgraded continuously since then.
root@euphoria:~# ll /var/log/installer/syslog
-rw------- 1 root root 281561 Jan 6 2014 /var/log/installer/syslog
root@euphoria:~# grep 'Installing grub on' /var/log/installer/syslog
Jan 6 21:12:29 grub-installer: info: Installing grub on '/dev/sda'
Initially installed with one disk in degraded RAID mode and then
subsequently additional disks were added. grub-install was used to
install grub to the new disks.
There are two ways to use the debian-installer in rescue mode. One is
to execute a chroot to the installed system and then install grub from
there. In that mode there are two ways to update grub.
Boot rescue mode. Using the debian-installer directly:
1. Reinstall GRUB bootloader
2. Execute a shell in /dev/sdX
2.1. grub-install /dev/sdX
2.2. dpkg-reconfigure grub-pc
The first way updates the disk grub image okay but does not update the
debconf settings.
The second way updates the disk grub image okay but does not update the
debconf settings.
Only the third way updates the disk grub image okay and also updates
the debconf settings.
Due to the use of /dev/disk/by-id/... I can also imagine that
replacing a failed disk would also create another situation where grub
bits are updated but debconf is not kept in sync. I am sure that
accounts for several failures I have experienced in the past but did
not understand the root cause of why at the time.
The root cause of this bug appears to be the abuse of debconf as a
registry. I always thought that was explicitly forbidden. It's clear
from this bug that debconf is required to be up to date and in sync or
upgrades will fail. At the least it should be strongly documented
that grub-install does not update debconf and the package relies upon
the debconf configuration for operation. I was completely unaware of
this requirement before today.
I really think the grub package should declare a config file (that is
not debconf) for what devices need updates. Then it would be plain
and simple to the local admins what files need to be updated to allow
grub to automatically upgrade.
Bob
Hello, I experienced the same problem on a couple of my machines too. Yes, technically a misconfiguration at my end, but the number of me-too's suggests that there are many others not realising that debconf needs to know about *every* bootable disk to avoid this sort of issue. I know it's not your fault and is a bit annoying, but I suggest that grub check for and complain if it notices disks that have grub installed on it, yet are not listed in debconf's install_devices (eg. because at some point in the (possibly distant) past, the admin ran grub-install manually, and/or used a rescue disk to (re)install grub). In the absence of such an actual check, perhaps just put a reminder in NEWS.Debian to the effect that running grub-install behind debconf's back may have unforseen consequences, and that a bootloader installed in this way will not get updated automatically.
Hi, just to inform that I suffered this problem too, after upgrading my system to Debian 10.9 (in the last security upgrade several days ago). I agree that the problem arose due to a misconfiguration in my system, as my main HDD was broken several months ago, so I "cloned" the system onto the new HDD, but I installed grub manually onto the new HDD, but I forgot to update debconf. The last time I replaced a HDD was 15 years ago, when LILO was the boot loader, so I did not take into account debconf for grub, my mistake. Anyway, in the upgrade process, I suggest to show a warning like other packages do (as example when a different version of kernel is running not corresponding to the driver version you are installing) to prevent to have an "inaccessible" system. If needed, I can open a new bug, with severity "wish list" to request this feature or to keep this bug open until the warning is implemented, so if other people have the same problem can fix it quickly. Thank you for your great work. Sincerely, Jose