!PSmBFWNKoXmlQBzUQf:helsinki-systems.de

Stage 1 systemd

76 Members
systemd in NixOs's stage 1, replacing the current bash tooling https://github.com/NixOS/nixpkgs/projects/5124 Servers

Load older messages


SenderMessageTime
9 Feb 2023
@lily:lily.flowers@lily:lily.flowers
In reply to @elvishjerricco:matrix.org
Oh btw this is ready for review now that 252.5 is in staging: https://github.com/NixOS/nixpkgs/pull/208269
I left a review with the only comment I had. I'll try running the PR on my own laptop after staging-next is merged, to ensure it doesn't regress anything on my system
17:08:08
12 Feb 2023
@kranzes:matrix.org@kranzes:matrix.orgHow's networking support going?00:08:59
@elvishjerricco:matrix.org@elvishjerricco:matrix.orgI've been using it reliably. Seems better than scripted initrd's networking so far.00:09:31
@elvishjerricco:matrix.org@elvishjerricco:matrix.orgThat's on my list of things to work on this weekend00:09:38
@elvishjerricco:matrix.org@elvishjerricco:matrix.orgWould like to get it merged soon00:09:45
13 Feb 2023
@elvishjerricco:matrix.org@elvishjerricco:matrix.org Lily Foster: FYI apparently I didn't notice that they replaced my PR with one that has the problems I mentioned: https://github.com/systemd/systemd/pull/26367 07:11:07
@elvishjerricco:matrix.org@elvishjerricco:matrix.org So I'm kinda frustrated, even though that will realistically solve the issue as far as they're concerned (since they seem to think literally only / and /usr will ever be mounted in initrd) 07:11:46
@lily:lily.flowers@lily:lily.flowers
In reply to @elvishjerricco:matrix.org
Lily Foster: FYI apparently I didn't notice that they replaced my PR with one that has the problems I mentioned: https://github.com/systemd/systemd/pull/26367
Yeah I saw :(
11:58:30
@lily:lily.flowers@lily:lily.flowers
In reply to @elvishjerricco:matrix.org
So I'm kinda frustrated, even though that will realistically solve the issue as far as they're concerned (since they seem to think literally only / and /usr will ever be mounted in initrd)
I don't even understand why something that just hides the problem rather than fixes it is preferred, since it was never articulated in the thread what is undesirable about a sync point or why the hack is better. Yu just sorta opened a new PR without waiting for your feedback
12:00:10
14 Feb 2023
@k900:0upti.meK900Bump: https://github.com/NixOS/nixpkgs/pull/21050518:01:36
@k900:0upti.meK900Any reason I shouldn't just merge this?18:01:40
@k900:0upti.meK900It's been running fine on all of my machines18:01:47
@k900:0upti.meK900(and I'm cleaning up my pile of cherry-picks)18:01:55
@elvishjerricco:matrix.org@elvishjerricco:matrix.org K900: I still think it should be based on chroot and realpath but I don't care enough to say it shouldn't be merged 18:08:19
@k900:0upti.meK900I'd rather run all of this after the chroot entirely tbh18:09:58
@k900:0upti.meK900But I'm not sure there's a good way to do that18:10:06
@k900:0upti.meK900Outside of wrapping systemd18:10:18
@k900:0upti.meK900Which is just ew18:10:24
@k900:0upti.meK900I'm still hoping to see the day where we don't need to do that on nixos-wsl18:11:29
@lily:lily.flowers@lily:lily.flowers ElvishJerricco: I've been thinking about submitting a PR to systemd to canonicalize source for bind mounts (specifically so that they can be canonicalized from /sysroot in initrd). It would prevent us needing to artificially prepend /sysroot to only bind mounts from the NixOS side when generating the fstab for systemd-based initrd, and based on the old systemd PR I linked, they seem receptive to merging that functionality (or at least they did a few years ago). Thoughts? 18:40:02
@elvishjerricco:matrix.org@elvishjerricco:matrix.orgwell the awkward thing is that bind mounts aren't the only problem18:41:26
@lily:lily.flowers@lily:lily.flowersYeah, was worried you were going to say that. We only handle it for bind mounts in NixOS though18:41:49
@elvishjerricco:matrix.org@elvishjerricco:matrix.orgoverlayfs, for instance, has the directory options that would need the same treatment18:41:44
@lily:lily.flowers@lily:lily.flowersI mean theoretically I could just make it do that for any mount if the source is a non-/dev and non-/sys path18:42:13
@elvishjerricco:matrix.org@elvishjerricco:matrix.orgthis isn't to say we shouldn't improve bind mounts18:41:56
@lily:lily.flowers@lily:lily.flowers * I mean theoretically I could just make it do that for any mount if the source is a non-/dev and non-/sys absolute path18:42:26
@elvishjerricco:matrix.org@elvishjerricco:matrix.orgjust saying it's awkward18:42:02
@lily:lily.flowers@lily:lily.flowers
In reply to @lily:lily.flowers
I mean theoretically I could just make it do that for any mount if the source is a non-/dev and non-/sys absolute path
(Idk if there are scenarios where that would also Do The Wrong Thing too though)
18:42:59
@elvishjerricco:matrix.org@elvishjerricco:matrix.orgwell the overlayfs example has the problem in the mount options, not the device or mountpoint18:43:19
@lily:lily.flowers@lily:lily.flowers
In reply to @elvishjerricco:matrix.org
overlayfs, for instance, has the directory options that would need the same treatment
Oh true, didn't even think about that. Hopefully people aren't doing that as an fs needed for boot though? Because we only generate for those needed for boot, right?
18:43:32

Show newer messages


Back to Room ListRoom Version: 6