Persistence/Remastering is one of the great features of Antix/MX. It is somewhat complex , so it took me a while and some experimentation to figure out how to use it most effectively. Here are my cliff notes for any newbies that are struggling with this:
I believe there are two use cases:
1. To take a snapshot of a fully loaded system, with a lot of your apps installed, data etc and put it on a usb stick , which you can then continue to use to install updates, new apps etc - just like it was on your original machine. ( This is my case).
2. To start with a downloaded ISO clean, and create your own flavor of distro. Here user data(/home) is clean and the stick will setup for a brand new user, with new acct, password etc. The focus is on the system ( not /home). ( not my case)
I will only talk about (1) here:
- At first boot,Choose persist_static ( my choice), or persist-all ( at the boot screen), and stick with that choice in future
- persist_all loads rootfs into ram and has to be saved before shutdown.
- persist_static keeps rootfs on disk, no need to save anything
- At first boot it will prompt to create rootfs and homefs, choose 4 GB for rootfs and 10+GB for homefs ( for me)
- at first boot , it will offer to copy entire /home to homefs ( approx 5GB in my system)- say YES
- Note: rootfs only saves changes to / ( excluding /home), homefs save the entire /home not just changes.
- Thats it! Every time you boot off the usb stick choose persist_* ( or choose to "save" your choice - it will show a "Custom" login)
- Remaster rolls up homefs and rootfs into linuxfs(so even without persistence enabled the system has all changes baked in)
- choose "Personal" - maintains login, password etc
-Say "YES" to "save /home" - agree to rolling up homefs(in addition to rootfs)
- create new rootfs - "Yes"
-After reboot, delete linuxfs.old, rootfs.old ( from the control panel gui)
- Note : homefs is maintained after initial creation, stays updated, never delete
- "live-usb-storage" is in /live/boot-dev, but has a bind-mount to /home/rs
- homefs ignores this, remaster ignores this
- can be used even without any persistence enabled
- use this for large data files like music , pictures etc.
- The space available in this is whatever is remaining on the usb-stick after accounting for linuxfs, rootfs, homefs ( need enough room for two copies each of linuxfs and rootfs when remastering)
Persistence/Remastering: My cliff notes
Re: Persistence/Remastering: My cliff notes
A gui suggestion to the developers:
- perhaps the boot screen options can be considerably simplified by simply asking the user to choose "persistence", or not. A simple binary choice ( and remember the previous choice). Maybe do some checks on flash drive size and give appropriate messages.
: can have a message box that says " to tweak settings go to Control Panel after login in"
- also automatically setup live-usb-storage and give a message that x GB are available ( size of flash drive - 2*linuxfs - 2*rootfs -homefs).
Then simply setup a rootfs at 4GB and a homefs at ( say) 2X the /home size , copy /home into homefs . All in the background without any user interaction. Assume persist_static. ( flash drive size is a non-issue these days, cant even buy one less than 16GB).
Remaster: Assume "Personal", assume "save /home" - no need for user interaction. User just pushes a button "Remaster".
This should work for most people .
For sophisticated users who maybe want to load rootfs into ram, not create homefs, or Remaster to not save Personal or /home etc : the Control Center can offer to do all that for them. So after login, this type of user can tweak to their hearts content.
- perhaps the boot screen options can be considerably simplified by simply asking the user to choose "persistence", or not. A simple binary choice ( and remember the previous choice). Maybe do some checks on flash drive size and give appropriate messages.
: can have a message box that says " to tweak settings go to Control Panel after login in"
- also automatically setup live-usb-storage and give a message that x GB are available ( size of flash drive - 2*linuxfs - 2*rootfs -homefs).
Then simply setup a rootfs at 4GB and a homefs at ( say) 2X the /home size , copy /home into homefs . All in the background without any user interaction. Assume persist_static. ( flash drive size is a non-issue these days, cant even buy one less than 16GB).
Remaster: Assume "Personal", assume "save /home" - no need for user interaction. User just pushes a button "Remaster".
This should work for most people .
For sophisticated users who maybe want to load rootfs into ram, not create homefs, or Remaster to not save Personal or /home etc : the Control Center can offer to do all that for them. So after login, this type of user can tweak to their hearts content.
Re: Persistence/Remastering: My cliff notes
Good info! Thanks. One correction (or maybe there is a bug in my code):
This led to a peculiarity when someone used root persistence only for a while and then added home persistence. The home persistence would mask their earlier changes under /home. I fixed this by trying to detect this situation and when it occurs offer to copy the root persistence (and even remaster) files under /home to the new home persistence file.
Root persistence does save changes under /home unless home persistence is also enabled.
This led to a peculiarity when someone used root persistence only for a while and then added home persistence. The home persistence would mask their earlier changes under /home. I fixed this by trying to detect this situation and when it occurs offer to copy the root persistence (and even remaster) files under /home to the new home persistence file.
"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
3rd use case: after installing and setting up MX the way you like it in computer no.1, you take a snapshot, write it onto a USB stick (can even be written as a read-only dd image without persistence), and then you use this live USB snapshot to install your nicely-setup system into your other computers. This is not for other users but yourself so all your user data remains.rs55 wrote: Thu Mar 28, 2019 12:29 pm Persistence/Remastering is one of the great features of Antix/MX. It is somewhat complex , so it took me a while and some experimentation to figure out how to use it most effectively. Here are my cliff notes for any newbies that are struggling with this:
I believe there are two use cases:
1. To take a snapshot of a fully loaded system, with a lot of your apps installed, data etc and put it on a usb stick , which you can then continue to use to install updates, new apps etc - just like it was on your original machine. ( This is my case).
2. To start with a downloaded ISO clean, and create your own flavor of distro. Here user data(/home) is clean and the stick will setup for a brand new user, with new acct, password etc. The focus is on the system ( not /home). ( not my case)
[snip]
Desktop: Intel i5-4460, 16GB RAM, Intel integrated graphics
Clevo N130WU-based Ultrabook: Intel i7-8550U (Kaby Lake R), 16GB RAM, Intel integrated graphics (UEFI)
ASUS X42D laptop: AMD Phenom II, 6GB RAM, Mobility Radeon HD 5400
Clevo N130WU-based Ultrabook: Intel i7-8550U (Kaby Lake R), 16GB RAM, Intel integrated graphics (UEFI)
ASUS X42D laptop: AMD Phenom II, 6GB RAM, Mobility Radeon HD 5400
Re: Persistence/Remastering: My cliff notes
Exactly! This is what I do - I am guilty of hoarding thinkpads! But this does not involve persistence/remastering - only snapshot and lum.asqwerth wrote: Thu Mar 28, 2019 1:18 pm3rd use case: after installing and setting up MX the way you like it in computer no.1, you take a snapshot, write it onto a USB stick (can even be written as a read-only dd image without persistence), and then you use this live USB snapshot to install your nicely-setup system into your other computers. This is not for other users but yourself so all your user data remains.rs55 wrote: Thu Mar 28, 2019 12:29 pm Persistence/Remastering is one of the great features of Antix/MX. It is somewhat complex , so it took me a while and some experimentation to figure out how to use it most effectively. Here are my cliff notes for any newbies that are struggling with this:
I believe there are two use cases:
1. To take a snapshot of a fully loaded system, with a lot of your apps installed, data etc and put it on a usb stick , which you can then continue to use to install updates, new apps etc - just like it was on your original machine. ( This is my case).
2. To start with a downloaded ISO clean, and create your own flavor of distro. Here user data(/home) is clean and the stick will setup for a brand new user, with new acct, password etc. The focus is on the system ( not /home). ( not my case)
[snip]
Re: Persistence/Remastering: My cliff notes
aaah - I was wondering about precisely this last night! Again- it seems to me there are two distinct use cases. For those who are starting with a downloaded iso, maybe just having root persistence is all they need?BitJam wrote: Thu Mar 28, 2019 1:07 pm Good info! Thanks. One correction (or maybe there is a bug in my code):Root persistence does save changes under /home unless home persistence is also enabled.
This led to a peculiarity when someone used root persistence only for a while and then added home persistence. The home persistence would mask their earlier changes under /home. I fixed this by trying to detect this situation and when it occurs offer to copy the root persistence (and even remaster) files under /home to the new home persistence file.
But, for most ( like me) - who are starting with a heavily modified system with a lot of apps etc - static seems best ( or _all). But why not assume _static and let users tweak later in the control center.
I was just thinking - for someone new to Antic/MX ( like me) and trying persistence for the first time, the boot choices are a bit overwhelming and requires digging into what each option really means. It would be nice to simply choose "Persistence" and let the system make some default choices - that you can then tweak later in the Control Center.
Re: Persistence/Remastering: My cliff notes
I should also mention that last night - after setting up initially as persist_static, then a few reboots later, I tried changing to persist_all at the boot screen - and got a fatal error, requiring a poweroff.
Thats why in my "cliff notes" I suggested picking one option and sticking with it.
Thats why in my "cliff notes" I suggested picking one option and sticking with it.
Re: Persistence/Remastering: My cliff notes
Sorry, I cant stop gushing about your LUM, persistence etc. Its a game changer. Why?
- Because it removes all fear of "security", viruses etc. Linux is already inherently much more secure than Windows - due to root permissions and repositories ( as opposed to downloading drivers and apps from all kinds of sites). But with a live-usb created, one can be fearless. Worst case just reinstall the whole system in 5 minutes!
And set up LuckyBackup to save all important data at every boot ( in my case its all in One file).
I mean think about all the hoohah in windows 10 with their huge updates and update-cycles and forced boots etc - ugggh. Why? Because if you catch a virus on windows or an update messes up the system - it can ruin a whole weekend - or worse.
- Because it removes all fear of "security", viruses etc. Linux is already inherently much more secure than Windows - due to root permissions and repositories ( as opposed to downloading drivers and apps from all kinds of sites). But with a live-usb created, one can be fearless. Worst case just reinstall the whole system in 5 minutes!
And set up LuckyBackup to save all important data at every boot ( in my case its all in One file).
I mean think about all the hoohah in windows 10 with their huge updates and update-cycles and forced boots etc - ugggh. Why? Because if you catch a virus on windows or an update messes up the system - it can ruin a whole weekend - or worse.
Re: Persistence/Remastering: My cliff notes
I will admit I have Windows 7 /10 as dual boot on most of my machines. Why? Becasue there are two apps that need windows - Lightroom and Mathematica.
Fortunately neither of those apps needs internet access. So I only use windows with internet connections disabled - and only if I need one of those two apps.
Most of the time I am on MX.
Fortunately neither of those apps needs internet access. So I only use windows with internet connections disabled - and only if I need one of those two apps.
Most of the time I am on MX.
Re: Persistence/Remastering: My cliff notes
When did the fatal error occur? It is most likely that you ran of RAM. With dynamic root persistence file system changes are store in RAM. They are copied from the rootfs file at startup and copied back when persist-save runs, usually at shutdown but this can be configured.rs55 wrote: Thu Mar 28, 2019 1:43 pm I should also mention that last night - after setting up initially as persist_static, then a few reboots later, I tried changing to persist_all at the boot screen - and got a fatal error, requiring a poweroff.
Thats why in my "cliff notes" I suggested picking one option and sticking with it.
So changing from dynamic (all) to static should always be safe but on systems with older usb-2, it can be slow (or dog slow with usb-1). It is only changing from static to dynamic that can be a problem. But again, I'm curious about when your problem occurred. There should be a check during the boot to refuse to copy rootfs to RAM if there is not enough room.
The solution for going from static to dynamic is to do a remaster first. This should mostly clear out the rootfs file and take the pressure off the RAM.
In general, it is of great help to us if you tell us when an error occurs (like in this case when during the boot process or if it was after the boot process) and give us some idea of what the error message is. The main reason we go to the trouble of generating error messages when things go wrong is so people can tell us what the error message is so we know where the problem occurred so we can try to fix it.
Without telling us the error message (and/or the context of when the error happened) it's like a race car driver telling their pit crew "There was something wrong with the car." Of course the pit crew wants to know what is wrong with the car, or what the funny noise is, so they can fix it.
"The first principle is that you must not fool yourself -- and you are the easiest person to fool."
-- Richard Feynman
-- Richard Feynman