Empowering the Zdrv

[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

[Pelo]

çà pourrait être intérressant d'en informer les non-citoyens de sa majesté, hispanisants et francophonistes entre autres.
Give the information to european citizen would be of some interest.
Can we make a summary of this subject and inform the rest of the world ? pls answer yes ! (Germany and consort excepted bien sûr, top secret)
Le comté de Bulkley-Nechako et la province de la Colombie-Britannique parlent-ils français, je l'ignore. nous devrons sans doute faire la traduction, à moins que nos amis quebecquois s'y attachent.

a tribute to the men and women who served in the Canadian Army during D-Day and World War II. To these people, we owe the freedom that we take for granted. Let us never forget their sacrifice. God bless them all.
junobeach

[musher0]

Thank you kindly for your thought of gratitude, pelo.

Canadians rarely toot their own horns, but in this case we should. I have
met and discussed with a few French-Canadian veterans of the Normandy
assault, and they were indeed quite aware that they were contributing to the
liberation of the land of our fore-fathers.

"Contributing", because indeed, alongside us were American, British and Australian
soldiers, your own General Leclerc's tank division, some Polish airmen, etc., etc.

I wish the younger generation of Canadians had your sense of history.

BFN.

[B.K. Johnson]

Hi guys
I posted a query here:
http://www.murga-linux.com/puppy/viewtopic.php?t=94449
but haven't got an answer. I would appreciate your help. Thanks.

B.K. Johnson

[musher0]

Hi guys
I posted a query here:
http://www.murga-linux.com/puppy/viewtopic.php?t=94449
but haven't got an answer. I would appreciate your help. Thanks.

B.K. Johnson

Hello.

I just answered you there.

Best regards.

musher0

[nic007]

I've tried this but get a kernel panic at loading. Made a zdrv.sfs and copied contents of pup_rw to it. Then swapped the names of the base sfs and zdrv. Booting from flashdrive and zdrv, base sfs, initrd.gz, vmlinuz located in the same directory. Is there a way to make it work without tinkering with the initrd.gz?

[musher0]

Hi nic007.

It's easy to squish stuff with this procedure. I hope you have a back-up?
Please see my post above and jrb's reply.

BFN.

[nic007]

Hi nic007.

It's easy to squish stuff with this procedure. I hope you have a back-up?
Please see my post above and jrb's reply.

BFN.

Hi musher0, not sure I follow. I don't have a devx file. Will it work if the two sfs files are not in the same location... where should I move it to? ....or does this method just have issues anyway like it may work or may not?

[gyro]

Of course instead of renaming files or moding the initrd.gz, you could try specifying them as boot params.

Here is an extract from slacko 5.7 "init", (it's been in standard "init" for a while now)

Code: Select all

[ $pupsfs ] && PUPSFS=$pupsfs #format partition:<path><filename> ex: sda2:/wary071/wary_071.sfs
[ $zdrv ] && ZDRV=$zdrv #ex: sda2:/wary071/zdrv_071.sfs
[ $adrv ] && ADRV=$adrv
[ $ydrv ] && YDRV=$ydrv

This shows how to use these params. e.g.

Code: Select all

pupsfs=sda2:/wary071/zdrv_071.sfs zdrv=sda2:/wary071/wary_071.sfs

or

Code: Select all

ydrv=sda2:/wary071/zdrv_071.sfs

Just be aware of the following limitations:
1) They don't fail gracefully, so get it right.
2) They cannot work on usb drives
3) Only the pup..sfs and pupsave code is capbable of mounting a partition. All other sfs's must reside on one of these 2 partitions.

Remember the order of the sfs's in the aufs stack is adrv, ydrv, pupsfs, zdrv.

gyro

[nic007]

I've copied the files to hard drive and re-booted. It now seems to load without kernel panic but later stops at a login error