| 20 Oct 2022 |
 colemickens | I think that's why I was confused, yes. I was getting the warning for all of my hosts, when I only opt into intird networking on a couple. | 07:45:32 |
 @elvishjerricco:matrix.org | oh wait wut | 07:46:29 |
| @elvishjerricco:matrix.org | the warning should definitely not show up if you don't have networking enabled in initrd, even in the current iteration | 07:47:04 |
| * colemickens better just use nix eval to confirm | 07:47:34 |
| @elvishjerricco:matrix.org | oh i may have goofed and made the warning show up when initrd networking is disabled... | 07:48:36 |
| @elvishjerricco:matrix.org | yea I did the goof | 07:50:03 |
| @elvishjerricco:matrix.org | just need an && <stuff> in the mkIf for the warning and assertion | 07:50:24 |
| colemickens | I'll repull the pr in a bit. Thanks! | 07:50:58 |
| @elvishjerricco:matrix.org | Ah, actually the current commit is wrong. The scripted initrd doesn't try to configure any interfaces if none are configured and networking.useDHCP = false;, whereas the commit currently defaults to the equivalent of networking.useDHCP = true; when there are no configured interfaces. | 08:03:45 |
| @elvishjerricco:matrix.org | And the warning needs to go anyway, because this can be configured on the cmdline | 08:03:59 |
| @elvishjerricco:matrix.org | alright there we go. The auto configuration is only done if boot.initrd.network.enable, rather than boot.initrd.systemd.network.enable, meaning the latter gives you full control. And the warning about no networks being configured is gone, because scripted initrd also allowed you to not configure any interfaces, and you can configure them with the cmdline anyway | 08:22:25 |
| 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 |
