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 _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox