Struggled to get Cascadia and Expedition 33 running on Steam under Linux.

I noticed the following output when running (a very recent) wine:

GL_INVALID_ENUM in glTexBufferRange(internalFormat GL_RGBA8_SNORM

and the fact that the OpenGL renderer was used and it might not implement certain texture formats (I'm using a AMD Ryzen 5600G with its internal GPU).

After installing mesa-vulkan-drivers (which was apparently missing for whatever reason), things switch to the Vulkan renderer and started working. Hurray!

fo:  Game: SandFall-Win64-Shipping.exe
info:  DXVK: v3.0.2
info:  Build: x86_64 gcc 16.1.0
info:  Vulkan: Found vkGetInstanceProcAddr in winevulkan.dll @ 0x6ffff9007840
...
info:  Found device: AMD Radeon Graphics (RADV RENOIR) (radv 26.1.5)
info:  Found device: llvmpipe (LLVM 21.1.8, 256 bits) (llvmpipe 26.1.5)

posted at: 23:46 | path: /configuration | permanent link

Try systemd-analyze blame to find out which service takes long during bootup.

For me, it was systemd-networkd-wait-online.service, apparently timing out after 2 minutes. Probably it tries to bring up all network interfaces (my PC has two NICs).

So: try SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd-wait-online --timeout 5 --any to see if it can quickly bring up at least one interface within 5 seconds.

Edit /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service and add the paramters above (-timeout 5 --any) to line ExecStart=/usr/lib/systemd/systemd-networkd-wait-online.

posted at: 00:42 | path: /configuration | permanent link

Postfix, when configured with multiple domains, should present a different certificate upon STARTTLS depending on the domain (via SNI).

In /etc/postfix/main.cf, there is tls_server_sni_maps which points to a hash file, e.g. hash:/etc/postfix/vmail_ssl.map with the following content (assuming Let's Encrypt certificates):

mail.domain1.com /etc/letsencrypt/live/mail.domain1.com/privkey.pem /etc/letsencrypt/live/mail.domain1.com/fullchain.pem
mail.domain2.net /etc/letsencrypt/live/mail.domain2.net/privkey.pem /etc/letsencrypt/live/mail.domain2.net/fullchain.pem

The postmap -F hash:/etc/postfix/vmail_ssl.map command has to be run on update of the certificates.

Run ssltestssl --starttls smtp mail.domain2.net:25 to checkk the setup.

posted at: 21:36 | path: /configuration | permanent link

When a name is resolved via DNS, the application, i.e. getaddrinfo(), asks for an IPv4 and IPv6 address via the local resolver. In Ubuntu, systemd's resolved is used as a stub resolver (not so on AWS Linux 2023, but that is another story).

The stub resolver is supposed to cache the query result. But why is resolvectl statistics still showing high cache miss numbers? Turning on debug log-level in resolved (resolvectl log-level debug) reveals the answer...

Turns out, Ubuntu chooses not to cache negative responses (LP: #1668771). In case the DNS A record (IPv4) is properly resolved, but not the DNS AAAA record (IPv6), the AAAA result is not cached and will be queried over and over.

On Ubuntu 26.04 (and likely earlier), this odd behavior can be changed in /usr/lib/systemd/resolved.conf.d/cache-no-negative.conf:

# Ubuntu defaults to Cache=no-negative. See LP: #1668771.

[Resolve]
#Cache=no-negative

The command systemd-analyze cat-config systemd/resolved.conf is useful to see the full resolved config (consisting of various parts).

posted at: 00:54 | path: /configuration | permanent link

See Pieter Bakker's tips for Postfix to pass internet.nl checks.

posted at: 15:57 | path: /configuration | permanent link