Search results

Check the logs of your VM and of the LXC - my guess is that clamav simply gets killed due to running out-of-memory. see https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#system_requirements

might be - but it could also be due to the newer kernel expecting some things that were fixed in more recent version of BIOS/Firmware: seems there were some updates available for the board...

Additionally the complete mount-options might be interesting: ``` mount |grep nfs ```

To route mail to the internet through some other servive (mimecast in your case) in PMG you usually just need to set a smarthost - see: https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_mailproxy_relaying I hope this helps!

see: https://bugzilla.proxmox.com/show_bug.cgi?id=2505 If you do not configure before-queue filtering, and don't enable 'Send NDR on Blocked E-mails' in the mail proxy options a Block should not be sent to the sender. I hope this helps!

This says, that 10.0.0.200 (I guess your mailserver) says that management@######.it is not deliverable -> check the logs of 10.0.0.200 I hope this helps!

welche variable soll das genau sein? `pmgconfig dump` liefert dns.domain aber nicht pmg.domain? für dns.domain ist es der erste Eintrag der search domains in /etc/resolv.conf Siehe auch: https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#_configuration_files_overview ich hoffe das hilft!

Der Block kommt daher, dass die sendende IP auf dnsbl.dronebl.org gelistet ist - es muss daher die IP erlaubt werden. Blocken auf diesem Level (postscreen) kann mit der mailproxy-whitelist umgangen werden (GUI->Configuration->Mail Proxy->Whitelist) - siehe hierzu auch die doku...

without reproducing it explicitly - the first issue I see is that the pmg.conf is synchronized across the cluster - so both would try to invoke avast - the one node where it's not available will log errors. I would not recommend this (and it's not supported) I hope this helps!

There is an article in the PMG wiki describing changing the hostname or ip - linked from the getting started page: https://pmg.proxmox.com/wiki/index.php/Getting_started_with_Proxmox_Mail_Gateway#Changing_Hostname_or_IP please try following this (and report if you run into issues, so we can...

Thanks! - my mistake - the module-load fails, thus i guess that zfs version fails. Do you get any more output from `modprobe zfs` ?

sent: https://lore.proxmox.com/all/20250414145705.1262110-1-s.ivanov@proxmox.com/T/#u

Thanks for the trace-file! I think the issue might be related to the following lines: 1109 14:24:25.334871 access("/dev/zfs", F_OK) = 0 ... 1109 14:24:25.335151 openat(AT_FDCWD</root>, "/dev/zfs", O_RDWR|O_EXCL|O_CLOEXEC) = -1 ENODEV (No such device) which I cannot reproduce locally. * Is...

Which boards/BIOS versions do both of you have? I'll see that we include the patch 1/3 https://lore.kernel.org/all/20250203162511.911946-1-Basavaraj.Natikar@amd.com/ in our kernel as well - but narrowing this down further might help upstream to also include it Thanks

the file would still be needed.

hm - the updated kernel in our repo does boot successfully on our testsystem (ASUS RS500 based - I just reverified this with the kernel from our repos): root@pve-test:~# uname -r 6.14.0-2-pve root@pve-test:~# lspci -d 1022:14dc 04:00.1 System peripheral: Advanced Micro Devices, Inc. [AMD] SDXI...

hm - that's unexpected - and might be a hint. please provide: * `dpkg -l |grep -Ei '(zfs|zpool|2.2.*-pve)'` * `strace -yyftt -o ./zfs-version.trace zfs version` (the last one will create a file ./zfs-version.trace - please attach that one as well) Thanks!

unrelated to the ZFS pool not getting imported - if I remember correctly - `intremap=off` on the kernel commandline can help with some issues on HP G8 series hardware (at least DL380)

the combination of key-error (which might point to a secure-boot issue) and the hp-g8 series (not sure if they do support EFI-boot/Secure boot at all?) is indeed odd. on a hunch - did you maybe at some point install some DKMS modules? (maybe even ones for ZFS)? else the following outputs might...

with 2 patches from this series applied (those that should also be applied in kernel.org 6.14.2) - the system where we ran into the issue booted up ok: https://lore.proxmox.com/all/20250410130834.1745644-1-s.ivanov@proxmox.com/T/#u once this is applied (or our kernel is updated to >= 6.14.2)...