Persistence/Remastering: My cliff notes

[skidoo]

why /home is treated differently

Choice of peristence, during a given bootsession, is optional.

Availability of /home during boot is mandatory.

[skidoo]

here's another recurring point of confusion, dredged from search results

http://forum.mxlinux.org/viewtopic.php?f=104&t=47082

This persistance/remaster is just totally confusing to me.

. . .

To avoid introducing confusion, the persistence setup gui begs the display of a disclaimer
PERSISTENCE WILL TAKE EFFECT WHEN YOU NEXT BOOT (AND YOU REQUEST/SPECIFY PERSISTENCE=ENABLED)
I haven't checked recently. If a disclaimer does already exist, it could stand to be more prominent.
Click to continue.
PERSISTENCE WILL TAKE EFFECT WHEN YOU NEXT BOOT (AND YOU REQUEST/SPECIFY PERSISTENCE=ENABLED)
got it.
Click to continue.
PERSISTENCE WILL TAKE EFFECT WHEN YOU NEXT BOOT (AND YOU REQUEST/SPECIFY PERSISTENCE=ENABLED)

. . .

snapshot is separate from, doesn't depend on persistence.

. . .

as [the OP's inquiry] has clearly demonstrated, the wording within the dialogbox is misleading.
The "flow" is also awkward, IIRC. Instead of displaying "OK success" then exiting after an operation has been performed,
the GUI returns to maindialog (for your convenience, in case you want to perform another operation). This looping (loopy?) behavior has caught me off-guard on multiple occasions. It leaves ya hanging, wondering, "did that change go through, or should I do it again?"

[skidoo]

@adrian
aha, not found in mxforum search results b/c the post I had in mind was from antixforum

antixforum...topic/improvements-and-looks

Recurring posts to both the MX and antiX forums have mentioned new user confusion regarding available persistence settings.
A “more thorough” description for each option would be helpful but character count is limited within the liveboot F1 help screens (no scrollbar, so ability to scroll to read long texts isn’t visually obvious). Wording in some of the status quo terse descriptions is misleading / inexact / inaccurate and certainly invites confusion, e.g.:

persist_root …. Fast. Only saves root

root user? root filesystem? Changes to files pathed under /home are NOT preserved???

In this case, the terse description is attempting to emphasize the fact that “only” a rootfs save file is created/used. Problem: at this point in his/her reading, the user likely doesn’t need to know, or care, whether or not “only a single savefile” will be utilized. In other words, drowning the user in unnecessary details.

Maybe a fresh pair of eyes reading this “improvements” topic can suggest brilliant wording for these terse descriptions. In the meantime, I’ll suggest that the names themselves could be changed. “persist_all” could become “persist_dual” (emphsizing dual savefiles), leaving that label available for what is currently described as persist_root…

(SMOOSHED to fit 80char line width)
persist_all ….. Fast(Uses RAM) At shutdown, saves all rootfilesystem changes

.
ref: Gfxboot :: Help/antiX/en.html

[Adrian]

Thanks for the info, like I said, not a user of persistency, didn't even know that there's a persist_all already. I understand now slightly more. In a way it's better because I see this with the eye of a newbie (or closer anyway)

persist_static -- would not be better name presist_dynamic because everything is saved as you go? Static is a bit of strange attribute here. Or even better, persist_disk (vs. persist_ram) -- that would make things clearer, it responds to a question "Where do you save persistency" while if you use "static" the question is "How you do persistency?" and "static" response is confusing, what does "static" exactly mean for a random newbie who doesn't speak the lingo?

Just throwing things around feel free to ignore me...

[rs55]

I'll go one step further:
- The average user , who set up his system , then made a live usb, then wants to use that usb in a persistent mode. For this user it makes no sense to not persist everything ( "root" and home). In fact he will get a nasty shock if he uses persist-root and discovers that his entire home folder has been wiped clean ( happened to me!). The choices that make sense for this user are:
- Want to lock your system files from changes? ( ie. persist_home ?)
- Want to use ram for better speed? (This will require you to save changes before rebooting)
Thats it. Two simple choices.
*And the system should silently copy the existing /home into homefs - period. To do otherwise is overwriting the user's precious files.

Then there is the user who is starting with a downloaded iso and wants to tweak it persistently. The choices for such a user are:
- Want to preserve changes to /home? ( I dont think any of the current choices allow this - since persist_root also persists the /home folder). But such a user may well want a clean /home to distribute to friends .
- Want to use ram for better speed?

[fehlix]

- The average user , who set up his system , then made a live usb, then wants to use that usb in a persistent mode. For this user it makes no sense to not persist everything ( "root" and home).
...
The choices that make sense for this user are:
- Want to lock your system files from changes? ( ie. persist_home ?)

Thats might be a good "default", but you missed the point that a user wants / needs to start without persistence in order to recover/copy from his existing home/root-persist-files some files and settings into a new home/root-persist file.

In fact he will get a nasty shock if he uses persist-root and discovers that his entire home folder has been wiped clean ( happened to me!).

You can study the wiki or ask here to avoid such shocks. Boot parameter are explained in the wiki https://mxlinux.org/wiki/system/boot-parameters/

- Want to use ram for better speed? (This will require you to save changes before rebooting)

The toram option has nothing todo with save changes when shutting down or reboot:

Code: Select all

toram .................. Copy the compressed file system to RAM. 

EDIT: But the persist_root(=root_dynamic) has. So this is probably meant. And speeds up for slow USB.

Then there is the user who is starting with a downloaded iso and wants to tweak it persistently.

That's a sub-optimal idea to store such big downloaded files within the persistence-file.
You have within the users home a "LiveUSB-Storage" folder, which is symlinked
outside of the homefs-persistence to a folder on the USB stick saving files directly onto the usb-stick.

The choices for such a user are:
- Want to preserve changes to /home? ( I dont think any of the current choices allow this - since persist_root also persists the /home folder). But such a user may well want a clean /home to distribute to friends .
- Want to use ram for better speed?

persist_root does not deal with home-persistence.
Suggest you read the description in the wiki and in the BIOS-bootmenu LiveHelp presented above by skidoo.
Here the help part as text file (instead a text-picture):

F5: Persistence Options

off ............. No Persistence/No frugal
persist_all ..... Fast. Saves root and home (uses RAM, saves at shutdown)
persist_root .... Fast. Only saves root (uses RAM, saves at shutdown)
persist_static .. Slow. Saves root and home (no RAM use, saves constantly)
persist_home .... Only home persistence

frugal_persist .. Frugal with both root and home persistence
frugal_root ..... Frugal with only root persistence
frugal_static ... Frugal with home and static root persistence
frugal_home ..... Frugal with only home persistence
frugal_only ..... Only Frugal, no persistence

Frugal

Copy files from the install media (LiveCD/USB) to an internal hard
drive partition and finish booting from that. Think of this as a
to-disk analogy of toram boot parameter.

Root Persist

Save all the changes to the file-system in RAM and then transfer these
changes to disk right before you shutdown or reboot. Fast, but space is
limited by how much RAM you have.

Static Root

Saves all your file-system changes directly to a file. This can be slow
but it requires no extra RAM and no changes need to be transfered when
you shutdown.

Home Persist

Only save changes to files and directories under /home. This will
include all of your bookmarks and personal settings. Changes are stored
immediately and speed is almost never an issue.

HTH

[skidoo]

person A sez

if he uses persist-root and discovers that his entire home folder has been wiped clean ( happened to me!).

person B sez

persist_root does not deal with home-persistence.

person C helptext sez

Code: Select all

persist_root ... Fast. Only saves root (uses RAM, saves at shutdown)

Has MX persistence labeling, and behavior, diverged from that of antiX?
Headscratching because, as a "person D" currently typing from an antiX liveboot persistence session, I can attest:

• the label for the currently-selected LegacyBIOS bootmenu option is "persist_root"

• conky (via /usr/local/bin/persist-enabled) shows "Persist Root Enabled"

• cat /proc/cmdline ------} vga=794 persist_root tz=America/New_York disable=lx

