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