Oct 30 06:33:12 host qubes-whonix-postinit[1420]: Failed to read /qubes-netvm-gateway6
Oct 30 06:33:12 host qubes-whonix-postinit[1386]: WARNING: 'qubesdb-read /qubes-netvm-gateway6' failed!
Oct 30 06:33:14 host tor-config-sane[1689]: Failed to read /qubes-netvm-gateway6
Oct 30 06:33:14 host tor-config-sane[1686]: WARNING: 'qubesdb-read /qubes-netvm-gateway6' failed!
This entry is expected to be missing if IPv6 is not enabled (the default). Maybe the scripts should be modified to avoid printing the message? Alternatively, it should be ignored by systemcheck.
Oct 30 06:33:15 host kernel: faux_driver regulatory: Direct firmware load for regulatory.db failed with error -2
Could be some missing package, but in context of qubes-whonix it’s irrelevant as Whonix Gateway isn’t supposed to have real devices attached anyway. Can be ignored.
Oct 30 06:40:17 host qrexec-agent[3671]: 2025-10-30 06:40:17.997 qrexec-agent[3671]: exec.c:902:find_qrexec_service: Warning: ignoring skip-service-descriptor=true for execute executable service /etc/qubes-rpc/qubes.UpdatesProxy
Similar to the other option (already removed in overridden config), this one is only for socket-based services.
And finally, on the Whonix Gateway 18 template itself:
Oct 30 10:10:15 host PAM_tmpdir[1215]: /tmp/user/1001 owned by uid 0 instead of uid 1001. Failed to create safe $TMPDIR
Ugh, not this again… will investigate. (This keeps popping up, but I don’t know why because the thing that made it pop up was some now-obsolete and I thought completely removed sdwdate code.) The others I can set to be ignored (if @Patrick hasn’t beat me to it already).
So far I’m unable to reproduce this on my end, with a Whonix-Gateway 18 template running the latest packages from the trixie-developers repos. I started it, ran systemcheck --verbose --leak-tests in it, then shut it down, five times (in the hopes of triggering a race condition if this was a race condition). All five times this error didn’t appear.
Is there anything in the tests themselves that creates temporary files or directories in the qube before sysmaint logs in? That might trigger this.
The test is running qvm-run -ap whonix-gateway-18 whonixcheck -–verbose –-leak-tests –-cli
I don’t see anything else started there (things started on earlier boots shouldn’t matter as /tmp is not persistent, right?). In any case, even if something is started, it would need to be running as root (owned by uid 0 part), but why would it touch /tmp/user/1001 then? Is it maybe some weird interaction of pam_tmpdir with sudo/privleap?
I’m not managing to reproduce it with that either.
True.
Probably not privleap, as privleap doesn’t use /tmp for anything unless put into a special test mode (which is only applicable when a special “regression testing mode” option is passed, not something that should ever occur “in the wild”). I wouldn’t really expect sudo to use $TMP, $TMPDIR, or similar (it looks like it may use /tmp but that shouldn’t cause this issue). I also grepped through both Whonix’s and Kicksecure’s package code for the string /tmp/user and didn’t find explicit use of the path in a context that would cause this issue. So it seems like something must be picking up TMPDIR and doing the wrong thing with it. I don’t think it could be a privleap action though since privleap intentionally does not allow the caller to dictate the callee’s environment, thus I don’t think TMP or TMPDIR could be “leaking” there.
edit: Would it be useful if I wrote a C program that used fanotify to try to trace what processes were modifying things under /tmp and wrote that information to a log file? That way you could reproduce the issue on your end, then look at the log to determine what process was at fault.
I don’t mean sudo itself, but something started as user 1001 (with TMPDIR=/tmp/user/1001 variable) and then called something as root, without adjusting/clearing TMP.