Unbootable PVE after upgrade

Saahib

Active Member
May 2, 2021
88
3
28
I upgraded promox 7.4 for 8.4, after upgrde it was stuck at "welcome to grub!", can't type or do anything. I booted in resuce, done chroot and an ran proxmox-boot-tool init /dev/nvme0n1p1 (here my ESP partition / efi partition reside). After that, on reboot, it fails say "No boot= argument given" and then drops to initramfs prompt.

There is no zfs on this system. From resuce I can see my EFI is at `/dev/nvme0n1p1` , /boot is at `/dev/md2`, root is at `/dev/md3`. While /var/lib/vz is on lvm `/dev/vg/data`. This means my raid is working fine and lvm is also fine.

If I run `efibootmgr -v` from chroot. It says "doesn't support efi variables".

However, if I run `proxmox-boot-tool status` , it says system has booted in to UFI

Also, from resuce I see that proper entries are there in /boot/grub/grub.cft

Another intersting thing is that I don't see grub loading anymore, I shows list of EFI bootable devices, then start booting and drops to "initramfs" prompt.


I have been through all possible related thread from countless hours, out of ideas now.
 
PVE doesn't use mdraid - how did you originally set up the system?

if you reinitialize your ESP, make sure you have prepared the chroot where you are executing proxmox-boot-tool correctly - i.e., mount /boot, /dev/, /proc, /sys into the chroot as well..
 
It was not installed by me so not sure, may be they had installed debian and then PVE over it.
Setup is this way :

/dev/nvme0n1p1 - ESP parition
/dev/md2 - boot
/dev/md3 - root
/dev/md5 - /var/lib/vz
/dev/vg/data (lvm) for storage.

Before chroot I did mount /proc /sys /run /dev /dev/ptr .

I did then `proxmox-boot-tool init /dev/nvme0n1p1`

Also did for other drive : /dev/nvme1n1p1

I think this should be enough ?


During update I had following error :

Code:
Running hook script 'zz-proxmox-boot'..

Re-executing '/etc/kernel/postinst.d/zz-proxmox-boot' in new private mount namespace..<br>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

I actually had ignored it. I did run it later but before that had done :
Code:
proxmox-boot-tool format /dev/nvme0n1p1
update-grub
update-initramfs -u -k all

Here, weird things is that I do not get Grub screen, rather I get EFI boot drive option (see below), If I boot to first option, it drops to `initramfs>` prompt. IfI use second option then it boots, but all links down,if I check via ethtool, it says link-not detected for all interface.



1749197836454.png


Formating via ESP partition had broken it as it removed EFI_SYSPART label which was used in /etc/fstab to mount it, I later added so now I can boot via second option but no network.

Also, when I am able to boot into proxmox via second option, efibootmgr -v works (I guess it doesn't work in chroot)
1749198349743.png

I don't want to reinstall here please.
 
Last edited:
you are actually booting from another bootloader (rEFInd is a third-party EFI bootloader)., likely the boot entry number 6 or 7? you should be able to set boot entry 0 as default, unless your EFI implementation is broken..
 
Since I can now boot to proxmox, can I fix it from promox ?
I did change order using `efibootmgr -o 0001,0003,0006,0006` but on next reboot it booted to incorrect one (0001) and dropped to `initramfs` prompt.

Also network thing is fixed, it was just change of name of NIC.
 
the correct one seems to be 0000..
 
Yes, 0000 seems correct but why entries got shuffled on next boot as I mentioned earlier ?
I need to understand what broke it in first place. I think it was Removable bootloader found at '/boot/efi/EFI/BOOT/BOOTX64.efi', but GRUB packages not set up to update it! which I had ignored.

Also, why grub was installed as removable bootloader in first place?
 
Yes, 0000 seems correct but why entries got shuffled on next boot as I mentioned earlier ?
you wrote that you changed it to "0001,0003,0006,0006" which doesn't include 0000.

Also, why grub was installed as removable bootloader in first place?

because there are broken EFI implementations that require it. the new warning is just for those systems - if you require it and use it, you also need to keep it updated. if you don't use it, the warning doesn't change anything either way.

you have a very non standard setup, I cannot tell you why it looks like it does, you'd have to ask your documentation.