layerfs setup in PUPMODE 5

[mavrothal]

Looked briefly in the init and pup sfs but I can not pin point where the layered files system (aufs or overlay) is defined.
The default in the init is aufs and DISTRO_SPECS has no relevant info (PUNIONFS) on first boot. So where would the overlay instruction would be?

[dimkr]

overlay is chosen if aufs is unsupported, or if booting with punionfs=overlay (#3363). This simplifies things a lot.

This line sets the default of aufs:

# Layered file system to use               
UNIONFS='aufs' 

Then, setup_onepupdrv is called for every SFS that gets loaded.

This block in setup_onepupdrv changes UNIONFS to overlay, if punionfs was specified, or if aufs is unsupported:

 if [ -n "$punionfs" ]; then                                                                                                 
  UNIONFS="$punionfs"                                                                                                        
 elif [ "$UNIONFS" = 'aufs' ]; then                                                                                          
  grep -qm1 aufs /proc/filesystems || UNIONFS="overlay"                                                                      
 fi 

When UNIONFS=overlay, a SFS is added to the stack using remount_overlay. It extracts the list of layers from /proc/mounts (if there is one) and creates a new overlay mount point with an extra layer for the newly mounted SFS.

Otherwise, if UNIONFS=aufs and it's the first SFS, the aufs mount point is created. Every SFS loaded is added as a read-only layer. All this happens inside setup_onepupdrv.

[mavrothal]

if punionfs was specified, or if aufs is unsupported

Let me try again
What I ask is:
on FIRST boot (PUPMODE 5) when init has UNIONFS='aufs' by default, where UNIONFS=overlay is specified for the system to use overlayfs.
For example on the first boot of dpup10.0.54, does it boot to overlay because the aufs is unsupported or is instructed somewhere do do so.
If instructed, where else punionfs is specified for the init to read?

[dimkr]

The 10.0.x kernel is built without aufs support. If the kernel supports aufs but you want to use overlay anyway, you must pass pnionfs=overlay in the kernel command-line.

[mavrothal]

The 10.0.x kernel is built without aufs support

That is not nice...
It really limits user choice forcing him/her to change or rebuild the kernel just to check which one suits him/her better.
I think that unionfs should be builder configurable either (as in the past I think) defined in the DISTRO_SPECS of main the sfs or better yet changing the default in the init.
Forcing the user to jump ropes is not kosher I would think.

[dimkr]

I'm fed up with aufs. If I can't maintain a 10.0.x release series for a year+ only because of frequent breakage of aufs or because aufs is unmaintained with known issues years before the kernel's EOL, then aufs is out of my releases.

All non-Debian-based woof-CE kernels (still) have a variant with aufs. A user who wants to swap the kernel with one of those is free to do so, but I won't be fixing aufs-specific bugs or fixing failing kernel builds for kernels with aufs.

Anyway, it's easy to switch between the two, without having to run woof-CE. You only need to swap the kernel (or drop punionfs=overlay if you have it) to change to aufs, and just specify punionfs=overlay to switch from aufs to overlay:

CONFIG_AUFS_FS	Boot parameter	File system used
y		aufs
n		overlay
y	punionfs=overlay	overlay
n	punionfs=overlay	overlay

[mavrothal]

No body asks you to support Aufs.
Besides if someone change the kernel are runs aufs and something in the main SFS brakes are you going to support it.? I guess (justifiably) not.
Why would you feel the need support if it if someone had change the initrd instead?

All I'm suggesting that one of puppies (and linux in general I would say) traditions is to tinker with the system.
The person that will rebuild the initrd.gz or the main SFS, to run aufs instead overlay or vise versa, should not be force to rebuild or change the kernel.

Removing a pre-existing option/choice from puppy and wanting to support it are two different things I believe.

[dimkr]

Removing a pre-existing option/choice

If I offer that choice, I won't be able to build kernels every time aufs breaks. Users who use overlay won't be able to use an up-to-date kernel with the latest security, only because that kernel cannot be built with aufs.

It happened in 5.10.140, it happened in 5.15.41, and it will happen again.

[mavrothal]

I do not think that are many distros offering on their stable releases the latest kernels just one day or week after they are released. The major reason is that they may brake some important functionality.
And is not like puppy is used for some major security servers that are constantly under attack so it needs the latest kernel security patches (not that the update kernels protect these system from the next attack)
So failing to catch up with a change or fix bugs immediately is not uncommon to programming, kernel included.
Anyway, do as you see fit. I think that aufs is a very handy option to have but as said many times, puppy is a doocracy.

[gyrog]

1. There are many kernels available that support both aufs and overlayfs.
2. Booting with either can be done by adding a "punionfs=" boot parameter to the appropriate "linux" line in "grub.cfg".
   The biggest problem for swapping between them is the incompatibility of the savefolder:
3. Whiteout files are implemented very differently.
4. Current Puppy overlayfs implementation has just an "upper" and "work" directories in the top of the savefolder. The "normal" content of the savefolder is in the "upper" directory.
   So, unless there are conversion utilities available, you need to do a clean install to change.