Setting up anon-base-files shows machine-id prompt followed by "OMINOUS WARNING" - *** OMINOUS WARNING ***: /etc/hosts is not linked to either hosts.whonix or hosts.whonix-orig

This prompt recently came up when updating Whonix templates. What’s the recommended action here?

Setting up anon-base-files (3:4.4-1) ...

Configuration file '/etc/machine-id'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.

I would think Y or I : install the package maintainer's version would make the most sense for anonymity. This seems to be supported by: Anonymize /etc/machine-id - #7 by Patrick

Immediately afterward, I received this:

*** OMINOUS WARNING ***: /etc/hosts is not linked to either hosts.anondist or hosts.anondist-
orig

No idea what this means. Is any user action required here?

2 Likes

Y or I should be selected. It’ll just change the value in /etc/machine-id to the same as /var/lib/dbus/machine-id so all Whonix users will have the same /etc/machine-id.

4 Likes

Yes.

Only saw this in Qubes-Whonix. Possibly the /etc/qubes/protected-files.d mechanism is broken. I.e. /etc/qubes/protected-files.d/qubes-whonix.conf not being honored. Something removed the symlink.

2 Likes
3 Likes

Happening again. In whonix-gw-15 TemplateVM:

cat /etc/hosts.anondist-orig

127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback disp8251
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

127.0.1.1 disp8251

disp8251 indicates that Qubes was writing to /etc/hosts at some point.

Any idea why Qubes /etc/qubes/protected-files.d mechanism isn’t working? What’s writing to /etc/hosts?

What’s removing the symlink from /etc/hosts to /etc/hosts.anondist-orig? @marmarek

1 Like

I see writing to /etc/hosts here: qubes-core-agent-linux/qubes-core-agent.postinst at master · QubesOS/qubes-core-agent-linux · GitHub
Maybe Whonix’s protected files configs are not installed yet at this time? You can look at the template build log and see package unpack/configure order.
There is also write in qubes-core-agent-linux/qubes-early-vm-config.sh at master · QubesOS/qubes-core-agent-linux · GitHub (guarded by protected file on /etc/hostname), but given the value (most likely build hostname) I doubt that’s the issue.

2 Likes

I could not log in to forum for several days to report this, so this might already be fixed.

After a recent update there was this warning message (OMINOUS WARNING: /etc/hosts is not linked to either hosts.whonix or hosts.whonix-orig). There was a similar warning message several years ago Setting up anon-base-files shows machine-id prompt followed by “OMINOUS WARNING”. I wasn’t sure whether I should reply to that topic or make a new one since that topic is several years old and this time it’s hosts.whonix and hosts.whonix-orig instead of hosts.anondist and hosts.anondist-orig.

1 Like

That might be what is happening. Qubes packages are installed before Whonix packages, and that is good as is for many reasons and should probably not change.

2025-05-14 09:56:19.142882 +0000 build-templates-community: .[38;5;246m11:56:19 .[96m[qb.template.whonix-gateway-17.prep] .[38;5;246m python3.11 python3.11-minimal qubes-core-agent qubes-core-qrexec.[0m

2025-05-14 10:01:05.780655 +0000 build-templates-community: .[38;5;246m12:01:05 .[96m[qb.template.whonix-gateway-17.prep] .[38;5;246mSetting up whonix-gw-network-conf (3:5.5-1) …[0m
2025-05-14 10:01:05.807287 +0000 build-templates-community: .[38;5;246m12:01:05 .[96m[qb.template.whonix-gateway-17.prep] .[38;5;246mAdding ‘diversion of /etc/resolv.conf to /etc/resolv.conf.whonix-orig by whonix-gw-network-conf’.[0m

But does any Qubes code change symlinks of /etc/hosts file? Yes. sed -i can destroy symlinks. [1]

Would it be possible to move the Qubes postinst code related to protected files into Qubes systemd units? Then it would not be done during Template build. Only during boot.

This is because postinst runs unconditionally while systemd units should not be started during the build process.

Would it be sane for Qubes to avoid touching symlinks? Would it be a good idea to express in source code “if a protect-able file is a symlink, it’s probably user managed and we should not touch it”?

Currently.

            if ! is_protected_file /etc/hosts ; then
                sed -i "/^127\.0\.0\.1\s/,+0s/\(\s$hostname\)\+\(\s\|$\)/\2/g" /etc/hosts || true
            fi

Proposed:

            if ! is_protected_file /etc/hosts ; then
                    if ! test -L /etc/hosts; then
                        sed -i "/^127\.0\.0\.1\s/,+0s/\(\s$hostname\)\+\(\s\|$\)/\2/g" /etc/hosts || true
                    fi
            fi

If acceptable, perhaps a shell function should test this instead. is_protected_file could check if it’s a symlink, and if it is, consider it protected.

I mean, who would use a symlink but still with automatic modifications?


[1] Here is a test script for developers.

#!/bin/bash

set -x
set -e

temp=$(mktemp --directory)
cd "$temp"

touch a
ln -s a b
echo "foo" > a

ls -la b
file b

sed -i 's/foo/bar/' b

ls -la b
file b

output:

+ set -e
++ mktemp --directory
+ temp=/tmp/user/1000/tmp.nZ1ROMG4Vy
+ cd /tmp/user/1000/tmp.nZ1ROMG4Vy
+ touch a
+ ln -s a b
+ echo foo
+ ls -la b
lrwxrwxrwx 1 user user 1 May 30 09:38 b -> a
+ file b
b: symbolic link to a
+ sed -i s/foo/bar/ b
+ ls -la b
-rw-r----- 1 user user 4 May 30 09:38 b
+ file b
b: ASCII text
1 Like

Yes, setting up /etc/hosts shouldn’t be relevant during template build (or update for that matter), as it inserts the host name, which normally changes between template and app qube, so needs to happen at qube boot anyway.

This I’m not sure, maybe? Do you know when else /etc/hosts may be a symlink?

2 Likes

This I don’t like, as there are cases when you do want to modify a file that is a symlink (intentionally breaking the symlink in the process). /etc/resolv.conf is such example - see Workaround systemd's broken /etc/resolv.conf symlink · QubesOS/qubes-core-agent-linux@cde610d · GitHub (and issues referenced in there) for details.

2 Likes

I’m slightly at a loss for how the qubes-core-agent-linux postinst could be causing this problem. If it’s installed before any of Whonix’s files are, the /etc/hosts writing won’t cause problems, and if it’s installed after Whonix’s files are, the protected files config will be in effect.

The only situation where I can see this not working is if whonix-base-files, qubes-core-agent-linux, and maybe also qubes-whonix are all installed at the same time. In this scenario, there’s a “race condition” between the postinst scripts of all three packages. If whonix-base-files is configured first, then qubes-core-agent-linux, then qubes-whonix, whonix-base-files will set up the symlink, qubes-core-agent-linux will clobber it, and then qubes-whonix will set up file protection after it’s too late. Any other combination will work - either whonix-base-files will end up being located after qubes-core-agent-linux (in which case it will override qubes-core-agent-linux’s /etc/hosts), or qubes-whonix will end up located before qubes-core-agent-linux (in which case /etc/hosts will be marked as protected and so qubes-core-agent-linux won’t touch it). I don’t know if the way templates are built is such that this scenario could ever happen, but I assume that’s what’s happening since that’s what would have to happen. (Either that or else something manually installs whonix-base-files first, then qubes-core-agent-linux, then qubes-whonix, which would be weird because why would you install Qubes packages in the middle of installing Whonix packages?)

Despite all the above, if Qubes packages really are installed before Whonix packages like Patrick said above, this shouldn’t happen at all since we should be diverting the file after Qubes has written to it, so that’s why I’m lost. The only other thing I can think of here is that /etc/hosts isn’t a normal conffile, no package owns it, so maybe dpkg-divert is acting funny. But I just tried making a file /etc/whatever in a whonix-workstation-17 template, then ran sudo dpkg-divert /etc/whatever.orig --rename --package whonix-base-files --add /etc/whatever just to see what would happen, and the whatever file was renamed to whatever.orig, so it seems like dpkg-divert is able to handle this.

If we really are installing Whonix and Qubes packages all at the same time, Pre-Depends isn’t the right tool to fix this. The only package that could reasonably have a Pre-Depends field is qubes-whonix, which is useless for avoiding the chain ot whonix-base-files → qubes-core-agent-linux → qubes-whonix since qubes-whonix is already at the end of the chain.

I guess my next step is to find and read through a Whonix template build log to see what’s going on.

2 Likes

Oh huh. According to build-logs-tertiary/build-r43-templates-community/log_2025-05-30_13-39-28.xz at main · QubesOS/build-logs-tertiary · GitHub, my hunch is probably right - qubes-core-agent-linux and whonix-base-files are being installed at the same time. That would do it.

Maybe the right solution here is for whonix-base-files itself to host the protected-files directives that protect /etc/hosts? It wouldn’t be the first time we’ve put Qubes-specific config in a package that might not be installed on Qubes, and given the fact that this config is critical to whonix-base-files working right, I’d say it belongs there.

2 Likes

Sure.

1 Like