Page 1 of 1

Normal cause of save2flash hanging in queue?

Posted: Thu May 13, 2021 11:23 am
by JASpup

This is LxPup Xenial using LXDE (JWM is also used/available):

LxQueue.png
LxQueue.png (5.64 KiB) Viewed 368 times

It's waiting for something that doesn't happen. No apps are running in the tray.


Re: Normal cause of save2flash hanging in queue?

Posted: Thu May 13, 2021 4:39 pm
by HerrBert

The only cause i can think of is that pup_event_frontend_d is not running, which would not be a 'normal' cause...


Re: Normal cause of save2flash hanging in queue?

Posted: Thu May 13, 2021 5:06 pm
by Jafadmin

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"


Re: Normal cause of save2flash hanging in queue?

Posted: Thu May 13, 2021 10:57 pm
by bigpup

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.


Re: Normal cause of save2flash hanging in queue?

Posted: Fri May 14, 2021 2:51 am
by amethyst

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).


Re: Normal cause of save2flash hanging in queue?

Posted: Fri May 14, 2021 3:36 am
by JASpup
bigpup wrote: Thu May 13, 2021 10:57 pm

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.

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.


Re: Normal cause of save2flash hanging in queue?

Posted: Fri May 14, 2021 3:42 am
by JASpup
HerrBert wrote: Thu May 13, 2021 4:39 pm

The only cause i can think of is that pup_event_frontend_d is not running, which would not be a 'normal' cause...

If I can recreate circumstances after running pup event, that would be something to try.


Re: Normal cause of save2flash hanging in queue?

Posted: Fri May 14, 2021 3:44 am
by JASpup

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 am

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).


Re: Normal cause of save2flash hanging in queue?

Posted: Fri May 14, 2021 3:52 am
by Jafadmin
bigpup wrote: Thu May 13, 2021 10:57 pm

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.

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.


Re: Normal cause of save2flash hanging in queue?

Posted: Fri May 14, 2021 6:49 am
by amethyst
JASpup wrote: Fri May 14, 2021 3:44 am

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 am

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).

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.


Re: Normal cause of save2flash hanging in queue?

Posted: Fri May 14, 2021 7:15 am
by bigpup
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?


Re: Normal cause of save2flash hanging in queue?

Posted: Fri May 14, 2021 2:45 pm
by Jafadmin

@bigpup

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 ..


Re: Normal cause of save2flash hanging in queue?

Posted: Fri May 14, 2021 6:15 pm
by bigpup

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.


Re: Normal cause of save2flash hanging in queue?

Posted: Thu May 20, 2021 10:54 am
by JASpup

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.