Add existing disk configuration to disko configs

oysteikt commented

2026-01-29 05:04:33 +01:00

Owner

It would be neat if we could use disko more. We can model the existing configurations in disko configs, and use the nixos modules that comes with it to have the disko config be the source of truth for fileSystems (e.g. fstab and mount units).

Already started by adding hosts/kommode/disks.nix and removing fileSystems from hosts/kommode/hardware-configuration.nix

It would be neat if we could use disko more. We can model the existing configurations in disko configs, and use the nixos modules that comes with it to have the disko config be the source of truth for `fileSystems` (e.g. fstab and mount units). Already started by adding `hosts/kommode/disks.nix` and removing `fileSystems` from `hosts/kommode/hardware-configuration.nix`

👎 1

oysteikt added the nixos label 2026-01-29 05:04:33 +01:00

oysteikt added this to the Kanban project 2026-01-29 05:04:33 +01:00

oysteikt moved this to Low priority in Kanban on 2026-01-29 05:04:44 +01:00

felixalb added the disputed label 2026-01-29 12:28:43 +01:00

felixalb commented

2026-01-29 13:42:14 +01:00

Owner

Why? We already have a nix source of truth for fileSystems, mainly in hardware-configuration.nix on all hosts, why complicate drive setup and add traps to an existing and working declarative setup?

Disko or something similar can make sense when installing new hosts, for example if we want to automatically provision/create VMs or something similar with little to no manual input. Does this issue add any value to existing hosts, except a cool tech demo / complication?

Why? We already have a nix source of truth for fileSystems, mainly in hardware-configuration.nix on all hosts, why complicate drive setup and add traps to an existing and working declarative setup? Disko or something similar can make sense when installing new hosts, for example if we want to automatically provision/create VMs or something similar with little to no manual input. Does this issue add any value to existing hosts, except a cool tech demo / complication?

danio commented

2026-01-29 13:56:53 +01:00

Owner

It makes the filesystem and disk-layout declarative and a property of the machine rather than, just "referred to" by filesystem uuids and mountpoints. It also lets us generate nixos-installers for a machine if we ever need to set it up from scratch

oysteikt commented

2026-01-29 14:06:03 +01:00

Author

Owner

fileSystems work, by all means. But adding config to disko would give us things like inherent disk config documentation (maybe even with comments and reasoning from whoever set it up), avoiding stuff like mounting /dev/sda just because you happened to use that with the mount command during install (disko tends to use by-partlabel by default). The inherent documentation thing also works for extended information in nix-topology and similar.

It's not just cool tech demo, having extended information about how the disks are configured accessible from within the configuration is valuable for several other purposes.

`fileSystems` work, by all means. But adding config to disko would give us things like inherent disk config documentation (maybe even with comments and reasoning from whoever set it up), avoiding stuff like mounting `/dev/sda` just because you happened to use that with the `mount` command during install (disko tends to use `by-partlabel` by default). The inherent documentation thing also works for extended information in nix-topology and similar. It's not just cool tech demo, having extended information about how the disks are configured accessible from within the configuration is valuable for several other purposes.

felixalb commented

2026-01-29 14:48:15 +01:00

Owner

Okay, I agree that using the hardware-config from mount /dev/sda /mnt; nixos-generate-config blindly is bad, but that is an easy fix, either when installing or by updating the config later (We should do that on bekkalokk 😅, everything else looks to be /by-uuid/). Explanations/reasoning, disk layouts and special properties/settings are as usual already documented in the wiki for most hosts. That said, we haven't finished the discussion on if the wiki and/or nix-topology should be canonical/main docs, or if we will somehow be able to keep both maintained.

Sure, for automatic (re-)installation of hosts, it can be practical, but I still think this will produce more accidents and confusion than benefits. Especially for new people, everyone probably already knows either how to use parted or check the nixos manual, this looks like an unnecessary complication.

Especially given the current state of our server environment, where reinstallations are rare, I am still opposed to diskofying current disk configurations in this issues. If/when we get some more automatic deployment/provisioning on PVE/OpenStack, disko can be a necessary tool on those type of hosts!

Okay, I agree that using the hardware-config from `mount /dev/sda /mnt; nixos-generate-config` blindly is bad, but that is an easy fix, either when installing or by updating the config later (We should do that on bekkalokk 😅, everything else looks to be /by-uuid/). Explanations/reasoning, disk layouts and special properties/settings are as usual already documented in the wiki for most hosts. That said, we haven't finished the discussion on if the wiki and/or nix-topology should be canonical/main docs, or if we will somehow be able to keep both maintained. Sure, for automatic (re-)installation of hosts, it can be practical, but I still think this will produce more accidents and confusion than benefits. Especially for new people, everyone probably already knows either how to use `parted` or check the nixos manual, this looks like an unnecessary complication. Especially given the current state of our server environment, where reinstallations are rare, I am still opposed to diskofying current disk configurations in this issues. If/when we get some more automatic deployment/provisioning on PVE/OpenStack, disko can be a necessary tool on those type of hosts!

Add existing disk configuration to disko configs #320