Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Mon 28 Jul 2014, 00:27
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects » Next Puppy Development
Multiple SFS support in initrd
Post new topic   Reply to topic View previous topic :: View next topic
Page 6 of 6 [88 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6
Author Message
mavrothal


Joined: 24 Aug 2009
Posts: 1568

PostPosted: Thu 29 May 2014, 15:39    Post subject:  

greengeek wrote:

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?

_________________
Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too Very Happy
Back to top
View user's profile Send private message 
greengeek

Joined: 20 Jul 2010
Posts: 2407
Location: New Zealand

PostPosted: Thu 29 May 2014, 18:59    Post subject:  

Quote:
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.
Back to top
View user's profile Send private message 
greengeek

Joined: 20 Jul 2010
Posts: 2407
Location: New Zealand

PostPosted: Sat 31 May 2014, 15:06    Post subject:  

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.

Last edited by greengeek on Sun 01 Jun 2014, 04:39; edited 1 time in total
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 8032

PostPosted: Sat 31 May 2014, 17:42    Post subject:  

Quote:
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 Very Happy

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 Sad but you seem to be finding the same old brick wall.

Mike
Back to top
View user's profile Send private message 
greengeek

Joined: 20 Jul 2010
Posts: 2407
Location: New Zealand

PostPosted: Sat 31 May 2014, 19:20    Post subject:  

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.
.
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 8032

PostPosted: Sun 01 Jun 2014, 03:16    Post subject:  

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
Back to top
View user's profile Send private message 
greengeek

Joined: 20 Jul 2010
Posts: 2407
Location: New Zealand

PostPosted: Sun 01 Jun 2014, 03:23    Post subject:  

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.
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 8032

PostPosted: Sun 01 Jun 2014, 13:29    Post subject:  

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
Back to top
View user's profile Send private message 
greengeek

Joined: 20 Jul 2010
Posts: 2407
Location: New Zealand

PostPosted: Tue 03 Jun 2014, 14:37    Post subject:  

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

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. Rolling Eyes
Back to top
View user's profile Send private message 
greengeek

Joined: 20 Jul 2010
Posts: 2407
Location: New Zealand

PostPosted: Wed 04 Jun 2014, 03:24    Post subject:  

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.
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 8032

PostPosted: Wed 04 Jun 2014, 05:05    Post subject:  

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

mike
Back to top
View user's profile Send private message 
greengeek

Joined: 20 Jul 2010
Posts: 2407
Location: New Zealand

PostPosted: Wed 04 Jun 2014, 13:21    Post subject:  

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)
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 8032

PostPosted: Wed 04 Jun 2014, 13:35    Post subject:  

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
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 6 of 6 [88 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects » Next Puppy Development
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0854s ][ Queries: 13 (0.0067s) ][ GZIP on ]