| 31 May 2023 |
 ElvishJerricco | ok so looking at my system that has zfs on luks: It looks like the zfs import service is starting before we reach cryptsetup.target, which is odd | 11:54:34 |
 Copa Dium | Also are you sure the emergency shell times out? In my journal it looks like there's just a second zfs-import-rpool-start that spawns a second emergency shell when it fails | 11:55:01 |
| ElvishJerricco | In reply to @copadium:matrix.org
Also are you sure the emergency shell times out? In my journal it looks like there's just a second zfs-import-rpool-start that spawns a second emergency shell when it fails Oh I see. That's weird | 11:55:22 |
| Copa Dium | Would the full log be helpful to you? | 11:55:56 |
| ElvishJerricco | possibly? | 11:56:02 |
 @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
but it's harmless (Well it's not harmless exactly if you do have plymouth because plymouth crashes instead of gracefully exits when entering emergency shell right now. I have a branch with a two line fix though..... just need to find time in the next week for nixpkgs work) | 11:56:10 |
| ElvishJerricco | oh that's why that happens? wut | 11:56:37 |
| @lily:lily.flowers | (Not that that's fatal or anything. But kinda silly) | 11:56:45 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
oh that's why that happens? wut Yeah plymouth expects systemd to stop it when entering emergency shell. That seems extraordinarily dumb to have that inter-project dependency. Systemd assumes plymouth is in its install bindir which is also silly | 11:57:43 |
| Copa Dium | Also interesting is that the ssh daemon is killed when the emergency shell enters, which is weird :D | 11:58:02 |
| @lily:lily.flowers | My fix just adds plymouth-quit-wait to be wanted by and before emergency and rescue shells | 11:58:13 |
| Copa Dium | Do you have a preferred pastebin like service around here? | 11:58:26 |
| @lily:lily.flowers | In reply to @copadium:matrix.org
Do you have a preferred pastebin like service around here? (One that works and preferably without ads for me. Otherwise I really don't care myself, but I imagine ElvishJerricco is more likely to be looking at them since I'm on mobile and really need to be getting ready to leave for $dayjob) | 11:59:25 |
| ElvishJerricco | In reply to @copadium:matrix.org
Also interesting is that the ssh daemon is killed when the emergency shell enters, which is weird :D Yea, I considered adding boot.initrd.systemd.targets.emergency.wants = ["network.target"]; when initrd networking is enabled, but ultimately decided against it. You can totally add that to your config though to keep networking up in an emergency | 11:59:48 |
| ElvishJerricco | er, actually, I guess sshd.service isn't wanted by network.target... | 12:00:36 |
| ElvishJerricco | 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 | ok so there's initrd-fs.target: Triggering OnFailure= dependencies. three different times | 12:03:57 |
| ElvishJerricco | and finally initrd-switch-root.service: Triggering OnFailure= dependencies. once | 12:04:09 |
| ElvishJerricco | that's all odd | 12:04:16 |
| ElvishJerricco | oh actually zfs-import-rpool.service starts and fails 3 times as well | 12:07:56 |
| ElvishJerricco | I wonder if this has anything to do with it: https://github.com/NixOS/nixpkgs/pull/227208 | 12:14:55 |
| ElvishJerricco | 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 | 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 | anyway, I think we just need to add after = ["cryptsetup.target"];, which I could swear we already had :P | 22:00:07 |
| ElvishJerricco | and yea, that does appear to fix it | 22:06:39 |
| ElvishJerricco | now testing what happens when you let it time out with ext4 instead of zfs | 22:06:54 |
| ElvishJerricco | I think zfs no longer has a timeout problem because of the ordering Before=sysroot.mount | 22:07:11 |
