q1: good question. I'm not sure if your data will survive a resize (any thoughts BitJam?)

q2: using the static persistence boot option should help.

Thanks for bringing this to my attention D.O. You continue to rock.

mello wrote:Q1: Any chance resizing persistance w/o destroying data?

Q2: Is there a better way setting-up persistance w/low-RAM?

TL;DR: Boot with static root persistence and do a live remaster.

I am delighted that someone has seen that error message.

Let me give you a bit of background. The LiveCD system normally works by storing any changes to the file system in RAM because it can't save them on the cd. When you reboot, those changes all go away. Dynamic root persistence (which is what you have been using) modifies this only slightly. Before your system shuts down, the perisist-save program writes all of your filesystem changes to a small fileystem inside the rootfs file. When you boot, those changes get copied out of the rootfs file and back into RAM. We need to be a little conservative in this step because if we use up too much RAM then bad things can happen and the system can become unusable.

You've bumped into the limit where we think it is no longer safe to copy all of your filesystem changes back into RAM.

The solution I suggest has two steps. First, enable static root persistence (in the bootloader menu). This will make things work a little differently. Instead of copying filesystem changes from the rootfs file to RAM, we mount the rootfs directly. This means there is no RAM limit and the only limit is the size of your rootfs file. File system changes get immediately stored in the rootfs file.

The only reason we don't do this all the the time is because reading and writing to usb sticks is much much slower than reading and writing to RAM so static root persistence can be unacceptably slow. But in this scenario you only need to use it once. After you've booted with static root persistence enabled, go the the RemasterCC and choose to remaster (sometimes called remaster-live). You need to be sure to do a Live remaster. This will regenerate your linuxfs file which contains a compressed version of your entire file system. This takes extra space on your LiveUSB (because there will be two copies of the large linuxfs file). It takes a lot of CPU power to compress your entire file system. But when it is done and you reboot then it resets the RAM usage (for file system changes) back to close to zero because all of those changes have been locked into the new linuxfs file.

You can then create another rootfs file to enable root persistence with this new linuxfs file. When you run out of RAM again, just rinse and repeat: boot with static root persistence and remaster again.

Generally, resizing the rootfs file is very safe but it won't be allowed if you have static root persistence enabled. But that's okay because you don't need to have persistence enabled to resize the rootfs file. But resizing the rootfs file won't solve your problem because you've run out of space in RAM, not space in the rootfs file.

It's safe to resize because we make first make the new, (usually) larger, rootfs file and then copy everything from the old file to the new file. If this works then we rename the old file rootfs.bak and the new one becomes rootfs. This is slower and consumes more resources but it is much safer than using clever tricks to actually expand the rootfs file and then expand the filesystem that lives inside of it. We try to be very careful with your data. We've chosen to do things slower and less efficiently in order to keep your data safe.

Maybe in the next version of remaster-live we could add a feature that will remaster from a rootfs file directly. This would let you avoid the step of enabling static root persistence.

Excellent BitJam, thanks for chiming in!

dolphin_oracle wrote:Excellent BitJam, thanks for chiming in!

BitJam wrote: After you've booted with static root persistence enabled, go the the RemasterCC and choose to remaster (sometimes called remaster-live). You need to be sure to do a Live remaster. This will regenerate your linuxfs file which contains a compressed version of your entire file system. This takes extra space on your LiveUSB (because there will be two copies of the large linuxfs file). It takes a lot of CPU power to compress your entire file system. But when it is done and you reboot then it resets the RAM usage (for file system changes) back to close to zero because all of those changes have been locked into the new linuxfs file.

You can then create another rootfs file to enable root persistence with this new linuxfs file. When you run out of RAM again, just rinse and repeat: boot with static root persistence and remaster again.

Generally, resizing the rootfs file is very safe but it won't be allowed if you have static root persistence enabled. .

BitJam,
Dry run of"rinse and repeat:
1)... boot w/static root persistance enabled
2a).. goto RemasterCC and click remaster-live
2b) .. data is now locked into new linuxfs
3)... create another rootfs file to enable root persistance with this newer one

