SAVESPEC - a SAVEMARK file on steriods - MakeSAVESPEC 7

[gyrog]

SAVESPEC support is now part of woof-ce.
This topic also contains information on the MakeSAVESPEC utility.
MakeSAVESPEC is now at version 7, announced here viewtopic.php?p=116450#p116450.

---------------------------Original post----------------------------
This is the next phase of my testing stuff in the woof-ce 'init-experiment' branch.

I've uploaded spec-UPupGG+D-20.10+0.tar.xz and spec-eslacko64-6.9.9.11.tar.xz to https://www.mediafire.com/folder/ufo1lerdg73j0/savespec

Each of these tar archive files contains an 'initrd.gz' and a 'ydrv...sfs' file for the corresponding Puppy.
These are meant to be replacements for the release file(s).

You can install them with a command like:

Code: Select all

tar xf spec-....tar.xz -U -C /path/to/install/directory

where "spec-....tar.xz" is the appropriate downloaded tar archive file.
But this will clobber any existing files, so don't do that to a production Puppy.

These files contain the latest updates to the woof-ce 'init-experiment' branch.
They provide support for a SAVESPEC file, a bit like a SAVEMARK file on steriods.

In a normal frugal install, 'shutdownconfig' will write a SAVESPEC file to the install directory on first shutdown, if you select either a different partition or a different sub-directory, to the default.
You can also create a SAVESPEC file with a text editor, and place it in the install directory before first boot. This will simplify the dialogs shown by 'shutdownconfig'.

If you are booting a CD/DVD, 'shutdownconfig' can't write a SAVESPEC file to your install directory,
but it is possible to create a SAVESPEC file and write it to an "open" CD/DVD, (one suitable for multisession, pupmode=77).

If you are using 'isoboot', you can generate a SAVESPEC that defines the location for all your save-folders,
and place it in the same directory as the iso files.

A typical SAVESPEC file, defines a partition and a sub-directory e.g.:

Code: Select all

SS_ID='Work'
SS_DIR='/tsaves'

[gyrog]

More information on SAVESPEC:

A SAVESPEC file is only processed (read) by the 'init' script, so changing it in the running system will not make any difference to the following shutdown.

A SAVESPEC file is written by 'shutdownconfig' only if the save location has been changed by 'shutdownconfig'

If PSAVEPART has been specified by, a "psave=" boot parameter, a SAVEMARK file or a SAVESPEC file,
'shutdonwconfig' will not give you an option to select a partition.
If PSAVEDIR has been specified by, a "psave=" boot parameter, a SAVEMARK file (assumes PSUBDIR), or a SAVESPEC file,
'shutdonwconfig' will not give you an option to change the sub-directory.
The idea here is that, 'shutdownconfig' does not ask you questions that you have already answered.

But there are still 2 parts of this project missing:

1. A utility to generate a SAVESPEC file for a selected save directory. This is the directory that will contain the savefolder.
This will make it easier to insert a SAVESPEC file into an appropriate place before first boot.

2. Changing 'shutdownconfig' so it offers a wider range of partitions for selection if none is specified at boot time.
This could also exclude all small partitions, e.g. less than 600MiB, this should rule out any "boot" partitions.
It should also offer at least all Linux partitions on other devices.
I would appreciate feedback as to which partitions should be offered.

[gyrog]

i've uploaded 'mk-savespec-1.sfs' to https://www.mediafire.com/folder/ufo1lerdg73j0/savespec.

This is a GUI utility to generate a SAVESPEC file for a selected directory.
You also get the oportunity to select the directory where the SAVESPEC file gets written.

Load it with "sfs-load" and it should show in the "Setup" menu.

[gyrog]

I've uploaded 'ydrv_eslacko64_6.9.9.12.sfs' and 'ydrv_upupgg+d_20.10.sfs' to https://www.mediafire.com/folder/ufo1lerdg73j0/savespec
Simply put them in the install directory, replacing any existing ydrv...sfs files.

They contain an updated 'shutdownconfig', that extends the list of partitions available for selection, if it has not been specified in PSAVEPART in PUPSTATE.
The list now ignores any partition < 600MiB.
Of the remaining partitions, it includes all Linux partitions,
other partitions are only included if they are on the same device as the install partition.

