Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: make nix work out of the box on rpm-ostree #8

Closed
wants to merge 4 commits into from

Conversation

yajo
Copy link
Contributor

@yajo yajo commented Apr 25, 2022

The main difference is that restorecon is executed against /var/nix instead of against /nix, because that's the path that actually exists at that point.

To make it work, SELinux policies are duplicated for the /var/nix prefix.

From there onwards, no more recursive restorecon calls are needed.

Also fixed a bug in the start conditions for the socket.

@moduon MT-83


I know you closed #5 but I hope you can reconsider it now that, with this patch, all works out of the box.

All you need to do is build it, and then rpm-ostree install --reboot ./nix.rpm. Then, after reboot: systemctl enable --now nix-daemon.

@yajo yajo changed the base branch from rpm-ostree to master April 25, 2022 09:27
@yajo yajo force-pushed the rpm-ostree branch 2 times, most recently from a823e33 to 5ae2f48 Compare April 25, 2022 10:16
@yajo
Copy link
Contributor Author

yajo commented Apr 25, 2022

Booting still warns with:

abr 25 11:32:54 yajolap systemd[1]: nix-daemon.socket: Failed to create listening socket (/nix/var/nix/daemon-socket/socket): Permission denied
abr 25 11:32:54 yajolap systemd[1]: nix-daemon.socket: Failed to listen on sockets: Permission denied
abr 25 11:32:54 yajolap systemd[1]: nix-daemon.socket: Failed with result 'resources'.
abr 25 11:32:54 yajolap systemd[1]: Failed to listen on Nix Daemon Socket.
abr 25 11:32:54 yajolap systemd[1]: Starting Nix Daemon...
abr 25 11:32:54 yajolap systemd[1]: Started Nix Daemon.

However it seems to work as expected.

Also, since Silverblue is so special, it's not really working after boot. You still need to do:

grep -E '^nixbld:' /usr/lib/group | sudo tee -a /etc/group
grep -E '^nixbld.*:' /usr/lib/passwd | sudo tee -a /etc/passwd
systemctl reboot

After installing and rebooting.

@yajo
Copy link
Contributor Author

yajo commented Apr 25, 2022

Hmm it still fails weird when I rpm-ostree update.

@yajo yajo marked this pull request as draft April 25, 2022 11:35
@adisbladis
Copy link
Member

I know you closed #5 but I hope you can reconsider it now that, with this patch, all works out of the box.

I closed it because I didn't feel motivated to push it through. Of course it's more than welcome for others to pick up the mantle :)

@yajo
Copy link
Contributor Author

yajo commented Apr 26, 2022

Thanks! I really love Fedora Silverblue and nix, and both share similar mindsets, but not being able to mix both was very sad.

I just hope I can get this to a point where I don't sacrifice experience for normal Fedora users. Having a couple extra systemd units shouldn't be a big problem as long as they just work IMHO.

The point of having to add nixbld group and users manually is relatively normal in rpm-ostree world. It's actually documented. We would just drop a note in the readme and it should be enough.

Now the biggest problem I have with current code is that it logs this after each boot:

abr 26 07:11:44 yajolap systemd[1]: sockets.target: Found ordering cycle on nix-daemon.socket/start
abr 26 07:11:44 yajolap systemd[1]: sockets.target: Found dependency on nix.mount/start
abr 26 07:11:44 yajolap systemd[1]: sockets.target: Found dependency on nix-setup.service/start
abr 26 07:11:44 yajolap systemd[1]: sockets.target: Found dependency on basic.target/start
abr 26 07:11:44 yajolap systemd[1]: sockets.target: Found dependency on sockets.target/start
abr 26 07:11:44 yajolap systemd[1]: sockets.target: Job nix-daemon.socket/start deleted to break ordering cycle starting with sockets.target/start

For some weird reason, it thinks that nix-setup.service depends on basic.target, which itself depends on sockets.target and creates a cycle. The error itself produces some weird logs at boot and shutdown, and has some side effects such as not being able to log in an Xorg session. Obviously not acceptable.

My current workaround is to systemctl disable nix-daemon.socket nix-daemon.service and then systemctl start nix-daemon manually after each boot. But that's not very elegant.

I've tried several ideas to fix the loop, but none of them worked. Do you have any suggestion?

@yajo yajo marked this pull request as ready for review May 2, 2022 08:40
@yajo yajo marked this pull request as draft May 2, 2022 08:55
@yajo yajo marked this pull request as ready for review May 2, 2022 14:27
@yajo
Copy link
Contributor Author

yajo commented May 2, 2022

Finally it seems I found how to deal with all corner cases and unit loops. I added to the README specific rpm-ostree instructions. I'm using it right now on my dev PC and works fine. Also tested in a bare-bones Fedora Silverblue VM I've set up. Just follow the instructions and all will go fine.

@blackberryshortcake
Copy link

blackberryshortcake commented May 26, 2022

On Silverblue 36, after rpm-ostree install --reboot ./nix-multi-user.rpm (and rebooting), nix --version failed, because nix wasn't even in $PATH. From what little I gathered from the boot logs, no nix-related services were started either. I ran systemctl enable --now nix-daemon once and after

# Verify all works
nix --version
# Create nixbld group and users
grep -E '^nixbld:' /usr/lib/group | sudo tee -a /etc/group
grep -E '^nixbld' /usr/lib/passwd | sudo tee -a /etc/passwd
sudo groupmod nixbld -aU $(grep -oE '^nixbld[[:digit:]]+' /usr/lib/passwd | tr '\n' ,)
# Reboot again
systemctl reboot

everything worked as expected. I've run rpm-ostree upgrade multiple times since and I haven't run into any issues. Thank you for your work, it's much nicer than running nix in a toolbox.

