Support for “in-place” updates?
It would be great to apply changes to the disko config on an already-installed system, when possible losslessly.
Currently, I need to add (for instance) new ZFS datasets (or change some options on them) both in the declarative config, and then imperatively (by calling zfs create manually)
I believe that would be super helpful for use cases where wiping all the storage isn't practical, like:
- personal computers, whose users presumably have data stored locally they do not wish to lose;
- database & storage servers, where copying data back from other replicas or backups may take a while and/or incur significant load;
- even on application servers that do not hold stateful data, wiping storage has significant side-effects: it would change the host SSH keys, clear caches on a web frontend, etc.
hello, yes I'm working on it. although it's a bit complicated to detect the current setup and decide which changes are destructive and which are not. The solution I'm working towards will have a _check for each type which could output if the system differs from the configured setup. We then need to find out which changes the _create step does are non-destructive and execute those.
All in all this is a feature which is coming, although I have no definite timeline on it. But I haven't decided on an interface yet. probably there will be a kind of mode selection (with modes like: non-destructive, force, force-non-critical, etc)
Great to hear you were already on it, thanks <3
@Lassulus Thank you for your amazing work! Any updates on this? Do you have any draft or anything done?
ah, I have a WIP commit which adds this for some types: https://github.com/nix-community/disko/pull/435 although I'm not very happy with the implementation. it's a lot of duplicated code and it would be nicer to include this more into the create step
I would personally like non-destructive options for disko to use. I am working on NixOS Asahi which requires installing alongside the MacOS partitions (Which are essential to keep around) and throwing a new SSD in is not an option. The installer prompts you to resize the existing MacOS partition so there is free space to install on and manage but it should never touch the existing partitions.
https://github.com/tpwrules/nixos-apple-silicon/blob/main/docs/uefi-standalone.md#partitioning-and-formatting
DANGER: Damage to the GPT partition table, first partition (iBootSystemContainer), or the last partition (RecoveryOSContainer) could result in the loss of all data and render the Mac unbootable and unrecoverable without assistance from another computer! Do not use your distro's automated partitioner or partitioning instructions!
alrighty, we now have https://github.com/nix-community/disko/pull/568 which "should" make the createScript non destructive, be careful to use the createScript and not the diskoScript (that one wipes the disks first). Also this code is not yet tested on a real setup, so take care to not lose your date! :)
I'm interested in the use case of being able to declaratively define zfs datasets, not for the first install case, but for creating new datasets long after install.
Example: A NAS or server system where you want to be able to create a new dataset to store the data from some service you enable with a nixos module.
Is this currently possible? If so are there any relevant examples?