How to save to Savefile only on demand in Puppy 5.2

[Zaven]

My hardware solution: usb flash drives w/ electronic write protect switch

[login123]

I have been using the configuration described in the first post for puppy 525 .
- It has worked OK since then.
- Nothing saves at shutdown.
- The unclean shutdown warning indeed seems to be harmless.
- Anytime you do want to save something, just click the save to flash bullseye (I renamed that bullseye)
- It's the simplest solution I have seen, just rem out 3 lines of code.

Attached is a screenshot.



Anybody else tried it yet?

[Bruce B]

I wrote the file /etc/.XLOADED with the data false with no line end.
(that's how Puppy writes it)

Then set it as immutable. Puppy can't write to it any more. I've been
doing this for a long time. It eliminates any unwanted dialogs.

~

[Bruce B]

why not use this ready made tool ?

http://www.murga-linux.com/puppy/viewtopic.php?t=60678

I didn't know that the referenced topic existed or this topic existed.

I wanted a yes/no option on shutdown.

The solution was a text edit of a few lines of text.

Even if I knew these topics existed, I'd just do it my way anyway.

~

[Mechanic_Kharkov]

Thanks!
To handle subj in my setup (boot from CD, save file on flash sda1) I have made following three steps:

• 1. Prevented scheduled saves by setting Save_interval=0 in Menu / System / Puppy Event Manager / Save Session;
• 2. Edited /etc/rc.d/rc.shutdown file and changed default behavior with this one:

  Code: Select all

    dialog --timeout 10 --yesno 'Save this session?
  (or just wait 10 sec to save)' 0 0 >/dev/console
    if [ $? -eq 1 ];then
     echo "Session saving cancelled" >/dev/console
    else
     echo "Saving session to $SAVEFILE (${SAVEPART})..." >/dev/console
     /usr/sbin/snapmergepuppy /initrd/pup_ro1 /initrd/pup_rw
    fi
  

• 3. Edited /usr/bin/xwin file to replace default 30 second timeout with 3 seconds one. (when "X seems have exited uncleanly.." appears).

And now I'm quite happy with results.
Thanks to Sylvander and others who posted to clarify the question!

[login123]

Hi, Mechanic_Kharkov. A question, if I may?

Does the "X seems have exited uncleanly.." message still appear the next time puppy is started? Thanks. Interesting setup you have, btw.

[Mechanic_Kharkov]

Does the "X seems have exited uncleanly.." message still appear the next time puppy is started?

Yes. It's still here. But it's here for a little time now.

Edited /usr/bin/xwin file to replace default 30 second timeout with 3 seconds one. (when "X seems have exited uncleanly.." appears).

Three seconds is quite enough for me to react when it's really no need to start X, and too short to bother me at boot time. And it's here only if I don't kill file /etc/.XLOADED before saving session.

And what about setup.. It's caused by my BI-440BX chipset that can't boot from USB devices like flash stick. :-/ So I need to use CD-ROM to boot from.

And there was another interesting thing discovered
After all editions made I decided that there would be great to have an ability to boot with my default settings without flash connected assuming no save would be made for such session at all.
So I 've written my pupsave.2fs file to CD. Before saving I have also changed some X configurations (pinboard behavior, backdrop, keyboard switchers, etc), restarted X, then killed file /etc/.XLOADED, and saved session file under X active. Then I have burned the file to boot CD.

Everything goes right if I boot with sda1 connected, but when there is no flash connected and it loads savefile from sr0 (CD) then X starts in strange manner. It shows "taskbar", clock, menu button, and black screen. Mouse works, but there is no icons, no backdrop image on the screen. Restarting X solves the problem. But I couldn't understand what is going wrong. Both files (pupsave.2fs) on flash and on CD are identical (I've compared them).
Trying to change backdrop image when X is in that "partially loaded" state, found that there is no pinboard active (see Scr1 image).
After restart X all my settings came back (see Scr2 image). I have no idea yet how to fix it. But it is not too hard to restart X, so I don't wory, and still happy. But it's really interesting glitch.
Also note on Scr2 that there is still "Save" button on the screen even if no sda drive active but sr0 only..

