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

nixos/boot: add option to disable initrd #80114

Merged
merged 1 commit into from Mar 16, 2020
Merged

Conversation

rnhmjoj
Copy link
Contributor

@rnhmjoj rnhmjoj commented Feb 14, 2020

Motivation for this change

Fix issue #6520

Things done
  • Tested via one or more NixOS tests
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@danbst
Copy link
Contributor

danbst commented Feb 14, 2020

would it make sense to create the enable option in stage-1.nix instead?

@rnhmjoj
Copy link
Contributor Author

rnhmjoj commented Feb 14, 2020

@GrahamcOfBorg test boot boot-stage-1

@rnhmjoj
Copy link
Contributor Author

rnhmjoj commented Feb 14, 2020

would it make sense to create the enable option in stage-1.nix instead?

You are right, it makes more sense there.

@rnhmjoj
Copy link
Contributor Author

rnhmjoj commented Feb 14, 2020

@GrahamcOfBorg test boot boot-stage-1

@@ -187,7 +187,7 @@ in

###### implementation

config = mkIf (!config.boot.isContainer) {
config = mkIf config.boot.initrd.enable {
Copy link
Contributor

Choose a reason for hiding this comment

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

is there any particular need to disable this config based on boot.initrd.enable? Everything related to initrd will be disabled in that case, why disable rest?

For example, system.build.kernel, boot.kernelParams, hardware.firmware are irrelevant to initrd, right?

cc also @acertain to explain usecase.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, it seems we have to separate the container from initrd logic somehow.

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've split the the configuration in two sections and used mkMerge. I'm not so sure if this is 100% correct.

@danbst danbst merged commit fab05f1 into NixOS:master Mar 16, 2020
@rnhmjoj
Copy link
Contributor Author

rnhmjoj commented Mar 16, 2020

Thank you for the review!

@rnhmjoj rnhmjoj deleted the initrd branch April 7, 2020 12:41
@rnhmjoj
Copy link
Contributor Author

rnhmjoj commented Apr 27, 2020

I guess it should be safe enough, it's been a month and no reported issues.

@samueldr
Copy link
Member

It would be nice to backport to 20.03, so https://github.com/NixOS/mobile-nixos would work with 20.03

While I agree that it should be safe enough, doing this on account of Mobile NixOS alone shouldn't be the deciding factor. Right now, to reduce complexity, it is expected that Mobile NixOS is built against the ever-evolving nixos-unstable channel. I do not know if there are other incompatibilities with 20.03, and do not try to keep it backward compatible for now.

Though, with that said, if there are incompatibilities, it would be fine if contributions can be provided, conditional on the imported nixpkgs revision.

I am ±0 with backporting for Mobile NixOS, -1 for backporting a change in NixOS past the freeze. Though with that said, this change is pretty self-contained and safe. So maybe +1 as far as risk goes (where +1 is not risky at all).

@wmertens
Copy link
Contributor

wmertens commented Jun 4, 2020

  • When I try to do this in nixops, the evaluation fails at
    initrdPath = "${config.system.build.initialRamdisk}/" +
    . A few lines ahead there's a check for isContainer
  • How about adding a little explanation about the option, like In order to use this, all the modules necessary to mount the root disk need to be compiled into the kernel

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants