FossaPup64 virtualbox VM had 5gb hard drive then suddenly out of space

[Megafrog]

I installed FossaPup64 in a Virtualbox VM. To be clear, this is not running off the iso but rather a virtual 5gb hard drive where I have previously saved text files and installed Firefox. I saw there was plenty of space left on the virtual hard drive, and I shut down the VM repeatedly after using it as if I were shutting down a hardware computer to zero power (not freezing the state of the VM).

As I had before in the VM I wanted to save some notes in a text file. Suddenly it told me I could not save with this message:

"Error writing to file: no space left on device. The file on disk may be truncated."
[Edit: whenever it boots from scratch it says this message: Error saving pinboard /root/Choices/ROX-Filer/-PuppyPin: No space left on device ]

Somewhere between my fresh install and shortly after the installation of Firefox the virtual hard drive was made to believe it was so full I could not save a tiny bit of text into a text file. I gave it a 5gb virtual hard drive, imagining this was a lavish amount of space for what I had intended. What is happening?

[rockedge]

It feels like some cache or log file is/has grown. Definitely clear the browser cache completely. You can perhaps use the GDmap graphical disk storage mapper to see what is using the storage.

There is something not quite right going on. No way should the 5 gig drive be full.

What is happening to the VM's RAM? Have yo installed anything? What are you working with?

[williams2]

Are you absolutely sure that the VM hard drive is 5GB?
Puppy seems to be running as if the VM hard drive is 5MB.

df -h should show the size of each file system.

This lists the largest files in my save layer: du -h /initrd/pup_rw/ | sort -h

[Megafrog]

Williams2: Putting "df -h" in the console shows that unionfs is using 4.9gb of the 5gb virtual hard drive That is a lot - especially since I can't even find unionfs in the file manager. I don't even know what unionfs is but a quick web search says its a utility to merge files together. 4.9GB is a LOT of files that I can't seem to find in the VM!

Rockedge: I don't know a lot about checking the VM's RAM other than to know I assigned it just 1gb of virtual RAM and that my actual hardware has 4gb RAM. The only thing I installed was Firefox.

Thank you for the responses. I hope we can solve the mystery.

[Phoenix]

unionfs is not a real filesystem, it's actually just the name. The actual filesystem is aufs, advanced union filesystem which incidentally was rejected for merging into mainline, due to 'unreadability'.

The 'unionfs' its name is set to the size of the savefile, OR one half of RAM if no save. Of course this means if you created a 1MB savefile puppy will act as if there is 1MB of freespace, and 4999MB of free space on the actual hard disk. (Well if we're being accurate to what computers are like, thats 5GiB subtract 1MiB)
This space could be even further reduced or be unusable at all due to journaling, which sets aside some space. This technique helps keep the filesystem 'transactional' in that it can be easily rolled back from unanticipated circumstances.
Most likely you just set your savefile too small.
Also what is the size of unionfs?

[Megafrog]

Phoenix, the "df -h" shows unionfs is taking up 4.9gb, which is effectively the virtual machine's entire hard drive.

I am a very raw beginner so I apologize that I do not know anything about the savefile nor journaling. I did not even know they existed until now.

[Phoenix]

Can you verify the size of the savefile? (Instead of looking at df -h use ls -lh <path/to/directory/of/savefile> Also did you happen... to issue chmod -R by any chance?

[Megafrog]

Phoenix, the command you suggested ls -lh <path/to/directory/of/savefile> gives "bash: syntax error near unexpected token `newline'

If I were supposed to have ls -lh and then follow it up with some directory that has the savefile, I have the problems of 1) not knowing where that is and 2) not knowing much of where anything is in Linux except what I can find in the Files browser, going to the downloads directory. I do not even see a search feature in the Files browser. I apologize for my lack of knowledge on this.

I did not use "chmod -R" since I don't know what that is. I could not recite anything in code to save my life unless I were reading it off a web page in front of me. I'm a GUI-only person unless someone gives me code to work with first.

[Phoenix]

Alright then, if you have saved to your virtual disk, it will be represented under /mnt/home. BUT the reasoning here is that you may have placed it into another directory under /mnt/home (aka your root partition, where the savefile is located). Substitute <foobar> with the appropriate file path. (/mnt/home/ OR /mnt/home/xxx/)

