| 20 Mar 2022 |
 @elvishjerricco:matrix.org | So long as they don't escape the scope of "core functionality" | 17:17:33 |
| @elvishjerricco:matrix.org | And I think that would be in scope | 17:18:00 |
 bobvanderlinden | I wish it was easier to make it clear that this section of nixos is experimental and people should not use it. That would make it easier to merge the PR in its current state. There are tons of ideas and suggestions to come up for the PR regarding its core functionality, but imo it doesn't really help to make you apply all of those suggestions rather than people making small PRs on top to improve things. Things like formatting, naming, file-placement are really popular to comment on, but do not contribute that much to moving forward imo. | 17:22:53 |
 @janne.hess:helsinki-systems.de | Something that I really think would contribute to the initial PR would be a simple nixos test that just boots a simple VM without anything fancy. I'm currently working on that and struggling with ext4 atm :/ For some reason the kernel and mount hate me | 17:24:15 |
| @elvishjerricco:matrix.org | I should probably hide these options from the nixos manual for the time being (I forget how to do that; something about visible or internal?) | 17:24:24 |
| bobvanderlinden | Janne Heß: I'm working on a test ;D | 17:24:38 |
| @janne.hess:helsinki-systems.de | In reply to @bobvanderlinden_:matrix.org
Janne Heß: I'm working on a test ;D oh that's great. Have you made it load ext4? | 17:24:56 |
| @elvishjerricco:matrix.org | Janne Heß: Well I think an issue there is the lack of auto formatting for the rootfs. Don't NixOS tests rely on stage 1 to format a disk image for / | 17:25:06 |
| @elvishjerricco:matrix.org | * Janne Heß: Well I think an issue there is the lack of auto formatting for the rootfs. Don't NixOS tests rely on stage 1 to format a disk image for /? | 17:25:09 |
| @elvishjerricco:matrix.org | ext4 works for me | 17:25:19 |
| bobvanderlinden | lol, no that's what I'm struggling with. I think the test hasn't yet formatted /dev/vda, so that's why it is failing to mount with auto fsType | 17:25:30 |
| @janne.hess:helsinki-systems.de | ohh so the tests don't work as I thought :// | 17:25:55 |
| @elvishjerricco:matrix.org | Yea I've been testing with a pre-formatted nixos.qcow2. We need the x-systemd.makefs and x-systemd.growfs fstab options so systemd will just do the formatting for us | 17:26:25 |
| bobvanderlinden | while I was struggling I thought I might've take the oppurtinity to create a test for the emergency shell 😅 | 17:26:46 |
| @janne.hess:helsinki-systems.de | maybe we can use an installer test that boots with the old initrd and installs a system with the new one? | 17:26:49 |
| @elvishjerricco:matrix.org | That'll also require adding file system packages to stage 1's environment. The old PR had some code for this that you should look at | 17:27:03 |
| @janne.hess:helsinki-systems.de | In reply to @bobvanderlinden_:matrix.org
while I was struggling I thought I might've take the oppurtinity to create a test for the emergency shell 😅 I have a really horrible solution but I think we should come up with something in the test runner that allows us to interact with qemu's stdin | 17:27:53 |
| @janne.hess:helsinki-systems.de | Or it may be easier to spawn backdoor.service in stage 1 🤔 | 17:28:44 |
| @elvishjerricco:matrix.org | https://github.com/ElvishJerricco/nixpkgs/blob/78d09d5d9eea1259f96b366d640ccbfb5983e6c2/nixos/modules/tasks/filesystems.nix#L129
https://github.com/ElvishJerricco/nixpkgs/blob/78d09d5d9eea1259f96b366d640ccbfb5983e6c2/nixos/modules/tasks/filesystems.nix#L320
This was the stuff from the old PR that made growfs and makefs work automatically | 17:30:19 |
| @elvishjerricco:matrix.org | It's just a couple fstab options and adding fsPackages to PATH for the right unit | 17:30:43 |
| bobvanderlinden | Hmyea, I added x-systemd.makefs and x-systemd.growfs to fstab's root, but that didn't work. It seems it didn't attempt to run them yet. | 17:32:46 |
| @elvishjerricco:matrix.org | You'll need the fsPackages is probably why | 17:33:03 |
| @elvishjerricco:matrix.org | (though we ought to filter fsPackages down to only the ones needed for the stage 1 file systems, and the ones that systemd actually supports) | 17:33:35 |
| @elvishjerricco:matrix.org | Oh and note the comment on IgnoreOnIsolate in that second link | 17:34:09 |
| @elvishjerricco:matrix.org | That'll be tricky to fix because these units are generated by a systemd generator, so they exist in /run and take precedence over unit files in /etc. With the old crappy code, I could just explicitly use unitOverrides to place it in systemd-makefs@.service.d/mke2fs.conf, which does still get applied over the /run/ unit. But the generateUnits code we use now doesn't have a way to say "put this in an override, even if the unit file doesn't exist" | 17:36:12 |
| @elvishjerricco:matrix.org | I think I fixed a similar issue in the old PR in stage 2 by adding a dummy package to systemd.packages with an empty unit file, then using the systemd options to set overrides on that unit. The dummy got shadowed by the generated /run unit, but the override file got applied on top anyway. Super jank :P | 17:37:29 |
| bobvanderlinden | are you sure generateUnits doesn't create an override for upstream service files? | 17:39:36 |
| bobvanderlinden | (for dynamic mounts, yes, you're right) | 17:39:59 |
| @elvishjerricco:matrix.org | bobvanderlinden: It does, but that's not the problem | 17:41:08 |
| @elvishjerricco:matrix.org | systemd-makefs@.service doesn't exist in the units actually stored in /etc. It's only a generated unit, created by systemd-fstab-generator | 17:41:52 |
