| 20 Mar 2025 |
 ElvishJerricco | I had assumed that this is covered by boot.kernel.sysctl. But I guess sysfs and sysctl do slightly different things? | 06:39:40 |
 @msanft:matrix.org | I thought that it's just a different interface to the same thing. | 08:09:04 |
| ElvishJerricco | Moritz Sanft: That's kinda what I thought but... I think that might be wrong? Seems like sysctl is for /proc/sys, not /sys, and apparently those are meaningfully different? | 08:32:58 |
| @msanft:matrix.org | Just learned that too. But it kind of makes sense. You don't find e.g. device info in /proc/sys, while you do in /sys | 08:52:08 |
 Ramses 🇵🇸 | Yeah, a lot of drivers expose things under /sys/class where you can write to files to configure stuff | 09:25:15 |
| Ramses 🇵🇸 | A lot of those things are only present when the device has been loaded though, so I feel that we'd need something more dynamic than a single systemd-tmpfiles invocation. I use path units myself to trigger writing to such files when they appear | 09:26:19 |
| ElvishJerricco | that sounds more like a udev thing then, doesn't it? | 09:26:41 |
| Ramses 🇵🇸 | Yeah, that would also work, I guess | 09:27:03 |
| ElvishJerricco | i.e. make udev rules that identify the devices and set the desired property | 09:27:06 |
| ElvishJerricco | though that obviously doesn't work in the example in the PR, which is about transparent_hugepage | 09:27:27 |
| Ramses 🇵🇸 | Yeah, those are exposed by the kernel and always available, I think | 09:44:18 |
 Sandro 🐧 | In reply to @elvishjerricco:matrix.org
Ok, I'm happier with this now: https://github.com/NixOS/nixpkgs/pull/375975 That sounds cool | 09:57:25 |
 Arian | This feels like the kind of thing that should be done with udev rules or device units not tmpfiles | 10:00:22 |
| Arian | Not sure | 10:02:19 |
| ElvishJerricco | the sysfs thing? That only works for sysfs nodes that actually represent devices, which is only a subset of sysfs | 10:14:27 |
| Arian | Ah | 10:18:47 |
| Arian | Then just order it later like https://man7.org/linux/man-pages/man8/systemd-sysctl.service.8.html | 10:19:42 |
| Arian | Surprised there isn't a systemd-sysfs | 10:19:50 |
| Arian | I guess best we can do is load after systemd-modules-load | 10:20:14 |
| ElvishJerricco | hm, currently tmpfiles and modules-load are unordered against each other | 10:23:51 |
 gdamjan | but even if you load a module, the sysfs knobs are not guaranteed to be available immediately right? modules initialize asynchronously | 13:29:29 |
|  @derrg:matrix.org joined the room. | 17:33:52 |
| Arian | Should the Systemd team be on nixos.org/community | 18:34:34 |
| 21 Mar 2025 |
|  mrdev023 joined the room. | 13:51:10 |
| 22 Mar 2025 |
| ElvishJerricco | I am finding some extremely broken behavior with systemd-repart running during boot when the device is already partitioned but needs modification (e.g. grow a partition). It seems that when it runs and repartitions, it causes the device units to stop and start. This causes fsck and mount units to be stopped, all the way up to initrd-fs.target, causing initrd-find-nixos-closure.service to be stopped. Then initrd-parse-etc.service starts and that starts initrd-fs.target again, but initrd-find-nixos-closure.service is still stopped, so it never happens and the system fails to boot | 09:10:18 |
| Arian | Wut | 09:12:19 |
| ElvishJerricco | now, all those units being stopped is a "job canceled", so they don't need to have already been started for this chain reaction to occur | 09:12:43 |
| ElvishJerricco | * now, all those units being stopped is a "job canceled" scenario, so they don't need to have already been started for this chain reaction to occur | 09:12:49 |
| ElvishJerricco | (some of these observations come from me being in the middle of messing with things and adding various orderings to debug things, so I might be getting the details wrong, but the core idea is I think a problem) | 09:13:41 |
| ElvishJerricco | the specific use case I was trying to debug was when / is a tmpfs and /nix is on a partition that needs to grw | 09:14:37 |