If you still cannot find it, use find /mnt/home -iname '*save*'.

[JASpup]

"Error writing to file: no space left on device. The file on disk may be truncated."
[Edit: whenever it boots from scratch it says this message: Error saving pinboard /root/Choices/ROX-Filer/-PuppyPin: No space left on device ]

This could be a PUPSAVE as Phoenix suggests or specific to your VM setup.
If you're using a save file and it's too small it can wreak havoc on your system.
You would have created it at Puppy shutdown.

The question: is the error within VM or within Puppy? (PUPSAVE of course being the latter). Within Puppy, if System -> Pup-SysInfo -> Sys-Files -> PupState reports you're in PUPMODE=13 (or 12) you're using a PUPSAVE.

My default VM memory allocation is 1G. In Puppy LIVE (PUPMODE=5), half is designated for ramdisk, which is where /root is loaded frugally.

I would not assign under 2G VM for this reason. The default VM memory allocation is too small.

Under normal conditions newly installed Fossa would not fill a 5G partition.

Puppy has also still adjustments with /home directory use as it does not exist in older pups.

[Megafrog]

Phoenix: I went into mnt/home/fossapup64bit95 as a directory. Within the directory, fossapup64save is 4.1gb, which is MOST of the way to filling up the hard drive. To see what was in that directory I right clicked for properties. It said this about mnt/home/fossapup64bit95 in the popup:
Real directory: /initrd/mnt/dev_save
Size: 4533M (4752531456 bytes)

That is even more of the 5gb virtually allotted.

JASpup:
The System -> Pup-SysInfo -> Sys-Files -> PupState reports PUPMODE=12 and also confirms that fossapup64save is the PUPSAVE

I am uncertain about the next step. I was hoping not to have a 2gb virtual machine since this particular computer only has 4gb to start and the VM is mostly used for sandboxing

[Phoenix]

I see then. You'll need to find what is occupying so much space via GDmap as aforementioned by rockedge. It's most likely the .cache directory in /root. You can delete that via rm -r /root/.cache

[rockedge]

Also check the size of the logs in /var/log as well as the caches mentioned by Phoenix

Also one can check the size of a directory like /root/.cache in the Rox file manager by right-clicking on the directory in a Rox window, look towards the bottom of the menu and select Count.

If the directory is very large it will take a moment or two. It will display the storage size of that directory. Small directories or individual files, alone or grouped together will show results very quickly. Huge directories take longer to show the resulting size is the point here.

[Megafrog]

Per GDmap, 3.34gb are being taken up in initrd/mnt/dev_save and 1.47gb in /usr/

I also wiped out the cache. Should I just start wiping things out in dev_save? I feel like there is progress since wiping the cache allows text files to be saved at least. However df -h still says /dev/sda1 still is 4.9g with 4.9g used.

[rockedge]

What does GDmap indicate is the name of the file(s) that are so large? Hovering over them with the mouse cursor should display the names.

[Megafrog]

Within dev_save there are a lot of files. Some are 220mb+ sfs files like adrv_fossapup64_9.5.sfs and some are 20mb like nouveau_dri.so, libxul.so was from firefox and has 20mb, there are just a ton of files. I'm also regretting naming my VM fossapup65_9.5 since I'm not sure what the system was and what is my named stuff - I thought I would just remember my version number easier for support.

Regardless, it's not just one file. Things in usr/lib total 1.07gb and are labeled "pup_a"

In mnt are a lot of dev_save/ files and that is claimed to take 4.65gb. "Pup_ro2" is a 378mb block of files. Also "pup_z" and "pup_f" are taking about 100mb each. I hope the "F" from pup_f isn't a description for a mistake I made during installation

[Phoenix]

The only filesystems that are of concern here, is the rewritable layer (your savefile) and /mnt/home (Your /dev/sda1 since your virtual disk is the first media present to Linux presumably!). Of course since your savefile is basically taking up almost all of that space probably by accident, we only need to look at the savefile.

