Puppy Remaster Program needs updated from 18th Century

What features/apps/bugfixes needed in a future Puppy
Message
Author
User avatar
davids45
Posts: 1326
Joined: Sun 26 Nov 2006, 23:33
Location: Chatswood, NSW

Musher0's script

#31 Post by 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 :oops: .

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 :oops: :oops: .

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 :D .

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 :shock: .

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

Thanks again, musher0.

David S.
Attachments
puduan-adrive-allapps.jpg
Puduan-Pup pinboard with icons of applications from the script-made a-drive (gimp from a combining of sfs files - a-drive and gimp.sfs)
(98.63 KiB) Downloaded 571 times
stretchdeluxe-adrivelinks.jpg
DPup-Stretch-Deluxe running with a script-made a-drive
(105.94 KiB) Downloaded 560 times

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#32 Post by 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
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#33 Post by musher0 »

nic007 wrote: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!!! :lol:

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
Last edited by musher0 on Mon 02 Apr 2018, 15:50, edited 1 time in total.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#34 Post by 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
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#35 Post by 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.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#36 Post by nic007 »

musher0 wrote: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.
The order of layers (preference) is most important. That's why we have the savefile at the very top to override everything loaded thereafter. Your pdrv won't work as suggested because it's loaded as an extra sfs and lower priority as the base sfs and zdrv. So you can do it your way but it won't work as replacement for the savefile or advr in older puppys. You will have to rename it to the name of the base sfs so that your configuration changes or whatever takes preference. I don't need to remaster anything. Now take a deep breath.... :wink:

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#37 Post by musher0 »

Why should I? I'm secure in what I produce, man!

Please try my script before bad-mouthing it! As long as your puppy has shinobar's
sfs_load, rsync and mksquasfs, it will work. And of course a pupsave file?! :twisted:

Now you take a deep breath! :)
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#38 Post by nic007 »

musher0 wrote:Why should I? I'm secure in what I produce, man!

Please try my script before bad-mouthing it! As long as your puppy has shinobar's
sfs_load, rsync and mksquasfs, it will work. And of course a pupsave file?! :twisted:

Now you take a deep breath! :)
You are missing the point my friend. It has NOTHING to do with your script (which I'm sure works for producing your adrv and your pdrv, etc.). The discussion is about what is going to work for older puppys which do not support the adrv. And now I'm going to repeat myself. Making a pdrv or any other extra sfs with sfs_load, will load LAST in order of preference at bootup. Same files in the base sfs or zdrv sfs will take preference because they have higher preference (like the contents of a savefile has). I'm not going to try to explain this to you further but will leave you with this thought to test your OWN theory. Bootup an older puppy like Racy. Save your configuration changes (like a change to background) to a pdrv.sfs as you suggest. Then bootup your base sfs and zdrv (if you have one)... and your pdrv.sfs with sfs_load and see if your configuration changes have been effected. Then please report back your results. Thanks and cheers.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#39 Post by musher0 »

Ok, let's play who's the most stubborn. If you're not going to test my script, I'm not
going to re-install some old Pup. Even if I do I won't tell you. So there. This is
silly. Whatever the theory of it is.

You try to help people, to get co-operation and confirmation on tests and either you
get a lecture or you get flak or you get misplaced pride.

When it's not shinobar's sfs_load f...g up your PuppyPin. Or a French rsync by
busybox. You people want to be spoon-fed with pre-cooked scripts and not
participate in the tests, and play "blame the developer" when things do not go as
expected and you do not get perfection the first time. davids45 excepted.

Enough. Where's the nearest bridge? I think I'll go there and jump off.

I just saw a flight in V formation of about 200 wild geese heading NW back home
along the Ottawa River. Now, they know the meaning of co-operation.

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#40 Post by nic007 »

musher0 wrote:Ok, let's play who's the most stubborn. If you're not going to test my script, I'm not
going to re-install some old Pup. Even if I do I won't tell you. So there. This is
silly. Whatever the theory of it is.

You try to help people, to get co-operation and confirmation on tests and either you
get a lecture or you get flak or you get misplaced pride.

When it's not shinobar's sfs_load f...g up your PuppyPin. Or a French rsync by
busybox. You people want to be spoon-fed with pre-cooked scripts and not
participate in the tests, and play "blame the developer" when things do not go as
expected and you do not get perfection the first time. davids45 excepted.

Enough. Where's the nearest bridge? I think I'll go there and jump off.

I just saw a flight in V formation of about 200 wild geese heading NW back home
along the Ottawa River. Now, they know the meaning of co-operation.

BFN.
Your script has nothing to do with the matter. :D :D :D If I haven't known you better from this forum, I might have concluded that you are, well, dumb, (okay, let's rather say stubborn). But I'm sure that's not the case..but I'm starting to wonder. You seem to be insecure about your script which is NOT under attack at all. :D :D :D

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#41 Post by musher0 »

