Normal cause of save2flash hanging in queue?
This is LxPup Xenial using LXDE (JWM is also used/available):
It's waiting for something that doesn't happen. No apps are running in the tray.
Discussion, talk and tips
https://forum.puppylinux.com/
This is LxPup Xenial using LXDE (JWM is also used/available):
It's waiting for something that doesn't happen. No apps are running in the tray.
The only cause i can think of is that pup_event_frontend_d is not running, which would not be a 'normal' cause...
This probably happens because you are running in pupmode 12 (atahd) and click the "save" icon on the desktop. The system has nothing to do because disk saves are automatic. In this situation the message is innocuous.
You can safely kill the message by running this command in the console: 'killall yaf-splash"
you are running in pupmode 12 (atahd) and click the "save" icon on the desktop
Pupmode 12 does not make a save icon on the desktop.
Only when in pupmode 13 do you have a save icon.
My guess is the size of what is needing to be written to the save and the speed of the writing to the USB drive.
How long does this message stay open?
Does it ever close?
This could be a bug in LxPup Xenial using LXDE and you need to report it in it's topic.
I think that is just a default message that the saving will follow. The save2flash script brings up the yad message, then executes a touch /tmp/snapmergepuppyrequest command, then executes a sleep 1 ( a 1 second waiting period) command before executing a command to kill the display message. The actual savings process takes a bit of time therefor there will be some delay after the display is killed and the next message that the saving has been successful (or not successful).
It hangs stuck. If I switch to JWM I can save.
I'm probably an unconventional user trying ill-advised options on the promise of what seems possible.
In this case it's two environments in the same boot.
JWM & LXDE/OpenBox share configuration and system data in Lx.
I have two 32 versions of it via ozsouth, one the release everyone else has and the other cobbled for different drivers.
On the cobbled version, I could save2flash in LXDE. On the regular version, it hangs with this error (these are different machines and that could be a factor as well).
In my XFCE experience, as I've written recently, puplet makers deliberately remove or cripple JWM, I presume either for technical reasons or resource conservation.
But that was the goal, generally, coexistence of two different environments on the same boot.
I get a kick out of seeing OpenBox in JWM, especially the menus. It almost works normally.
It could be a glitch, but it seems to be not saving unless I switch the DE to JWM. When I run LXDE without configuring JWM, it saves normally.
amethyst wrote: ↑Fri May 14, 2021 2:51 amI think that is just a default message that the saving will follow. The save2flash script brings up the yad message, then executes a touch /tmp/snapmergepuppyrequest command, then executes a sleep 1 ( a 1 second waiting period) command before executing a command to kill the display message. The actual savings process takes a bit of time therefor there will be some delay after the display is killed and the next message that the saving has been successful (or not successful).
Try this, little big dog: Take a puppy in pupmode 13 and change it to pupmode 12. You will retain the save icon. It will produce the described stuck message
This most commonly happens to me when I take a savefile from a thumbdrive and copy it to a HD.
JASpup wrote: ↑Fri May 14, 2021 3:44 amIt could be a glitch, but it seems to be not saving unless I switch the DE to JWM. When I run LXDE without configuring JWM, it saves normally.
amethyst wrote: ↑Fri May 14, 2021 2:51 amI think that is just a default message that the saving will follow. The save2flash script brings up the yad message, then executes a touch /tmp/snapmergepuppyrequest command, then executes a sleep 1 ( a 1 second waiting period) command before executing a command to kill the display message. The actual savings process takes a bit of time therefor there will be some delay after the display is killed and the next message that the saving has been successful (or not successful).
If you have the save icon on desktop (which is the shortcut for the save2flash script in /use/sbin) and click it, the script should run. The script has nothing to do with the windows environment.
Jafadmin wrote:Try this, little big dog: Take a puppy in pupmode 13 and change it to pupmode 12. You will retain the save icon
Not when I make the change.
The correct way to do it:
You do have to do a complete reboot to make the change correctly.
you change the pmedia= entry in the boot loader menu config file entry.
pmedia=usbflash to pmedia=atahd.
Note:
The pmedia= options have changed over the years.
But usbflash will run in pupmode 13 and atahd will run in pupmode 12.
Those two always have been in Puppy.
The actual type of drive does not matter.
The pmedia= controls.
The Puppy version and what specific version of the control files/programs can have an affect on this.
This stuff has been tweaked a few times over the years.
I tried it in a very new version of Puppy.
Puppy like OS's on this forum. Well, they do not do things exactly as an official Puppy version does.
About the save file used from a USB install that was running in pupmode 13.
Does the boot menu entry for the hard drive frugal install use pmedia=atahd command option?
Does the save icon still stay on the desktop after the second shutdown and boot up?
There may be a info file, in the save, that needs correcting, by doing a save and reboot.
What specific Puppy version are you seeing this?
Puppy is a "portable" OS. This means that it isn't tethered to the monolithic "one-computer-one-OS" model. The convenience is that I can create a really sweet savefile for my favorite puppy distro, and copy that savefile to any machine or thumbdrive I want.
One of the side-effects of doing that is that I often wind up with "Save" icons on the desktop of savefiles that are running on HD's. Not a big deal. Just remove the desktop "save" icon on that machine.
This isn't a problem. It's a feature. Everyone can comfortably move along now ..
A save is not exactly that 100% correct for any computer.
The save will have settings and configure info files, specific for the computer it was made on.
If the Puppy version is new enough.
A lot of the hardware differences will be detected at boot and corrected.
But this is not 100% correct all the time.
I recently realized one other cause, and that was having the ppm open, though I don't have enough experience to know if it's consistent or circumstantial.
I.e., close ppm and save commences.
'Course in my dual-wm setup saving in LXDE didn't work at all.