(OLD) (ARCHIVED) Puppy Linux Discussion Forum

Smithy · Joined: 12 Dec 2011 Posts: 1157

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?

nic007 · Posted: 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.

Smithy · Joined: 12 Dec 2011 Posts: 1157

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

nic007 · Posted: 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

nic007 · Posted: 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.

s243a · Joined: 02 Sep 2014 Posts: 2626

O.F.I.N.S.I.S. · Joined: 01 Mar 2020 Posts: 162

Smithy · Joined: 12 Dec 2011 Posts: 1157

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

nic007 · Posted: Mon 23 Mar 2020, 06:55 Post subject:

nic007 · Posted: Tue 07 Apr 2020, 06:46 Post subject:

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

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.

nic007

mikeslr · Posted: 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.