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
