nicOS-Utility-Suite

[amethyst]

Deleted

[greengeek]

Thanks for this suite Nic. I have not used it before and could use a pointer or two.

I am using Tahr32 without save file and attempting to capture some minor changes to an adrv as an alternative to savefile.

I have previously tried creating a small savefile then manually converted that to an adrv and it works fine - but i would like to use this suite to try to create the adrv direct from the pup-rw contents if that is possible. (Without savefile creation as a stepping stone).

Does this suite allow this? I tried a couple of the options but could not make any progress.

Cheers!

[amethyst]

Thanks for this suite Nic. I have not used it before and could use a pointer or two.

I am using Tahr32 without save file and attempting to capture some minor changes to an adrv as an alternative to savefile.

I have previously tried creating a small savefile then manually converted that to an adrv and it works fine - but i would like to use this suite to try to create the adrv direct from the pup-rw contents if that is possible. (Without savefile creation as a stepping stone).

Does this suite allow this? I tried a couple of the options but could not make any progress.

Cheers!

Yes, try the Save2SFS utility of the suite. Click the 'help' button of the utility for more information.

[greengeek]

Yes, try the Save2SFS utility of the suite. Click the 'help' button of the utility for more information.

Hmmm, not working for me. It seems as if that is only for processing an existing savefile into an adrv - is that correct? What i am looking for is a script to capture pup-rw into an adrv. Have i misunderstood the save2sfs utility?

[amethyst]

Yes, try the Save2SFS utility of the suite. Click the 'help' button of the utility for more information.

Hmmm, not working for me. It seems as if that is only for processing an existing savefile into an adrv - is that correct? What i am looking for is a script to capture pup-rw into an adrv. Have i misunderstood the save2sfs utility?

No, you don't need an existing savefile for it to work. The contents of pup_rw is captured. There are two choices to choose from: the first choice is to save your changes to a ydrv. If you choose this option the contents of any existing ydrv, adrv and pup_rw will be captured to a new ydrv. It's recommended to use this option if you already have a big ydrv/adrv/savefile so that the new ydrv can replace it. The second choice is to choose the adrv option. This option will capture the contents of any existing adrv as well as pup_rw and create a new adrv. The idea is to use the adrv option only to save the small changes as you go along. No need for a savefile, ever.

NOTE: Check/use the RAMDISK option for the working area if you have enough RAM. For some reason Tahr may have a peculiar name for the puppy partition if you don't have a loaded savefile and you have booted with pfix=nocopy. This specific issue is uniquely related to Tahr only.

[greengeek]

NOTE: Check/use the RAMDISK option for the working area if you have enough RAM. For some reason Tahr may have a peculiar name for the puppy partition if you don't have a loaded savefile and you have booted with pfix=nocopy. This specific issue is uniquely related to Tahr only.

Thanks for the tip. Works well after selecting RAMDISK. Sorted! cheers

[amethyst]

Added nicOS-Auto-Base-Remaster. This is not part of my official suite but I'm adding it as an additional remaster script which may be useful for some. It does not require any user input at all. See first post.

[JASpup]

My Save2SFS ran but quit with a message I couldn't see before the window closed. I only caught the word "ERROR".

I'm struggling to adrv a Xenial 64 XFCE pupsave. There's an existing adrv as well as ydrv (which presumably contains the desktop environment).

I've tried both manually making an adrv from the pupsave and a remaster to no avail. At the least, it boots likes the original live session with no changes.

The remaster puts all alphabet drv in the main sfs, Barry giving the option of leaving the zdrv out. Perhaps XFCE is always looking for a ydrv.

I probably should have tried to make an sfs from pup_ro1 instead of the pupsave file itself, though haven't determined the difference.

Thus far I've one successful adrv creation, manual in X-Tahr.

[mikeslr]

Running the Save2SFS module you have two options, create an adrv.sfs or a ydrv.sfs.

Just wanted to point out something amethyst mentioned here, viewtopic.php?p=29114#p29114:
"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."
Generalizing, if the OS has an adrv.sfs or you've already created one, rename it ydrv.sfs and select the adrv.sfs option for the reason above stated.

