Empowering the Zdrv

[RSH]

However, the puppy cloner will not respect one's choice of zdrv-xxx.sfs. It will ask you if you want to create a zdrv, and if you answer yes, it will create its own (6-7 Mgs), not the substitute main file you provided initially. This needs further investigation and testing.

I have disabled this in LazY Puppy. I can run every sfs file i want as "substitute"-zdrv.sfs - even if it was new created and named WhereTheHellAreMyPasswordsICouldNotFindMySlippersAndSoIGetDrunk.sfs

Lazy Puppy can boot with every sfs file as "substitute"-zdrv.sfs i want to boot with.

[jrb]

Hello again, jrb.

Tested your idea a couple of ways in a new puppy alpha being created (not by me). So here are a few test notes that may or may not be useful to others.

Do not put the devx in place of the regular puppy sfs: you'll get a panic message in the loader. This linux loader needs a properly configured "root" sfs with at least a simple /root/ structure in it.

So I created a "root" sfs that had only 12 k (with near-empty my-documents and my-applications directories), but this time it loaded without "panic" and the entire Puppy in the zdrv was available and functional.

However, the puppy cloner will not respect one's choice of zdrv-xxx.sfs. It will ask you if you want to create a zdrv, and if you answer yes, it will create its own (6-7 Mgs), not the substitute main file you provided initially. This needs further investigation and testing.

That's it for now.

Regards.

