Re: updating direct from 5 to 9?

[Martin Husemann <martin%duskware.de@localhost>]

On Sun, Aug 21, 2022 at 09:57:55AM +0200, Martin Husemann wrote:
> The only thing I found is in CHANGES-7.1:
> 
> sbin/fsdb/fsdb.c                                1.49
> sys/ufs/ffs/ffs_vfsops.c                        1.340
> usr.sbin/quot/quot.c                            1.34
> 
>         The superblock field that distinguishes between 4.2BSD and
>         4.4BSD inodes is really only relevant on a UFS1 file system.
>         Make sure that it is a UFS1 fs before using fs_old_inodefmt.
> 
>         Note that the NetBSD newfs and mkfs utilities initialize
>         fs_old_inodefmt even for UFS2, so problems were apparent only
>         on file systems created by other operating systems, for example,
>         FreeBSD.

I was curious and it was easy to test: I installed NetBSD 4.0 on a VirtualBox
VM (3.0 would not work with the virtual hardware and earlier versions
did not have a bootable ISO).

This gave me a MBR partitioned disk with (already) partition type 169,
which is good. It created a disklabel and a FFSv1 file system with
FFSv2 superblock and fslevel 4 -  so far all fine.

I then put a NetBSD 9.3 kernel into that filesystem and tried to boot it -
which resulted in a non mountable / filesystem - duh!

Booting a 9.3 install CD and digging around a bit I found the 9.3 kernel

 - auto-creates bogus wedges dk0 (for the FFSv1 at /) and dk1 (for the
   swap partition.

 - the wedges are bogus because their start block is 1 block off: the
   disklabel for wd0a makes the partition start at offset 63, but the
   auto-created wedge dk0 starts at block 64!

Removing the wedges makes /dev/rwd0a fsck fine (with 9.3's fsck_ffs)
and also makes /dev/wd0a mountable.

So what goes wrong is not at the file system level, but MBR and disklabel
handling. I dimly recall the disklabel moved into the type 169 MBR partition
a long time ago - I bet 4.0 was before that change and this is what
now causes the broken wedge auto-detection.

Martin