Empowering the Zdrv
Empowering the Zdrv
(Note: I’m keeping this brief so feel free to ask questions)
From time to time I have tried putting my favourite applications in the zdrv_puppy_xxx.sfs file so they will be automatically loaded at bootup and not take space in a Pupsave (or be lost when a Pupsave dies). I can also transfer them from pup to pup without reinstalling. This works well except for the fact that the main Puppy.sfs takes precedence over the Zdrv and overwrites any files that they have in common.
Recently it occurred to me how to overcome this, 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. One bonus is that any configuration changes I want, such as show hidden files and small icons arranged vertically in Rox can be placed in my SFS along with my apps and will be implemented at bootup.
In practice I keep a copy of my generic SFS with all the apps. When I try a new puppy I make the configuration changes I want, grab the configuration files from /initrd/pup_rw and add them to my generic SFS and then rename it to whatever the new pups name is. Then I rename the main puppy file to zdrv and I’m good to go.
From time to time I have tried putting my favourite applications in the zdrv_puppy_xxx.sfs file so they will be automatically loaded at bootup and not take space in a Pupsave (or be lost when a Pupsave dies). I can also transfer them from pup to pup without reinstalling. This works well except for the fact that the main Puppy.sfs takes precedence over the Zdrv and overwrites any files that they have in common.
Recently it occurred to me how to overcome this, 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. One bonus is that any configuration changes I want, such as show hidden files and small icons arranged vertically in Rox can be placed in my SFS along with my apps and will be implemented at bootup.
In practice I keep a copy of my generic SFS with all the apps. When I try a new puppy I make the configuration changes I want, grab the configuration files from /initrd/pup_rw and add them to my generic SFS and then rename it to whatever the new pups name is. Then I rename the main puppy file to zdrv and I’m good to go.
Interesting... What if my zdrv has all the kernel modules (/lib/modules, missing from pup_420.sfs) and so on? Does it still work OK?
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]
Re: Empowering the Zdrv
Assuming the big dummy mode(very easy for me to do).....Running Slacko 5.3.3 on a bootable usb drive.jrb wrote:(Note: I’m keeping this brief so feel free to ask questions)
How do I create the zdrv sfs file, and add the favorite apps into that file?
Am I correct that this method gets around the number of sfs files limitation?
Thanks
Thom
It works fine but you have to either combine your apps with the /lib/modules etc. or combine the /lib/modules etc. with the main puppy files. I tried it the second way on spup51 and it worked no problem.sc0ttman wrote:Interesting... What if my zdrv has all the kernel modules (/lib/modules, missing from pup_420.sfs) and so on? Does it still work OK?
Nice, thanks.jrb wrote:It works fine but you have to either combine your apps with the /lib/modules etc. or combine the /lib/modules etc. with the main puppy files. I tried it the second way on spup51 and it worked no problem.sc0ttman wrote:Interesting... What if my zdrv has all the kernel modules (/lib/modules, missing from pup_420.sfs) and so on? Does it still work OK?
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]
Re: Empowering the Zdrv
The easiest way is to copy puppy_slacko_5.3.3.sfs to zdrv_slacko_5.3.3.sfs and then use Pizzagood’s Edit-SFS 2.1 (squash filesystem editor) to open up puppy_slacko_5.3.3.sfs, delete the contents and add in your own apps.tlchost wrote:Assuming the big dummy mode(very easy for me to do).....Running Slacko 5.3.3 on a bootable usb drive.jrb wrote:(Note: I’m keeping this brief so feel free to ask questions)
How do I create the zdrv sfs file, and add the favorite apps into that file?
Am I correct that this method gets around the number of sfs files limitation?
Thanks
Thom
This method does not affect the number of SFS files that can be loaded but all the apps that I know I will use regularly are in mine leaving me 6 other SFS's that I can load and unload as I choose.
jrb,
That's just a fantastic discovery.
I had fooled around with converting the save file to an sfs zdrv file a while back and ran into the priority problem.
Ironically, It occured to me to swap and rename the two sfs files, but then rejected that idea because it seemed that the initialization would fail - so I never tried it.
My solution was to compare the puppy sfs with the pup save zdr file and where they were equal, copy those from the pup save zdr to the main file system - not worth the game.
One way to create the zdr is to go to /initrd, open a terminal and "dir2sfs /initrd/pup_roX" where /intitrd/pup_roX is the pup save file. This will create an sfs file of your save file which you can rename and swap.
Again, a great find.
Regards,
s
That's just a fantastic discovery.
I had fooled around with converting the save file to an sfs zdrv file a while back and ran into the priority problem.
Ironically, It occured to me to swap and rename the two sfs files, but then rejected that idea because it seemed that the initialization would fail - so I never tried it.
My solution was to compare the puppy sfs with the pup save zdr file and where they were equal, copy those from the pup save zdr to the main file system - not worth the game.
One way to create the zdr is to go to /initrd, open a terminal and "dir2sfs /initrd/pup_roX" where /intitrd/pup_roX is the pup save file. This will create an sfs file of your save file which you can rename and swap.
Again, a great find.
Regards,
s
Nice one 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.seaside wrote:One way to create the zdr is to go to /initrd, open a terminal and "dir2sfs /initrd/pup_roX" where /intitrd/pup_roX is the pup save file. This will create an sfs file of your save file which you can rename and swap.
Hi Christian,musher0 wrote:Hello, jrb.
Aren't the drivers already in the zdrive crushed in the copying operation?
Best regards.
This is getting confusing. Which Zdrv and which copying operation?:lol:
If you mean copying /etc and /lib from a pup built with the kernel in the Zdrv into the Main Puppy files then no there are no duplications between the Zdrv files and the Main Puppy files.
If you mean copying your applications into the Zdrv then if there are any duplicates you want the ones that go with your apps to replace the current ones, although right off the top of my head I can't think of any apps that I've run into which replace kernel drivers.
IMHO having two versions of the same driver around is definitely not a good thing.
Cheers, J
Thanks for the reply, jrb.
I meant that some Puppies already have a zdrv_xxx.sfs sometimes, which contains hardware or other drivers.
I gather from your reply that merging the puppy_xxx.sfs into zdrv_xxx.sfs with the merging utility would not erase anything. Right?
Regards.
I meant that some Puppies already have a zdrv_xxx.sfs sometimes, which contains hardware or other drivers.
I gather from your reply that merging the puppy_xxx.sfs into zdrv_xxx.sfs with the merging utility would not erase anything. Right?
Regards.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
Right. I haven't seen any of the standard Puppies with Zdrv's that come with duplicate files.musher0 wrote:Thanks for the reply, jrb.
I meant that some Puppies already have a zdrv_xxx.sfs sometimes, which contains hardware or other drivers.
I gather from your reply that merging the puppy_xxx.sfs into zdrv_xxx.sfs with the merging utility would not erase anything. Right?
Regards.
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.
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.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
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.sfsHowever, 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.
Lazy Puppy can boot with every sfs file as "substitute"-zdrv.sfs i want to boot with.
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]
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.musher0 wrote: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.
Cheers, J
jrb, you wrote to seaside,
Wognath
If you have done this, could you please link it? No luck searching. Thanks.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.
Wognath
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
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
On the other hand
Code: Select all
mount -t aufs -o udba=reval,diropq=w,dirs=${UMNTMAIN}${ZLAYER}${UMNTRO} unionfs /pup_new
Main advantage would be to use the normal names so compatible with a remaster and perhaps other scripts.
mike