| 31 May 2023 |
 @elvishjerricco:matrix.org | er, actually, I guess sshd.service isn't wanted by network.target... | 12:00:36 |
| @elvishjerricco:matrix.org | so that wouldn't actually work | 12:01:09 |
 @gdamjan:spodeli.org | you can add that too :) | 12:01:47 |
 Copa Dium | In reply to @elvishjerricco:matrix.org
possibly? https://hastebin.skyra.pw/itupozaruc.yaml | 12:02:25 |
| @elvishjerricco:matrix.org | ok so there's initrd-fs.target: Triggering OnFailure= dependencies. three different times | 12:03:57 |
| @elvishjerricco:matrix.org | and finally initrd-switch-root.service: Triggering OnFailure= dependencies. once | 12:04:09 |
| @elvishjerricco:matrix.org | that's all odd | 12:04:16 |
| @elvishjerricco:matrix.org | oh actually zfs-import-rpool.service starts and fails 3 times as well | 12:07:56 |
| @elvishjerricco:matrix.org | I wonder if this has anything to do with it: https://github.com/NixOS/nixpkgs/pull/227208 | 12:14:55 |
| @elvishjerricco:matrix.org | bleh; still extremely sleepy. I need to like... actually wake up before I start messing with this any more | 12:17:43 |
 oddlama | Is there a way to inject udev rules into the initrd? I have some interfaces that I usually rename in stage2, but apparently the rules are not applied if the interface is already configured in stage1 | 20:06:29 |
| @elvishjerricco:matrix.org | Ok so the zfs import service appears not to be ordered after cryptsetup.target. Then, when it fails, initrd-fs.target fails and local-fs.target is finally reached, and two things happen simultaneously: 1) initrd-parse-etc.service starts, which reloads the daemon and starts initrd-fs.target again, and 2) emergency mode is entered. So now that initrd-fs.target is starting again, the zfs import service starts one more time, and again will fail when you timeout. After the second failure, initrd.target is reached, and it attempts to move on to initrd-cleanup.service, which isolates initrd-switch-root.target. This kills the emergency mode. Finally, initrd-swithc-root.service fails, re-entering emergency mode.
Two unexplained things. 1) Why does Copa Dium's log have three attempts at zfs-import-${pool}.service, when I only have two in my test? 2) In my test, there's an additional, third attempt to mount the root fs because initrd-switch-root.service depends on initrd-fs.target, but for some reason this doesn't start zfs-import-${pool}.service a third time.
| 21:59:18 |
| @elvishjerricco:matrix.org | anyway, I think we just need to add after = ["cryptsetup.target"];, which I could swear we already had :P | 22:00:07 |
| @elvishjerricco:matrix.org | and yea, that does appear to fix it | 22:06:39 |
| @elvishjerricco:matrix.org | now testing what happens when you let it time out with ext4 instead of zfs | 22:06:54 |
| @elvishjerricco:matrix.org | I think zfs no longer has a timeout problem because of the ordering Before=sysroot.mount | 22:07:11 |
| @elvishjerricco:matrix.org | which means sysroot.mount is never started, and it never starts counting time | 22:07:27 |
| @elvishjerricco:matrix.org | meanwhile with ext4, sysroot.mount is started, and the cryptsetup service is waiting in the background? | 22:07:53 |
| @elvishjerricco:matrix.org | hm nevermind; testing with ext4, it does not appear to be timing out for me? | 22:09:13 |
| Copa Dium |
Why does Copa Dium's log have three attempts at zfs-import-${pool}.service
Maybe because I sshed into it to read the logs?
| 22:09:25 |
| Copa Dium | *
Why does Copa Dium's log have three attempts at zfs-import-${pool}.service
Maybe because I sshed into it to read the logs?
| 22:09:30 |
| @elvishjerricco:matrix.org | I wouldn't expect that to cause that... | 22:09:40 |
| @elvishjerricco:matrix.org | but maybe? | 22:09:42 |
| @elvishjerricco:matrix.org | In reply to @oddlama:matrix.org
Is there a way to inject udev rules into the initrd? I have some interfaces that I usually rename in stage2, but apparently the rules are not applied if the interface is already configured in stage1 oh, oddlama: boot.initrd.services.udev.rules | 22:10:18 |
| oddlama | In reply to @oddlama:matrix.org
Is there a way to inject udev rules into the initrd? I have some interfaces that I usually rename in stage2, but apparently the rules are not applied if the interface is already configured in stage1 Got that sorted out. Turned out to be boot.initrd.services.udev.packages which I initially dismissed because there was no systemd in the name | 22:10:19 |
| oddlama | Lol same time xD Thanks tho | 22:10:37 |
| oddlama | A bit weird is that it wasn't necessary to include interface renaming rules in the non-systemd initrd | 22:11:12 |
