[Buildroot] [PATCH] fs/ext2: further fix to the UUID

* [Buildroot] [PATCH] fs/ext2: further fix to the UUID
@ 2013-05-28 22:11 Yann E. MORIN
  2013-05-28 22:19 ` Peter Korsgaard
  0 siblings, 1 reply; 2+ messages in thread
From: Yann E. MORIN @ 2013-05-28 22:11 UTC (permalink / raw)
  To: buildroot

From: "Yann E. MORIN" <yann.morin.1998@free.fr>

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>
---
 fs/ext2/genext2fs.sh | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/fs/ext2/genext2fs.sh b/fs/ext2/genext2fs.sh
index 7a6e232..a6cd7d2 100755
--- a/fs/ext2/genext2fs.sh
+++ b/fs/ext2/genext2fs.sh
@@ -49,6 +49,14 @@ e2tunefsck() {
         tune2fs "$@" "${IMG}"
     fi
 
+    # genext2fs does not generate a UUID, but fsck will whine if one is
+    # is missing, so we need to add a UUID.
+    # Of course, this has to happend _before_ we run fsck.
+    # Although a random UUID may seem bad for reproducibility, there
+    # already are so many things that are not reproducible in a
+    # filesystem: file dates, file ordering, content of the files...
+    tune2fs -U random "${IMG}"
+
     # After changing filesystem options, running fsck is required
     # (see: man tune2fs). Running e2fsck in other cases will ensure
     # coherency of the filesystem, although it is not required.
@@ -69,14 +77,9 @@ e2tunefsck() {
     printf "\ne2fsck was successfully run on '%s' (ext%d)\n\n"  \
            "${IMG##*/}" "${GEN}"
 
-    # e2fsck will force a *random* UUID, which is bad
-    # for reproducibility, so we do not want it. Asking
-    # tune2fs to 'clear' the UUID makes for an invalid
-    # fs, so we explicitly set a NULL UUID, which works.
     # Remove count- and time-based checks, they are not welcome
     # on embedded devices, where they can cause serious boot-time
     # issues by tremendously slowing down the boot.
-    tune2fs -U 00000000-0000-0000-0000-000000000000 "${IMG}"
     tune2fs -c 0 -i 0 "${IMG}"
 }
 
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 2+ messages in thread