| 7 Oct 2024 |
 ˈt͡sɛːzaɐ̯ | In reply to @scrumplex:duckhub.io
I think it could be a great option here. Basically you could configure everything once and then just set different hostnames for different machines in separate configurations. You could then generate small disk images that you can then dd onto the drives while using the option boot.growPartition to expand the rootfs to the remaining size. I wonder, is there a more elegant way of doing this? If you build an image per system, you'll be compressing the same content a lot of times. I'd rather have one image, and an activation script that checks what mac addresses it can find on the system and then pics the hostname / activation script for the correct system. But that sounds brittle to set up. Are there any examples of doing this in a sane way? | 05:47:17 |
| ˈt͡sɛːzaɐ̯ | In reply to @theelevated:matrix.org
does nix also shell bin commands? if I need want to have a elevated listener for a root ssh session and in the global file. Your question is a little bit gibberish. Are you using some translation software? In any case: Yes, you can run sshd and add something to users.users.root.openssh.authorizedKeys.keys on all hosts, so you'll be able to ssh in as root and e.g. execute nixos-rebuild. | 05:48:39 |
|  @thunder:kotiboksi.xyz joined the room. | 08:28:15 |
|  mabh joined the room. | 10:19:59 |
 steveej | does anyone here happen to have a disko config for EFI boot with raid0 over two drives? | 11:34:23 |
| steveej | interesting, hetzner puts the EFI partition on a mdadm raid1 with their default debian installations. it seems they're doing something non-standard which is using "EFI System" as a partition type for a mdadm member:
/dev/nvme0n1p1 4096 528383 524288 256M EFI System
i'll see if disko supports creating such a layout
| 12:07:49 |
| steveej | snippet from lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 1.7T 0 disk
├─nvme0n1p1 259:2 0 256M 0 part
│ └─md0 9:0 0 255.9M 0 raid1 /boot/efi
| 12:08:23 |
 @adam:robins.wtf | Raid zero for efi? I hope you mean one, because what in the world…. | 13:23:48 |
| @adam:robins.wtf | Anyway there’s `boot.loader.grub.mirroredBoots` . I haven’t used it but would investigate if I was trying to have boot redundancy | 13:25:22 |
|  Sam Lehman changed their profile picture. | 14:24:40 |
 Scrumplex | I noticed today that one file in my Nix store was off. It is a YAML config file for frigate. I mounted the config file into an oci-container (using Docker, not Podman) using the following snippet:
virtualisation.oci-containers.containers."frigate".volumes = [ "${configFile}:/config/config.yml" ];
When comparing the contents of this store file with the store file I built locally it has version: 0.14 at the end of it. I assume this was added by Frigate.
I created a root shell in this container, installed a text editor but was unable to edit the file in anyway, as I would expect, so I am wondering if I am missing something here
| 16:54:48 |
| Scrumplex | I ran these inside of the container:
# ls -la /config/config.yml
-r--r--r-- 2 root root 2250 Sep 30 20:48 /config/config.yml
# chmod 644 /config/config.yml
chmod: changing permissions of '/config/config.yml': Read-only file system
| 16:56:05 |
| 8 Oct 2024 |
|  MonkCanatella joined the room. | 00:24:02 |
|  Lloyd Alexandre joined the room. | 00:57:45 |
|  turmite joined the room. | 17:17:56 |
| 10 Oct 2024 |
|  p4cmanus3r joined the room. | 13:21:47 |
|  Karma joined the room. | 14:36:52 |
|  @lars:familie-vogdt.de joined the room. | 16:55:29 |
| 11 Oct 2024 |
| steveej | In reply to @adam:robins.wtf
Raid zero for efi? I hope you mean one, because what in the world…. you read that write. i think raid0 makes sense on ephemeral build machines. for /boot i ended up using an mdadm raid1 with metadata 1.0 and a vfat -F 16 partition on it. | 07:42:16 |
| steveej | In reply to @adam:robins.wtf
Raid zero for efi? I hope you mean one, because what in the world…. * you read that right. i think raid0 makes sense on ephemeral build machines. for /boot i ended up using an mdadm raid1 with metadata 1.0 and a vfat -F 16 partition on it. | 07:42:28 |
| steveej | In reply to @scrumplex:duckhub.io
I ran these inside of the container:
# ls -la /config/config.yml
-r--r--r-- 2 root root 2250 Sep 30 20:48 /config/config.yml
# chmod 644 /config/config.yml
chmod: changing permissions of '/config/config.yml': Read-only file system
this seems expected if the mount source ${configFile} is a storepath | 07:43:36 |
| Scrumplex | In reply to @steveej0:matrix.org
this seems expected if the mount source ${configFile} is a storepath Yes, but still I sometimes saw that the store path's contents have seemingly changed and running nix store verify --all shows that the content hash doesn't match anymore | 07:46:11 |
| steveej | and it happens only for the single store path at ${configFile}? | 07:48:25 |
| Scrumplex | yup | 07:58:54 |
| steveej | that's quite strange. is there a syntax for the volume to make the mount read-only? maybe the container runtime does indeed do a mount namespace thing to access the nix store in rw mode. i'm wildly guessing here | 08:09:47 |
| Scrumplex | I have recently changed it to be read only (with Docker/Podman you just add :ro to the mapping, i.e. ${configFile}:/config/config.yml -> ${configFile}:/config/config.yml:ro)
This might have fixed the issue
| 08:12:02 |
|  Tdr joined the room. | 18:56:27 |
|  Artturin joined the room. | 19:24:32 |
| 12 Oct 2024 |
|  Federico Damián Schonborn changed their profile picture. | 00:30:17 |
|  @lachlanmalec:matrix.org joined the room. | 12:26:29 |
