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 Fri 19 Dec 2014, 13:41
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 1 of 6 [88 Posts]   Goto page: 1, 2, 3, 4, 5, 6 Next
Author Message
mavrothal


Joined: 24 Aug 2009
Posts: 1894

PostPosted: Fri 11 Jan 2013, 17:09    Post subject:  Multiple SFS support in initrd  

Jemimah introduced in Saluki the ADRV sfs. An SFS that will mount in the union with the main puppy sfs which was used to hold applications. The idea being that could be easily replaced without affecting the core functions.
Her work was never made it into woof, so when Archpup wanted to go that way I adapted jemimah' s code for the more recent initrd that Archpup uses.
Then I took it one step further adding a YDRV, since Archpup people wanted a separate sfs for the Desktop/Window managers.

So here are a couple of patches for Woof2 ver:8fa56fa1c1d5fb12 (today's).
Ones adds the adrv and the other both adrv and ydrv.
Please also notice the additional mount-point folders that should be added in the initrd tree as indicated, as well as the required changes in DISTRO_SPECS.

Obviously the code could be expand to encompass the entire alphabet Razz but without the woof changes to build the separate SFSs is not of much use Rolling Eyes .
Still I put it here since a modular puppy may not be such a bad idea. Could facilitate building the different versions of a puppy that become all the more often like "retro", "fat", "XFCE" etc, without the need to replace/rebuild the entire ISO.
Woof_initrd-tree0_patches.tar.gz
Description  Initrd support for multiple SFS
gz

 Download 
Filename  Woof_initrd-tree0_patches.tar.gz 
Filesize  3.64 KB 
Downloaded  514 Time(s) 

_________________
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 
scsijon

Joined: 23 May 2007
Posts: 1052
Location: the australian mallee

PostPosted: Mon 04 Feb 2013, 18:06    Post subject: D Drive  

@mavrothal

I had also looked at Jemimas's way of doing it as I wanted similar with my Development Puppy qtpy, I have added further a d-drive for the Development tools \ apps SFS to mount into as they are quite a size (naturally) and do get regularly updated.

However, I was wondering how \ if we could force some of the apps to be added to the new SFS's instead of the savefile with a 'marker tickbox' in PPM, since there are a few decent sfs packaging apps out there now.

I was \ am also considering how to split the existing puppy system up so that /root lives on it's own partition \ savefile with the intention of having a common /root available across a number of puppy versions. The problem as far as I can see is how to deal with the 'differances' between the /root settings files. But I wonder how different it is nowadays other than the 'set' and 'menu' items.
Back to top
View user's profile Send private message Visit poster's website 
mavrothal


Joined: 24 Aug 2009
Posts: 1894

PostPosted: Tue 05 Feb 2013, 08:35    Post subject: Re: D Drive  

scsijon wrote:
However, I was wondering how \ if we could force some of the apps to be added to the new SFS's instead of the savefile with a 'marker tickbox' in PPM, since there are a few decent sfs packaging apps out there now.

The SFS is read only and you can not add things to it after is made.
However, you can define [a,d,y]drv is DISTRO_SPECS as, say Apps_mypuppy_123.sfs and then let the user or developer make the Apps_mypuppy_123.sfs with apps of their liking. That's what Archpup_13.2 is doing currently.
A down side is that these SFSs will load in RAM (if available) so you may need 1GB+ to take full advantage of this system.

scsijon wrote:
I was \ am also considering how to split the existing puppy system up so that /root lives on it's own partition \ savefile with the intention of having a common /root available across a number of puppy versions. The problem as far as I can see is how to deal with the 'differances' between the /root settings files. But I wonder how different it is nowadays other than the 'set' and 'menu' items.

I _think_ that the init script and snapmerge could be modified to use an additional "root_savefile" but I'm not sure if it worths the effort and the potential problems. Also I doubt about the benefits since unless you use very similar pupplets can be a source of problems.
If you have some settings you want to carry from pupplet to pupplet you can make an SFS to "load_on_the_fly" or just a tarball.

_________________
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 
Q5sys


Joined: 11 Dec 2008
Posts: 1074

PostPosted: Sat 16 Feb 2013, 14:20    Post subject: Re: D Drive  

mavrothal wrote:
scsijon wrote:
However, I was wondering how \ if we could force some of the apps to be added to the new SFS's instead of the savefile with a 'marker tickbox' in PPM, since there are a few decent sfs packaging apps out there now.

The SFS is read only and you can not add things to it after is made.
However, you can define [a,d,y]drv is DISTRO_SPECS as, say Apps_mypuppy_123.sfs and then let the user or developer make the Apps_mypuppy_123.sfs with apps of their liking. That's what Archpup_13.2 is doing currently.
A down side is that these SFSs will load in RAM (if available) so you may need 1GB+ to take full advantage of this system.


I'm sure someone could hack the PPM to utilize the Edit-SFS package and give you that functionality... but honestly I'd think its a bad thing. One of the benefits of using a layered file system that we do, is if something causes a problem... its easy to reverse. Example, install a PET that uses a newer version of some core lib. If its a pet you can simply uninstall the pet, because the original lib is still in the base SFS package. If you edit the SFS by adding programs through the PPM, if you overwrite a important lib... you've just completely nuked your system.

If there are specific programs you use and know will work, you can always use the Edit-SFS package yourself to change the base SFS. But I think making this an option in the PPM is only going to cause more problems than it'd solve.

mavrothal, do you agree with that assement or do you have another opinion on it?

_________________



Back to top
View user's profile Send private message Visit poster's website 
mavrothal


Joined: 24 Aug 2009
Posts: 1894

PostPosted: Sat 16 Feb 2013, 16:47    Post subject: Re: D Drive  

Q5sys wrote:
mavrothal wrote:
scsijon wrote:
However, I was wondering how \ if we could force some of the apps to be added to the new SFS's instead of the savefile with a 'marker tickbox' in PPM, since there are a few decent sfs packaging apps out there now.

The SFS is read only and you can not add things to it after is made.
However, you can define [a,d,y]drv is DISTRO_SPECS as, say Apps_mypuppy_123.sfs and then let the user or developer make the Apps_mypuppy_123.sfs with apps of their liking. That's what Archpup_13.2 is doing currently.
A down side is that these SFSs will load in RAM (if available) so you may need 1GB+ to take full advantage of this system.


I'm sure someone could hack the PPM to utilize the Edit-SFS package and give you that functionality... but honestly I'd think its a bad thing. One of the benefits of using a layered file system that we do, is if something causes a problem... its easy to reverse. Example, install a PET that uses a newer version of some core lib. If its a pet you can simply uninstall the pet, because the original lib is still in the base SFS package. If you edit the SFS by adding programs through the PPM, if you overwrite a important lib... you've just completely nuked your system.

If there are specific programs you use and know will work, you can always use the Edit-SFS package yourself to change the base SFS. But I think making this an option in the PPM is only going to cause more problems than it'd solve.

mavrothal, do you agree with that assement or do you have another opinion on it?


Given the current pet QA I do agree that is not a good idea to mess up the pristine state of the original SFSs.
An option could be to install new pets directly in an "additional_apps.sfs". If anything goes wrong you can always drop it and go to pristine state.
Theoretically after a new pet download/installation your "additional_apps.sfs" expands the new pet is/are added the original sfs gets backed-up and umounted and the new one squashed and mounted (so you have the previous version if something goes wrong)
I still find it unpractical though and I can hardly see the advantages over installing in the savefile.
If you eventually have a set of additional apps that you feel happy with you just 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 
R-S-H

Joined: 18 Feb 2013
Posts: 490

PostPosted: Sat 02 Mar 2013, 06:42    Post subject: SFS? Yes, yes, yes!
Subject description: Personal Data SFS
 

Hi.

First I have to say: I really like the idea of using SFS files instead of installing applications.

So, I run my LazY Puppy (by now Version 3.0.0, not published yet) from USB flash (and USB hdd) totally in RAM, no save file is used and all programs are coming as SFS file. There are SFS files in sizes of several 100 MB and also some of sizes in less KB - by now there are 334 SFS files in the LazY Puppy boot directory.

All these SFS files are loaded automatically by a RunScript, which can be created with right-click action on SFS files. The RunScripts are executed by a menu entry - just like as the program would have been installed (downloading the SFS directly to the boot directory from server smokey01.com is included).

LazY Puppy can load every SFS file directly at boot up (mounted like the zdrv SFS) just by giving the name of the SFS or by predefined boot menu entries in menu.lst, using predefined constants for the SFS Suites.

There is just one single PET to install for me - if I want to go online with my USB GPRS Modem!

BUT: I have to make sure all Data is saved outside LazY Puppy before shutting down the computer - each and every day.

That's why I have invented the Personal Data SFS in LazY Puppy 3.0.0. This can be loaded automatically at boot up (by boot option in menu.lst) and can also be saved automatically before shutting down the computer - selectable option in the shutdown-gui of LazY Puppy. If I'm saving the Personal Data SFS at shut down, an existing Personal Data SFS is renamed (date is added to the file name) before that!

Just by a right-click I can set files and directories to be added to the Personal Data SFS or to be removed from the Personal Data SFS.

Everything is temporary until I save the Personal Data SFS manually or at shut down.

This is my vision of Puppy and SFS!

And it's become REAL!

RSH
Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 1894

PostPosted: Sat 02 Mar 2013, 07:08    Post subject: Re: SFS? Yes, yes, yes!
Subject description: Personal Data SFS
 

R-S-H wrote:

This is my vision of Puppy and SFS!
And it's become REAL!


How is that different/better from tinycore linux?

The idea of puppies with 2-3 distinct SFSs instead of the usual monolithic one, has to do only with the ease of development/customization of a complete system/ISO.
Not with the philosophy of the puppy setup.

As mentioned, there are other distros to do that.

(sorry for the "loud" mark up. Just try to be clear)

_________________
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 
R-S-H

Joined: 18 Feb 2013
Posts: 490

PostPosted: Sat 02 Mar 2013, 07:41    Post subject:  

Quote:
How is that different/better from tinycore linux?

I do not know Tiny Core Linux and I did never ever see one running or read any specific information about Tiny Core.

What I've found now by your presented links is totally new to me - however: I don't believe, that Tiny Core uses RunScripts to be able to do the following:

Clicking a GIMP Image (Gimp is not installed and there is no SFS file at local computer available), automatically downloading the SFS into the boot directory, automatically loading the SFS after download, automatically starting GIMP application and automatically loading the GIMP Image into GIMP - ready to edit by just a single click on a menu entry.

Tiny Core surely can NOT do this.

Sorry, but that's all and that's much more as I've ever seen in any Linux (there are not much, but some)

Quote:
As mentioned, there are other distros to do that.

No!

They might do something similar, but not exactly the same!
Back to top
View user's profile Send private message 
R-S-H

Joined: 18 Feb 2013
Posts: 490

PostPosted: Sat 02 Mar 2013, 08:52    Post subject:  

Thanks to this thread I've discovered and examined the adrv option of Saluki. Found it very useful and surely will try to add such feature to LazY Puppy. I've had a quick look at the init script in Saluki's initrd.gz - seems not to be too much code. Smile
_________________
LazY Puppy Home
The new LazY Puppy Information Centre

Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 1894

PostPosted: Sat 02 Mar 2013, 14:09    Post subject:  

R-S-H wrote:

Clicking a GIMP Image (Gimp is not installed and there is no SFS file at local computer available), automatically downloading the SFS into the boot directory, automatically loading the SFS after download, automatically starting GIMP application and automatically loading the GIMP Image into GIMP - ready to edit by just a single click on a menu entry.

This can be handy at times.
The reason that distros do not do that (ie download an SFS or package) for a missing MIME type/file extension, is that usually more than 1 app can handle a file.
Some distros (not tinycore) do provide a list of suggestions if a file can not be handle by the installed applications

_________________
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 
R-S-H

Joined: 18 Feb 2013
Posts: 490

PostPosted: Mon 04 Mar 2013, 06:02    Post subject:  

Quote:
Some distros (not tinycore) do provide a list of suggestions if a file can not be handle by the installed applications

Yes, this might be also a nice feature in LazY Puppy. Smile

However...

I've tried to put in the "adrv"-option into LazY Puppy using the code taken from the Saluki initrd.gz. I did get the adrv sfs mounted in pup_a. All files where in the directory and I was able to open f.e. scripts in geany.

BUT, the sfs seems not to be mounted like to have the menu entries and to be able to execute the applications. Crying or Very sad

To me it seems like it is mounted to be able to grab some files off it, but not mounted to the "layered filesystem".

What am I doing wrong?

I did try this also using the exactly code for the zdrv modified to adrv - didn't work also.

Is there anything else I would have to do to get the adrv mounted like the main sfs is mounted (to be able to execute its applications from menu)?

Thanks

P.S.

No, "fixmenus" did not "the job" Laughing

_________________
LazY Puppy Home
The new LazY Puppy Information Centre

Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 1894

PostPosted: Mon 04 Mar 2013, 10:48    Post subject:  

R-S-H wrote:

I've tried to put in the "adrv"-option into LazY Puppy using the code taken from the Saluki initrd.gz. I did get the adrv sfs mounted in pup_a. All files where in the directory and I was able to open f.e. scripts in geany.

BUT, the sfs seems not to be mounted like to have the menu entries and to be able to execute the applications. Crying or Very sad

To me it seems like it is mounted to be able to grab some files off it, but not mounted to the "layered filesystem".

What am I doing wrong?

I did try this also using the exactly code for the zdrv modified to adrv - didn't work also.

Is there anything else I would have to do to get the adrv mounted like the main sfs is mounted (to be able to execute its applications from menu)?

Besides the changes in initrd/init you also need to have the mount points (folders) in initrd. Did you?
Did you also added the adrv to DISTRO_SPECS
If you want post or PM all the changes you have made in initrd, to take a look, (or compare with the patches above. There is both the adrv only and the adrv+ydrv patches. Did you look at them?...)

_________________
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 
R-S-H

Joined: 18 Feb 2013
Posts: 490

PostPosted: Mon 04 Mar 2013, 14:10    Post subject:  

Yes, I did everything. pup_a is in initrd.gz.

The 'adrv' directory is created by init script - like the zdrv is.

I did not add the adrv as DISTRO_ADRVSFS to DISTRO_SPECS - I do submit this from the grub bootmenu. The file is then in pup_a, I can see the files and I can open scripts in geany, so it is successfully submitted, but the .desktop files do not appear in the menu and none of the program runs.

No, I did not have a look into the above attached patches, because I'm not in woof. I just do remaster.

Should I?
image-2.jpg
 Description   Content of initrd.gz
 Filesize   101.1 KB
 Viewed   1612 Time(s)

image-2.jpg


_________________
LazY Puppy Home
The new LazY Puppy Information Centre


Last edited by R-S-H on Thu 07 Mar 2013, 21:00; edited 1 time in total
Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 1894

PostPosted: Mon 04 Mar 2013, 14:58    Post subject:  

R-S-H wrote:
Yes, I did everything. pup_a is in initrd.gz.

The 'adrv' directory is created by init script - like the zdrv is

I did not add the DISTRO_ZDRVSFS to DISTRO_SPECS - I do submit this from the grub bootmenu. The file is then in pup_a, I can see the files and I can open scripts in geany, so it is successfully submitted, but the .desktop files do not appear in the menu and none of the program runs.

I'm afraid descriptions are not gong to do it.
You may want to post your init and the contents of your /initrd/tmp folder to see what are you doing exactly, during boot.
Also /tmp/xerrs.log can be informative (or maybe just run pdiag)

_________________
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 
R-S-H

Joined: 18 Feb 2013
Posts: 490

PostPosted: Wed 06 Mar 2013, 18:23    Post subject:  

Here is the init script from my LazY Puppy 3. Saluki code included - commented out, because it failed and I did try it with an code-copy of the zdrv code. I have made a lot of modifications also, so it's a bit more than a usual init script.

Script removed!

_________________
LazY Puppy Home
The new LazY Puppy Information Centre


Last edited by R-S-H on Sun 10 Mar 2013, 16:38; edited 1 time in total
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 6 [88 Posts]   Goto page: 1, 2, 3, 4, 5, 6 Next
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.1190s ][ Queries: 13 (0.0073s) ][ GZIP on ]