From owner-freebsd-fs Fri Apr 30 14:14:57 1999 Delivered-To: freebsd-fs@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 70B4315597 for ; Fri, 30 Apr 1999 14:14:54 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id HAA19815; Sat, 1 May 1999 07:14:48 +1000 Date: Sat, 1 May 1999 07:14:48 +1000 From: Bruce Evans Message-Id: <199904302114.HAA19815@godzilla.zeta.org.au> To: dfr@nlsystems.com, klh@us.oracle.com Subject: Re: When is a FFS not a FFS? Cc: freebsd-fs@FreeBSD.ORG Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >FreeBSD/alpha will mount UFS filesystems from NetBSD/alpha and OSF1 with >no problems at all. Your problem is that FreeBSD/i386 puts the disklabel >at a different place on the disk from the alpha OSs. On the alpha, the >disklabel is stored at offset 64 in block zero but on FreeBSD/i386, it is >stored at offset zero in block one of the FreeBSD fdisk slice (which can >be anywhere). This doesn't explain why `disklabel -r da5' seemed to work, or how NetBSD/i386 handled labels at a nonstandard offset. I think alpha disks can only be handled by putting suitable metadata in sectors 0 and 1. Metadata suitable for NetBSD is not necessarily suitable for FreeBSD. `disklabel -r' is apparently finding slightly unsuitable metadata. For FreeBSD, sector 0 should not end with bytes { 0x55, 0xAA }, or else it will be considered to contain a DOS partition table and you would have to fudge that right too. Sector 1 must contain a valid label. A valid label for NetBSD needs more fudging than a valid label for FreeBSD, since the "raw" partition is 3 ('d') for NetBSD-i386 and 2 ('c') for NetBSD-alpha and FreeBSD-any. However, I think NetBSD-i386 labels look like FreeBSD-2.0 labels, and FreeBSD fixes up the latter. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message