SOLVED: PVE update broke my system (because I missed something). GRUB error

G

gctwnl

Member
Aug 24, 2022
67
11
13
I upgraded PVE on my NUC which ended with

Code: 
Your System is up-to-date


Seems you installed a kernel update - Please consider rebooting
this node to activate the new kernel.

starting shell
So, I rebooted, entered the BIOS/disk passwords and then I got:
Code: 
Welcome to GRUB!

error: symbol `grub_disk_native_sectors' not found.
grub rescue>
And looking again at the upgrade window, I had missed something, because the complete message at the end of the upgrade was:
Code: 
update-initramfs: Generating /boot/initrd.img-6.8.12-8-pve
Running hook script 'zz-proxmox-boot'..
Re-executing '/etc/kernel/postinst.d/zz-proxmox-boot' in new private mount namespace..
No /etc/kernel/proxmox-boot-uuids found, skipping ESP sync.

Removable bootloader found at '/boot/efi/EFI/BOOT/BOOTX64.efi', but GRUB packages not set up to update it!
Run the following command:

echo 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' | debconf-set-selections -v -u

Then reinstall GRUB with 'apt install --reinstall grub-efi-amd64'

Processing triggers for libc-bin (2.36-9+deb12u9) ...

Your System is up-to-date


Seems you installed a kernel update - Please consider rebooting
this node to activate the new kernel.

starting shell
In addition: my NUC has a BIOS password and an internal SSD which is also encrypted/protected with a password.

Now, what do I have to do to get this fixed? Is there a way at all? I have seen more have been hit by this but I am a bit at a loss.

the ls command gets me:

Bash: 
grub rescue> ls
(lvm/pve-root) (lvm/pve-swap) (hd0) (hd0,gpt1) (hd1) (hd1,gpt3) (hd1,gpt2) (hd1,gpt1)
 
Last edited:
  • Like
Reactions: omaktl
Solved through these steps:
  1. Download the Proxmox VE 8.3.1 IOS and flash it to a USB drive
  2. Connect the USB drive to the USB of the system
  3. Boot the system (mine will boot from a USB drive found without BIOS changes)
  4. The Proxmox installer boots. Select the recovery option in Advanced
  5. This boots the PVE environment and you can log in via the web browser as you normally will
  6. Use the shell in the web browser for this PVE to execute the forgotten commands:
    Code: 
    echo 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' | debconf-set-selections -v -uapt install --reinstall grub-efi-amd64
  7. reboot the system
After these steps, my PVE booted again and launched all VMs on it. Phew!
 
  • Like
Reactions: omaktl, ikidd, fabian and 2 others
Curious. I have my systems set to auto update via crontab. How would i i know if i need to run these commands or not? Would it be beneficial to run the commands even if the update did not specifically say to?
 
R3dM3at said:
Curious. I have my systems set to auto update via crontab. How would i i know if i need to run these commands or not? Would it be beneficial to run the commands even if the update did not specifically say to?
Click to expand...
you can check in /var/log/apt/term.log
 
which issue? the update exposed a (configuration) issue on some systems. so now there is a warning to detect potentially affected systems so the configuration issue can be fixed before the next reboot. you need to run those commands (or fix the config in a different fashion).
 
fabian said:
which issue? the update exposed a (configuration) issue on some systems. so now there is a warning to detect potentially affected systems so the configuration issue can be fixed before the next reboot. you need to run those commands (or fix the config in a different fashion).
Click to expand...
Forgive me for my lack of know how here, but if the system can detect what you must do so a reboot will not fail, why not simply do it? For false positives, I assume, but then, how do I personally would recognise a false positive? If I get this message (and do not miss it as last time, but then, the message did not tell me my system would be potentially bricked) I will by definition have to do this anyway to be on the safe side.

Maybe better: is there a way I can fix my config (which was basically created by a PVE install on the hardware, I never touched anything so deep, so the configuration issue has been created by PVE in the first place I guess) so that I cannot run into this again?
 
gctwnl said:
Forgive me for my lack of know how here, but if the system can detect what you must do so a reboot will not fail, why not simply do it? For false positives, I assume, but then, how do I personally would recognise a false positive? If I get this message (and do not miss it as last time, but then, the message did not tell me my system would be potentially bricked) I will by definition have to do this anyway to be on the safe side.
Click to expand...

the warning will be shown if a removable bootloader entry is detected, but the config isn't set up in a way that automatically upgrades it. this combination is only a problem if you also attempt to use that entry to boot, which is not the normal way of booting. so the warning is a bit over cautious (it will be printed on systems that are not affected unless you manually boot using the removable entry), and gives admins a chance to investigate.

there are two ways to fix the issue:
- remove the removable entry if it is not needed (very dangerous if you actually need it, so better to not do that automatically)
- change the config to always update it (should always be safe, but might not be desired)

the warning recommends the latter, but an admin might choose the former.

gctwnl said:
Maybe better: is there a way I can fix my config (which was basically created by a PVE install on the hardware, I never touched anything so deep, so the configuration issue has been created by PVE in the first place I guess) so that I cannot run into this again?
Click to expand...

simply run the command once (which will fix the config), that's it.
 
You must log in or register to reply here.
Top Bottom