How to make an app into an .SFS file that loads at boot?

[xeroye2038]

First of all thanks for all the great work that's being put in puppy linux.

I'm using puppylinux, FossaPup64 and boot it with ventoy.
And it works great, I've downloaded libre office .sfs file and load that to run it as well.
My question is, How to create custom .sfs file for jq (JSON parser) and mpv's config files, so it would work when loaded?

also is there a way to load it into ram at boot?
Thanks again.

[davids45]

G'day xeroye2038,

If you just want to turn a simple directory into an sfs, the attached script could do that. It runs in 32 and 64 bit Pups as far as I know.

Remove the fake .gz from its name and copy/save it to somewhere you like (and can find again).

Drag the saved script to the desktop and then drag the directory you want made into an sfs onto the script icon.

A terminal will then do the creation. Check where the sfs is made to.

For an executable application, the directory should consist of ALL the files in the sub-directories for the program files (eg a /usr/, /usr/bin/, usr/share/applications/ and so on).

Check any sfs that's made by temporarily Mounting in to 'View' its files then Unmount it before trying to actually run it?

A more complex sfs creator to try is PADS by taersh on the forum.

David S.

[mikeslr]

My question is, How to create custom .sfs file for jq (JSON parser) and mpv's config files, so it would work when loaded?
also is there a way to load it into ram at boot? Thanks again.

Tackling the last question first. I'm not sure I know what you mean. If you are running a Frugal Puppy with a SaveFile/Folder, executing a Save while an SFS is loaded should result in it being automatically loaded on bootup. Saves preserve your current settings. If you want the application to open as soon as you boot, you can drag either its desktop or executable [may vary with the applications, so experiment] into /root/Startup and preserve that setting by Saving.

Creating a link in /root/Startup applies without regard to any other hoop you may have to jump thru to get your system to use the application.

If you mean that you want to have an application available and open without employing a SaveFile/Folder you'll either have to remaster or employ the save2sfs module of nicOS-Utitlity-Suite, viewtopic.php?p=12983#p12983. That module will convert a SaveFile/Folder and/or just your current configuration into an adrv.sfs or a ydrv.sfs either of which are automatically used by Puppys on bootup. But they won't include applications.SFSes.
I'm pretty sure both the remaster module of that Suite or shinobar's remaster-x, https://oldforum.puppylinux.com/viewtop ... de#p780345 lack that capability.

AFAIK, to have an application available and open on boot-up when not using a Save/File folder you'll have to employ some structure other than an SFS. Not much is lost as the main advantage of an application.SFS is that you can unload it. Rather than creating an SFS, use or create a pet and install it before remastering or using Save2SFS. [If you know where all an application's files belong, you can just put them in their proper places rather than creating a pet].
To create a pet from an SFS:
(1) Create a folder --with an appropriate name-- to hold the files, e.g. my-toy.
(2) Left-Click the SFS and select "View Contents".
(3) From the window which opens, Left-Press, hold, then drag all its files and folders into your "my-toy" folder.
(4) Left-Click the SFS again to unmount it.
(5) Right-Click the "my-toy" folder and select "Create a pet package". If that's not on your Right-Click menu, open a terminal in "my-toy"'s parent folder and type the command: dir2pet my-toy -- or whatever name you gave the folder.
The second disadvantage with not using SFSes is that the libraries and instructions required by one application may conflict with those required by another. Unloading SFSes can avoid that. But installing a pet may over-write that which is needed by another application. There may, however, be a couple of solutions:
Rather than creating a pet, once you have your 'my-toy' folder populated, you might create an AppImage, viewtopic.php?p=3250#p3250. You can place that AppImage in /opt together with appropriate links and files to create menu entries, and link into /root/Startup. [IIRC, MikeWalsh has a post somewhere detailing that].
The other alternative is, again locating it in /opt, place the extracted SFS Folder there together with a launcher script compelling the application to look only within its own folder for libraries. [If you examine an SFS-loaded libreoffice, you'll find almost all of its files are in a folder in /opt. And examination of fredx181's and MikeWalsh's portable applications --particularly firefox's 'ff' script, or a Google-Clone's chrome-pup script-- you'll see what I mean]. But, unfortunately, I haven't yet gotten my head around that concept.

