| 7 Dec 2022 |
 @elvishjerricco:matrix.org | So maybe I was wrong when I suggested it doesn't matter much when the rollback happens :P | 21:13:53 |
| @elvishjerricco:matrix.org | If the snapshot being rolled back to doesn't have those mountpoints, I'm not sure what happens... | 21:14:16 |
 @hexa:lossy.network | my point exactly 😄 | 21:14:40 |
| @elvishjerricco:matrix.org | So I guess try adding before = ["sysroot.mount"]; | 21:14:45 |
| @hexa:lossy.network | though I would expect them to get created during activation | 21:14:48 |
| @elvishjerricco:matrix.org | That wouldn't help. If a file systems mountpoints simply vanish, then making new directories at the same path wouldn't be reviving the old mount points | 21:15:19 |
| @elvishjerricco:matrix.org | * That wouldn't help. If a file systems mountpoints simply vanish, then making new directories at the same path wouldn't be reviving the old mountpoints | 21:15:21 |
| @elvishjerricco:matrix.org | I'm just... surprised it's possible to make mountpoints vanish | 21:15:31 |
| @hexa:lossy.network | wantedby initrd.target, before sysroot.mounts => odering cycle found, skipping Local File Systems | 21:16:23 |
| @elvishjerricco:matrix.org | oh | 21:16:35 |
| @elvishjerricco:matrix.org | If you're going to come before local-fs.target, you need DefaultDependencies=no, which also means you'll need to order after the import service | 21:17:10 |
| @hexa:lossy.network | where do I set DefaultDeps=no? | 21:17:55 |
| @elvishjerricco:matrix.org | unitConfig | 21:18:12 |
| @hexa:lossy.network | ok | 21:18:15 |
| @elvishjerricco:matrix.org | the ordering cycle is because the default dependencies of a unit include After=local-fs.target, and sysroot.mount has Before=local-fs.target | 21:18:41 |
| @elvishjerricco:matrix.org | * the ordering cycle is because the default dependencies of a service include After=local-fs.target, and sysroot.mount has Before=local-fs.target | 21:18:49 |
| @elvishjerricco:matrix.org | (more reasons we need to use initrd-fs.target instead of local-fs.target...) | 21:19:49 |
| @hexa:lossy.network | cool 😄 now it starts quite early and fails | 21:19:50 |
| @elvishjerricco:matrix.org | oof | 21:19:57 |
| @hexa:lossy.network | even before luks | 21:20:00 |
| @hexa:lossy.network | so after zfs-import.target | 21:20:10 |
| @elvishjerricco:matrix.org | I don't remember if we actually pull zfs-import.target into initrd or not... Probably not? | 21:20:39 |
| @hexa:lossy.network | well the pool gets imported 😄 | 21:22:08 |
| @hexa:lossy.network | I see it happening | 21:22:12 |
| @hexa:lossy.network | and that depends on luks | 21:22:26 |
| @hexa:lossy.network | somehow | 21:22:29 |
| @elvishjerricco:matrix.org | wut | 21:22:36 |
| @hexa:lossy.network | boot.initrd.luks.devices... | 21:22:47 |
| @hexa:lossy.network | and that the resulting device is the zpool | 21:22:58 |
| @hexa:lossy.network | so somehow | 21:23:00 |
