On Mon, Aug 11, 2014 at 08:06 AM, Laurent Bercot said: > Isn't it possible to simply remount it read-only ? That's the > traditional way of fscking a rootfs, and it has always worked > for me - but maybe it's unapplicable to your situation, > especially with a HD install that users can modify.
I used to do this but I think the aufs (which combines several file systems into one) made it not work as well as I wanted. One of my workarounds was to use dynamic root persistence where changes to the fs (the rw part) was still in tmpfs but we copied in to the tmpfs from our root persistence file on startup and copied from tmpfs to the root persistence file before shutdown. This ensured that all the writing I needed to do happened before the real shutdown process. There was a need to have static root persistence where the changes are saved directly in the root persistence file so I needed to bite the bullet and finally get clean umounts during shutdown. Previously, filesystems were consistently reporting they were uncleanly mounted. I wanted to do it all cleanly. I tried like crazy to get remounting read-only to work but I just could not do it. Maybe the problem was that I couldn't remount the rw file system under the aufs as ro (because the aufs was rw) and I couldn't remount the aufs as ro because its mount options are unconventional. > I don't think functionality is your argument here: you'll never > have *more* functionality than a full-fledged system that has > been live and made it all the way to your shutdown procedure. Well busybox has all the tools I need. The tmpfs gives me a place to stand so I can move the world^H^H aufs file system. It gives me a place where my tools and everything I need are off of the aufs. > AIUI, your argument is reliability: by pivot_rooting on a known, > static, unmodifiable-by-the-user image, you have the guarantee > that you can perform clean operations even if the user has hosed > the root filesystem. I pivot onto a tmpfs that has the busybox stuff and very little else. Root could easily erase it all. Since it is tmpfs there is no need to umount it at all. The point is to finish the shutdown from a tmpfs so I can cleanly umount the aufs and the filesystems under it including the file system on the host machine or on the LiveUSB. > Hehe. I like to say that initrd/initramfs is useless, [...] It is required for a live system. It is needed at the very least to find the squashfs file and mount the aufs. Ours does a bunch more than this. We offer home persistence and two kinds of root persistence, and live remastering and the "toram" feature and an md5 check of almost all of the major files (just not the bootloader), and probably a bunch of other things. As I said before we check the rw filesystems we use to see if they need to be fscked. We perform the fsck if it is needed. In the last round of development I added the easy frugal install and easy persistence. If you select persistence and the persistence file(s) are not found then we offer to create them for you. These need to be in place *before* /sbin/init starts because the root filesystem is based on the aufs which is based on the data in the root persistence file. Basically, any futzing around you need to do to create the root filesystem needs to be done in the initrd. In addition, by doing the frugal install and persistence file creation in the initrd, it makes things much easier and faster for the user. Previously, users would have to boot, get passed some error messages saying files were missing to do what they selected and then they had to run some program(s) to create the files (or do the frugal install) and then reboot. Now instead of throwing an error or a warning when the files don't exist to do what the user asked to do, I create them on the spot. There were a number of standard complaints we used to get on the forums regarding the convoluted reboot process. We don't get these complaints any more. > it adds more complexity than it helps you. We've certainly added a lot of complexity. OTOH it makes it really easy and convenient for the users. I have a theory about this which explains why Flash beat Java in the browser even though Java had almost every conceivable advantage: first to market, it came pre-installed, it has a clean code base, it was a full fledged programming language. Flash won because they absorbed the complexity into their code base, making things easier for both developers and users. Java took the opposite approach and made their code base as simple as possible (for easier porting) but this meant you needed to be a programmer plus a UX designer to work in Java and the user experience usually sucked unless the developer absorbed complexity in order to shield the user from it. In the end Flash won even though its code base was/is a nightmare because you didn't need to be a programmer to write in it. It was designed to be programmed by graphics designer. This, in turn led to consistently better user experiences. I'm not saying it was impossible to create a great user experience in Java (well at least in Java 1.1 and later) it just took a skilled programmer and a lot of work. If that programmer was not also a graphics designer then you needed to hire one of those as well. Flash is very very very loosely based on a byte-code language I wrote back in the early 1980's for doing laser light shows. I was under a horrendous deadline (one month to hire people, put in phones and stuff, build the hardware and get all the software written). I designed a simple byte-code language so the people designing the show could work in parallel with the person implementing the language. We had something Forth-like before that but only the person who wrote that system could write shows for it. My focus was on making a language that non-programmers could use. This same focus was used in designing Shockwave and then Flash. I went off to physics grad school after that but one of the guys who worked for me and who used the language went on to start MacroMind which later became MacroMedia. I'm not claiming I deserve credit or renumeration or anything. I'm delighted to have my ideas and my (sometimes unique) approach spread around. My approach has usually been to shift complexity into what I'm working on in order to keep it away from developers and users. My theory is like the CAP theorem. You usually can't eliminate complexity, you can only shift it between: 1) your code base 2) the downstream developers 3) the users Java minimized complexity in (1) which shifted it on to (2) and (3). Flash took the opposite approach. They minimized the complexity in (2) and (3) by shifting it into (1). IMO Flash sucks (well not nearly so bad as it used to) but a part of me is pleased that their choice of where to shift the complexity won out in the marketplace. If you shift more complexity into your code base than you can handle then it is a big lose-lose-lose. A similar thing happened in Perl. The Perl-5 code base is a nightmare but the language is great for developers and for end-users (I realize not everyone agrees with me here). In Perl-6 they decided it was time to clean up the code base and "do things right". The design of Perl-6 started 14 years ago. The last time I tried it (a few years ago), it was way too slow to be usable, but hey, their code base is clean. It seems they wanted to be more like Java. Waddaya know, they seem to have succeeded. I think I need to join OAOA: on-and-on anon. > Come back to the candy store any time you want. Not only do we > have some yummy candy, but you may also have some brands to > share that we're not familar with! Gosh, thank you! I couldn't resist replying after I read that. It is better than talking to myself (as I've done for years) and I still know someone intelligent and knowledgeable is listening. Peace, James _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox