A SAVE-session to directory option added for PUPs [REOPENED]

[gyro]

Are you saying finally in puppy an sfs is layered over the main sfs after 8 years and much tub thumping.... lets do a dance

Yes.
gyro

[gyro]

Unfortunately I may not have time to test this for few days but it looks good.

That's almost timely, as I will be releasing a new version shortly. I've just found another way to work around the "`mount " problem, using a "cat" of "/proc/self/mountinfo".
I would expect the previous method to "kernel panic" under pupmode 13.

I was wondering however what is the advantage of ...

A good question.
My reasoning is:
1) Easy to only do this search on linux partitions, and ensure that the facility will not be available on non-linux partitions, even if a suitable named directory exists.
2) The flexibility of naming the save directory, it only has to start with the standard save file name, and be a directory.
3) The extensions of the save files have meaning, that is irrelevant to a save directory. So, I don't like the idea of using any of these extensions for a save directory. (I use simply "slackosave".)
4) It's just the way I did it.
5) I haven't looked at the first shutdown code yet.

gyro

[mavrothal]

That's almost timely, as I will be releasing a new version shortly.

OK.
Would you please provide "diff -u" instead of just "diff" output files. Are much easier to read in geany (or any other capable editor) and understand what is going on.

[gyro]

Here is updated code for Slacko 5.7 and Dpup Wheezy 3.5.2.11.
In both cases there is diff to help with patching the "init" script in "initrd.gz,
and an sfs file of patched applications that could be used as a ydrv.

Why the update?
Mainly because I realised that the previous version would almost certainly "kernel panic" if someone tried to use it in pupmode 13.
I haven't sorted out pupmode 13, but at least this version has a good chance that it will boot.

Changes:
1) I've commented out some of the useless "find" commands, since anything they find, gets ignored anyway. (see my previous whinge)
2) A much more robust method of working around the "`mount " problem that is a side effect of the "mount -o bind".

"`mount " problem:
After the "mount -o bind" command mounts our save directory as "/pup_pw",
there are 2 entries for the "/mnt/home" device in both "mount" and "df" output.
This confuses scripts that try to obtain the mount point for the device by processing this output.
The script gets 2 responses when only 1 was expected. Unfortunately the "init" script does this several times.
Using only the first entry, seems to work, but will it always continue to work? I don't know.
Discarding the one containing "pup_rw" works fine in pupmode 12, but would do nothing in pupmode 13, since our save directory would be mounted as "/pup_ro1" in pupmode 13.
But, the file "/proc/self/mountinfo" contains a field which contains the source directory within the device. For normal mounts this field is "/" but for our "mount -o bind" it contains something like "/slacko/slackosave".
So, the current work around uses a "grep '/ '" to select only the entry for the normal mount of the partition.
This should be a robust solution.

gyro

[gyro]

Thinking about a possible alternate implementation of save directories in the "init" script.

Could replace
find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -type f -iname ${DISTRO_FILE_PREFIX}save*.[234]fs
with
find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -iname ${DISTRO_FILE_PREFIX}save*.[234d]fs

Downside:
The name of the directory is now restricted to ${DISTRO_FILE_PREFIX}save*.dfs

Challenge:
Any save directories in the PUPSAVES list that are not on a Linux partition have to be ignored.

So, either,
a) only look for save directories on Linux partitions
or
b) always look for save directories, and then ignore them if they are not on a Linux partition

gyro

[bigpup]

So, either,
a) only look for save directories on Linux partitions
or
b) always look for save directories, and then ignore them if they are not on a Linux partition

To me (a) seems to be the logical one to use.

a) only look for save directories on Linux partitions

As I understand, the save directory has to be on a Linux formatted partition to work.
If this is true, there should never be one on a non-Linux partition.

A non-Linux partition should never be offered as a place to put a save directory.

The present save options (without your modifications).

On USB flash drives.
When Puppy is installed to a USB flash drive that is formatted a Linux format.
You are offered the option to use the entire flash drive partition to save to. You do not use a save file, you save to the partition.

You are only offered this save option with Linux formats.

If a Vfat format is used. Save file is the only option offered.

The present code already eliminates options determined by the partition format.
However, I think it only looks at USB flash drive installs to offer the partition save option.
If using a hard drive partition it only offers save file regardless of format.

If you are still going to offer the option to make a save file. They can still be on any partition format.

[mikeb]

Hmm I suppose that depends on if you rely on the shutdown script to only use posix partitions or not rather than someone randomly making a folder.

I like versioned naming...makes life very simple but I can see it is nice to have multiple saves and that is now an established option since multiuser is unlikely to happen in the near future.

The old init used to look for the initrd/ directory as a test for a save partition....again its based on correct making of the folder in the first place but that might be a simple but effective test for a valid save directory.

mike

[gyro]

Here are updated ydrv sfs files that implement save directories.
The both now contain:
1) patched "drive_all"
2) patched "pmount"
3) patched "rc.shutdown"
4) patched "shutdownconfig"

This concludes this proof of concept implementation.

Note on "shutdowconfig":
This is an extremely minimalist patch. Right at the beginning of the script, if it finds that the puppy.sfs is on a linux partition, it creates a save directory there, writes the config file and exits.
(The name of the directory is setup by NAMEONLY="${DISTRO_FILE_PREFIX}save")

So with a patched puppy running on a linux partition, there are no questions at 1st shutdown, it just does it.

