If the file you want to download has not been transfered, please report it in this topic http://www.murga-linux.com/puppy/viewtopic.php?t=115959.
In the next few weeks most URL's beginning with http://www.fishprogs.software/puppy/* will fail.
Edit:
The release of overlay_init-0.9.
This version contains a number of download variants, please see this post http://www.murga-linux.com/puppy/viewto ... 777#989777 for details.
The easiest way to use overlay_init, is to create an iso using a released delta.
Download one of those available from http://www.mediafire.com/folder/inbkdjmie89hm/overlay.
But for a Puppy that has no released overlay delta, you can use a "normal" Puppy with a working sfs_load to modify a frugal install:
1. Do a fresh frugal install of your target Puppy into a suitable writeable directory.
Make sure the "kernel" line for this install in your boot loader config contains
at least an appropriate "pupsfs=<partition>" parameter and a "psubdir=<sub-directory>" parameter if required.
Where "<partition>" is the LABEL or UUID of the target partition, and "<sub-directory>" is the path to the target directory.
2. Download an overlay_init .tar file from http://www.mediafire.com/folder/inbkdjmie89hm/overlay e.g. overlay_init-0.9b.tar to the new install directory.
Open a console window in the new install directory, and run command "tar xf overlay_init-0.9b.tar".
This should produce 2 files, "initrd.overlay.gz" and "overlay_mods.sfs".
3. Load "overlay_mods.sfs" using sfs_load.
This will make a number of utilities specific to this 'init', available to the running Puppy.
4. Run the command "overlay-setup-frugal <install-directory>", where "<install-directory>" is the full path to your install directory.
5. Unload "overlay_mods.sfs" using sfs_load.
6. Boot this modified installation.
Instead of loading "overlay_mods.sfs" with sfs_load, you could load "overlay_installers-0.10.sfs" from http://www.mediafire.com/folder/inbkdjmie89hm/overlay
See this post, http://www.murga-linux.com/puppy/viewto ... 083#988083, for more detail.
Edit:
---Old stuff, now obselete, the way it started---
Replacements for standard puppy files:
http://www.fishprogs.software/puppy/initrd/init
http://www.fishprogs.software/puppy/initrd/initrd.gz
http://www.fishprogs.software/puppy/ini ... verlay.sfs
Possibly usefuly utilities:
http://www.fishprogs.software/puppy/initrd/file2initrd
http://www.fishprogs.software/puppy/initrd/initrd2file
An example text file:
http://www.fishprogs.software/puppy/initrd/TIME_ZONE
To use:
In a clean frugal install:
1. Add a copy of DISTRO_SPECS to the frugal install directory.
2. Download the "initrd.gz" and "ydrv_overlay.sfs" into the frugal install directory.
3. Boot, with boot parameters similar to the following:
Code: Select all
pdrv=sdc2:/slacko/ ydrv=:ydrv_overlay.sfs
---Original message---
I'm not sure if this is a warning, a threat or a promise.
I'm working on another rewrite of the "init" script.
Amongst other things, I want to explore some different technologies, one of these is OverlayFs.
Some folk are saying that aufs is dead, that OverlayFs is the way of the future because it is included in the kernel.
This prediction may or may not happen, but I am interested in finding out what it would mean for puppy it we moved to OverlayFs as a replacement for aufs.
The results of my reading research are:
1) OverlayFs is much simpler that aufs, it seems to lack any ability to modify an existing stack.
If this proves to be true in practice, then the stack would have to be created once in "init", and then remain unchanged for the session.
"sfs_load" would be reduced to being an sfs manager whose results did not take effect until after a reboot.
Utilities that execute sfs files, by loading them into the aufs stack, executing the program inside and then unloading them would go.
There might also be some challanges with pupmode=13, since what happens when a directory that is part of an overlay is modified directly is undefined. So "snapmergepuppy" might have to go.
2) There are similarities, a number of directories are combined together to form a stack,
sfs files have to be mounted and their mountpoints used in forming the stack,
it uses whiteout files in the rw layer to hide files in the ro layers that have been "deleted".
3) But it can have read only overlays, and an overlay can consist of more than 1 directory, which could themselves be overlays.
So we could create a puppy-sfs overlay(ro) containing all the puppy system sfs's, and an extra-sfs overlay(ro) and a save-layer overlay(rw) and then mount all these as a puppy overlay.
Or we could build an sfs overlay(ro) that contains all the sfs's in the current session, and combine that with a save-layer directory to produce the puppy overlay. One of the advantages of this approach is that it would be easy to find if a file exists in any of the sfs's, by simply testing it's existence in the directory where the sfs overlay is mounted.
Or we could build an sfs overlay gradually by combining the previous sfs overlay with the directory for this sfs file to produce a new overlay, and so on. The challange with this approach is that each new overlay needs a new directory.
The next thing to do is to try using OverlayFs, so my questions are:
Has anyone tried to use OverlayFs?
Since it is a kernel facility, is it enabled in current Puppy kernels?
Or do I need do a kernel compile before I can try using it?
gyro