Re: fsck damages FreeBSD 5 disklabels ?

[Craig Carey <research_(_at_)_ijs_(_dot_)_co_(_dot_)_nz>]

At 2003-08-13 23:39 -0600 Wednesday, Theo de Raadt wrote:
...
>> There is a magic number in the 1st 2 (512byte) blocks and it is
>> checkable. My report is weak but it seem like an OpenBSD bug
...
>
>Hundreds of Unix operating systems ship with an fsck that will not check
>that field.
>
>Therefore, it is clear that they are creating an incompatibility.
...
-------------------

By the way, I quit OpenBSD, but I returned to finish off this thread.

It turned out that OpenBSD was innocent. In fact it was official
FreeBSD 5.1 that was trashing disk info on that size and locations
of UFS2 slices.

The faulty binaries appeared in about 5 June 2003. Still they are
not updated:
  ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/5.1-RELEASE/

That directory lacks a document providing a warning. Obviously there
is some problem putting a text file into that directory. They really
don't respond well to inquiries.

---

Clues:

(1)  OpenBSD is not the cause of the trashed UFS2 disklabels because
the problem reappeared after I repaired the disklabels (using
Norton DISKEDIT.EXE, etc) and deleted my OpenBSD installation.

(2) The FreeBSD 5.1 "bsdlabel" program can't read the disklabels
 correctly. It shows a good UFS2 disklabel as being corrupt when it
 isn't. (My HDD was a Seagate 80GB Barracuda).

One of the official 5.1 executables was corrupting my FreeBSD UFS2
slice data since it had to be that. Probably it was fsck called from
the code running fstab.

Installing an v5.1 emergency repair system is a way to cause
(seeming) destruction of the other FreeBSD UFS2 system.

Buildworld removes the problem, but FreeBSD v5 buildworld didn't
run last time I tried it.


Craig Carey