| 2 Mar 2025 |
| Heitor Augusto joined the room. | 22:57:36 |
| 3 Mar 2025 |
| myxos joined the room. | 04:12:45 |
myxos | I have a running system with several partitions, one of which has a ZFS filesystem. The ZFS partition is configured with a single pool, which houses several datasets. If I want to add another dataset, will this affect any of the others? | 04:15:29 |
lassulus | well you would have to to run the format script again for there to be any effect, that doesn't happen automatically | 04:21:49 |
lassulus | you can create the format script and look at it before you run it again | 04:22:00 |
lassulus | but in theory it should only create the new dataset | 04:22:09 |
lassulus | but that is relatively new and untested behavior :) | 04:22:25 |
lassulus | be sure not to run the diskoScript, as this will wipe the drives beforehand | 04:22:43 |
Raj | I'd like to have this external HDD sometimes plugged in and other times removed, but automatically have LUKS unlocked at boot whenever it's connected. If I remove the disk, the boot process fails at stage 1. Is there a setting I can adjust to fix this apart from mountOptions = ["nofail"]? I'm not too familiar with the initrdUnlock argument: I presume it's what asks for my LUKS password after booting?
backup_1 = {
device = hdd_1;
content = {
type = "gpt";
partitions = {
backup_1 = {
device = "${hdd_1}-part1";
priority = 0;
end = "-0";
content = {
type = "luks";
name = "backup_1";
initrdUnlock = true;
extraFormatArgs = ["--pbkdf argon2id"];
content = {
type = "btrfs";
extraArgs = ["-f"];
mountpoint = "/backup/drive_1";
mountOptions = ["compress=zstd" "noatime" "nofail"];
};
};
};
};
};
};
| 04:30:48 |
myxos | @lassulus You mean don't run the script that was generated by --dry-run? | 04:31:44 |
lassulus | myxos: that one probably has the disk-deactivate bit at the start, so you could skip that part, and the part of mounting at the end, or run with --mode format | 04:33:49 |
myxos | Gotcha, I'll try that out, thanks! | 04:44:21 |
lassulus | Raj: hmm, the initrdUnlock adds this to the boot.initrd nixos config, so booting will fail if the device is not available. I don't see an easy way to disable that in nixos, alternative would be to not have the initrdUnlock and unlock it after booting | 04:48:05 |
Raj | Got it, thank you! | 04:49:04 |
myxos | @lassulus just to update, adding the dataset via Disko configuration caused my system to crash, and I had to roll back to a previous configuration. I needed to first manually create the dataset (zfs create ...), after which I could update the Nix config (for posterity) without error. | 17:13:34 |
lassulus | ah did you run the create script manually before switching? | 17:14:47 |
myxos | Yep | 17:16:55 |
lassulus | and it still crashed? I'm a bit confused why it worked manually afterwards | 17:17:35 |
myxos | Oh, I did not manually run the create script manually before switching at first. That's when it crashed. | 17:18:22 |
myxos | I was initially hoping the changes to the disko config would be smart enough to just create the new dataset (a bit risky, I know, but no harm done) | 17:19:09 |
lassulus | ah, yeah that was the missing step I guess, but looking at my history I just said looking at it :D | 17:19:13 |
lassulus | I meant looking at it and running it if it looks fine :) | 17:19:31 |
lassulus | that step doesn't happen automatically with disko (yet?) | 17:19:54 |
lassulus | because it's not widely tested and I don't want people to lose data | 17:20:13 |
myxos | I didn't end up running the whole generated disko script, just the zfs create command | 17:20:12 |
lassulus | ah ok, so we will never know if it would have broken something :) | 17:20:30 |
myxos | That's certainly understandable | 17:20:34 |
myxos | Thanks for your help, and for your contributions to this tool, it's great! | 17:22:20 |
myxos | Maybe on my next throwaway system I'll test running the script to see if it borks anything 🙂 | 17:23:40 |
| @cent:neuland.enterprises joined the room. | 18:20:36 |