| 28 Jan 2023 |
 @elvishjerricco:matrix.org | lol great | 22:30:38 |
| @elvishjerricco:matrix.org | I did not mean for that to be taken seriously | 22:30:44 |
| @elvishjerricco:matrix.org | but yea it might be better | 22:30:49 |
| @elvishjerricco:matrix.org | Well, the issue author created a version of the hibernate test that exhibits the issue | 22:31:33 |
| @elvishjerricco:matrix.org | they just hard coded the resume offset | 22:31:38 |
| @elvishjerricco:matrix.org | so that's fragile and we can't actually have that in nixpkgs :P | 22:31:52 |
| @elvishjerricco:matrix.org | but it helps diagnose for now | 22:31:57 |
 @lily:lily.flowers | I wonder if one of the more esoteric filesystems in the kernel allows you to either deterministically know or set a specific offset for a file | 22:32:58 |
| @elvishjerricco:matrix.org | oh | 22:33:59 |
| @elvishjerricco:matrix.org | oh no | 22:34:00 |
| @elvishjerricco:matrix.org | best bad idea yet | 22:34:03 |
| @elvishjerricco:matrix.org | networking | 22:34:06 |
| @elvishjerricco:matrix.org | the test machine tells a server machine the offset, which remembers it until initrd (using initrd networking) asks for it | 22:34:41 |
| @elvishjerricco:matrix.org | absolutely cursed | 22:34:45 |
| @lily:lily.flowers | Very cursed yeah 😆 | 22:35:17 |
| @elvishjerricco:matrix.org | Ok, I used their config and I see this:
resume # [ 0.948879] systemd[1]: Found device /dev/vda1.
resume # [ 0.949179] systemd[1]: Mounting /sysroot...
resume # [ 0.949847] systemd[1]: Starting Resume from hibernation using device /dev/vda1...
resume # [ 0.951809] systemd-hibernate-resume[115]: Could not resume from '/dev/vda1' (254:1).
| 22:37:33 |
| @elvishjerricco:matrix.org | it doesn't say why it couldn't resume, so maybe I need to enable some debug output | 22:37:48 |
| @elvishjerricco:matrix.org | but | 22:37:49 |
| @lily:lily.flowers | Wait I've got another one. What if you made a swap partition but nuked that partition from the table and set an offset relative to the previous partition | 22:37:54 |
| @elvishjerricco:matrix.org | the Mounting /sysroot thing is scary | 22:37:57 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
the Mounting /sysroot thing is scary Yes | 22:38:02 |
| @elvishjerricco:matrix.org | I mean, I've known about that ordering issue for a while | 22:38:13 |
| @elvishjerricco:matrix.org | but it hasn't actually bitten any of my testing | 22:38:19 |
| @elvishjerricco:matrix.org | maybe btrfs is smart enough to make it bite you | 22:38:28 |
| @lily:lily.flowers | In reply to @lily:lily.flowers
Wait I've got another one. What if you made a swap partition but nuked that partition from the table and set an offset relative to the previous partition (it would read in basically the same from the kernel's perspective as a swapfile, right?) | 22:38:34 |
| @elvishjerricco:matrix.org | let me see what happens if I force a proper ordering... | 22:38:56 |
| @elvishjerricco:matrix.org | In reply to @lily:lily.flowers
Wait I've got another one. What if you made a swap partition but nuked that partition from the table and set an offset relative to the previous partition oh wow | 22:39:15 |
| @elvishjerricco:matrix.org | brillian | 22:39:17 |
| @elvishjerricco:matrix.org | * brilliant | 22:39:18 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
let me see what happens if I force a proper ordering... It would be interesting to know if your branch for that fixes it. Because then they've been very lucky so far that it's failed to resume and they haven't lost data | 22:40:46 |
