Change:
consider the following which is running inside of a container: and the corresponding system profile: the original produces a store path of now let's modify to add a simple file to : instead of immediately ing to this new configuration, let's set it to activate on : looking at the system profile it looks like everything is in order here... the symlink has been switched appropriately: the new produces a store path of let's , the new profile, and look at the file we to : :thinking: what happened? what does our system profile say? :explodinghead: somehow an additional system generation, the old system generation, was created, symlinked, and activated! additionally worth noting is that + works absolutely fine at this point i'm completely lost :manshrugging: any help? :bowing_man: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --... maybe has run into this before and has some insight because he seems to know what he is doing with running on ? or at least he can confirm whether he has this issue as well? :heart: Please run and paste the result.
I can confirm I'm seeing the same thing. I followed basically the steps you laid out for testing this. Before running , I am on . My profiles look like this: I then run , and I'm now on . I then run , and my profiles look like: I then run and restart the LXC container. After logging back in, I can confirm a new profile has been created and it is pointing to the previous profile for some reason: Although, at this point, if I jump into and look at the nixos version, it does appear to be pointing to the latest NixOS version (which is system-16-link in my example). So this at least looks correct?? I'm not sure I understand exactly the semantics of vs , or how exactly the works. It is not clear to me what is the "correct" thing to happen at each of these steps. edit: Oh, I did a little more digging and I think I know why gives the seemingly correct nixpkgs version. After I've rebooted, still has the correct channel setup: So 's channel does seem like it is setup correctly, it is just the system that is not: Here, you can see that both and are pointed at the previous version (as you would expect from the state of the directory, as shown above).
I should add the following two things: I can also confirm that doing followed by , and then booting the machine back up does get the correct profile setup, as reported.I'm not able to confirm that was ever working for me in my LXC container. Looking at some of my previous system profiles, I see the same Nixpkgs commit hash being reused over and over again (corresponding to the bug you'd expect). It is possible that has never worked in an LXC container. I don't have any ideas here, except that maybe the module is doing something bad?
Thanks for looking and confirming I'm not sure the answer lies in the script... but it is somewhere down that path so I'll ping our expert in case they can take a look and provide any useful insight. I'm also not exactly sure who else to ping specifically about this... so I'll just ping some random people who know a fair bit about the lower levels of NixOS in case they can provide any insight ping
Could you comment the switch-to-configration output as well?
I don't know a lot about lxc, but these unconditional commands look rather suspicious:
Thanks for the comments everyone! I spent a few minutes poking around and found a few things. By commenting out this line the new generation is not created, though + still doesn't activate the new generation. More on that below... The doesn't do much when called via - it . The script, which calls , looks to be as it should. Our module includes which will use to boot the new system... but since we are running this replacement of never happens, which is the cause of the problem here! I confirmed that if I manually replace and reboot everything regarding works as expected. I don't think will execute any code from the module system directly (ie. activation scripts). So how do we teach to run ? I appreciate any and all thoughts on this topic :bowing_man:
I found some time to dig into the depths of how NixOS builds systems and now have the understanding I was missing to solve this problem.

Discussion:
extraCommands = "mkdir -p proc sys dev"; }; <ins> system.build.installBootLoader = pkgs.writeScript "install-lxd-sbin-init.sh" '' #!${pkgs.runtimeShell} ln -fs "$1/init" /sbin/init ''; </ins> # Add the overrides from lxd distrobuilder # https://github.com/lxc/distrobuilder/blob/05978d0d5a72718154f1525c7d043e090ba7c3e0/distrobuilder/main.go#L630 systemd.packages = [