Using the control panel to make a fresh Live-USB, I inserted an 8GB drive and quickly discovered the live-persistence limited the total size of the combined persistence files to 3328MB and it made no difference if I chose ext2 or ext3. I didn't bother with selecting fat because by default, I try to keep away from such limited file system types wherever possible and I already know there is a 2GB limit and a dirty work-around to attain 4GB.
Is there a reason for such a limitation? I am wondering if the script has 4GB as the absolute limit for creating a live-USB, minus file size of the iso file and leaving 3328MB as the closest block of 64Mb chunks available remaining for persistence files.
I may be wrong, but certainly curious to know.
topic title: Restrictions on live-persistence files?
4 posts
• Page 1 of 1
-
Posts: 19
- Joined: 09 Nov 2012
-
Posts: 1,308
- Joined: 31 Aug 2009
#2
At one time I imposed a limit on the size of the root persistence file to be smaller than the amount of RAM on the system. I looked at the persist-makefs code and the limit is still there.
You should be able to remove the RAM limit by changing one line in /usr/local/bin/persist-makefs:
I've also attached the patch as a gzipped file. It may be just as easy to edit that line by hand.
If you plan to install or remove packages then I suggest you run"remaster-live" when you are done installing/removing. This will put all of the file system changes stored in the rootfs file (or in RAM) into the squashfs file.
NOTE: Static root persistence will immediately store file system changes in the rootfs file. Dynamic root persistence stores file system changes in RAM (just like the normal LiveCD/USB) and then copies these changes to the rootfs file right before shutdown. This is done by the persist-save program which eventually calls rsync to do the copy/update. When the persist-save program was written we only had dynamic root persistence which is why I limited the size of the rootfs file to something under the total amount of RAM.
Oh yes, ideally you should save enough empty space on the LiveUSB partition to have enough room to make a new squashfs file. This is what the remaster-live program does. We automatically switch to the new squashfs file on the next reboot. If something goes horribly wrong then use the"rollback" boot parameter to go back to the orignal squashfs file. About 1 Gig could suffice but it entirely depends on how much you want to install. The average compression ration is for antiX-13.2 3:1 so 2.1 Gig of files fits in a 682 Meg squashfs file.
For maximum speed, once everything is installed, use the"toram" option and either no root persistence or only dynamic root persistence. The"toram" will copy the squashfs file into RAM. It eats up a lot of RAM and there is a wait at boot-time when the file gets read into RAM but after that , the system really flies. Of course, if you end up swapping then that would totally defeat the purpose and ruin the speed. For maximum security, disable persistence after you are done with tuning and installs. This makes it extremely difficult to make permanent changes to the system so on every reboot you get back to the same known system.
You should be able to remove the RAM limit by changing one line in /usr/local/bin/persist-makefs:
Code: Select all
--- persist-makefs.orig 2013-11-06 01:12:24.352101828 -0700
+++ persist-makefs 2013-11-06 01:14:13.882733916 -0700
@@ -540,7 +540,7 @@
TOTAL_RAM=$(ram_total)
SAFE_RAM=$(($TOTAL_RAM + $SAFETY_MARGIN))
- MAX_SIZE=$(min_of $SAFE_RAM $SAFE_AVAIL)
+ MAX_SIZE=$SAFE_AVAIL
DEVICE_TEXT=( \
"[fixed]" \
If you plan to install or remove packages then I suggest you run"remaster-live" when you are done installing/removing. This will put all of the file system changes stored in the rootfs file (or in RAM) into the squashfs file.
NOTE: Static root persistence will immediately store file system changes in the rootfs file. Dynamic root persistence stores file system changes in RAM (just like the normal LiveCD/USB) and then copies these changes to the rootfs file right before shutdown. This is done by the persist-save program which eventually calls rsync to do the copy/update. When the persist-save program was written we only had dynamic root persistence which is why I limited the size of the rootfs file to something under the total amount of RAM.
Oh yes, ideally you should save enough empty space on the LiveUSB partition to have enough room to make a new squashfs file. This is what the remaster-live program does. We automatically switch to the new squashfs file on the next reboot. If something goes horribly wrong then use the"rollback" boot parameter to go back to the orignal squashfs file. About 1 Gig could suffice but it entirely depends on how much you want to install. The average compression ration is for antiX-13.2 3:1 so 2.1 Gig of files fits in a 682 Meg squashfs file.
For maximum speed, once everything is installed, use the"toram" option and either no root persistence or only dynamic root persistence. The"toram" will copy the squashfs file into RAM. It eats up a lot of RAM and there is a wait at boot-time when the file gets read into RAM but after that , the system really flies. Of course, if you end up swapping then that would totally defeat the purpose and ruin the speed. For maximum security, disable persistence after you are done with tuning and installs. This makes it extremely difficult to make permanent changes to the system so on every reboot you get back to the same known system.
-
Posts: 19
- Joined: 09 Nov 2012
#3
Thanks BitJam.
My server has 8GB RAM and I am using the 64-bit version of antiX. I have moved to a full hard disk install and am just plumbing it in now, I basically had to because I thought I would simply roll the system back to an earlier backup to tide me over until I was ready to roll with antiX full time, but the backup was from my build prior to the latest build, which couldn't handle the hardware on my system and in doing so, I killed my other backups - oops __{{emoticon}}__
My salesman has called one of our nationwide television stations about a news article on the TV last night concerning Windows XP's end of life and what I call scare-mongering (though I won't tell them that) to get them to do buy more windows. He's trying to get them to come and interview me about the missing pieces in their article.
I had better hurry up and finish the server build then hadn't I.
My server has 8GB RAM and I am using the 64-bit version of antiX. I have moved to a full hard disk install and am just plumbing it in now, I basically had to because I thought I would simply roll the system back to an earlier backup to tide me over until I was ready to roll with antiX full time, but the backup was from my build prior to the latest build, which couldn't handle the hardware on my system and in doing so, I killed my other backups - oops __{{emoticon}}__
My salesman has called one of our nationwide television stations about a news article on the TV last night concerning Windows XP's end of life and what I call scare-mongering (though I won't tell them that) to get them to do buy more windows. He's trying to get them to come and interview me about the missing pieces in their article.
I had better hurry up and finish the server build then hadn't I.
-
jdmeaux1952jdmeaux1952Posts: 667
- Joined: 01 Nov 2013
#4
Makes me wonder if Microsoft isn't working with Intel to sell more Windows products and more higher end machines. I had to try to explain to everyone at the church that this just means Microsoft isn't going to SUPPORT Windows XP anymore, not that XP will die and leave their computer dead with no OS.pcpavnz wrote:My salesman has called one of our nationwide television stations about a news article on the TV last night concerning Windows XP's end of life and what I call scare-mongering (though I won't tell them that) to get them to do buy more windows.