When should I load xdrv?

[O.F.I.N.S.I.S.]

In addition to my previous post:

6. edit puppy ... .sfs

Nope.

You don't need to do that!

Near the bottom end of the init script there's this section:

Code: Select all

cp -af /DISTRO_SPECS /pup_new/initrd/
cp /init* /pup_new/initrd/
chmod -x /pup_new/initrd/init
dmesg > /tmp/dmesg.txt

Just add

Code: Select all

cp -af /DISTRO_SPECS /pup_new/etc/

on top of this section.

No need to edit the base .sfs!

Btw.: this works also that way if one wants to rename the base .sfs to a new name. Just change the related entries in initrd's DISTRO_SPECS and you're done!

[Smithy]

Tried it and got B,C,D.E and G. No problems or lags or anything as far as I could tell..Difficulty level=7, if you get one letter wrong..Like a crossword, had to use good old rsh editinit, 'cos rox lies, wouldn't sqoosh it back up.
Good job! Things like Wine and java and office stuff.

[ozsouth]

@Smithy - excellent!
@O.F.I.N.S.I.S. - After thinking this over, Slacko pups should have no problem simply copying the init DISTRO_SPECS to /etc, but Ubuntu based ones apparently need the 2 multiarch entry lines at the end of the puppy... .sfs version of DISTRO_SPECS.
sfs_load is indeed an issue - could edit /usr/sbin/sfs_load, I suppose, but it looks complicated.
As I don't use it, deleting /usr/sbin/sfs_load & /usr/share/applications/SFS_Load.desktop then running fixmenus will solve issue for me. If I make B, C, D & E drives, won't need sfs_load. Alternatively, I could just use sfs_load, as was suggested earlier.

[O.F.I.N.S.I.S.]

@O.F.I.N.S.I.S. - After thinking this over, Slacko pups should have no problem simply copying the init DISTRO_SPECS to /etc, but Ubuntu based ones apparently need the 2 multiarch entry lines at the end of the puppy... .sfs version of DISTRO_SPECS.

I'm doing this in Ubuntu based Puppy.
So, you might think editing the base .sfs is the better way than to just to copy those two lines from .sfs DISTRO_SPECS to the initrd DISTRO_SPECS - of course only if they are not already inside the initrd DISTRO_SPECS. Which should be the case, if the developer knows his job well enough.

There are many ways are leading to Rome...

[Smithy]

Hi ozsouth, O.F.I.N.S.I.S. I managed to do two initrd.gz files, one was artful and one bionic 1903 32 bits.
In both final cases I didn't touch the etc distrospecs in either the main puppy sfs or the initrd.gz
Just mentioning because these are ubuntu based? Unless there may be problems down the line.
I'll post these sort of templates in case anyone wants to experiment without having to go through the typing!

Code: Select all

#OZSOUTH TEMPLATE
#MAKE SOME EMPTY FOLDERS INSIDE THE EXPANDED INTIRD.GZ LIKE pup_b pup_c pup_d etc. 
#These will become the drvs.

[color=red]#ROUND ABOUT LINE 78[/color]

#precaution - if DISTRO_SPECS was not processed by 3builddistro...
[ ! "$DISTRO_ZDRVSFS" ] && DISTRO_ZDRVSFS="zdrv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs"
[ ! "$DISTRO_FDRVSFS" ] && DISTRO_FDRVSFS="fdrv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs"
[ ! "$DISTRO_ADRVSFS" ] && DISTRO_ADRVSFS="adrv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs"
[ ! "$DISTRO_YDRVSFS" ] && DISTRO_YDRVSFS="ydrv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs"
[ ! "$DISTRO_XDRVSFS" ] && DISTRO_XDRVSFS="xdrv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs"
[ ! "$DISTRO_BDRVSFS" ] && DISTRO_BDRVSFS="bdrv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs"
[ ! "$DISTRO_CDRVSFS" ] && DISTRO_CDRVSFS="cdrv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs"
[ ! "$DISTRO_DDRVSFS" ] && DISTRO_DDRVSFS="ddrv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs"
[ ! "$DISTRO_EDRVSFS" ] && DISTRO_EDRVSFS="edrv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs"
[ ! "$DISTRO_GDRVSFS" ] && DISTRO_GDRVSFS="gdrv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs"
[ ! "$DISTRO_PUPPYSFS" ] && DISTRO_PUPPYSFS="puppy_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs"

[color=red]#ROUND ABOUT LINE 85[/color]

# filenames specified in DISTRO_SPECS: DISTRO_ZDRVSFS, DISTRO_PUPPYSFS...
Z_DEF_FN="$DISTRO_ZDRVSFS"
F_DEF_FN="$DISTRO_FDRVSFS"
A_DEF_FN="$DISTRO_ADRVSFS"
Y_DEF_FN="$DISTRO_YDRVSFS"
X_DEF_FN="$DISTRO_XDRVSFS"
B_DEF_FN="$DISTRO_BDRVSFS"
C_DEF_FN="$DISTRO_CDRVSFS"
D_DEF_FN="$DISTRO_DDRVSFS"
E_DEF_FN="$DISTRO_EDRVSFS"
G_DEF_FN="$DISTRO_GDRVSFS"
P_DEF_FN="$DISTRO_PUPPYSFS"

[color=red]#ROUND ABOUT LINE 1038[/color]

