NetBSD Problem Report #60855

From www@netbsd.org  Tue Oct  6 08:42:40 2026
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)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.netbsd.org", Issuer "YR1" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id E61841A923B
	for <gnats-bugs@gnats.NetBSD.org>; Tue,  6 Oct 2026 08:42:39 +0000 (UTC)
Message-Id: <20261006084239.059D31A923C@mollari.NetBSD.org>
Date: Tue,  6 Oct 2026 08:42:38 +0000 (UTC)
From: phako@free.fr
Reply-To: phako@free.fr
To: gnats-bugs@NetBSD.org
Subject: FFSv2ea superblok mismatch
X-Send-Pr-Version: www-1.0
X-From4GNATS: "phako@free.fr via gnats" <gnats-admin@NetBSD.org>

>Number:         60855
>Category:       kern
>Synopsis:       FFSv2ea superblok mismatch
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    chs
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 06 08:45:00 +0000 2026
>Last-Modified:  Sat Oct 31 15:30:02 +0000 2026
>Originator:     paco
>Release:        11
>Organization:
>Environment:
NetBSD netbsd.home.arpa 11.0 NetBSD 11.0 (GENERIC) #0: Thu Jul 30 15:23:12 UTC 2026  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
When creating with newfs or converting a FFSv2 to FFSv2ea filesystem with fsck_ffs -c ea, the resulting FS has all but the first one superblock with a wrong magic number, running fsck on such filesystem correct the issue and dumpfs then report the alternate blocks with the same magic number and FS type (FFSv2ea and not FFSv2 only) than the first superblock.
>How-To-Repeat:
Create a new FFSv2ea FS or convert a FFSv2 to FFSv2ea and run fsck or dumpfs -a on it.
>Fix:
I guess that creating and converting the FS whith the correct magic number on all superblocks should correct the issue.

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->chs
Responsible-Changed-By: chs@NetBSD.org
Responsible-Changed-When: Tue, 06 Oct 2026 12:15:43 +0000
Responsible-Changed-Why:
my area