[login123]

Thank you. Very informative reply. I'm sorry to not know much about that odd boot difference. The reason I asked that question about the warning is that if I failed to click on "Ignore" during bootup, then the usb stick wouldn't boot next time. That is, if I remember rightly.

[Sylvander]

1. "Yes. It's still here. But it's here for a little time now."
How to prevent the spurious warning as a pupsave installation of Puppy boots, that the previous shut-down was improper.

2. "Also note on Scr2 that there is still "Save" button on the screen"
It's like your Puppy thinks your pupsave is on a Flash Drive.
Perhaps it's been configured [by changing a config setting in a file in the ISO used to make the optical disk?] to treat the pupsave as though it's on a Flash Drive; did you perhaps use this method to do that?

3. For background info see this.

[SimpleWater]

I used this method, and works nice, but not guaranteed. It does save on certain situations. I think restarting X is one of them.

[Mechanic_Kharkov]

2 Sylvander:
1. I think it's not a good idea to hardcoded deleting the .XLOADED file. If everything is ok with X - maybe. But if something going wrong, then this prompt helps to bypass X starting. I know that there is ability to use pfix=nox, but standard prompt seems to be more finger-saving technology (less typing required)

2. It really does. It thinks that it's still on flash in some mystic way. But it's not my own fault [or glory]. Yes, I really edited a little some configuration files on CD, but there was nothing about savefile location. I have just add a key to forcing ACPI usage - it's necessary to powerdown correctly on my board, and add a notification about ACPI is forced to boot.msg file ("Just wait 5 seconds for normal startup (note that acpi is forced)").
Now the "isolinux.cfg" file contents such settings:

Code: Select all

label puppy
kernel vmlinuz
append initrd=initrd.gz pmedia=cd acpi=force 

