Puppy Linux Discussion Forum

On a few occasions I have powered down without first plugging in the drive where my save file resides sdc2. Fatdog doesn't prompt the user to remind them to plug it in, it pretends to save and then shuts down. A warning would be better.

A related issue is if I click the save session button without connecting the drive then the computer starts running hard 100% and the fans spin up, but the process seems to get stuck. This is a user error, but it could be handled more gracefully.

I stopped save2session with the task manger on the time I did it accidentally and today when I did it deliberately. Hopefully nothing will get broken as a consequence.

je55eah wrote: Sat Dec 10, 2022 11:02 pm

On a few occasions I have powered down without first plugging in the drive where my save file resides sdc2. Fatdog doesn't prompt the user to remind them to plug it in, it pretends to save and then shuts down. A warning would be better.

If you use savefile and save2flash, you are not supposed to unplug the drive.
No amount of warning will help because if you unplug your flash drive when you use save file, you cannot save anything anymore (even if you plug the flash drive back).

A related issue is if I click the save session button without connecting the drive then the computer starts running hard 100% and the fans spin up, but the process seems to get stuck. This is a user error, but it could be handled more gracefully.

I stopped save2session with the task manger on the time I did it accidentally and today when I did it deliberately. Hopefully nothing will get broken as a consequence.

This is not supposed to happen. If you forget to connect the drive, then what should have happened is that the save will fail and that's it, it shouldn't lock up. I will need to test further if I can reproduce it. In any case, the most likely reason for the 100% cpu is that the kernel hangs because it's running out of RAM.

@jamesbond

This is the menuentry I have been using.

menuentry "Fatdog64 with unencrypted USB multisession support" {
	echo Loading ...
	linux /vmlinuz rootfstype=ramfs waitdev=10 coldplug ntfsnoperm HOSTNAME=fatdog0284-E81B savefile=ram:multi:uuid:0284-E81B:/saves/fatdog813save.ext4
	initrd /initrd
	echo Booting ...
}

It works as long as I remember to plug the drive in again before saving.

We talked about this here: viewtopic.php?t=7067

@Feek offered a solution to the two button issue, but I was intimidated by the process of extracting the base.sfs and making my system even more unusual. I didn't use direct because I want to run from ram and disconnect the drive.

je55eah wrote: Fri Dec 16, 2022 4:10 pm

This is the menuentry I have been using.

So you are using RAM layer with multisession mode.

It works as long as I remember to plug the drive in again before saving.

The information helps, but it does not change anything.
Everything that I said still stands.

Let me repeat again.

save2flash is for the RAM layer.
RAM layer does not free up the "savefile". The "savefile" must be plugged in at all times.
save2flash saves the content of the RAM layer into the "savefile".

But you are also using multisession mode.
In multisession mode there is a "virtual savefile", which is located in RAM (which obviously is "plugged-in" at all times).
When you save2flash, you are saving the content of the RAM layer to this "virtual savefile".
It is __NOT__ pretending to save, it actually __DOES__ the save.
(And it does not need to warn anything about disk not plugged in, because, I repeat again: save2flash and running with RAM layer __REQUIRES__ the savefile to be plugged in at all times; and in this particular case, the savefile is located in a "virtual savefile", so it is already always plugged in).

However, remember that this "virtual savefile" is in RAM, so, if you don't do anything else, it will be wiped out when you shutdown or reboot. Nothing surprising here.

To actually save the content of the "virtual savefile" and create a new session on your disk (or DVD), you need to use save2session.
save2session does indeed gives a reminder to plug in the device, before it does the actual save.
If the device is not plugged in, it will attempt to save anyway but it will fail and nothing will be saved (for obvious reasons). I never have a crash in this process; I suspect that you're crash because you're running out of memory during the process.

I didn't use direct because I want to run from ram and disconnect the drive.

In the very thread you quoted ( viewtopic.php?t=7067 ), I asked you to use multisession mode. I told you that the RAM layer was the wrong tool for the job.

But instead you end up using __BOTH__ the RAM layer and the multisession mode. There are situations that require this configuration, but if all that you want is to be able to unplug the device while running, @Feek indeed already offered the correct advice: use "direct:multi" instead of "ram:multi" to avoid the double "save" button (in other words, only enable the multisession but don't use the RAM layer).

If you want to make sure that nothing is saved at shutdown, you can still run with "direct:multi" but change the "RAM Save Internal" from the Fatdog Event Manager to zero; and then __save the session__. Saving the session makes sure that this change is persisted, so that on the next boot, this value will always be set to zero. Then nothing will ever be saved a shutdown time ever again. If you really want to save your session, click the save2session button manually.

Good luck.

Thank you. It seems that I was timid to change the thing because of the wrong reasons. One of my questions on the other thread was not answered and I simply kept my grub as is because it was working.

Based on what you have just explained I now feel confident that direct with multsession will be superior. I prefer to unplug the drive during use, but it will be nice having only the single button rather than two. I will try this when the next release comes out. (direct still sounds like a setting that will preclude me from detaching the drive which hosts my multisession save files, but I surmise that multissession has a ram layer of it's own which makes the ram setting redundant.) This should provide the added benefit that when the session save is triggered at poweroff all of the data will be saved and the ram layer will not be lost.

As for the 100% cpu issue, your theory about the memory running out sounds plausible, but I wonder why because with no drive attached, it ought to simply tell me that it cannot save. What data would fill the memory? At that point everything is already in ram.. ..Answering my own question, it is possible that it attempts to create a whole new save file, exactly as it would if the target drive is attached and the save file is absent. I have successfully rebased a multisession in that way and the process does take some time. Where is it trying to write the thing, that is the puzzle if that is even the issue.

To test this theory, I deliberately shut down with the drive detached and it wasn't a fast shutdown at all. It built the initial save file somewhere before shutting down, but I didn't locate the file on the internal drive and there was no other drive attached. In the end nothing was saved. If I wish to discard my session that's great, but why even make a save file if there is no place to put it? I was wrong in my OP, fatdog does post a reminder to attach the drive when I click shutdown. There is nothing to be done about user error, but a message along the lines of "Warning: (multisession) save file location/drive is not present. Discard changes? (Yes/Retry)" would be more attention grabbing. If the answer is Yes, then it could shutdown without generating an initial (multisession) savefile first.

update:

I backed up my save files and changed my grub setting to direct.
After rebooting in multisession direct I changed the background image and shutdown. Upon reboot, the background reverted to the prior background so the data containing the setting changes must have been lost. Although multisession usually creates an additional save file each time the session is saved, no additional save file was created at shutdown. It appears that save2session doesn't work during shutdown.

Moreover, I tried changing the desktop again and when I used the save2session button a save file was created and the desktop change was preserved through a reboot.