one test that might make sense is booting the last 6.5 pve kernel with intel_iommu=on (I hope I did not overlook that you tried that?)
does the NUC run apart from the warnings in dmesg?
good point - no actual fixes for dm_crypt explicitly - but a few on the block subsystem (and afair the traces indicated issues there in the bottom)
I tried running a Debian VM with dmcrypt disksetup here with our latest kernel and 6.8.4-2-pve - but did not run into issues (tested with a short...
the issue here is simply that `pve-ha-manager` conflicts with the watchdog package - as HA needs access to the watchdog for fencing...
https://pve.proxmox.com/pve-docs/chapter-ha-manager.html
you cannot install the package watchdog on a PVE system
could you maybe share the complete journals since boot (and/or at least `dmesg` ) - might help to get a more complete picture.
Our git-repo contains instructions on how to build the proxmox kernels...
The dmesg.log you posted indicates an issue with mdraid (which we do not officially support) - please try the 6.8.4-3-pve kernel - there were quite a few fixes in that area of the linux codebase - hopefully your issue is gone with that.
do you have any logs from the crash? - else it's hard to see where the issue is rooted...
also did you try `6.8.4-3-pve` ?- this got released to the no-subscription repository yesterday and contains quite a few fixes.
Hm - thanks for verifying this and for your efforts so far!
could you try the zabbly kernel for 6.8.4 (as that's what our kernel is actually based on)
and the Ubuntu 24.04 kernel:
https://packages.ubuntu.com/noble/amd64/linux-image-6.8.0-31-generic/download
one further difference I noticed in...
did you add the intel_iommu=on to the commandline?
asking because the package downloaded from: https://pkgs.zabbly.com/kernel/stable/pool/main/l/linux-zabbly-6.8.8-amd64-202404301432-debian12/linux-image-6.8.8-zabbly%2B_6.8.8-amd64-202404301432-debian12_amd64.deb
does not enable intel_iommu by...
Then I think this is the resolution to the issue on that NUC.
The default will most likely stay 'on' so for systems with broken implementations disabling it is a sensible solution.
not really - the transport_maps entry is one of the highest-priority places for the postfix configuration (many mail-services rely on this to be higher, because the public MX points to e.g. a PMG, but the PMG needs to send the mails to a downstream server)...
You could quite easily script the...
nein - die liste ist hardcoded:
https://git.proxmox.com/?p=pmg-log-tracker.git;a=blob;f=src/main.rs;h=0a4f1922d442f38409aab2d56b12dec386876ad7;hb=HEAD#l2113
aber es steht in beiden files meist dasselbe drinnen bezüglich mail-services ;)
Ja - Das Tracking Center bezieht seine Informationen aus /var/log/syslog (und die rotierten Varianten)
Wie lange Logs aufgehoben werden lässt sich in /etc/logrotate.d/rsyslog einstellen (siehe `man logrotate.conf`)
Ich hoffe das hilft!
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.