There is no flash references in boot config files on CD. The reference is still maybe somewhere inside pupsave file itself. Maybe the cause is last saving of pupsave file under alive X. So, pupmode=13 is still active (it's exactly correct, because the prompt on shutdown inserted to case 13 only, and it appears anyway).
Btw, while trying to save pupsave file from command line (/usr/sbin/snapmergepuppy /initrd/pup_ro1 /initrd/pup_rw) with X inactive I've got some "file is locked" conditions. So it does not work while some processes are still running. And I really have no idea neither which ones exactly nor how to stop them.
So, next step is trying to burn onto CD pupsave file after correct shutdown with session saved on exit. Awaiting for save completion (now it still saves. about 30 minutes were already passed).

Thanks for remastering ISO file manual too. I did not know how to do it under linux, and used UltraISO under windows.

I used this method, and works nice, but not guaranteed. It does save on certain situations. I think restarting X is one of them.

I have a bit strange situation with the file laying on CD (read-only CD-ROM), but with saving abilities also activated. So if any saving would be tried to perform then the system must raise some writing error message [or simply hang-up]. But nothing like that was detected even when restarting X many times. So, it seems that the X restarting is not an accidental save cause.

[backi]

Hi folks !
Tried several options .(mochi mopel--)
Somehow after installing a pet file then shutdown without saving (with mochimopels script) previous installed pet file still saved ,despite shutdown
without saving.(this occurs alwasy after installing programms either pet or deb files)
Other changes (for example a text file) where not saved.
what is that ?
Same effect- result with sylvanders change of the rc.shutdown.

then tried reversed action ,deleting the program(previous installed pet or deb files) manually (during session) then -shutdown without save.but now the " no save" option did work. These files still where there despite deleting during session.
Strange behaviour.
My saveintervalls are set to =0.
Does anybody know a simple way to choose save or not to save at shutdown .
I also used pupsavecinfig pet similar results.
I am using macpup 525- lucid- puppy 529- and dpupexprimo on USB stick.

[Sylvander]

1. All of my Puppies are each loaded using a "live" CD-RW, with the pupsave+SFS filepair...
Either on an ext3 partition on a Flash Drive, or else on an ext3 partition on an internal HDD...

2. And a file included in the ISO has had a configuration setting changed...
So that the pupsave on the HDD is treated as though a pupsave on a Flash Drive->[GREAT feature].

3. Not all of my Puppies [at least 1 doesn't] have feature 2 working, even when the necessary change has been made.
Don't know why.

[login123]

Fwiw, the method described in post 1 still works for Puppy 5.2.8.05. You still get a harmless warning during restart.

If I had a tiny bit more courage I would try some of those dialog options. Has anyone used them enough to say they work without fail?

Thanks.

[mikeb]

ripping out the code that generates and uses that .xloaded is the best thing you can do for any puppy...its totally pointless and just gets in the way.

mike

[Moat]

You still get a harmless warning during restart.

Hi login123 - did you catch this post by Bruce B, one page back in this very thread? Looks like a simple solution for eliminating that warning - http://www.murga-linux.com/puppy/viewto ... 050#522050

Bob

[mikeb]

The stupid code that writes it is in /usr/X11R7/bin/xwin and the stupid code that reads it is in /etc/profile

I like to point out stupid

mike

[mikeslr]

Since this thread was re-opened some 4 years after login123's original post seeking a “simple way to control saving sessions

[login123]

Hi, Moat. Thanks for that reminder. I saw that post by Bruce B but just forgot it. Will try it within a day or two.
But, I would much appreciate if you explain what it means to:
1. Write the file "/etc/.XLOADED with the data false with no line end"
2. "set it as immutable".

Hi, mikeslr, thank you for the advice. Sorry for reviving an old post. I only recently found out for sure it still works with 528.05. I bumped it because a post here by bill says it may have become lost: http://murga-linux.com/puppy/viewtopic.php?t=81911

I haven't tried Shinobar's excellent PupsaveConfig-2.2.5 yet. If I knew for sure that it worked in 528 05 I would install it right away. I did try several of the suggestions earlier in this topic with no success, probably some mistake in my code.

It is not easy to dig out all the issues and solutions on this forum, but I am reading as fast as I can, and much appreciate the helpful attitudes of all the members.

[mikeslr]

Hi login123

When this thread started, you were running 5.20 and 5.25. I still run 5.25 on a Dell Dimension 4600 which is attached to our only printer. I don't recall if, after finding jpeps's instructions, I tried to avoid AutoSave. I rarely print anything and the Dimension is only turned on when I do. So I may not have taken the time to attempt modification. In fact, I may have applied the adage "If it ain't broke, don't fix it". The Dimension still runs 5.25 because setting up Cups is a PITA.

I can, however, confirm that the shinobar-jpeps combination does work on Lupu 5.28. While i explore many Pups, mostly from a ZTSystems Quad Core, and drop some Pups as others are published, the original Lupu 5.28 has been on that computer now for at least 3 years. Lupu 5.28 is my "fall-back": (a) it just works; and (b) my impression is that webpages load faster and it can often pick up weak wireless signals when newer Pup's can't. The ZTSystem is 2 floors and about 150 feet from the router.

By now, I rarely have any reason to modify Lupu 5.28. But as I do put it to work at least 4 or 5 times a week, avoiding unwanted additions to its SaveFile was something worth obtaining. I am certain that before trying the jpeps-shinobar combination I backed up my SaveFile. And I distinctly recall that I initially only applied jpep's instructions and only thought of Shinobar's modified PupSaveConfig when I noticed it was still Saving at shutdown despite having applied the first 2 steps of jpep's instructions. [Shinobar's modification to PupSave is apparently the standard for newer Pups. So I hadn't realized jpep's instructions went beyond the second step].

At any rate, the information in my prior post is based on my experience on my system. I do recommend, however, that before trying it you back up your SaveFile. I have no idea how the other changes I've made over the last 3 years on my system may have differed from your own.

mikesLr