| 28 May 2023 |
 @elvishjerricco:matrix.org | In reply to @elvishjerricco:matrix.org
I mean, what else is there to do? If a critical thing fails, an emergency shell is really the only option maybe we could make emergency.target output systemctl status --failed before starting emergency.service? | 22:04:36 |
 @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
maybe we could make emergency.target output systemctl status --failed before starting emergency.service? Now that sounds like a good idea, actually | 22:04:57 |
| @elvishjerricco:matrix.org | yea we could put it in the ExecStartPre of emergency.service | 22:05:39 |
| @elvishjerricco:matrix.org | since it takes the TTY | 22:05:45 |
| @elvishjerricco:matrix.org | that way we don't have to do silly hacks about it | 22:05:52 |
 @hexa:lossy.network |
zfs-scrub-start[3654385]: cannot open 'zpool': no such pool
| 22:05:55 |
| @hexa:lossy.network | lalalala | 22:05:58 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
yea we could put it in the ExecStartPre of emergency.service Also I think it may need fixing with plymouth, btw. It only works now because plymouth crashes rather than being told to quit. I had a branch where I did fix that, but never PR'd it because I never PR'd the plymouth update/overhaul branch which I wanted first because time and effort and triage | 22:06:53 |
| @lily:lily.flowers | (Also jtojnar never got back to me on it... which is fine, but it did lead to it slipping my mind) | 22:07:30 |
| @elvishjerricco:matrix.org | In reply to @hexa:lossy.network
zfs-scrub-start[3654385]: cannot open 'zpool': no such pool
wait is it trying to scrub in initrd? We should fix that for sure | 22:07:38 |
| @hexa:lossy.network | nah, unrelated | 22:07:44 |
| @hexa:lossy.network | just executed systemctl status --failed and noticed the failure 😄 | 22:07:54 |
| @elvishjerricco:matrix.org | Lily Foster: And yea, there's probably a bunch of plymouth stuff to do... | 22:07:59 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
Lily Foster: And yea, there's probably a bunch of plymouth stuff to do... I've done a lot, but I guess I never PR'd it. I think I was also still trying to muck around with luks in a nixos-rebuild build-vm for testing too | 22:09:25 |
| @lily:lily.flowers | I'll make sure it's up-to-date and still working later in the week and opening it up + ping you on it if you want (also jan, again) | 22:10:28 |
| @elvishjerricco:matrix.org | sounds good | 22:10:41 |
| 29 May 2023 |
 Winter (she/her) | In reply to @lily:lily.flowers
I use initrd-root-device.target and initrd-root-fs.target and sysroot.mount for ordering why that ordering (well, when it works) or hexa's, over mine? is there something wrong about mine? (i have no idea what i'm doing) | 01:24:24 |
| Winter (she/her) | also | 01:25:00 |
| @elvishjerricco:matrix.org | In reply to @winterqt:nixos.dev
why that ordering (well, when it works) or hexa's, over mine? is there something wrong about mine? (i have no idea what i'm doing) The problem with your ordering was that you have both Before and After on local-fs.target | 01:25:31 |
| Winter (she/her) | right, but what if I set DefaultDependencies = no? | 01:25:45 |
| Winter (she/her) | as hexa's does | 01:25:49 |
| @elvishjerricco:matrix.org | because without DefaultDependencies=no, After=local-fs.target is a (transitive) default dependency | 01:25:49 |
| @elvishjerricco:matrix.org | Then it's still not right because initrd uses initrd-fs.target instead of local-fs.target | 01:26:17 |
| @elvishjerricco:matrix.org | or rather | 01:26:19 |
| @elvishjerricco:matrix.org | it uses both | 01:26:21 |
| Winter (she/her) | ah, okay. | 01:26:24 |
| @elvishjerricco:matrix.org | but initrd-fs.target is your host file systems | 01:26:31 |
| Winter (she/her) | so sysroot.mount + initrd-fs.target are the way to go, i guess? | 01:26:41 |
| @elvishjerricco:matrix.org | while local-fs.target is stage 1 specific file systems | 01:26:42 |
| @elvishjerricco:matrix.org | initrd-fs.target depends on sysroot.mount already | 01:26:55 |
