Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
package grub-efi-amd64
found 984760 2.02+dfsg1-20+deb10u4
thanks
Hello,
I also had this issue when upgrading from stretch to buster.
For me the BIOS allowed be to select the EFI image to boot, so I was
able to boot into the system that way, then the fix was to:
1) run again update-grub2 and
2) dpkg-reconfigure -plow grub-efi-amd64
After this the old FreeDOS images (HP diagnostics and FreeDOS) I have
were no longer booting via grub, but I kept them just in case and I
still can boot them via direct EFI image selection from BIOS.
Some info on my system:
eddy@aptonia:~ $ ll /dev/disk/by-id/
total 0
lrwxrwxrwx 1 root root 10 sep 2 14:44 dm-name-nmve-home -> ../../dm-1
lrwxrwxrwx 1 root root 10 sep 2 14:44 dm-name-nmve-lvcrypt -> ../../dm-3
lrwxrwxrwx 1 root root 10 sep 2 14:44 dm-name-nmve-root -> ../../dm-0
lrwxrwxrwx 1 root root 10 sep 2 14:44 dm-name-nmve-swap -> ../../dm-2
lrwxrwxrwx 1 root root 10 sep 2 14:44
dm-uuid-LVM-dszzt4JF4qOrlcZdVIM8pF8M4cwQBR3TCeJFI4DcmZKcD7dPi6cIdHpueQNgBHPY
-> ../../dm-3
lrwxrwxrwx 1 root root 10 sep 2 14:44
dm-uuid-LVM-dszzt4JF4qOrlcZdVIM8pF8M4cwQBR3TgemRtgdFDbSpUbPwRC2XuZlz0qd2TAe6
-> ../../dm-1
lrwxrwxrwx 1 root root 10 sep 2 14:44
dm-uuid-LVM-dszzt4JF4qOrlcZdVIM8pF8M4cwQBR3Thu3VxxfPFVJ2y1xVoBWopwxAdqh3RMNv
-> ../../dm-2
lrwxrwxrwx 1 root root 10 sep 2 14:44
dm-uuid-LVM-dszzt4JF4qOrlcZdVIM8pF8M4cwQBR3TLNIBeUak8X026nSToUE5QcrOpTfiuJfM
-> ../../dm-0
lrwxrwxrwx 1 root root 15 sep 2 14:44
lvm-pv-uuid-ZkjWrn-o4q3-wkB8-kvLh-k0L1-jRsM-9Wj11m -> ../../nvme0n1p5
lrwxrwxrwx 1 root root 13 sep 2 14:44 nvme-eui.ace42e008509e89f ->
../../nvme0n1
lrwxrwxrwx 1 root root 15 sep 2 14:44 nvme-eui.ace42e008509e89f-part1
-> ../../nvme0n1p1
lrwxrwxrwx 1 root root 15 sep 2 14:44 nvme-eui.ace42e008509e89f-part2
-> ../../nvme0n1p2
lrwxrwxrwx 1 root root 15 sep 2 14:44 nvme-eui.ace42e008509e89f-part3
-> ../../nvme0n1p3
lrwxrwxrwx 1 root root 15 sep 2 14:44 nvme-eui.ace42e008509e89f-part5
-> ../../nvme0n1p5
lrwxrwxrwx 1 root root 13 sep 2 14:44
nvme-SK_hynix_BC501_HFM256GDJTNG-8310A_NJ8CN75131210CU3L ->
../../nvme0n1
lrwxrwxrwx 1 root root 15 sep 2 14:44
nvme-SK_hynix_BC501_HFM256GDJTNG-8310A_NJ8CN75131210CU3L-part1 ->
../../nvme0n1p1
lrwxrwxrwx 1 root root 15 sep 2 14:44
nvme-SK_hynix_BC501_HFM256GDJTNG-8310A_NJ8CN75131210CU3L-part2 ->
../../nvme0n1p2
lrwxrwxrwx 1 root root 15 sep 2 14:44
nvme-SK_hynix_BC501_HFM256GDJTNG-8310A_NJ8CN75131210CU3L-part3 ->
../../nvme0n1p3
lrwxrwxrwx 1 root root 15 sep 2 14:44
nvme-SK_hynix_BC501_HFM256GDJTNG-8310A_NJ8CN75131210CU3L-part5 ->
../../nvme0n1p5
eddy@aptonia:~ $ ll /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 sep 2 14:44
2615ddb7-eab6-428c-9291-c3245b41c1f3 -> ../../dm-2
lrwxrwxrwx 1 root root 15 sep 2 14:44 2C53-59FF -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 10 sep 2 14:44
53ff31db-a553-42be-85ab-720ffcb070a7 -> ../../dm-0
lrwxrwxrwx 1 root root 10 sep 2 14:44
61f9b8c2-bc4d-46e4-8a2c-b1e443a54f48 -> ../../dm-3
lrwxrwxrwx 1 root root 15 sep 2 14:44 6A53-125B -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 10 sep 2 14:44
714a3bfa-0c2e-4bb1-a800-407ed7bf0556 -> ../../dm-1
eddy@aptonia:~ $ cat /proc/mdstat
cat: /proc/mdstat: No such file or directory
eddy@aptonia:~ $ dpkg -l | grep grub-efi-amd64
ii grub-efi-amd642.02+dfsg1-20+deb10u4
amd64GRand Unified Bootloader, version 2 (EFI-AMD64
version)
ii grub-efi-amd64-bin2.02+dfsg1-20+deb10u4
amd64GRand Unified Bootloader, version 2 (EFI-AMD64
modules)
ii grub-efi-amd64-signed 1+2.02+dfsg1+20+deb10u4
amd64GRand Unified Bootloader, version 2 (amd64
UEFI signed by Debian)
eddy@aptonia:~ $ cat /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_msdos
insmod lvm
insmod ext2
set
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
On 7/17/21 10:09 AM, Ryan Thoryk wrote: On 7/17/21 9:44 AM, Steve McIntyre wrote: I found that I was using an older ARM image from last year, but that doesn't mean the issue was fixed later. In AWS's community AMI section, the main one I tried is listed as "debian-10-arm64-20200511-260". When you launch it, if you do a package upgrade it installs a newer version of grub. Then running a grub-install makes it unbootable. If you do the dpkg-reconfigure method, you have to choose "yes" to the "force extra installation" question, if you choose "no", it won't boot anymore. I tried launching a newer AMI, titled "debian-10-arm64-20210621-680", and that one reboots fine if you do a "grub-install", but that's because it didn't install a newer version of grub, since the packages are recent. I don't know what would happen if it installed a newer grub, you might have to look into that. In the boot folder the EFI boot loader is listed as "/boot/efi/EFI/BOOT/BOOTAA64.EFI", there's no "EFI/debian" folder. I'm not sure what they did to generate the AMI image. The AMI IDs I used are: ami-00249fe66e0872181 and ami-025a7500c83d92798 I didn't try the Marketplace one. One thing to add to that - when I did a "grub-install" on the newer AMI, it didn't write a "EFI/debian" folder, just an "EFI/BOOT" folder, which means that it might be working properly. If that's the case, then the older instances are broken, which would affect existing systems. I'm not sure if a grub upgrade would change that or not. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
On 7/17/21 9:44 AM, Steve McIntyre wrote: Hi Ryan, So when you say "spin up a new Debian ARM VM on AWS", what exact image are you using here? It sounds like the build process for that image needs to be fixed to DTRT for the platform. Then you and other users won't be bitten by this problem... I found that I was using an older ARM image from last year, but that doesn't mean the issue was fixed later. In AWS's community AMI section, the main one I tried is listed as "debian-10-arm64-20200511-260". When you launch it, if you do a package upgrade it installs a newer version of grub. Then running a grub-install makes it unbootable. If you do the dpkg-reconfigure method, you have to choose "yes" to the "force extra installation" question, if you choose "no", it won't boot anymore. I tried launching a newer AMI, titled "debian-10-arm64-20210621-680", and that one reboots fine if you do a "grub-install", but that's because it didn't install a newer version of grub, since the packages are recent. I don't know what would happen if it installed a newer grub, you might have to look into that. In the boot folder the EFI boot loader is listed as "/boot/efi/EFI/BOOT/BOOTAA64.EFI", there's no "EFI/debian" folder. I'm not sure what they did to generate the AMI image. The AMI IDs I used are: ami-00249fe66e0872181 and ami-025a7500c83d92798 I didn't try the Marketplace one. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
Hi Ryan, On Sat, Jul 17, 2021 at 09:19:22AM -0500, Ryan Thoryk wrote: >On 7/17/21 8:18 AM, Steve McIntyre wrote: >> On Sat, Jul 17, 2021 at 07:57:48AM -0500, Ryan Thoryk wrote: >> EFI/debian is *NOT* wrong, it's the correct location for a system that >> has working firmware which supports setting UEFI boot variables. If >> you *also* need to write a copy of grub (etc.) to the removable media >> location (EFI/boot) then that's supported as well by the Debian >> packaging - run "dpkg-reconfigure grub-efi-arm64" and say yes when the >> system asks about that. > >Thanks for that suggestion, that explains the correct procedure in resolving >the issue. What I'm trying to point out though (I tried this), is that if >you spin up a new Debian ARM VM on AWS, and run "grub-install" *without* >doing a dpkg-reconfigure, it results in an unbootable system. To recover the >system, you have to attach the disk on a different VM and replace the old >boot loader image with the new one, then it boots again. After running the >dpkg-reconfigure command though like you suggested, it copied over the EFI >boot image to the "BOOT" folder, and also set the nvram variables to >apparently boot from the "debian" folder, so that solved the problem for me. >After doing that, the system comes up after a reboot with the newer grub >modules. > >With others on here, the issue might have to do with the system executing an >older EFI boot image resulting in a module mismatch, like what happened to >me. Your dpkg-reconfigure suggestion might fix their issues too. So when you say "spin up a new Debian ARM VM on AWS", what exact image are you using here? It sounds like the build process for that image needs to be fixed to DTRT for the platform. Then you and other users won't be bitten by this problem... -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
On 7/17/21 8:18 AM, Steve McIntyre wrote: On Sat, Jul 17, 2021 at 07:57:48AM -0500, Ryan Thoryk wrote: EFI/debian is *NOT* wrong, it's the correct location for a system that has working firmware which supports setting UEFI boot variables. If you *also* need to write a copy of grub (etc.) to the removable media location (EFI/boot) then that's supported as well by the Debian packaging - run "dpkg-reconfigure grub-efi-arm64" and say yes when the system asks about that. Thanks for that suggestion, that explains the correct procedure in resolving the issue. What I'm trying to point out though (I tried this), is that if you spin up a new Debian ARM VM on AWS, and run "grub-install" *without* doing a dpkg-reconfigure, it results in an unbootable system. To recover the system, you have to attach the disk on a different VM and replace the old boot loader image with the new one, then it boots again. After running the dpkg-reconfigure command though like you suggested, it copied over the EFI boot image to the "BOOT" folder, and also set the nvram variables to apparently boot from the "debian" folder, so that solved the problem for me. After doing that, the system comes up after a reboot with the newer grub modules. With others on here, the issue might have to do with the system executing an older EFI boot image resulting in a module mismatch, like what happened to me. Your dpkg-reconfigure suggestion might fix their issues too. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
On Sat, Jul 17, 2021 at 07:57:48AM -0500, Ryan Thoryk wrote: >On Sat, 10 Jul 2021 23:15:15 +0100 Colin Watson wrote: >> In general, this means that grub-install is not installing to the place >> that your firmware is actually booting from, which causes the core image >> (installed to a file under /boot/efi/ on UEFI systems) to be out of sync >> with the modules (installed to a subdirectory of /boot/grub/). This is >> much rarer on UEFI systems than on BIOS systems, but it's still possible >> in some misconfigured cases. >> >> Could you please attach the output of "sudo grub-install --debug", "sudo >> efibootmgr -v", and "sudo find /boot/efi -ls"? > >Thanks for looking into this issue. > >I did some investigating this morning for my situation, and found the >problem. Your suggestion is what helped me. > >The test case I had was that if you start a new Debian ARM VM on AWS, and run >grub-install on it, future boots fail, where they stop at the rescue prompt >and an "insmod normal" shows the error message. In other words, >"grub-install" was breaking grub, which is pretty bad. > >After some investigating I found that grub-install was writing the EFI boot >loader image (grubaa64.efi) to the wrong location on the system. It should be >installing into /boot/efi/EFI/BOOT but is putting it into >/boot/efi/EFI/debian. Future boots fail because the loader image that >executes (the one in BOOT) is the older version and is out of sync with the >modules. > >I tried deleting the /boot/efi/EFI/BOOT folder to see what would happen, >wondering if it would try to use the "EFI/debian" one, and after rebooting >the system was stuck in an EFI shell (couldn't find a boot loader), so the >"EFI/debian" folder is clearly wrong. This could be similar to what's >happening with others on here. EFI/debian is *NOT* wrong, it's the correct location for a system that has working firmware which supports setting UEFI boot variables. If you *also* need to write a copy of grub (etc.) to the removable media location (EFI/boot) then that's supported as well by the Debian packaging - run "dpkg-reconfigure grub-efi-arm64" and say yes when the system asks about that. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters." -- Ignatios Souvatzis
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
On Sat, 10 Jul 2021 23:15:15 +0100 Colin Watson wrote: In general, this means that grub-install is not installing to the place that your firmware is actually booting from, which causes the core image (installed to a file under /boot/efi/ on UEFI systems) to be out of sync with the modules (installed to a subdirectory of /boot/grub/). This is much rarer on UEFI systems than on BIOS systems, but it's still possible in some misconfigured cases. Could you please attach the output of "sudo grub-install --debug", "sudo efibootmgr -v", and "sudo find /boot/efi -ls"? Thanks for looking into this issue. I did some investigating this morning for my situation, and found the problem. Your suggestion is what helped me. The test case I had was that if you start a new Debian ARM VM on AWS, and run grub-install on it, future boots fail, where they stop at the rescue prompt and an "insmod normal" shows the error message. In other words, "grub-install" was breaking grub, which is pretty bad. After some investigating I found that grub-install was writing the EFI boot loader image (grubaa64.efi) to the wrong location on the system. It should be installing into /boot/efi/EFI/BOOT but is putting it into /boot/efi/EFI/debian. Future boots fail because the loader image that executes (the one in BOOT) is the older version and is out of sync with the modules. I tried deleting the /boot/efi/EFI/BOOT folder to see what would happen, wondering if it would try to use the "EFI/debian" one, and after rebooting the system was stuck in an EFI shell (couldn't find a boot loader), so the "EFI/debian" folder is clearly wrong. This could be similar to what's happening with others on here. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Processed: Re: Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
Processing control commands: > tag -1 moreinfo Bug #984760 [grub-efi-amd64] grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found) Added tag(s) moreinfo. -- 984760: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984760 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
Control: tag -1 moreinfo
Sorry for our long delay in replying to this.
On Mon, Mar 08, 2021 at 02:20:08PM +1100, Anand Kumria wrote:
> grub went into grub rescue mode and displayed:
>
> error: symbol `grub_is_lockdown` not found
In general, this means that grub-install is not installing to the place
that your firmware is actually booting from, which causes the core image
(installed to a file under /boot/efi/ on UEFI systems) to be out of sync
with the modules (installed to a subdirectory of /boot/grub/). This is
much rarer on UEFI systems than on BIOS systems, but it's still possible
in some misconfigured cases.
Could you please attach the output of "sudo grub-install --debug", "sudo
efibootmgr -v", and "sudo find /boot/efi -ls"?
> Currently, I am booting using a rescue CD and then entering commands to
> manually start the laptop
What commands are you using?
> -- Package-specific info:
>
> *** BEGIN /proc/mounts
> /dev/sda5 / ext4 rw,relatime,errors=remount-ro 0 0
> /dev/sda6 /home ext4 rw,relatime 0 0
> /dev/sda2 /boot/efi vfat
> rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
> 0 0
> *** END /proc/mounts
[...]
> *** BEGIN /dev/disk/by-id
> total 0
> lrwxrwxrwx 1 root root 9 Mar 8 11:14 ata-MATSHITADVD-RAM_UJ8C2_WP18_009183
> -> ../../sr0
> lrwxrwxrwx 1 root root 9 Mar 8 11:14 ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY
> -> ../../sda
> lrwxrwxrwx 1 root root 10 Mar 8 11:14
> ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY-part1 -> ../../sda1
> lrwxrwxrwx 1 root root 10 Mar 8 11:15
> ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY-part2 -> ../../sda2
> lrwxrwxrwx 1 root root 10 Mar 8 11:14
> ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY-part3 -> ../../sda3
> lrwxrwxrwx 1 root root 10 Mar 8 11:14
> ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY-part4 -> ../../sda4
> lrwxrwxrwx 1 root root 10 Mar 8 11:14
> ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY-part5 -> ../../sda5
> lrwxrwxrwx 1 root root 10 Mar 8 11:15
> ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY-part6 -> ../../sda6
> *** END /dev/disk/by-id
>
> *** BEGIN /dev/disk/by-uuid
> total 0
> lrwxrwxrwx 1 root root 10 Mar 8 11:14 141A3D7E1A3D5E44 -> ../../sda4
> lrwxrwxrwx 1 root root 9 Mar 8 11:15 2020-11-30-03-01-21-00 -> ../../sr0
> lrwxrwxrwx 1 root root 10 Mar 8 11:15 26cd5a33-dd28-4968-b2b4-2d134be2e444
> -> ../../sda6
> lrwxrwxrwx 1 root root 10 Mar 8 11:14 A65030AD50308659 -> ../../sda1
> lrwxrwxrwx 1 root root 10 Mar 8 11:15 DE31-8EDF -> ../../sda2
> lrwxrwxrwx 1 root root 10 Mar 8 11:14 a49dde0e-f2e4-4679-8c56-b9013d7b0fd2
> -> ../../sda5
> *** END /dev/disk/by-uuid
I notice that not all your partitions are mounted. What's on partitions
1, 3, and 4? ("sudo parted -s /dev/sda print" might help.)
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
Package: grub-efi-amd64
Version: 2.04-16
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: akum...@gmail.com
Dear Maintainer,
* What led up to the situation?
A Toshiba laptop with a single disk, with GPT partitions, a few days ago
performed a normal upgrade:
...
2021-03-03 16:21:30 status installed man-db:amd64 2.9.4-2
2021-03-04 06:44:34 startup archives unpack
2021-03-04 06:44:34 upgrade grub2-common:amd64 2.04-15 2.04-16
2021-03-04 06:44:34 status half-configured grub2-common:amd64 2.04-15
2021-03-04 06:44:34 status unpacked grub2-common:amd64 2.04-15
2021-03-04 06:44:34 status half-installed grub2-common:amd64 2.04-15
2021-03-04 06:44:34 status triggers-pending man-db:amd64 2.9.4-2
2021-03-04 06:44:34 status unpacked grub2-common:amd64 2.04-16
2021-03-04 06:44:35 upgrade grub-efi-amd64:amd64 2.04-15 2.04-16
2021-03-04 06:44:35 status half-configured grub-efi-amd64:amd64 2.04-15
2021-03-04 06:44:35 status unpacked grub-efi-amd64:amd64 2.04-15
2021-03-04 06:44:35 status half-installed grub-efi-amd64:amd64 2.04-15
2021-03-04 06:44:35 status unpacked grub-efi-amd64:amd64 2.04-16
2021-03-04 06:44:35 upgrade grub-efi-amd64-bin:amd64 2.04-15 2.04-16
2021-03-04 06:44:35 status half-configured grub-efi-amd64-bin:amd64 2.04-15
2021-03-04 06:44:35 status unpacked grub-efi-amd64-bin:amd64 2.04-15
2021-03-04 06:44:35 status half-installed grub-efi-amd64-bin:amd64 2.04-15
2021-03-04 06:44:35 status unpacked grub-efi-amd64-bin:amd64 2.04-16
2021-03-04 06:44:35 upgrade grub-common:amd64 2.04-15 2.04-16
2021-03-04 06:44:35 status half-configured grub-common:amd64 2.04-15
2021-03-04 06:44:35 status unpacked grub-common:amd64 2.04-15
2021-03-04 06:44:35 status half-installed grub-common:amd64 2.04-15
2021-03-04 06:44:36 status unpacked grub-common:amd64 2.04-16
2021-03-04 06:44:36 startup packages configure
2021-03-04 06:44:36 configure grub-common:amd64 2.04-16
2021-03-04 06:44:36 status unpacked grub-common:amd64 2.04-16
2021-03-04 06:44:36 status half-configured grub-common:amd64 2.04-16
2021-03-04 06:44:36 status installed grub-common:amd64 2.04-16
2021-03-04 06:44:36 configure grub-efi-amd64-bin:amd64 2.04-16
2021-03-04 06:44:36 status unpacked grub-efi-amd64-bin:amd64 2.04-16
2021-03-04 06:44:36 status half-configured grub-efi-amd64-bin:amd64 2.04-16
2021-03-04 06:44:36 status installed grub-efi-amd64-bin:amd64 2.04-16
2021-03-04 06:44:36 configure grub2-common:amd64 2.04-16
2021-03-04 06:44:36 status unpacked grub2-common:amd64 2.04-16
2021-03-04 06:44:36 status half-configured grub2-common:amd64 2.04-16
2021-03-04 06:44:36 status installed grub2-common:amd64 2.04-16
2021-03-04 06:44:36 configure grub-efi-amd64:amd64 2.04-16
2021-03-04 06:44:36 status unpacked grub-efi-amd64:amd64 2.04-16
2021-03-04 06:44:36 status half-configured grub-efi-amd64:amd64 2.04-16
2021-03-04 06:44:49 status installed grub-efi-amd64:amd64 2.04-16
2021-03-04 06:44:49 trigproc man-db:amd64 2.9.4-2
2021-03-04 06:44:49 status half-configured man-db:amd64 2.9.4-2
2021-03-04 06:44:50 status installed man-db:amd64 2.9.4-2
...
During the course of this upgrade, I was prompted to run:
$ /usr/share/debconf/fix_db.pl
Do to some debconf database corrupt (I believe the package which prompted this
was either mysql-common or mariadb-common)
I recall some questions / answers related to linux (and potentially grub) being
removed due to there being no corresponding question (or similiar)
* What exactly did you do (or not do) that was effective (or
ineffective)?
Rebooted on 7 Mar
* What was the outcome of this action?
grub went into grub rescue mode and displayed:
error: symbol `grub_is_lockdown` not found
* What outcome did you expect instead?
A reboot into a functioning system.
Currently, I am booting using a rescue CD and then entering commands to
manually start the laptop
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/sda5 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda6 /home ext4 rw,relatime 0 0
/dev/sda2 /boot/efi vfat
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
(hd0) /dev/disk/by-id/ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
