Another re-write of the "init" script - using OverlayFs?

[gyro]

@ruwoof,
When you say "chrooted", are you referring to the line,
"mount -o bind,ro / initramfs"?

I still can't quite get my head around the relationship between "top" and "/", since "initramfs" is the lowerdir of the stack.

I also would have thought you should be creating "/top/root/hello.txt" not "/changes/root/hello.txt".

Would this approach allow for the replacement of the stack with a different stack, i.e. containing a different sfs file in it's lowerdir list?

gyro

[gyro]

This project has become about experimenting with a lot more things than just overayfs, so I've morphed it into "Minimal Init Overlay (mio)",
at http://www.murga-linux.com/puppy/viewtopic.php?t=116059.

In the "mio" project, the overlayfs stuff is pretty much the same as here, but the other stuff is moving on.

There will be no more releases in this project.
Even if advancements are made with the overlayfs stuff, it will be released as a new version of the "mio" project.

Sorry, I meant to make this statement when I started the "mio" project.

gyro

[rufwoof]

@ruwoof,
When you say "chrooted", are you referring to the line,
"mount -o bind,ro / initramfs"?

mkdir initramfs and then mount -o bind,ro / initramfs has the current / system also reflected in intramfs/ ... excepting any mounted folders, as though the root system had been shifted over/into the initramfs folder. So when we chroot to that then its pretty much the same, not too dissimilar to doing a chroot /

I still can't quite get my head around the relationship between "top" and "/", since "initramfs" is the lowerdir of the stack.

.. but we're not actually doing just a chroot / we're creating a stack/layered sytem, where / (initramfs folder) is at the bottom (lowerdir) in that stack. top is the top folder (the visible layer), changes is the folder where changes are stored (like whiteout files in aufs, but using overlayfs style instead), work is just a (empty) folder for overlayfs to work.

I also would have thought you should be creating "/top/root/hello.txt" not "/changes/root/hello.txt".

Either really. Creating a file in the top (visible layer), adds that file to the changes folder (and vice-versa).

Would this approach allow for the replacement of the stack with a different stack, i.e. containing a different sfs file in it's lowerdir list?

If you exit the chroot, then you're back into the initramfs system, so yes you could create a entirely different stack set and chroot into that new stack. Maybe leaving the previous stack as before, or deleting it. If left as before then you'd have the option to again exit the chroot and revert back to that former stack. Best if the new stack has different changes/work folders as otherwise the new stack wouldn't work (work folder not empty) and/or the changes folder content for the original stack might have files/folders in it that conflicted with the correct operation/use of the new stack.

Unlike switch-root that in effect wipes out the initramfs content, with chroot the initramfs is still there. You could set capsh restrictions (provided built in) to prevent exiting out of a chroot to make it impossible to get back to the initramfs cli if that was desired, but equally if you block exiting out of a chroot then neither can you chroot into anything else.

In some ways, setting up and running (chroot'ing into) a stack, and then exiting out again, is a bit like having done a reboot back into the initramfs level, but without having had to go back through BIOS bootup. The record of changes made whilst in the stack are also available, so you could chroot back into the exact same stack and carry on as before. Or with the same stack re-established after a clean boot, along with a copy of the changes folder content loaded into the changes folder prior to doing the chroot, then the changes would have persisted across reboots. Fundamentally whilst you can't dynamically add/remove sfs's from overlayfs as you can with aufs, you can in effect do the equivalent of a quick reboot (exit chroot), reform the stack with additional (or removed) sfs's and chroot into that. But that does mean a fresh desktop whenever a sfs is loaded/unloaded, as though the desktop had just been restarted (couldn't for example have programs left running, or windows open ...etc. when a sfs was to be loaded/unloaded (as we exit the chroot)). However if you have a cli still running in the initramfs system then that could extract a sfs directly into the changes folder whilst the chroot system was still running, and that would be as though the sfs content had been added to the chrooted system. Or the initramfs cli could wipe out and replace the entire content of the changes folder content, which again the chrooted system would see those changes as having occured.

[gyro]

@ruwoof,

So, theoretically we could have something a bit like "Restart graphical server" in "Puppy Log Out", called "Restart Stack".
But would we end up performig most of "rc.shutdown" then "init" then "rc.sysinit", anyway.
Which is why for now I'm living with doing a "reboot" to change the composition of the stack.

Just to be clear, are you doing a chroot to top?

I find your approach interesting, since I have been wondering if there are ways of running a Puppy other than by using switch-root.
But frustratingly, I need to leave this "rabbit hole" for a later date.

gyro

[rufwoof]

Yes I chroot into top. That's just the naming convention that stuck with me. Typically I do mkdir sfs changes work top ... and then load (mount) a sfs to sfs, know that work is just required by overlayfs, changes has all changes recorded in it and top is the top 'visible' layer and the syntax is

mount -t overlay overlay -o lowerdir=sfs,upperdir=changes,workdir=work top
chroot top

If the main system is set up for such, then you can just chroot top as above and then run startx without having to go through rc. In my cutdown Bulldog (Fatdogs initramfs cli) I have a complete cli/tui system - that wifi net connects, has full OpenSSH (rather than dropbear), mc ...etc. I can and often do just use that boot (ssh into hashbang where tmux is running with irc, email ..etc. all as left when I was last logged in). Using that I could just mount the main fatdog sfs and chroot into it and run startx and have the gui desktop appear, with any changes being stored in the initramfs's changes folder (that could be pre-loaded from a saved version such as unsquashing a sfs of a prior changes folder mksquashfs. Or drop out of that (exit the chroot), set up a entirely different stack perhaps with another Puppy main sfs and chroot into that.

The main 'cost', is that unlike with aufs where you can just load a sfs at any point during a session with other windows open etc, with that method you do have to exit/restart - similar to exiting X and restarting X.

If you set up capabilities (capsh) then systems can be started with selected capabilities dropped. Along the lines of what EasyOS does. Bearing in mind that if you drop chroot capabilities then once you've chrooted into the main system (gui) then that's trapped, can't chroot out of itself (nor chroot into anything else). However if in initramfs you're running screen/tmux or even another session (ctrl-alt-Fn), then that can end (kill) that chroot'd gui session (in effect running cli in one terminal session, where that terminal session is running gui; running initramfs cli in another terminal session).

Fundamentally using chroot instead of switch-root.

[gyro]

@ruwoof,

Just one more question:
Have you tried making "changes" and "work", directories on a mounted Linux partition? (Thus providing persistence)

Then I'm going to have to leave this, until I have some time to produce some actual code that tries to do this, in a Puppy environment.

gyro