Puppy Linux Discussion Forum

[gyro]

[Rangan Masti]

Hi, thank you for the reponse. Do not give up!!. Try further. Wish you a good success!!

Rangan

[gyro]

I've uploaded new versions to http://www.fishprogs.software/puppy/initrd/initrd.gz and http://www.fishprogs.software/puppy/initrd/ydrv_overlay.sfs.
Both need to be downloaded, since the "ydrv_overlay.sfs" now contains a new utility "extra_sfs", and the command line utilities "file2initrd" and "initrd2file".

The significant change in this 18 July version is, extra sfs support.

The "extra_sfs" utility is a replacement for "sfs_load", in the sense that it masks "sfs_load" and takes its place in the menu.
But it does not load or unload any sfs files.
It simply maintains a list of extra sfs files that are loaded by "init" into the "pup_sfss" overlay, before the main overlay is created.

If "init" fails to load any extra sfs file, an appropriate message is written to "/initrd/tmp/bootinit.log", but the file remains in the list.
You can then either use "extra_sfs" to remove the failing entry, or fix the problem so that it will load successfully next boot.

The list is stored as a variable called "XTRA_SFS" in the "BOOT_SPECS" file.
This file can reside in the frugal install directory or in "initrd.gz", but it must reside in the same place as "DISTRO_SPECS".
So if you use the "file2initrd" utility to move "DISTRO_SPECS" into "initrd.gz" then you should do the same with any "BOOT_SPECS".
Also if you move these files into "initrd.gz", it will confuse "extra_sfs" if copies still exist in the frugal install directory. So either delete them, or rename them.
It's easier to just leave these files in the frugal install directory.

Note on DISTRO_SPECS:
This file defines the puppy you are booting, so the same "initrd.gz" can boot many different puppies provided it has access to the appropriate DISTRO_SPECS.
So, having this file outside "initrd.gz" means the same "initrd.gz" file can be tested with many puppies without change, I've booted both 64bit and 32bit puppies with the same "initrd.gz".
The limitation of the current "initrd.gz" is that the puppies kernel must support overlayfs.

gyro

[Rangan Masti]

Hi, good work !
--Testing!!. Have a nice evening.

Rangan

[peebee]

Looking good here - although I did have an oddity when I did a reboot - I got the saving message but this was followed by a dropout to the terminal prompt and neither reboot nor poweroff actually worked - had to press the power off button....

[gyro]

[peebee]

[gyro]

[peebee]

[gyro]

@peebee,
Before I answer your questions there is just 1 thing:
Adding

[peebee]

[gyro]

[gyro]

[gyro]

So what have we learnt from this project?

Issues:

1. It has been reported on the net that there is a problem with using tmpfs as the upper fs for an overlay.
This is of concern because this init script does this for pupmode=5, pupmode=21 and pupmode=29.
Apparently this problem is related to a lack of extended attribute support in tmpfs, which can be fixed by compiling the kernel with "CONFIG_TMPFS_XATTR=y".
Fortunately the kernels in slacko 6.9.9.9 and LxPupSc 17.07.25 meet this requirement. Unfortunately the released kernel in xenialpup 7.0.8.1 does not.
The issue can be avoided by running in pupmoode=12.
Note: I have never experienced any problem, although I did notice recent kernels did complain with "overlayfs: uppper fs does not support xattr" in dmesg.

2. Compared to aufs, overlayfs has some significant limitations, i.e. can't add or delete directories in a stack, can't directly modify the contents of a directory in a stack.
This init script works within these limitations.

Things we can do:

1. We can boot and run normal woof-ce puppies using overlayfs for the stack.
The upside is, overlayfs is supposed to be very efficient, and is supported directly in the kernel, (no aufs patch needed).
The downside is, "sfs_load" is gone, the stack has to be completely created by init.
We can still have extra sfs's, it's just that it takes a reboot, to actually load or unload an sfs.

2. The same initrd.gz can be used to boot many different puppies.
I introduced the facility for init to use a DISTRO_SPECS from outside the initrd.gz to simplify testing.
But it has demonstrated that, just as we can move huge-kernels from one puppy to another, it's possible to move initrd.gz's from one puppy to another.
So I can take this initrd.gz, push my "TIME_ZONE" file into it, and expect to be able to boot any woof-ce puppy with it, after extracting the puppies DISTRO_SPECS from the release initrd.gz.

3. We can easily specify things like extra sfs's before first boot, using a BOOT_SPECS file, beside the DISTRO_SPECS file.
(And any specified extra sfs's will be loaded by first boot.)

4. We can have a puppy that has automatic persistence, without shutdownconfig.
Of course pupmode=21 has significant limitations, i.e. it all has to fit back into the tmpfs on next boot.
So it would not be recommended for use as a "work" puppy.

Other new things:

1. Enable save folder by simply creating an appropriately named directory.
If done before first boot, e.g. as part of installation, it will be ignored until first reboot.

2. "pfix=nosave" boot parameter, disables automatic saving at shutdown in pupmode=5, pupmode=21 and pupmode=29, i.e. when /initrd/mnt/tmpfs/pup_rw is the rw directory of the main overlay.

3. "pfix=rosave" boot parameter, use a read-only save layer, i.e. choose pupmode=29 instead of pupmode=12.
Pupmode=29 is a replacement for pupmode=13, but I didn't want to confuse puppy utilities like snapmergepuppy.

4. "pfix=nobs" boot parameter, disable processing of BOOT_SPECS file.

5. "pfix=nofsckp" boot parameter, disable fsck of each partition before first mount.
The previous "pfix=fsckp" processing is now the default.

gyro

[woodenshoe-wi]

I just wanted to let you know that after replacing the 386 binaries in the initrd.gz with ARM binaries I was able to use your init script on my Pi2 (1GB RAM) with only two small modifications.