Add overlay support to initrd.gz

[dimkr]

With this PR, a Puppy built with UNIONFS=overlay uses overlay instead of aufs. sfs_load only manages the list of SFSs to load at boot time, and SFSs cannot be loaded on-the-fly.

Still testing this. So far, tested live boot and use of a savefolder. Seems to boot faster in a VM, compared to aufs, but it could be an illusion.

sfs_load has many levels of indentation, making it impossible to minimize the changes. It's easier to review this PR with whitespace changes hidden: https://github.com/puppylinux-woof-CE/woof-CE/pull/2963/files?diff=unified&w=1.

[mavrothal]

A brief test of the init and sfs_load on bionic64 installed in a HD shows no problem (using aufs).
Tried it with the vDpup kernel but is not functional on bionic64 (no input devices)
So, not sure how the init will behave with layerfs. Specially with the options to have the SFS/save files all over the place as the current init options allow.

Using the sfs_load with fugalified vDpup not much is happening.
The SFS-to-be-installed is queued and stays queued (ie not loaded or moved at the root of the partition)

Bottom line, more testing is needed.

[mavrothal]

Forgot to mention that adding a punionfs as kernel parameter in the new init and setting it to overlay results in kernel panic using the vDpup 5.10.102 kernel and zdrv (un-usrmerged).

[dimkr]

This won't work with Vanilla Dpup, it relies on the changes in 3builddistro.

[mavrothal]

I managed to get bionic64 (in a subdir) going with overlayfs. Looks OK.
Savefolder created and loaded. However, is pretty messy .
The savefolder has the usual files and also "upper" that also has the overlayfs save directories.
Trying to sfs_load (with the new sfs_load) an SFS at the root of the partition is queued and never loads.
Trying to laod an SFS at the root of the subdir results in kernel panic.

[mavrothal]

This won't work with Vanilla Dpup, it relies on the changes in 3builddistro.

I just added in the init a pfix option overlay) PUNIONFS="overlay";; and booted with pfix=overlay

[dimkr]

Trying to sfs_load (with the new sfs_load) an SFS at the root of the partition is queued and never loads.

As I mentioned earlier - sfs_load is used only to select the SFSs to load at boot time.

[mavrothal]

As I mentioned earlier - sfs_load is used only to select the SFSs to load at boot time.

I do not expect to SFS_load to load the SFS in the overlayfs.
What I see and mentioned above is the selection of the SFS by sfs_load is not working as expected, because
a) when the SFS is at the root of the partition the SFS is queued but not loaded in the layerfs at reboot,
and b) when the SFS is at the root of the subdir that the puppy is booting from, leads to kernel panic at reboot.

[mavrothal]

The f997a89 init still gives kernel panic trying to load an extrasfslist sfs file

[dimkr]

https://github.com/dimkr/woof-CE/releases/tag/vanillaupup-22.03-beta4-overlay is a rebuild of Vanilla Upup 22.03 beta4, with this branch merged.

Tested saving into a savefile under the partition root and saving to a folder (with psubdir) seem to work just fine. I tested loading of SFSs from psubdir and from the root, and made sure init continues if a SFS is missing or invalid.

[mavrothal]

The init in vanillaupup-22.03-beta4-overlay works as advertised with overlayfs AND in with aufs (removed PUNIONFS from the puppy sfs PUPSTATE file that init looks at to deside for the unionfs)
Testing was brief of course but still

[mavrothal]

Not sure if this is a design choice buy acfc73d finds extraSFSs only in then PSUBDIR and not at the root of the partition

[mavrothal]

6ae9d21 still fails for me to load SFSs from the root of the partition in overlayfs.

[mavrothal]

Looks like that what is happening is the grep -m1 /dev/sda1 shows as mounted in /initrd/mnt/pdrv that does not exist and not in /initrd/mnt/dev_save which is actually the root of the partition.

[mavrothal]

7047bd0 loads extra SFSs from the root of the partition fine. However it fails to load them from PSUBDIR.
Interestingly enough, if you reintroduce the syntax error of 20eed6f it now recognises the extra SFSs in the PSUBDIR but not the root.
You might want to go back to 4a9bdfc

[mavrothal]

dfde6df works as expected both under overlayfs and aufs.

One issue I noticed under AUFS is that sfs_load fails to unload extra SFSs indicating that they are in use. Does not appear to be an sfs_load issue as the woof-ce version also fails. Looks like is an effect of the way extra SFSs are mounted in the union now.

[mavrothal]

Not sure if a68b4ff aims to address the unloading of extraSFSs loaded in the union at boot time under AUFS, but it does not.
(No other testing was done with this init)

BTW I find this addition handy (for me now and) in case unionfs becomes user-configurable

--- a/init	2022-03-14
+++ b/init	2022-03-14
@@ -1083,6 +1083,9 @@
 mount
 echo --------------------
 
+# Inform the user for the layer system we use in case of multiple savefiles
+echo -en "$(printf "The layer file system is \\033[1;35m${UNIONFS}\\033[0;39m")" > /dev/console
+
 PUPSAVE=""
 if [ "${SAVE_MP}" != "" -a "$PRAMONLY" != "yes" ];then #have mounted save? partition
  #check if save partition is linux

[mavrothal]

6e72953 still fails to unload extrasfs.
sfs_load fails to -o remount,del:/initrd/pup_ro3 unionfs / at L1507 with the generic mount-FULL: /: wrong fs type, bad... error

BTW the addition of "filesystem used" at the switch_root stage is impossible to catch up at the console and fairly late in the game to be of any use to the user.

[dimkr]

6e72953 still fails to unload extrasfs. sfs_load fails to -o remount,del:/initrd/pup_ro3 unionfs / at L1507 with the generic mount-FULL: /: wrong fs type, bad... error

Is it with aufs? If yes and it's the same behavior as in testing before this PR, I'm not going to fix this.

If it's with overlay, then sfs_load shouldn't try to unload, and it's a bug I need to fix.

[mavrothal]

Is it with aufs? If yes and it's the same behavior as in testing before this PR, I'm not going to fix this.

If it's with overlay, then sfs_load shouldn't try to unload, and it's a bug I need to fix.

This with AUFS and this behaviour appears to be triggered by the specific PR.
Unmounting SFSs from the extrasfs list in 9.0.35 works fine.
However, in vanillaupup-22.03-beta4-overlay (with modified PUPSTATE to run aufs) and the 6e72953 init, it fails. Both with the modified sfs_load of this PR or the sfs_load from 9.0.35.

Could be an issue with busybox mount and mount-FULL or something else in vanillaupup-22.03-beta4-overlay that triggers that. If not, this PR breaks the sfs_load function for aufs-running puppies

[dimkr]

Unmounting SFSs from the extrasfs list in 9.0.35 works fine.

9.0.35 is not built from testing (very far behind), so this is irrelevant.

I'll test everything aufs-related in a dpup built from this PR.

[mavrothal]

Not sure how relevant 9.0.35 is, but using the the 6e72953 init with it gives NO problem in unloading sfs files from the extrasfs list.
This is good I guess.

Latter I may test the sfs_load in that environment too.

[mavrothal]

Latter I may test the sfs_load in that environment too.

The sfs_load from this PR also works in 9.0.35 with or without the new init.
So looks like the sxtrasfs unloading was some strange vanillaupup-22.03-beta4-overlay issue.

[01micko]

Why not break up sfs_load into sfs_load_aufs and sfs_load_overlay and make a symlink at an early stage?

I'm hearing you about quicksetup!

(edit)
OR.. keep sfs_load as a entry point and if[ under the right condition ] exec sfs_load_aufs elif [ the other right condition ] exec sfs_load_overlay else "why are you running a full install?".

[dimkr]

Why not break up sfs_load into sfs_load_aufs and sfs_load_overlay and make a symlink at an early stage?

Tried that! It does so many things in one script, and some things work for the wrong reason: for example, loaded SFSs are considered to be loaded because it checks the output of losetup -a at some point, instead of using one of the global variables.

But maybe I can write a simple replacement, just a list of SFs with checkboxes (load next time or not).

OR.. keep sfs_load as a entry point and if

Yes, like I did with snapmergepuppy - I think this is a better approach.

[dimkr]

#!/bin/sh

. /etc/rc.d/BOOTCONFIG
. /etc/rc.d/PUPSTATE

export TEXTDOMAIN=sfs_load
export OUTPUT_CHARSET=UTF-8

queue() {
	. /etc/rc.d/BOOTCONFIG
	cat << EOF > /etc/rc.d/BOOTCONFIG.tmp
EXTRASFSLIST='`echo "$EXTRASFSLIST $1" | tr ' ' '\n' | sort | uniq | tr '\n' ' ' | sed -e 's/^ //' -e 's/ $//'`'
PREVUNIONRECORD='$PREVUNIONRECORD'
LASTUNIONRECORD='$LASTUNIONRECORD'
EOF
	mv -f /etc/rc.d/BOOTCONFIG.tmp /etc/rc.d/BOOTCONFIG
}

unqueue() {
	. /etc/rc.d/BOOTCONFIG
	cat << EOF > /etc/rc.d/BOOTCONFIG.tmp
EXTRASFSLIST='`echo "$EXTRASFSLIST $1" | tr ' ' '\n' | sort | uniq | fgrep -v $1 | tr '\n' ' ' | sed -e 's/^ //' -e 's/ $//'`'
PREVUNIONRECORD='$PREVUNIONRECORD'
LASTUNIONRECORD='$LASTUNIONRECORD'
EOF
	mv -f /etc/rc.d/BOOTCONFIG.tmp /etc/rc.d/BOOTCONFIG
}

export -f queue unqueue

LOADED=`losetup -a | sed 's~.*/~~g' | grep '\.sfs$'`

SFS_DIRS="/initrd${PUP_HOME}"
[ -n "$PSUBDIR" ] && SFS_DIRS="$SFS_DIRS /initrd${PUP_HOME}${PSUBDIR}"

BUTTONS=""
for SFS in `find $SFS_DIRS -maxdepth 1 -name '*.sfs' -printf '%f\n' | sort | uniq`; do
	DEF=false
	for BASE in $EXTRASFSLIST; do
		[ "$BASE" != "$SFS" ] && continue
		DEF=true
		break
	done

	if [ "$DEF" = "false" ]; then
		AUTO=0
		for BASE in $LOADED; do
			[ "$BASE" != "$SFS" ] && continue
			AUTO=1
			break
		done
		# if the user didn't ask to load this SFS but it's still loaded, it's
		# probably auto-loaded and we should hide it
		[ $AUTO -eq 1 ] && continue
	fi

	BUTTONS="$BUTTONS <togglebutton><label>$SFS</label><default>$DEF</default><action>if true queue \"$SFS\"</action><action>if false unqueue \"$SFS\"</action> </togglebutton>"
done

TITLE=xx
export DIALOG='<window title="SFS-Load" default_width="400">
	<vbox space-expand="true" space-fill="true">
		'`/usr/lib/gtkdialog/xml_info fixed package_sfs.svg 20 "$(gettext "Which SFS do you want to load?")"`'
		<vbox scrollable="true" height="400">
		'$BUTTONS'
		</vbox>
	</vbox>
</window>'

exec gtkdialog -p DIALOG

@01micko What do you think?

[01micko]

It's a reasonable start.

Bear in mind some scripts call sfs_load +my.sfs to load, so that it can be added to the queue.

[dimkr]

Using a upup built from this PR for weeks now and it works very very well. snapmergepuppy.overlay is pretty efficient, and it's much faster than the aufs equivalent. Application start times are great (much better than aufs, probably because pup_rw acts as a cache layer), and changes don't get lost like they sometimes do with aufs, because the inherent race condition between whiteouts handling in snapmergepuppy and the creation of new files is not a problem with overlay. IMHO, the PUPMODE 13 user experience with a slow flash drive, enough RAM and zram swap is much better compared to aufs (but not because overlay is 'better').

There are limitations compared to aufs, like the inability to load a SFS without having to reboot (which I don't find very limiting myself, I apt install my applications), and it's easier to accumulate enough files in pup_rw to fill RAM, so you have no choice but to save and reboot (to get a brand new, empty pup_rw).

[mavrothal]

Still not merged or further tested? :-o

[dimkr]

Still not merged or further tested? :-o

I'm waiting for @01micko to decide (and I'm giving others time to raise objections) - I think this PR is not perfect, but good enough for a beta release followed by small fixes. I'm using a Puppy built from it as a daily driver on one of my laptops, and it works great.

[01micko]

Still have had no time to test this but I'm thinking about waving it through.

[dimkr]

As long as it's not the default and doesn't break aufs in any way, I don't think it's risky.

[dimkr]

I've been using overlay since March, and it still works very well.

The only problem I had was the small size of pup_rw: if you apt install many packages and it gets full, and you have to save+reboot to flush it back to disk, while with aufs, you need to save and don't have to reboot. But it's better since 03c4824: with a limit of 75% (for example, up to 6 GB of changes if you have 8 GB of RAM), it's really hard to fill pup_rw. Under normal use, without installing big packages, it rarely exceeds 1 GB even with uptime of several days, because most changes are browser cache files and they have a size limit.

[dimkr]

@puppylinux-woof-CE/members @puppylinux-woof-CE/founders Objections to this PR?

[mavrothal]

3 months since the last commit in the PR, is pleanty of time for review.
I intent to merge this WE (if no one else does)

[dimkr]

3 months since the last commit in the PR, is pleanty of time for review.

I squashed this PR about a week ago. I added a punionfs=aufs/overlay boot code to allow the user to override the default.

I want to cherry-pick this PR into Vanilla Dpup 9.2.x, as a "technology preview" for users who want to try overlay. Some users will find this useful, especially those hit by #3187.

[mavrothal]

Forget cherry picking
From what I can see very few pups are build these days from woof
Merge and if it breaks anything, you'll have the review!!!

[dimkr]

Merge and if it breaks anything, you'll have the review!!!

Ha, it will break PPM (because #3188 and #3115). I hate PPM and I don't use it: all my woof-CE builds include apt. I think I'll just make PPM show an error and quit if it's overlay at /, in a separate PR.