Anonymous
If the system does a persist save repos get reset.
So to me the system is also not behaving as I might reasonably expect. By design or not I do not know.
Why I did not see that before, I guess because after a remaster I do not continue to do any work or play, just shutdown,
I don’t use static persistence but have learned (probably the hard way) that
yes, if performing a live-remaster operation during a dynamic persistence session,
you should shutdown the machine immediately after performing a remaster operation.
-=-
said differently:
Subsequent to the remaster operation, further same-session changes to the system will not be saved.
This detail, coaching the user to shutdown now and restart, probably should be added into the “success” messagebox (or commandline output) displayed at the end of a live-remaster operation. Additionally, this detail could be mentioned in the docs. Wait, does a standalone docs page (beyond the –help output) exist for live-remaster? Yeah, but it doesn’t exactly “get into detail”, eh /FAQ/remaster.html
In the interim In the absence of such a notice of a the end of the live-remaster operation, or perhaps as an additional “heads up”… the l-r operation should place a /tmp/flagfile which the persist-save script (applicable to dynamic perisstence only, eh) would test for on each run, and if the flagfile is present would advise “subsequent to live-remaster, cannot save further changes until the system is restarted”.
^— hmm, the additional “persist-save would check and…” is too late ~~ amounts to “salt in the wound” of any caught-by-surprise user.
Ah, the biting edge(s) of “confusingly flexible functionality”.
Confusingly (to me, at the time), back around 2016 or 2017… live-remaster was “expanded, improved”, it grew a third-leg feature offering to optionally — in advance — create the fresh persistence container(s) which will be used (immediately//automatically) upon next reboot. Typically, at the start of each liveboot session, we have the opportunity (via bootmenu or or bootline) to choose/change the type of persistence to be used during the current session -OR- we may choose to altogether forego use of persistence for the current session.
I understand (and agree) that some aspects of the status quo behavior are “surprising”, are “unexpected”. I’m not trying to defend the status quo, am merely attempting to explain the status quo behavior.
Somehow, attention to “it might be inconvenient if live-remaster _forced_ the user to immediately shutdown following its completion” apparently outweighed attention to the prospect of cofusion induced by having too many options and choices available.
if performing a live-remaster operation during a dynamic persistence session
In that (dynamic) scenario, one of the steps during the live-remaster operation is to rename ‘rootfs’ to ‘rootfs.bak’. If the user optionally elects to “create, in advance” a new persistence container, a file named ‘rootfs.new’ is created. If/when persist-save is called subsequently later in the same session, it will be unable to find a ‘rootfs’ file to, so is unable to save any changes.
In the ‘static’ scenario, I do not know whether a similar “technical limitation” exists.