rfcs
rfcs copied to clipboard
NixOS
[RFC 0139] Declarative filesystem layouts
WIP, feel free to get involved.
@Lassulus @Mic92 As the biggest contributors to Disko, your ideas & contributions would be very welcome. I feel like declarative filesystem layouts could massively simplify one of the biggest, riskiest, and most long-standing complexities of installing any Linux distro.
I will try to chime in when I find some time, but if you want to do a jitsi session or something like that I could talk a bit about plans to integrate disko into nixpkgs. maybe one can sketch out the RFC after that :)
The idea of this is to use the Nix language to describe the hard disk layout?
The idea of this is to use the Nix language to describe the hard disk layout?
Yes, ideally in such a way as to make sure the info can be used to both apply the structure (using any of the standard tools, like fdisk) and to declare them at runtime in for example /etc/fstab.
One thing to consider in your write-up: what happens when the end-user changes the described layout on a running system?
In the past, non-commital lightweight discussions about that topic always ended-up at that dead-end, where declaratively describing this inherently stateful thing can't be handled through the lifecycle of NixOS systems, except at the very start before the first generation is booted, otherwise known as "installation".
Again, something to consider, please continue :).
Well we can't really change the filesystem of the system we are running on without losing a bunch of files. But maybe we can add a flag (similiar to how we handle the bootloader) to try to force the application of the filesystem changes. We could then kexec into a live system. rescue some files we care about, reformat the disks and then bootup into the new system. with a lot of files lost though
A recent MacOS update forced filesystem changes on all devices (including removing /nix). This was done by adding a "Relocated Items" folder on the user's desktop and placing all the files there that would otherwise be deleted/lost. I remember thinking that this was a pretty neat solution. A similar idea is the lost+found directories used in some Linux filesystems. Maybe we can do something similar?
Maybe this could work:
- Copy the files that would be deleted/lost to a path in the Nix Store.
- Have a
/nix/lost+founddirectory. - Add a garbage collection root to the Nix Store path from step 1 above under
/nix/lost+found.
EDIT: Actually, it's probably a bad idea to use the lost+found name in case /nix is using its own filesystem that adds that directory itself. But there are plenty of other names that can be used.
Could Ignition serve as an example? https://coreos.github.io/ignition/examples/
Note that we recently merged repart support which allows you to declaratively create your partitions and filesystems. Adding support for it to nixes-install is definitely something I'd like
https://github.com/NixOS/nixpkgs/pull/232533
Note that we recently merged
repartsupport which allows you to declaratively create your partitions and filesystems. Adding support for it tonixes-installis definitely something I'd like
Excellent!
@nikstur Thank you! Especially like the test. Is this going to be in 23.05? Is there a PR with documentation on the way? And is it possible to use this to bootstrap a NixOS install?
@Nyabinary There's been a lot of excellent feedback, and it sounds like people would be interested in the feature, but I don't feel qualified to lead this to completion by myself. As far as I'm concerned, there are a few possible next steps. Off the top of my head and in no particular order:
- Evaluate systemd-repart as a partial or complete solution to this. I'm not familiar with it, I haven't seen any examples of it, and I don't know whether it's appropriate for this use case.
- Evaluate the Ignition syntax as an alternative to Disko. I'm not familiar with either, but it looks like they could both do the job. On the other hand, we need to be wary of analysis paralysis and bikeshedding.
- Come up with common use cases (like initial setup when booting from USB/network, how to change an existing system, etc) and solutions. For example, maybe
nixos-rebuildneeds a new flag or subcommand to apply the configuration, or to check whether the configuration needs applying. - Have a big get-together to work out what people are most interested in/worried by.
- Work out what would be a minimal first step towards this and implement that rather than designing a bunch up front.
Any status on this?
I feel like this plus impermanence would be great, but impermanence would def be out of scope for this RFC.
I can help/be the new author of this for now if nobody else steps up, I still think this is a great idea.
Disko in the meantime also added support for updating some aspects of the disk configuration in an existing system. Systemd-repart supports some stuff as well but is still more limited.
I can help/be the new author of this for now if nobody else steps up, I still think this is a great idea.
If you're still up for it and have the bandwidth to progress the RFC, please feel free to undraft, open for nominations and get things moving. I'm sure a lot of people, like myself, would like to see this materialise.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/rfcsc-meeting-2024-09-02/51514/1
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/rfcsc-meeting-2024-09-16/52224/1
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/rfcsc-meeting-2024-09-30/53690/1