When you run out of RAM again, repeat #1, #2a, #3
****************
Please translate #3 into actual mouse click events for the ignorant.
This step sounds to me that the 1GB root persistance should be resized to ~750MB.
thanks,
mello

male wrote:

dolphin_oracle wrote:Excellent BitJam, thanks for chiming in!

DITTO

mello wrote:Dry run of"rinse and repeat:
1)... boot w/static root persistance enabled
2a).. goto RemasterCC and click remaster-live
2b) .. data is now locked into new linuxfs
3)... create another rootfs file to enable root persistance with this newer one

When you run out of RAM again, repeat #1, #2a, #3
****************
Please translate #3 into actual mouse click events for the ignorant.

Navigate to the RemasterCC. Select"Enable Persistence". Select"Root: Create Root Persistence". Follow the steps. Perhaps the missing link was associating"Enable Persistence" with creating persistence files.

A slight variation is to create a new rootfs file in the same session you do the live remaster. It is just like the above except you select"New: Make rootfs.new for remastering". Do this right before or right after you do the remaster but before you reboot. This way, your use of root persistence won't be interrupted.

PLMK if you still need more info. Since you had root persistence enabled I figured you had done this before. I'd prefer not to fire up antiX-13.2 just to write down the exact mouse clicks for you. I imagine there's an app ... I mean Dolphin Oracle video for that already.

This step sounds to me that the 1GB root persistence should be resized to ~750MB.

I don't know the specs of your machine so I can't comment on actual sizes. If you make the rootfs file much smaller then you will hit an error when you try to save your changes with persist-save. It will say there is not enough room to save the changes. You will then have two choices: either do a live remaster before you shut down or lose your changes. [Well, I guess you could also go to persist-makefs ("Enable Persistence" in the RemasterCC) and enlarge the rootfs file but this will totally defeat the purpose of making it smaller to begin with!]

Getting an error message earlier is not a horrible scenario but I don't think you gain much with it. Also, with a smaller rootfs file then you can't use static root persistence to temporarily side-step the problem of running out of RAM.

BTW, the command"df -h /live/aufs-ram" should give you an early warning about when it is getting to be time to remaster. If that filesystem is starting to fill up then you can do a remaster to reset the ram usage (for file system changes) back close to zero. This will allow you to avoid the warning message at boot time.

mello wrote: d_o,
Just installed LiveUSB as you did and find that Claws Mail cannot send or receive mail. Iceweasel browser is very marginal too.

hi,

Week 2 of AntiX 13.x shakedown found this problem resurface!

Dillo trapped an error that just might get it SOLVED:

UNABLE TO RESOLVE NAMESERVER!

If nameserver=192.168.0.1, browsers cannot render URL's, I've seen on other distros.
Changing it to nameserver=8.8.8.8, resolved it before. Address 192.168.0.1 is the router gateway, which causes browsers to FAIL on other OS's.

Suspect AntiX problem is tied to nameserver . . .
Q: Can a Trace be done?
mello

BitJam wrote:I don't know the specs of your machine so I can't comment on actual sizes.

RAM is maxed 256MB.
Complete SPEC:


========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://h10025.www1.hp.com/ewfrf/wc/document?docname=bph04810&cc=us&dlc=en&lc=en&product=59943"
linktext was:" http://h10025.www1.hp.com/ewfrf/wc/doc ... uct=59943 "
====================================

Re: AntiX 13.x

hi,
The USB printer connected to AntiX has date coded ink cartridges and one has a chip code that's past end-of-life! Therefore, inorder to print, the Year must be turned back to 2013.

Q1: How can one change the system clock Year back to 2013, inorder to get a hardcopy?
A couple mouse clicks does the job on other distros.

Q2: Why doesn't AntiX have this common linux feature?

mello

Q1: How can one change the system clock Year back to 2013, inorder to get a hardcopy?

Normally this is set by the BIOS. Shut the computer down, open the back, take out the BIOS backup battery, and hey, everything is set to whenever your motherboard was made. Of course, should you have a brand new motherboard __{{emoticon}}__ __{{emoticon}}__ __{{emoticon}}__

mello wrote:Q1: How can one change the system clock Year back to 2013, inorder to get a hardcopy?

Try:

sudo date --set 2013-07-12

That's so much easier. Thanks!