Empowering the Zdrv
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
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
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?
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?
Wasn't that the whole point of this thread, i.e. in the original posting :If not is there any way I can change the priority of the zdrv so it sits higher in ranking than the puppy.sfs?
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.
Yes, I guess sorufwoof wrote:Wasn't that the whole point of this thread, i.e. in the original posting :
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.
.
Last edited by greengeek on Sat 31 May 2014, 21:00, edited 1 time in total.
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:
I could possibly reverse the names as follows:
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...
eg: if DISTRO_SPECS shows the following:
Code: Select all
DISTRO_PUPPYSFS='puppy_slacko_5.6.sfs'
DISTRO_ZDRVSFS='zdrv_slacko_5.6.sfs'
Code: Select all
DISTRO_PUPPYSFS='zdrv_slacko_5.6.sfs'
DISTRO_ZDRVSFS='puppy_slacko_5.6.sfs'
Hmmmm, I feel some experimenting coming on...
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)
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)
Hi guys,greengeek wrote: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:I could possibly reverse the names as follows:Code: Select all
DISTRO_PUPPYSFS='puppy_slacko_5.6.sfs' DISTRO_ZDRVSFS='zdrv_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.sfsCode: Select all
DISTRO_PUPPYSFS='zdrv_slacko_5.6.sfs' DISTRO_ZDRVSFS='puppy_slacko_5.6.sfs'
Hmmmm, I feel some experimenting coming on...
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'
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
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.
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.
@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
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.gyro wrote:@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
Cheers, J
Informer les peuples barbares
çà 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
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
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.
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.
Last edited by musher0 on Mon 23 May 2016, 14:27, edited 1 time in total.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
-
- Posts: 807
- Joined: Mon 12 Oct 2009, 17:11
zdrv-xxx.sfs in Slacko-6
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
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
Re: zdrv-xxx.sfs in Slacko-6
Hello.B.K. Johnson wrote: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
I just answered you there.
Best regards.
musher0
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
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?
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?musher0 wrote: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.
Use boot params
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)This shows how to use these params. e.g.or
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
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
Code: Select all
pupsfs=sda2:/wary071/zdrv_071.sfs zdrv=sda2:/wary071/wary_071.sfs
Code: Select all
ydrv=sda2:/wary071/zdrv_071.sfs
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