| 17 Apr 2025 |
 palo | * I created a zraid2 setup on top of luks a while ago (with this disko config : https://git.ingolf-wagner.de/palo/nixos-config/src/branch/main/machines/chungus/hardware-configuration/disko-config.nix) now one of my disks broke down, and I just plugged a new disk in the computer.
Is there an easy way to format them the same way I defined in that disko-config.nix ? I mean I have to define the new disk in there anyway, but is there an easy command to only format this device and all? I'm asking because I think disko does a lot of stuff like labeling and proper flagging and such. | 20:24:58 |
| palo | Hmm according to documentation, and from what I see in the script, disko --dry-run -m format ... it will only format drives which don't have the proper label set | 20:48:13 |
| palo | * Hmm according to documentation, it will only format drives which don't have the proper label set | 20:49:56 |
| palo | I just rand --dry-run -m format, than copied and edited the file to just run the part of the new drive. | 21:04:56 |
| palo | * I just rand --dry-run -m format, than copied and edited the file to just run the part of the new drive. Worked fine so far. | 21:05:07 |
 lassulus | I also added some safeguard into the format scripts, that it shouldn't run on already formatted drives | 22:10:54 |
| lassulus | but removing that code is also fine | 22:10:59 |
| 18 Apr 2025 |
 Mic92 | @reflux1291:catgirl.cloud: nixos-install is idempotent. You can use it to repair stuff | 05:14:53 |
|  jlesquembre joined the room. | 13:29:48 |
| 19 Apr 2025 |
|  jopejoe1 (4094@39c3) changed their display name from jopejoe1 to jopejoe1 (4094@eh22). | 13:01:24 |
|  ·☽•Nameless☆•777 · ± changed their profile picture. | 14:31:10 |
 parismagpie | Hey | 19:05:27 |
| 20 Apr 2025 |
| parismagpie | so I'm using disko to declare partitioning for two raw disk images (/ in ext4, /home in zfs). Booting the system using qemu to test whether everything works or not, zfs complain about the zpool being mounted on another system ( "pool was previously in use from another system.", "The pool can be imported, use 'zpool import -f' to import the pool." ) | 07:35:01 |
| parismagpie | I'm thinking that it's might be related to the use of diskoImagesScript to create the two raw images. Is there any disko option to avoid this problem ? | 07:35:55 |
| parismagpie | (I can boot.zfs.forceImportAll = true but that seems a bit overkill) | 07:47:57 |
| 21 Apr 2025 |
|  @creepinson:matrix.org joined the room. | 04:53:02 |
| @creepinson:matrix.org | Redacted or Malformed Event | 04:53:41 |
|  NixOS Moderation Bot banned @creepinson:matrix.org (spam). | 04:53:43 |
| 22 Apr 2025 |
| NixOS Moderation Bot unbanned @creepinson:matrix.org. | 02:28:45 |
| @creepinson:matrix.org joined the room. | 02:41:04 |
|  senorsmile joined the room. | 02:51:48 |
|  jaredmontoya joined the room. | 09:32:35 |
 phaer | Hm... between two vms, that shouldn't be an issue if networking.hostId is the same for both.
For diskoImagesScript i believe the idea would be that it runs zfs export in the end which also should cause it to import cleanly on another system iiuc.
| 10:07:47 |
| 23 Apr 2025 |
 f44 | Redacted or Malformed Event | 18:42:13 |
| 24 Apr 2025 |
 nicoty | The PR got merged 🎉 (thanks for your UUID contribution, btw), but I couldn't quite get subvolumes to mount at boot time.
I saw that your PR included code for a custom systemd unit. I haven't tried using that and haven't much experience with writing systemd units, so maybe you could try implementing something with it to get boot-time subvolume mounts to work, if you're interested? | 23:32:42 |
| 25 Apr 2025 |
|  thirdofmay18081814goya joined the room. | 16:10:02 |
|  Nils (Skarmux) joined the room. | 18:00:35 |
| 26 Apr 2025 |
| nicoty | @projectinitiative:matrix.org: Ignore my last message. Apparently the PR did allow subvolumes to be mounted at boot time and I just didn't implement the test properly to allow the test to unlock the subvolumes. This new PR fixes that though. So I think this means that we can probably now use bcachefs for impermanence, or we're at least one step closer to it 😀. | 00:17:04 |
| nicoty | * @projectinitiative:matrix.org: Ignore my last message. Apparently the PR did allow subvolumes to be mounted at boot time and I just didn't implement the test properly to allow it to unlock the subvolumes. [This new PR fixes that though](https://github.com/nix-community/disko/pull/1021). So I think this means that we can probably now use bcachefs for impermanence, or we're at least one step closer to it 😀. | 00:19:53 |
|  @lys:lys.ee left the room. | 01:46:44 |
