!PSmBFWNKoXmlQBzUQf:helsinki-systems.de

Stage 1 systemd

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

Load older messages


SenderMessageTime
6 Jan 2022
@sjanssen:matrix.orgSpencer Janssen joined the room.05:15:42
14 Jan 2022
@colemickens:matrix.orgcolemickens phaer: finally circling back to look at this and I noticed that your zfs sets "encryption=off". why is that? 02:28:12
@colemickens:matrix.orgcolemickensI was all into my idea of iPXE booting Oracle VMs into some sort of installer like that, but I'm not sure it gets me a whole lot over your kexec approach, since kexec seems to work even on OCI aarch64 VMs.02:31:21
@phaer:matrix.orgPaul Haerle
In reply to @colemickens:matrix.org
phaer: finally circling back to look at this and I noticed that your zfs sets "encryption=off". why is that?
Where is that? There's encryption=on in https://github.com/dep-sys/nixos-zfs-installer/blob/main/installer/scripts/nuke-disk.sh#L35
08:32:23
@phaer:matrix.orgPaul Haerle
In reply to @colemickens:matrix.org
I was all into my idea of iPXE booting Oracle VMs into some sort of installer like that, but I'm not sure it gets me a whole lot over your kexec approach, since kexec seems to work even on OCI aarch64 VMs.
My main problem with it is that the installer image is so huge, next time i have time for this project, I'd like to work on that. Which is also one of the reasons i became interested in systemd in stage one.
But as we are a bit off-topic here. Shall we discuss in a repo, new channel or dms?
09:06:11
@colemickens:matrix.orgcolemickensweird, maybe I was just really tired. I'll make a room or something soon23:57:00
3 Feb 2022
@kirelagin:matrix.orgkirelagin joined the room.01:58:33
2 Mar 2022
@phaer:matrix.orgPaul Haerle set a profile picture.13:09:04
@phaer:matrix.orgPaul Haerle changed their display name from phaer to Paul Haerle.13:09:36
3 Mar 2022
@colemickens:matrix.orgcolemickens changed their display name from colemickens 🏳️‍🌈 to colemickens.07:10:23
12 Mar 2022
@bobvanderlinden_:matrix.orgbobvanderlinden joined the room.11:23:42
@bobvanderlinden_:matrix.orgbobvanderlindenHi! I'm currently working on getting systemd to work in initrd. I was wondering whether others have attempted to do so as well and how far you got?11:25:35
@ius:nltrix.netius joined the room.11:31:07
@arianvp:matrix.orgArian I'm planning to work on this with Janne Heß during oceansprint.org 11:41:25
@bobvanderlinden_:matrix.orgbobvanderlindenCool. I just found out about https://github.com/NixOS/nixpkgs/pull/120015, so I'm going to give that a go 👍️ Is this PR also what you're going to work on?11:42:59
@arianvp:matrix.orgArianI don't know yet. Have to recap it a bit. I have my own homegrown initrd but it hasn't put any effort yet in minimizing closure size11:46:38
@bobvanderlinden_:matrix.orgbobvanderlinden Ah, same here. I resurrected an old local branch of the systemd work and wasn't aware the PR was made yet. I ran into the same problem as ElvishJerricco in that the extraUtils was not a good solution and looked into a same kind of thing as his make-initrd-ng tool. I'm excited how far along the PR seems to be, but it does seem outdated. I'll look if it can be based on current nixos-unstable. 11:59:43
13 Mar 2022
@yinfeng:matrix.orgyinfeng joined the room.01:44:49
@bobvanderlinden_:matrix.orgbobvanderlindenI worked a bit more on the initrd-systemd PR and make-initrd-ng: https://github.com/NixOS/nixpkgs/pull/120015#issuecomment-106600189101:45:20
14 Mar 2022
@shu9:matrix.orgshu9 joined the room.01:57:48
15 Mar 2022
@janne.hess:helsinki-systems.de@janne.hess:helsinki-systems.de

bobvanderlinden_: I looked at your branch today and while I like what I see, there's one or two things you should consider. First off, a huge PR which touches most of nixos/ is unlikely to find happy mergers and likely to find happy reverters if it breaks something (which is of course more likely with huge PRs). I saw you split out the systemd splitting stuff and I think that's a good way to go forward.

The second thing is that I noticed you just replace stage-1.nix. This is of course the way to go in the future, but imo it would be easier to adopt if it was opt-in at first, opt-out in a later release and no option anymore in an even later release. The reason for that is that I find it hard to believe that all use cases of all users are working when the PR is merged (there are just so many of them), so being able to go back to the old behavior could help. For simple systems, curious users (like myself) could adopt the new stage-1 in 22.05 (or whenever the PR is merged) already while people with more complex setups can wait until their stuff works. A thing you could do here (just my thoughts) would be to provide a secondary interface, maybe something like boot.initramfs (Wikipedia says we have a initramfs, not an initrd) with visibility = "shallow" in the manual so people can discover the option. This way you could cut all ties with the old initrd interface and start from a clean slate. While most options still need counterparts in the new initrd, we don't necessarily have to keep all types and implications of these options

