| 19 Jan 2025 |
 jade_ | * yeah i think that nix store ls might plausibly case hack its output lmao | 03:46:40 |
 @elvishjerricco:matrix.org | ... what on earth is "case hack"? | 03:57:58 |
| jade_ | nars that have case-conflicting file names will have them written to disk as foo~nix~case~hack~1 and fOO~nix~case~hack~2 | 04:05:12 |
| jade_ | which deals with not corrupting nars that get expanded on macOS in the process of being used for linux or such | 04:06:26 |
| @elvishjerricco:matrix.org | huh. That's... interesting | 04:08:48 |
 uep | i always end up reading that option as "use-case hack" | 04:59:55 |
|  @srestegosaurio:tchncs.de joined the room. | 05:54:39 |
|  Jeff joined the room. | 06:01:07 |
|  Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) joined the room. | 06:34:18 |
 Arian | In reply to @jade_:matrix.org
wait a minute, another bug: case hack is entirely global (lol lmao), so you cannot have different stores with different case hack settings if you are trying to fix this
this has somewhat horrifying implications for NAR handling on CppNix on macOS Yeh ran into this because I wanted to use overlay stores but nooe | 06:55:51 |
| jade_ | it really needs to be per store both because it's the only correct way to implement it for auto detection and also because of allowing multiple stores | 06:57:53 |
|  @rgrunbla:matrix.org left the room. | 09:36:51 |
 networkException | hi, it looks like our systemd-confinement + RuntimeDirectoryMode=0700 + RuntimeDirectoryPreserve=true fails on v257 with CHDIR or EXEC, very likely because nobody:nogroup intended for id mapped mounts is incompatible with some other option confinements sets. | 18:31:14 |
| networkException | ...looks like its RootDirectory | 18:43:54 |
| networkException | * hi, it looks like our systemd-confinement + RuntimeDirectoryMode=0700 + RuntimeDirectoryPreserve=true + DynamicUser=true fails on v257 with CHDIR or EXEC, very likely because nobody:nogroup intended for id mapped mounts is incompatible with some other option confinements sets. | 18:50:43 |
|  Tobias Widmann joined the room. | 23:24:35 |
| 20 Jan 2025 |
| @elvishjerricco:matrix.org | phaer: I think I've figured it out. We bind mount /run for initrd-nixos-activation but we don't do so recursively, so /run/credentials/ isn't mounted. But then when we switch-root, we still have the /sysroot/run bind mount, so systemd doesn't move the stage 1 /run mounts over and we lose /run/credentials/@system, which is supposed to be provided by initrd when systemd is in initrd | 00:03:41 |
| @elvishjerricco:matrix.org | need to do more testing to confirm and fix it, but now is D&D time :P | 00:03:53 |
| @elvishjerricco:matrix.org | * phaer: I think I've figured it out. We bind mount /run for initrd-nixos-activation but we don't do so recursively, so /run/credentials/@system isn't mounted. But then when we switch-root, we still have the /sysroot/run bind mount, so systemd doesn't move the stage 1 /run mounts over and we lose /run/credentials/@system, which is supposed to be provided by initrd when systemd is in initrd | 02:02:57 |
| @elvishjerricco:matrix.org | Incidentally, that means this would be fixed by something I've been trying to do for a while. I really don't like the sysroot-run.mount unit that we toss into the initrd; I'd much rather use RootDirectory= and BindPaths= on the unit that actually needs it. But for whatever reason, the things I've tried to make that work have failed | 02:10:03 |
| @elvishjerricco:matrix.org | * Incidentally, that means this would be fixed by something I've been trying to do for a while. I really don't like the sysroot-run.mount unit that we toss into the initrd; I'd much rather use RootDirectory= and BindPaths= to do activation. But for whatever reason, the things I've tried to make that work have failed | 02:11:37 |
| @elvishjerricco:matrix.org | Part of it is abandoning boot.specialFileSystems. AFAICT, our special file systems basically just worse than systemd's versions, which they call "API file systems". The only thing we have that they don't is this ptmxmode=0666 option. Other than that we just have less of them and worse handling. Does anyone know what that ptmxmode thing is for? | 02:45:55 |
| @elvishjerricco:matrix.org | I mean, according to the commit it's from, it's for stuff like tmux, but does anyone know if that's even true? | 02:46:44 |
 emily |
2017
| 02:53:44 |
| emily | i would assume it is lies by default | 02:53:46 |
| emily | https://github.com/NixOS/nixpkgs/pull/28490 "Currently, when creating a container, the pts filesystem is mounted without the right permission. As a result, tmux fails to create a new session. According to the kernel doc, it should be mounted with mode 0666." | 02:54:00 |
| emily | seems easy to test | 02:54:02 |
| @elvishjerricco:matrix.org | Lol I just noticed the special file systems code says:
Sync mount options with systemd's src/core/mount-setup.c: mount_table.
which uh, it clear has not done
| 02:54:03 |
| @elvishjerricco:matrix.org | I think I will bother with that only after I've actually verified I can do what I want with this change in the first place :P | 02:54:38 |
| @elvishjerricco:matrix.org | ok so for some reason, letting systemd do all the handling of special file systems leads to.... networking not working? | 02:57:50 |
