Recent content by keeka

It's not clear to me from reading this thread or the linked bugzilla page if this is a bug or an anticipated consequence of recent kernel/security code. Assuming it is the latter, and is here to stay, will unprivileged containers no longer support RO mountpoints?

AFAIK smtp_helo_name=$myhostname and the latter comes from the template: myhostname = [% dns.hostname %].[% dns.domain %]. Try to regenerate the config files by way of pmgconfig sync --restart 1

The version numbering (~deb13u1), whilst originating from the proxmox repo, was unusual in my experience. Thanks for the information.

Why is, for example, the Debian package systemd available via the Proxmox repo? Also in this case it's newer than that on Debian repo. I have not encountered that before. Do I have misconfigured sources? ~# apt policy systemd systemd: Installed: 257.8-1~deb13u2 Candidate: 257.9-1~deb13u1...

Newer, Debian systemd and associated packages appear to be coming from the Proxmox repository.

I have also seen this behaviour recently. I then noticed that changing the sidebar view mode results in the expected tag colours being applied.

That's good news. Thanks for the updates on your progress. Can you post images of the suspect card?

As a newcomer to Linux and Linux-based virtualisation, your time might be better spent putting this network card issue aside for a while and sticking with PVE8. I have a similar network card in my setup, so was interested in your report. It's a common card so should surface again soon as more...

I do something like this: # grep -r -e 'describe.*GB_OBFU_PHONE' /usr/share/spamassassin* /var/lib/spamassassin /var/lib/spamassassin/4.000001/kam_sa-channels_mcgrail_com/KAM.cf: describe GB_OBFU_PHONE Obfuscated phone number

@Philebos I'm not familiar with the script you mention or what it's function is. I am currently setting governor by just passing kernel boot parm `cpufreq.default_governor=ondemand`. Are you saying (having confirmed the governor has been set successfully) that for a given governor, you see...

The pertinent parts of lxc.conf for coral access and igpu encoder. features: keyctl=1,nesting=1 unprivileged: 1 dev0: /dev/dri/renderD128,gid=106 lxc.cgroup2.devices.allow: c 189:* rwm lxc.mount.entry: /dev/bus/usb dev/bus/usb none bind,optional,create=dir 106 is the render group in my debian...

I'm using it in an unprivileged lxc running frigate (docker). I did not find it necessary to install a driver on the PVE host. The mini-pcie versions though do require the driver on the host (for lxc use).

How are you using the Coral USB TPU? I'm curious what benefit you get from installing the driver on the PVE host.

I experienced problems with the e1000 driver and the onboard NIC on my ancient motherboard. I gave up using it for a VLAN trunk and resorted to the other built-in NIC (Atheros). I eventually disabled both onboard NICs and purchased a secondhand Intel i350 (2 port version). If you are happy with...

Try, temporarily, changing the lxc mount to: lxc.mount.entry: /dev/bus/usb dev/bus/usb none bind,optional,create=dir