#have basic system, now try to add optional stuff
find_onepupdrv "$F_PART" "$F_BP_FN" "$F_DEF_FN" "f"
[ "$ONE_FN" ] && FDRV="$ONE_PART,$ONE_FS,$ONE_FN"
[ "$FDRV" ] && { LOADMSG="fdrv"; setup_onepupdrv "$FDRV" "f"; }

find_onepupdrv "$Z_PART" "$Z_BP_FN" "$Z_DEF_FN" "z"
[ "$ONE_FN" ] && ZDRV="$ONE_PART,$ONE_FS,$ONE_FN"
[ "$ZDRV" ] && { LOADMSG="zdrv"; setup_onepupdrv "$ZDRV" "z"; }

find_onepupdrv "$Y_PART" "$Y_BP_FN" "$Y_DEF_FN" "y"
[ "$ONE_FN" ] && YDRV="$ONE_PART,$ONE_FS,$ONE_FN"
[ "$YDRV" ] && { LOADMSG="ydrv"; setup_onepupdrv "$YDRV" "y" "p"; }

find_onepupdrv "$A_PART" "$A_BP_FN" "$A_DEF_FN" "a"
[ "$ONE_FN" ] && ADRV="$ONE_PART,$ONE_FS,$ONE_FN"
[ "$ADRV" ] && { LOADMSG="adrv"; setup_onepupdrv "$ADRV" "a" "p"; }

find_onepupdrv "$B_PART" "$B_BP_FN" "$B_DEF_FN" "b"
[ "$ONE_FN" ] && BDRV="$ONE_PART,$ONE_FS,$ONE_FN"
[ "$BDRV" ] && { LOADMSG="bdrv"; setup_onepupdrv "$BDRV" "b" "p"; }

find_onepupdrv "$C_PART" "$C_BP_FN" "$C_DEF_FN" "c"
[ "$ONE_FN" ] && CDRV="$ONE_PART,$ONE_FS,$ONE_FN"
[ "$CDRV" ] && { LOADMSG="cdrv"; setup_onepupdrv "$CDRV" "c" "p"; }

find_onepupdrv "$D_PART" "$D_BP_FN" "$D_DEF_FN" "d"
[ "$ONE_FN" ] && DDRV="$ONE_PART,$ONE_FS,$ONE_FN"
[ "$DDRV" ] && { LOADMSG="ddrv"; setup_onepupdrv "$DDRV" "d" "p"; }

find_onepupdrv "$E_PART" "$E_BP_FN" "$E_DEF_FN" "e"
[ "$ONE_FN" ] && EDRV="$ONE_PART,$ONE_FS,$ONE_FN"
[ "$EDRV" ] && { LOADMSG="edrv"; setup_onepupdrv "$EDRV" "e" "p"; }

find_onepupdrv "$G_PART" "$G_BP_FN" "$G_DEF_FN" "g"
[ "$ONE_FN" ] && GDRV="$ONE_PART,$ONE_FS,$ONE_FN"
[ "$GDRV" ] && { LOADMSG="gdrv"; setup_onepupdrv "$GDRV" "g" "p"; }



[color=red]# TOWARDS THE END OF SCRIPT ROUND ABOUT LINE 1405 ADD O.F.I.N.S.I.S.  cp -af /DISTRO_SPECS /pup_new/etc/
[/color]
fi
cp -af /DISTRO_SPECS /pup_new/etc/
cp -a /DISTRO_SPECS /pup_new/initrd/
cp /init* /pup_new/initrd/
chmod -x /pup_new/initrd/init
dmesg > /tmp/dmesg.txt


###FINISHED EDITING###

[O.F.I.N.S.I.S.]

@Smithy
Yes, this works also if defined only inside of the init script.

BUT: other programs depending on that data (not exclusively the sfs_load) don't include the init script. They simply do:

Code: Select all

. /etc/DISTRO_SPECS

Keep this in mind!

And: since you put it into the init script, why not to put it into the DISTRO_SPECS instead?

It's more save in general to prevent problems that way and it should be exactly the same amount of work.

However, many ways leading to Rome...

[Smithy]

Thanks O.F.I.N.S.I.S.
I will do that. I had a bit of a disaster making a quite complicated jack/qjackctl *.drv
Maybe that had something to do with it. A P.Widgets *.drv was not a problem. I've shoved jack/qjackctl now in the main puppy sfs,
but will give a wine *drv a go at some point, see if that works ok.
I hope that (appian) ways to Rome will be a happy and healthier one towards late Summer.

[nic007]

Thanks for the template Smithy. I got this to work for the first time without any issues it seems. Is the order of layer preference (higher in preference level): adrv, xdrv, ydrv, bdrv, cdrv, ddrv, edrv, gdrv, base sfs, zdrv, fdrv?

[nic007]

In any case, a-f-y-z-drv code aside, we need to remember that we can load ANY sfs
by scripting sfs_load, which makes the number of sfs's a Puppy can load near infinite
-- if we need to.

It's good to have both options

It's useful having these extra drives sfs's load on top of the base sfs in order of preference which is not the case when loading extra sfs's on the fly.

[Smithy]

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.

[nic007]

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.

[Smithy]

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]

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).
PS: The folders are created automatically in /initrd.

[Smithy]

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

[nic007]

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.

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

[s243a]

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.

[O.F.I.N.S.I.S.]

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!

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

[Smithy]

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

[nic007]

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

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