| 4 Jan 2022 |
 Paul Haerle | colemickens 🏳️🌈: It's not really in a state to be published yet. I have some local branches, but what's there in main should work at least on hetzners hcloud and you might get an idea or two for your oracle instances from there. Be aware that the resulting initrd is currently gigantic (1.3GB uncompressed at last count) | 17:11:43 |
| Paul Haerle | colemickens 🏳️🌈: Ah, forgot the link which i just made public https://github.com/dep-sys/nixos-zfs-installer | 17:12:22 |
| Paul Haerle | I think it should in theory be doable to maintain a generic flake which provides nix functions and nixosModules to bundle parameterized install scripts with a somewhat minimal kernel configuration + initrd for kexec, netbooting and vms all together. Making them unattended and seed thinks such as the host name, network config, etc to the installer in a generic way seems challenging to me. Same as flexible partitioning. e.g. EFI & zfs mirroing support would be awesome | 17:28:23 |
 colemickens | I think maybe this is OT and maybe I should throw up a repo even just so we can spitball ideas, but I am thinking along the same lines. In many cases, disk layout will be known ahead of time and I'm thinking a heuristic for "matching" to a selected disk layout to a booted machine, it notices the disks are not zpool members and kicks in. | 18:56:02 |
| colemickens | I am also thinking this initrd could be smart enough to consume VM userdata via cloud api, libvirtd, etc for last mile provisioning. | 18:56:42 |
| colemickens | With sops-nix having support for cloud KVM, and a scheme I've found for supporting multiple user zfs keys... I think some somewhat interesting things could be built that would be highly appealing to certain types of orgs. | 18:57:32 |
| colemickens | phaer: ^^ | 18:57:50 |
 @janne.hess:helsinki-systems.de | In reply to @colemickens:matrix.org
With sops-nix having support for cloud KVM, and a scheme I've found for supporting multiple user zfs keys... I think some somewhat interesting things could be built that would be highly appealing to certain types of orgs. We don't have stage-1 support in sops-nix yet though. But it's one of my next projects apart from the stc stuff | 19:13:26 |
| 5 Jan 2022 |
| Paul Haerle | In reply to @colemickens:matrix.org
I think maybe this is OT and maybe I should throw up a repo even just so we can spitball ideas, but I am thinking along the same lines. In many cases, disk layout will be known ahead of time and I'm thinking a heuristic for "matching" to a selected disk layout to a booted machine, it notices the disks are not zpool members and kicks in. A place to collect ideas would be most welcome, I learned a lot since and would have a few ideas to improve my current playground. Also quite interested in the vm data via cloud api thing! :) | 01:01:25 |
| 6 Jan 2022 |
|  Spencer Janssen joined the room. | 05:15:42 |
| 14 Jan 2022 |
| colemickens | phaer: finally circling back to look at this and I noticed that your zfs sets "encryption=off". why is that? | 02:28:12 |
| colemickens | 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. | 02:31:21 |
| Paul 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 |
| Paul 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 | weird, maybe I was just really tired. I'll make a room or something soon | 23:57:00 |
| 3 Feb 2022 |
|  kirelagin joined the room. | 01:58:33 |
| 2 Mar 2022 |
| Paul Haerle set a profile picture. | 13:09:04 |
| Paul Haerle changed their display name from phaer to Paul Haerle. | 13:09:36 |
| 3 Mar 2022 |
| colemickens changed their display name from colemickens 🏳️🌈 to colemickens. | 07:10:23 |
| 12 Mar 2022 |
|  bobvanderlinden joined the room. | 11:23:42 |
| bobvanderlinden | Hi! 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 joined the room. | 11:31:07 |
 @arianvp:matrix.org | I'm planning to work on this with Janne Heß during oceansprint.org | 11:41:25 |
| bobvanderlinden | Cool. 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.org | I 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 size | 11:46:38 |
| bobvanderlinden | 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 joined the room. | 01:44:49 |
| bobvanderlinden | I worked a bit more on the initrd-systemd PR and make-initrd-ng: https://github.com/NixOS/nixpkgs/pull/120015#issuecomment-1066001891 | 01:45:20 |
| 14 Mar 2022 |
|  shu9 joined the room. | 01:57:48 |
| 15 Mar 2022 |
| @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 |
