nicOS-Utility-Suite

[bigpup]

You do know the pet package is OK to attach as a pet?
The forum allows pet packages as attachments.
Only limited in size to no larger than 512KiB.

So, this is not needed.
The fake .gz extension, added to the name.

Update:
Corrected my keyboard error input, by me, to correct 512KiB max size limit.

[amethyst]

Yo do know the pet package is OK to attach as a pet?
The forum allows pet packages as attachments.
Only limited in size to no larger than 512MB.

So, this is not needed.
The fake .gz extension, added to the name.

Yes. 512MB?

[rockedge]

@amethyst

512 KiB is the correct size

[amethyst]

@amethyst

512 KiB is the correct size

512KB (500KiB) or 512KiB (524.288KB)?

[rockedge]

Screenshot.jpg (26.68 KiB) Viewed 2832 times

[bigpup]

Sorry about that!
I hate keyboards that will type the wrong thing, even when your mind is thinking the wrong thing
Well I got the 512 correct

[mikeslr]

pet vs. gz: My usual practice is that when applications are small I prefer pets to SFSes. But your Suite is an exception. Regardless of how you package it I rebuild it as an SFS. As such, I can load it when I need it into any of the several Puppys I run; unload it when it's not needed; and continue that practice because your Save2SFS tools specifically provides for the exclusion of SFSes. If and when you publish a new version, the 'old version' isn't in the operating system having priority over an SFS-loaded version.

So, my vote on the pet vs. gz question is neither. But can the Forum accept SFS attachments? I should know that but don't. If not, I'd vote for an SFS with a false gz ending.

[amethyst]

pet vs. gz: My usual practice is that when applications are small I prefer pets to SFSes. But your Suite is an exception. Regardless of how you package it I rebuild it as an SFS. As such, I can load it when I need it into any of the several Puppys I run; unload it when it's not needed; and continue that practice because your Save2SFS tools specifically provides for the exclusion of SFSes. If and when you publish a new version, the 'old version' isn't in the operating system having priority over an SFS-loaded version.

So, my vote on the pet vs. gz question is neither. But can the Forum accept SFS attachments? I should know that but don't. If not, I'd vote for an SFS with a false gz ending.

This was not an sfs vs gz issue. It was about the file extensions allowed by the forum for attachments. One can't upload a .sfs file as an attachment because the .sfs extension is not allowed. One way to bypass this "difficulty", is to give it a fake extension like .gz which is allowed. .pet files can be uploaded as attachments because that extension is allowed. I uploaded a .pet file and gave it a fake extension but it wasn't necessary to give the .pet a fake extension.
Most users use savefile/folders and install applications in the form of .pets, etc. Users who like to save their changes to an adrv or ydrv instead like you and I seem to be far in the minority. Note that installing a .pet at any given time during a session, will give its contents preference to the base sfs and any other additional drives (like the adrv or ydrv) mounted at the time. This is why I, in rare cases where it is required, temporarily "install" a .pet file for use during a session instead of loading an extra sfs file. I don't use a savefile/folder ever.

[Fat Tony]

@amethyst Can you explain what the difference is between Remaster: Classic and Remaster: Alternative options are? I did try using the help button in the utility suite but I couldn't see anywhere explaining what the differences are

[amethyst]

@amethyst Can you explain what the difference is between Remaster: Classic and Remaster: Alternative options are? I did try using the help button in the utility suite but I couldn't see anywhere explaining what the differences are

They differ in terms of how the files are copied to produce the new base sfs. The classic method works like the builtin remaster script. With the classic method, the contents of all mounted/loaded sfs files (except the zdrv and fdrv) are included in the new base sfs by default. So the new base sfs will have the contents of the old base sfs, the contents of all additional drives (like adrv and ydrv but not the zdrv and fdrv as mentioned), the contents of all loaded extra sfs files, and the system changes (savings). There is however an option to decide which of the loaded extra sfs files you want to exclude. The biggest drawback of the classic method is that you have to boot without the additional drives (adrv/ydrv) to exclude them.

The alternative method only includes the contents of the old base sfs and the changes to the system (savings) in the new base sfs. Previously, a drawback of the alternative method was that it did not deal correctly with "white-out" files but I have found a way to overcome this and it's not an issue anymore. An advantage of the alternative method is that you can check and edit all contents of the new base sfs during the final check before the new base sfs is created. With the classic method you can only check and edit the /root, /etc and /var folders before the new base sfs is created at final check. The alternative method is a bit slower than the classic method.

So it's a matter of which method you prefer and what you want to include in your new base sfs. Personally, I use the alternative method most of the time.

[mikeslr]

Thought the Heading would make it easier to find the post above. And reduce the occasions, such as here https://www.forum.puppylinux.com/viewto ... 505#p60505, where the information has to be repeated.
The above link and the two posts above it discuss the use of Save2SFS as a possible alternative.

[amethyst]

