| 22 Oct 2022 |
 @elvishjerricco:matrix.org | https://github.com/systemd/systemd/releases/tag/v252-rc2
* Various units are now correctly ordered against
initrd-switch-root.target where previously a conflict without
ordering was configured. A stop job for those units would be queued,
but without the ordering it could be executed only after
initrd-switch-root.service, leading to units not being restarted in
the host system as expected.
I wish they linked the PR that did this. I'd like to see what exactly changed
| 17:41:14 |
 @janne.hess:helsinki-systems.de | ElvishJerricco: ma27 told me about this today: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/stage-1.nix#L153 | 17:43:47 |
| @janne.hess:helsinki-systems.de | do we need to adapt that? | 17:43:53 |
| @elvishjerricco:matrix.org | I don't think so | 17:45:14 |
| @elvishjerricco:matrix.org | we don't nuke the rpath | 17:45:17 |
| @elvishjerricco:matrix.org | and glibc is in its original path in the initrd | 17:45:29 |
| @janne.hess:helsinki-systems.de | ah that might work around that, yeah | 17:45:52 |
| @elvishjerricco:matrix.org | as long as something is causing libpthread to be pulled in | 17:46:06 |
| @janne.hess:helsinki-systems.de | feels a bit unreliable :D | 17:46:25 |
| @elvishjerricco:matrix.org | yea maybe we can add that to storePaths as an assurance | 17:46:36 |
| @elvishjerricco:matrix.org | In reply to @elvishjerricco:matrix.org
https://github.com/systemd/systemd/releases/tag/v252-rc2
* Various units are now correctly ordered against
initrd-switch-root.target where previously a conflict without
ordering was configured. A stop job for those units would be queued,
but without the ordering it could be executed only after
initrd-switch-root.service, leading to units not being restarted in
the host system as expected.
I wish they linked the PR that did this. I'd like to see what exactly changed
Ah, think I found it: https://github.com/systemd/systemd/pull/24670 | 17:48:12 |
| @janne.hess:helsinki-systems.de | seems related but is unmerged: https://github.com/systemd/systemd/pull/24680 | 17:51:22 |
| @elvishjerricco:matrix.org | I really wish systemd PRs contained some kind of explanation for wtf it's doing. They seem to almost always have zero context | 17:52:02 |
| @janne.hess:helsinki-systems.de | well I see the same thing in nixpkgs more often than I would hope ;) | 17:53:20 |
| @elvishjerricco:matrix.org | https://github.com/systemd/systemd/pull/24670/files#r972921587
This is... useful, if strange, information. | 17:54:30 |
| @elvishjerricco:matrix.org | Apparently when one thing would be stopped at the same time as the other would be started, the only way to influence the ordering of those things is to have any ordering between them, which always means the stop happens first | 17:55:40 |
| @elvishjerricco:matrix.org | Looks like they missed at least a couple units; like systemd-networkd.service. But then again I don't think anyone actually expects people to use networkd in initrd yet :P | 17:59:00 |
| @elvishjerricco:matrix.org |
At shutdown, systemd will now log about processes blocking unmounting of file systems.
Oh sweet. I could actually really use this
| 18:03:11 |
 @andreas.schraegle:helsinki-systems.de | In reply to @elvishjerricco:matrix.org
At shutdown, systemd will now log about processes blocking unmounting of file systems.
Oh sweet. I could actually really use this
finally, after all these years | 22:12:04 |