From: Showta Ishizaki <zakinko@snowrabbit.org>
To: gnats-bugs@NetBSD.org
Cc: zakinko@snowrabbit.org
Subject: Re: kern/60855: FFSv2ea superblok mismatch
Date: Thu, 29 Oct 2026 09:01:27 +0900 (JST)

 I ran into the same thing while testing UFS2ea images in CI: a file
 system made with newfs -O 2ea fails fsck_ffs -n -f with "ALTERNATE
 SUPERBLK(S) ARE INCORRECT" straight after newfs.  As far as I can tell
 there are two causes, one in newfs and one in fsck_ffs.

 In newfs, mkfs() puts FS_UFS2EA_MAGIC only into the superblock itself.
 The alternates are written by initcg() from a copy in iobuf that was
 made earlier, so they still have FS_UFS2_MAGIC, and pass5 of fsck_ffs
 rejects an alternate whose magic does not match.  The magic is also
 stored after ffs_sb_swap(), in host byte order, so with -B be on amd64
 the superblock cannot be read at all; fsck_ffs reports "BAD SUPER
 BLOCK: SIZE PREPOSTEROUSLY LARGE".

 In fsck_ffs -c ea, setup() fills sblk from the in-memory sblock (whose
 magic is always FS_UFS2_MAGIC) to write the last alternate, and pass5
 later copies that buffer to every cylinder group.  That code repeats
 what sbdirty() does but leaves out cvt_magic(), so the alternates keep
 the old magic, and only the superblock itself is converted when
 ckfini() calls sbdirty().

 The patch below fixes both.  I tested it on NetBSD 11.0/amd64 with
 trunk as of 2026-10-28, using file images (newfs -F -s 64m) and
 checking the magic of each superblock copy.  Without the patch, newfs
 -O 2ea and newfs -O 2 followed by fsck_ffs -y -c ea both leave the
 four alternates with the plain UFS2 magic, with or without -B; newfs
 -O 2ea -B be gives the unreadable superblock described above.  With
 the patch, all five copies have the UFS2ea magic in the right byte
 order and fsck_ffs -n -f exits 0.  newfs -O 2 and fsck_ffs -c no-ea
 behave as before.

 Index: sbin/newfs/mkfs.c
 --- sbin/newfs/mkfs.c
 +++ sbin/newfs/mkfs.c
 @@ -662,6 +662,9 @@
  	memcpy(iobuf, &sblock, sizeof sblock);
  	if (needswap)
  		ffs_sb_swap(&sblock, (struct fs *)iobuf);
 +	if (eaflag)
 +		((struct fs *)iobuf)->fs_magic = needswap ?
 +		    FS_UFS2EA_MAGIC_SWAPPED : FS_UFS2EA_MAGIC;
  	if ((sblock.fs_old_flags & FS_FLAGS_UPDATED) == 0)
  		memset(iobuf + offsetof(struct fs, fs_old_postbl_start),
  		    0xff, 256);
 @@ -748,7 +751,8 @@
  	if (needswap)
  		ffs_sb_swap(&sblock, (struct fs *)iobuf);
  	if (eaflag)
 -		((struct fs *)iobuf)->fs_magic = FS_UFS2EA_MAGIC;
 +		((struct fs *)iobuf)->fs_magic = needswap ?
 +		    FS_UFS2EA_MAGIC_SWAPPED : FS_UFS2EA_MAGIC;
  	if ((sblock.fs_old_flags & FS_FLAGS_UPDATED) == 0)
  		memset(iobuf + offsetof(struct fs, fs_old_postbl_start),
  		    0xff, 256);
 Index: sbin/fsck_ffs/setup.c
 --- sbin/fsck_ffs/setup.c
 +++ sbin/fsck_ffs/setup.c
 @@ -453,6 +453,7 @@
  		sb_oldfscompat_write(sblk.b_un.b_fs, sblocksave);
  		if (needswap)
  			ffs_sb_swap(sblk.b_un.b_fs, sblk.b_un.b_fs);
 +		cvt_magic(sblk.b_un.b_fs);
  		memmove(asblk.b_un.b_fs, sblk.b_un.b_fs, (size_t)sblock->fs_sbsize);
  		flush(fswritefd, &asblk);
  	}

 File systems that already have the wrong alternates can be repaired
 with fsck_ffs -y -f, even without the patch, since pass5 rewrites the
 alternates from the superblock.

From: Phako <phako@free.fr>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/60855: FFSv2ea superblok mismatch
Date: Sat, 31 Oct 2026 16:29:50 +0100

 Le 29/10/2026 à 01:05, Showta Ishizaki via gnats a écrit :
 > The following reply was made to PR kern/60855; it has been noted by GNATS.
 > 
 > From: Showta Ishizaki <zakinko@snowrabbit.org>
 >   I ran into the same thing while testing UFS2ea images in CI: a file
 >   system made with newfs -O 2ea fails fsck_ffs -n -f with "ALTERNATE
 >   SUPERBLK(S) ARE INCORRECT" straight after newfs.  As far as I can tell
 >   there are two causes, one in newfs and one in fsck_ffs.
 >   

 [...]>   File systems that already have the wrong alternates can be repaired
 >   with fsck_ffs -y -f, even without the patch, since pass5 rewrites the
 >   alternates from the superblock.
 >   

 I don't understand all the implications of this response (eg: does it 
 correct also the following problem or not) but I have found a new 
 unexpected behavior:
 With a newly created FFSv2ea filesystem and non repaired by fsck_ffs, 
 checking it with the -n -X options (Use internal snapshot to check a 
 mounted FS) on it once mounted, no error are reported.  And inversely 
 when a mounted but now repaired filesystem, running fsck_ffs -n -X, get 
 you back the error "ALTERNATE SUPERBLK(S) ARE INCORRECT".

 Regards

>Unformatted:

Home	PR Database Search