| 15 Dec 2022 |
 @elvishjerricco:matrix.org | Ok, so I think I know what we ought to do. We should mount /sysroot in some normal fashion, like root= or by fixing systemd#3551. Then we should populate /sysroot/etc/fstab without nixos activation before initrd-parse-etc.service. From there everything will be normal. The one little problem is if the user has /etc on a different file system. Then we probably need to undo the prepopulation of /sysroot/etc/fstab somehow just to cleanup after ourselves. So it may be that the best thing is to have a mount unit that bind mounts our preferred /sysroot/etc/fstab, and give that mount unit Conflicts=initrd-fs.target or something to that effect (probably need better ordering than that). | 23:15:23 |
| 16 Dec 2022 |
| @elvishjerricco:matrix.org | I think this is loosely what I want to do: https://github.com/NixOS/nixpkgs/compare/master...ElvishJerricco:systemd-stage-1-bind-fstab | 05:33:15 |
 @mlyx:matrix.org | https://github.com/NixOS/nixpkgs/pull/169116
Hope this PR can be merged into master as soon as possible.
Networkd and openssh are extremely useful. However, it seems that openvpn is on the to-do list. Could the openvpn part be another PR? | 07:49:43 |
| @elvishjerricco:matrix.org | I think it could. I've still got one or two tiny fixups to do first though, and I don't actually think the openvpn stuff will be very hard (I just haven't bothered trying yet) | 07:53:31 |
| 18 Dec 2022 |
 @me:linj.tech | 
Download IMG_20221218_224932.jpg | 15:41:44 |
| @me:linj.tech | it hangs here if I use linux_latest (6.1) | 15:42:19 |
| @me:linj.tech | * it hangs here if I use linux_latest (6.1) and works well using the lts kernel | 15:43:21 |
| @me:linj.tech | any ideas about how to debug this? | 15:43:35 |
| @elvishjerricco:matrix.org | That's... strange | 15:44:04 |
| @elvishjerricco:matrix.org | Can you describe the hang? Is it possible the graphics driver is scraping up? | 15:44:38 |
| @elvishjerricco:matrix.org | * Can you describe the hang? Is it possible the graphics driver is screwing up? | 15:44:59 |
| @me:linj.tech | wait a minute | 15:45:35 |
| @me:linj.tech | In reply to @elvishjerricco:matrix.org
Can you describe the hang? Is it possible the graphics driver is screwing up? even though the screen does not change, I can type the password for luks and then the system can boots into gdm. I guess it is has something to do with my config for passing through a nvidia gpu. | 17:06:54 |
| @me:linj.tech | In reply to @elvishjerricco:matrix.org
Can you describe the hang? Is it possible the graphics driver is screwing up? * even though the screen does not change, I can type the password for luks and then the system can boot into gdm. I guess it is has something to do with my config for passing through a nvidia gpu. | 17:07:13 |
| @me:linj.tech | btw, nvidia gpu pass through is broken with linux 6.1. The system hangs when I start the virtual machine with the passed through nvidia gpu. | 17:08:44 |
| @me:linj.tech | * btw, nvidia gpu passing through is broken with linux 6.1. The system hangs when I start the virtual machine with the passed through nvidia gpu. | 17:09:04 |
 K900 | $5 says blame Nvidia | 17:09:37 |
| 19 Dec 2022 |
|  lgcl (she/they) changed their profile picture. | 13:46:48 |
| 20 Dec 2022 |
| @elvishjerricco:matrix.org | Well, TIL about SYSTEMD_SYSROOT_FSTAB | 08:37:09 |
| @elvishjerricco:matrix.org | that would have been good to know | 08:37:14 |
 Winter (she/her) | In reply to @elvishjerricco:matrix.org
that would have been good to know (context, out of curiosity?) | 16:07:46 |
| @elvishjerricco:matrix.org | Winter (she/her): Basically, we get some nice things automatically by putting stuff at /sysroot/etc/fstab instead of /etc/fstab, and it's much easier if you can point it at a file of our choice instead of /sysroot/etc/fstab | 16:25:34 |
| @elvishjerricco:matrix.org | otherwise you have to deal with the fact that /sysroot/etc/fstab might not be correct for the current generation so you might have to update it, but what if /sysroot/etc is a different file system? Or if we can't write to that location for whatever reason? You can bind mount something magical over the path but that has its own quirks.
All that just goes away thanks to SYSTEMD_SYSROOT_FSTAB :P
| 16:26:54 |
| @elvishjerricco:matrix.org | and for it, we get to remove a silly hack that we have, and our FSes use the correct initrd targets instead of the regular FS targets. | 16:27:52 |
| @elvishjerricco:matrix.org | * and for it, we get to remove a silly hack that we have where we set IgnoreOnIsolate when we really shouldn't have to, and our FSes use the correct initrd targets instead of the regular FS targets. | 16:28:18 |
| @elvishjerricco:matrix.org | (all this because I wanted to test out hibernation stuff and noticed that the hibernation resume service runs with unfortunate ordering at the moment; queue discovering that we're supposed to get an fsck unit that introduces the right ordering (though even that shouldn't really be necessary), and then a whole rabbit hole about why that doesn't work quite right either) | 16:30:13 |
| @elvishjerricco:matrix.org | This is infuriating. I'm now properly onto the point of getting fsck stuff all working well, and the part that already worked in stage 2 isn't working anymore and only intermittenetly! | 18:28:30 |
| @elvishjerricco:matrix.org | I can see the unit exists with {Requires,After}=systemd-fsck@dev-vdb.service, but that unit only gets started sometimes | 18:29:33 |
| @elvishjerricco:matrix.org | * I can see the mount unit exists with {Requires,After}=systemd-fsck@dev-vdb.service, but that unit only gets started sometimes | 18:29:43 |
| @elvishjerricco:matrix.org | This is the part that I didn't change. No clue why it's busted now | 18:30:00 |
