From owner-freebsd-current Fri Oct 16 21:36:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA26626 for freebsd-current-outgoing; Fri, 16 Oct 1998 21:36:19 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA26619 for ; Fri, 16 Oct 1998 21:36:18 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id VAA17784 for ; Fri, 16 Oct 1998 21:36:26 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: current@FreeBSD.ORG Subject: The "cross device link" bug people have been seeing on newfs Date: Fri, 16 Oct 1998 21:36:26 -0700 Message-ID: <17780.908598986@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Neither David, Mike nor myself have any idea why this is currently happening or why it apparently did not happen 3 days ago, but in the meantime I've come up with a work-around that appears to do the trick (according to Ulf, the first tester to respond, anyway). I've re-rolled the boot.flp on ftp.cdrom.com and, for consistency's sake, will also reroll the src and bin distributions so that newfs is updated in all locations. The fixed bits will also go out on the CDROM since I haven't built that yet. Those who have already installed 3.0-RELEASE can either cvsup themselves up to date to get the fix in or simply apply the following patch: RCS file: /home/ncvs/src/sbin/newfs/newfs.c,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- newfs.c 1998/09/30 07:53:52 1.25 +++ newfs.c 1998/10/17 04:19:29 1.26 @@ -601,8 +601,10 @@ if (realsectorsize != DEV_BSIZE) pp->p_size /= realsectorsize /DEV_BSIZE; #endif +#if 0 /* XXX this shouldn't fail, but it returns ENXDEV right now - pure workaround, this */ if (!Nflag && bcmp(pp, &oldpartition, sizeof(oldpartition))) rewritelabel(special, fso, lp); +#endif if (!Nflag) close(fso); close(fsi); Again, we've no idea why rewriting the label causes this bug in the first place and this is a WORK-AROUND until we do. Not rewriting the lable doesn't (shouldn't) hurt in any case since we don't use the fields it updates right now, at least not in any typical disklabel/newfs scenario. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message