When should I load xdrv?

[nic007]

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.

[ozsouth]

Found other files inside initrd.gz needing editing - sbin/init-bootmenu and README.txt

[mikeslr]

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.

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

[nic007]

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.

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. ... 14#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?

[mikeslr]

Hi nick,

Thanks for reminding me about the Edit-initrdgz.pet. Is that the one from here? http://murga-linux.com/puppy/viewtopic. ... 145#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.

[ozsouth]

@mikeslr - my method is that any reference to ydrv needs xdrv (and/or others) added after it (similar with y_bp refs). After editing init & DISTRO_SPECS (including OFINSIS' edit) I scoured the remaining files & found sbin/init-bootmenu & README.txt contained ydrv refs.
As I don't use sfs_load, I've taken it out of the main menu (using NoDisplay=true in its .desktop file). That program itself is still needed to open an .sfs in ROXFiler. I don't use remasterpup2 any more - I just create a save file, mount that & extract needed file changes then repack as another .sfs

[nic007]

Hi nick,

Thanks for reminding me about the Edit-initrdgz.pet. Is that the one from here? http://murga-linux.com/puppy/viewtopic. ... 145#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.

Hi, Mike. Yes I think that is the edit script. Attached an experimental remaster script dealing with additional drives and extra sfs's. You can choose which to include or not and the sfs's do not have to be unmounted for exclusion. I didn't do much testing myself. The selection dialog may not work correctly with old Puppys which have old versions of gtkdialog installed. It works for me with Precise and newer.

[ozsouth]

initrd.gz-wx2001, allowing wdrv & xdrv for ScPup64-20.01, is here: http://s000.tinyupload.com/?file_id=082 ... 1480281330
Rename it to initrd.gz