Thought the Heading would make it easier to find the post above. And reduce the occasions, such as here https://www.forum.puppylinux.com/viewto ... 505#p60505, where the information has to be repeated.
The above link and the two posts above it discuss the use of Save2SFS as a possible alternative.

Each application in this suite has a help section with more information. Click the Help button when using the utility. Also here just a few posts up: https://www.forum.puppylinux.com/viewto ... 590#p58590

[mikeslr]

Amethyst, I've taken the liberty of repackaging your last pet (October '22) as an SFS. I use it in that format because (a) I can use the same file-system under many Puppys without having to install it into each and (b) running Save2SFS I don't have to incorporate it into the advr or ydrv I'm building.

If figured I'd save the time of others who might prefer your really useful application that way.

nicOS-Utility-Suite-Oct22_8.0.sfs

(20 KiB) Downloaded 103 times

[Jasper]

@mikeslr

I did load your SFS and when I unloaded it, I was informed that it would delete itself.

Is that correct?

LOL, I had to download it again and put it away in a safe place.

[amethyst]

Moved to new topic

[amethyst]

@mikeslr and others.
I've added some notes i.r.o of using this tool with some of the newer Puppys.https://forum.puppylinux.com/viewtopic. ... 033#p78033

[mikeslr]

If my flaky memory serves, an earlier version of Save2SFS had a check box by which, when creating either an adrv or a ydrv, the contents of the other could be excluded. This worked well with my routine: 1st create a ydrv that would rarely change; then create a adrv which could be modified as needed. The current GUI doesn't offer that option.

Save2SFS Options.png (25.79 KiB) Viewed 1404 times

The "and" in the option "Exclude existing adrv and ydrv" I read to mean both: no choice to exclude one but not the other.

I'm not sure how to retain my routine, except to rename the ydrv (e.g. 0ydrv --anything which will be ignored on boot-up), reboot and then create a new/modified adrv, then rename 0ydrv to ydrv again and reboot.

Perhaps this is where your new SaveToAdrv comes in, viewtopic.php?p=87387#p87387. That post suggests that it only affects Adrv (perhaps unless the "Create new adrv in /tmp" is chosen?). But have I interpreted the post correctly? Using either of the first two options of SaveToAdrv will the contents of a ydrv be excluded from the newly created adrv?

At any rate, how would you suggest creating/modifying adrv so that its contents will not include things already included in a ydrv?

[amethyst]

If my flaky memory serves, an earlier version of Save2SFS had a check box by which, when creating either an adrv or a ydrv, the contents of the other could be excluded. This worked well with my routine: 1st create a ydrv that would rarely change; then create a adrv which could be modified as needed. The current GUI doesn't offer that option.
Save2SFS Options.png

The "and" in the option "Exclude existing adrv and ydrv" I read to mean both: no choice to exclude one but not the other.

I'm not sure how to retain my routine, except to rename the ydrv (e.g. 0ydrv --anything which will be ignored on boot-up), reboot and then create a new/modified adrv, then rename 0ydrv to ydrv again and reboot.

Perhaps this is where your new SaveToAdrv comes in, viewtopic.php?p=87387#p87387. That post suggests that it only affects Adrv (perhaps unless the "Create new adrv in /tmp" is chosen?). But have I interpreted the post correctly? Using either of the first two options of SaveToAdrv will the contents of a ydrv be excluded from the newly created adrv?

At any rate, how would you suggest creating/modifying adrv so that its contents will not include things already included in a ydrv?

This is an extension of the save to adrv option only (the save to adrv option of the save2sfs module of the suite). ydrv does not come in to play here. Option 3 of this utility gives exactly the same result as the save to adrv option of the save2sfs module in the suite (and the other two options overwrites the adrv directly, so it's just additional user options for save to adrv with the same resulting new adrv). If you want to make a ydrv, you must use the save to ydrv option of the save2sfs module of the suite. To make it clear:
save to ydrv = capture contents of existing ydrv, adrv, savefile/folder and changes of the system for the session.
save to adrv = capture contents of existing adrv, savefile/folder and changes of the system for the session.

In short - you can use this save to adrv utility instead of the save to adrv option of the save2sfs module in the suite.

[mikeslr]

I've been trying to create a ydrv using Bionicpup64-Revival and your last Utility Suite. Everything works except on boot-up it halts and presents 'an improper shut-down' notice (or words to that effect) with the choices of 'ignore' or (I think) run xorg setup. I've chosen to ignore and, as said, everything is as expected. After creating a Save the Notice is no longer displayed.

I'm starting with a pristine boot (which doesn't show the notice). I've tried first creating a Save and booting into it (no notice) then running Save2SFS; or running Save2SFS without first creating a Save. It doesn't make any difference.

FWIW, there's no adrv and no external applications (portables or application.SFSes)

Any ideas about what's generating the notice? Or how to get rid of it?

[amethyst]

