Puppy Linux Discussion Forum

Using the -c switch to load from the command line, in the middle of execution it asks if you want to copy the .sfs you're loading to the root (/mnt/home for example with a pupsave) and proceeds to copy anyway without interactivity.

Example: 2 .sfs in image were unintentionally put there by sfs_load:

Is there an argument I'm missing to stop the copy?

You can't stop it from being copied because it's a safety measurement (unless you change the script itself perhaps, which will not be advisable). You can however avoid the nag screen by adding the -q option to the commandline.

-q is the copy confirmation? Help just labels it the "first".

I'm cramming in too many details to keep it all sorted, but my current belief is it doesn't happen every time.

I think one time I was actually able to enter a character, though not sure if "n" vs. "N" make a difference (i.e., it copies anyway).

If it asks if you want to copy in terminal and doesn't allow a choice, that's probably more like a bug.

Anyway I'm using scripts, more worried about slowing them down to see what is going on than reading all the output feedback.

I'm going to be doing this for a while 'til running browsers is fluid, will probably post more about it later.

No, -q stands for quiet. So if you use the correct syntax, ie. sfs_load -c -q [location and name of sfs].sfs in a script, you shouldn't get any pop-up messages. The sfs will still be copied automatically to the parent partition where your puppy files are if it is on another partition but you won't see a message.

The normal expected location for SFS packages to load is in /mnt/home
The top layer of the partition, the Puppy install is on, and outside of the save file/folder.

Why is it so hard for you to understand that stuff does not work exactly the same in all Puppy versions?
Well, very little does!

If you do not identify a specific Puppy version you are using to do this.
There is no way to give you specific information.

All programs that do things in Puppy Linux get tweaked, improved, changed, even turned over to using a totally different program.
Everything!
The commands available to use even change over time as program versions used change.

First needed info:
# sfs_load -v
sfs_load 3.1w

Inconsistency is a fact, and sometimes for the better.

By the look of my roxfiler window, I was in 32-bit Mainline Xenial, though those two browsers also work in Tahr which is the reason I use them. They're both Chromium 58 I suspect not coincidentally.

I ought learn about auto-running scripts in .sfs as they seem present like .pet.

What qualifies as a bug?

sfs_load 3.1w

The program waits a few seconds:

Do you want to copy '32Chromium65-Xenial.sfs' to '/mnt/home'(recommended)?
N

Capital or lowercase "n" or "no" with [enter] or not, the .sfs is copied to /mnt/home.

Unless there's an esoteric input that thwarts copying, I would consider this a bug in sfs_load.
@shinobar

Try nocopy as the response to the question.

bigpup wrote: Mon Oct 04, 2021 1:30 am

Try nocopy as the response to the question.

--nocopy displays the help menu.

-nocopy doesn't seem to do anything (the .sfs is still copied to /mnt/home).

In Tahr, sfs_load 2.3.7 using /usr/sbin/gtkdialog4,

sfs_load: --warning --custom 'opera-45.0.2552.898_all.sfs' has been successfully loaded.
NOTE: Loading the SFS is temporary. It may be unloaded at the next boot.
Do not remove or move the file unless you unload it.

there are two flags, --warning & --custom, not mentioned in help:

SFS-Load on-the-fly v.2.3.7
Load or unload extra sfs files on-the-fly.
usage: sfs_load [OPTION] [OPTION2 ...] [+|-][FILE_NAME] [+|-][FILE_NAME2] ...
      +FILE_NAME: load, same as FILE_NAME without '+'.
      -FILE_NAME: unload, same as --unload FILE_NAME.
  Options (short, or long):
    -u, --unload: unload the extra sfs files.
    -c, --cli: commandline interface, without dialog.
    -d, --debug: verbose output for debugging information.
    -h, --help: print this help and exit.
    -i, --info: print the base names of installed sfs files.
    -l, --list=FILE_LIST : read file names from the list file FILE_LIST.
    -q, --quiet: skip the 1st confirmation dialog.
    -v, --version: print version and exit.
    - (without file name): read file names from standard input. Imply '--cli'.
  Examples:
        ls -1 DIR_NAME | sfs_load -
        sfs_load - < FILE_LIST
        sfs_load --list=FILE_LIST
      Note that FILE_LIST contains each filename per a line.
  Other options(sfs_load internal use):
    -n, --no-afterwork: suspend fixmenus and etc. after (un)loading.
    -a, --afterwork (without file name): only do suspended afterwork.
    -s, --skip-fixmenus: skip fixmenus (but do startup scripts and etc.).
    start: auto load at boot (called from /etc/initd.d/sfs_load)
    stop: clean up at shutdown (called from /etc/initd.d/sfs_load)

