nix-community / nix-installers Goto Github PK

It appears to be just a warning, but I couldn't find it already reported, so I just wanted to make sure people are aware. I don't recall any configuration changes I might have made to trigger this warning.

Full installation log:

$ sudo dnf localinstall nix-multi-user-2.9.1.rpm 
Dependencies resolved.
================================================================================================================================
 Package                           Architecture              Version                      Repository                       Size
================================================================================================================================
Installing:
 nix-multi-user                    x86_64                    2.9.1-1                      @commandline                     40 M

Transaction Summary
================================================================================================================================
Install  1 Package

Total size: 40 M
Installed size: 40 M
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                        1/1 
  Installing       : nix-multi-user-2.9.1-1.x86_64                                                                          1/1 
  Running scriptlet: nix-multi-user-2.9.1-1.x86_64                                                                          1/1 
useradd warning: nixbld1's uid 30001 is greater than SYS_UID_MAX 999
useradd warning: nixbld2's uid 30002 is greater than SYS_UID_MAX 999
useradd warning: nixbld3's uid 30003 is greater than SYS_UID_MAX 999
useradd warning: nixbld4's uid 30004 is greater than SYS_UID_MAX 999
useradd warning: nixbld5's uid 30005 is greater than SYS_UID_MAX 999
useradd warning: nixbld6's uid 30006 is greater than SYS_UID_MAX 999
useradd warning: nixbld7's uid 30007 is greater than SYS_UID_MAX 999
useradd warning: nixbld8's uid 30008 is greater than SYS_UID_MAX 999
useradd warning: nixbld9's uid 30009 is greater than SYS_UID_MAX 999
useradd warning: nixbld10's uid 30010 is greater than SYS_UID_MAX 999
useradd warning: nixbld11's uid 30011 is greater than SYS_UID_MAX 999
useradd warning: nixbld12's uid 30012 is greater than SYS_UID_MAX 999
useradd warning: nixbld13's uid 30013 is greater than SYS_UID_MAX 999
useradd warning: nixbld14's uid 30014 is greater than SYS_UID_MAX 999
useradd warning: nixbld15's uid 30015 is greater than SYS_UID_MAX 999
useradd warning: nixbld16's uid 30016 is greater than SYS_UID_MAX 999
useradd warning: nixbld17's uid 30017 is greater than SYS_UID_MAX 999
useradd warning: nixbld18's uid 30018 is greater than SYS_UID_MAX 999
useradd warning: nixbld19's uid 30019 is greater than SYS_UID_MAX 999
useradd warning: nixbld20's uid 30020 is greater than SYS_UID_MAX 999
useradd warning: nixbld21's uid 30021 is greater than SYS_UID_MAX 999
useradd warning: nixbld22's uid 30022 is greater than SYS_UID_MAX 999
useradd warning: nixbld23's uid 30023 is greater than SYS_UID_MAX 999
useradd warning: nixbld24's uid 30024 is greater than SYS_UID_MAX 999
useradd warning: nixbld25's uid 30025 is greater than SYS_UID_MAX 999
useradd warning: nixbld26's uid 30026 is greater than SYS_UID_MAX 999
useradd warning: nixbld27's uid 30027 is greater than SYS_UID_MAX 999
useradd warning: nixbld28's uid 30028 is greater than SYS_UID_MAX 999
useradd warning: nixbld29's uid 30029 is greater than SYS_UID_MAX 999
useradd warning: nixbld30's uid 30030 is greater than SYS_UID_MAX 999
useradd warning: nixbld31's uid 30031 is greater than SYS_UID_MAX 999
useradd warning: nixbld32's uid 30032 is greater than SYS_UID_MAX 999

  Verifying        : nix-multi-user-2.9.1-1.x86_64                                                                          1/1 

Installed:
  nix-multi-user-2.9.1-1.x86_64                                                                                                 

Complete!

I've been using the pre-built RPMs here with a script, and found that the hashes changed for the same version (2.17.1) at the same URL, with no clear indication of why here in the commit logs. That was a bit unsettling.

Could this project have versioned releases and host the pre-built binaries there, maybe with some kind of version suffix or something?

I used the rpm to install Nix under Fedora 37, as this seems to be the only installer that supports SELinux.
The good news: The problems I encountered seem to be not caused by SELinux 😄

The bad news:

After a reboot, GNOME did not start. In fact, gnome-session-binary crashes:

Feb 15 19:25:47 elitebook gnome-session[4007]: gnome-session-binary[4007]: GLib-GIO-ERROR: No GSettings schemas are installed on the system
Feb 15 19:25:47 elitebook gnome-session[4007]: aborting...
Feb 15 19:25:47 elitebook audit[4007]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=4 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=4007 comm="gnome-session-b" exe="/usr/libexe>
Feb 15 19:25:47 elitebook gnome-session-binary[4007]: GLib-GIO-ERROR: No GSettings schemas are installed on the system
                                                      aborting...
