@kalbasit, yes - the default/example config ships with xterm installed and X11 works fine. you can install the RPM, launch xterm via qvm-run ( app shortcuts aren’t populated yet ), cd to /etc/nixos and customize the config. note that hardware.graphics.enable isn’t set so you’ll probably want to do that to enable opengl.
I’m using a template installed from the published RPM to run my entire personal config, browser, dev tools, etc.
I know Guix, but don’t understand Nix.
How does user use proxy on NixOS template?
https_proxy=$all_proxy nix…
Is this correct command of proxy?
@scales you shouldn’t need to in most cases. by default this template/expressions add an alias which will pluck it out of the nix-daemon environment ( where it was set by a modified version of the qubes update-proxy-configs script. )
alias nix='all_proxy=$(systemctl show nix-daemon -p Environment | grep
-oP '\''(?<=all_proxy=)[^ ]*'\'') nix'
manually setting all_proxy should also work
@evq I tried to create an AppVM based off of the nixos template, and it seems to be stuck during boot:
A start job is running for Adjust root filesystem size
Let me know if you need the entire console, or anything else.
@kalbasit hmm… try this new rpm instead for now, I’ll investigate:
@evq Thank you, this one works.
I’ve been thinking about the template/AppVM /nix relationship. As it stands, /nix in the template has whatever was built in the system and any changes to /nix in the AppVM do not persist. This poses a problem for AppVMs that have to pull a lot of paths, for example, a nix-shell project. It’s a difficult problem to address, for sure.
What if we mount a /rw/bind-dirs/nix/store to /nix/store but then bind-mount anything from the original /nix/store back on top of the new /nix/store? Not sure if it will work, overkill but maybe worth a try to combine template’s Nix with AppVM’s Nix? /nix/store is immutable anyways so it should not break Nix itself, although we have to be mindful that the Nix daemon also does some /nix/store mount/remount to make it rw for the daemon but ro for all other users.
how i’m currently handling this is to create different specializations for each appvm configuration and I have a systemd unit which dynamically switches the specialization on boot based on the qubes vm name. it’s a bit hacky but it works. i suppose for the use case you mentioned, it’d be a little less ideal to create specializations for the various nix-shell projects since they may be managed by other repos.
I thought about using the experimental overlay store which sounds closer to what you’re describing. iirc there would need to be special handling to fixup paths after upgrading the template. also if you ever do garbage collection in the template, you’d have to deal with the potential for broken paths, etc. it seemed possible but annoying.
another thought - what if we made a qubes RPC service for nix, such that each appvm would use a remote store shared by all appvms as a sort of pull-through cache? perhaps we could even use the template itself in this role. in your example, running the nix-shell invocation would cause the template to pull / build the dependencies and then copy them locally to the appvm. after a restart of the appvm, either they would be available locally if the template shut down or it could pull them quickly via the store rpc.
such an rpc service could also be a place to take further advantage of qubes features e.g. we could add vm sandboxing to builds, by automatically performing them in disposable vms.
In Guix, user uses ‘guix pull’ command to update packages and '‘guix package’ command to install or remove packages.
That’s it.
How can user do same thing in NixOS?
I read NixOS official manual but could not understand how NixOS manages packages.
There are pros/cons to both approaches as you already highlighted with the overlay store (thanks for reminding me that it’s a thing). The rpc approach means that the template VM would grow quite large as AppVM pull stuff into it, and we would also have to deal with garbage collection and for that we would have to probably keep gcroot in sync from AppVMs to the template. We should probably work on a proof of concept for the RPC approach as it better aligns with Qubes.
It depends on how you want to access those packages.
If you want to have it available for the entire system (under /run/current-system/sw/bin then edit /etc/nixos/configuration.nix and add any package of your choice to the option environment.systemPackages and then run sudo nixos-rebuild switch. In @evq 's template, you’ll notice she already has xterm in there so just add it next to it. You can find a list of packages here.
If you want to have access to a package in your current shell (transient package) just type nix shell nixpkgs#<name> such as nix shell nixpkgs#vim.
You can also install a package for your own profile with nix profile install nixpkgs#<name> such as nix profile install nixpkgs#vim.
Hope this helps!
I use ‘sudo nixos-rebuild switch’, error message:
warning: you don't have Internet access; disabling some network-dependent features
error: while updating the lock file of flake 'path:/etc/nixos?lastModified=173...'
while updating the flake input 'nixpkgs'
error: unable to download 'https://channels.nixos.org/flake-registry.json': Could not resolve hostname (6)
sudo of NixOS template perhaps does not use proxy.
I use ‘nixos-rebuild switch’, error message:
warning:'/etc/nixos/flake.lock'
error: while updating the lock file of flake 'path:/etc/nixos?...'
error: opening file '/etc/nixos/flake.lock: Permission denied
Without sudo, ‘nixos-rebuild switch’ command has not Permission.
What Do I?
As noted by @evq you should first do sudo -s and then write nixos-rebuild switch.
That worked, thanks!
In other words, Nix have not simple commands like Guix does?
I never used Guix so I don’t know. Nix is not easy, but nix shell and nix profile tend to be easier to start using Nix than having to worry about entire system config. This might be quite the journey for you to learn Nix inside this template since it’s new and not very well tested. I recommend that you start by installing Nix on a standalone VM based on fedora-40-xfce template with the following command from DeterminateSystems nix-installer.
curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | \
sh -s -- install
You can experiment with nix profile inside that standalone VM (there’s no /etc/nixos since it’s not NixOS) and it should be easier for you to experiment in an environment that’s well tested.
Case of Guix, if user hopes packages upgrade, type command ‘guix pull’ only.
If user hopes new package install, type command ‘guix package ‘package name’’ only.
No complicated settings or instructions are required.
I read NixOS official manual, there is not Guix like simple command in Nix?
That would be nix profile install and nix profile upgrade
Thanks for this @evq! I am looking at getting nixos running now. Are you able to include instructions for building the rpm template package? I am new to nixos so maybe it will become obvious once I learn more but some tips now would be invaluable. I am also trying to get your individual qubes-* packages installed in a working hvm install of nixos.
Ok, I think I found the answer. In nixos, checkout repo and run: nix build .#rpm
This will generate the rpm package.
Any progress on this?