In case you've gotten lost, all the above is done before you remaster or create a ydrv-or-adrv using Save2SFS.

About having an application's settings/configurations load on boot-up --again assuming that you aren't employing a SaveFile/Folder -- you may have to isolate those and copy them to be used as explained below.

[There might be a way to 'lock in' your preferences with some remaster application, but I don't know. It's been quite awhile since I've done a remaster: the Save2SFS module is easier to use, quicker, and accomplishes everything I want. And when doing remasters my intent was to publish for other to use so I wasn't concerned with preserving settings and configurations unique to my system and aesthetics.]

'Locking in' your setting may depend on where those settings are located. Save2SFS preserves some, but not all. But, as that is the easiest way to proceed, try it first. However, rather than deleting the files a new adrv or ydrv replaces --i.e., the old adrv and/or ydrv and the SaveFile or Folder-- move them to where they would NOT be loaded but remain available if you have to revert.
The default setting for libreoffice writer is to italicize everything after you press the / key. That makes a mess out of trying to communicate "/root/my-applications/bin". To avoid this I do the following:
Load LibreOffice. Change its settings. Execute a Save. The contents of a SaveFile/Folder have priority over those of an Application SFS. Unload LibreOffice. Your settings are still in the SaveFile/Folder --they are not unloaded. So when you Save2SFS they become part of your adrv/ydrv and still have priority over the loaded SFS. I think the same will apply if you extracted LibreOffice and located it in /opt. LibreOffice writes its settings to /root/.config/libreoffice which is preserved by Save2SFS.
Another way would be to SFS load an application, make your settings changes, then copy the files and folders containing those changes into their corresponding locations in the --for example-- 'my-toy' folder you created to repackage your application.
Most settings are written to either a specific application in /root or /root/.config. Note the '.'/dot indicating a hidden file. Click Rox's 'Eye' to see them. Before making your settings changes open two rox windows (with hidden files shown) to /root and /root/.config so that you can see if your application writes its settings to either.

[amethyst]

It seems like he is working without a savefile. I agree Save2sfs option to save the configurations (not just of the two application but all system changes) to an adrv seems to be the easiest to achieve the desired result. But doesn't Fossa already have an adrv for its applications? If the latter is the case, the applications' adrv should be renamed to an ydrv so that the newly created adrv for the configurations take preference.

[mikewalsh]

@mikeslr :-

Mike:-

Fred's come up with a new script for turning any application which has everything in one folder - like my 'portables', for instance - into an AppImage, by judicious editing of that script.

viewtopic.php?p=28697#p28697

I've been experimenting with it the last few days (I've already published an AppImage of the current release of Chrome, for example):-

viewtopic.php?p=28949#p28949

.....and have just used it to successfully build an AppImage of Master PDF Editor.

Things are set-up so that you can name your profile/.config to whatever you want, and when you run your AppImage for the first time, it will create the profile/.config directory beside the AppImage, at the same level.

Conceivably the OP could run his 'Live' Puppy/whatever, then plug in a flash drive containing AppImages of applications he wants to run, and run 'em from there. These things don't need to be 'loaded' at boot, since they just 'run' as soon as you click on 'em.

Mike.

[amethyst]

@mikewalsh - do app images (with existing configurations) have preference to base files when in operation? If your specific application configurations change frequently app images should work well. I still think running a very small adrv only for ALL your system/applications configuration changes works very well. My adrv is about 5mb and it can at any time be updated with changes. I just run a script which takes 5 seconds.

[xeroye2038]

I apologize for the confusion, since I don't seem to be able to phrase what I need.
I'm using ventoy to boot puppylinux ISO file, so I need to boot everything into ram with pfix=ram, then remove the usb flash drive and re-insert it again to access the data on the drive.
Which is great on it's own, but sometimes I need extra stuff to use and I don't have internet connection to download what I want, so I want SFS modules available to rapidly add those features, for e.g. certain configuration for mpv, jq, ffmpeg, youtube-dl, etc, and by simply loading those, I can get a puppy linux with similar tools to my linux desktop on my USB flash drive.

G'day xeroye2038,