@yajo yajo force-pushed the rpm-ostree branch 2 times, most recently from f803f3f to ed1e3c5 Compare May 27, 2022 06:44
@yajo
Copy link
Contributor Author

yajo commented May 27, 2022

Thanks for your feedback. I rebased and updated the rpm-ostree-specific instructions on the readme to make them more straightforward.

@jcdickinson
Copy link

Are there any plans to merge this? I am currently using my rather janky script to get Nix running on my machines, and would like to migrate to this.

@yajo
Copy link
Contributor Author

yajo commented Aug 2, 2022

I've been using this for 2 months on my dev Silverblue machine and it works like a charm. It's up to the maintainer to decide if he wants to merge. On my side AFAIK it's all done.

@jcdickinson
Copy link

jcdickinson commented Aug 8, 2022

@yajo: I am attempting to bake this into an OSTree. I have found that this is needed in nix-setup.

+ mkdir -p /var/nix/var/nix/daemon-socket/
+ touch /var/nix/var/nix/daemon-socket/.keep

  # Set up root channels ()

Without that, the daemon-socket dir doesn't exist, which fails the prerequisite for the systemd socket.

@yajo
Copy link
Contributor Author

yajo commented Aug 22, 2022

Would you mind to open a PR against my branch?

@jcdickinson
Copy link

@yajo: moduon#1

@yajo
Copy link
Contributor Author

yajo commented Oct 27, 2022

Hi folks. This has been working without any hassle for some months. Do you think you could merge it?

FWIW I built it locally, so you can test it fast: nix-multi-user.rpm.zip

adisbladis and others added 3 commits November 4, 2022 15:58
The main difference is that restorecon is executed against `/var/nix` instead of against `/nix`, because that's the path that actually exists at that point.

To make it work, SELinux policies are duplicated for the `/var/nix` prefix.

From there onwards, no more recursive restorecon calls are needed.

Fixed a bug in the start conditions for the socket.

Start the nix-setup.service before nix-daemon.service, not before nix.mount. This is because mounting the empty directory first doesn't have any negative effect, but running the service before the mount enters a service dependency loop that we want to avoid.

@moduon MT-83
Following instructions from https://fedoraproject.org/wiki/Packaging%3aUsersAndGroups#Dynamic_allocation now:

- Do not hardcode GID/UID.
- Preexisting users is normal sysadmin work.
- Use getent to know that.
@yajo
Copy link
Contributor Author

yajo commented Nov 4, 2022

I rebased and rebuilt to include #14 and other changes. Updated zip: nix-multi-user.rpm.zip

@dnkmmr69420
Copy link
Contributor

https://gitlab.com/ahayzen/silverblue-nix check this out

@jcdickinson
Copy link

@dankmemermusic

We need to disable SELinux otherwise the nix socket cannot be created.

This repo does not have that issue, it creates the required SELinux policies.

@orowith2os
Copy link

What's the current status of this being merged? If it needs more testing, I can install it locally and see if I can find any issues.

@orowith2os
Copy link

Hm, found a weird issue.

If I run my rpm-ostree config without this installer, it works just fine. However, the moment I install it, my terminal apps don't launch, and Firefox's theme resets. Uninstalling this installer fixes all of that. It seems to happen regardless of whether or not the systemd service is going, too.

@yajo
Copy link
Contributor Author

yajo commented Nov 28, 2022

I've been using this package for more than 6 months without an issue.

@orowith2os have you followed instructions in the readme? Those that are added in this PR

@orowith2os
Copy link

I've been using this package for more than 6 months without an issue.

@orowith2os have you followed instructions in the readme? Those that are added in this PR

I did them step-by-step, and still have the issue.

My Firefox theme goes back to light, Nautilus and any terminal apps don't open, and some other (GNOME) apps don't work, like Disks. Are there any logs I should upload?

@yajo
Copy link
Contributor Author

yajo commented Nov 29, 2022

Could you make sure your nix profile is totally empty? I'm thinking that maybe some nix apps are conflicting with usual fedora apps.

Otherwise, you could post your logs for all *nix* systemd units. And the same for any other failed units you find when booting with the nix package installed.

@orowith2os
Copy link

@yajo I haven't installed anything via Nix, only enabled it, so I don't see why anything would conflict.

On the systemd unit topic, any commands I should use to grab the logs?

@orowith2os
Copy link

okay this is a lil weird

I thought I could get into a terminal using vscode's terminal emulator, but something's weird with dbus, I think, and it gives me "the name is not activatable"

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/should-the-default-nix-store-location-be-below-usr/32222/13

@maribox
Copy link

maribox commented Mar 11, 2024

I now installed nix with the rpm package, but when I run nix in my shell I get command not found.

The only places where I have found a nix executable are:

/home/<username>/cargo/registry/index/index.crates.io-6f17d22bba15001f/.cache/3/n/nix
/nix/store/11glc2yk4jmycvk42q6kikpdcpbnbf6w-nix-2.17.1/bin/nix
/nix/store/11glc2yk4jmycvk42q6kikpdcpbnbf6w-nix-2.17.1/share/bash-completion/completions/nix

should I just add the bin in the store to path? 😬

@yajo
Copy link
Contributor Author

yajo commented Mar 11, 2024

Not even after rebooting?

@maribox
Copy link

maribox commented Mar 11, 2024

I found out that it works when I run bash but in my standard shell zsh it does not work

@yajo
Copy link
Contributor Author

yajo commented Aug 28, 2024

I'm no longer using rpm-ostree systems, and https://github.com/DeterminateSystems/nix-installer supports those, so I have no longer interest in this feature. Closing. You can continue in #22 if you wish.

@yajo yajo closed this Aug 28, 2024
@yajo yajo deleted the rpm-ostree branch August 28, 2024 09:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants