(OLD) (ARCHIVED) Puppy Linux Discussion Forum Forum Index (OLD) (ARCHIVED) Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info

This forum can also be accessed as http://oldforum.puppylinux.com
It is now read-only and serves only as archives.

Please register over the NEW forum
https://forum.puppylinux.com
and continue your work there. Thank you.

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups    
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 04 Dec 2020, 01:12
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
When should I load xdrv?
Moderators: Flash, Ian, JohnMurga
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
Page 3 of 4 [48 Posts]   Goto page: Previous 1, 2, 3, 4 Next
Author Message
nic007


Joined: 13 Nov 2011
Posts: 3444
Location: Cradle of Humankind

PostPosted: Thu 19 Mar 2020, 21:08    Post subject:  

Smithy wrote:
Hi nic, according to ozsouth, the section around 1046:
#have basic system, now try to add optional stuff
The drvs will load up in ascending order.
Maybe a test run of a small text file made into a bunch of *.drvs will show that this works.

I ended up editing the init distrospecs file AS WELL and putting:
#for the partition, path and actual files loaded, see PUPSFS and ZDRV in /etc/rc.d/PUPSTATE
DISTRO_PUPPYSFS='puppy_upupbb_19.03.sfs'
DISTRO_ZDRVSFS='zdrv_upupbb_19.03.sfs'
DISTRO_FDRVSFS='fdrv_upupbb_19.03.sfs'
DISTRO_ADRVSFS='adrv_upupbb_19.03.sfs'
DISTRO_YDRVSFS='ydrv_upupbb_19.03.sfs'
DISTRO_BDRVSFS='bdrv_upupbb_19.03.sfs'
DISTRO_CDRVSFS='cdrv_upupbb_19.03.sfs'
DISTRO_DDRVSFS='ddrv_upupbb_19.03.sfs'
DISTRO_EDRVSFS='edrv_upupbb_19.03.sfs'
DISTRO_GDRVSFS='gdrv_upupbb_19.03.sfs'
DISTRO_XDRVSFS='xdrv_upupbb_19.03.sfs'

I THINK that was what O.F.I.N.S.I.S. meant in his caution?
That could do with clarification, so there's no trouble down the line.

I was also wondering what type of programmes might be calling for distrospecs.

Okay, as long as they load on top (in preference to) the base sfs, zdrv and fdrv it can be useful. The adrv is at top of the order as far as sfs's are concerned, I'm sure. Yes, I did add them to DISTRO_SPECS.
DISTRO_SPECS is actually used in quite a few applications to identify specific Puppy files/versions. The remaster script for instance will check DISTRO_SPECS to be able to generate the name of the new base sfs automatically.

_________________
nicOS-Utility-Suite
Back to top
View user's profile Send private message 
Smithy


Joined: 12 Dec 2011
Posts: 1157

PostPosted: Sat 21 Mar 2020, 05:02    Post subject:  

Here’s some *.drvs each containing a small abiword text file that should end up in root/Downloads if anyone wants to do some testing.
Add .sfs to the end and whatever distro name you are using to the prefix.

1. Clicking on initrd DOES work to expand and recompress that file. I didn’t read it properly.

2. From tests it doesn’t seem necessary to make empty folders in the init named pup_b, pup_c etc?
gdrv_upupbb_19.03.gz
Description 
gz

 Download 
Filename  gdrv_upupbb_19.03.gz 
Filesize  4 KB 
Downloaded  167 Time(s) 
edrv_upupbb_19.03.gz
Description 
gz

 Download 
Filename  edrv_upupbb_19.03.gz 
Filesize  4 KB 
Downloaded  165 Time(s) 
ddrv_upupbb_19.03.gz
Description 
gz

 Download 
Filename  ddrv_upupbb_19.03.gz 
Filesize  4 KB 
Downloaded  168 Time(s) 
cdrv_upupbb_19.03.gz
Description 
gz

 Download 
Filename  cdrv_upupbb_19.03.gz 
Filesize  4 KB 
Downloaded  172 Time(s) 
bdrv_upupbb_19.03.gz
Description 
gz

 Download 
Filename  bdrv_upupbb_19.03.gz 
Filesize  4 KB 
Downloaded  165 Time(s) 
Back to top
View user's profile Send private message 
nic007


Joined: 13 Nov 2011
Posts: 3444
Location: Cradle of Humankind

PostPosted: Sat 21 Mar 2020, 06:14    Post subject:  

As a test I took existing extra sfs files and renamed a few to bdrv, etc. They all seem to load correctly and were operational. I also did not find any conflicts with the sfs_load script (and I did not edit the sfs_load script). Smile
PS: The folders are created automatically in /initrd.

_________________
nicOS-Utility-Suite
Back to top
View user's profile Send private message 
Smithy


Joined: 12 Dec 2011
Posts: 1157

PostPosted: Sat 21 Mar 2020, 06:48    Post subject:  

Great, I think we've got it covered if we run out of drvs, which was ozsouth's (and mine) niggle!
Back to top
View user's profile Send private message 
nic007


Joined: 13 Nov 2011
Posts: 3444
Location: Cradle of Humankind

PostPosted: Sat 21 Mar 2020, 07:00    Post subject:  

I'm using the init script with extended functionality with my customised versions of Racy and Precise (which are using Tahr's kernel). Just changed DISTRO_SPECS for the different Puppys. Who would have thought one could supe up an old puppy like Racy this way. Smile
_________________
nicOS-Utility-Suite
Back to top
View user's profile Send private message 
nic007


Joined: 13 Nov 2011
Posts: 3444
Location: Cradle of Humankind

PostPosted: Sat 21 Mar 2020, 07:14    Post subject:  

I think there is a possibility to rename the extra drv's as a measure to identify what it contains. Needs some investigating. For now I suppose one can just list the contents in a text file eg. bdrv_racy_5.5.1.sfs = VLC2.0 and so on.
_________________
nicOS-Utility-Suite

Last edited by nic007 on Tue 07 Apr 2020, 06:48; edited 3 times in total
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2626

PostPosted: Sat 21 Mar 2020, 10:39    Post subject:  

nic007 wrote:
I think there is a possibility to rename the extra drv's as a measure to identify what it contains. Needs some investigating. For now I suppose one can just list the contents in a text file eg. bdrv_racy_5.5.1.sfs = VLC2.0 and so on.


I would suggest if one does this to have an external file to define the layers and the init script would just get the layer order from the external file.

_________________
Find me on minds and on pearltrees.
Back to top
View user's profile Send private message Visit poster's website 
O.F.I.N.S.I.S.

Joined: 01 Mar 2020
Posts: 162

PostPosted: Sat 21 Mar 2020, 18:21    Post subject:  

Smithy wrote:
Great, I think we've got it covered if we run out of drvs, which was ozsouth's (and mine) niggle!

You should consider to add an additional boot option to the init script.

E.g.: if doing a remaster with any of the *drv loaded its contents is going to be included into the base .sfs when using the puppy remaster script or any of its many available derived or cut-down versions. Otherwise one needs to move these *drv out of the way before (re-)booting and doing a remaster.

From this point of view the concept of the *drv is not thought out to the end very well! Wink

Using an additional boot parameter (like I do) will let you boot without any of the *drv loaded.

Just to mention...

...however, many ways are leading to Rome...

_________________
Our Future Is Not Set In Stone
https://www.youtube.com/channel/UCyfyaxCNMduwyXlQFRQKhhQ
https://soundcloud.com/user-633698367
My own build of Bionic64
Back to top
View user's profile Send private message 
Smithy


Joined: 12 Dec 2011
Posts: 1157

PostPosted: Mon 23 Mar 2020, 05:44    Post subject:  

Well remastering (and save files/ folders) is not something that comes into the scope of the original intention of this thread I would have thought. (Unless it becomes a woofce proposal.)

But if a puppy user did for some reason want to do a remaster, they could just remove an s off the end of the unwanted *.sfses (rename), reboot and do a remaster.

If one wanted to incorporate the contents of *drives into the remaster, the step would be to delete the *drvs after completing that process.

if you are building *drvs, then I would think remastering is not high on the list. Optimising init and barebones main sfs might be more relevant...

I suggest your code might be better placed in the remastering dialogue section rather than in the boot cfg? Many ways to skin a cat Wink
Back to top
View user's profile Send private message 
nic007


Joined: 13 Nov 2011
Posts: 3444
Location: Cradle of Humankind

PostPosted: Mon 23 Mar 2020, 06:55    Post subject:  

Smithy wrote:
Well remastering (and save files/ folders) is not something that comes into the scope of the original intention of this thread I would have thought. (Unless it becomes a woofce proposal.)

But if a puppy user did for some reason want to do a remaster, they could just remove an s off the end of the unwanted *.sfses (rename), reboot and do a remaster.

If one wanted to incorporate the contents of *drives into the remaster, the step would be to delete the *drvs after completing that process.

if you are building *drvs, then I would think remastering is not high on the list. Optimising init and barebones main sfs might be more relevant...

I suggest your code might be better placed in the remastering dialogue section rather than in the boot cfg? Many ways to skin a cat Wink

The standard builtin remaster script will include the contents of all loaded sfs files (except the zdrv if you choose so). You need to unload them or not boot them if you don't want them included. I would only use the additional drv's if the specific sfs needs to be loaded in preference to the base sfs. This is usually on rare occasions only. Mostly addiditional sfs's will be loaded as extra sfs's with the sfs_load script. The latter can easily be installed and uninstalled during a session. But to have the option of using the additional drives expands the functionality of Puppy, so all good...

_________________
nicOS-Utility-Suite
Back to top
View user's profile Send private message 
nic007


Joined: 13 Nov 2011
Posts: 3444
Location: Cradle of Humankind

PostPosted: Tue 07 Apr 2020, 06:46    Post subject:  

nic007 wrote:
I think there is a possibility to rename the extra drv's as a measure to identify what it contains. Needs some investigating. For now I suppose one can just list the contents in a text file eg. bdrv_racy_5.5.1.sfs = VLC2.0 and so on.


Actually, I found this to be quite simple. One method - You can just change the names by editing DISTRO_SPECS in the initrd (edit initrd.gz). Say for instance you want to load an sfs file containing VLC as the bdrv: change the name of the bdrv to something like bdrv_VLC.sfs in initrd (edit DISTRO_SPECS only), rename the actual sfs file to bdrv_VLC.sfs and place it in the location of the other Puppy files.

_________________
nicOS-Utility-Suite
Back to top
View user's profile Send private message 
ozsouth

Joined: 01 Jan 2010
Posts: 862
Location: S.E Australia

PostPosted: Fri 17 Apr 2020, 23:31    Post subject:  

Found other files inside initrd.gz needing editing - sbin/init-bootmenu and README.txt
Back to top
View user's profile Send private message 
mikeslr


Joined: 16 Jun 2008
Posts: 3913
Location: 500 seconds from Sol

PostPosted: Fri 24 Apr 2020, 08:54    Post subject: Frankly, this area of inquiry suggest the future of Puppy  

Frankly, making greater use of READ-ONLY Applications may suggest the future of Puppy as it evolves to function in a virus plagued internet.

nic007, "Actually, I found this to be quite simple. One method - You can just change the names by editing DISTRO_SPECS in the initrd (edit initrd.gz)." Unless the functionality of this technique is to be limited to experts, an application with a GUI should be developed.

nic007, "The standard builtin remaster script will include the contents of all loaded sfs files (except the zdrv if you choose so)." -- This suggests the need that your remaster scripts be revised so that the user can choose what is, and isn't, included without first having to physically remove SFSes.

ozsouth wrote:
Found other files inside initrd.gz needing editing - sbin/init-bootmenu and README.txt
.
Details would be appreciated.

Kind of 'off topic': But on the subject of reducing exposure of one's system note fredx181's technique to create and the two methods to use AppImages, http://murga-linux.com/puppy/viewtopic.php?p=1011814#1011814. I think 'PortableAppsLinux Mode' mounts at /tmp as do 'alien' AppImages. [Can anyone confirm?]. I've yet to get my head around the entire concept of Chroot.
Back to top
View user's profile Send private message 
nic007


Joined: 13 Nov 2011
Posts: 3444
Location: Cradle of Humankind

PostPosted: Fri 24 Apr 2020, 12:19    Post subject: Re: Frankly, this area of inquiry suggest the future of Puppy  

mikeslr wrote:
Frankly, making greater use of READ-ONLY Applications may suggest the future of Puppy as it evolves to function in a virus plagued internet.

