Bill Allombert <ballo...@debian.org> writes: > On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote: >> On Sep 17, Russ Allbery <r...@debian.org> wrote:
>>> (I am a little confused by this wording, but I think what you're >>> saying is that /usr is encrypted and read-only, and /var is recreated >>> on each boot. That at least is my understanding of the pattern that >>> you're trying to enable.) >> The general idea is to be able to create /var on the first boot. > Does not that would break users expectation that the system image > contains /var before the first boot ? > A lot of things in /var are caches that are mostly instance-independent > and can be prefilled, but for that, users expect a minimal directory > hierarchy to be present before first boot. Not that I think we're particularly close to achieving this design currently (and to be clear we haven't decided we're working towards this yet), but while I understand why a user would have that expectation today, I'm not sure why it would practically matter. If all of that directory structure appears on first boot, and no static data is stored in /var, what use case requires the directory structure already exist in /var before the first boot? I think you're thinking of cases where the user puts data into /var and expects it to be used by the system after boot, but configuration data would go into /etc, so I'm not sure what data that would be. Also, I think that scenario would still work. My understanding of the design is that /var isn't tmpfs; while there's no precreated directory structure, the user could still make one if they wanted. There wouldn't be the guide of existing empty directories, but this is a fairly sophisticated use case, IMO. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