I have not updated woof-ce yet.
I'm hoping for some feedback on which partitions should be in this list, if not the ones I have implemented.

[gyrog]

I've uploaded UPDATED 'ydrv_eslacko64_6.9.9.12.sfs' and 'ydrv_upupgg+d_20.10.sfs' files to https://www.mediafire.com/folder/ufo1lerdg73j0/savespec
Simply put them in the install directory, replacing any existing ydrv...sfs files.

They contain an updated 'shutdownconfig', that has a new algorithm for selecting the "RECOMMENDED" save partition, within the list of partitions offered.
This chooses the biggest Linux partition,
otherwise the biggest partition on the same device as the install partition,
otherwise the install partition.

[gyrog]

I've removed 'ydrv_upupgg+d_20.10.sfs' file from https://www.mediafire.com/folder/ufo1lerdg73j0/savespec.
The latest 'UPupGG+D-20.10+1.iso', already includes this stuff.

[williwaw]

what is a savespec or savemark intended purpose? can i read up on the project objectives somewhere? tx

[gyrog]

A 'SAVEMARK' file is an ancient (in Puppy time) method for defining the location of the savefile/savefolder in a partition other than the install directory.
If a Puppy is frugally installed in the directory '/anypup99' on the sdc2 partition,
and there exists a file '/anypup99/SAVEMARK' on the sdc2 partition that contains simply the number '3',
then the location for the savefile/savefolder becomes '/anypup99' on the sdc3 partition.
The sub-directory has been retained but the partition number is changed.

A 'SAVEMARK' file could be added to the install directory before first-boot,
or it would be written by the 'shutdownconfig' utility on first-shutdown, if a partition other than the install partition was selected during first-shutdown.

The spec provided by a 'SAVEMARK' file, is device name independent, i.e. it will work on a usb stick that was 'sdd' when it was plugged in yesterday, but is 'sdc' when it is plugged in today.

The limitations of a SAEWMARK file spec are:
It cannot specify a partition on a different device, e.g. in the above example, sdb2.
And it cannot specify a directory other than the install sub-diretory.

A 'SAVESPEC' file overcomes these limitations.
An example SAVESPEC file for the above:

Code: Select all

SS_ID='Work'
SS_DIR='/psaves'