If you just want to turn a simple directory into an sfs, the attached script could do that. It runs in 32 and 64 bit Pups as far as I know.

Remove the fake .gz from its name and copy/save it to somewhere you like (and can find again).

Drag the saved script to the desktop and then drag the directory you want made into an sfs onto the script icon.

A terminal will then do the creation. Check where the sfs is made to.

For an executable application, the directory should consist of ALL the files in the sub-directories for the program files (eg a /usr/, /usr/bin/, usr/share/applications/ and so on).

Check any sfs that's made by temporarily Mounting in to 'View' its files then Unmount it before trying to actually run it?

A more complex sfs creator to try is PADS by taersh on the forum.

David S.

Thanks for the reply.
I guess this is what I wanted but failed to phrase.
This only works for binaries if I'm planning to make executable applications into .SFS?
Does this use the same sfs file for the folders structure when using more than one folder? I mean if I used usr/bin then I used local/bin, does it create two separate sfs files or single one?

If you mean that you want to have an application available and open without employing a SaveFile/Folder you'll either have to remaster or employ the save2sfs module of nicOS-Utitlity-Suite, viewtopic.php?p=12983#p12983. That module will convert a SaveFile/Folder and/or just your current configuration into an adrv.sfs or a ydrv.sfs either of which are automatically used by Puppys on bootup. But they won't include applications.SFSes.
I'm pretty sure both the remaster module of that Suite or shinobar's remaster-x, https://oldforum.puppylinux.com/viewtop ... de#p780345 lack that capability.

Thanks for the detailed answer.
You're right, I'm running puppy linux without savepup file, Since I'm using ventoy to boot the ISO image, and don't want to remaster it since it would make it more "bloated", because the stuff I want to add aren't always wanted, but when i need it I'd like to load it at boot time.

It seems like he is working without a savefile. I agree Save2sfs option to save the configurations (not just of the two application but all system changes) to an adrv seems to be the easiest to achieve the desired result. But doesn't Fossa already have an adrv for its applications? If the latter is the case, the applications' adrv should be renamed to an ydrv so that the newly created adrv for the configurations take preference.

Similar to what you suggested, but only for certain stuff, is this even possible?

[amethyst]

Why do you want to copy to RAM at bootup? I would actually make pfix=nocopy for fast booting. Puppy is fast as it is so not really necessary to copy stuff to RAM at bootup as the necessary system files are decompressed at bootup anyway. I would just create a very small savefile on the usbdrive and use that to store all my configuration settings. Puppy should be able to pick up the savefile at bootup. Keep the flashdrive plugged-in. Also - if you boot from an iso directly, any changes to the Puppy files (base sfs, adrv, zdrv) will have to be re-constructed and a new iso created. That shouldn't be necessary.

[xeroye2038]

@amethyst

Because the way ventoy works, after booting the iso file the USB flash drive can't be mounted unless removed first and then re-inserted again.
And this is only possible when copying the whole thing into ram.
savefile is ok, but I don't need all the settings to be saved, since I'm probably booting on different machine/hardware, that's why loading .sfs files is better.

For e.g. Booting puppy linux on some PC to copy files over, I won't be needing the extra .sfs files to be loaded, or when booting puppy linux on some friend's laptop to work on my thesis, or watch a movie, I'd want to load the libreoffice .sfs file or my mpv config and get something to my liking.
I guess savepup, is something similar to what I'm getting at, but savepup save everything, including settings and such which is not what I want.
You can say I'm looking for a more modular approach.

[mikeslr]

I'm in a hurry and have forgotten what has already been posted on this thread. So forgive any duplication,

Almost any application can be rebuilt as an SFS even if you are working with a Puppy which doesn't have a SaveFile/Folder. Read the PaDS thread, viewtopic.php?f=106&t=933, and any links from it, especially the posts on the 'old forum' relating to the earlier version, https://oldforum.puppylinux.com/viewtop ... c5#p998922 for tips, advice, and restrictions.

