/etc/os-release is an absolute symlink but should be a relative one for e.g. systemd-nspawn

[florianjacob]

Issue description

The file /etc/os-release is an absolute symlink /etc/os-release -> /etc/static/os-release, and that is an absolute symlink /etc/static/os-release -> /nix/store/98dh917436hpwwz141l9fv2qclfscffw-etc-os-release. This results in problems when trying to execute a systemd installation / root image via systemd-nspawn, as systemd-nspawn requires etc/os-release to be working from outside of the image.

Excerpt from the os-release manpage:

/etc/os-release should be a relative symlink […]. A relative symlink instead of an absolute symlink is necessary to avoid breaking the link in a chroot or initrd environment such as dracut.

This would be very handy for people like me who wanted to test NixOS and develop their configuration.nix while still using another distribution prior to making the switch.

Related issue: #9884

Steps to reproduce

Boot a (e.g. live) system that is not NixOS and try to execute NixOS via systemd-nspawn. It will fail because it cannot find /etc/static/os-release on the host system. On NixOS hosts, this issue is shadowed as then the host system's os-release file is used.

Technical details

• System: 18.03.git.fafa57d (Impala)
• Nix version: 1.12pre5511_c94f3d55
• Nixpkgs version: 17.03.1606.6bf7904140
• Sandboxing enabled: false

[palmeida]

There's another use case for this. os-prober can use different methods to detect Linux OSes in other partitions, and if it had access to os-release it would be easier to fill in the parameters it needs (short name and long name, which usually includes the version).

In particular, the Debian default installation of os-prober looks for os-release only after looking at other files in /lib , so a custom entry would still be needed for NixOS, but that custom entry would be easier to write and more robust if we could access os-release, in a standard location, from os-prober (it's possible to look for os-release in /nix/store, of course, but not as nice).

[palmeida]

It seems the goal of this issue could be achieved by setting the environment.etc."os-release".mode option to "0644". That should copy the file instead of creating a symlink. Looking at the source, I see two possibilities to make it the default:

1. Add an option in etc.nix to make the link relative and update the build code in make-etc.sh accordingly. (Alternatively, use the existing option "mode" and pass a different value to make a relative link.)
2. Edit version.nix and set the environment.etc."os-release".mode option there.

[florianjacob]

@palmeida both sounds sensible, I'd either go with something like mode = "relative-symlink" or the mode = "0644" ”workaround”. It seems like setup-etc.pl is also involved somehow, as there's an undocumented "direct-symlink" mode in it.

@palmeida can you / do you want to implement one of your solutions?

Otherwise I'd provide a PR, and for me, I'd go with option 2. While Option 1 seems to be cleaner, I don't think there are many other cases where you really need relative links (accesses from outside of the OS is the only thing I could think of — tried to judge how many of the existing mode assignments are actually to work around the absolute link issue, but not sure), I don't feelt too confident in writing proper bash or perl, a copy will just work fine and in combination with a comment saying we're doing this to avoid the absolute symlink and not for achieving the actual mode or mutability, it should be ok and make things work with minimal effort.

[palmeida]

@florianjacob I completely agree with your analysis. If generality is not useful here (I don't know enough to judge), option 1 is a lot of extra work for nothing. In my Debian system, /etc/mtab is the only other relative link in the root of /etc, there are others deeper in the hierarchy. I don't know what could make sense in NixOS. Also, maybe the mode of os-release could be 0444, to reinforce the idea that people aren't supposed to edit the file.

If you are willing to make the PR, please do. I am completely new to NixOS, I have never even edited anything in my system, other than configuration.nix, so it would take me a while, and it's time I won't have in the near future.

[florianjacob]

PR at #35364 - @palmeida maybe you could test with os-prober? 🙂

[palmeida]

@florianjacob I'm not on NixOS right now, but I can confirm os-prober works if /etc/os-release is a regular file. I have created it with the environment.etc."os-release".mode option in my configuration.nix and then tested with a probe that just checks for the existence of /etc/os-release, and the result of os-prober is:

/dev/sda2:NixOS 17.09.3023.c882c4dd55e (Hummingbird):NixOS:linux

I'll test the commit when I have time (not sure exactly when that will be...).

[florianjacob]

@palmeida That's already sufficient I'd say, as I do nothing else in the PR and I tested it's now a regular file with 0440. Thanks!

[palmeida]

@florianjacob I agree, it's such a simple change, if you tested it and I tested the "end result", it should be fine.

[danbst]

Note that PR was reverted #54980

[stale]

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.