14:18:37
@bobvanderlinden_:matrix.orgbobvanderlinden

Janne Heß: Thanks for looking into it! I completely agree. I'd like to do https://github.com/NixOS/nixpkgs/pull/164016 in stages and the individual commits are the smallest I could make the steps. A next stage is also ready, but I'd like to send that as a separate PR. That one makes the options units, services, slices, etc reusable, so they can be reused in systemd, systemd.user as well as initrd.systemd. I'd like to use the same units/services/etc structure, so that we have something to build on further.

I totally agree that stage-1.nix should be made compatible with an option to switch between the two. I worked on a local branch myself in the past where that was the case, but since this PR (https://github.com/NixOS/nixpkgs/pull/120015) seemed to be progress further along I thought I'd resurrect that one. To move on that one further I'd like to be able to add systemd services to initrd properly, hence why I started with the refactoring of systemd. Once I can add services, I'd like to add a preDeviceCommands, postDeviceCommands, postMountCommands, etc services that will essentially emulate the current initrd boot process.

boot.initrd.systemd.enable = true; sounds like a viable option.

I know big PRs are quite annoying to review and merge. If I can make the changes smaller, let me know. I can also submit the individual commits as separate PRs if that's desired. For some of the changes I can even make sure that the build hashes of the tests do not change (an actual 'no functionality has changed' refactor). As long as I know the path I'm walking is one that won't get stalled. Let me know what I can do to move things forward :+1:.

Btw, I really appreciate your message here, I was quite glad to see it. I'll install the Element mobile/desktop to keep up with notifications here.

19:56:11
@bobvanderlinden_:matrix.orgbobvanderlinden *

Janne Heß: Thanks for looking into it! I completely agree. I'd like to do https://github.com/NixOS/nixpkgs/pull/164016 in stages and the individual commits are the smallest I could make the steps. A next stage is also ready, but I'd like to send that as a separate PR. That one makes the options units, services, slices, etc reusable, so they can be reused in systemd, systemd.user as well as initrd.systemd. I'd like to use the same units/services/etc structure, so that we have something to build on further.

I totally agree that stage-1.nix should be made compatible with an option to switch between the two. I worked on a local branch myself in the past where that was the case, but since this PR (https://github.com/NixOS/nixpkgs/pull/120015) seemed to be progress further along I thought I'd resurrect that one. To move on that one further I'd like to be able to add systemd services to initrd properly, hence why I started with the refactoring of systemd. Once I can add services, I'd like to add a preDeviceCommands, postDeviceCommands, postMountCommands, etc services that will essentially emulate the current initrd boot process.

boot.initrd.systemd.enable = true; sounds like a viable option.

I know big PRs are quite annoying to review and merge. If I can make the changes smaller, let me know. I can also submit the individual commits as separate PRs if that's desired. For some of the changes I can even make sure that the build hashes of the tests do not change (an actual 'no functionality has changed' refactor). As long as I know the path I'm walking is one that won't get stalled (and result in neverending rebases and conflict resolution). Let me know what I can do to move things forward :+1:.

Btw, I really appreciate your message here, I was quite glad to see it. I'll install the Element mobile/desktop to keep up with notifications here.

19:58:01
@bobvanderlinden_:matrix.orgbobvanderlinden *

Janne Heß: Thanks for looking into it! I completely agree. I'd like to do https://github.com/NixOS/nixpkgs/pull/164016 in stages and the individual commits are the smallest I could make the steps. A next stage is also ready, but I'd like to send that as a separate PR. That one makes the options units, services, slices, etc reusable, so they can be reused in systemd, systemd.user as well as initrd.systemd. I'd like to use the same units/services/etc structure, so that we have something to build on further.

I totally agree that stage-1.nix should be made compatible with an option to switch between the two. I worked on a local branch myself in the past where that was the case, but since this PR (https://github.com/NixOS/nixpkgs/pull/120015) seemed to be progress further along I thought I'd resurrect that one. To move on that one further I'd like to be able to add systemd services to initrd properly, hence why I started with the refactoring of systemd. Once I can add services, I'd like to add a preDeviceCommands, postDeviceCommands, postMountCommands, etc services that will essentially emulate the current initrd boot process.

boot.initrd.systemd.enable = true; or boot.initramfs.enable = true are viable options. I still need to dive deeper into this than I currently have.

I know big PRs are quite annoying to review and merge. If I can make the changes smaller, let me know. I can also submit the individual commits as separate PRs if that's desired. For some of the changes I can even make sure that the build hashes of the tests do not change (an actual 'no functionality has changed' refactor). As long as I know the path I'm walking is one that won't get stalled (and result in neverending rebases and conflict resolution). Let me know what I can do to move things forward :+1:.

Btw, I really appreciate your message here, I was quite glad to see it. I'll install the Element mobile/desktop to keep up with notifications here.

20:02:36
@bobvanderlinden_:matrix.orgbobvanderlinden *

Janne Heß: Thanks for looking into it! I completely agree. I'd like to do https://github.com/NixOS/nixpkgs/pull/164016 in stages and the individual commits are the smallest I could make the steps. A next stage is also ready, but I'd like to send that as a separate PR. That one makes the options units, services, slices, etc reusable, so they can be reused in systemd, systemd.user as well as initrd.systemd. I'd like to use the same units/services/etc structure, so that we have something to build on further.

I totally agree that stage-1.nix should be made compatible with an option to switch between the two. I worked on a local branch myself in the past where that was the case, but since this PR (https://github.com/NixOS/nixpkgs/pull/120015) seemed to be progressed further along I thought I'd resurrect that one. To move on that one further I'd like to be able to add systemd services to initrd properly, hence why I started with the refactoring of systemd. Once I can add services, I'd like to add a preDeviceCommands, postDeviceCommands, postMountCommands, etc services that will essentially emulate the current initrd boot process.

boot.initrd.systemd.enable = true; or boot.initramfs.enable = true are viable options. I still need to dive deeper into this than I currently have.

I know big PRs are quite annoying to review and merge. If I can make the changes smaller, let me know. I can also submit the individual commits as separate PRs if that's desired. For some of the changes I can even make sure that the build hashes of the tests do not change (an actual 'no functionality has changed' refactor). As long as I know the path I'm walking is one that won't get stalled (and result in neverending rebases and conflict resolution). Let me know what I can do to move things forward :+1:.

Btw, I really appreciate your message here, I was quite glad to see it. I'll install the Element mobile/desktop to keep up with notifications here.

20:17:10
@bobvanderlinden_:matrix.orgbobvanderlinden Btw, looked into initrd/initramfs some more. You're right about nixos currently using initramfs, not initrd. It's confusing that the options are referring to initrd. Might indeed be nice to move to more sane option naming while introducing the systemd one. boot.initramfs.systemd.enable = true currently seems most fitting. 20:26:39
@bobvanderlinden_:matrix.orgbobvanderlinden changed their display name from bobvanderlinden_ to bobvanderlinden.20:36:41
@bobvanderlinden_:matrix.orgbobvanderlindenMoving the systemd helper functions to systemd-lib.nix seemed like the most important change to merge, so I create a separate PR for that: https://github.com/NixOS/nixpkgs/pull/16431720:59:21
@janne.hess:helsinki-systems.de@janne.hess:helsinki-systems.de
In reply to @bobvanderlinden_:matrix.org

Janne Heß: Thanks for looking into it! I completely agree. I'd like to do https://github.com/NixOS/nixpkgs/pull/164016 in stages and the individual commits are the smallest I could make the steps. A next stage is also ready, but I'd like to send that as a separate PR. That one makes the options units, services, slices, etc reusable, so they can be reused in systemd, systemd.user as well as initrd.systemd. I'd like to use the same units/services/etc structure, so that we have something to build on further.

I totally agree that stage-1.nix should be made compatible with an option to switch between the two. I worked on a local branch myself in the past where that was the case, but since this PR (https://github.com/NixOS/nixpkgs/pull/120015) seemed to be progressed further along I thought I'd resurrect that one. To move on that one further I'd like to be able to add systemd services to initrd properly, hence why I started with the refactoring of systemd. Once I can add services, I'd like to add a preDeviceCommands, postDeviceCommands, postMountCommands, etc services that will essentially emulate the current initrd boot process.

boot.initrd.systemd.enable = true; or boot.initramfs.enable = true are viable options. I still need to dive deeper into this than I currently have.

I know big PRs are quite annoying to review and merge. If I can make the changes smaller, let me know. I can also submit the individual commits as separate PRs if that's desired. For some of the changes I can even make sure that the build hashes of the tests do not change (an actual 'no functionality has changed' refactor). As long as I know the path I'm walking is one that won't get stalled (and result in neverending rebases and conflict resolution). Let me know what I can do to move things forward :+1:.

Btw, I really appreciate your message here, I was quite glad to see it. I'll install the Element mobile/desktop to keep up with notifications here.

I'll let you know if anything should be split into smaller pieces but that really depends a lot on the person reviewing it and their knowledge in the different subsystems (for example, I'd rather not merge a large PR like yours in the systemd area but I think others would be able to comprehend the implications). I usually think of PR size in a project this size of the minimal amount of changes that make sense without further changes (I hope that sentence makes sense). Another thing I learned that makes merging a lot quicker and more likely is to supply an absurd amount of tests but it's probably too early to have anything worth testing right now
23:11:09
16 Mar 2022
@bobvanderlinden_:matrix.orgbobvanderlinden Indeed. I also realized that it could take a long time before everyone agrees on all the changes that I have made in #164016. That is why I split off the most important change to https://github.com/NixOS/nixpkgs/pull/164317. I can keep working on making initramfs's systemd as nice and reusable as possible. Since it will be under a boot.initramfs.systemd.enable-option it'll be easier to merge already. Once it is settled that the reusable parts are indeed the right way to go, we can slowly merge them into the systemd and systemd.user modules. 19:08:34

Show newer messages


Back to Room ListRoom Version: 6