These are not command arguments but something else

Dialog messages. The others in --help are commandline options/switches.

bigpup wrote: Mon Oct 04, 2021 1:30 am

Try nocopy as the response to the question.

Try

nocopy

!!

Not -nocopy or --nocopy

nocopy is not something to put in a command line.
nocopy is the answer you give, if asked to copy the sfs to /mnt/home

If you place all the program sfs packages in /mnt/home.
You will be using the expected location and sfs_load, would not need to even ask about copying them, to the correct location, for how it was designed.

Very peculiar:

In X-Tahr (last post was Mainline Tahr, 1st post was Xenial) I just loaded and unloaded Opera 45 via terminal script and the .sfs did not copy.

ALSO

There is no waiting in terminal for feedback or the copy prompt.

The X-Tahr version of sfs_load is the same as Tahr.

What could be the difference?

I'm experimenting in four pups. In the newest (sfs_load 3.1w) since X-Tahr working properly, nocopy did not work (it copied), but it was worth a try.

I will try again later in Xenial as well.

Could the copy function be a part of the .sfs?

I've loaded Chrome, Chromium, & Vivaldi in this Xenial session.

Only Chrome copied.

Exactly where were these SFS packages stored?

They're in various locations, all folders out of Puppy or /root.

I'd like to understand the consequence if they all wind up in /mnt/home or the LIVE mode equivalent, which brings up another distinction - PUPMODE.

13 copies the .sfs while 5 is less likely to?

I have to be testing just this to notice all the differences.

Processes in Puppy Linux are not the same in all versions of Puppy Linux.
Things are constantly being tweaked with each new version of Puppy.
Known bugs are fixed, improvements are made, programs are added, changed, deleted, etc......
So do not expect one Puppy version to operate exactly the same as another Puppy version.
Some processes have been the same for many years, but very few.

They're in various locations, all folders out of Puppy or /root.

That is the first thing you are doing wrong.
The program is designed to have the SFS packages in /mnt/home
One specific location to look for them and be able to find them.
No need to try to search, in all kinds of locations, to find the SFS packages.

/mnt/home to Puppy Linux, is the top layer of the partition Puppy is installed on or the Puppy save file/folder is on.
Really, /mnt/home is not correctly identified or even shows up in the Puppy filesystem, until a save is made and being used by the booted Puppy OS. (depends on pupmode running in)

you really need to have a save made and booting using the save, before downloading and loading program SFS packages.
The save stores information used to properly run sfs_load

If you use amethyst's nicOS-utilities-suite's, viewtopic.php?t=1694 Save2SFS module, substituting an SFS for a SaveFile, your Puppy will always boot in Pupmode 5. You will always be offered the 'NOCopy" option when loading an SFS.
But as bigpup said, the devices built into Puppys to work with a SaveFile/Folder will be absent. Among those perhaps not the least you'll miss is the ease with which you can uninstall applications or upgrade versions. Another is the use of symbolic links to move files/folders onto your Home partition and still have them immediately available. You'll have to get used to running your Puppys in a slightly different way.

You can take a cue from the way amethyst runs his Puppys. After creating an adrv or ydrv, he creates a SaveFile and two menu listings: one which boots 'pfix=ram' so as to not use that SaveFile.

Another tip is that fredx181 and MikeWalsh's portables work in the absence of a SaveFile. You can even use the "MenuAdd" script Mike's been providing to create a menu-entry at the start of your session to have a portable easily available through out that session.

