Search results

Hm - the sender should not get a notification - but if you have before-queue filtering enabled PMG sends a 5xx response ("Rejected for policy reasons") - I think (but haven't tested it yet) if you don't have before-queue filtering enabled the mail should be dropped silently (unless you enable...

Why do you think so? - which errors do you get and why (if it's still an issue)? Thanks!

Thanks for the information! your system is using proxmox-boot-tool - in that case keeping the ESP mounted might be problematic/the cause of the failing boot: I'd probably remove the /boot/efi mount from /etc/fstab, run proxmox-boot-tool reinit to get the system in a consistent state! (Keep in...

I'll lock this thread - so all answers end up in the first post.

Thanks for the feedback and the report! We improved the check for the boot-loader issues (but it's still not available on our public repositories) - https://lore.proxmox.com/pve-devel/20250814120807.2653672-1-s.ivanov@proxmox.com/T/#t I'd guess that this version should have caught the issue...

please check/post the journal after booting when the cards are not available - new kernel/new systemd version might change the names of the NICs - the journal should tell you if there's a problem there. physically available means that they are listed in `lspci -nnk`? In most cases I'd recommend...

Looking through our bugzilla (which is the place where feature requests and bug-reports are tracked) I found: https://bugzilla.proxmox.com/show_bug.cgi?id=5538 which should align with your issue - please note your suggestion there (it gets more visibility). Thanks!

please send it to our development list - and provide a short explanation why this is needed in your case. Thanks!

hmm - check if there are some files in `/etc/ssh/ssh_config.d/` - or even a bit more general run - `grep -rE 'ssh-dss' /etc/` - check this on all nodes in your cluster! if that does not point to the issue - please open a new thread (feel free to mention me with @Stoiko Ivanov) - and share the...

as @LnxBil said - it would help a lot to know which commands you ran to get in that situation? (and to provide /var/log/apt/term.log and history.log from that upgrade) a very blind guess: did you maybe run `apt upgrade` instead of `apt dist-upgrade`?

No - the permission system in PMG is not domain aware - and for a very large part of the administration/configuration the settings are global (e.g. rules, most postfix configuration,...) I hope this helps!

Contributions are very welcome - thanks for the suggestion! We use a mail-based workflow - see https://pve.proxmox.com/wiki/Developer_Documentation for submitting patches.

from a quick look at the code: https://git.proxmox.com/?p=pve-container.git;a=blob;f=src/PVE/LXC/Setup/Base.pm;h=dbfc775c6f4769609c50caa6c8a7b91a91566080;hb=HEAD#l294 It should be set to true, if you set the containers IPv6 config to 'auto' (called SLAAC) in the GUI (did not test this explicitly...

send a patch for this just yesterday: https://lore.proxmox.com/pbs-devel/20250818194026.840749-2-s.ivanov@proxmox.com/T/#u :) Thanks for the report in any case!

see: https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_template_engine - v320.pre is handled by the templateing system. I hope this helps!

Yes! (systems not using proxmox-boot-tool should have it mounted on /boot/efi) proxmox-boot-tool is (currently) used for all installations which are not using Ext4/XFS (with LVM) - it was initially added to handle ESPs for machines with multiple disks (and to add sensible support to UEFI...

See: https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_template_engine - the postfix configuration is done via templates. 127.0.0.1 is also called the loop-back ip (localhost) and is e.g. used to speak with services on the same computer via TCP/IP - PMG sends mails through the...

don't think that it's related to IPMI/Server board vs. Desktop board - but maybe it's something related to when the servers were setup - or secure-boot related... - do you happen to remember when you set them up? - and does `dmesg|grep -i secure` indicate that secure-boot is in use? anyways -...

term.log received via different channel. from the one you sent - looking through the large output - you can find: Installing for x86_64-efi platform. grub-install.real: error: cannot find EFI directory. Failed: grub-install --target=x86_64-efi WARNING: Bootloader is not properly installed...

Hm - could I ask you for the term.log from the dist-upgrade in this case? Maybe you ran into something we haven't considered yet - or something we could add a warning about to pve8to9 (and thus help users who yet have to upgrade) Thanks!