Change:
# Need to run `nixos-rebuild` twice because the first run will install # GRUB anyway with subtest("Switch system again and install bootloader"): <del> result = machine.succeed("nixos-rebuild switch --install-bootloader") </del> <ins> result = machine.succeed("nixos-rebuild switch --install-bootloader 2>&1") </ins> # install-grub2.pl messages assert "updating GRUB 2 menu..." in result assert "installing the GRUB 2 boot loader on /dev/vda..." in result

Discussion:
I've set up a github action to deploy nixos on remote hosts with command But after , it stops working. The failed job shows it hangs for about 2 hours and exit abnormally. On the target host I found exited successfully but the process hangs. I can also reproduce it locally with . Might be related to tty. Steps to reproduce the behavior: nixos-rebuild --target-host either in github action environment or locally with systemd-run Exit successfully <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
This may be related to , that commented on the original PR but I couldn't find a way to reproduce. I imagine this problem may only happen when systemd itself is updated. Could you confirm that this issue happens in every update or just big ones ?
BTW, looking at your logs it seems I missed to preserve the bootloader updates inside the , so this also needs to be fixed.
This works fine to me: Can you pass the flags and post the output of the TTY to check the logs? Because without it doesn't work for me because my configuration is Flake based and it compains the lack of .
I can only reproduce it without the --tty flag. Here's the logs The second command without flag hangs. But on the remote machine switch-to-configuration runs successfully and only systemd-run process hangs.
I believe it's not related to a systemd update since I can reproduce it by running the same command again without an actual system upgrade.
See the reasoning here: To workaround for now you can pass to , for example: Edit: no it is not. Keep in mind that is a temporary workaround until all activation scripts are fixed to not depend on the environment and will be removed in the future.
That HOME(/var/empty) is not writable. It will not exit with error.
! It seams will hang if no tty is available. Not sure if it's a feature or bug.
! Adding a flag could prevent it from hanging. I guess we should add a flag in ?
I guess it is fair: Especially because it seems and can be used together and will do the appropriate thing.
I will test and add it to if it works.
BTW, from the manual it seems that this is a feature.

will connect to the terminal it is invoked on, and there is no fallback unless is passed. So adding both flags seems correct in this case.
I tried to add the flag to the call, see patch: But got stuck with some strange errors during tests: Not sure what is happening here, maybe can help? For now I think one workaround can be to wrap the call to in a bash call, something like:
BTW, I think we can substitute with , because is not an interactive process anyway. I tried this and it works in my configuration, however still gets the same error during the tests.
I think I found a way to fix the issue, opened a PR:
I didn't work ( and doesn't work together). I will probably need further help in this issue.
Investigating the test error: Found the tty settings being changed. Logs: Logs diff: I'll try to restore the settings and see if the test could pass.
I'm getting an identical hang using Packer to produce EC2 EBS images; with a Packer HCL fragment containing: I'm starting from the NixOS-23.05.555.-* AMIs. I can confirm the workaround works with Packer.
Since upgrading to I'm having issues that sound similar: if I run just it works fine, but if I run then it hangs after this: until I ctrl-C it. Looking at while it is hanging, it does indeed seem to be : and indeed completes just fine. (I assume the fact that I'm passing in a different nixpkgs with is irrelevant, but I'm including it just in case; in my real use case the stdin I feed to is more interesting, this is just a minimal reproduction) I have an effective workaround for my case (just running commands in one-by-one, instead of feeding a script on stdin to , which I guess means that there is a pty available) but happy to help debug if necessary.