Several ways to skin a fat dog!

[Duprate]

Helo! FatDog64 is a very efficient system (everyone already knows). Recently, I decided to find other ways to start it. So, using Slacko64's initrd, with some modifications to the "init" script and "DISTRO_SPECS", the system continues to work very well. What is the advantage? None! However, it is already the first step to initialize it with Overlayfs. How to take the second step? Still do not know ...
If the pandemic continues too long, I will find out!

[Duprate]

My desktop ...

[s243a]

Helo! FatDog64 is a very efficient system (everyone already knows). Recently, I decided to find other ways to start it. So, using Slacko64's initrd, with some modifications to the "init" script and "DISTRO_SPECS", the system continues to work very well. What is the advantage? None! However, it is already the first step to initialize it with Overlayfs. How to take the second step? Still do not know ...
If the pandemic continues too long, I will find out!

You should have a look at the init script used in @dimkr's, "dpup OS 1 Rolling", it lets you specify the layers via symlinks and it doesn't have the limitations that the puppy initrd has regarding the amount of layers. It also uses overlayfs. Some links:

Puppy Linux without an initrd -- Barry's News

Nope. Every dpup OS version has a directory under boot partition, and every SFS has a symlink on the partition root:

dpup-os-1-x/1.sfs
dpup-os-1-x/2.sfs
1.sfs -> dpup-os-1-x/1.sfs
2.sfs -> dpup-os-1-x/2.sfs

During update, the new version is unpacked to a directory:

dpup-os-1-x/1.sfs
dpup-os-1-x/2.sfs
1.sfs -> dpup-os-1-x/1.sfs
2.sfs -> dpup-os-1-x/2.sfs
dpup-os-1-y/1.sfs
dpup-os-1-y/2.sfs

Then, the symlinks are updated to point to the new version:

dpup-os-1-x/1.sfs
dpup-os-1-x/2.sfs
1.sfs -> dpup-os-1-y/1.sfs
2.sfs -> dpup-os-1-y/2.sfs
dpup-os-1-y/1.sfs
dpup-os-1-y/2.sfs

Overwriting the SFS while mounted will result in issues, like inability to read /bin/busybox and reboot may not work, or X may crash, applications may not start, and so on.

