Puppy Remaster Program needs updated from 18th Century

[musher0]

Hey, belham2.

I really don't care what you think of me.

There was a reason BarryK had his remaster script operate step by step. That
reason did not change with time, it is still valid today: are you remastering for
yourself only or for your friends? Remastering for your friends is worth the extra
work, IMO.

Plus it would be nice if you showed some respect for our founder. Sure he left a few
stumps here and there, maybe his interfaces and choices seem clumsy to us ten
years later, but he was clearing ground! BarryK the Puppy Linux pioneer cleared the
ground for us! Remember that!

I notice that you also handily bypassed mfb's solution -- to serve your objective, no
doubt. You shouldn't have. I suppose you paid no attention to nic007's work either?

BTW, what is so famous about the DOG's remaster script anyway? Care to explain?
Care to provide some scrots? Maybe a comparison of the features? Is that below
you? Or God forbid, are you trying to sell us wind? Was it plundered from Debian, or
is it original work? (BarryK's remaster script was entirely written by him, AFAIK.)

Finally, no one in this thread has mentioned the third option, which is to transform
your pupsave into an adrv_xxx.sfs -- instead of doing a remaster. It does not even
need to be an adrv_xxx.sfs, it can be a regular sfs that you load at startup.

Then your Pup_xxx.sfs remains in its original state (pristine), but you have available
all the material that you have added in your old pupsave; plus you can start a new
pupsave if you wish. IMO, this is the cleverest, most adaptable and fastest solution
these days.

BFN.

[zagreb999]

Woof-CE is a Swiss cheese, full of holes,
anti-harmonious...!
only debian with synaptic is
fully harmonious...
it is impossible to remaster
Woof-CE!!!

[musher0]

Woof-CE is a Swiss cheese, full of holes,
anti-harmonious...!
only debian with synaptic is
fully harmonious...
it is impossible to remaster
Woof-CE!!!

Oh, please.

[Burn_IT]

As I said to start with, it IS a community project so stop complaining and do something yourself, or with friends??!!!
Of course anything you do produce will need to be approved before being adopted officially.

[nic007]

Let's be very clear here. The builtin scripts that come with official releases of Puppy ARE generally very good with a few shortcomings. It does a good job even if you use it as is. I've altered a few things which I thought were necessary and think are improvements...and released it as part of my own remaster suite (three of the scripts in my suite are based on and relies heavily on the builtin remaster scripts). I used the builtin remaster script in Precise 571 Retro as "master or "base" for these scripts. There are certain versions of Puppy where the builtin remaster script seems to be broken (Racy comes to mind) but that's an exception. And - as musher0 said, there are more than one way to achieve what you want without using the remaster script eg. the use of an adrive to record your changes. I've even done a how to for that on this forum. Just needs a bit of searching..let your fingers do the walking through the yellow pages.

[musher0]

As I said to start with, it IS a community project so stop complaining and do something yourself, or with friends??!!!
Of course anything you do produce will need to be approved before being adopted officially.

Very true. Thanks for the reminder, Burn_IT.

[davids45]

G'day musher0,

I've been using the Remaster option in the Set Up menu quite a bit recently with the frequent deltas for BionicPup isos from peebee.

First I add my application pets and sfs, and various links as configs for personalising the new Pup. Mostly these are included in the remastered iso, just a few StartUp scripts tend to not work the first time - I suspect I overload the pinboard with icons so timing is awry.

I find BK's script in BionicPup is fairly easy to use with good explanations of the process. But it is a long process (on the Puppy time dimension, more like what I remember of the Windows world speed for doing something such as this).

A post in another thread by forum member willypuppy said he replaced the /root and /etc in /tmp prepared by the Remaster script with the versions on his computer (just copied them across to /tmp). I've been doing this and it is simple and seems OK.

However some of the changes I make to each new Puppy occur in other directories, not just in /etc & /root so I need to re-do these few changes in each remastered iso. Whether extra stops/steps to offer editing other directories is worth changeing in the Remaster program is doubtful.

While doing these almost daily BionicPup remasters lately, I was wondering about doing something with the Save-file as this has everything I need as far as I know and should pick up all my additions and changes, regardless of the directory involved.

So the idea to simply add the personalised Pup's Save-file to the presently-ignored-by-me 'a-drive' sounds very interesting. Almost worth a Homeric 'Doh!' And could be much quicker?

Any links for prior trials, etc of this approach?

Thanks,

David S.

[musher0]

G'day musher0,

I've been using the Remaster option in the Set Up menu quite a bit recently with the frequent deltas for BionicPup isos from peebee.

First I add my application pets and sfs, and various links as configs for personalising the new Pup. Mostly these are included in the remastered iso, just a few StartUp scripts tend to not work the first time - I suspect I overload the pinboard with icons so timing is awry.

I find BK's script in BionicPup is fairly easy to use with good explanations of the process. But it is a long process (on the Puppy time dimension, more like what I remember of the Windows world speed for doing something such as this).

A post in another thread by forum member willypuppy said he replaced the /root and /etc in /tmp prepared by the Remaster script with the versions on his computer (just copied them across to /tmp). I've been doing this and it is simple and seems OK.

However some of the changes I make to each new Puppy occur in other directories, not just in /etc & /root so I need to re-do these few changes in each remastered iso. Whether extra stops/steps to offer editing other directories is worth changeing in the Remaster program is doubtful.

While doing these almost daily BionicPup remasters lately, I was wondering about doing something with the Save-file as this has everything I need as far as I know and should pick up all my additions and changes, regardless of the directory involved.

So the idea to simply add the personalised Pup's Save-file to the presently-ignored-by-me 'a-drive' sounds very interesting. Almost worth a Homeric 'Doh!' And could be much quicker?

Any links for prior trials, etc of this approach?

Thanks,

David S.

Hello David.

nic007 has evolved his own approach and script for this -- hopefully he will chime in
and answer you as well.

As for me, this is how I did it on the xenial-7.0.6:

Code: Select all

#!/bin/sh
# /opt/local/bin/psave2adrv.sh
# Alternately, you can save this script in: 
# /root/my-applications/bin/psave2adrv.sh
#

##########
# Usage: 
# First, enter the directory where your Pup is located and 
# open a terminal there. Then, type: 
# psave2adrv.sh name-and-version-of-your-Pup
#
# Example: psave2adrv.sh xenial_7.0.6 
#
# You have to change this variable to match the Pup's
# name and version.
####

ReceivingDir="adrv_$1"

# 1st part: copy
mkdir -p $ReceivingDir

cd $ReceivingDir
rsync -avz /initrd/pup_rw/* . # Don't forget the dot!
wait # optional; to make sure the copy is finished before
# we start squashing

# 2nd part: squash
cd ..
mksquashfs $ReceivingDir/ $ReceivingDir.sfs -noappend -all-root -b 1048576 -comp xz -Xdict-size 100% 
# The last part of this line < -b 104... etc. > insure pretty much maximum 
# compression of the sfs file. # It takes a minute or so, depending on the size.
# Careful ! If you already have an adrv sfs in the directory, it will be destroyed 
# and replaced with this new one.

echo -e "\n\tDone!\n
You should now reboot your Puppy to activate your new adrv sfs.
Important: make sure your originating pupsave has been renamed.\n"

exit
###########################

# To double-check: (optional)
# diff -q $ReceivingDir /initrd/pup_rw | more 
# 
# All the sub-dirs should have the mention "identical", except
# some "wh.*" files and possibly file .usb-drive-log-probedisk
# in # /initrd/pup_rw only. This is normal. 

Please read the comments in the script beforehand.
If you follow the instructions, it should be fool-proof.
Any question, please ask.

Enjoy!

[musher0]

Hello again all.

A new version, which, compared to the above, hopefully adds all necessary
safeguards. Feel free to comment or pinpoint shortcomings.

Maybe a note about why I do not squash directly to the adrv sfs file: FWIW,
I think having an intermediate folder offers a safer and more adaptable solution.
If you ever want to change something directly in the adrv directory, it's there,
whereas pup_rw is read only. Of course, in this new version you can erase it,
but still.

Enjoy!

Code: Select all

#!/bin/bash
# /opt/local/bin/psave2adrv.sh
# Alternately, you can save this script in:
# /root/my-applications/bin/psave2adrv.sh
#

##########
# Usage:
# First, enter the directory where your Pup is located and
# open a terminal there. Then, type:
# psave2adrv.sh name-and-version-of-your-Pup
#
# Example: psave2adrv.sh xenial_7.0.6
#
# You have to change this variable to match the Pup's
# name and version.
####

if [ "$1" = "" ];then
     echo -e "\n\t\e[33m\e[4mPlease restart with the name and version of\e[24m
     \e[4myour Pup as the first parameter after the command.\e[24m
          E.g.:      psave2adrv.sh \e[4mxenial_7.0.6\e[0m\n"
     exit
fi

ReceivingDir="adrv_$1"

# 1st part: copy
mkdir -p $ReceivingDir

cd $ReceivingDir
rsync -avz --exclude .wh.* /initrd/pup_rw/* . # Don't forget the dot!
wait # To make sure the copy is finished before we start squashing.

# 2nd part: squash
cd ..

if [ -f $ReceivingDir-bis.sfs ];then # Precaution
     echo -e "
     \e[33m\e[4mIf we continue, the existing $ReceivingDir-bis.sfs\e[24m
        \e[4mfile will be destroyed (erased). -- Is this ok? --\e[24m

        \e[4mType 'n' or 'N' to exit; any other key to continue.\e[0m
     "
     read Answer1
     case "$Answer1" in
          n|N)exit ;;
     esac
fi

mksquashfs $ReceivingDir/ $ReceivingDir.sfs -noappend -all-root -b 1048576 -comp xz -Xdict-size 100%
# The last part of this line < -b 104... etc. > insure pretty much maximum compression
# of the sfs file. It takes a couple of minutes, depending on the size of the pupsave file.

echo -e "\n     \e[33m\e[4mRemove $ReceivingDir/ ?\e[24m
\t\e[4mType 'y' or 'Y' for 'yes', any other key for 'no'.\e[0m"
read Answer2
case "$Answer2" in
     y|Y)rm -rf $ReceivingDir
          # rmdir $ReceivingDir
          ;;
esac

echo -e "\n     \e[33m\e[4mDone!\e[24m
\t\e[4mYou should now reboot to activate your new adrv sfs.\e[24m
\t \e[4mImportant -- \e[4mMake sure to store ALL pupsave files\e[24m
\t     \e[4mOUT OF THE WAY to be able to start afresh.\e[0m\n"

exit # Anything after this, bash ignores. #
###########################

# To double-check: (optional)
# diff -q $ReceivingDir /initrd/pup_rw | more
#
# All the sub-dirs should have the mention "identical", except
# some "wh.*" files and possibly file .usb-drive-log-probedisk
# in # /initrd/pup_rw only. This is normal.

[davids45]

G'day musher0,
Thanks for your scripts to automate the process of adding a fully optioned Save-file into a Pup's a-drive.

Your post yesterday made me try to do it as a non-scripting 'beginner'. My steps, as I recall... ...:
in a safe place, expanded a backed-up tar file of a Save-file (most recent BionicPup update) which gave me the Puppy-iconed save-file
opened a new directory in another safe place (a temp directory on my data partition)
started a sub-directory there called 'adrv_ubbpup_18.03"
copied the files (retaining the path structure) of the expanded tar into this new 'adrv_ubbpup_18.03' directory
in Muppy-Filer, navigated to the directory containing the empty 'adrv_ubbpup_18.03'
opened a 'shell' in Muppy
entered 'mksquashfs adrv_ubbpup_18.03 adrv_ubbpup_18.03.sfs'
this gave me the test adrv sfs to try

on my main Frugals partition, I started a new directory (BionicAdrvTest)
into this, I copied all the Bionic+12 iso files for a Frugal Pup, except its adrv.sfs which I now substituted with the fresh adrv sfs
added the approriate lines to my Frugal partition's menu.lst to offer this new Pup
booted up to it, and it worked, and is still working now after several re-boots (screenshot) - a Save-file was created on first boot which is presently about 9MB.

I still find each start-up leaves some icons 'unfinished' on the pinboard but a restartX fixes this. All links are there and working.

All my personalisations (added apps, configs, etc) are operative including linking my tray-reported internet use to the sns on my data partition which recent normal remasters tended to miss.

I feel this a-drive has produced a faster Pup than the other methods but need to try this with some other Pups. Those coming with an a-drive option, anyway.

So I will give your script a try out or three, and let you know how it goes.

Thanks again,

David S.

[musher0]

Thanks for your report, Davids45.

Good to hear!

Now, since the beaver is the animal emblem of Canada, as a dutiful Canadian, I will
have to present an official objection to the authors of BionicBeaver and BionicPup,
who no doubt where on LSD or mescaline when they drew that logo:
beavers are reddish brown in color, never green!!!

As proof!
That is a Canadian beaver, do not pay any attention to the file name.
Shucks, I will have to present an official objection to the Wikipedia photographer too!

[hamoudoudou]

"Hence, the Puppy remaster script IS outdated and very not user friendly given it cannot simply, for example, via one click, include ALL Personalization of a user's system."

My feed-back : i am used to remterize Puppies to create my puplets at home. It's quite an evidence that all these pets and scripts created apart somewhere in our forum are the proof thait remaster tool included in ISO needs some renew.
Ramsfs never tried
Remaster x is one i use.
When you are happy with a pupsave, after having used it long time, you can consider about remaster.. But pay attention to remaster only importants changes.. Just copying what is in RAM will be very big ISO. Start a new pupsave with just what you like and immediately remasterize it.
I was never deceived by 0_pupbuild_tools, and ISO is bootable..
About Bionic, each day Ubuntu remasterize it, because they are building it for apr26, date of release. in fact puppy has nothing of Ubuntu Bionic (systemd d, kernel, gnome desktop), Puppy has access to multiverse and universe repositories, which are users ones

[nic007]

"Hence, the Puppy remaster script IS outdated and very not user friendly given it cannot simply, for example, via one click, include ALL Personalization of a user's system."

My feed-back : i am used to remterize Puppies to create my puplets at home. It's quite an evidence that all these pets and scripts created apart somewhere in our forum are the proof thait remaster tool included in ISO needs some renew.
Ramsfs never tried
Remaster x is one i use.
When you are happy with a pupsave, after having used it long time, you can consider about remaster.. But pay attention to remaster only importants changes.. Just copying what is in RAM will be very big ISO. Start a new pupsave with just what you like and immediately remasterize it.
I was never deceived by 0_pupbuild_tools, and ISO is bootable..
About Bionic, each day Ubuntu remasterize it, because they are building it for apr26, date of release. in fact puppy has nothing of Ubuntu Bionic (systemd d, kernel, gnome desktop), Puppy has access to multiverse and universe repositories, which are users ones

The builtin puppy remaster script works quite well but isn't as user friendly as it should be. That is why I made a remaster suite based on the builtin script with user friendly options. One of the scripts in the suite is an automatic option where NO user input is required (the default action there is to personalize for the same computer). So, you select the automatic one and the remaster will be done without user input. BTW - RemasterX is exactly the same as the builtin puppy remaster script just with another/easier GUI. I've made an effort to improve on and add to the actual script. The link for my remaster suite pet has already been posted in this thread, you can download and try if you like.

[musher0]

Hello all.

I have uploaded a French version of my script here.

TWYL
~~~~~~~~~~~~~~~~~~
Bonjour à tous.

J'ai enligné une version française de mon script ici.

À+

[bigpup]

I will assume the Remasterpup2 that is being talked about is the latest version in Woof-CE.
https://github.com/puppylinux-woof-CE/w ... masterpup2

[davids45]

G'day,

I have made two a-drives from Pup save-files using musher0's script.

These were oldish recent Pups which had no a-drive by default, just puppy- and z- sfs and a save-file. So I didn't know if the a-drive would work since there wasn't one to begin with.

First mistake I made was to try running the script from another Pup - found I needed to be in the Pup itself to convert the save-file to an a-drive .

Once 'in the Pup', everything went quickly and smoothly. Well, when I got it right.

Second mistake was to not quite get the words after 'adrive-' right so the new a-drive file was ignored at booting .

For each test, once I had the a-drive sfs created in the particular Pup's /root/myapplications/bin, I made a new Frugal sub-folder of the Pup and copied the usual files from the iso and added the just-made a-drive.

Adding this new Pup to my Frugals menu.lst, I booted up each new Pup with its a-drive and each had the wanted applications from the new a-drive (pinboard screenshots). On closing down each new Pup, I made a save-file as normally required. Rebooting was normal.

Pets & sfs for applications
All my applications (as per icons on the pinboards) are added to a new Pup as pets made of symlinks to the program files stored on my data partition. Except gimp which I still add as an sfs. Initially I found gimp was not being included in the a-drive although the pinboard icon was still there, albeit as a missing file icon (!).

Adding an extra sfs
I found MU's sfs-combiner pet from 10 years ago and tried combining the gimp sfs with the just-made a-drive sfs. The new combined sfs (re-named as needed to be the a-drive sfs) I now used in place of the initial a-drive sfs and now each a-drive also loaded up the sfs of gimp .

So a good result for me and what I think I'm trying to achieve by remastering my Pups - I'm not really certain why, but that's life .

I'll keep on trying with other Pups and adding applications, missing libs, etc., as needed in each Pup.

Thanks again, musher0.

David S.

[nic007]

Hi, Davids45. Older Puppys don't support the adrv, ydrv, etc. but only the zdrv. However, one can still use the "adrv" method by renaming your big, base sfs to that of the zdrv and renaming your newly created "adrv" to that of the base sfs.

[musher0]

Hi, Davids45. Older Puppys don't support the adrv, ydrv, etc. but only the zdrv. However, one can still use the "adrv" method by renaming your big, base sfs to that of the zdrv and renaming your newly created "adrv" to that of the base sfs.

EEEEchch!!!

If you rename the zdrv, you lose it, nic007! And bye-bye to AA-LL-LL your drivers!

IIRC, that was a technique evolved by much respected Albertan compatriot and
forum member "mrb" shortly after he created a Puppy-4.12 that could load +/- 60
sfs's without blinking : it worked for him, but never for me!!!

I'll try to find the thread with his comments and mine. (It may take some "real"
research since that was quite a few years ago.)

~~~~~~~~~~~~
Edit --

Removed the "pdrv" script after discussion with nic007 below. Also because sfs_load
messes up a number of things. Some day or other, I'll try to make a version that does
not need sfs_load.

On the other hand, the script above psave2adrv.sh workds well on recent Puppies,
provided you do not already have an adrv.

BFN

[nic007]

musher0, you will find that most of the older puppys do not actually use a seperate zdrv as all the drivers have already been packaged into the base sfs. I use puppy 412, Wary and Racy and none of them have an operating zdrv for the drivers/extra drivers by default. So the "adrv method" to replace and act like an existing running savefile works perfectly for me with the name switching as suggested (my script is different of course to make this easy). Even if I had a seperate zdrv for drivers in this scenario, I would have merged the contents of the zdrv and the base sfs and called it the zdrv (no drivers are getting lost here). This option is normally available too when one does a remaster. I'm not quite sure I follow your suggestions if one has an old puppy and want to use the "adrv method". The thing is, one has limited options when working with an old puppy. You basically have the base sfs, zdrv and extra sfs's you can work with. The order of loading an old puppy would be in order of layers (preference) - savefile, base sfs, zdrv, extra sfs's. So if you want to replace the savefile with an sfs to load your changed configurations, etc. in the top layer, the name of that sfs MUST be the name of the original base sfs according to the booting sequence. The zdrv then follows and then extra sfs's. Creating an extra sfs for additional drivers may or may not work, depending upon whether those drivers are required during the bootup process. As a matter of interest and clarity: what is the name of your "adrv" replacing your savefile when dealing with an old puppy that does not support the adrv?

[musher0]

Hi nic007.

In the new version of my script, it is "pdrv". P being sort of the typical letter for
anything Puppy. psave to pdrv, it is easy to remember what it does.

About the order thing, is it that important? In my mind, sfs layers are more like
slices of swiss cheese, with holes in them, and the full parts of one slice may or
may not cover the holes of other layers.

Let's say that you have icewm in one sfs, but not in any other "slice" or sfs: it will
work regardless of which slice or layer it is in. But if you compile and include a
more recent version of the fsck utility in an "extra" sfs, it will sit over the old
version, it will block the access to the old version and be used instead.

So that theory of layers, of what gets executed first depending on the layer, is not
absolute, as I understand it. Anyway, you do it your way, through remaster, and I
do it my way, ok?

BFN.