I didn't know that. Maybe I should have read the documentation.

[JASpup]

Generalizing, if the OS has an adrv.sfs or you've already created one, rename it ydrv.sfs and select the adrv.sfs option for the reason above stated.

If there is both the issue becomes combining alphabet drv or looking for a way out.

I try but when something doesn't work as advertised it feels like more of a game than a feature.

I believe I've had success in Tahr because it's not released with an adrv, consequently booting it more regularly.

I'm booting internal hd puppies off a USB bootloader in both MODE 5 & 13.

My ultimate goal is 5 for everything on USB but that won't happen until a fluid method of creation and saving changes.

[amethyst]

Running the Save2SFS module you have two options, create an adrv.sfs or a ydrv.sfs.

Just wanted to point out something amethyst mentioned here, viewtopic.php?p=29114#p29114:
"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."
Generalizing, if the OS has an adrv.sfs or you've already created one, rename it ydrv.sfs and select the adrv.sfs option for the reason above stated.

I didn't know that. Maybe I should have read the documentation.

Well as we know this is a new and unique thing with Fossa having an existing adrv containing all its software (or that is what I understand as I have never used it before). Changes appear in (some) Puppys as we go along and we ask our questions and get answers as we go along and try to solve things the best we can.
It depends upon the content of any existing adrv and ydrv which option of Save2SFS you want to use and what you want to achieve. An adrv has system preference over a ydrv so system configuration changes should be in the adrv. I think the instructions in the help section of the utility is quite clear what is copied to create either the ydrv or adrv and how it should/can be used. In the end utilities are created to be useful to some. If it works for you, lovely. If not, well tough luck, try something else. Yes, the adrv option should be used in the Fossa scenario and renaming its existing adrv to an ydrv is the easiest way out.

[bigpup]

This is a utility you may want to add to the collection.

savefile2dir 1.6 - Convert savefile to savefolder
This is the forum topic:
http://murga-linux.com/puppy/viewtopic.php?t=96472
The savefile2dir-1.6.pet is here:
https://oldforum.puppylinux.com/downloa ... p?id=89079

[rockedge]

@amethyst I removed the conflicting original topic thread as requested. Double check so I can permanently delete the old topic.

I use the nicOS-Utility-Suite, it's a great package.

[JASpup]

I may give it another shot.

It's a dilemma when you lean towards alt-windows managers in newer pups with a&ydrvs & a pupsave, combining tools aren't facile, and you're out of your league manually.

Hopefully I'm missing something simple.

[amethyst]

@amethyst I removed the conflicting original topic thread as requested. Double check so I can permanently delete the old topic.

I use the nicOS-Utility-Suite, it's a great package.

Thanks.

[amethyst]

I may give it another shot.

It's a dilemma when you lean towards alt-windows managers in newer pups with a&ydrvs & a pupsave, combining tools aren't facile, and you're out of your league manually.

Hopefully I'm missing something simple.

Shouldn't matter. adrv/ydrv/savefiles are not new but it matters what it contains. Always remember the pecking order: savefile contents > adrv >ydrv. The best time to do a remaster is first thing after you have rebooted to desktop (with an existing savefile/folder).

[stemsee]

@amethyst I use the nicOS-Utility-Suite, it's a great package.

No! It isn't!!

[JASpup]

Shouldn't matter. adrv/ydrv/savefiles are not new but it matters what it contains. Always remember the pecking order: savefile contents > adrv >ydrv. The best time to do a remaster is first thing after you have rebooted to desktop (with an existing savefile/folder).

Even as a 1yr non-coding novice this is part my fault as I'm attempting an alt-DE puplet.

It seems easier when both a & ydrv are not taken to start.

Being able to run PUPMODE 5 instead of a save is a big deal. The system is resilient, personal storage options change, you don't need anything mounted, file references change, etc.

I haven't tried it yet, but I'm considering alternatives like trying to load the pupsave as a regular sfs after adrv.

[one]

@amethyst I use the nicOS-Utility-Suite, it's a great package.

