| 28 Jan 2023 |
@elvishjerricco:matrix.org | In reply to @lily:lily.flowers I did not mean auto-magicking the value from initrd. I mean in a VM figure out the offset and build a new initrd with the number baked in Oh, well that would require IFD to read the output of the VM into a Nix expression | 22:23:01 |
@lily:lily.flowers | In reply to @lily:lily.flowers I did not mean auto-magicking the value from initrd. I mean in a VM figure out the offset and build a new initrd with the number baked in (A multi-stage test I suppose? Like the installer tests but less extreme) | 22:23:26 |
@lily:lily.flowers | In reply to @elvishjerricco:matrix.org Oh, well that would require IFD to read the output of the VM into a Nix expression Why? | 22:23:31 |
@elvishjerricco:matrix.org | builtins.readFile (runCommand "foo" {} "echo hi > $out") is technically IFD. Or, rather, the same basic internal mechanism | 22:24:06 |
@lily:lily.flowers | Nix doesn't need it. But your idea of saving it on another disk is better | 22:24:14 |
@elvishjerricco:matrix.org | oh wait | 22:24:23 |
@lily:lily.flowers | In reply to @elvishjerricco:matrix.org
builtins.readFile (runCommand "foo" {} "echo hi > $out") is technically IFD. Or, rather, the same basic internal mechanism Nix doesn't need the number in what I was offering | 22:24:28 |
@elvishjerricco:matrix.org | oh, you mean like build a whole new initrd in the vm | 22:24:39 |
@elvishjerricco:matrix.org | not build it as a nix expression | 22:24:46 |
@lily:lily.flowers | Yes | 22:24:48 |
@elvishjerricco:matrix.org | neat | 22:24:48 |
@elvishjerricco:matrix.org | I think saving it somewhere the initrd can read it would be easier though | 22:24:58 |
@lily:lily.flowers | I'm sorry for being a tad unclear 😅 | 22:25:00 |
@lily:lily.flowers | In reply to @elvishjerricco:matrix.org I think saving it somewhere the initrd can read it would be easier though It would yes. I like that idea better | 22:25:13 |
@lily:lily.flowers | * It would, yes. I like that idea better | 22:25:28 |
@elvishjerricco:matrix.org | or, realistically, we can mount the file system readonly and extract it from there. That would avoid dangers with mounting before resume | 22:25:32 |
@lily:lily.flowers | In reply to @elvishjerricco:matrix.org or, realistically, we can mount the file system readonly and extract it from there. That would avoid dangers with mounting before resume It does not. The kernel faq page for resume says that still would eat your data | 22:26:05 |
@lily:lily.flowers | Iirc | 22:26:10 |
@elvishjerricco:matrix.org | oh really? | 22:26:14 |
@elvishjerricco:matrix.org | even if you unmount it? | 22:26:16 |
@elvishjerricco:matrix.org | does just having stuff in the page cache pre-resume fuck with it? | 22:26:34 |
@elvishjerricco:matrix.org | where is that faq? | 22:27:04 |
@lily:lily.flowers | About initrd resume:
It is vital that this be done prior to remounting any filesystems (even as read-only) otherwise data may be corrupted.
At https://www.kernel.org/doc/html/latest/power/swsusp.html | 22:27:45 |
@lily:lily.flowers | In reply to @elvishjerricco:matrix.org does just having stuff in the page cache pre-resume fuck with it? Maybe. I'm not quite sure, it doesn't elaborate | 22:28:03 |
@elvishjerricco:matrix.org | Yea, that's annoying. If you're going to warn about it, you should explain it | 22:28:45 |
@elvishjerricco:matrix.org | * Yea, that's annoying. If they're going to warn about it, they should explain it | 22:28:52 |
@lily:lily.flowers | (I would hope mounting an unrelated disk that wasn't present at hibernation would be fine, but idk why it's a problem to begin with so maybe not) | 22:29:15 |
@elvishjerricco:matrix.org | An EFI variable should work, right? lol | 22:29:44 |
@lily:lily.flowers | You know, that's an even better idea | 22:30:16 |
@lily:lily.flowers | Cursed, but better | 22:30:23 |