| 31 May 2023 |
 @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 |
| @elvishjerricco:matrix.org | oddlama: That might just be because systemd stage 1 defaults flushBeforeStage2 to false? Assuming you're using initrd networking | 22:12:09 |
| @elvishjerricco:matrix.org | if you set that to true you might not need the udev rule | 22:12:17 |
| Copa Dium | In reply to @elvishjerricco:matrix.org
anyway, I think we just need to add after = ["cryptsetup.target"];, which I could swear we already had :P should I add that and re-test? | 22:12:52 |
| @elvishjerricco:matrix.org | In reply to @lily:lily.flowers
If I don't enter password it times out on the mapper device though Lily Foster: In my test with ext4, I'm not getting such a timeout | 22:13:13 |
| @elvishjerricco:matrix.org | In reply to @copadium:matrix.org
should I add that and re-test? Yea, you could try boot.initrd.systemd.services."zfs-import-${poolname}".after = ["cryptsetup.target"]; | 22:13:35 |
| @elvishjerricco:matrix.org | (obviously substitute your actual pool name) | 22:13:51 |
| Copa Dium | Okay I am testing now | 22:15:39 |
| @elvishjerricco:matrix.org | In reply to @elvishjerricco:matrix.org
Lily Foster: In my test with ext4, I'm not getting such a timeout in fact, when I finally decided to enter the passphrase, the little "waiting for..." message about the mapper device showed up for a second, saying it had been waiting for 9mins, so that definitely doesn't time out :P | 22:15:46 |
 @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
in fact, when I finally decided to enter the passphrase, the little "waiting for..." message about the mapper device showed up for a second, saying it had been waiting for 9mins, so that definitely doesn't time out :P Uhhhh let me try it again real quick | 22:16:46 |
| Copa Dium | Still getting a timeout | 22:21:53 |
| Copa Dium | and 2 emergency shells | 22:22:01 |
| @elvishjerricco:matrix.org | Copa Dium: and you're using luks, not zfs encryption, right? | 22:23:46 |