No! It isn't!!

You are right - it's only 20 KB unzipped ...

peace

[amethyst]

nicOS-Remaster-Alternative script attached to first post.

[amethyst]

I've made a faster version of the alternative remaster script. Did some limited testing and it seems to be working correctly for me. I'm attaching it here for those interested. It will replace the alternative remaster script in the first post if no dragons appear during testing.

[amethyst]

I've made a faster version of the alternative remaster script. Did some limited testing and it seems to be working correctly for me. I'm attaching it here for those interested. It will replace the alternative remaster script in the first post if no dragons appear during testing.

Added to first post.

[mikeslr]

Hi amethyst,

Thanks again for your very useful applications. Using your remasters and Save2SFS I've been able to reconstruct Puppys so that they include what I want, appear as I want -including pwidgets on bootup-- and function as I want from READ-ONLY source files. AFAICT, there remains only one slight annoyance.

Although all the setting choices offered by First-Run Dialog have been set, 'saved' and will be used, on boot-up the First-Run Dialog still appears and has to be manually closed. IIRC, to avoid that either a file has to be written, edited, or deleted. But that's as far as my memory takes me. Hopefully, yours is better.

[amethyst]

Hi amethyst,

Thanks again for your very useful applications. Using your remasters and Save2SFS I've been able to reconstruct Puppys so that they include what I want, appear as I want -including pwidgets on bootup-- and function as I want from READ-ONLY source files. AFAICT, there remains only one slight annoyance.

Although all the setting choices offered by First-Run Dialog have been set, 'saved' and will be used, on boot-up the First-Run Dialog still appears and has to be manually closed. IIRC, to avoid that either a file has to be written, edited, or deleted. But that's as far as my memory takes me. Hopefully, yours is better.

Yes, that is the position regulated by a builtin script when you do a remaster. After the firstrun dialog, a "flag" file is written to /var/local and when you save your session (to either a savefile/folder or via save2sfs) this flag file will be there at reboot and you won't get the dialog again. Obviously if you do not save anything and just run read-only all the time, the original remastered puppy will boot the same everytime and you will see the first run prompt. A solution for you: Try the
Alternative remaster script in future when doing a remaster (attached to first post) > a "Final Check" dialog will appear during the remaster process where you have the opportunity to check or edit files for the new base sfs before it is compressed > copy the file called "delayedrun_firstboot_flag" from /var/local in your running system to the corresponding location in the PuppyRemaster build folder and click 'OK" in the Final Check Dialog to continue the remaster process. Of course, if you have already done the remaster before (like you have probably done), edit the base sfs by adding the mentioned file accordingly.

[mikeslr]

Thanks.

P.S. The file can also be copied to Fossapup64's ydrv.sfs /var/local, and that ydrv rebuilt: mounted, copied to a folder, then dir2sfs.

[amethyst]

Thanks.

P.S. The file can also be copied to Fossapup64's ydrv.sfs /var/local, and that ydrv rebuilt: mounted, copied to a folder, then dir2sfs.

If you want to rebuild the ydrv just run save2sfs again and the new, replacing ydrv will include that file (and any newer system changes to your system). This is because the current status of /var is copied unlike with a remaster where a rather pristine /var is included. BTW - there are sfs editing tools in the nicOS utility suite, for example the right-click tool where you just have to right-click an sfs file you want to edit to start the process (nicOS-SFS-Editor).

[mikeslr]

Thanks, amethyst. I was thinking of trying out your editing tool the next time I have to work on an SFS.

One thing I think I've discovered. Remaster should be used to remove unwanted built-ins before creating a/y-drivs. Or, at least, that care for naming be taken. I wanted to 'update' /opt/palemoon. My system ended up with both /opt/palemoon and /opt/palemoon64, the former being just a waste of space and resources.

[amethyst]

Made a few changes to the alternative remaster script. Updated in first post.

[amethyst]

nicOS-Utility-Suite-2022 released. Attached to first post.

[amethyst]

Made a few adjustments. See first post for new .pet, replacing all previously.