Fine.

Let's say -- for now, until I or someone else checks further --
that my scripts are not for older Pups.

I have other, urgent, things to do today.

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#42 Post by nic007 »

Last reply. Ask yourself this question and maybe something will hit home. Why do you think it's necessary to save the contents of your savefile to an adrv and not to any other made-up sfs file called pdrv.sfs or whatever, instead?

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#43 Post by musher0 »

It's not necessary either way. Some people will be happy forever with a 9Gb pupsave.

Some other people do not like big pupsave files, but find the remaster process long,
arduous, and demanding a lot of focus and knowledge. For a newbie, I'd go as far as
saying that remastering is an anxiety generator. ("Been there, done that.")

Another factor which is important to me, but maybe not to other Puppyists, is that
remastering spoils the original Pup. I do not like remastering and try to avoid it.

That does not mean that a developer should not adapt a woof-CE product for say, the
icewm or waimea WMs, if we want to showcase them -- or Linphone, or a different
browser, or what have you. But once that variant is finalized, it should stay finalized as
much as possible.

Anyway, in my post above (q.v.), I removed my "pdrv" script until I find a replacement
for sfs_load and study the subject more.

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#44 Post by nic007 »

As a matter of interest here is my howto on what we have been discussing, posted many months ago: http://www.murga-linux.com/puppy/viewto ... 790#944470
I've been using my Puppys for years this way. BTW - If you keep your adrv very small (mine is about 2MB) and only use it to save configuration changes/settings (like me), you may just as well operate with a small savefile instead. A savefile is more flexible anyway as it is read and write and not read-only like an sfs file. I will however never use or recommend the use of a huge savefile. Choices, choices...

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#45 Post by musher0 »

Hi nic007.

With a rested head, something did "hit home":

-- Absolutely all Puppies can have a zdrv_xxx.sfs

-- Absolutely all versions of mksquashfs append by default. The user has to
specify the "-no-append" parameter to squish an existing squash file. (Play on words
not really intentional!) Otherwise it appends.

Do you see where I'm going ??!! Just a thought.

If applied, of course, this raw reasoning will need to be refined. Among other things,
providing the user with a small pupsave somewhat automatically to replace the
one that has just been squashed. Plus lots of tests so everything would be down pat.

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

Re: Puppy Remaster Program needs updated from 18th Century

#46 Post by greengeek »

belham2 wrote:Every time I do a remaster in a puppy, I want to scream and pull my hair out at the idiocy of not being able to easily incorporate all my personal settings into the remaster (constantly dragging and dropping everything is 18th century stuff, people!!).
Remastering correctly is about asking the user the following questions:

- Do you want to keep the original puppy.sfs identical to what the developer released? (the answer IMHO should always be Yes, but in the case of current puppy remaster utilities is "NO - lets fiddle with it but call it the same name - despite the confusion this causes".

- Do you want to create a "personal sfs" which adds your personal preferences as a new layer on top of (ie dominating) the main puppy.sfs?

- Do you want to add some new personalisations on top of the previous "personal sfs created at some prior time"?

- Do you want to add some other fware, software or mods/scripts etc as an experimental layer below the main puppy.sfs just to see if they work (but withut crippling your system)?

Unfortunately there is no one remaster script that is able to work properly in all puppies because the "layering" of puppies has changed over time.

Originally the main "puppy.sfs" was the "top" layer and nothing else could superceed it (except temporarily loaded sfs files).

More lately puppies can have "xdrvs" which may sit either above or below the main puppy.sfs depending on how the initr.gz specifies the layering.

What is needed is more clarity around which layer is "top dog" and whether or not a remaster script alters the main puppy.sfs released by the dev (it should not) or only alters the other "super layers" that sit higher than the original puppy.sfs

Until the layering of the main puppy.sfs, and the personal.sfs, adrvs, zdrvs, fdrvs, and the programatically loaded sfs files is better defined there is no way that a remaster script can give the newbie (or even mildly experienced) user what they want.

It is currently "DIY"

(many thanks to nic007 for his remaster scripts - I use modified versions of them to remaster my Slacko 5.6 based system which is structured according to JRB's "empowering the zdrv" method. Newer pups have xdrvs that Slacko56 lacks so I had to follow JRBs unconventional method)

For me the system that works is:

- Keep the basic puppy.sfs pristine. Don't change it (after all that is what the dev released!! Don't bastardise it !!)
- Add your personalisations on top (steal the /initrd/pup_rw contents and make an sfs)
- Add any further personalisations (in future sessions) by also grabbing the new contents of initrd/pup_rw and adding them to the initrd/mnt/tmpfs file (which is the sfs containing your previous personalisations).

The only issue is - what is the layering system of your current pup?

If you don't know what it is then you have no chance of getting a good outcome.

So many puppies...so many layers!

But what about save files? I have no idea how best to handle them during a remaster. Why would anybody use them? What is the purpose of having a "system critical" file space that can be permanently and instantaneously corrupted by loading a single bad pet or piece of malware ???$%#!????

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#47 Post by musher0 »

Hi greengeek.

Please find attached BarryK's README.txt included in the initrd.gz of Puppies.
I think it will answer a good number of your questions.

IHTH
Attachments
README.txt.zip
(5.25 KiB) Downloaded 154 times
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#48 Post by belham2 »

Guys,

This is all I am trying to say:

Why is it we cannot have, just like DDogs and/or Anti-X, a beautiful, simple one screen pop-up for remastering that includes every option your heart could desire? Whether doing a full "Personal" remaster or not. Just one screen. Beautifully laid out. Simple. Clear. Concise. All simple clicks, making your choices. This exists but people keep defending the "Model T" that is the current remaster situation in all Puppys (and Woof-CE).

Why is it this beautifuly nirvana described above can be done in DDogs and Anti-X (and to a certain extent, with Nic007's scripts) but it cannot be a feature of the ALL existing puppy OSes/Woof-CE?

There should be never of this:

------forcing a user (especially "new" users) to open multiple file managers because they want to "Personalize" their remaster? How can none of you (except nic007--hence, why he created his scripts) see the modern-day stupidity and lack of ease of use in this method?? Barry always, always, assumed that people would never first want to create a "Personalized" (everything from /root & /etc), so thus the remaster-script made it hard, made it mind-numbing my heavens, having to "drag & drop" everything, for all your email. browsers, program settings/!!) & opening multiple file managers to do so. This is out-dated. I'll say it again" OUT-DATED.

This is all I am talking about.

If we didn't have nic007's scripts, or Musher being forced (God Bless him--he's always creating workarounds for us with a lot of things, witness the beginnings of Dpups!) to always come up with workarounds (adrvs, pdrvs, solar-Battlestar-Galactica-drvs....good heavens!!!), I would QUIT all puppy OSes completely.

Someone, or someone(s), have created a better mousetrap with regards to remastering. Remastering should ALL be controlled from one beautiful pop-up screen, for any option a user could desire, and then it is off & running. This is not currently the case, yet it exists in DDogs, in Anti-X/MX-Linux (and to a certian extent with Nic007's stuff).

But to defend the current setup with remastering as "modern", or "user-friendly" and/or anything other than a clicking-dragging-dropping "pain the a##", is the miss the forest for the trees.


P.S. On a lighter note: Greengeek, when we getting a new, fully updated Banksy? :wink:

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#49 Post by musher0 »

As luck would have it, this doc about remastering AntiX comes without
any illustrations, so we still do not know what belham2 is in awe about! ;)

Same thing for AntiX' big brother, MXLinux.

If someone can come up with illustrations, please do.

I'm telling you in advance that I will not attempt to code anyhing. I don't
have the talent for pretty interfaces, plus my idea of an ideal interface is
an rxvt window with a numbered menu! :twisted:

But i believe wiak has found an easy "language" to produce pretty
interfaces, so maybe someone with the talent could use it?
Last edited by musher0 on Tue 03 Apr 2018, 19:44, edited 3 times in total.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#50 Post by greengeek »

musher0 wrote:Please find attached BarryK's README.txt included in the initrd.gz of Puppies. I think it will answer a good number of your questions.
Thanks musher - indeed that readme offers a lot of info that is highly relevant to anyone wishing to effectively remaster their pup.

Obviously not the original file as written by BarryK though - it contains references to much later inclusions, and reveals the fact that the layered sfs files are not identical (or present) on all pups.

This is at the heart of why remastering is fraught with difficulties.

System files do not belong in the savefile layer, they only belong in the main puppy.sfs. If the user wants to add personalisations they belong in either a personal.sfs or the save file. No-one should be encouraged to drag and drop files confusing the different system/userspace areas.

An effective remaster script must take into account the particular layering arrangement used by the specific pup it is used in. As well as taking into account what the user intends to achieve. One script won't fit all.

I don't agree with remastering the main puppy.sfs - except where it is done to eliminate errors or add new features or functionality - and that process should be done by the dev or by the woof-CE process. Shouldnt be part of userspace.

All other "remastering" should be aimed at the personal.sfs only (whichever of the xdrvs represents the personal.sfs....)
belham2 wrote:when we getting a new, fully updated Banksy?
Good question. It's still cooking. (Just last week i completed the "progressive personal sfs remaster" script that has been plaguing me for two years. It's a work in progress) :-)

Post Reply