| 16 Dec 2023 |
 matthewcroughan | Idea:
/dev/disk/by-id/usb-Samsung_PSSD_T7_S6WZNS0T500569P-0:0
I used Disko to install to this disk, but the xhci_pci kernel module wasn't available causing it to break when booting
| 17:29:17 |
| matthewcroughan | We could parse the usb part of that device id string, and know we need to include that in the boot.initrd.availableKernelModules | 17:29:56 |
| matthewcroughan | * We could parse the usb part of that device id string, and know we need to include that in the boot.initrd.availableKernelModules and include it as part of the disko module. | 17:30:08 |
| matthewcroughan | the device option of disko can do all sorts of magic like that, just by parsing the string | 17:30:23 |
| matthewcroughan | * the device option of disko can do all sorts of magic like that, just by parsing the device by-id string | 17:30:28 |
| 17 Dec 2023 |
|  Dandellion joined the room. | 23:58:12 |
| 18 Dec 2023 |
|  Julia DeMille joined the room. | 16:24:16 |
| Julia DeMille | I've encountered a rather alarming issue: when I add a subvolume (/@opt-containers, mounted at /opt/containers, with no other subvolumes involved in /opt), and then switch the system config (via deploy-rs), my server just becomes inaccessible, completely. after a reboot, and a switch to the previous generation, access is restored, but this is seriously alarming | 16:25:51 |
 raitobezarius | what was the cause of making the server inaccessible? | 16:30:29 |
| raitobezarius | can you get the journal log? | 16:30:34 |
| raitobezarius | did you enter into emergency mode or something? | 16:30:52 |
| Julia DeMille | i'll try to grab journals -- the SSH connection just dropped, and i got no route to host upon trying to connect again | 16:33:57 |
| Julia DeMille | deploy-rs didn't even finish, it was just waiting | 16:34:05 |
| Julia DeMille |
| 16:36:21 |
| Julia DeMille | * Dec 18 15:54:58 callisto mount[1721]: mount: /opt/containers: mount(2) system call failed: No such file or directory.
Dec 18 15:54:58 callisto mount[1721]: dmesg(1) may have more information after failed mount system call.
| 16:36:23 |
| Julia DeMille | * Dec 18 15:54:58 callisto mount\[1721\]: mount: /opt/containers: mount(2) system call failed: No such file or directory.
Dec 18 15:54:58 callisto mount\[1721\]: dmesg(1) may have more information after failed mount system call.
| 16:36:31 |
| Julia DeMille | * Dec 18 15:54:58 callisto mount[1721]: mount: /opt/containers: mount(2) system call failed: No such file or directory.
Dec 18 15:54:58 callisto mount[1721]: dmesg(1) may have more information after failed mount system call.
| 16:36:39 |
| matthewcroughan | So you make the machine with disko/nixos-anywhere, then you deploy to it, and the first deployment causes it to blow up in the way you explain? | 16:37:50 |
| Julia DeMille | make the machine with disko/nixos-anywhere, deploy to it a few times, eventually add that subvolume in a place it shouldn't cause any interference, and that makes it blow up | 16:38:24 |
| matthewcroughan | ah okay, well hopefully this can all be debugged with pure nix evaluation then, as the issue obviously lies in the nix code? | 16:38:46 |
| matthewcroughan | do you have any nix code, or diffs? | 16:39:08 |
| Julia DeMille | "/@opt-containers" = {
mountOptions = ["compress=zstd" "noatime"];
mountpoint = "/opt/containers";
};
these lines in disko.devices.disk.vdb.content.root.subvolumes make it blow up
| 16:39:55 |
| matthewcroughan | so it's zfs? | 16:40:20 |
| Julia DeMille | btrfs | 16:40:24 |
| matthewcroughan | Could it be a string parsing issue? @opt vs opt ? | 16:40:50 |
| Julia DeMille | here's the config: https://pastebin.com/raw/ZK7SSgZs
those lines are commented out to avoid breakage | 16:40:53 |
| matthewcroughan | https://github.com/nix-community/disko/blob/master/example/btrfs-subvolumes.nix | 16:41:41 |
| matthewcroughan | I don't see any @ in here? | 16:41:50 |
| matthewcroughan | what's the @ for | 16:41:55 |
| Julia DeMille | personal convention -- believe it also is necessary for some snapshotting tools
regardless, the original @s didn't cause any issues | 16:42:22 |
