Puppy Linux Discussion Forum

Latest:
viewtopic.php?p=31076#p31076

----------original post------------
Yes, a "drv" can be any letter other than 'p', that's notionally the "puppy_...sfs" file.
An adrv, bdrv, mdrv, xdrv,.....

This 'init' takes a slightly different approach to handling the "?drv_...sfs" files.
It processes each file completely one at a time, from begining with just an identifying letter, to the ".sfs" files mount-point being in the stack.
So there is no prescribed set of "?drv_...sfs" files, just 2 lists of characters, the APPEND_DRVS list and the PREPEND_DRVS list.
To simulate the current 'init' would require APPEND_DRVS='f z' and PREPEND_DRVS='y a', which is the default.
Note that the PREPEND_DRVS list is in reverse order, because they each get inserted as branch 1, thus "pushing down" any inserted before this one.

But there is more:
To make it easy for folk to manipulate which "?drv_...sfs" files are processed by 'init', and their order,
the APPEND_DRVS and PREPEND_DRVS can be defined in a 'BOOT_SPECS' file in the installation directory,
which gets read after the "puppy_...sfs" file has been processed, and thus established the location of the install directory.

Don't worry, this is not a complete re-write of 'init', the bulk of the current code is still used, it just has a new way of starting.

I have uploaded 'drvs+tmp.tar.gz' to https://www.mediafire.com/folder/hkwe9y ... /init-wait.
Download and extract the tar file to produce 'BOOT_SPECS', 'initrd.gz', and 'ydrv_upuphh+d_21.04.sfs'.

'BOOT_SPECS':
An example text file that can be edited, and placed in the installation directory.

'initrd.gz':
Replaces the current 'initrd.gz' file in the installation directory.
A "UPupHH+D" 'initrd.gz' file, containing the patched 'init' script.
(It might work in other recently "woofed" Puppies if the '/DISTRO_SPECS' file is replace with the one for the target Puppy.)
Or the 'init' script in another Puppies 'initrd.gz' could be replaced by the 'init' script in this one.

'ydrv_upuphh+d_21.04.sfs':
Contains only scripts so it should work in other Puppies by simply renaming it, and placing it in the installation directory.

It contains a patched 'sfs_load' that can recognise what is a ".sfs" file loaded by 'init' and so to be ignored, in the new environment.
And 'lsaufs', a utility for listing the contents of the stack in order.

It also contains a patched 'rc.sysinit',
because the 'init' script also contains a patch to mount a tmpfs directly as '/tmp', instead of creating a symbolic link to '/initrd/mnt/tmpfs/tmp'.
This 'rc.sysinit' recognises this, and adjusts the size of the '/tmp' tmpfs, rather than '/initrd/mnt/tmpfs/tmp' that contains the ".sfs" files.
With this change it would be Ok for ".pet" files to contain files in '/tmp'.
Besides, it makes the path of a ".AppImage" file to it's temporary mount-point, significantly shorter.

Do you know what the maximum amount of additional drives are that can be accommodated? I've done this along time ago and changed the initrd accordingly (the additional drives are available but I don't use it), mine is also the rest of the alphabet letters but I have also created additional ones beyond that named like bbdrv, ccdrv, etc. which also worked. We may as well find out the maximium additional drives possible and make provision for that. With your method it seems this can be done easily (maybe) without much effort.

@amethyst,
There is no theoretical limit, the lists are ' ' delimited lists, so 'a b' could also be 'aa ab ba bb' etc..
Each item in the list is prepended to "drv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION.sfs" for the filename.
You could probably even use APPEND_DRVS='firmware modules' and PREPEND_DRVS='light fixit'.
The code is just a loop for each entry in each list.
Since there are 2 lists, the "item" value doesn't make any difference to the disposition within the stack. You just need to make sure that no item appears in both lists.
With easy access to the lists, the sky is the limit.
Well actually the machine is the limit, of course in reality some resource will run out.
There could be a problem with simply the number of loaded sfs files.

WELL NO, I just realised, that 'sfs_load' looks for "^.drv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION.sfs" to determine if this could be a system ".sfs" and so should be ignored, the "." in this case represents any single character. So could have more by using '+'etc... ???, or try replacing the "." with "*". But really, what's the point. Surely 25 is more than enough.

I just don't see any value in exploring it.

@gyrog

Well I thought this could be achieved with one list (say a pre-set lettering of say 50 additional drives)?

amethyst wrote: ↑Sat Jul 03, 2021 3:05 pm

Well I thought this could be achieved with one list (say a pre-set lettering of say 50 additional drives)?

Nope, no "pre-set lettering" in this project, it's all in the hands of the user.

And 'sfs_load' could be fixed.
And there would be a place in the 'init' code where it would probably be prettier to ensure there was no trailing '_' or '-'.

Sorry, but I still don't get any need for even that. Even 10 above and 10 below is surely more than enough.

gyrog wrote: ↑Sat Jul 03, 2021 3:40 pm

amethyst wrote: ↑Sat Jul 03, 2021 3:05 pm

Well I thought this could be achieved with one list (say a pre-set lettering of say 50 additional drives)?

Nope, no "pre-set lettering" in this project, it's all in the hands of the user.

And 'sfs_load' could be fixed.
And there would be a place in the 'init' code where it would probably be prettier to ensure there was no trailing '_' or '-'.

Sorry, but I still don't get any need for even that. Even 10 above and 10 below is surely more than enough.

What may be enough for you may not be enough for others. Anyways, I'm not really a horse in this race, I have all these additional drives already available for use but I don't use it.

