NixOS System Operations | 583 Members | |
| About system administration for running NixOS systems in production. Declaratively manage your operations. | Room recommendations: #networking:nixos.org | 160 Servers |
| Sender | Message | Time |
|---|---|---|
| 7 Oct 2024 | ||
| 00:06:01 | ||
In reply to @scrumplex:duckhub.ioI 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 | |
In reply to @theelevated:matrix.orgYour 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 | |
| 08:28:15 | ||
| 10:19:59 | ||
| does anyone here happen to have a disko config for EFI boot with raid0 over two drives? | 11:34:23 | |
| 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:
i'll see if disko supports creating such a layout | 12:07:49 | |
| snippet from
| 12:08:23 | |
| Raid zero for efi? I hope you mean one, because what in the world…. | 13:23:48 | |
| 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 | |
| 14:24:40 | ||
| 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:
When comparing the contents of this store file with the store file I built locally it has 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 | |
| I ran these inside of the container:
| 16:56:05 | |
| 8 Oct 2024 | ||
| 00:24:02 | ||
| 00:57:45 | ||
| 17:17:56 | ||
| 10 Oct 2024 | ||
| 13:21:47 | ||
| 14:36:52 | ||
| 16:55:29 | ||
| 11 Oct 2024 | ||
In reply to @adam:robins.wtfyou 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 | |
In reply to @adam:robins.wtf* 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 | |
In reply to @scrumplex:duckhub.iothis seems expected if the mount source ${configFile} is a storepath | 07:43:36 | |
In reply to @steveej0:matrix.orgYes, 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 | |
and it happens only for the single store path at ${configFile}? | 07:48:25 | |
| yup | 07:58:54 | |
| 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 | |
| I have recently changed it to be read only (with Docker/Podman you just add This might have fixed the issue | 08:12:02 | |
| 18:56:27 | ||
| 19:24:32 | ||
| 12 Oct 2024 | ||
| 00:30:17 | ||