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

feat: add a recovery shell #274

Merged
merged 1 commit into from
Aug 20, 2023
Merged

feat: add a recovery shell #274

merged 1 commit into from
Aug 20, 2023

Conversation

K900
Copy link
Contributor

@K900 K900 commented Aug 9, 2023

No description provided.

@github-actions github-actions bot added the enhancement New feature or request label Aug 9, 2023
then chroot into your NixOS system, similar to what `nixos-enter` would do
on a normal NixOS install.

You can choose an older generation to load with
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a subcommand to list available generations?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really want to make that wrapper any bigger than it needs to be, but maybe we should document that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds like something that should be handled in the distro-launcher. NixOS rescue could give a selection of the available generations and then run the appropriate command

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once we have it, yes, though I'd like to also have the fallback for people that install from their own tarballs.

@@ -8,6 +8,16 @@ let
exec ${pkgs.bashInteractive}/bin/sh "$@"
'';

nixos-enter' = config.system.build.nixos-enter.overrideAttrs (_: {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we already have the fix for NixOS/nix#7602 ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be in the next 2.13 release.

Copy link
Member

@nzbr nzbr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the systemd-container branch, I put all well-known binaries into /nix/nixos-wsl. That might be a good idea for this as well (It doesn't have to be that exact path, I can still change that, it should just be the same one for everything like this)

@K900
Copy link
Contributor Author

K900 commented Aug 9, 2023

I don't think we should have things in /nix that are not managed by Nix itself. It's just asking for trouble later. Otherwise agreed.

@nzbr
Copy link
Member

nzbr commented Aug 11, 2023

Good point. How about /usr/lib/nixos-wsl then?

@K900
Copy link
Contributor Author

K900 commented Aug 12, 2023

I'm not sure we want to be touching /usr either... Not really sure what a good place for this is.

@nzbr
Copy link
Member

nzbr commented Aug 14, 2023

image

/usr and /usr/lib look like this on my installation. I don't see how putting some extra files in there could break anything.

A great place (but I don't know how feasible it is) would be in the toplevel derivation. That would make the binaries independent of the currently active system so that it'd be possible to just use the one from the previous generation when something breaks the recovery script

Edit: It's possible through system.systemBuilderCommands

mkdir $out/wsl
cp -f ${recovery}/bin/nixos-wsl-recovery $out/wsl/recovery

Should give us /nix/var/nix/profiles/system/wsl/recovery

@K900
Copy link
Contributor Author

K900 commented Aug 15, 2023

So I just figured something out - we can't actually put this in the toplevel, because the toplevel is an absolute symlink, so it ends up pointing to the wrong place on the system distro.

@K900
Copy link
Contributor Author

K900 commented Aug 15, 2023

Also, I've changed the shebang and added an explicit error message to detect when the recovery shell is running from inside NixOS, so we can abort.

@nzbr
Copy link
Member

nzbr commented Aug 20, 2023

we can't actually put this in the toplevel, because the toplevel is an absolute symlink

Unfortunate... It might be worth revisiting when adding a recovery command to the launcher, but for now I'll merge this as-is

@nzbr nzbr merged commit faab319 into main Aug 20, 2023
33 checks passed
@nzbr nzbr deleted the recovery-shell branch August 20, 2023 15:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants