shutdown busybox and start another PID1 process

[James Bowlin]

On Sun, Aug 10, 2014 at 11:52 PM, Laurent Bercot said:
>  I don't understand why you would pivot_root to shutdown. Who
>  cares what your rootfs is, since the system isn't going to
>  live anyway ?

I'm sorry, I should have explained.

I work on the Live system for MX-14 Linux and antiX Linux.  The
root file system is an aufs that combines a read-only squashfs
with a read-write fs that can be either tmpfs or a
file-system-on-a-file which I call a static persistence file.

If someone had done a frugal install (copy the squashfs file to
internal hd) or if they enable static root persistence (which
opens a persistence file on the internal hd ) then it is
impossible to cleanly umount the hd without doing a pivot_root
first.  These problems are not just on ntfs.  There is a problem
cleanly umounting any read-write file system that holds the
squashfs file or the static root persistence file.

Before I can umount the ntfs (or other rw fs) I need to first
umount the squashfs file and the static persistence file (if it
is being used).  To do that I need to first umount the aufs which
is the root file system.  Without the pivot_root, this is not
possible.  Among other things, the pivot_root gives me access to
/sys, /dev, and /proc even after I unmount the root file system.
IMO even non-live systems would benefit from doing a pivot_root
into a busybox system during shutdown.  You have access to a
fully functional shell all the way up to the final "shutdown" or
"reboot" command.

I try to design systems that are easy to debug.  I started out
doing professional programming in the 1970's by entering my
programs as hex machine code on a teletype.  I now like to make
things easy to debug, especially when there is a longish
development cycle like with this shutdown code.  The speed of the
development cycle for this is dominated by the need to fully boot
the system and then shut it down.

The game I play with the Live system is to do a switch_root at
the end of the /init script in the initrd and then do the
opposite, a pivot_root on my way out. I start and end in a
busybox environment.

Another reason I want to cleanly unmount the host/base filesystem
is because during startup I do periodic fscks on ext2/3/4
filesystems that are used by the Live system.  If I don't cleanly
umount these filesystems then the fsck is run on every boot
because the filesystems have not been cleanly umounted.  AFIAK,
we are the only LiveUSB that does this.

Having the squashfs and persistence files on a usb-2.0 or usb-3.0
or on a hard drive is MUCH faster than having them on a CD.  It
is fast enough that people have complained that they see little
benefit from the "toram" option only the LiveUSB.  The "toram"
option wcopies the squashfs file into RAM for better speed on the
LiveCD.

Many (at least a few) people use our LiveUSB or our frugal-install
as their main system.  It has a lot of great features and AFAIK, it
is the best LiveUSB in the Linux world.  One reviewer recently
said that it works just like Puppy Linux in many ways except it
is very reliable and is Debian based.

With decent hardware a user can do a frugal install and boot into
it in less than a minute.  The speed is dominated by how fast the
squashfs file can be copied to the hard drive.  The user also has
to select which partition they want to do the install on.  There
is a "Frugal Install" choice in the bootloader menu.  The first
time it is used we do the frugal install and boot into it.  On
subsequent boots it just boots into the frugal install that was
previously created.  I imagine this must be the fastest and
easiest Linux install available.  No reboot is needed.  You
select "Frugal Install" from the boot loader menu, select which
partition to use and a minute later you are running in X-windows
on the newly installed system.

The easy/fast frugal install was the culmination of years of work
(although I did not work continuously over those years, usually
just 2-month or 3-month spurts).  I think the overall strategy
and design were done in 2008 or 2009.  There was a lot of work
and learning involved getting all the many pieces working.

I've also fully automated our Live iso production.  On a decent
system you can create a 700M iso in five minutes (assuming that
most of the .deb files have already been cached (which my system
does automatically) or you have really good bandwidth).  We use
this automated system to build six different antiX iso files.
Other people have used it to make respins.


\end tooting my own horn


Peace, James