sfs_load_alt-0.2 an alternate to sfs_load

Under development: PCMCIA, wireless, etc.
Post Reply
Message
Author
gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

sfs_load_alt-0.2 an alternate to sfs_load

#1 Post by gyro »

The file "sfs_load_alt-0.2.pet" is attached.
This is a utility to load and unload extra sfs files in a frugal install.
It's an alternate to the normal sfs_load, but it doesn't do a lot of the things sfs_load does, and it's not as pretty as the normal sfs_load.

But the one thing it does do, it does "better" than the normal sfs_load.
Whereas the normal sfs_load insists that extra sfs files should reside in the same directory as the savefolder,
sfs_load_alt will load, (and re-load at next boot) extra sfs files stored virtually anywhere.
This is because instead of storing only the base filenames of the extra sfs's, it stores a spec as <partition>:</relative/path/to/filename.sfs>, where the <partition> is specified by it's UUID.
During the boot process, it will even mount the partition if it has not already been mounted. And then umount it on shutdown.

This exists to fully support the "psave=" boot parameter.
Using the following boot parameteres:

Code: Select all

pupsfs=sda4 psubdir=/puppy/slacko psave=sdb2:/pups/
The frugal install directory containing the vmlinuz and puppy system sfs files, is on sda4 in the "/puppy/slacko" directory.
But "slackosave" resides on sdb2 in the "/pups" directory.
The normal sfs_load insists that "devx_slacko_6.9.6.7.sfs" should reside on sdb2 in the "/pups" directory, but I insist that it should reside in the frugal install directory with the other ro files.
Because sda is an SSD and sdb is a HD.
The whole point of separating the savefolder from the install directory onto a different device is to have the ro files on the much faster but much smaller device, the SSD, and the rw stuff on the slower but much larger device, the HD.

Usage:
After installing the pet, "sfs_load" is effectively replaced by "sfs_load_alt", in the menu and to "rc.sysinit" and "rc.shutdown".
So starting "sfs_load_alt" is the same as starting "sfs_load".

If there are any extra sfs's that have been loaded by "sfs_load_alt", it opens with a screen listing the loaded sfs files, and buttons to "Load", "Unload", or "Exit".
Otherwise there is no list and only 2 buttons, "Load" and "Exit".
To load an sfs, click "Load", this will open a file selection dialog to choose the sfs file. After the sfs is loaded, the main screen will be displayed with the sfs now in the list.
To unload an sfs, click on the name of the sfs file you want to unload and then click the "Unload" button. Once the sfs is unloaded, the main screen will be displayed with the sfs file no longer in the list.

"sfs_load_alt" does the following after-processing if required, mime, font, icon and menu.

During boot, if there is a problem with loading a particular sfs, it is simply omitted, it's spec entry is deleted, and all after-processing is done.

In the running system, if an sfs file fails to unload, it's spec entry is deleted and a flag file is created, so that during the next boot all afer-processing will be done.

Any error messages are written to "/tmp/sfs_load/sfs_load_alt.log".

It stores it's data and a conf file in "/root/.sfs_load/".

Warning: Since "sfs_load_alt" and "sfs_load" store the data specifying what extra sfs files are loaded in different ways and different places, they should be treated a incompatible.
Make sure there are no extra sfs files loaded before you change from using one to the other.

Edit:
This utility is meant to work with the new "init" script that contains no code to process extra sfs files.

gyro
Attachments
sfs_load_alt-0.2.pet
simply install
(8.05 KiB) Downloaded 205 times
Last edited by gyro on Tue 30 May 2017, 03:40, edited 1 time in total.

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#2 Post by nic007 »

Nice. Just a matter of interest. I use the older sfs_load and overcome the limitation by symlinking the extra sfs file (no matter where it exists) to either the root directory where the puppy files are installed or the folder where the puppy files are installed. For instance, I have the ydrv.sfs of another puppy symlinked to the directory of the running puppy.

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#3 Post by gyro »

@nic007,
Yes I could have created a symbolic link on the HD to the sfs file on the SSD, but if I ever removed my "pfix=nocopy", then the SSD would not remain mounted after the "init" script is finished, and the symbolic link would fail.

Besides, this is a proof of concept thing, given the new "init" script, sfs_load no longer needs it's current limitation.

gyro

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#4 Post by nic007 »

You can load the extra sfs files by adding a command line to /etc/rc.d/local for example, would that make a difference? I operate without a savefile and use this method. Of course, if you pack your xtra sfs's into an adrv or ydrv there won't be any problems.

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#5 Post by gyro »

@nic007,
Yes, there are many workarounds that I could use.
But why should I bother with them?
It's quite doable for sfs_load to simply do it.

gyro

Post Reply