How To Make and Use an SFS File?

[JusGellin]

I want to learn how to do this from another topic (which would be useful):

How is puppy faster and or better?
https://www.forum.puppylinux.com/viewto ... 41#p127041

1)..., Puppys can be run in such a way as to be inherently secure. Both Bookworm and F96 include an application: nicOS-Utility-Suite. One of its modules enables the User to create or modify either a ydrv.sfs or adrv.sfs, or both to include all the additional applications, settings and customizations you've installed. Both adrv.sfses and ydrv.sfses are READ-ONLY. On boot-up they are copied into RAM. The result is that you no longer need a SaveFile/Folder. If you then operate under Pupmode 5 (pfix=ram) after boot-up from a USB-Key you can unplug the Key. Hard to contaminate an operating system which isn't there. If booted from a hard-drive, the hard-drive is dismounted after boot-up. That still presents an obstacle to hackers. Things downloaded intentionally or inadvertantly will only exist in RAM and be wiped wiped on reboot/shutdown unless you first mount a hard-drive and specifically choose the files you want to keep.

First of all by doing the above, should using an sfs in place of the SaveFolder look identical?

I tried doing this by using nicOS-Utility-Suite.
I made an sfs for the ydrv.
Then I put it where the other sfs's are at.
Changed to Pupmode 5 - pfix=ram
But booting up doesn't show any of the menu items I had before when using the Save folder.
The boot up shows the new sfx is loaded.

How can I figure this out?
I'm using BookwormPup64_10.0.6 on a frugal install on a usb stick.

Thanks

[mikeslr]

@JusGellin
"Then I put it where the other sfs's are at."

adrvs.sfs and ydrv.sfs must be located next to [in the same folder as] the 'core'.sfs --which under the latest BookwormPup is named puppy_dpupbw64_10.0.7.sfs-- and other system files, e.g., vmlinuz, initrd.gz.

By the way make a note of their priorities. The content of an adrv.sfs has priority over that of a ydrv.sfs. Which means that if there is a conflict between them --such as adrv.sfs includes an older version of an application or contains settings and customization-- adrv.sfs's versions will be used.

For that reason I locate applications I never expect to update in ydrv.sfs and reserve adrv.sfs for those applications frequently updated such as web-browsers.

[JusGellin]

@mikeslr
I did do it like you mentioned in the last post, but it still didn't work:

adrvs.sfs and ydrv.sfs must be located next to [in the same folder as] the 'core'.sfs --which under the latest BookwormPup is named puppy_dpupbw64_10.0.7.sfs-- and other system files, e.g., vmlinuz, initrd.gz.

So I remade the usb stick frugal install and just changed the time zone and connection to wifi. After I placed it in BookwormPup folder, I again set pfix=ram.
It didn't have those settings. If I set the pfix back again, it does have those settings.
What am I doing wrong.

The reason I used ydrv was because adrv was already being used by default. Once an sfs file is made, can it be named something else and placed in this same place?

[Wiz57]

@mikeslr
I did do it like you mentioned in the last post, but it still didn't work:

adrvs.sfs and ydrv.sfs must be located next to [in the same folder as] the 'core'.sfs --which under the latest BookwormPup is named puppy_dpupbw64_10.0.7.sfs-- and other system files, e.g., vmlinuz, initrd.gz.

So I remade the usb stick frugal install and just changed the time zone and connection to wifi. After I placed it in BookwormPup folder, I again set pfix=ram.
It didn't have those settings. If I set the pfix back again, it does have those settings.
What am I doing wrong.

The reason I used ydrv was because adrv was already being used by default. Once an sfs file is made, can it be named something else and placed in this same place?

What exactly did you name your ydrv? I ask because for any "alphabet" drv.sfs to be loaded at bootup, the name MUST INCLUDE the SPECIFIC name of the
Puppy being booted. If you just name it like "ydrv.sfs" or "adrv.sfs" they will not be loaded automatically, BUT, they can be loaded and unloaded using the
sfsload utility in the Utility applications in the Menu.

WIz

[JusGellin]

What exactly did you name your ydrv?

The nicOS-Utility-Suite gave it the name ydrv_dpupbw64_10.0.6.sfs.
I didn't know about the sfsload. When I brought it up all the sfs were loaded.

[JusGellin]

I figured out what I was doing wrong because my pfix=ram wouldn't respond to the sfs for the save folder.

