| 31 May 2023 |
 ElvishJerricco | which means sysroot.mount is never started, and it never starts counting time | 22:07:27 |
| ElvishJerricco | meanwhile with ext4, sysroot.mount is started, and the cryptsetup service is waiting in the background? | 22:07:53 |
| ElvishJerricco | 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 | I wouldn't expect that to cause that... | 22:09:40 |
| ElvishJerricco | but maybe? | 22:09:42 |
| ElvishJerricco | 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 | oddlama: That might just be because systemd stage 1 defaults flushBeforeStage2 to false? Assuming you're using initrd networking | 22:12:09 |
| ElvishJerricco | 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 | 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 | 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 | (obviously substitute your actual pool name) | 22:13:51 |
| Copa Dium | Okay I am testing now | 22:15:39 |
| ElvishJerricco | 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 | Copa Dium: and you're using luks, not zfs encryption, right? | 22:23:46 |
| Copa Dium | Yes | 22:24:15 |
| Copa Dium | Any commands I should run in the emergency shell? | 22:24:32 |
| Copa Dium | oh wait | 22:24:57 |
| ElvishJerricco | systemctl show -p After zfs-import-POOL.service? | 22:24:57 |
| Copa Dium | maybe I messed up | 22:25:00 |
| Copa Dium | Dumb me misspelled the pool name in the dependnecy | 22:25:34 |
| Copa Dium | I'll try again and report | 22:25:42 |
