woof-CE
woof-CE copied to clipboard
puppylinux-woof-CE
shutdownconfig: bug + SAVESPEC enhancement + autosave enhancement
In current Puppies it would seem that while the "CHANGE FOLDER" button is honoured in 'shutdownconfig', the 'init' script fails to use it.
My proposed solution is to enhance Puppy with a SAVESPEC facility, an enhanced back-channel from 'shutdowconfig' to 'init'.
Instead of "shutdownconfig' writing a 'SAVEMARK' file, it writes a 'SAVESPEC' file whenever a non-default partition or sub-directory is specified.
The 'SAVESPEC' file contains a "psave=" type spec, i.e.
Writing a 'SAVEMARK' file can indicate only a different partition on the installation disk, writing a 'SAVESPEC' file can indicate any partition and any sub-directory.
For some time now, Puppy has supported the save location being independent of the install location, but 'shutdownconfig' has not really reflected this. With these changes, it does a lot better.
See the savepec home page, http://www.fishprogs.software/puppy/savespec/index.html for download information.
***Edit To test, extract a 'savespec....tar.xz' file into a fresh frugal install of the corresponding Puppy and reboot. ***End Edit
To understand the changes, download 'woof.tar.gz' which contains the following files that relate directly to woof-ce files.
'init' A patched 'init' script
'init-savespec.diff' The patch to implement SAVESPEC. A 'SAVESPEC' file takes precedent over all other definitions of the save location.
'shutdownconfig' A patched 'shutdowconfig' utility
'shutdownconfig-savespec.diff' Implements the actual writing of the 'SAVESPEC' file at the end of 'shutdownconfig'
'shutdownconfig-partslist.diff' A patch to enhance the selection of partitions to be included in the partition selecion dialog. It currently accepts only partitions that are > 1GiB, to ignore things like boot partitions. It also accepts Linux partitions that are on any device, but other partitions must be on the install device.
'shutdownconfig-folder.diff' This removes the line from the change folder dialog saying that only single level sub-directories are acceptable, because this is no longer true.
Note1: The algorithm for ignoring some partitions process the output from 'probepart' line by line, so the details of the algorithm could be readily changed.
Note2: The change folder dialog in 'shutdownconfig' would be better as a directory selection dialog, if I were to implement this it would be with a yad dialog.
This has not been committed yet. Commnets/suggestions welcome.
When save to folders was introduced few years ago, I thought this ability would have surfaced as a lot of thought went into save-session save-folder save-file technology in Puppy. The save-folder(s) effort has a great benefit for lots of reasons. But, over time, since, I have run into an occasion or 2 where I had wanted to save-folder to a different pre-selected partition and was not allowed, even as a Linux partition was available.
On another note, associated with this thread, if a new folder (other than root) is changed, it would be nice if the save-session utility would "alert" the user via some message of the need to change the kernel's boot line to have an additional subfolder so that the booting system would know to look deeper into the partition(s) to find the save-session folder/file.
Just a thought.
If the save location is not specified by a "psave=" or "psavemark=" boot parameter, or a SAVEMARK file; this code will allow you to select any Linux partition (unless it is too small) and any sub-directory to store your savefolder. 'shutdownconfig' will store this selection in a SAVESPEC file which will be acted on by the 'init' script on following boots. There would be no need to change the kernel's boot line.
If the save location is specified by a "psave=" or "psavemark=" boot parameter, or a SAVEMARK file; 'shutdownconfig' will honour this and not display a partition selection dialog.
Although the SAVESPEC file is meant to be only internal, i.e. written by 'shutdownconfig' and read by 'init', the save loaction could be specified by manually creating a SAVESPEC file in the install directory.
The ydrv...sfs and woof.tar.gz files in the download directory have been updated with an "autosave" facility.
The "autosave" facility remains dormant unless an AUTOSAVE file exists in the install directory. It currently only works if the currrent save location is on a Linux partition, by creating a savefolder. On first shutdown, the user sees only the first 'shutdownconfig' dialog, clicking the 'SAVE' button proceeds to 'rc.shutdown' without further dialogs.
My plan is that the next version of "f2StickPup" will write an 'AUTOSAVE' file, so if the "autosave" facility is included in 'shutdownfigconfig' "f2StickPup" will produce a usb stick that automatically creates a savefolder in the f2fs partition on first shutdown.
The next version of "autosave" will include a pupmode=66, (just like "mio" pupmode=21), that saves '/initrd/pup_rw' to an archive file in 'rc.shutdown'. The 'init' script then extracts the contents of the archive file into '/initrd/pup_rw' in ram. "autosave" will use this pupmode for all non-Linux save partitions.
Then 'StickPup' can write an 'AUTOSAVE' file and produce a usb stick with automatic persistence.
The end goal is to produce usb sticks that are very easy to use as introductions to Puppy Linux.
I've uploaded files containing an updated "autosave" facility. The testing files are tar files, e.g. 'spec+auto_ScPup64-20.06.tar.xz', simply extract the tar file into the install directory of the corresponding Puppy, and it will replace the 'initrd.gz' and the 'ydrv...sfs'. I intend to replace the old testing files with similar tar files contianing only the "savespec" facility.
Now uploaded 4 'savespec...tar.xz' files. simply extract the archive into a fresh frugal install of the corresponding Puppy and reboot. I've edited the original post appropriately.
Quick test of BionicPup32 and ScPup32 - all seems OK.
What happens when booting from CD when the SAVESPEC can't be written?
...
...
@peabee, Thanks for testing.
If "pmedia=cd" then this stuff must be avoided. I'm not sure if this will happen with current code. I will try to trace what happens in 'shutdowconfig' for "pmedia=cd", (it's so long since I've booted from an actual CD). I'm not sure what options 'shutdownconfig' offers "pmedia=cd".
If CD booters choose pupmode=77, then there is no problem. But if they choose to save to a writeable disk partition, then this choice can not be recorded since the install directory is not writable. I note that 'initmodules' has a similar problem, and, if I remember correctly, it just gives up.
One obvious solution is for 'shutdownconfig' to only offer CD booters pupmode=77. Particularly as the "BootCD" option of "FrugalPup" enables a Puppy to be installed on some writable partition, but be non-uefi booted via a CD, (a uefi machine can most probably boot from a usb stick). But I suspect that some folk might object mightly if this solution were adopted.
Another obvious way is to enhance the "search" function in 'init' when "pmedia=cd", but I have no enthusiasm to do this, even though I do have a very low priority idea to split it into a "puppy serach function" and a "save search function" just to simplify 'init'.
The more general problem is that there is no default writeable location that is easily available to both the running system and the 'init' script, and be independent of the save mechanism since the information in it could be part of resolving the actual save location. So thinking a little outside the box, we could provide such facility by creating an easily identifiable partition, e.g. with a particular Volume Label. But the idea I am curently playing with is similar to an 'EFI system partition', i.e. a "vfat" partition with a specific flag root directory similar to the '/EFI'. This could be something like '/PLD' as in "Puppy Linux Definitions", or '/PLBI' as in "Puppy Linux Boot Information", so it would make sense to have it as another root directory in a "vfat" boot partition, even the real 'EFI system partition'. (I have a little script that can quickly find such a partition.) We could store the SAVESPEC (and initmodules) information under a Puppy ID based on $PUPSFS info as in '/etc/rc.d/PUPSTATE', only using the parition UUID rather than the partition name. This information is readily available to both the running system and the 'init' script.
@peabee, The short answer is that "savespec" will do nothing for CD booters, just like 'initmodules'. In the next version, I will change 1 line of code to ensure that it doesn't attempt to write a 'SAVESPEC' file if "$PMEDIA" is "cd".
The whole "Puppy Linux Boot Information" thingo looks like it would work fine, but becomes a pain if CD's are included, because 'busybox blkid' (as used in the 'init' script) does not provide a UUID for CD's.
Compared to easily re-writable devices with reliable UUID's and LABEL's, like HD's, usb sticks etc.., CD's and ISO's are frustrating, and trying to make things work with them is just too much hassle.
Sorry folks, I thought I was close to a real solution, but I've had to go back to the drawing board, so there could be a bit of a delay.
The problem with the "Puppy Linux Boot Information" thingo is that it's not obvious to the user that this partition is slowly being filled with different Puppy config files. Since this would all be happening automatically in the background.
I want 'shutdownconfig' to be able to change the save location and signal this new save location to 'init' via a "back-channel" file. So the "back-channel" file can't be written to the new save location. But I also want to be able to readily configure the install directory to be read only, so the "back-channel" file has to be able to be somewhere else. So I'm working on a "default save" location, as defined by boot parameters, and doesn't change, and writing all "back-channel" files there, (including 'initmodules'). My new solution might even be able to be used by CD booters, (perish the thought).
Now that I'm out of the "waiting" rabbit-hole, I am back here. The first set of commits to 'init-experiment' will be to implement a SAVESPEC file, a bit like a SAVEMARK file. Instead of writing a SAVEMARK file, 'shutdownconfig' will write a SAVESPEC file to the install directory when the save location is modified in 'shutdownconfig'. This SAVESPEC file can specify the save partition, the save directory and a PMEDIA that's appropriate for the save partition, rather than the install partition. The 'init' script will be modified to be able to process this SAVESPEC, if it exists.
I have given-up on trying to find a writable location that can work for all Puppy installs, so it's simply going to the install directory, just like the current SAVEMARK. However my plan also includes a "Save location" utility that can produce a SAVESPEC file for a selected directory. So if the user is not using a simple frugal install on a writable drive, they can generate a SAVESPEC for heir chosen save directory, and then inject it into the install directory, by what ever means they can, preferrably before "first boot". Of course a SAVESPEC file could be created by frugal install and moved to the install directory before "first boot", thus simplifying 'shutdownconfig'.
I'm thinking of changing the "Puppy" facility in "FrugalPup" to write a SAVESPEC file, instead of getting the "Boot" facility to generate a "psave=" boot parameter.
Here is the content of a typical SAVESPEC file:
SS_ID='Work'
SS_DIR='/tsaves/fossa64'
SS_MEDIA='atahd'
I'll ask this here as well as in the forum.
What partitions should be offered by 'shutdownconfig' if none is specified by PSAVEPART? Currently it offers all the partitions on the same device, but with SAVESPEC in place, we can now offer partitions on other devices. We could offer all known partitions. Or exclude small partitions < 600MiB Or add only Linux partitions from other devices, to the existing list. Or .....? My idea: 1 Exclude all small partitions 2 Add all Linux partitions 3 Add any other "big" partitions on the current device.
i'm not sure it this is a promise or a warning, but I haven't forgotten about the "aufosave" part of tthe title of this issue. My next patch to 'shutdownconfig' will include an "autosave" facility for saving on a Linux partition. It will automatically create a save-folder, but there will be some kind of trigger so it can be enabled/disabled by the user.
My goal is that "f2StickPup" will setup a usb stick so that the only question on first-shutdown is to save or not, and thereafter to run in pupmode=12.
These commits provide the last part of my "autosave" facility. A save facility that can always be safely invoked on a non-Linux partition.
pupmode=66 is very simple, although inefficient for long-term use (i.e. installing lots of .pet's). On shutdown, save the RW directory in RAM to an archive file, in this instance a "tar.gz" file. On boot, populate the RW directory in RAM from the archive file. (It's a bit like pupmode=77)
The point of all this is so that 'StickPup', 'f2StickPup' and my releases of Puppy as a ".zip" file will, by default, do first-shutdown with only 1 question, "Save" or "NoSave"? Although it will be easy to disable this by deleting the file named "AUTOSAVE".
The previous "autosave" for Linux filesystems, took care of 'f2StickPup'. This "autosave" pupmode=66 for "vfat" partitions takes care of 'StickPup' and "Puppy as a .zip file".
init-experiment branch:
I've committed the same 'shutdownconfig' bug fix to init-experiment as for testing, I simply didn't like leaving code out there, with a known bug with a known fix.
If the 'shutdownconfig' bug fix mucks up the possability of merging init-experiment with testing, then I suggest that init-experiment be deleted. I now have 4 patches for the recent pupmode=66 stuff that can apply directly against the current testing branch. I could maintain these patches against the testing branch for a while, hopefully until they are committed to testing. Or a new clone of testing could be generated, and I could directly apply these patches to that.
Well tis done.
'shutdownconfig' and 'init' are now consistent, but 'shutdownconfig' still provides wide options, in appropriate circumstances.
And, 'StickPup' and 'f2StickPup' can, and will, trigger automatic "save" creation, i.e. the only question on first-shutdown is to save or not to save.