| 16 Apr 2023 |
 @hexa:lossy.network | personally I configure a dedicated IPv6 address in stage1, and something else in stage2, so that I don't get conflicting hostkeys on SSH 🙂 | 16:47:03 |
| @hexa:lossy.network | no strong opinion, as you said I can enable flushing | 16:47:44 |
| @hexa:lossy.network | * no strong opinion, as you said I can enable flushing and I will | 16:47:50 |
| @hexa:lossy.network | since it is configurable I don't see it as a blocker fwiw | 16:48:34 |
| @hexa:lossy.network | the default also doesn't bother me too much | 16:48:44 |
 @elvishjerricco:matrix.org | Yea I think we'll leave flushing disabled by default when systemd initrd is enabled (and enabled by default with regular initrd, since that's the existing behavior). flokli does that sound ok to you? | 16:49:52 |
 flokli | Sorry, i was busy with family stuff all day and couldn't get to reply on messages | 16:50:45 |
| @elvishjerricco:matrix.org | no worries | 16:50:54 |
| flokli | I'll reply in a bit | 16:51:27 |
 Arian | Slight preference on opt in flushing from my side | 16:51:43 |
| Arian | But fine either way | 16:51:47 |
| flokli | I guess flushing is now opt-in. | 20:26:45 |
| flokli | ElvishJerricco: hexa I commented in https://github.com/NixOS/nixpkgs/pull/169116#discussion_r1168015358 | 20:26:58 |
| @hexa:lossy.network | If system-wide link configs are used in stage1 that would make my use case for flushing non-existant | 20:28:22 |
| @hexa:lossy.network | * If system-wide link configs are applied in stage1 that would make my use case for flushing non-existant | 20:28:29 |
| flokli | As far as other netdev settings (like controlling link speeds explicitly, or *{CheckSum,Segmentation}Offload, systemd also pretty much added all these as options | 20:32:53 |
| flokli | * As far as other netdev settings (like controlling link speeds explicitly, or *{CheckSum,Segmentation}Offload, systemd also pretty much added all these as options. I'm not sure how much of that is exposed to be accessible from the module system | 20:33:06 |
| flokli | and when it comes to "having a different IP address in initrd to avoid host key stuff", I'd probably go with a different port, and keep the IP. But in any case, that might be a usecase that could be mentioned in the description | 20:35:18 |
| 17 Apr 2023 |
| flokli | ElvishJerricco: sorry for being so pedantic on the networking bits in the PR, but i feel like we need to get the semantics sorted out before too many people end up switching to it, and possibly get angry if we switch semantics and break possibly remote machines. | 21:08:14 |
| @elvishjerricco:matrix.org | Yep, I totally understand | 21:08:29 |
| @elvishjerricco:matrix.org | I do really want to get it done before 23.05, but that shouldn't be too hard even with max pedantry :) | 21:08:50 |
| flokli | I'll try to check my notifications more frequently in the coming days :-) | 21:09:30 |
| @elvishjerricco:matrix.org | Rather than continuing to discuss this tangent on the PR,
As for the link units, the PR that added this comment also linked to an issue, but that issue was closed by this way before that PR was even made. I'm wondering why that systemd change isn't enough to resolve the problem. Surely you're not expected to do your interface renaming in stage 1. In fact, the comments in the issue suggest that the udev rules to rename the interface in stage 2 should happen before networkd is even notified the interface is ready.
| 21:18:09 |
| @elvishjerricco:matrix.org | And fwiw, if I remove the line that adds the link units to systemd stage 1 and enable systemd stage 1 in the nixosTests.networking.rename test, the test doesn't fail even after 20 tries. | 21:19:59 |
| @elvishjerricco:matrix.org | * And fwiw, if I remove the line that adds the link units to systemd stage 1 and enable systemd stage 1 in the nixosTests.networking.networkd.rename test, the test doesn't fail even after 20 tries. | 21:20:16 |
 @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
And fwiw, if I remove the line that adds the link units to systemd stage 1 and enable systemd stage 1 in the nixosTests.networking.networkd.rename test, the test doesn't fail even after 20 tries. Yeah I tried it as well and that test seemed perfectly happy renaming in stage2. But I admittedly didn't try it with initrd networking enabled | 21:47:26 |
| 18 Apr 2023 |
|  @nikstur:matrix.org joined the room. | 09:26:29 |
| @nikstur:matrix.org | In reply to @elvishjerricco:matrix.org
like, if we're going to require the stage 2 fs to be set up, then we should do it in stage 2, not stage 1. And if we're doing it in stage 1, just put the config files in stage 1 This is, however, just the design of systemd-repart. Not a decision the module makes: https://www.freedesktop.org/software/systemd/man/systemd-repart.html#--root= systemd-repart is really designed to work with disk images (containing all required data to setup the system, including the root fs). Running systemd-repart in the initrd is then just a matter of running it earlier so that other services that start in stage 2 can already work on the enlarged partitions. Also the module gives the user the choice to run repart either in the initrd or in stage 2. All in all it to mimic the standard behaviour of repart as closely as possible in NixOS. | 09:38:23 |
| @nikstur:matrix.org | In reply to @elvishjerricco:matrix.org
like, if we're going to require the stage 2 fs to be set up, then we should do it in stage 2, not stage 1. And if we're doing it in stage 1, just put the config files in stage 1 * This is, however, just the design of systemd-repart. Not a decision the module makes: https://www.freedesktop.org/software/systemd/man/systemd-repart.html#--root= systemd-repart is really designed to work with disk images (containing all required data to setup the system, including the root fs). Running systemd-repart in the initrd is then just a matter of running it earlier so that other services that start in stage 2 can already work on the enlarged partitions. Also the module gives the user the choice to run repart either in the initrd or in stage 2. All in all it tries to mimic the standard behaviour of repart as closely as possible in NixOS. | 10:02:04 |
| @elvishjerricco:matrix.org |
This is, however, just the design of systemd-repart
No? The docs say nothing of the sort. --root is just something that a lot of systemd utils support; it's not saying that's the only way to work with not-the-current-root-fs
The use case for systemd-repart in stage 1 is 100% for formatting and resizing the root fs. This is a major reason why /sysusr exists at all; systemd-repart finds the config files in what will become /usr and uses that to format what will become /. /sysusr exists so that /sysroot doesn't have to be mounted first, precisely because things like systemd-repart are meant to alter that stuff
| 16:41:25 |
