Search results

Thanks that does sound quite sensible indeed! - I tried adapting the docs accordingly: https://pve.proxmox.com/wiki/Upgrade_from_8_to_9#Systemd-boot_meta-package_changes_the_bootloader_configuration_automatically_and_should_be_uninstalled

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 hope this helps!

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 `71-local.conf` I hope this helps!

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 boolean true' | debconf-set-selections -v -u *...

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!

hm - was sagt denn `journalctl -b -u systemd-modules-load.service` ? und bitte auch `journalctl -b` durchschauen ob fehler reported werden

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 removing the fstab entry of /boot/efi - as...

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 case please use the rotated variant which contains...

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 that point the system will have...

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 I hope this helps!

Thanks for the report! fixed that (and looked in the page for other mentions of pve this time)

Thanks again for the keen eye! - Should be fixed now!

could you please share the complete logs of the mail - usually there should be logs from pmg-smtp-filter present as well. without further information I would guess that something caused the mailprocessing to take too long and thus it was not done within the time out...

Thanks for the report! good catch - https://lore.proxmox.com/pve-devel/20250806110251.2117322-1-s.ivanov@proxmox.com/T/#u (found that just a short bit before)

We tried to make those checks as safe as possible so this should not cause issues. A bit of background - currently systems: * having root on ZFS or BTRFS * booting using UEFI (not legacy bios boot) * not having secure-boot enabled use systemd-boot for booting `proxmox-boot-tool status` should...

Hm - we did quite a few fixes in that area - precisely due to the report you linked. Regarding recovery - I'd boot the 9.0 ISO in debug-mode, and get in the system from the second debug shell (let it boot into the first shell (which on some systems only produces garbled screen-output), hit...

yes - installing systemd-boot is needed to update the boot-loader copies on the ESPs.