| 22 Mar 2025 |
 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 |
| ElvishJerricco | * the specific use case I was trying to debug was when / is a tmpfs and /nix is on a partition that needs to grow | 09:14:39 |
| ElvishJerricco | but I think it would be a problem in a lot more generic scenarios than that | 09:14:56 |
 Arian | Can you make a non-nix-specific reproducer? | 09:15:11 |
| ElvishJerricco | uh | 09:15:28 |
| ElvishJerricco | I don't know enough about other distros to make another distro do this :P | 09:15:43 |
| Arian | I don't understand how you have mounts before repart runs | 09:16:23 |
| Arian | You cant resize a mounted partition no? | 09:16:31 |
| ElvishJerricco | well, a) yes you can, and b) I don't have mounts anyway. The mount jobs are cancelled before they're started | 09:16:51 |
| Arian | Repart should be running before /sysroot is mounted | 09:16:57 |
| ElvishJerricco | the device appears, satisfying some dependencies, and then disappears, which causes job cancellations because of BindsTo=dev-foo.device | 09:17:42 |
| ElvishJerricco | and then reappears, but then it's too late and damage is done | 09:18:07 |
| Arian | Could it be a kernel bug? | 09:18:20 |
| Arian | Why is the kernel sending uevents on resize | 09:18:30 |