@mikeslr
That message seems to be related to /root/.XLOADED. This file is automatically generated when you bootup. My guess is that that file is sitting in the base sfs of this puplet you have made, should not be there. Edit your base sfs by removing that file if it is there and repack the base sfs.

[mikeslr]

@mikeslr
That message seems to be related to /root/.XLOADED. This file is automatically generated when you bootup. My guess is that that file is sitting in the base sfs of this puplet you have made, should not be there. Edit your base sfs by removing that file if it is there and repack the base sfs.

Likely something like that, but not that exactly. I looked for the file mentioned above and it wasn't there. Finally decided as there was actually to be very little in the ydrv to just remaster using your Alternate remaster. The new base doesn't have the issue.

[mikeslr]

Hi amethyst,

I just used your Save2SFS module under Bookworm Pup64. Its 'core' file is now named puppy_dpup_10.0.1.sfs (emphasis supplied). Save2SFS successfully created a ydrv_dpup sfs which could be used but failed to include the 'trailing' .1. I had to manually rename it.

[amethyst]

Hi amethyst,

I just used your Save2SFS module under Bookworm Pup64. Its 'core' file is now named puppy_dpup_10.0.1.sfs (emphasis supplied). Save2SFS successfully created a ydrv_dpup sfs which could be used but failed to include the 'trailing' .1. I had to manually rename it.

The script checks /etc/DISTRO_SPECS for the name. The trailing number could be the result of a remaster/newer version where initrd.gz were not amended

[amethyst]

Hi amethyst,

I just used your Save2SFS module under Bookworm Pup64. Its 'core' file is now named puppy_dpup_10.0.1.sfs (emphasis supplied). Save2SFS successfully created a ydrv_dpup sfs which could be used but failed to include the 'trailing' .1. I had to manually rename it.

The script checks /etc/DISTRO_SPECS for the name. The trailing number could be the result of a remaster/newer version where initrd.gz were not amended too.

[Clarity]

Could a convert Savefile2SaveFolder option be added in next version of this utility

Thanks

[galen]

I'm using the nicOS remaster
under bookworm64pup
but it won't make the iso

if I run from commandline
script states /archive not found ...
does not prompt for /mnt/sr0

it makes the sfs but then not the .iso
waited _1hr no process

I need a solution to build iso for BWpup

[amethyst]

I'm using the nicOS remaster
under bookworm64pup
but it won't make the iso

if I run from commandline
script states /archive not found ...
does not prompt for /mnt/sr0

it makes the sfs but then not the .iso
waited _1hr no process

I need a solution to build iso for BWpup

The remaster scripts do not make an iso automatically, you need to select that option at the start if you want to make an iso too. The main focus is to remake the base sfs but if you choose to make an iso as well, you will have the opportunity to do so later in the process. Note however that the making of the iso does not happen automatically, you will have to manually copy over the rest of the files for the new iso (except the old base sfs) from the original iso/CD (if you have one) or at least the files mentioned when prompted to do so. Follow the prompts during the remaster process.

[sonny]

I'm using the nicOS remaster
under bookworm64pup
but it won't make the iso

if I run from commandline
script states /archive not found ...
does not prompt for /mnt/sr0

it makes the sfs but then not the .iso
waited _1hr no process

I need a solution to build iso for BWpup

The remaster scripts do not make an iso automatically, you need to select that option at the start if you want to make an iso too. The main focus is to remake the base sfs but if you choose to make an iso as well, you will have the opportunity to do so later in the process. Note however that the making of the iso does not happen automatically, you will have to manually copy over the rest of the files for the new iso (except the old base sfs) from the original iso/CD (if you have one) or at least the files mentioned when prompted to do so. Follow the prompts during the remaster process.

DARKPUPPY.iso and DARKPUPPY BE.iso were made with nicOS-Utility-Suite.

Thumbs up and thanks to you!

[galen]

Yes I need not rush, follow instructions

[rockedge]

@amethyst Oddest thing happened! While using the utilities to remaster the base SFS on a "instance" of F96-CE created using @wiak's wd_multi script, the utility script managed to delete the entire /mnt/sdc1/TestPup directory containing 10 frugally installed instances of F96-CE_5-alpha3.

Funny thing, I had done 10 or more remasters with no problems when suddenly in the last attempt, the partition icons all began to change as the partitions disappeared! The OS became unstable and froze, when I realized it was actually gone!

In summary, the utility suite managed to delete the entire directory /mnt/sdc1/TestPup/, which contains /mnt/sdc1/TestPup/F96-CE_5-alpha3/instance0, /mnt/sdc1/TestPup/F96-CE_5-alpha3/instance1, /mnt/sdc1/TestPup/F96-CE_5-alpha3/instance2...... during a remaster process!

For a moment of panic it appeared that the suite managed to delete the entire 4 partitions of a 1 terabyte HDD, but it only deleted the /mnt/sdc1/TestPup/ directory and it's complete contents of 10 frugally installed Puppy's