nixos/stratis: initrd support for stratis root volumes #229767
Conversation
github-actions
bot
added
6.topic: nixos
ofborg
bot
added
10.rebuild-darwin: 0
|
Still I prefer using the generator, that would give us the opportunity to use stratis in the initrd without being restricted to the rootfs. |
|
@NickCao , I'm afraid I don't understand your comment regarding the generator. All it does is read the |
|
Ah I confuse the fstab generator with the root setup ones, now I see that your implementation is reasonable. A bit busy to review this these days, would you mind adding a test for this first? A side note: why split the initrd related files to a separate output? These are merely text files and should be pretty small. |
|
There is now an installer test for this. Since Stratis can be used without encryption, Plymouth is actually not strictly required, so I've decided to remove the Plymouth requirement. And since the |
|
@mberndt123 I'm not a fan of this
I would prefer the second, but I don't know if stratis will allow you to choose the UUID. That said, this does raise an interesting point. Shouldn't the |
it is now possible to supply a stratis pool uuid for every filesystem, and if that filesystem is required for boot, the relevant pool will be started in the initramfs.
ofborg
bot
added
10.rebuild-darwin: 1-10
10.rebuild-darwin: 1
and removed
10.rebuild-darwin: 0
|
I've now changed this so that the stratis pool UUID can be configured for every individual file system, and if any of them are required for booting, then initramfs support will be enabled automatically. |
| unitConfig.DefaultDependencies = "no"; | ||
| conflicts = [ "shutdown.target" "initrd-switch-root.target" ]; | ||
| onFailure = [ "emergency.target" ]; | ||
| unitConfig.OnFailureJobMode = "isolate"; |
There was a problem hiding this comment.
Why isolate? Seems like the upstream units all use replace-irreversibly.
There was a problem hiding this comment.
No particular reason, I just modeled it after this:
https://github.com/stratis-storage/stratisd/blob/7d0125be75a68d25329a6e72db4b581fadee536b/src/bin/generators/stratis_setup_generator.rs#L44
I can change it to replace-irreversibly if you want.
| stratis.poolUuid = lib.mkOption { | ||
| type = types.uniq (types.nullOr types.str); | ||
| description = lib.mdDoc '' | ||
| UUID of the stratis pool that the fs is located in | ||
| ''; | ||
| example = "04c68063-90a5-4235-b9dd-6180098a20d9"; | ||
| default = null; | ||
| }; | ||
|
|
There was a problem hiding this comment.
Not sure how I feel about extending the fileSystems options for this. Can't multiple FSes be in the same pool?
There was a problem hiding this comment.
Yes, sure. But I don't see how that creates a problem. Due to how attrsets.mapAttrs' works, this is automatically deduplicated, so only one stage 1 service unit will be generated per pool.
I could put this information somewhere else, I just found it convenient this way.
There was a problem hiding this comment.
On second thought, I think this makes the most sense. Associating it with the FS gives the most useful information.
|
Thanks! |
Janik-Haag
added
the
12. first-time contribution
Hey,
I added initrd support for booting from a Stratis volume. It's mostly based on the way that it's done in Stratis' dracut module, except that I've decided not to use the stratis_setup_generator and instead just added a systemd service configuration with the required STRATIS_ROOTFS_UUID env variable.
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)