Interesting!

That's pretty similar to what I did with my ArtStudio64 (and with the ArtStudios 64/32 I published).

I have uploaded 'drvs+tmp2.tar.gz' to https://www.mediafire.com/folder/hkwe9y ... /init-wait.
Download and extract the tar file to produce 'BOOT_SPECS', 'initrd.gz', and 'ydrv_upuphh+d_21.04.sfs'.

The only change is that the included 'sfs_load' is now agnostic to the length of the "drv" prefix.
The 'init' code already is.

I must admit that it had not occured to me to allow for more than a single charcter, because I can only think of using maybe 1 or 2, at least a very small number.
It's just I keep seeing references in the forum of folk that have added a "bdrv", "cdrv", etc..., there is always someone who wants just 1 more.
So I wondered, what if Puppy had "no" limit to the "drv" files?
And here it is.

If anyone would like to test on some other Puppy, and would like an appropriate 'initrd.gz',
please ask for one for that Puppy, I will try to oblige.

As a matter of interest - It's not necessary to give the additional drive the name of the specific distribution, one can actually give it any name you like, for instance: bdrv_VLC.sfs (if I remember correctly last time I experimented with it). I changed the name in DISTRO_SPECS, I think.

amethyst wrote: ↑Sun Jul 04, 2021 7:21 am

As a matter of interest - It's not necessary to give the additional drive the name of the specific distribution, one can actually give it any name you like, for instance: bdrv_VLC.sfs (if I remember correctly last time I experimented with it). I changed the name in DISTRO_SPECS, I think.

Not with this patch, you can't.
If you want to use a different name and you are on a Linux file system, you can simply use a symbolic link from the different name to the "standad" name.

gyrog wrote: ↑Sun Jul 04, 2021 7:57 am

amethyst wrote: ↑Sun Jul 04, 2021 7:21 am

As a matter of interest - It's not necessary to give the additional drive the name of the specific distribution, one can actually give it any name you like, for instance: bdrv_VLC.sfs (if I remember correctly last time I experimented with it). I changed the name in DISTRO_SPECS, I think.

Not with this patch, you can't.
If you want to use a different name and you are on a Linux file system, you can simply use a symbolic link from the different name to the "standad" name.

It's useful when loaded with the different name (eg: the name of the software) especially when you have a lot of additional drives. So you have bdrv_VLC, cdrv_Seamonkey, etc. and you can decide which to boot and when loaded you can see which applications are loaded.

For what's it's worth, the code is now in the 'init-experiment' branch of woof-ce.

I have uploaded 'drvs+tmp5.tar.gz' to https://www.mediafire.com/folder/hkwe9y ... /init-wait.
Download and extract the tar file to produce 'BOOT_SPECS', 'initrd.gz', and 'ydrv_upuphh+d_21.04.sfs'.

It now uses the the "drv_...sfs" definitions in DISTRO_SPECS as the first try for the default filename.
If there is no definition for the "drv" in DISTRO_SPECS then "<identifier>drv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs" is used,
where <identifier> is the string that "names the "drv", e.g. 'y' for the "ydrv_...sfs" file.

I have uploaded 'local-initrd.gz' to https://www.mediafire.com/folder/hkwe9y ... /init-wait.

This is an easier way to try the experimental 'init'.
It uses the grub2 facility to load multiple "initrd" files.
This extra "initrd" file contains the new 'init' script and other files needed to support it, but no DISTRO_SPECS file,
so it will work with many Puppies without change.
It worked for me with "Xenialpup", released in Nov 2017.

To use:
Download 'local-initrd.gz' into a recent, working Puppy frugal install, preferably not a "production" install.
Edit the grub2 'grub.cfg' for this install, change the "initrd" line from:

  initrd /puppy/xenial/initrd.gz

to

  initrd /puppy/xenial/initrd.gz /puppy/xenial/local-initrd.gz

It's impoprtant that 'local-initrd.gz' is second in the list.

Re-boot into this install.
If the re-boot is successful, you might make use of the 'ydrv_...sfs' and 'BOOT_SPECS' from 'drvs+tmp5.tar.gz' to make full use of the update.

Here is a grub2 entry for xenialpup that can cope with 2 extra "initrd" files that may or may not exist, i.e. 'ucode.cpio' and 'local-initrd.gz':

menuentry "Puppy xenialpup 7.5" {
  insmod ext2
  search --no-floppy --fs-uuid --set=root 0db94719-cdf1-44b7-9766-23db62fb85a5
  echo "Loading vmlinuz"
  linux /puppy/xenial/vmlinuz acpi_osi=Linux libata.noacpi=1 intel_pstate=disable pmedia=atahd pdrv=Work psubdir=/puppy/xenial pfix=fsck,fsckp TZ=AEST-10
  if [ -e /puppy/xenial/local-initrd.gz ]; then
    set local_rd=/puppy/xenial/local-initrd.gz
  else
    set local_rd=
  fi
  if [ -e /puppy/xenial/ucode.cpio ]; then
    echo "Loading ucode.cpio and initrd.gz"
    initrd /puppy/xenial/ucode.cpio /puppy/xenial/initrd.gz $local_rd
  else
    echo "Loading initrd.gz"
    initrd /puppy/xenial/initrd.gz $local_rd
  fi
}

A new version of 'local-initrd.gz' has been uploaded to https://www.mediafire.com/folder/hkwe9y ... /init-wait.
The 'init' script has been further patched to fix a bug with "humongous-initrd" support.