fs/ext2: further fix to the UUID
authorYann E. MORIN <yann.morin.1998@free.fr>
Tue, 28 May 2013 12:11:37 +0000 (12:11 +0000)
committerPeter Korsgaard <jacmet@sunsite.dk>
Tue, 28 May 2013 22:18:37 +0000 (00:18 +0200)
commit60474dcec67922782a244ca3fe30fe9c35a5c963
treefa17d28fb8b16a67b93e3704dffa18bebfef2bf6
parent5b591b4052de5c650dcaa9033d77b739b82c132a
fs/ext2: further fix to the UUID

Turned out that setting a nil-UUID is no better than clearing it.

What currently happens is as follows:
  - first, genext2fs does not generate a UUID
  - then we tune2fs to upgrade the filesystem
  - then we run fsck, which generates a random UUID
  - then we re-run tune2fs to set a nil-UUID

So, on the target, if the file system is improperly unmounted (eg.
with a power failure), on next boot, fsck may be run, and a new
random UUID will be generated.

*However*, fsck improperly updates the filesystem when it adds the
UUID, and there are a few group descriptor checksum errors.

Those errors will go undetected until the next fsck, which will then
block for user input (bad on embedded systems, bad).

Fix that by systematically generating a random UUID _before_ we call
to fsck.

A random UUID is not so bad, after all, since there are already so
many sources of unpredictability in the filesystem: files date and
ordering, files content (date, paths...) which renders a fixed UUID
unneeded.

And it is still possible to set the UUID in a post-image script if
needed, anyway.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
fs/ext2/genext2fs.sh