Hmmm I thought multisession was he only one that could still use extra sfs off the CD or has that changed too?
Well yes altering the initrd will solve the problem .... even just having ONE sfs above the main would do the trick. I mean the joy of sfs is that they DO NOT make permanant changes so easy to reverse should be the bonus bunny an easy way to customise without remastering..
You just need to alter how the option segment of the mount aufs command is built up. It works left to right...highest to the left...lowest on the right.
There was a huge thread a while ago because another user wanted to change a file using an sfs so you are not alone. I changed it for the same reason.
Option B would be to insert an sfs post initrd say early in rc.sysinit .... sfs loaded on the fly can be inserted above or below the main sfs easily with a couple of lines. Otherwise go with copying from an archive of some kind to the pup_rw early on.
mike
Multiple SFS support in initrd
I have found one way to make this work, following on from jrb's idea of renaming the main sfs and the zdrv. I don't rename them, but do change the initrd.gz as mentioned here
I'm keen to give some of those other ideas a go too.
I'm keen to give some of those other ideas a go too.
OK, thanks for this - finally I understand it. I was using slacko 5.6 and not seeing adrv or ydrv in the DISTRO_SPECS - and now I understand (thanks gyro) that they don't show in 5.7 either - although the ability to use them is at least already built into 5.7mavrothal wrote:The adrv and ydrv are already in woof-CE and slacko-5.7 initrd could use them if defined in DISTRO_SPECS. You could use those instead of a pdrv.
For a puppy that does not use a zrdv (most don't) you can just make your changes and save them as a zdrv.
And at least I now know that the zdrv is designed to sit underneath the puppy sfs.
Sorry to be so far behind the 8ball.
Do you think it would be possible to allow wildcard characters in the naming of one of the xdrvs?
If you were using a ydrv to trial a patch to the main puppy system it would be nice to have enough "variables" in the name to allow putting a date or other identifier in it.
eg, instead of slacko_ydrv_5.7.sfs it would be nice for the init to also tolerate a format like slacko_ydrv_XXXXXX_5.7.sfs so that variations like slacko_ydrv_140303_5.7.sfs, or slacko_ydrv_patch2_5.7.sfs could be accepted. (or maybe slacko_ydrv_5.7_xxxxxx.sfs would be better)
Init would not have to handle the prescence of multiple ydrvs - that would be up to the user to control and limit to one at a time.
This would enable a very quick method of completely changing the personality of a given puppy just by swapping ydrvs. If there were no wildcard characters this would be more difficult because every ydrv would be called by the same name.
If you were using a ydrv to trial a patch to the main puppy system it would be nice to have enough "variables" in the name to allow putting a date or other identifier in it.
eg, instead of slacko_ydrv_5.7.sfs it would be nice for the init to also tolerate a format like slacko_ydrv_XXXXXX_5.7.sfs so that variations like slacko_ydrv_140303_5.7.sfs, or slacko_ydrv_patch2_5.7.sfs could be accepted. (or maybe slacko_ydrv_5.7_xxxxxx.sfs would be better)
Init would not have to handle the prescence of multiple ydrvs - that would be up to the user to control and limit to one at a time.
This would enable a very quick method of completely changing the personality of a given puppy just by swapping ydrvs. If there were no wildcard characters this would be more difficult because every ydrv would be called by the same name.
I wasn't suggesting the wildcards would be a method of altering the layer position - just a means for the user to identify which one was latest, or had a specific feature.
As gyro was saying - the adrv and ydrv already have their positions in the layer predetermined as needed (I just didn't realise that this was new in slacko 5.7 and not fully visible yet)
As gyro was saying - the adrv and ydrv already have their positions in the layer predetermined as needed (I just didn't realise that this was new in slacko 5.7 and not fully visible yet)
Okies...well as mentioned the method of layer determining is by name ... 01-blah.sfs is below 02-blah.sfs which is below fred-blah.sfs .... read/write always on the top. So the user/builder can simply choose the order by convenient names.... only puppyism is to make pup_xxx.sfs the base layer regardless.
Mike
Mike
I know this is a long time ago.... but what is the answer? Is adrv (as defined in WOOF) sitting on top of the main sfs?R-S-H wrote:Oh, that's interesting!
To me it seems like the adrv is mounted on top of the main sfs file. There's a image for the fbpanel menu in main sfs. But the menu shows the image from LP2_WindowManagers.sfs!
This might make possible to boot using settings from sfs that would "overwrite" existing files from main sfs ? ! ? ! ? !
Or is it only because i did not change UMNTMAIN to UMNTRW
cheers
That application will probably work as sfs-addon (extra sfs). I load those sfs's I want to load automatically by placing a commandline in /etc/rc.d/rc.local, eg: sfs_load -c -q /mnt/sda1/LibreOffice.sfs
If you are using a savefile/folder you can add it by specifying it in the Boot Manager via the menu (no need for the commandline then).
If you are using a savefile/folder you can add it by specifying it in the Boot Manager via the menu (no need for the commandline then).