Now your rewritable layer should be in /initrd and is named pup_rw or pup_a. ``df -h`` will tell you that for certain, as it size matches the 'unionfs'.
Now with Gdmap you'll need to navigate so that you are inside the folder (no, selecting it and then pressing ok doesn't work as expected). It will give you a better idea of what is taking all that space (firefox is roughly 250MB or so).

Why not use Gdmap on the base directory '/'? It will then use every single directory and file even if its a separate filesystem (because it was mounted meaning you might get unexpected sizes that are larger than your virtual disk.

[Megafrog]

Why not use Gdmap on the base directory '/'? It will then use every single directory and file even if its a separate filesystem (because it was mounted meaning you might get unexpected sizes that are larger than your virtual disk.

I did not know enough about linux even to select just / and check in GDmap. Now I did it and the results are even weirder than expected. With a bunch of tiny (and some large) files within it (mostly purple and gray) there is a 6.33gb square for initrd. Off to the right there is a square with similarly colored file rectangles but it is 3.34gb and is titled .-22-02-14_21.18 with lots of files that are apparently with names like initrd/mnt/dev_save/fossapup64bit95/fossapup64save/.22-02-14_21.18/initrd/pup_ro2/usr/lib/x86_64-linux-gnu/libicudata.so.66.1

Below that there is a usr block that has fewer and smaller rectangles/files but still takes up 1.47gb

Considering my virtual hard drive is supposed to be only 5gb, this is almost 7gb more than Oracle Virtual Box seems to think I even have! No kidding about unexpected sizes! Now the questions are why and what to do next!

[Phoenix]

If your savefile itself (If you still don't know what path the savefile mounts itself to, just click on the savefile via ROX-Filer and it will do it for you) contains 'initrd/pup_ro*' with files, not directories, taking up actual space, I think you have a problem then. Those read only layers shouldn't have been copied to the savefile, which means you'll have to delete those while running in RAM mode. You could of course delete while using the savefile, but it will cause the unexpected. (Please don't do it, I did it myself )

Why are files copied over to the savefile even though they already exist? It might have simply edited or copied/overwrote which then writes to the savefile. As well if it never let you write changes it wouldn't be a particularly useful filesystem. But it is not intelligent, it does what its told to do, and will make the assumption the user knows all. This means if you copy-paste the initrd folder (copy it in the same spot) it will overwrite with identical data, and also fill up your savefile.

As well scanning from / will cover all mount points as well as what you'd normally see which almost always add up over the size of the savefile. (Think external filesystems + internal filesystem)

[Megafrog]

Interesting Phoenix. 'initrd/pup_ro" has many directories, but not so many files there. I could find, within my initrd/mnt/dev_save/fossapup64bit95/fossapup64 savefile, another directory to another savefile, which has a huge directory tree and can go to initrd/mnt/dev_save with a third subdirectory that does not include a savefile.

If you have not seen the movie "Inception" my Puppy Linux install is describing the plot. I'm not sure what to do about that though.

[williams2]

I thought I read somewhere that you wanted to save the iso file with the iso file saved in the original iso file.

Something like, FossaPup64.iso with a copy of FossaPup64.iso in /root.
That is, your file FossaPup64.iso has a file /root/FossaPup64.iso in it.
If you try to do that, your iso file will have an infinite number of FossaPup64.iso files in the iso, taking up an infinite amount of space.

For example, if the original iso file is 400MB, and you modify it by adding a copy of that iso file,
then the iso file will now be 800MB (the original FossaPup64.iso file plus a copy of the iso /root/FossaPup64.iso)

But /root/FossaPup64.iso will also be 800MB, because if it is a copy of the original iso, it will also have a copy of the original in it, as /root/FossaPup64.iso. So the original iso file must be 800MB+800MB or 1600MB.

So, if you try to add a copy of the original iso file to the original iso file then your original iso file must have an infinite number of /root/FossaPup64.iso files in it, each one using 800MB of space, and so using an infinite amount of space.

If you do not try to save a copy of the original iso in the original iso,
then the original iso would be about 400MB.

[Megafrog]

williams2 that was not anything I intended to do. I certainly hope I did not do it. I checked that the VM was actually running off the virtual hard drive and not the iso in the virtual optical drive since I want it to be "installed" like my host operating system to save persistent data.