One thing you'll discover using PaDS is that --drawing its files from an 'alien' distro-- it doesn't always result in an application with a menu entry (or a menu entry) in the category where you would expect to find it. Menu entries are generated by the arguments in the /usr/share/applications/...desktop files. These are text files you can edit with any text editor. However, to preserve the change you have to rebuilt the SFS.
To rebuild an SFS, you Right-Click it (to mount it) then copy its files into an appropriately named folder. Make any changes regaring the files in that folder. Then Right-Click that folder and select dir2sfs. If your Puppy doesn't provide that Right-Click option, Right-Click an empty space next to that folder, select Windows>terminal here, then enter the command dir2sfs NAME-OF-FOLDER; of course using the actual name of the folder.

Along the way, you will have created a folder in which all of an applications required files will be located. So, as an alternative, you may also be able to create an AppImage. See this thread. viewtopic.php?f=106&t=590. These also can be used by Puppys lacking a SaveFile/Folder.

In many instances you may also be able to download an application -- a pet, deb or other packaging format-- Right-Click it, and Select UExtract. You can similarly use the "extracted" folder to create an SFS --by dir2sfs-- or an AppImage.

fredx181 has been working on a slightly different way to create AppImages. See the discussion beginning here, viewtopic.php?p=28697#p28697. Later in that thread Mike Walsh expanded on the use of that technique. I haven't had a chance to work with it so can't presently tell you more.

Neither PaDS nor Create Portable AppImage will work with every application. And if the computer you are working with doesn't have any Linux formatted partitions, you'll have to do all your work in RAM: You can create temporary folders in /root for that purpose. Or, you can structure your USB-Key to have a Linux formatted partition.

When you SFS-load an SFS from a Puppy without a SaveFile/Folder, a GUI will open offering to copy it somewhere. The choice at the bottom of the options list --the one you would select-- is NO COPY. As I understand it, it will just be mounted with links in RAM being created as necessary to its files.
Similarly, AppImages are just mounted and linked to.

[taersh]

Hi.

I worked for some years on different tools to make Puppy able to be used in a much more modular way.
Running programs from .sfs modules via RunScripts just like they are installed.
With automated unload of .sfs modules after exiting the program.
Created some Programs to achieve parts of this for the community.

Though, I never have been really successful on this approach - except for my own use.
Still most Puppy users do use save files and/or save folders.

So, I almost gave up on this except for my own use.
Running my own Puppies still without any save file/folder for almost 10 years now.

Search in Forum Utilities for PaDS and SFS PLUS 2.

[Grey]

Though, I never have been really successful on this approach - except for my own use.
Still most Puppy users do use save files and/or save folders.

I have a save folder of about 60 gigabytes and at the same time I periodically make a backup of it. I just have the opportunity. Plus a habit. I can't say anything about other users.

[mikeslr]

By the way, because of he way you asked the question, perhaps no one has yet pointed out that you may not actually have to do much in order to have an application available shortly AFTER booting up.
When you first 'install' an application, its files are copied into appropriate locations in RAM. You can Menu>Exit>Restart-X (AKA Graphical Server) and Puppy will 're-catalogs' what makes up it's system. You'll probably now find a listing for the application on your Menu. If not, you should still be able to find its binary or the script or wrapper needed to run the binary with instructions.
SaveFiles/Folders are for preserving a condition in order not to have to start from scratch each time. SFSes, AppImages, even pets themselves, are constructed if for no other reason than that often, for an application to function, there must already be many libraries already present. I once used PaDS to build an application that had --IIRC-- 88 dependencies. It would have been sort of annoying if every time I wanted to to run it I'd have had to install it and 89 packages.

[amethyst]

@amethyst

Because the way ventoy works, after booting the iso file the USB flash drive can't be mounted unless removed first and then re-inserted again.
And this is only possible when copying the whole thing into ram.
savefile is ok, but I don't need all the settings to be saved, since I'm probably booting on different machine/hardware, that's why loading .sfs files is better.

For e.g. Booting puppy linux on some PC to copy files over, I won't be needing the extra .sfs files to be loaded, or when booting puppy linux on some friend's laptop to work on my thesis, or watch a movie, I'd want to load the libreoffice .sfs file or my mpv config and get something to my liking.
I guess savepup, is something similar to what I'm getting at, but savepup save everything, including settings and such which is not what I want.
You can say I'm looking for a more modular approach.

