| 11 Oct 2024 |
 mjm | to fix up any permissions | 04:28:20 |
 ElvishJerricco | In reply to @mjm:midna.dev
seems like it could happen after all the mounts are done yea, I think so | 04:28:31 |
| ElvishJerricco | I might review the problem tomorrow | 04:29:29 |
| ElvishJerricco | I've never used this thing | 04:29:36 |
| mjm | i just started trying to use it the other day | 04:29:49 |
| mjm | it still feels like an improvement over impermanence tbh | 04:30:01 |
| mjm | easier to reason about | 04:30:17 |
| ElvishJerricco | how so? | 04:30:37 |
| ElvishJerricco | is the API simpler or something? | 04:30:44 |
| ElvishJerricco | or is it just that it's using normal systemd tools? | 04:30:52 |
 emily | IIRC impermanence doesn't work with userborn OOTB | 04:31:02 |
| emily | and depends on activation scripts | 04:31:09 |
| emily | so doing it systemd-natively seems like the correct approach | 04:31:33 |
| emily | https://willibutz.github.io/preservation/impermanence-comparison.html | 04:31:39 |
| mjm | it's just normal systemd. no activation scripts, no automatic persisting of existing files, no using services to bind mount files for some reason instead of just using mounts | 04:32:35 |
| mjm | there just seem to be less weird surprises for the most part | 04:33:42 |
| mjm | the API is almost the same | 04:34:20 |
| ElvishJerricco | yea, I think it just has the relationship between file systems and tmpfiles wrong | 04:34:27 |
| ElvishJerricco | other than that, it all sounds good | 04:34:31 |
| mjm | mhm | 04:35:47 |
 Willi Butz | In reply to @elvishjerricco:matrix.org
yea, I think it just has the relationship between file systems and tmpfiles wrong Just saw the discussion here after responding on the issue.
So tmpfiles is currently used to populate the persistent fs before bind mounts (via mount units) are set up, and as was stated here before that is done to have targets with correct permissions for the bindmounts and symlinks from the volatile root.
This comes with its own issue of not being able to use tmpfiles inside mounts created by preservation. In TODO.md of the repo I describe both a workaround (for stage-2) and a proposed solution for this | 08:59:36 |
| Willi Butz | @elvishjerricco:matrix.org: can you elaborate on how you'd imagine using toplevel fileSystems / fstab? | 09:06:28 |
| Willi Butz | my goal is to see if having an impermanence-like abstraction, that simply configures existing services (tmpfiles rules + mount units) rather than creating custom scripts, is viable. I'm very much interested to know if there is something wrong / that can be improved so that at some point such an abstraction could be provided directly from nixpkgs | 09:19:45 |
| ElvishJerricco | Willi Butz: So is the goal to have it automatically create the bind mount source directories? i.e. If there should be /persist/foo bind mounted to /foo, you want tmpfiles to automatically create /persist/foo? | 18:02:38 |
| ElvishJerricco | Because yea, I suppose that would have to happen before the bind mounts. I don't personally consider that a critical use case; I don't think it's too much to ask for the source directories to be manually created beforehand. But if that's important to you, then yea, I think you would need to do some trickery. I'm thinking you could create a separate tmpfiles service that isn't ordered after local-fs / initrd-fs. Though again, this is assuming you need to have /persist/foo automatically created. | 18:05:51 |
| emily | I assume yes precisely because / is a tmpfs | 18:05:54 |
| emily | so there cannot be any /persist at boot | 18:05:59 |
| emily | or it wouldn't be very impermanent | 18:06:04 |
| ElvishJerricco | emily: well that's not the issue in that case | 18:06:13 |
| emily | you can't "manually create them" when you have no root filesystem | 18:06:17 |
