Multiple SFS support in initrd

[mavrothal]

1) My question is really directed at the idea of HOW such a drv.sfs is used when the initrd grabs it and uses it.

As I said adding the a,y,zdev name in initrd DISTRO_SPECS will make it mountable when present.
But why do you think that building an cdrv.sfs with ones personal setting will be easier than just a good old puppy remaster?

[greengeek]

But why do you think that building an cdrv.sfs with ones personal setting will be easier than just a good old puppy remaster?

Firstly because it is much easier to add a xdrv into an iso by using isomaster than it is to remaster a puppy, and secondly I was hoping someone would say 'yes, we can force the initrd to load a textfile from the cd' which would be a very simple way of grabbing a users setup parameters. Simpler even than making an xdrv. One simple text file containing basic desktop setup defaults in a standard format - for puppy init scripts to refer to during boot.

[greengeek]

Now that I have spent a couple of days tinkering with the zdrv.sfs in slacko 5.6 I understand a bit more about the relative priorities in how the initrd treats the main puppy.sfs versus other .sfs files that are available to it.

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.

If that file already exists within the main puppy.sfs then the 'new' version available within the zdrv.sfs is ignored. This compromises the effect of the zdrv.

My question is - are there any types of .sfs files that ARE able to overwrite the main.sfs? Is there any version of puppy that has an initrd which contains the ability to accept an "xdrv.sfs" that can be used to 'override' or 'overwrite' a file within the main puppy.sfs?

If this does not exist then I think it should be a priority for future puppies. Obviously there are good reasons why the use of such a file could be dangerous - but just as many reasons why it could be an advantage. For instance - I want a user to be easily able to change the default timezone that is used by puppy during the boot process. (rather than waiting for a chance to run quicksetup after boot). I could achieve this if the zdrv (or similar) had the ability to let me overwrite a single file within the puppy sfs.

[mikeb]

My question is - are there any types of .sfs files that ARE able to overwrite the main.sfs? Is there any version of puppy that has an initrd which contains the ability to accept an "xdrv.sfs" that can be used to 'override' or 'overwrite' a file within the main puppy.sfs?

It appears I am the only one. If it were dangerous then pets are even more so

Its not the squashfs/aufs system...its how its used you are observing...Slax and porteus are 2 examples of layering on top....actually in their cases the layering order is determined by the alphabetical naming of the squash files...01-blah is under 02-blah

I was hoping there might have been at least one of these wonder sfs that would have been suitable for your purposes but you seem to be finding the same old brick wall.

Mike

[greengeek]

I guess it doesn't cause problems for most people - in general people are happy that their savefile can take the higher ground, and over-ride the files in the main puppy.sfs.

If you boot from an HDD or a usb stick they are R/W media and you can easily change the files the way you want.

However, this is not true when trying to load from a CD. You can load the main puppy.sfs, but the initrd has no way to force the boot process to also grab (and overlay) a set of personal files that are 'contained' within an sfs. Multisession allows you to grab a save FOLDER / DIRECTORY, but for some reason restricts this behaviour in such a way that an sfs cannot achieve the same thing. (And also multisession keeps wanting to save further updates to those personal files, which is something I would like to be able to avoid...)

I don't know if this was done deliberately to make it easy to start in a pristine mode (pfix=ram from cd) but if it could be changed it would allow someone to easily make a CD that had the main puppy.sfs that they wanted, and simply graft personal files (like wifi SSID etc) over the top - WITHOUT ANY FURTHER ATTEMPT BEING MADE TO CHANGE OR RE-SAVE THE PERSONAL SETTINGS.

I would like the initrd to recognise the puppy.sfs as an unchangeable 'kernel', then allow the addition of a personal sfs to over-ride that kernel, and to respect the option of not making any savefile that could cloud the integrity of what had been set up by the puppy.sfs and personal.sfs

This is the kind of ability needed to make a fully read-only, yet perfectly configured puppy that does exactly what you want. Pristine files at every boot.

EDIT : I probably need to look at how multisession mounts the savedirectory from cd (it MUST be mounted with higher priority than the main puppy.sfs) and see if that code could be modified to do the same with an sfs rather than a directory structure.

EDIT 2 : Maybe what I really need is a way to make the initrd capable of pulling a .2fs or.3fs etc file off the CD - instead of only looking through the HDDs and USB sticks.
.

[mikeb]

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

[greengeek]

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.

[mikeb]

Okay dokay.... it WOULD make life a whole lot simpler if the main sfs was at the bottom of the stack generally.... perhaps one day . After all its a more of a legacy hangover than a design decision.

mike

[greengeek]

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.

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

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.

[greengeek]

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.

[mikeb]

If you are going to alter the initrd why not just change the sfs loading order... might be simpler in the long run

mike

[greengeek]

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)

[mikeb]

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

[greengeek]

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

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?
cheers

[mikeb]

I belive that is the idea ... a token gesture to sanity.

If in doubt do a quick test with a dummy sfs ... after all you cannot read the init script or see the aufs layering while running nowadays...that would be too convenient ...

mike

[linux28]

I want to automatically mount LibreOffice.sfs when I boot up. How can I modify the initrd to add it?

[ozsouth]

If you don't have a ydrv, can rename libreoffice.sfs to ydrv_(your pup detail).sfs & place in with other os .sfs.
If you've no spare drvs, I'm experimenting with an xdrv (see cutting edge section).

[nic007]

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

[linux28]

If you don't have a ydrv, can rename libreoffice.sfs to ydrv_(your pup detail).sfs & place in with other os .sfs.
If you've no spare drvs, I'm experimenting with an xdrv (see cutting edge section).

Okay, thank you very much! Thank you!