Empowering the Zdrv

[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...

[rufwoof]

I like mikeb's layers of glass/blobs description. There's also this link http://puppylinux.com/development/howpuppyworks.html

ramdisk pup_rw (/initrd/pup_rw) is perhaps the way to go for you. Script that over-writes/adds to that as desired. Which is basically the way mikeb performs saves/boots as I understand it.

I do something similar, but that I run after booted to gui/desktop rather than during the boot stage. i.e. copy in/replace config files etc from HDD to the respective directories (in effect writing to pup_rw) using a script (in effect a dos autoexec.bat type file).

You just have to identify what needs to be changed (and where its stored). For each SFS I load that way, I have the respective config files for the application stored alongside the sfs file where the config file is tuned to the way I want the application configured (locale etc.) and that get copied to the relevant location as part of the sfs load process. (sfs_load some.sfs; cp someconfig /root/.someconfig)

[jrb]

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

Hi guys,

Just picked up on this thread and thought I should comment. Your idea of reversing the names in DISTRO_SPECS is not a bad idea, but it would have to be done in the DISTRO_SPECS file in initrd.gz.

What I have done, along with reversing the names of the .sfs files is open the initrd.gz file, copy in the pup_a folder and init files from the Slacko-5502 initrd.gz and add:

Code: Select all

DISTRO_ADRVSFS='adrv_slacko_5.7.0.sfs'

just under the DISTRO ZDRVSFS line. The adrv file loads before the puppy.sfs file and take precedence over it. I use it to customize settings for different machines. That way I have Micko's stock Slacko-570 in the the zdrv, all my added in packages in the puppy.sfs and all my machine specific scripts in the adrv. I don't know why Micko dropped the adrv idea from 5.6 and 5.7, wouldn't have hurt to leave it in even if unused.

Now that I consider your idea, I would do that too and then I wouldn't have to rename the two sfs files. I like it and will do it on the next Slacko.

Cheers, J

[greengeek]

Hi jrb - I can confirm that swapping the two names in initrd.gz as shown above DOES allow the zdrv to take precedence over the main puppy sfs. Just spent the last couple of hours giving it a try and so far it works perfectly. I haven't tried adding any pets yet so more info to follow if I find any problems.

My main aim for this is to build live CD puppies anyway so any downstream problems from doing this are not likely in my case. Seems to work fine though!

Thanks for the zdrv empowerment thread. I'm a big fan of your work. Love the reductionist philosophy.

[gyro]

@jrb,
Sorry if this rains on your parade, but the "init" script of Slacko 5.7 supports both adrv and ydrv, although neither is configured in DISTRO_SPECS. Both of these load above the main puppy.sfs.
So, if you modify DISTRO_SPECS in "initrd.gz" to add an adrv line and a ydrv line, you can use "ydrv_slacko_5.7.0.sfs" to patch the main puppy.sfs and "adrv_slacko_5.7.0.sfs" for you apps, or the other way round.

gyro

[jrb]

@jrb,
Sorry if this rains on your parade, but the "init" script of Slacko 5.7 supports both adrv and ydrv, although neither is configured in DISTRO_SPECS. Both of these load above the main puppy.sfs.
So, if you modify DISTRO_SPECS in "initrd.gz" to add an adrv line and a ydrv line, you can use "ydrv_slacko_5.7.0.sfs" to patch the main puppy.sfs and "adrv_slacko_5.7.0.sfs" for you apps, or the other way round.

gyro

, Imagine my surprise. I thought I had checked the slacko_5.7.0.sfs init file and not found ADRV. I take back everything I said about micko, well maybe not the good stuff. Thanks gyro for cluing me in.

Cheers, J