in this case it's not mounted, because you have ZFS on `/` and use proxmox-boot-tool for managing the boot-loader :) (similarly for pve-root and swap(on ZFS no swap is created)
on systems installed on ext4+lvm-thin it needs to be mounted.
I...
just to be on the safe side - you mean /etc/sysctl.conf?
theoretically yes - but see the man page sysctl.d(5):
`It is recommended to prefix all filenames with a two-digit number and a dash, to simplify the ordering of the files` - so maybe...
Thanks!
hm - not sure how grub deals with /boot/efi being a mdraid - I'd suggest:
* checking `efibootmgr -v`
* ensureing that bootx64.efi (a.k.a removable grub entry) gets updated as well:
echo 'grub-efi-amd64 grub2/force_efi_extra_removable...
see https://pve.proxmox.com/wiki/Upgrade_from_8_to_9#Prerequisites:
(that is before changing the sources to trixie - you should install all pending updates)
I hope this helps!
For anyone still looking for a solution, my /boot/EFI partition had some corruption. Running an fsck and fixing the errors on the partition resolved this for me.
not necessarily - the only thing that is odd about it as far as I can see is that you have both:
* using proxmox-boot-tool for booting (ZFS system on legacy boot)
* one of the ESPs mounted at /boot/efi (on a legacy boot system!)
I'd recomment...
it looks like I could eventually fix it as I force-reinstalled grub-efi-amd64 which was broken during upgrade process.
Phew ! Thanks for your assistance !
it sounds like you are booting from the removable boot loader entry, and did not update that one, so now there is a mismatch between the first part of grub and the rest of grub on the ESP..
could you post the output of "efibootmgr -v" (from a...
that sounds odd (should not happen with our usual setups) - please share:
* `proxmox-boot-tool status`
* `mount |grep efi`
(thanks for sharing the term.log!)
8 Months ago should have been bookworm - thanks for the info!
Could you (and others affected by grub not booting after upgrade) - also share:
grep grub /var/log/apt/term.log
(unless your term.log has been rotated after the upgrade in which...
thanks - which version did you start with? any other specifics how this was setup?
this would also help narrowing this down - s a stock debian bookworm system here has shimx64.efi as configured boot-entry and not grubx64.efi as in your case.
good find regarding the mismatch of grubx64.efi - how was this system setup?
* proxmox VE ISO or on top of debian?
* when was it setup ? (debian version PVE version)?
This should help us in reproducing the issue.
Thanks!
Yes
Yes - because you're still on PVE-8 (bookworm) - I thought that the following part should explain that:
which is also why the pve8to9 script does not warn you before upgrading to pve-9 (trixie):
I will warn you after upgrading to 9 (at...
Yes your assumption is correct - removing the sytemd-boot meta-package is what we recommend - the patch for pbs3to4 was just a tad to late for the ISO today:
https://lore.proxmox.com/pbs-devel/20250806114909.2143258-1-s.ivanov@proxmox.com/T/#u...
Just a heads up, there are some references to pve filenames rather than pbs filenames in the repository sections - under both codeblock sections, listing: /etc/apt/sources.list.d/pve-enterprise.list & /etc/apt/sources-list.d/pve-install-repo.list
Hi,
if you are on Proxmox VE 9 (based on Debian 13), you should not run the kernel for Proxmox VE 8 (based on Debian 12, the bpo12 means the package was backported for Debian 12). Also make sure the proxmox-default-headers package is installed.