fix: container os still sometimes reported erroneously

[dantebarbieri]

Description

Handle each possible OS file:

• /etc/os-release
• /etc/lsb-release
• /etc/openwrt_release
• /usr/lib/os-release

Follow broken links from the host (/mnt/host) and link them to the same file within the container.

In other words, /mnt/host/etc/os-release may link to something else, like /mnt/host/nix/store/znmly1f5ahwz9yrl7h89ljqxyr0xrk94-etc-os-release and the container establishes /etc/os-release to link to the same file by resolving the host links.

If at least one file from the host can be found and successfully linked, now the other candidate files from the container are cleaned up so that they do not incorrectly report the container's OS information.

I also improved the logging so you can see which candidate files were linked and which were not:

In this case, my host uses both /etc/os-release and /etc/lsb-release, but neither of /etc/openwrt_release nor /usr/lib/os-release. As such:

dash-1  | OS metadata files:
dash-1  |   /etc/lsb-release -> "/mnt/host/nix/store/3zklxvjkwjb4ds0lf2jlcqcdggp1d272-etc-lsb-release"
dash-1  |   /etc/os-release -> "/mnt/host/nix/store/znmly1f5ahwz9yrl7h89ljqxyr0xrk94-etc-os-release"
dash-1  |   /usr/lib/os-release [missing]
dash-1  |   /etc/openwrt_release [missing]

Related Issue(s)

#1232

[MauriceNino]

Overall, I am having a bit of doubt, that this is the best solution to the problem. There is a lot of manipulation going on, just so systeminformation can read the data from those specific files - maybe it would be better to just hook into the static information gathering here and manually read the values from the hosts files, similar to what systeminformation does, just at the correct base directory (here you can see what the lib does).

What do you think?

[MauriceNino]

Setting up the OS version linking should not fail the entire startup. Adding a warning to the logs and going on is enough.

[dantebarbieri]

Good point. I can add back a warning to logs. I don't want to impact startup.

[dantebarbieri]

First, sorry for the delay, life has been busy in September.

Overall, I am having a bit of doubt, that this is the best solution to the problem.

I think you are correct. The main cause of the issue I am seeing is that NixOS uses absolute-path symbolic links for its os-release files.

However, there is still an issue with my earlier code which is that the use of systeminformation uses strings in lsb-release to override those in os-release. This is a standards-compliant handling of these files. The solution needs to be replacing lsb-release inside the container with that of the host, or if the host does not have this file, then deleting it from the container (if it exists).

There is a lot of manipulation going on, just so systeminformation can read the data from those specific files - maybe it would be better to just hook into the static information gathering here and manually read the values from the hosts files, similar to what systeminformation does, just at the correct base directory (here you can see what the lib does).

I'm not especially interested in rewriting the functionality in systeminformation, since it is very close to what we want.

I think the code looks more complex than it is. Mainly, what is happening is that the host files are resolved (with a special link resolver which can handle absolute symlinks from inside Docker but also works outside of Docker), then they are linked appropriately within the container keeping their original names.

The code initially would link both /etc/os-release & /usr/lib/os-release to whatever we found which was a bug because the lsb-release override file was not altered and continued to expose container os info.

The code now seeks out all OS_CANDIDATES and ensures a link, removing any container os-info files which were not present in the host in order to avoid the lsb-release class of issue (a scenario where the container has an overriding os-info file not present on the host). And due to this guard clause we can safely call this function at any time to fix the files in the container based on those from the host.

What do you think?

I would be happy to clean up any errors that can occur on startup since I don't want this change to break startup behavior (or anything critical really). I just want to see the correct OS info, and ultimately this bug is more the fault of the NixOS maintainers for using absolute paths in the symbolic links to os-release, but they aren't fixing it. We can work around that bug here.

Ultimately, you get the final say on dashdot. Do you want me to make the tweaks regarding startup failures and keep the behavior I outlined or is this too much complexity for a niche problem? What do you think?

[MauriceNino]

First of all, sorry for the huge delay in my answer!

I have a hard time following why this is necessary. The way I see it, there are a few locations where the host OS can save its information and just checking and symlinking them should be enough, right? I am just not sure, if merging this is worth the added complexity. Because let's be real - if something breaks, I am the one who is going to maintain it. And I don't really get what's going on here.