You can take a cue from the way amethyst runs his Puppys. After creating an adrv or ydrv, he creates a SaveFile and two menu listings: one which boots 'pfix=ram' so as to not use that SaveFile.

Hmmm. No, personally I don't use a savefile/folder at all but there's nothing wrong using one (in fact most puppyists do use a savefile/folder) even if you have saved bulk of your stuff to an adrv/ydrv. You are right about the two menu entries though if you do have a savefile and want to boot without it for some reason. In my case I have a test folder which I use for running other puppys to test things. I like to have a lot of diffrent boot parameters for these test puppys which I want to test. So there are different menu entries for ram, nocopy, nox, etc.

JASpup wrote: Thu Oct 07, 2021 7:36 am

They're in various locations, all folders out of Puppy or /root.

I'd like to understand the consequence if they all wind up in /mnt/home or the LIVE mode equivalent, which brings up another distinction - PUPMODE.

13 copies the .sfs while 5 is less likely to?

I have to be testing just this to notice all the differences.

@JASpup :-

As m'colleague says, things are constantly being 'tweaked' from one new release to the next, and he's right; not much remains from Puppy's early days. For instance, older Puppies always used /mnt/home.....but ONLY after your 'save' has been created. Nowadays, they all use /initrd/mnt/dev_save....which I personally find somewhat confusing, especially given that the name of the main 'kennels' directory (where my various Puppy sub-directories live) has a disconcerting tendency to change, depending on which Puppy I've booted into.....

I know what I'm doing with /mnt/home..!

Mike.

Well, I guess I confused what amethyst does with what I do. I also use multiple menu entries to enable different boot arguments for the same frugal install. But I also have different boot listing for the same base Puppy when more than one kernel is employed: i.e., a different folder each having the same puppy_xxx.sfs, but different vmlinuz + zdrv.sfs

mikewalsh wrote: Thu Oct 07, 2021 3:01 pm

Nowadays, they all use /initrd/mnt/dev_save....which I personally find somewhat confusing, especially given that the name of the main 'kennels' directory (where my various Puppy sub-directories live) has a disconcerting tendency to change, depending on which Puppy I've booted into.....

I've seen that too and I agree. Creators' prerogative.

You might sympathize - I'm creating browser scripts in duplicate depending upon which mode I've booted. Surely that can be accounted for in an advanced script, but not quite there yet.

For a record: currently in X-Tahr in MODE 5 w/Pale Moon** and Chromium .sfs loaded which did not copy to the root directory of the partition from which they were loaded.

**Light is a choice default browser for easy loading/installation of Pale Moon & Firefox.

mikeslr wrote: Thu Oct 07, 2021 1:58 pm

...substituting an SFS for a SaveFile, your Puppy will always boot in Pupmode 5. You will always be offered the 'NOCopy" option when loading an SFS.

The issue of this thread is only the cli loading of .sfs. In the same PUPMODE, the copy or nocopy options should be consistent whether we use the gui or cli.

I would argue they should be consistent regardless of PUPMODE, because an .sfs doesn't have to be in the root of the booting or loading partition to work.

I tried it for a while, even tried symlinks, and found I simply do not need .sfs where sfs_load wants to copy them.

I just installed Chrome gui PUPMODE 5, and the sfs_load copy option did not present itself.

[ Missed in last post: Chromium and Pale Moon were installed by script w/ "-c" switch. The Chrome I just installed was from the file manager. ]

I'm suspecting the .sfs.

I have three browsers loaded and an email reader.

I just loaded Chrome again by script (a 4th browser) with "-c" and it copies after the usual cli prompt (in X-Thar LIVE).

The one difference this time is I have a USBFLASH plugged in and it's copied to that partition instead of the internal.

Now, how can an .sfs affect the process of the utility that loads it?

Is this like the pinstall.sh scripts in .pets?

This inconsistent .sfs loading dilemma could be solved with testing until observable patterns are recognized. It would include observing:

1. booted Puppy

2. .sfs file loaded

3. method of loading

4. PUPMODE

Method examples include: file manager clicks, sfs_load gui, sfs_load -c, and sfs_load script without "-c" [hybrid loading].

