We need to get some feedback about running live persistence (and remastering) in MX-14. We'll stick to running it live from usb at the moment, but it also works (and IMO it works better) as a frugal install to hard drive.
Running from an installed MX-14-beta2 or live from cd/dvd/usb/frugal
1. Plugin the usb device you want to run MX-14 live with persistence on.
2. Thunar will automatically mount the device. Unmount it in Thunar (just clicking the pop up doesn't work)
3. Run the live-usb application
4. Find the MX-14-beta2.iso, use full disk (4GB is more than enough though), choose FAT or ext2. DO NOT CHOOSE GRUB!
Click on persistence options and keep to default (for testing) for root and home.
5. Once finished, reboot
6. At usb boot menu screen choose root persistence
7. You will be prompted for a new root and user password
8. In desktop, use the meta-installer to install a couple of apps eg Clementine, minitube (nothing too big)
9. DO NOT REBOT FROM THE MENU. For changes to save on next boot, you MUST run the Remastercc application -> Save root persistence.
10. Once that has finished, reboot as usual and again choose root persistence in the menu.
11. You should now have the apps you installed in 8 in the menu.
Testing live persistence
- anticapitalista
- Developer
- Posts: 4285
- Joined: Sat Jul 15, 2006 10:40 am
Testing live persistence
anticapitalista
Reg. linux user #395339.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - lean and mean.
https://antixlinux.com
Reg. linux user #395339.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - lean and mean.
https://antixlinux.com
Re: Testing live persistence
Yes Sir, this works. It even remembered my wireless password. Installed Clementine and it was there at next boot.
I take it I could have set a gig or more persistence and it would have had much more room? I just used the defaults.
Good job!
I take it I could have set a gig or more persistence and it would have had much more room? I just used the defaults.
Good job!
Re: Testing live persistence
That is really, really cool. Installed to 16G flash drive, used metapackage-installer for chromium, qBittorrent, minitube...all working as advertised. Could have install a lot more...
Do I need to always run the RemasterCC app to save all state (browser changes, blah blah), or just to save the installed apps?
Do I need to always run the RemasterCC app to save all state (browser changes, blah blah), or just to save the installed apps?
Asus Prime X570-Pro | AMD Ryzen 7 3700X
16 Gig DDR4 3600 | Radeon RX 5600 XT Graphics
Samsung 860 500GB SSDs (2)
Re: Testing live persistence
The answer is a little tricky. There are 3 different answers depending on how you do things.KBD wrote: I take it I could have set a gig or more persistence and it would have had much more room? I just used the defaults.
Dynamic Persistence
With normal (dynamic) persistence, filesystem changes are stored in RAM. When persist-save is run these changes in RAM get copied to the rootfs persistence file. When you boot with persistence enabled, the changes saved in the rootfs file get copied back to RAM. In this mode the amount of free RAM you have will affect the maximize size of the file system changes that can be stored. If you only use this mode then it makes no sense to have the rootfs persistence file any larger than your RAM (minus what RAM you need for the system). There are two upsides to this approach: 1) it is very fast, and 2) it reduces wear if you are saving the rootfs persistence file on a flash drive or flash usb stick or card.
Static Persistence
In this mode (accessible via the bootloader menu) file system changes are stored directly in the rootfs persistence file. No extra RAM is used. Here, the size of the changes are only limited by the size of the rootfs persistence file. The downside is that it can be a lot slower and it cause more wear on the device that holds the rootfs persistence file. You get to choose static versus dynamic every time you boot. So one approach is to normally use the fast Dynamic Persistence but when you know you are going to do a system upgrade or a bunch of installs then boot into the Static Persistence mode.
Live Remaster (via the RemasterCC)
Live remaster takes all the file system changes whether persistence is enabled or not (and regardless of which type of persistence is enabled) and creates a new squashfs file (called linuxfs.new) that combines all the changes with the existing squashfs file. Since you are compressing the entire file system this can take a little while and max out your CPU(s) while it is running. Also you need enough space on the persistence device to hold the new squashfs file as well as the existing one. The next time you boot the new squashfs file will be used automatically. You can use the "noremaster" boot parameter to keep this from happening. After you boot with the new squashfs file you can use the "rollback" boot parameter to go back to using the original squashfs file.
The great benefit of a Live Remaster is that it frees up the RAM that was being used to hold filesystem changes. If you used Static Persistence to do a system upgrade then you should really do a remaster-live so that you can go back to using Dynamic Persistence or even no persistence at all. But you don't need to enable persistence in order to do a Live Remaster. For example, you can just use it to make a LiveUSB (or LiveHD (frugal)) that has the programs *you* want on it. Although if you want to install a bunch of things in one go then you might need to use Static Persistence until you do the remaster-live so the size of your changes is not limited by your RAM.
Re: Testing live persistence
To save installed apps you need to use either root persistence (either Dynamic or Static) or RemasterCC. My comment above explains this in more detail.pcallahan80 wrote:Do I need to always run the RemasterCC app to save all state (browser changes, blah blah), or just to save the installed apps?
If you just want to save user preferences and bookmarks and such then any of the above will work and you also have the option of using Home Persistence. This only comes in one form which is similar to Static Root Persistence in that changes are saved immediately to disk and are not stored in RAM. Home Persistence is not fancy. We just mount the homefs persistence file at /home. This is just like mounting a partition at /home but we only use a single file (called homefs) to hold the filesystem instead of an entire partition.
If you want to download a lot of iso files or a lot of movies on your LiveUSB then you should really use Home Persistence and store all of the big files under the /home directory (usually under your own home directory). Otherwise you will run out of RAM.
Summary
- If you want to store large files use Home Persistence.
- If you want to install a few small packages you can just use RemasterCC without using persistence.
- If you want to track system changes every time you boot then you need to use either Dynamic or Static Root Persistence.
- Use Static Persistence if you want to install a lot of packages and/or if you don't have much free RAM.
- Use Dynamic Persistence if you want the system to be very fast and are not installing a bunch of packages.
- Finally, use RemasterCC to reset your RAM usage (for filesystem storage) back to near zero. You can do this with or without Root or Home Persistence.
Re: Testing live persistence
@BitJam, you're the best! This is a great explanation...and a very cool implementation. We could use both of your posts as documentation 'whole-cloth'...no editing required.
Asus Prime X570-Pro | AMD Ryzen 7 3700X
16 Gig DDR4 3600 | Radeon RX 5600 XT Graphics
Samsung 860 500GB SSDs (2)
Re: Testing live persistence
I agree. +1pcallahan80 wrote:@BitJam, you're the best! This is a great explanation...and a very cool implementation. We could use both of your posts as documentation 'whole-cloth'...no editing required.
Green Comet
Space particles.
Space particles.
Re: Testing live persistence
Yes, we need to add that in manual in the remastering section. Very cool, I didn't even know it can all these options.
Re: Testing live persistence
Yes indeed, and thanks BitJam!
Re: Testing live persistence
If someone could make it so, that would be great. Forum posts tend to get buried and lost over time. There is also this detailed LiveUSB guide but some if it needs to be updated. For example it doesn't mention Static Root Persistence. Part of it was a guide to implement user programs which have already been created. There are some nice html tables on that page but they don't include Static Root Persistence.pcallahan80 wrote:This is a great explanation...and a very cool implementation. We could use both of your posts as documentation 'whole-cloth'...no editing required.
There are many more options in addition to the ones I gave above. For example you can use persistence even when you boot from a LiveCD by simply putting the persistence files on a read-write partition somewhere. You can specify this partition with the pdev= plabel= or puuid= boot parameters. Or you can specify the device more generally by adding either "usb" or "hd" to the persist= boot parameter. But when the device we are booting from is read-only and just general persistence was specified (for example via the persistence entries in the main bootloader menu) then we will automatically look for the persistence files on a device with the label "MX-14-Persist". This way, you can have persistence on with a stock LiveCD and you don't have type in any boot parameters, just make a main menu selection!
There is also a somewhat comprehensive, somewhat outdated list of Live boot options. Although it is probably best not to overwhelm users up front with all the possible options. Best to keep it simple, at least at first.
If someone does want to document this, they should feel free to PM me and I will glad to let them know what the ground truth is (or is supposed to be) for the MX-14 release. I've been on vacation but now I feel it is time for me to help with the push to get MX-14 out the door (and fix a few remaining bugs before the final release).