Date: Fri, 6 Dec 2002 18:06:03 +0200 From: Ruslan Ermilov <ru@FreeBSD.org> To: Petr Holub <hopet@ics.muni.cz>, Matt Dillon <dillon@FreeBSD.org> Cc: current@FreeBSD.org, mckusick@beastie.mckusick.com Subject: Re: UFS1 created by 5.0 is incompatible with 4.0's? Message-ID: <20021206160603.GB1058@sunbay.com> In-Reply-To: <004a01c29d27$45c2e0c0$2603fb93@kloboucek> References: <004a01c29d27$45c2e0c0$2603fb93@kloboucek>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Fri, Dec 06, 2002 at 01:59:11PM +0100, Petr Holub wrote: > Hi, > > > While testing the 4.0 -> 5.0 upgrade path, I've created (under > > 5.0) a UFS1 partition and installed 4.0 onto it. After booting > > the 4.0 from it, kernel complained about ``numdirs is zero, try > > using an alternate superblock'' for / partition -- I've tried > > what it suggests (by fsck -b 32, etc.) but the result was always > > the same -- the file system was marked dirty and only read-only > > usable. After rebooting in 5.0, this file system was similarly > > unusable. Is this a bug or a feature? > > I've discussed this issue with Poul-Henning Kamp. You need fsck > from at least 4.7. > Is this handled by fsck/setup.c,v 1.17.2.4 commit? : revision 1.17.2.4 : date: 2002/06/24 05:10:41; author: dillon; state: Exp; lines: +26 -56 : MFC 1.30. Check only the fields we know should be the same between the : primary and alternate superblocks, so fsck doesn't barf on new features : added to UFS in later releases. : : Submitted by: mckusick Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE98MrrUkv4P6juNwoRAtW4AJ44LkhTbjMMQjY0XQs7eNWTqc2TmQCggGg0 tN+d6RXkbVHKSuzx6IJAEH4= =0SGd -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021206160603.GB1058>