Interesting. One of the Puppies I tested with this let me use an empty SFS for the puppy_xxx.sfs (can't remember which one ), one insisted I put at least one file in the puppy_xxx.sfs and now you've found one that requires /root. Probably has to do with the date of the Woof build they used. Will have to keep testing I suppose.

Cheers, J

[nooby]

Interesting solutions you have here.
It is way over my noob experience
so I don't know how to follow your instructions.

What is your latest practice and could you
describe how one do it in some easy to follow way please!

[Wognath]

jrb, you wrote to seaside,

As I remember you're an advocate of running without pupsaves. I followed your lead and have been doing that for a while now using an initialization script in /etc/init.d (previously in my zdrv now in the main sfs). The script has gotten a lot simpler now that I am putting so much of my configuration directly in my main SFS file. But that's another story and I'll write it up in a separate thread.

If you have done this, could you please link it? No luck searching. Thanks.
Wognath

[mikeb]

I changed the ordering of sfs files many moons ago with the main pup_xxx.sfs at the bottom but it would require significant initrd changes.
On the other hand

Code: Select all

mount -t aufs -o udba=reval,diropq=w,dirs=${UMNTMAIN}${ZLAYER}${UMNTRO} unionfs /pup_new 

as a sample of how the zdrv is loaded in standard puppies it does not look like major surgery to move the Zdrv layer.
Main advantage would be to use the normal names so compatible with a remaster and perhaps other scripts.

mike

[jrb]

jrb, you wrote to seaside,

As I remember you're an advocate of running without pupsaves. I followed your lead and have been doing that for a while now using an initialization script in /etc/init.d (previously in my zdrv now in the main sfs). The script has gotten a lot simpler now that I am putting so much of my configuration directly in my main SFS file. But that's another story and I'll write it up in a separate thread.

If you have done this, could you please link it? No luck searching. Thanks.
Wognath

Pardon the delay, I've been a bit lax in checking the forum lately, and I never got around to writing up that thread.

The key part of the initialization script in /etc/init.d is:

Code: Select all

sed -i 's|PUPMODE=5|PUPMODE=12|' /etc/rc.d/PUPSTATE

This tells puppy that there is already a save file so it doesn't bother to ask if you want to create one.

I should mention that in order to turn off the Quickstart wizard and Setup wizard at every boot you need to create the empty file /var/local/delayedrun_firstboot_flag. Of course this means you have to place things like /etc/localtime and other custom setup files in your new custom puppy_xxx.sfs file.

Cheers, J

[mikeb]

Yes the custard in my soup made me itch.

Perhaps it would be a good idea to remotely attach a hapster

mike

[jrb]

Yes the custard in my soup made me itch.

Perhaps it would be a good idea to remotely attach a hapster

mike

Had your morning coffee yet mike

[mikeb]

Don't drink it..... but in another recent thread someone was trying to use the zdrv to load a save and layering was a problem...only found this one recently.

Actually on further memory searching UMNTMAIN is pup_rw and pup_xxx.sfs merged so not so easy to move around within the default init. If the rw layer was a separate variable then no problem.

mike

[jrb]

Don't drink it..... but in another recent thread someone was trying to use the zdrv to load a save and layering was a problem...only found this one recently.

Actually on further memory searching UMNTMAIN is pup_rw and pup_xxx.sfs merged so not so easy to move around within the default init. If the rw layer was a separate variable then no problem.

mike

Thanks for mentioning that. I missed Multiple SFS support in initrd. I'll give it a good read.

P.S. I don't drink it either.

[mikeb]

current inits are too hairy for me... mine is based on puppy 2... but minor changes should be possible.

mike

[Wognath]

jrb,
Thanks for the information about running without savefile. I've got it working now, based on Lucid. Since remastering a custom Puppy is so easy, it's surprising that running without savefile is so complicated. ...
Wognath

[greengeek]

current inits are too hairy for me... mine is based on puppy 2... but minor changes should be possible.

Hmmm, I have only just stumbled across the concept of zdrvs and the idea of using them to tailor a puppy to one's own needs. i like your idea of placing the puppy.sfs at the bottom (rather than at the top, which I do not understand...) and I would like to see this idea developed.

Imagine a puppy that was well configured, ready to accept user customization (by way of zdrv or other sfs overlayed over the top) and it was easy to add the extra sfs pre-boot or even on-the-fly.

That would be great.

Why did this concept get buried after puppy 2?

EDIT :Now that I think about it - it would be nice to have some sfs loaded underneath the normal pup.sfs (like an sfs that tells the puppy what language and timezone to load) and other sfs over the top (like a word processor sfs)

[mikeb]

Hmm not sure what the advantage would be of being underneath...bear in mind the read/write layer is always on top.
Being underneath is the reason why sfs on the fly is so large...lots of hacky workarounds needed and the result is often quirky...my activate is small and simple by adding on top.

Layering considerations were not considered when unionfs was used as it was so limited so I assume the code from then carried on rather than revising it to take advantage of what aufs has to offer.

zdrv was more thought of as a way to get around the change that sfs are not loaded automatically if added next to the main sfs ...note my 415 loads any suitably named sfs as used to be the case.
Also was looking at kernel sources and the loop device limit went around kernel 2.6.24 so you can load as many as you like without needing a boot parameter. the kernel is happy...the coder just has to add mount points/nodes as needed to use them.

Sorting layering would require a bit of a small rejiggle of the code but loading on the fly involves a three character change...no excuses there.

Also note my save sfs is not used as an sfs but simply has its content copied into the read/write layere ( tmpfs)...I originally used tar but embutils tar was too flaky...any archive format could be used really which I suppose would allow encryption.

Bear also in mind I simply used puppy 2 and the techniques from slax to get this combination...so this stuff is from 2006.....

mike

[greengeek]

Hmm not sure what the advantage would be of being underneath...bear in mind the read/write layer is always on top.

I'm not really explaining it well because my understanding of these processes is poor - when I said "underneath" what I was trying to imply was that the main puppy.sfs would 'look at' the lower level sfs that is already loaded - and modify it's own behaviour based on that.

What I meant was something like this:

"initial.sfs" (or zdrv.sfs) gets loaded and contains info describing what keyboard layout and language and wifi key the user wants. Than "puppy.sfs" gets loaded and brings up the desktop with those basic user parameters it grabbed from the initial sfs. Then the "savefile.sfs" (if there is one at all...) gets loaded on top, and contains all the applications and broader personalisation etc.

I'm just looking at a simple way to get puppy to boot with some basic desktop parameters pre-configured. (I want to send puppy sampler CDs to my friends and preconfigure the wifi ssid etc so they don't have to run the wizards or see the quicksetup wizard. I know the basic set up they need and I want to tell that to the initrd somehow, before the main puppy.sfs makes it's own assumptions about defaults.)

[mikeb]

Hm ok but the components or the layered filesystem are just that...there is no 'intellegence' going on...aufs just takes the top file or whiteout as the valid content in the filesystem that the system 'sees' . So its up to the builder to arrange things to produce the result they want...if you want premade configs they need to be on a higher layer by some method than any existing defaults in order to be used.
The layers are stacked and the result is chrooted into to run as the puppy you know and love.

Sort of thing that better explained in a diagram and iirc there is one somewhere around.

Imagine each layer as a sheet of glass with various blobs marked on and you are looking down from the top .

Unfortunately puppies mount command no longer lists the union layer which is a shame as you could easily see what was on top of what...instead it has to be surmised from the initrd scripts.

Hope that helps a bit...tis frustrating when you have an aim but are still learning the mechanisms.

mike

[greengeek]

I have spent a couple of days using the zdrv.sfs in slacko 5.6 in an attempt to try to overwrite the timezone symlink used by puppy as the default during booting of a live CD.. I now understand better what you mean about the relative priorities in how the initrd treats the main puppy.sfs versus other .sfs files that are available to it. I can't do what I need to do by using the zdrv

I see that a file in the zdrv will be grafted into the running system ONLY if that file is NOT currently existing in the main puppy.sfs.

I need a way to overwrite a file in the main puppy.sfs during the boot process. Are there any other 'xxdrv.sfs' files that achieve that?

If not is there any way I can change the priority of the zdrv so it sits higher in ranking than the puppy.sfs?

[rufwoof]

If not is there any way I can change the priority of the zdrv so it sits higher in ranking than the puppy.sfs?

Wasn't that the whole point of this thread, i.e. in the original posting :

rename puppy_xxx.sfs to zdrv_puppy_xxx.sfs and rename my generic SFS to puppy_xxx.sfs. Now my applications take precedence over the main puppy files.

[greengeek]

Wasn't that the whole point of this thread, i.e. in the original posting :

Yes, I guess so
In my defense I have a slow brain and it's a very cold morning here...

I guess what I was really hoping for was for someone to say - "the zdrv priority can't be changed, but hey, there is another xxxdrv.sfs that can be used instead..."

Now that I am starting to understand the layering a bit better (I'm late to the party...) it surprises me that there is no mechanism to allow overwriting of even a single file within the puppy.sfs other than by usage of a boot code parameter like 'pkeys=xxx" or "plang=xxx" does..

Maybe it is time for a boot cheatcode of something like "puppy ppriority=xxxx.sfs".

EDIT : (that way I could use as a foundation the fantastic work of someone like 01micko in producing the wonderfully complete slacko_xxx.sfs and then I could stuff it up easily with my own overwrites. At least then I wouldnt be stuffing up what is INSIDE the slacko_xxx.sfs the way I am doing now...).

Constantly remastering a slacko_xxx.sfs and ending up with so many different sfs versions with the same name is annoying. Itd be so much nicer if I didnt have to change the slacko_xxx.sfs at all, but simply added some changes by using the "dumb_user_drv.sfs" as an overlay.

EDIT 2 : That way I would be using the work of 01micko as a form of "kernel" and leaving it untouched.
.

[greengeek]

Maybe the method I am looking for is actually the direct OPPOSITE of the way jrb has done it - maybe I really want to leave the names of the puppy.sfs and zdrv.sfs intact (so there is no confusion) and instead just change the wording in the last few lines of the DISTRO_SPECS file in the initrd.gz (which is what I do anyway to identify that I have modified the pup)

eg: if DISTRO_SPECS shows the following:

Code: Select all

DISTRO_PUPPYSFS='puppy_slacko_5.6.sfs'
DISTRO_ZDRVSFS='zdrv_slacko_5.6.sfs'

I could possibly reverse the names as follows:

Code: Select all

DISTRO_PUPPYSFS='zdrv_slacko_5.6.sfs'
DISTRO_ZDRVSFS='puppy_slacko_5.6.sfs'

then the contents of my zdrv might get treated with the same dignity as was previously reserved for the main puppy.sfs

Hmmmm, I feel some experimenting coming on...