gyro

Edit: I have deleted the attachments because they contained some hidden files (.XLOADED, .java, .wh.Frisbree). I't very sorry about that, I will upload corrected ones shortly.

[gcmartin]

Hello @Gyro

... So with a patched puppy running on a linux partition, there are no questions at 1st shutdown, it just does it. ...

Those 3 words.

Scenario: I boot with a "patched" puppy ISO (assuming someone produces with this technology adaptation). If I am "kicking the tires", I may not want to save the session (an example is booting a distro for test in a VM guest).

Question

• Can I shutdown without saving the session?

There maybe a time when I would want to do this where I am just testing, but do not want to keep the results of the session's tests.

Thanks.

[gyro]

@gcmartin

I'm not suggesting that the patched "shutdownconfig" is the best way to do it.
In one sense it's a quick and dirty, just to get an implementation done.
On the other hand, it's how I would like puppy to work. I think I can remember on my very first install of puppy, I was a little confused by all these questions, for which I did not know the consequences.

gyro

[gyro]

Can I shutdown without saving the session?

Not if you are running puppy on a Linux partition, and using my patch.
But, anyone is welcome to take it and "fix" it.

gyro

[gyro]

Here are the cleaned, updated sfs files.

gyro

[mikeb]

If you are playing with shutdown choices if it still applies i found the default to make a save a bit naff... after all what if you get a blank console and you definitely dont want to use the pup cos you were only testing...or its a live boot to fix yer mates machine.

I made the default to not save with a timeout period to do it automatically.
Once a save is established then its the opposite...the default is to save after a time out unless you choose not to... The idea to make everything more hands off for normal use.
And yes it can be confusing so anything to simplify and clarify choices would be welcome.

My sequence is something like

save or not....
turn off after a few seconds OR...
list devices/partitions and the options available for each with brief info
choose place to save....
choice of save option...
any further options depend on the choice... eg save file format and name

I suppose if save choices were set at boot or during install then the user would read up about whats best in the furkling manual or the installer would offer the options but this aspect of puppy does again have a certain appeal.

Just my 3 cents worth...

mike

[bigpup]

Can I shutdown without saving the session?

Not if you are running puppy on a Linux partition, and using my patch.
But, anyone is welcome to take it and "fix" it.

gyro

You are at that stage of software coding where you have proven the concept works.
The question now is, how do you want it to work?

This is not Windows development.
Do not give up by just making it work one way.
Linux is about choices in everything you do.

Now the code tweaking begins.

Adding an option should not eliminate other established options.

We only point out things, to you, as a help to make your fine work even better.
You are coding to add a very good save option to Puppy.

You and us are in the tweaking stage of this code.

This is the hard part. Getting it to 100% of what you really want to happen.

We are all here to help you.
Do not think otherwise

[bigpup]

entered in error.

[gyro]

after all what if you get a blank console and you definitely dont want to use the pup cos you were only testing

That's what a puppy on a cd is for, boot and delete the mess.

...or its a live boot to fix yer mates machine.

If you boot from a cd then the puppy.sfs is not on a Linux partition.
If you boot from a usb stick formated with a Linux partition, then the worst thing that happen is you get a new directory on your usb stick, which you can delete after a "pfix=ram" boot.

gyro

[mikeb]

That's what a puppy on a cd is for, boot and delete the mess.

and those with a dead hard drive or grub fear

mike

[gyro]

@mikeb
Sorry, I think I was editing my reply while you were replying to it.
gyro

[gyro]

@bigpup

I appreciate your encouragement, but I'm not sure we're on quite the same page.

All I set out to do was to prove that the concept works, and that it can be done so that it does not diminish anything in current puppy.
(I exclude "shutdownconfig" from this, because right now I don't have any enthusiasm for tackling a script based gui.)

A project like this is going to fizzle unless it gets picked up in main stream puppy, i.e. woof-ce.
It's a pain to have to keep on patching each new version of "init"; been there done that in the days of puppy 4.3.

My number one wish would be to see the "init" script and the "drive_all" script modified to support save directories.
These get used before there is any possibility to patch them with a pet.

Next, would be "rc.shutdown". It can be patched with a pet, but it may contain stuff that is unique to a particular puppy.

Then "pmount", it's just an application that can easily be patched, and a single pet would most likely be compatible with most puppies.

Note: All the patches to this point do not change any of the existing puppy facilities.

Lastly, "shutdownconfig".
I happen to like the way I've patched it, but that certainly changes the normal puppy way.
(I wish puppy had worked this way the first time I tried it.)

That's one of the significant tasks todo; design what "shutdownconfig" should do to in a puppy that supports save directories.

gyro

[gcmartin]

@Gyro, thanks for your reply.

In my high-lighting those 3 words, I was assuming you were referring to a 1st boot of a PUP, say 'Live boot" or a pfix=ram boot. And, was assuming that somewhere in the use process or shutdown processing, the user has decided to Shutdown with no desire to have a session-save. That's what drew my attention.

Question
Is this the same scenario you were envisioning? And, how would you see a user step thru this?

Your other efforts seem well-structured and should be easy for developers to incorporate. I'm sure other developers are considering this particular approach for its merits.

Puppy needs this kind of consistent and deliberate approach across the Puppy-line. This would be apparent, not as a locked in direction, but, as a consistent guide that users would see (and understand) in save-session processing.