NetBSD Problem Report #57945

From www@netbsd.org  Sun Feb 18 15:33:36 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 4E7581A9239
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 18 Feb 2024 15:33:36 +0000 (UTC)
Message-Id: <20240218153334.C1E301A923A@mollari.NetBSD.org>
Date: Sun, 18 Feb 2024 15:33:34 +0000 (UTC)
From: jbglaw@lug-owl.de
Reply-To: jbglaw@lug-owl.de
To: gnats-bugs@NetBSD.org
Subject: makefs: msdos filesystems with label not reproducible
X-Send-Pr-Version: www-1.0

>Number:         57945
>Category:       misc
>Synopsis:       makefs: msdos filesystems with label not reproducible
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Feb 18 15:35:00 +0000 2024
>Last-Modified:  Sun Feb 18 17:05:01 +0000 2024
>Originator:     Jan-Benedict Glaw
>Release:        current
>Organization:
>Environment:
>Description:
Hi!

I'm working towards getting NetBSD builds reproducible. One issue I face is `makefs` creating/poupulating MSDOS/VFAT filesystems. They're nearly reproducible, but not quite.

While `makefs` has options to create reproducible filesystems (most outstanding are `-T <timestamp>` and `-o volume_id=<n>` (for `-t msdos`), the `-T` timestamp seems to be ignored in the case when there's a volume label (`-o volume_label=<name>`) supplied. That volume label seems to be stored like a filename entry, but it doesn't get the `-T` time set.
>How-To-Repeat:
# Reproducible case:

mkdir __content__
cp /netbsd __content__
makefs -s 100m -t msdos -o volume_label=NETBSD,volume_id=$((0x4711)) -T 1708256777 makefs1.img __content__
sleep 5
makefs -s 100m -t msdos -o volume_label=NETBSD,volume_id=$((0x4711)) -T 1708256777 makefs2.img __content__
sleep 5
makefs -s 100m -t msdos -o                     volume_id=$((0x4711)) -T 1708256777 makefs3.img __content__
sleep 5
makefs -s 100m -t msdos -o                     volume_id=$((0x4711)) -T 1708256777 makefs4.img __content__


sha256 makefs?.img
SHA256 (makefs1.img) = dd4be3ab580bb187a6a0e28cad8f11ccef73ceee6ea4bfc4d1fbdf5b60e88661
SHA256 (makefs2.img) = 3e49d1532e565a737cd06ea2035b098594b6fbefd4323a66eb8533f5115a1a97
SHA256 (makefs3.img) = 37d4bdfb9c5b04a543f46c046cf97139a25f510234da32e6e0f787618d2d5e40
SHA256 (makefs4.img) = 37d4bdfb9c5b04a543f46c046cf97139a25f510234da32e6e0f787618d2d5e40


If the `-o` option (in conjunction with `-t msdos` sets a `volume_label`, its timestamp is taken from current time. Using `fatcat` (had it around on a Linux box), you can actually have a look at the FS label and its timestamp (although that should have been gotten its time from `-T`):

jbglaw@lili:~$ for i in makefs?.img; do echo === $i ===; fatcat $i -l /; echo; done
=== makefs1.img ===
Listing path /
Directory cluster: 0
f 18/2/2024 15:25:42  NETBSD                                             c=0 s=0 (0B)
f 18/2/2024 11:46:16  netbsd (NETBSD)                                    c=12345 s=29579584 (28.2093M)

=== makefs2.img ===
Listing path /
Directory cluster: 0
f 18/2/2024 15:25:48  NETBSD                                             c=0 s=0 (0B)
f 18/2/2024 11:46:16  netbsd (NETBSD)                                    c=12345 s=29579584 (28.2093M)

=== makefs3.img ===
Listing path /
Directory cluster: 0
f 18/2/2024 11:46:16  netbsd (NETBSD)                                    c=12345 s=29579584 (28.2093M)

=== makefs4.img ===
Listing path /
Directory cluster: 0
f 18/2/2024 11:46:16  netbsd (NETBSD)                                    c=12345 s=29579584 (28.2093M)


The NetBSD kernel image OTOH has a properly set timestamp in all four images.
>Fix:
Not yet known. `makefs` uses code from usr.sbin/newfs_msdos and it _seems_ to properly set the timestamp option (and it actually works for copied content), but it seems to not work for the FS label.

>Audit-Trail:
From: "Christos Zoulas" <christos@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/57945 CVS commit: src/usr.sbin/makefs
Date: Sun, 18 Feb 2024 11:58:51 -0500

 Module Name:	src
 Committed By:	christos
 Date:		Sun Feb 18 16:58:51 UTC 2024

 Modified Files:
 	src/usr.sbin/makefs: msdos.c

 Log Message:
 PR/57945: Jan-Benedict Glaw: makefs: msdos filesystems with label not
 reproducible.
 When we specify a label, the volume label is used to create the root dir
 and it gets stamped by the timestamp. We were trying to set the timestamp
 in the fs-specific part of the options parsing which did not work since
 the method was called only for fs_specific options. Move setting of the
 timestamp just before we create the fs, where we reconcile the rest of
 the options.


 To generate a diff of this commit:
 cvs rdiff -u -r1.23 -r1.24 src/usr.sbin/makefs/msdos.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/57945: makefs: msdos filesystems with label not reproducible
Date: Sun, 18 Feb 2024 18:01:24 +0100

 The problem is the argument order: if you move the -T before the -o
 argument, it all seems to work fine.

 -T sets "stampst" (src/usr.sbin/makefs/makefs.c:257) and that is
 only transfered to the msdos specific options in 
 src/usr.sbin/makefs/msdos.c:msdos_parse_opts if that is called later.

 Maybe add a "dummy" final call after the getopt loop like

 	fstype->parse_options(NULL, &fsoptions)

 and make all parse_options deal with the NULL?

 Martin

Home	PR Database Search