Sorry - here it is: ( this works perfectly with persistence_static): With persistence_all this is the error message:
Error: mount: mounting overlay on /live/aufs failed: No data availbale
Fatal Error
Could not mount overlayfs
- I did a remaster last night, the rootfs file is only filled to 20MB or so.
Persistence/Remastering: My cliff notes
Re: Persistence/Remastering: My cliff notes
I've added it to my list. Thank you for the detailed error message and the explanation of the circumstances. That helps me a lot!rs55 wrote: Thu Mar 28, 2019 3:29 pm Sorry - here it is: ( this works perfectly with persistence_static): With persistence_all this is the error message:
Error: mount: mounting overlay on /live/aufs failed: No data availbale
Fatal Error
Could not mount overlayfs
- I did a remaster last night, the rootfs file is only filled to 20MB or so.
"The first principle is that you must not fool yourself -- and you are the easiest person to fool."
-- Richard Feynman
-- Richard Feynman
Re: Persistence/Remastering: My cliff notes
rs55, by searching past topics (persistence, title only) you'll discover quite a range of "use cases".
My own usage f'rinstance is wide of the mark, compared the the usage described in your cliff notes.
My default usage (infrequently I will select other, for a given boot session) is:
persist_root (which is arguably a misnomer, b/c that mode also captures changes to files pathed under /home)
+ semi-automatic save mode
+ toram
+ no automount, plus elevated permission required to mount attached drives
To me, the perceived benefits of the above are:
tinhat secure,
"read/write speeds" in the realm of Gb/sec,
reduced drive wear, reduced power consumption,
and risk-free ability to continually install and test-drive various software, tweak/break stuff, then discard and reboot to a known-good system.
Although I admire LuckyBackup (and similar), I can't recall the last time used it.
Insert a secondary pendrive, run live-usb-maker. 2min 10sec later (or so) ~~ voilà!
Also, I periodically create, and offload for archiving, a dated/labeled copy of the rootfs.
Recurring, redundant, backup of files related to select projects is handled via set-n-forget rsync to external drive scripts.
Yeah, during first-run, the selection of of boot options, including persistence permutations, can be daunting. Having witnessed the progression of changes across antiX and MX version releases I do believe the (LegacyBIOS) bootscreen presentation is now well-honed, as is the "upon first request" persistence activation and setup walkthrough script during boot. I'm really leary of the proposal to attempt streamlining (onboarding?) by introducing further "assumptions" into the setup workflow.
My own usage f'rinstance is wide of the mark, compared the the usage described in your cliff notes.
My default usage (infrequently I will select other, for a given boot session) is:
persist_root (which is arguably a misnomer, b/c that mode also captures changes to files pathed under /home)
+ semi-automatic save mode
+ toram
+ no automount, plus elevated permission required to mount attached drives
To me, the perceived benefits of the above are:
tinhat secure,
"read/write speeds" in the realm of Gb/sec,
reduced drive wear, reduced power consumption,
and risk-free ability to continually install and test-drive various software, tweak/break stuff, then discard and reboot to a known-good system.
Although I admire LuckyBackup (and similar), I can't recall the last time used it.
Insert a secondary pendrive, run live-usb-maker. 2min 10sec later (or so) ~~ voilà!
Also, I periodically create, and offload for archiving, a dated/labeled copy of the rootfs.
Recurring, redundant, backup of files related to select projects is handled via set-n-forget rsync to external drive scripts.
Yeah, during first-run, the selection of of boot options, including persistence permutations, can be daunting. Having witnessed the progression of changes across antiX and MX version releases I do believe the (LegacyBIOS) bootscreen presentation is now well-honed, as is the "upon first request" persistence activation and setup walkthrough script during boot. I'm really leary of the proposal to attempt streamlining (onboarding?) by introducing further "assumptions" into the setup workflow.
Re: Persistence/Remastering: My cliff notes
...Root persistence does save changes under /home unless home persistence is also enabled.
Sometimes the hardest things for programmers is to find appropriate names for things, as people say:persist_root (which is arguably a misnomer, b/c that mode also captures changes to files pathed under /home)
I wonder if there's an alternative like "persist_all" that might be a more obvious choice for users (which comes with its own set of problems if indeed is not doing that). Maybe we need to think like users "what do I want to preserve" - only /home or all changes, or only system changes? So maybe have these choices:There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
- persist_all
- persist_home
and I guess if only system changes are desired "persist_system", not sure. Or even compose the command like "-persist_all -disable_persist_home" to be explicit.
That might also give a clue to people that if they already do persist_all they probably don't need to enable persist_home that would hide whatever they had in /home. I'm not a user of persistency, for my needs I usually just use remaster (it takes a minute with LZ4 so it's fast enough for me to save my changes this way -- BTW there's an extra step in GUI that kind of annoys me when it detects an old remaster, I think it asks you if you want to deal with it or exit, it should just give you the options how to deal with it and one option should be the exit one, but this is a very minor issue) so I am not even sure what would be the most common use cases, like for example if it even makes sense to enable persist_home if you enabled persist_root (persist_all as I would call it).
Re: Persistence/Remastering: My cliff notes
Thanks, that is interesting. I can see that those are good options to try out changes to the system. In my case: toram is a non-starter because my linuxfs is 8GB ! persist_root likewise does'nt work because I have a 5GB /home that has all my app related stuff-.config etc. and I dont want that overwritten by a clean new /home !skidoo wrote: Fri Mar 29, 2019 2:30 am rs55, by searching past topics (persistence, title only) you'll discover quite a range of "use cases".
My own usage f'rinstance is wide of the mark, compared the the usage described in your cliff notes.
My default usage (infrequently I will select other, for a given boot session) is:
persist_root (which is arguably a misnomer, b/c that mode also captures changes to files pathed under /home)
+ semi-automatic save mode
+ toram
+ no automount, plus elevated permission required to mount attached drives
To me, the perceived benefits of the above are:
tinhat secure,
"read/write speeds" in the realm of Gb/sec,
reduced drive wear, reduced power consumption,
and risk-free ability to continually install and test-drive various software, tweak/break stuff, then discard and reboot to a known-good system.
Although I admire LuckyBackup (and similar), I can't recall the last time used it.
Insert a secondary pendrive, run live-usb-maker. 2min 10sec later (or so) ~~ voilà!
Also, I periodically create, and offload for archiving, a dated/labeled copy of the rootfs.
Recurring, redundant, backup of files related to select projects is handled via set-n-forget rsync to external drive scripts.
Yeah, during first-run, the selection of of boot options, including persistence permutations, can be daunting. Having witnessed the progression of changes across antiX and MX version releases I do believe the (LegacyBIOS) bootscreen presentation is now well-honed, as is the "upon first request" persistence activation and setup walkthrough script during boot. I'm really leary of the proposal to attempt streamlining (onboarding?) by introducing further "assumptions" into the setup workflow.
So- there are indeed widely different use cases.
Re: Persistence/Remastering: My cliff notes
I thought I had posted suggestion for the labeling during MX18 betatesting topic, but a forum search today isn't finding that.I wonder if there's an alternative like "persist_all" that might be a more obvious choice for users
Here's a near-miss from the search results:
oh, and skimming the search results reminded me of this (related) source of potential confusion:http://forum.mxlinux.org/viewtopic.php?f=104&t=40255
Perhaps "static", in the context of persistence phraseology, is an unintuitive term.the terms "dynamic" and "static"
Howabout "immediate", would that be a more intuitive label than "static"?
(too many characters, bloats the width of the F5 selectbox...
Nowadays, the casper mechanism (depending on which version of which distro) supports optional use of same-partition persist file, IIRC. Still, the overlap (er, the reuse of the vaguely-defined term "persistence") begs confusion.Maybe you've been exposed to one or more various distros which utilize the "casper" persistence mechanism which demands use of a separate persistence partition and/or a predefined label (persistence, persistent). FYI, the antiX/MX mechanism doesn't need a separate persistence partition.
I still occationally lose sleep over the term "cloning"Sometimes the hardest things for programmers is to find appropriate names for
(seen in live-usb-maker, right above/alongside "dd mode and a side order of frobnik, w/ optional flavorburst")
It is very dark. I may be eaten by a grue.
Re: Persistence/Remastering: My cliff notes
Perhaps you haven't yet discovered how to leverage the antiX/MX "Live-USB-Storage" directory.[ must ruleout suchandsuch because ]
I have a 5GB /home
It provides an additional storage location and its content resides outside the (home|root)fs file.
related note:
The toram and "Live-USB-Storage" features aren't intrinsically mutually-exclusive...
but toram+eject (my preference, when feasible) does rule out using "Live-USB-Storage".
^--- Earlier I mentioned "tinhat", but neglected to explain:
I'm in a lightning-prone area & have twice encountered hardware damage due to indirect lightning strikes.
Re: Persistence/Remastering: My cliff notes
The reason my /home is 5GB is not because I have dumped a bunch of video or music or photo files in there. Nope. I agree that live-usb-storage is the place for that kind of stuff.skidoo wrote: Fri Mar 29, 2019 1:17 pmPerhaps you haven't yet discovered how to leverage the antiX/MX "Live-USB-Storage" directory.[ must ruleout suchandsuch because ]
I have a 5GB /home
It provides an additional storage location and its content resides outside the (home|root)fs file.
related note:
The toram and "Live-USB-Storage" features aren't intrinsically mutually-exclusive...
but toram+eject (my preference, when feasible) does rule out using "Live-USB-Storage".
^--- Earlier I mentioned "tinhat", but neglected to explain:
I'm in a lightning-prone area & have twice encountered hardware damage due to indirect lightning strikes.
Its because I installed Anaconda and R-Studio. Also Google-chrome installs over a gig of cache, config files etc in /home. Those , unfortunately install all kinds of files in the home folder. These are executables and config files and such. And I have'nt figured out how to get those to install elsewhere without causing permission issues in linux.
Re: Persistence/Remastering: My cliff notes
So - for me - there is not much distinction between "root" and "home". My installed apps are in both locations and if I overlaid a clean /home , for instance, on my system - I would lose access to all my important apps. I found it confusing that while normally , root, ie, the / partition contains everything, in persistence ,"root" has a different meaning.( / minus /home).rs55 wrote: Fri Mar 29, 2019 1:32 pmThe reason my /home is 5GB is not because I have dumped a bunch of video or music or photo files in there. Nope. I agree that live-usb-storage is the place for that kind of stuff.skidoo wrote: Fri Mar 29, 2019 1:17 pmPerhaps you haven't yet discovered how to leverage the antiX/MX "Live-USB-Storage" directory.[ must ruleout suchandsuch because ]
I have a 5GB /home
It provides an additional storage location and its content resides outside the (home|root)fs file.
related note:
The toram and "Live-USB-Storage" features aren't intrinsically mutually-exclusive...
but toram+eject (my preference, when feasible) does rule out using "Live-USB-Storage".
^--- Earlier I mentioned "tinhat", but neglected to explain:
I'm in a lightning-prone area & have twice encountered hardware damage due to indirect lightning strikes.
Its because I installed Anaconda and R-Studio. Also Google-chrome installs over a gig of cache, config files etc in /home. Those , unfortunately install all kinds of files in the home folder. These are executables and config files and such. And I have'nt figured out how to get those to install elsewhere without causing permission issues in linux.
Re: Persistence/Remastering: My cliff notes
I also dont understand why /home is treated differently to root. Why rootfs is capturing Changes, while homefs is not( homefs is the whole /home folder , not just changes).
In my case, ideally, I would just like to persist the whole thing , ie. the / folder. And maybe have a deltafs that captures changes to anything in / .
In my case, ideally, I would just like to persist the whole thing , ie. the / folder. And maybe have a deltafs that captures changes to anything in / .