CAUTION
A Potentially dangerous bug
The bug described again here:
http://forum.porteus.org/viewtopic.php? ... 225#p45543
there is more info on this... as this bug appeared again.
On a fat32 USB with image file container for changes file, this leads to a potentially corrupted software and a dirty fat32 partition.
Now I had an update manager session with 2 packages to be installed, this update fully filled the remaining space of the container (only about 100MB left), without a notification. So zero bites left, 1 package succeeded, the second has been stopped with an error. Then I had a restart.
This might be an issue to the "disk image" file, preventing system from a successful changes file save at shutdown. So there might have been a partial save and this lead to corrupted files.
Some side effects after restarting with 0 bites left on save changes device:
Pcmanfm lost its settings and had reset all its configuration.
Palemoon presented an error about "read only profile" and prevented https pages from loading. There could be more. So I have reverted from a backup, again.
Those software got corrupted was open during the error and during shut down. At my first post, there was an updated package corruption.
Tested only on fat32 changes file, fat32 partition got checked by windows check disk that found and fixed problems again.
There has to be an alternative way of preventing the zero bite issue, or at least a notification message. so then user could be prompt to expand the file size of the container and processed again with the failed command. If there is no left space on drive, then the corruption will probably happen.
So I would say that if changes file will reach its full space, there might be a linux system corruption of the current open software and the files being edited this time. Then there will be a fat32 partition size mismatch that can be fixed by only by check disk.
Reminder: This seems a serious bug, maybe you could reproduce it, and it might exist on slackware version also.
The only workaround is to check that space left on container will meet your needs before any update. For example a full update to current from 3.5 will probably need 2-3GB of free space, if you will not have it you will end up to this bug.
I suppose this would never happen this way if a native linux partition has been used, maybe only an unsuccessful update.