As a beginner, it's funny how I try to understand how things work, but don't always (most of the time) get it right.
I thought that you should not touch the save file when it's used for a running system and should boot up with
an iso or clean version to manipulate it.

So what I was doing wrong was setting the pfix=ram and then booting up with that.
Then from there, I used the nicOS-Utility Suite to make the ydrv sfs file.
This doesn't work at all, even though I can see the local save folder. It must be using its own invisible save even though it never has been saved to
to make the ydrv sfs file, because it never has the information from the local save file.

What you have to do, is use the nicOS-Utility Suite from the local system that has all of your changes in its
specific save folder to make the ydrv sfs file. Then resetting pfix=ram will now have the ydrv sfs file contain the local
save information.

I imagine how hard it must be to try to figure out what a beginner is talking about when all of you try to support and help someone.
I again can only appreciate more that you try to help a new person like myself.
Just your response and suggestions to look at things that you think might help is so valuable to me.
It makes me think, "what problems am I causing myself this time!" because you don't seem to have those problems yourself since
you have a lot of experience.
So that encourages me to really try things to see how I can make it work because I no doubt am thinking wrong somewhere.

Anyway, after all of this, I think I can do what @mikeslr suggested here :

1)..., Puppys can be run in such a way as to be inherently secure. Both Bookworm and F96 include an application: nicOS-Utility-Suite. One of its modules enables the User to create or modify either a ydrv.sfs or adrv.sfs, or both to include all the additional applications, settings and customizations you've installed. Both adrv.sfses and ydrv.sfses are READ-ONLY. On boot-up they are copied into RAM. The result is that you no longer need a SaveFile/Folder. If you then operate under Pupmode 5 (pfix=ram) after boot-up from a USB-Key you can unplug the Key. Hard to contaminate an operating system which isn't there. If booted from a hard-drive, the hard-drive is dismounted after boot-up. That still presents an obstacle to hackers. Things downloaded intentionally or inadvertantly will only exist in RAM and be wiped wiped on reboot/shutdown unless you first mount a hard-drive and specifically choose the files you want to keep.

whew! another small learning step for me.

Thanks

[RSH]

You wrote: ydrv_dpupbw64__10.0.6.sfs.
Is this a typo in forum or typo in the name of the .sfs.
If it's a typo in .sfs name then it won't be loaded by the doubled underline.

[JusGellin]

@RSH
It should be like you thought -
ydrv_dpupbw64_10.0.6.sfs

I corrected it.
Thanks for catching that.

[mikeslr]

Thanks, JusGellin. Your struggles have just given me an idea about how to 'update' adrv.sfs. As I mentioned adrv.sfs has priority over ydrv.sfs and I only place those applications which are frequently updated in adrv.sfs. That priority, however, also applies to settings and customization which have changed. So, for example if experimenting I change the default wallpaper and then create an adrv.sfs, on boot-up that new wallpaper will be displayed even if I really want the choice I 'captured' in the ydrv.sfs to be the default. And there's another problem. Unlike remastering --where links to deleted/Remove builtin files/applications aren't followed-- when creating an adrv or ydrv the deleted files/application are copied along with a 'white-out' which tells puppy to not use them.*

amethyst last version --the one built-into Bookworm64 and F96-- provides an option to exclude both the current adrv and ydrv in a new adrv or ydrv.

Choices.png (32.82 KiB) Viewed 456 times

So I think for my purposes to accomplish my objective what I should do is:
(a) rename adrv.sfs >0adrv.sfs and reboot so that it won't be part of the system 'in RAM'.
(b) Install those applications (web-browsers + addons, new versions of rerwin's Network Managers, https://www.forum.puppylinux.com/viewto ... 2241#p2241, etc.)
(c) Make no changes other than that.
(c) Then choose the option to exclude both existing adrv and ydrv.
(d) Reboot and if satisfied, delete the old adrv now named 0adrv.sfs.

-=-=-
* amethyst published an application to remove 'white-outs'. But I've never used it so can't comment on its functionality.

[JusGellin]

@mikeslr thanks for that.
I tried that and I can see that it gets the new changes made after the reboot.

So when you do this on the puppy in ram, and make a new adrv, does the new adrv now contain just the changes made for this puppy in ram?
Also how can you see what has been white-out?

Thanks