It's easy to make extra sfs's of your applications (and include the necessary configuration files if you know their location) but keep in mind that extra sfs's loaded during a session have a lower priority than your base sfs so any files which clash with files in the base sfs may result in problems running your application. However this situation does not occur often in my experience so in most cases you will be okay. I haven't used app images myself but it could be the better and easier option in your case.

[mikewalsh]

@amethyst :-

Nic;

@mikewalsh - do app images (with existing configurations) have preference to base files when in operation? If your specific application configurations change frequently app images should work well. I still think running a very small adrv only for ALL your system/applications configuration changes works very well. My adrv is about 5mb and it can at any time be updated with changes. I just run a script which takes 5 seconds.

I tend to agree with you. For relatively 'fixed' configurations that don't change very often, the adrv/ydrv idea is definitely better. For something like a browser, where stuff is constantly changing from session to session, the AppImage is probably more suitable.....and the way Fred's script works, the profile/config-stuff is created right alongside the AppImage, at the same level. So it's easy to locate.

As for "do they have preference to base files", umm.....it's not really an issue, since these unpack themselves into, and run from /tmp for the duration.

Mike.

[amethyst]

As for "do they have preference to base files", umm.....it's not really an issue, since these unpack themselves into, and run from /tmp for the duration.

How does this affect RAM usage?

[xeroye2038]

When you SFS-load an SFS from a Puppy without a SaveFile/Folder, a GUI will open offering to copy it somewhere. The choice at the bottom of the options list --the one you would select-- is NO COPY. As I understand it, it will just be mounted with links in RAM being created as necessary to its files.

Thanks for the reply, I looked into those links and I'll see how it will turn out.
As for the NO COPY option, while it does load to ram, it still access the .sfs module from the USB drive, Is this the normal behavior? because it doesn't allow unmounting the drive when .sfs file is loaded from it.

[amethyst]

Extra sfs's do not load into RAM (in other words the contents do not decompress fully in RAM) but the loading process itself uses some RAM about 10MB per extra sfs in my experience. That's why you can't unplug your drive.

[xeroye2038]

Extra sfs's do not load into RAM (in other words the contents do not decompress fully in RAM) but the loading process itself uses some RAM about 10MB per extra sfs in my experience. That's why you can't unplug your drive.

I see, is there anyway to make it load into RAM and decompress there? Or I have to copy the SFS over to the machine and load it from there?

[amethyst]

Extra sfs's do not load into RAM (in other words the contents do not decompress fully in RAM) but the loading process itself uses some RAM about 10MB per extra sfs in my experience. That's why you can't unplug your drive.

I see, is there anyway to make it load into RAM and decompress there? Or I have to copy the SFS over to the machine and load it from there?

You can manually copy the sfs to "RAM space" at any location in your running filesystem and load it from there (choose NOCOPY when asked). So your available RAM will reduce with the size of the sfs file. Sfs files are not actually decompressed fully as would happen if you unzip a folder that you compressed. It just gets loaded and the contents read. Being copied to RAM should make the application startup a bit faster. No real other advantages there and if you have limited physical RAM not recommended.

[xeroye2038]

Well. most laptops have at least 4 GB or RAM, so I guess it can be fine.
In worst case I'd copy the .SFS file to the HDD.
Is there a difference between the booting modes?
pfix=ram and pfix=copy?
What about media=cd vs media=flashdrive?

[amethyst]

Well. most laptops have at least 4 GB or RAM, so I guess it can be fine.
In worst case I'd copy the .SFS file to the HDD.
Is there a difference between the booting modes?
pfix=ram and pfix=copy?
What about media=cd vs media=flashdrive?

Yes. pfix=ram will result on Puppy operating fully in RAM and will not load any savefile/folder. pfix=copy is the default Puppy booting action. If you have enough RAM the base sfs and adrv/ydrv will be copied to RAM. That media paramater indicates which media you are booting from, media=flashdrive will also typically boot pupmode 13 when you have a savefile.

[bigpup]

media=flashdrive

The boot loader option is pmedia= to identify the type of drive Puppy is on.
pmedia=usbflash for usb flash drive.
pmedia=ataflash for internal flash drives like a SSD.
pmedia=atahd for internal or external hard drive.
pmedia=cd for a CD/DVD install.