nic007, "Actually, I found this to be quite simple. One method - You can just change the names by editing DISTRO_SPECS in the initrd (edit initrd.gz)." Unless the functionality of this technique is to be limited to experts, an application with a GUI should be developed.

nic007, "The standard builtin remaster script will include the contents of all loaded sfs files (except the zdrv if you choose so)." -- This suggests the need that your remaster scripts be revised so that the user can choose what is, and isn't, included without first having to physically remove SFSes.

ozsouth wrote:
Found other files inside initrd.gz needing editing - sbin/init-bootmenu and README.txt
.
Details would be appreciated.

Kind of 'off topic': But on the subject of reducing exposure of one's system note fredx181's technique to create and the two methods to use AppImages, http://murga-linux.com/puppy/viewtopic.php?p=1011814#1011814. I think 'PortableAppsLinux Mode' mounts at /tmp as do 'alien' AppImages. [Can anyone confirm?]. I've yet to get my head around the entire concept of Chroot.


There are initrd.gz GUI edit scripts available, I installed the Edit-initrdgz.pet. Very easy to use but the process will still require manual input. Once initrd.gz is opened however, all you need to do is to change the names of the appropriate sfs's at the bottom of the DISTRO_SPECS file, save the changes, let the script rebuild initrd.gz and replace your old initrd.gz with the new one. Not difficult.

The conventional remasterscript copies files directly from /. Extra sfs files loaded during a session can easily be unloaded but sfs drives mounted by the bootmanager can't (well, the experts will say it can but it involves messing with the top AUFS layers which could make the system unstable and screw up the attempted remaster). BTW - My remaster script also excludes the fdrv like the zdrv. HOWEVER - Following an alternative way of "remastering" akin to my savefile/folder to sfs method may well be a viable option. Would you be interested to be a guinea pig for testing?

_________________
nicOS-Utility-Suite
Back to top
View user's profile Send private message 
mikeslr


Joined: 16 Jun 2008
Posts: 3913
Location: 500 seconds from Sol

PostPosted: Fri 24 Apr 2020, 16:04    Post subject:  

Hi nick,

Thanks for reminding me about the Edit-initrdgz.pet. Is that the one from here? http://murga-linux.com/puppy/viewtopic.php?p=821145#821145

"...Would you be interested to be a guinea pig for testing?" Maybe. But I've got a couple of other, sort-of-related, projects. I recently downloaded ff-74.0-qAlight.sfs which I thought was published by rufwoof with a link on the Quirky-light thread. But I can't find the link again. At any rate, it runs firefox-74 [I think fredx181's portable] in a firejail. I have it running under bionicpup64. Mounting the SFS reveals what appears to be almost another operating system.

The regular-portable version of firefox I have when run-as-spot honors spot's permission limitations. So I don't think a firejail adds much to it. But it got me thinking. Wine is particularly problematic for several reasons. The first is that WineHq indicates that protection against malware is a problem left to various Distros. Puppy, running as Root, ignores that. The second is that most of the useful Windows programs anyone would want are 32-bit while current Linux operating systems are, increasingly, only 64-bit. So, although, there are 64-bit version of Wine, to be useful one needs Multi-arch capabilities which Puppies --fatdog, I think, being the exception-- don't have. The Puppy work-around is to sfs-load 32-bit libraries, configure your system to use them (ldconfig) then install 32-bit Wine. As far as I can see, that's the only reason to load 32-bit libraries. "Rub Goldberg Machine" comes to mind. And, of course, this has to be done for each 64-bit version of Puppy by every user.

Wine running in a firejail --or configured to install into one-- suggests itself as an alternative. But figuring out all the details is probably above my pay-grade. I tried creating a wine "adrive" from a functioning system with a SaveFile using your tool. Something --beyond my knowledge-- went wrong. So I shelved that project and, hence, my pessimism regarding my ability to place wine in firejail.

But email me exactly what you have in mind --remember I have the technical knowledge of a kid playing with blocks-- and I'll let you know.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 3 of 4 [48 Posts]   Goto page: Previous 1, 2, 3, 4 Next
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
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.8768s ][ Queries: 12 (0.7550s) ][ GZIP on ]