But replacing the symlinks is safe, because the symlinks are resolved before the SFS files are mounted (https://github.com/dimkr/frugalify/blob ... ify.c#L181), so the mounted SFS is not modified on disk.

I noted you are now using overlayfs rather than aufs - is that correct?

Yes.

viewtopic.php?p=21355#p21355

[Duprate]

Helo! I didn't know what my second step towards Overlayfs would be on FatDog64! I'm not a programmer. But I'm lucky and I never give up! Today I am pleased to say that, using the WDLGO_UbuntuFocal64 initrd developed by "Wiak", I was able to start FatDog64 811 with an overlayfs kernel! Long live freedom!
Now, I will test exhaustively ....

The grub looked like this:

menuentry "FatDog64 WDLGO Overlayfs" {
linux /WDLGO/vmlinuz w_bootfrom=/mnt/sda3/WDLGO w_changes=RAM w_copy2ram kvm.nx_huge_pages=auto lockdown=confidentiality
initrd /WDLGO/ucode.cpio /WDLGO/initrd
}

[dimkr]

You should have a look at the init script used in @dimkr's, "dpup OS 1 Rolling", it lets you specify the layers via symlinks and it doesn't have the limitations that the puppy initrd has regarding the amount of layers.

Actually, it's artificially limited to 8 SFSs, but this limit can be raised easily

[Duprate]

Helo!
Now I am using the 5.11.12 overlayfs kernel, do not mount modules because, when necessary, I use the ROX-apps programs (type appimage) and the system run entirely in RAM. I think it's safer!

* ROX-apps: directory with application + AppRun (script) + icon (.DirIcon),
such as system applications in /usr/local/apps.

[Duprate]

My Desktop ...

Thanks to Wiak and his "magical initrd"!

It is very good to be able to compile the kernel, updating whenever necessary, without complications or additional patches!

[fatdoguser]

It is very good to be able to compile the kernel, updating whenever necessary, without complications or additional patches

I've been tracking 6.6 kernel, compiled 6.6.10 yesterday for instance, direct from kernel.org and a refined .config highly specific to my hardware, so all modules/firmware built in (mostly just make oldconfig with no changes however I changed it yesterday to include SND_ALOOP).

Boots to a framebuffer, where initramfs contains just enough to wifi/ethernet connect, has ssh/ssl, alsa and framebuffer vnc viewer, quite a capable 'bulldog' in itself. Around 6MB kernel, 6MB initramfs (both xz compressed), boots to around 50MB of ram being used, obviously very quickly.

Once booted I just do a straight mounting of sfs's and overlayfs those, and chroot into that, and start vncserver. As though a headless system. Then I fbvnc into that. The mounting of sfs's (I just load fd64.sfs and the devx sfs) overlayfs and chroot are also quick. I store the sfs's on HDD but they are just as operationally quick if stored on a second partition of a usb stick where the first partition is used as a grub4dos and vmlinuz/initramfs boot partition (somewhat EasyOS style).

Code: Select all

mount /dev/sda2 /mnt/sda2
mkdir /overlaystuff
cd /overlaystuff
mkdir lower middle upper work merged middledevx
mount -o bind,ro / lower
mount /mnt/sda2/FATDOG901-FINAL/fd64.sfs middle
mount /mnt/sda2/FATDOG901-FINAL/fd64-devx_901.sfs middledevx
mount -t overlay -o lowerdir=middledevx:middle:lower,upperdir=upper,workdir=work none merged
mount --bind /proc merged/proc
mount --bind /sys merged/sys
mount --bind /dev merged/dev
mount --bind /tmp merged/tmp
mount -t devpts devpts merged/dev/pts
chroot merged

fd64.sfs is my own reconfigured version, all the changes/setup I use, with a new fd64.sfs built from that. Similarly I update it regularly for the latest chrome version, download the chrome Deb, extract that and replace /opt/google/chrome folder with the new version in that Deb set.

As it boots very quickly I have no real issue with 'loading' a additional sfs, something I do infrequently anyway and when needed its just a additional sfs to add to the overlayfs as above, and a quick reboot.

A nice feature when booting to framebuffer is that its pretty much universal, and vncservers are also common. I have one on my phone so I can fbvnc into that and run a otter browser, another within a kvm/qemu vm on a powerful server that I use to compile the kernel, vncserver is available for mac, windows ....etc.

I also like being able to just compile the latest kernel, and takes <10 minutes to build for me. As do I like having the latest chrome, direct from the horses mouth. I have no real need to be able to dynamically load/unload sfs's without rebooting, for me a reboot flashes by in a quick grub menu for 1 second, kernel for a fraction of a second, initramfs for a fraction of a second type bish-bash-bosh

[m1k3]

Are there any benefits to using OverlayFS other than it being in the kernel?

[wiak]

Are there any benefits to using OverlayFS other than it being in the kernel?

The fact it is supported in the kernel means we can rely on overlayfs being updated with maintenance fixes. It does have some disadvantages compared to the likes of aufs such as easy on-the-fly insertion of new layers after booting, which overlayfs itself cannot do as far as I know. However, overlayfs is probably simpler in implementation, and for my purposes at lease works well and does plenty and enough - there are other ways to do the likes of on-the-fly sfs filesystem loading, so being able to rely on overlayfs as an ongoing supported technology is a winner thus far for my needs. I don't know if it is faster or slower or uses more RAM or CPU or not, but it works fine for me anyway. I don't in other words want to adopt a technique that may end up not maintained or buggy or overly complex in underlying code. I've heard, but don't myself know, that aufs is beginning to be problematic at times and older versions for older kernels no longer supported at all; main issue I personally have with aufs is that it needs a specially compiled kernel with aufs patches whereas overlayfs is available out to the box in official upstream available default kernel builds too, such as from Debian.

[fatdoguser]

Are there any benefits to using OverlayFS other than it being in the kernel?

OverlayFS
Sound
KVM/QEMU
... and for me the being in kernel is the predominant benefit.

I'm tracking the 6.6 kernel (6.6.10 as of recent). I also track stable busybox. Around a 10 minute task to compile. As the latest chrome versions are released I upgrade to that (replace /opt/google/chrome folder with the same folder within the chrome .deb file). All direct from the horses-mouth. For instance with James' .asoundrc config file along with SND_ALOOP=y in the kernel .config viewtopic.php?t=6112 and https://lightofdawn.org/blog/?viewDetailed=00228
and live recording is as easy as setting up a alias for arecord -D mixout recording.wav
or arecord -D mixout | lame - recording.mp3
and where much of the back end of that is maintained at the highest level.

Layering other levels on top, aufs ...etc. adds risk/complexity that for me is unnecessary. Kernel based sound/virtual machine/filesystem code is distinctly more preferable than alternatives that may involve dependency upon just a single individual as I believe is the case with aufs.

In the case of loading/unloading sfs's (aufs) and nowadays there's not a sea of difference between that and booting/shutting down a vm with whatever additional functionality that sfs may contain (or a simple mount sfs/overlayfs/chroot combination, or other choice) assuming that a avoiding a main system reboot was absolute necessity - which is my usage case more often isn't a issue.