Since the last option never forces a copy, and my .sfs loads to date are always gui apps, I will default to hybrid for the time being.

I've discovered a 5th test observation criterion:

Whether or not sfs_load cli will copy an .sfs in process of being loaded can be dependent upon mounted partition availability, almost like how partitions are scanned for pupsave placement.

It sounds ridiculous, but that's how it works. I just got a Chromium .sfs loaded from an internal HD copied to a mounted usbflash -- typical cli prompt with no allowable user feedback.

Less distracted I would have honed in on this by now. It's almost as if the gui is a different program.

Recently I've experienced .sfs not loading by gui but loading by command line. Iow, if it doesn't work this way, try it that way.

sfs_load is a great program and integral to Puppy but I gotta get this sorted.

This is the way I solved the problem

I'm using Slack64-7.0 and it also worked in Slacko-64-6.3.2.
Frugal with no save file.
If the sfs is not on usb or home it will always copy. So to solve the problem I've created a home folder /mnt/home
which does not exit in Slacko64-7.0. I just create a symlink for every sfs I want to load at boot in /mnt/home.
I use the adrv_slacko64_64.sfs as my configuration file to make changes (which I do very often) because it is very small.
I added "sfs_load -c -q /mnt/home/*" in /etc/rc.d/rc.local so every symlink in that folder will be loaded

Good luck

eddy_norton wrote: Mon Nov 15, 2021 5:16 am

This is the way I solved the problem

I'm using Slack64-7.0 and it also worked in Slacko-64-6.3.2.
Frugal with no save file.
If the sfs is not on usb or home it will always copy. So to solve the problem I've created a home folder /mnt/home
which does not exit in Slacko64-7.0. I just create a symlink for every sfs I want to load at boot in /mnt/home.
I use the adrv_slacko64_64.sfs as my configuration file to make changes (which I do very often) because it is very small.
I added "sfs_load -c -q /mnt/home/*" in /etc/rc.d/rc.local so every symlink in that folder will be loaded

Good luck

It won't copy if the extra sfs files are in the root directory where your puppy files are. My frugal install is on a harddrive partition and I also use an adrv for configuration changes and no savefile. No need to create a home folder. In my case the command in /etc/rc.c/local reads sfs_load -c -q /mnt/sda3/NameofSFSfille.sfs

eddy_norton wrote: Mon Nov 15, 2021 5:16 am

Frugal with no save file.
If the sfs is not on usb or home it will always copy. So to solve the problem I've created a home folder /mnt/home
which does not exit in Slacko64-7.0. I just create a symlink for every sfs I want to load at boot in /mnt/home.
I use the adrv_slacko64_64.sfs as my configuration file to make changes (which I do very often) because it is very small.
I added "sfs_load -c -q /mnt/home/*" in /etc/rc.d/rc.local so every symlink in that folder will be loaded

I get the gist of your explanation.

Frugal with no save file = running LIVE (PUPMODE 5).

If we run LIVE, /mnt/home is not created nor part of the system because that directory is used with save files.

If sfs_load is looking for those .sfs while using save files, it won't try to copy them if they are symlinked to the directory it wants to copy them to.

I am not sure with adrv what their name has to be, so I copy the exact format of an zdrv or fdrv. E.g., what is a browser adrv? To me it seems like just another .sfs that is loaded before the rw layer.

My challenge at this point is where any .sfs are going to reside running LIVE. We certainly don't want all the .sfs copied to RAM. And those external partitions will have to be mounted.

Alas, the question you answered is asked here: http://forum.puppylinux.com/viewtopic.p ... oot#p41415

My problem does not involve loading .sfs at boot, but from the command line in manually executed scripts. I could still probably adjust your technique for those .sfs.

Hopefully this solution can be integrated into normal Puppy functionality. Discretionary .sfs placement is better.

My mistake !!
I forgot to mention it is a remastered Slacko64.7.0 with most of my preferences.
It is in PUPMODE=13 and when shutting down I just get the message saving session to () for a few secondes and the shutdown is completed