When should I load xdrv?

[ozsouth]

Is there a technical reason that I shouldn't load an xdrv at boot, (between ydrv & adrv)?
I use ydrv for office packages, adrv for browsers, fdrv for firmware, zdrv for kernel. Hence if I make customisations & want to load those every boot, I'm out of drvs. By editing DISTRO_SPECS in etc as well as it & init in initrd.gz, it boots with no obvious issues. In example, I made browser xdrv & late settings adrv - to load last.

[s243a]

It should work fine as far as I'm concerned provided you make the above edits that you mentioned.

[nic007]

No problem. I guess the main thing would be to decide in which order to have them boot (and perhaps which of them shoud be copied to RAM or not). Post a copy of your initrd.gz as an example how you have managed it. Thanks.

[ozsouth]

With initrd.gz expanded (click on it in ROX-Filer), DISTRO_SPECS is edited as in original post, folder pup_x is added, & init is edited as per attached (remove .fake.gz). Then re-saved (click on it again in ROX-Filer). /etc/DISTRO_SPECS also needs editing to be as in original post. My load order is f z y x a (using x for browsers & a for late settings). Lines 1047-1065 in init seem to set this order. Not sure I got lines 82-83 right. End of original line 82 referred to adrv ilo ydrv which looked wrong to me.

[musher0]

Hi ozsouth.

Sorry to rain on the party, but I tried something similar a while back, and it didn't work
because editing the "index card" is not enough.

The number of "drvs" ( a f y z ) one can load in Puppy is hard-coded in the general init
script, IIRC. You'd have to edit that too. ( I got lost because BK uses a lot of vars and
internal functions in that script.)

IHTH.

[ozsouth]

@musher - it actually loaded & ran - I edited init in initrd.gz too, but reading 3builddistro on github, as you say f z y a are setup by that build script, so you'd think it may work in certain circumstances. That's what I was hoping devs would clarify.

[musher0]

Ah. Ok. Sorry.

[nic007]

A while back I tried to add a bdrv, cdrv, etc. editing the initrd.gz, DISTRO_SPECS as well as the sfs_load script. The additional drv's were created (the folders) correctly but I couldn't get the actual files (contents) of the additional drives to load.

[s243a]

@musher - it actually loaded & ran - I edited init in initrd.gz too, but reading 3builddistro on github, as you say f z y a are setup by that build script, so you'd think it may work in certain circumstances. That's what I was hoping devs would clarify.

I'm pretty sure you said it worked, so why the self doubt?

[ozsouth]

@s243a - I'm worried about hidden 'gotyas'. The reference to 3builddistro which specifies f z y a drvs only & with adrv appearing twice in original init lines below, I'm concerned about unforseen consequences. The init I attached higher up doesn't follow the pattern of the original code below. In refs to YDRVSFS (& then XDRVSFS), I didn't refer to adrv. I'm hoping the devs will explain why the original is necessary. Both ways seem to work.

Original code:

#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="adrv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs"


Part of my change attached to my post above (without multiple adrv refs):

#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"

[musher0]

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.

[ozsouth]

yes, musher - is interesting experiment, but I think you're right.

[s243a]

@s243a - I'm worried about hidden 'gotyas'. The reference to 3builddistro which specifies f z y a drvs only & with adrv appearing twice in original init lines below, I'm concerned about unforseen consequences.

You can verify the aufs layers once it boots up. The layers are in:

/sys/fs/aufs/$AUFS_ROOT_ID/

I think that br0 is the top layer. If there are are unforeseen consequences than either your blocking/replacing something important or the puppy code needs to be modified to make it more generic/universal. If you find such an unforeseen consequence please report it as a bug. I'll at least take it seriously regardless of whether or not the puppy dev team will.

The init I attached higher up doesn't follow the pattern of the original code below. In refs to YDRVSFS (& then XDRVSFS), I didn't refer to adrv. I'm hoping the devs will explain why the original is necessary. Both ways seem to work.

Original code:

#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="adrv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs"


Part of my change attached to my post above (without multiple adrv refs):

#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_YDRVSFS="xdrv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs"

You should be able to assume with reasonable confidence that this is a bug that needs to be fixed. Either report the bug on github or do a merge/pull request.

P.S. it still looks like there is a bug in your code. Notice in the last line your are assigning the xdrv to the ydrv. I think you want:

Code: Select all

[ ! "$DISTRO_XDRVSFS" ] && DISTRO_XDRVSFS="xdrv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs"

[s243a]

yes, musher - is interesting experiment, but I think you're right.

I like the option of being able to have extra *DRVSFS type files. However, a more generic approach then adding a new letter might be to use numbered suffixes. Then for each of these *DRVSFS we have an inner loop that adds a layer for each numbed suffix.

Anyway, your xdrv is a quick fix for what you want and if someone decides to implement the numbered suffixes later, your xdrv can be one of the parameters in the outer loop.

[s243a]

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

[ozsouth]

@s243a - thanks for your support & for answering my original query. The typo I made is only my later post entry (I shouldn't rush) - the init.fake.gz I posted up top is correct (so I edited my later mistake).

[ozsouth]

Ok, this is how enabling xdrv worked for me (try at own risk!):
1. expand initrd.gz (click on it in ROX-Filer) & in /root/initrd-expanded:
2. add folder pup_x
3. edit DISTRO_SPECS (add XDRV line near end)
4. edit init - first line with YDRVSFS should have ydrv ilo adrv. With every reference to a ydrv or Y_BP, add xdrv or X_BP line.
Then:
5. recompress initrd.gz (click on it again in ROX-Filer).
6. edit puppy ... .sfs - add XDRV line near end of /etc/DISTRO_SPECS via updatesfs tool:
http://murga-linux.com/puppy/viewtopic. ... 87#1028687
7. replace old initrd.gz & old puppy ... .sfs & reboot.

[musher0]

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

Indeed!

Actually, I should qualify that. It's not "near infinite".

It came back to me that former French forum member ASRI_Education did test
manually how many sfs's a Puppy could load, and that number is 123. Although ASRI
was ( still is! ) extremely bright, I thought he had mildly lost it for this experiment, since
he spent days creating over 120 sfs's from scratch for his test. But now we know.

In any case, it makes sense: 128 bits ( through aufs or similar on a 32-bit PC ) minus
5 for the essential sfs's: the puppy_"schmurf"_version-number, the devx, the zdrv and
the pupsave, plus room for one other, maybe Libre|Open|Office = 123.

Puppy could not accommodate the a-f-y drv's at the time.

Since we now have 64-bit Pups, would it be safe to say that aufs or similar would be
able to accommodate a maximum of 251 sfs's in a Pup? ( 256 minus 5 )
I'm afraid I'm not technical enough to come up with the answer, so I'm asking.
TIA for any insight.

A secondary question comes to my mind: could ozsouth generalize his script to all
letters of the alphabet? It would be a done deal, wouldn't it!

BFN.

[s243a]

A secondary question comes to my mind: could ozsouth generalize his script to all
letters of the alphabet? It would be a done deal, wouldn't it!

BFN.

One could do that by using the ASCII tables. However, are the puppy layers stacked alphabetically? If not then we would have to perhaps apply a permutation, or an easier way to do it would be to hard code it in the loop:

Code: Select all

for Letter in A B C D E F G ...

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

You need to modify shinobar's sfs_load as well for the XDRV or you may get into trouble when loading .sfs files at run time.

I'm running GDRV, MDRV, NDRV and VDRV.