Confused - off shoot from USM bug reports [Solved]

[Ed_P]

I agree, this thread was off topic in the USM bug reports thread but it is where you posted the /var/usm script. Sorry. Hopefully it's better here.

But when I later reboot and my save.dat file is created
I don't quite understand what you mean here.

Put simply, if you change a file or create one, it is added to your 'changes' file/folder. If you don't change or create it then it is not. Your 002-xorg module doesn't get added to your changes folder and in the same way, a module from your modules folder doesn't either. Please leave this thread for bug reports only. Questions should go in the thread under 'community effort'.

The procedure I mentioned there for creating a module is for use in fresh mode.

Save.dat incompasses the folders noted which include the /var/usm folder. The module you suggest creating replicates the /var/usm folder which thus gets included with the save.dat file when it is created, right?

I'm probably missing something obvious but I just don't see it. Sorry.

[brokenman]

My method is to work from fresh mode with no changes. Therefore I keep the /var/usm database files in a separate module and activate them when I need them. This technique is not appropriate when using changes because when you do a USM update, files are written to /var/usm and therefore included in your save file too. The files in the change folder would overwrite the module so you probably wouldn't notice anything different, but it kind of makes the module redundant and just extra weight.

[tome]

@Ed_P
save.dat contains only newer files than in module. If you don't create, change, overwrite any file (even with the same file) then there is no replica in save.dat. Two modules with the same names of files don't create replicas in save.dat - you (or your OS) must do it. For example (not tested) you can extract all your modules to large save.dat file and use only save.dat file (without activating modules) if you don't want have replicas.
I don't understand also what is exactly your problem. Wrong file - delete/correct it, missing file - create it (/mnt/live/memory/(images/)changes) - I use Porteus in this or similar way (little changes-ro container with my default settings and symlinks for some persistent changes).
If you don't want have database replicas - don't create database-module.
If you don't want have database in module or in save.dat file - edit usm.conf:

Code: Select all

# Storage of database files (e.g PACKAGES.TXT)
DBDIR=/mnt/your sda1-4/new-usm-database-folder

and

Code: Select all

# Where packages will be downloaded to.
STORAGE=/mnt/sda x/new-packages-folder

and you can store database on ntfs partition outside any container.

[Ed_P]

Thanks for trying to help guys, I appreciate it.

My confusion stems from running out of space and seeing what seems to be a lot of duplication of files. Files in /home/guest/ and in /mnt/live/memory/changes and in /mnt/live/memory/images/changes. It makes trying to find things confusing, knowing when you find something whether it's current, changed or save.dat'ed.

This frustration comes from working with the PlayOnLinux module and Wine. When initially activated they are HUGH!! Installing a simple Windows card game with PlayOnLinux eats up 577 MB in /home/guest/.PlayOnLinus AND in /mnt/live/memory/changes/home/guest/.PlayOnLinux. And when I try to use the make a module approach suggested for /var/usm/ the copy of the 577 MB folder to /tmp/POL/ runs out of space. Here's a few of the many:

Code: Select all

cp: failed to extend ‘/tmp/POL/home/guest/.PlayOnLinux/wineprefix/MicrosoftSpider/playonlinux.log’: No space left on device
cp: error writing ‘/tmp/POL/home/guest/.PlayOnLinux/wineprefix/MicrosoftSpider/playonlinux.cfg’: No space left on device
cp: failed to extend ‘/tmp/POL/home/guest/.PlayOnLinux/wineprefix/MicrosoftSpider/playonlinux.cfg’: No space left on device

The space problem results in Firefox loosing it's Bookmark bar and error msgs informing me it can't save passwords and other files. Similar msgs from closing spaceFM.

I've increased my save.dat file from 256 MB to 394 MB then to 512 MB but it hasn't helped. I've deleted the /var/usm/ folder which saved me 146 MB but it didn't help. I made the Wine app a 170 MB module and that didn't help either.

It takes about 1/2 hr for the PlayOnLinux to download it's Wine and other dependencies and if I don't stop the update of my save.dat file when rebooting I end up with a corrupted file.

So now you see why I am confused?

[tome]

It is not possible to use PlayOnLinux, Wine and Windows games with so little available space. You should either increase your save.dat file to ca 5 GB or more, or create new folders for large programs databases on NTFS/Fat partition (/mnt/sdax) and symlinks to it in your /home/guest/... folder (ln -s in terminal or Ctrl+Shift+Move_folder in PcManFM, SpaceFM)

[Ed_P]

Thanks tome.

I don't think the save.dat file is the device that is running out of space. I use the changes=EXIT cheatcode so nothing is written to it until I shutdown. However I do think I need to increase it's size, yet again, to support saving the PlayOnLinux 577 MB folder to it. Then when I reboot the folder will be in only one place so maybe then I can copy it to /tmp/ and make it a module.

I've considered copying it to a folder on my NTFS partition and making the module from there but was concerned I would loose the Linux file attributes and the module wouldn't work.

[fanthom]

I don't think the save.dat file is the device that is running out of space. I use the changes=EXIT cheatcode so nothing is written to it until I shutdown.

yes - 'changes=EXIT:' buffers in RAM so this is probably your limitation. Porteus allocates up to 60% of RAM for the filesystem so if you have 1GB of ram then only 660MB is available for changes. you may tweak this value with 'ramsize=' cheatcode but i would be careful with setting it higher than 90%.

please do not post bug reports if you start playing with too high value of the 'ramsize=' cheat.
use on your own risk.

Code: Select all

ramsize=some_value%

... Will let you set a custom size for the tmpfs partition
which is used as the root (/) of your live filesystem
when changes are not saved on a real filesystem
(i.e., Always Fresh mode). The default value is 60% of
available RAM memory.
Example: 'ramsize=40%'

[Ed_P]

yes - 'changes=EXIT:' buffers in RAM so this is probably your limitation. Porteus allocates up to 60% of RAM for the filesystem so if you have 1GB of ram then only 660MB is available for changes. you may tweak this value with 'ramsize=' cheatcode but i would be careful with setting it higher than 90%.

An excellent suggestion fanthom. Thank you.

I assumed it was RAM based but I also assumed it was 100% of the RAM being used.

please do not post bug reports if you start playing with too high value of the 'ramsize=' cheat.

So 150 % isn't an option?

[Ed_P]

ramsize=80% solved the problem.

Thanks fanthom.