A fresh installation from the ISO has the contrib component for the Debian repositories enabled/included, while the docs: [1] do not mention it.
[1] https://pve.proxmox.com/pve-docs/chapter-sysadmin.html#_debian_base_repositories
Hmm we had a few similar reports - could you please share /var/log/apt/term.log (or the rotated variant that covers the upgrade from 8 to 9)?
my guess is - you still had `systemd-boot` installed while upgrading - see...
Please provide the output of `pmgversion -v`
else:
what's the output of `ip -details -json link show` ?
EDIT: did you reboot/restart any services after the upgrade? - if not - does restarting `pmgtunnel` make the warnings go away?
EDIT2...
The mail is blocked in your configured rules - more concretely by the rule called Blacklist - take a look there.
Just to have mentioned it explicitly: PMG 7.2 is EOL since over one year now - please consider updating to the latest version as...
The reason why we don't add it there is that this is a one-way street - once you've upgraded your zpools you cannot use a kernel that is shipping an older (minor) version for ZFS.
In general I'd recommend to rather upgrade a zpool if you need...
FYI, multiple (external) users reported [0] [1] [2] that processes with the name "kauditd0" were malware running on their system / containers, especially because they try to imitate a kernel thread but are clearly not a kernel thread at all.
[0]...
the results from address verification are cached - PMG uses postfix functionality for the recipient verification:
https://www.postfix.org/ADDRESS_VERIFICATION_README.html
and
https://www.postfix.org/verify.8.html
show which parameters can be used...
No - PMG does not have a permission system that is domain-aware - and for now we don't plan on implementing it.
And the tracking center is also not a privilege of its own
I hope this helps!
Just to get the steps all in one place for anyone benefiting in the future...
Assuming booted onto system using recovery ISO.
Assuming you are logged in as root.
Assuming a boot disk of sda.
Assuming an EFI partition of sda1.
Assuming a PVE...
Thanks - looking through them (and knowing what to search for) - shows:
Replacing config file /etc/default/grub with new version
Installing for x86_64-efi platform.
grub-install.real: error: cannot find EFI directory.
Failed: grub-install...
yes - can relate to that - it bit me while testing as well ... - We do try to add checks for more common problematic configurations to the `pve8to9` script
(using proxmox-boot-tool, while having the ESP mounted on /boot/efi is nothing I've seen...
Well, a couple more minutes of research and I fixed it. Turns out you also need to mount -o bind /sys/firmware/efi/efivars <target>.
Working. Finally. Thank you! I will search for and post the requested log files shortly.
I guess you have mounted your btrfs (sda3, sdb3 at a directory - for the reminder assume /target)
* check if you have /etc/kernel/proxmox-boot-uuids (this is the check if proxmox-boot-tool is used) - and the contents match the UUIDs of sda2 sda3...
That usually is not a problem - as TLS in SMTP is opportunistic - if your downstream/backend mailserver does not advertise STATTLS PMG should simply transfer the mails without TLS.
If you run into problems - please share the logs - then we might...
hm - there were a few posts about mismatched grub stages after an upgrade ...
I'd check if you can look through the ESP (EFI service partition) and try the proxmox/shim / proxmox/grub or BOOTX64.efi entries on them - most UEFIs have an option to...
updated systemd-boot package will hit the repositories shortly on our end, so that upgrading before removing systemd-boot should avoid triggering this issue.
Thanks - will try reproducing it with the 8.0 ISO - afaics it's a single disk system?
yeah it's not the most straight-forward to read - but it does contain the most information - and in that case it points us to the issue with your system:
This...