<snip>
Feb 15 19:25:47 elitebook systemd[1]: Started [email protected] - Process Core Dump (PID 4022/UID 0).
Feb 15 19:25:47 elitebook audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@5-4022-0 comm="systemd" exe="/usr/lib/>
Feb 15 19:25:47 elitebook systemd-coredump[4025]: [🡕] Process 4007 (gnome-session-b) of user 1000 dumped core.

After running gnome-session --debug manually from a tty and restarting gdm.service, I could log in. I have no idea why that fixes the issue.

While debugging the problem, I wanted to reboot my system, typing reboot into my shell, fish. It responded with reboot: command not found. That should not be the case, /usr/sbin is normally in PATH.

I then noticed that /nix/var/nix/profiles/system/bin was still in the PATH, even though I had removed it from any local config of my shell. That lead me to find /usr/lib/environment.d/nix-daemon.conf, which sets PATH and XDG_DATA_DIRS.

The critical thing, at least for GNOME crashing, seems to be that $HOME/.nix-profile/share is added to XDG_DATA_DIRS. In my case, /home/david/.nix-profile/share is a symlink to /nix/var/nix/profiles/per-user/david/profile, which does not exist. GTK apps seem to have an allergic reaction to XDG_DATA_DIRS containing nonexisting paths, at least that was I could gather from a quick internet search.

After renaming /usr/lib/environment.d/nix-daemon.conf to nix-daemon.conf.disabled and rebooting, everything was back to normal.

I have not tested if creating /nix/var/nix/profiles/per-user/david/profile also fixes the problems.

it would be really nice if the installers would be uploaded to releases and the links on the gh-pages branch redirect to there, instead of increasing the size of the repo even further (already at 500MB).

I attempted to install nix-multi-user-2.8.0.rpm on RHEL 8, and it threw this error before "succeeding":

libsemanage.semanage_pipe_data: Child process /usr/libexec/selinux/hll/pp failed with code: 255. (No such file or directory).
nix: libsepol.policydb_read: policydb module version 20 does not match my version range 4-19
nix: libsepol.sepol_module_package_read: invalid module in module package (at section 0)
nix: Failed to read policy package
libsemanage.semanage_direct_commit: Failed to compile hll files into cil files.
 (No such file or directory).
semodule:  Failed!

The "obvious" thing to do to fix that is to build with an older version of libsepol, but I'm not sufficiently Nix-fluent yet to know how to do that off the top of my head. I'll try to take a look at this at some point if no one says anything.

I think this may also be revealing that the after-install hook needs set -e or so, if that sounds right to folks I can open a PR for that part.

@adisbladis would you be willing to add a license?

I would like to use the installer for VMs and containers where the nix store is on an external (to the VM/container image) mount which could be empty on first use. I think it should be possible by essentially executing the post-install hook as a systemd service before starting the nix daemon. I still need to try it out, but would there be interest in supporting that?

The rpm should do the same thing as this guide https://gitlab.com/ahayzen/silverblue-nix except instead of disabling selinux, it adds a policy just like the normal rpm.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): lock file maintenance

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

On 2024-03-31, the file at https://nix-community.github.io/nix-installers/x86_64/nix-multi-user-2.17.1.deb had the SHA-256 sum f7a72254709f700e2b804c418b1314dc326e4fa492de2375f4e68362dbc1ea46.

Today, the same URL points at a different file, with the SHA-256 sum 830093ee961ef50977ff14a450d99f18ea34479ec9188d3259cb42ebbfdf74dc.

It looks like the package may have been rebuilt with a different version of nixpkgs?

I'm not sure if this is intentional or not.

If this was intentional, I think it would be better to avoid doing this, because it breaks the ability to download a file from a known URL and then verify its integrity with a previously acquired hash.

If you need to rebuild a package even though the upstream software hasn't changed, I suggest that you introduce a packaging version, for example 2.17.1-1, 2.17.1-2, etc. For Debian packages, you may want to read https://www.debian.org/doc/debian-policy/ch-controlfields.html#version (the debian_revision field).

After running commands like nix-store --optimise, nix-store --gc, and/or nix-collect-garbage -d, there seems to be a large risk of the nix-daemon.socket breaking with permission style errors. This makes all nix commands break, and a reboot does not help the socket to come back to a working state.

I have attempted to fix this manually in the past, using the SELinux policies shipped in this repo together with relabeling using restorecon. But these steps did not seem to help the socket to come back after becoming unavailable.

This may be a nix problem, but i have not seen this be an issue when i used to run nix through the official installer shell file.

After uninstalling this package on Fedora due to a broken installation, my system was almost bricked because the SELinux policy was broken. Running sudo semodule -r nix and removing /usr/share/selinux/packages/nix.pp fixed it. There should be something in after-remove.sh to mirror this https://github.com/nix-community/nix-installers/blob/master/hooks/after-install.sh#L36-L38

Nix is still installs in /nix/store instead of /usr. That means that it will be part of the system just like everything else in the installer