• homefs absolutely does not exist on this pendrive, never has

• changes to files pathed under /home absolutely are preserved within the rootfs, via persist-save operation

A rising tide lifts all ships?
To the contrary, we're all suffering under the constraints imposed by attempting to squeeze
(in order to avoid linewrap) overly-terse text into an 80 char helptext delivery component
~~ intended (back in the day, and still) to accommodate low-res displays.

Code: Select all

name of persistence optionA
description of persistence optionA

name of persistence optionB
description of persistence optionB

Yay! with description on its own line, it could more correctly explain:
persist_root
Fast. Only stores to rootfs (uses RAM, saved at shutdown, or on-demand) 70 chars

[skidoo]

person A sez

if he uses persist-root and discovers that his entire home folder has been wiped clean ( happened to me!).

I wonder if that's truly what happened.
As I mentioned earlier, we can choose on a per-session basis which persistence type to use. I suspect your homefs content may have been right where it belongs, and would have been loaded right back into place the next time you once again chose to enable "home_persist" or "persist_all".

You (or I) might retest to confirm or refute:
When homefs is activated, its overlay (the content within its overlay) masks any /home* content contained within the rootfs.
Although I may be mis-remembering which masks which...
I surely can't recall finding that my "home folder had been wiped clean" permanently.
( if that had happened during betatesting, surely I would have made a note on my clipboard... and filed a report )