indicates that the savefile/savefolder should be stored on the partition with the Volume Label of 'Work' in the sub-directory '/psaves'.
(The "SS_ID=" line could also use the UUID of the partition rather than it's Volume Label.)

Like a SAVEMARK file, a SAVESPEC file can be added to the install directory before first-boot, or it might be written by 'shutdwonconfig' during first-shutdown.
Also, like a SAVEMARK file the partition specification is device name independent.

The SAVESPEC file is firstly a full featured back-channel from first-shutdown to the 'init' script on subsequent boots, to indicate the location of the savefile/savefolder, (so 'init' can always get it right).
Which then allows 'shutdownconfig' to offer more options that will work on subsequent boots.
But it can also be used preempt the save location dialogs in 'shutdownconfig', particularly in situations where the install directory is not writable.

NOTE: If you use Volume Labels, make sure they are unique, for all partitions on your computer.

[gyrog]

I've re-uploaded 'ydrv_eslacko64_6.9.9.12.sfs' and 'ydrv_upupgg+d_20.10.sfs' to https://www.mediafire.com/folder/ufo1lerdg73j0/savespec
Simply put them in the install directory, replacing any existing ydrv...sfs files.

They now contain an updated 'shutdownconfig' that will automatically create, and use, a save-folder if the save partition is Linux,
and the save sub-directory contains a flag file called 'AUTOSAVE'. This means you only see a single dialog on first-shutdown.
Otherwise it behaves the same as the previous version.

[gyrog]

I've uploaded 'mk-savespec-3.sfs' to https://www.mediafire.com/folder/ufo1lerdg73j0/savespec.

Load it with "sfs-load" and it should show in the "Setup" menu as "Make SAVESPEC file".

'mk-savespec' is a GUI utility to create a SAVESPEC file that will reference a selected directory.
The generated SAVESPEC file can be saved to a selected location on disk.

This version introduces the option of writing it to a "multi-session" capable DVD, instead.
if you save it to a DVD, you only get one go, this utility does not support replacing existing files on a DVD.

Writing to DVD is now possible because the sfs includes a CLI utility 'file2dvd'.
This utility can write 1 (or more) files to an "open" DVD, i.e. suitable for use by multi-session.
Enter the command "file2dvd' in a console to see it's "usage" message.

[gyrog]

I've uploaded 'mk-savespec-4.sfs' to https://www.mediafire.com/folder/ufo1lerdg73j0/savespec.
It's just to fix an icon problem it had on some Puppies.

[gyrog]

I've uploaded 'ie-update-bionicpup32.tar.xz' to https://www.mediafire.com/folder/ufo1lerdg73j0/savespec.
It contains a replacement 'initrd.gz' and a 'ydrv_upupbb_19.03.sfs'.

I've also uploaded 'ie-update-fossapup64.tar.xz' to the same place.
It contains a replacement 'initrd.gz' and a 'ydrv_fossapup64_9.5.sfs'.

These contain the changes to woof-ce developed in the 'init-experiment' branch,
which encapsulates the following 3 projects from "Cutting edge":
"'init' script doesn't always wait appropriately - 'wait4usb' limitations" -> viewtopic.php?f=66&t=1059,
"pupmode=66 - a simple save mechanism that can be used on any filesystem" -> viewtopic.php?f=66&t=2346,
and this project.

They also include the "mk-savespec" utility and the "lsaufs" CLI utility.
'ie-update-fossapup64.tar.xz' also includes "mokutil" a CLI utility to manage MOK's (Machine Owner Key) on uefi booting machines.

To use:
Choose a fresh bionicpup32 or fossapup64 frugal install directory, preferably before first-boot.
Any existing 'initrd.gz' in the directory will be clobbered, so you might want to rename it out of the way, and the same if you alredy have a 'ydrv_...sfs'.
Then extract the contents of the corresponding 'ie-update-...tar.xz' into this directory and boot the Puppy contained in the directory.

[Clarity]

I have a couple questions about SAVESPEC. They are more general and are NOT asking for changes or repairs. It's more about how best to implement in the SG2D use I (and others) are using. As you remember, SG2D USB boots modern PUPs directly from their ISO files.

This question arose recently for me when I was attempting to boot @666philb's ImpPUP64. The pristine boot was confused (and hung on one occasion) on one of the PCs in this KVM configuration.

Turns out in comparison with other PCs, where it booted correctly, it was NOT correctly booting BECAUSE it had 3 SAVESPEC files in 3 different locations at boot time. Deleting all 3 on that PC allowed the PUP to boot to desktop, as is expected with ALL current modern WoofCE PUPs.

More information:
Configuration Layout

1. At Shutdown on ALL PUPs/DOGs I save the pristine sessions in a '/Sessions' folder; for example in that folder one finds other save-sessions named "some-pupsave".

   

   SessionFolder on PC1.jpg (17.56 KiB) Viewed 3666 times

   • There is ONLY 1 Session folder per PC!

   • The partition that a /Session folder resides may different for each PC.

   • In the pic, /Session is on partition 7 of its PC.

2. All PCs are booted from the exact same SG2D USB where their ISO files are maintained in a folder on the USB /BOOTISOS'

4 PCs to KVM with folders - small.jpg (27.24 KiB) Viewed 3666 times

SG2D presents the list of ISO files it finds as well OS(s) it finds on a PCs' system drive.

Boot Process

1. When a PC is booted it presents the ISOs and I select a PUP. In the problem case it was ImpPUP64.

2. I select a PUP and the PUP presents its menu. I hit 'e' and add to the linux line

   Code: Select all

   ...psave=sda7:/Sessions/

   afterwhich the boot process is started and, until the one case already reported, the PUP boots to desktop.

The single ImpPUP64 case is the ONLY time over the past 2 years of this problem. The one thing I did NOT do before discarding all 3 SAVESPEC was to save them for review. This was because I was unsure if it was the problem I was having; thus I was just trying something to get the PUP to boot. This problem has NOT re-occurred and I do NOT have 3 SAVESPEC files on any of the PCs.

The location of the 3 different SAVESPEC files before discard were

• within the USB folder ('/BOOTISOS') with all ISO files

• the root of the main system drive

• within the /Session folder on the main system drive

I am careful since finding this dilemma to insure that condition doesn't arise.

MY QUESTIONS

1. For this configuration what contents (lines) do you recommend the SAVESPEC contain?

   • (the above SAVESPEC in the /Session folder shows

     Code: Select all

     SS_ID='Linux'
     SS_DIR='/Sessions'
     SS_MEDIA='atahd'

     as its contents.)

2. Under what conditions could a SAVESPEC land in places different from the /Session folder?

3. Is there a search hierarchy that the boot process uses to find a SAVESPEC for instructions?

4. Does the psave boot parm impact the SAVESPEC processing during boot?

5. Is there a manual utility that will generate a SAVESPEC for personal inspection?

Again, this does NOT seem like a bug, nor does it seem that SAVESPEC generation is in error. I am sure that over the years of booting various PUPs at various times under various conditions, I have created the problem. I now know what to look for if it occurs again. Yet, if I know the answers to my questions, I can easily ID the proper SAVESPEC to keep in the future.

Again, this single case is the ONLY problem, EVER, in booting modern PUPs/DOGs via a SG2D USB in 2 years. And its a case that I generated without knowing the answers to the above. I would hope that the SAVESPEC would reside in the Save-Session folder; namely "/Sessions".

A recommendation is appreciated.

[gyrog]

I'm assuming that '/BOOTISOS' is shared between computers, but each '/Sessions' is local to each computer, and can not be seen by the other computers.

For this configuration what contents (lines) do you recommend the SAVESPEC contain?

• (the above SAVESPEC in the /Session folder shows

  Code: Select all

  SS_ID='Linux'
  SS_DIR='/Sessions'
  SS_MEDIA='atahd'

  as its contents.)

The "SS_ID='Linux'" line says that the '/Sessions' directory resides on a partition with a Label of 'Linux', it could also be the UUID of a particular partition.
With a single SAVESPEC file in '/BOOTISOS' with the above contents, you would have to have a local partition on each computer with a Label of 'Linux', whiich would contain '/Sessions'.
Using a UUID won't work for you, since it's unlikely that you would have a local partition on each computer, each with the same UUID.
By default a Linux partition does not have a Label, you have to specify it. The easiest way is to specify a "Label" when you create the partition in 'GParted'.

Under what conditions could a SAVESPEC land in places different from the /Session folder?

When directly booting an ".iso" file, none.

Is there a search hierarchy that the boot process uses to find a SAVESPEC for instructions?

No, 'init' processes only 1 SAVESPEC, which has to be in the same directory as the ".iso" file you are booting.

Does the psave boot parm impact the SAVESPEC processing during boot?

psave does basically the same thing as a SAVESPEC file, i.e. specifies the "save loaction".
If both are present for a boot, the 'init' script should give precedence to the SAVESPEC file.

Is there a manual utility that will generate a SAVESPEC for personal inspection?

Yes, it's called "Make SAVESPEC file", see viewtopic.php?p=10222#p10222.

[gyrog]

Mistake, please ignore.

[Clarity]

@gyrog Thanks you very much for clearing things in your response.

I'm assuming that '/BOOTISOS' is shared between computers, but each '/Sessions' is local to each computer, and can not be seen by the other computers.

Yes, the same USB which contains the ISO files (/BOOTISOS folder) is switched via the KVM to boot each PC when they are each booted.

The "SS_ID='Linux'" line says that the '/Sessions' directory resides on a partition with a Label of 'Linux',

And on one of the PCs, its sda7 partition is named 'Linux', and ext4 as you note. In almost (on rare occasions I might note when doing problem investigations) ever case, I will boot any PC with its psave...no matter if it is pristine or has a session saved. This way, all save-sessions land in that folder on each PC. /Session is individual to every PC I have. And ALL ISO files are kept on a USB (created using SG2D) in /BOOTISOS for this scenario.

As you surmised, this is also "Good Housekeeping" keeping consistent files in consistent libraries.

Is there a search hierarchy that the boot process uses to find a SAVESPEC for instructions?

No, 'init' processes only 1 SAVESPEC, which has to be in the same directory as the ".iso" file you are booting.

From a prior discussion months ago, I have made it a point to NOT keep a SAVESPEC with the ISO files; instead allowing the system to create a SAVESPEC in the Sessions folder.
REason: A /Sessions folder does exist on other PCs but the partition's label maybe (are) different on the other PCs ... not 'Linux' ... say 'DATA' or something else, depending on the PC. The idea is when the system creates the save-session, it also creates the SAVESPEC in the same folder as the save-session. Once it is created, EVERY PUP ISO that boots will find the PC's SAVESPEC matching the Partition layout of its PC. This is the behavior one would want; namely to have a SAVESPEC that accompanies the PC... not the ISO. This way the PUP boot process wotheuld find a SAVESPEC matching the PC.

This would allow the USB with the ISO to be used anywhere and if the PC it is used for booting has its SAVESPEC file, the PUP will find accurate needs for booting.

Does the psave boot parm impact the SAVESPEC processing during boot?

psave does basically the same thing as a SAVESPEC file, i.e. specifies the "save loaction".
If both are present for a boot, the 'init' script should give precedence to the SAVESPEC file.

You know, based upon your advice awhile ago, I remember testing this. I cannot remember why I have continued to use the psave at boot.
Edit: I remember why: For directing 'ALL" boots. If psave is NOT present, PUP boot process will never find the save-sessions nor will it find the SAVESPEC file.

QUESTION
Would you advise the SAVESPEC file to be kept on the root of the system drive and if so would the boot process find it there to know where the save-sessions are kept OR where to save a session at shutdown? If it works there, then that would solve and negate the need for using the psave parm and the boot process would find its needs. Hummm???

Otherwise in the KVM cases for booting PUPs via ISOs the /Sessions folder via the psave would continue to be necessary to find and boot with save-sessions; unless there is a way to instruct the boot process presumably via the SAVESPEC to check all system partitions for a /Sessions folder (SS_Dir).

Edit2: Just ran a test on a pristine boot of a modern PUP with NO SAVESPEC in the /BOOTISOS folder. Results: ...

[Clarity]

@gyrog Thanks you very much for clearing things in your response.

Edit3: HOLD THE PRESS! I may be wrong in how this is working in boot processing. I am testing the most current WoofCE distros; ImpPUP64 & Slacko64 v005 and discovering some interesting observation that counters what I thought is happening during pristine boots in the presence of those of us who use KVMs and boot PUPPY ISO files directly.

I'm assuming that '/BOOTISOS' is shared between computers, but each '/Sessions' is local to each computer, and can not be seen by the other computers.

Yes, the same USB which contains the ISO files (/BOOTISOS folder) is switched via the KVM to boot each PC when they are each booted.

The "SS_ID='Linux'" line says that the '/Sessions' directory resides on a partition with a Label of 'Linux',

And on one of the PCs, its sda7 partition is named 'Linux', and ext4 as you note. In almost (on rare occasions I might note when doing problem investigations) ever case, I will boot any PC with its psave...no matter if it is pristine or has a session saved. This way, all save-sessions land in that folder on each PC. /Session is individual to every PC I have. And ALL ISO files are kept on a USB (created using SG2D) in /BOOTISOS for this scenario.

As you surmised, this is also "Good Housekeeping" keeping consistent files in consistent libraries.

Is there a search hierarchy that the boot process uses to find a SAVESPEC for instructions?

No, 'init' processes only 1 SAVESPEC, which has to be in the same directory as the ".iso" file you are booting.

From a prior discussion months ago, I have made it a point to NOT keep a SAVESPEC with the ISO files; instead allowing the system to create a SAVESPEC in the Sessions folder.
REason: A /Sessions folder does exist on other PCs but the partition's label maybe (are) different on the other PCs ... not 'Linux' ... say 'DATA' or something else, depending on the PC. The idea is when the system creates the save-session, it also creates the SAVESPEC in the same folder as the save-session. Once it is created, EVERY PUP ISO that boots will find the PC's SAVESPEC matching the Partition layout of its PC. This is the behavior one would want; namely to have a SAVESPEC that accompanies the PC... not the ISO. This way the PUP boot process wotheuld find a SAVESPEC matching the PC.

This would allow the USB with the ISO to be used anywhere and if the PC it is used for booting has its SAVESPEC file, the PUP will find accurate needs for booting.

Does the psave boot parm impact the SAVESPEC processing during boot?

psave does basically the same thing as a SAVESPEC file, i.e. specifies the "save loaction".
If both are present for a boot, the 'init' script should give precedence to the SAVESPEC file.

You know, based upon your advice awhile ago, I remember testing this. I cannot remember why I have continued to use the psave at boot.
Edit: I remember why: For directing 'ALL" boots. If psave is NOT present, PUP boot process will never find the save-sessions nor will it find the SAVESPEC file.

QUESTION
Would you advise the SAVESPEC file to be kept on the root of the system drive and if so would the boot process find it there to know where the save-sessions are kept OR where to save a session at shutdown? If it works there, then that would solve and negate the need for using the psave parm and the boot process would find its needs. Hummm???

Otherwise in the KVM cases for booting PUPs via ISOs the /Sessions folder via the psave would continue to be necessary to find and boot with save-sessions; unless there is a way to instruct the boot process presumably via the SAVESPEC to check all system partitions for a /Sessions folder (SS_Dir).

Edit2: Just ran a test on a pristine boot of a modern PUP with NO SAVESPEC in the /BOOTISOS folder. Results: ...

[gyrog]

@Clarity,
The whole point of a SAVESPEC file is to define where the save directory is located.
It can not be found if a SAVESPEC file is created in the save directory which is not the same as tthe install directory.
( need the SAVESPEC to find the SAVESPEC)

The current 'init' script will find and process a SAVESPEC file in 2 places:
1. Normally the SAVESPEC resides in the install directory along with the 'puppy_...sfs'.
This is where the 'shtdownconfig' script will write a SAVESPEC, if the selected save directory is not the same as the install directory.
Locating the install directory, where the 'puppy_...sfs' resides, is done very early in the 'init' script. It's a fatal error if it fails to do this.

2. When directly booting a ".iso" file the install directory is the ".iso" itself, i.e. where the 'puppy_...sfs' is loacated.
So a special case is provided to look for a SAVESPEC file in the same directory as the ".iso" files, since this is a location that 'init' knows about, actually it's all handled in a sub-file to 'init' called 'isoboot'.

So, the only way I can see for you to use the current SAVESPEC, is to have a single SAVESPEC in the directory that contains the ".iso" files. It's the only location where the SAVESPEC file will be found and processed.
Since the Label of a partition is user defined, you can Label the partition that holds the "/Sessions" directory on each computer with the same Label. This should not cause a problem with the OS, provided that each of these partitions is really local to each computer.

Otherwise you are requesting a change to 'init'.

[Clarity]

Hi @gyrog, yes, I am finding that.

The only way around the problem is to somehow have,

• in the absence of a SS_ID='Linux' line AND

• in the presence of a SS_MEDIA='atahd'

to search the system drive's partitions for the SS_DIR='/Sessions' folder

This would be the only current way for a KVM switch arrangement to exist with multiple PCs where a single PUP used Sessions folder exist for all the saves that might boot on any individual PC in the hive.

This would allow the ISO file to boot, use the SAVESPEC in the ISO folder and find the save-session for the booting PUP.

Further, there would be a requirment for pristine boots at shutdown to check for an existing SAVESPEC and insure any update would NOT challenge the existing SAVESPEC's intent.

And, of course, the system knows of USB hubs and KVM switches it see in its hardware inventory. You have seen this thread before.

On another finding
I am finding an interesting boot arrangement of ISO file boots where it is becoming apparent "why" I have been using psave on ALL PUP boots. This I feel should be an off-line discussion as you are the best developer with the greatest understanding of Puppy Linux boot processing to cover this with.

Summary
All of this arises from the increased use of ISO file booting that continues in 2021. Seen here via these instructional posts:

• https://forum.puppylinux.com/viewtopic.php?t=4161[/uror DOGl]

• [url]https://forum.puppylinux.com/viewtopic.php?t=3680

• And more generally in this forum section

All of this is aimed at a consistent effortless Frugal; with the aim to eliminate past member issues in Frugal USB setups.

If I can overcome this hurdle, no member should have problems in Frugal/pristine use of any PUP in the future; no matter which of the published boot processes they venture on their hardware environmental setups...BIOS/UEFI.

[gyrog]

I've uploaded 'MakeSAVESPEC_AppDir-5.tar.gz' to [url[https://www.mediafire.com/folder/ufo1lerdg73j0/savespec[/url].
It's the 'mk-savespec' utility as an AppDir, a portable application.

The GUI has been simplified, so that the option to write to a DVD is in a separate dialog that is only shown if "pmdeia=cd".

[gyrog]

Info on AppDir, viewtopic.php?t=4789

[Clarity]

Hello @gyrog

In an earlier post, you outline the processing hierarchy of INIT when PSAVE is specified by the user and a SAVESPEC file is present.

In this case, the user indicates the drive partition and folder of location of the place to find (or place) the save-sessions. There are 2 conditions that I ask you to consider the SAVESPEC logic when the user specifies a PSAVE:
(Assume that there is a SAVESPEC file exist presently for each condition, below)

1. On Pristine boot

   • Here the user is indicating 'where' they want the save-session, at shutdown, to be placed which "could" be different from what is present in SAVESPEC file.

2. On any subsequent boot where the desired session is saved at the PSAVE location

   • Here the user is indicating 'where' a save-session resides which "could" be different from what is present in SAVESPEC file.

If I interpret your earlier response, SAVESPEC presence will, in each case, IGNORE the user wishes when the user specifies PSAVE at boot. If true can you see the confusion that surfaces where the user is unaware that the system is over-riding user intention without notifying the user it is doing so?

I am not sure you intend to overrule the user's request. I think this is an error...not in something broken, rather, is proper handling.

All other SAVESPEC operations, when PSAVE is not used, are perfect. I do see PSAVE and SAVESPEC intending to work together as a proper view. There should not be an "either-or" and certainly there should NOT be a "either-or" for the myriad of PUP users who boot their PCs unaware that this is happening.

Do you agree?

[Clarity]

Will the SAVESPEC maker utility become a utility in WoofCE PUPs?

Specifically "mk-savespec" or something similar for user-use to generating this requirement?

Could this be presented to WoofCE for consideration and addition?

[gyrog]

I've uploaded 'mk-savespec-6.sfs' and 'MakeSAVESPEC_AppDir-6.tar.gz' to http://www.mediafire.com/folder/ufo1lerdg73j0/savespec.

Current Puppy gives users the freedom to specify the "save location" anywhere, this includes the freedom to "shoot yourself in the foot".
Unfortunately this "trap" has not been documented.

This version of 'MakeSAVESPEC' includes a warning of this "trap" in the 'save location' dialog.

Some background:

The base filename for a Puppy savefolder/savefile is defined by the Puppy version, i.e. 'DISTRO_FILE_PREFIX' in '/etc/DISTRO_SPECS',
e.g. for 'xenialpup' it's always 'xenialpupsave'.

When a "save location" is specified, Puppy takes the specified directory, prepends the mount-point of the specified partition,
and then looks in this directory for files with names that start with the savefolder/savefile base filename for the Puppy being booted,
if it finds such a file then it uses it, and boots in an appropriate mode.

Result:

If multiple copies of the same Puppy are installed and the same "save location" is specified for each of them,
they will all use the same savefolder/savefile.
Only the first boot of the first copy installed will actually boot as a "first boot".
The first boot of any following copies will find the existing savefolder/savefile and boot accordingly.
In this context, a re-master is just another copy of the parent Puppy.

Solution for frugal installs:

When specifying a "save location", make it unique for each frugal install using a unique sub-directory.
While it's not necessary when there is never more than a single copy of any Puppy installed,
it's a safe habit to aquire.
e.g. Install xenialpup in '/pups/xenial' on 'sdb9', and use a "save location" in '/psaves/xenial' on 'sdc9'.

Notes:

Of course this issue does not arise if a "default" frugal install is performed, i.e. do not specify a "Separate save loaction".
Puppy will assume that the "save location" is the same as the "install location" and the savefolder/savefile will appear beside the other Puppy files of the frugal install.

[Clarity]

Thanks @gyrog for this update.

It intends to make the persistence 'clearer' for users.

In my observation, users have been "shooting themselves in the foot" for years.

If time permits, I will try to document some use cases for users to visualize meaningful housekeeping as well as meaningful management of the persistence files. This includes suggested folder names as wlll as ways to attempt management of the various REMASTERS where the Puppy Remaster Subsystem, currently, does not provide the user the necessary freedom to have a unique name for his remaster such that its name and its persistence is NOT identical to the original PUP author-developer's PUP.

An example of this is found with the MANY flavors of FossaPUP64 Remasters that are found across the forum where its system name (seen in Conky, Hardinfo, PupSysInfo, etc) ALL save there persistence session filenames as FossaPUP64save... This should NOT be allowed as @666philb did not create the 'new' remasters by other PUP members. So we need a mechanism to differential the work of the author from the work of those 'new' contributors. BTW: this is NOT limited to FossaPUP64, as it occurs with ALL of the PUPs presented from the WoofCE developers. Thusly it affect the WoofCEs generated by @01micko, @peebee, and any others too.

This problem DOES NOT exist with WoofCE generated PUPs, IIRC.

This shortcoming, it is hoped that development sees this, and will take the steps to FIX the shortcoming in the Remaster subsystem.

Great work, again, from your 'sighted' efforts for our understanding. Thanks

BTW: This is NOT a negative of the good work that the members using remasters produce. I find their work compelling, too. But this rename "SHOULD" be created, either optionally or forced, when the Remaster subsystem is used. The users have no hand in this problem, as this subsystem is generated at the WoofCE build which encorporates Remaster into the build.

One option is to force a timestamp onto the name of the newly remastered PUP. Where its persistence would be named, using a fossapup64 remaster for example, 'Fossapup64savetimestamp-..."

The developers would best know the kind of solution they are most comfortable with.

[Clarity]

Hello @gyrog

The SAVESPEC file, essencially is a 'conf' file for WoofCE PUP's sessions.

As you know many conf files for all sorts of packages offer the ability for comments to be within their config file(s). For example:

Code: Select all

# Alsa kernel modules' configuration file.
# - https://gitweb.gentoo.org/repo/gentoo.git/diff/media-sound/alsa-utils/files/alsa-modules.conf-rc?id=56bd759df1d0c750a065b8c845e93d5dfa6b549d

# ALSA portion
alias char-major-14 soundcore
alias char-major-14-* soundcore
    o
    o
    o

Question
Does SAVESPEC operate with a similar ability for comments within it?

[gyrog]

@Clarity
Yes it should, but I've never done it.

The 'init' script does not process a SAVESPEC line by line,
it "includes" the whole file, i.e ". /path/to/SAVESPEC".
So it is treated as extra script code, therefore scripting rules apply.
The variables SS_ID, SS_DIR, and SS_MEDIA, are then processed by name, if they are set.

[Clarity]

I will test (and will report) use of this file booting WoofCE PUPs

Code: Select all

# This file, if present, will be used by WoofCE PUPs at boot time.
# The file sets the SESSIONs directional for the booting distro.

# Indicate the label or UUID containing Sessions
SS_ID='Persistence'
# Indicate the folder containing Sessions
SS_DIR='/Sessions'
# Indicate the media type device containing Sessions
SS_MEDIA='atahd'

to replace this

Code: Select all

SS_ID='Persistence'
SS_DIR='/Sessions'
SS_MEDIA='atahd'

[Clarity]

Report
Embedded comments do NOT affect WoofCE PUPs ability to find its Sessions in preliminary tests.

I think comments would be helpful when developers/users need arise to review the file contents.

[gyrog]

@Clarity, Thankyou for testing.
Though I am not surprised by the result.

I'll put adding your comments to any generated SAVESPEC file, on my todo list.