From owner-freebsd-questions Mon Sep 28 21:15:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA04203 for freebsd-questions-outgoing; Mon, 28 Sep 1998 21:15:38 -0700 (PDT) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from castor.chuck (lucy.bedford.net [206.99.145.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA04197 for ; Mon, 28 Sep 1998 21:15:32 -0700 (PDT) (envelope-from listread@bedford.net) Received: (from listread@localhost) by castor.chuck (8.8.8/8.8.8) id AAA04594; Tue, 29 Sep 1998 00:15:05 -0400 (EDT) (envelope-from listread) Message-Id: <199809290415.AAA04594@castor.chuck> Subject: Re: bad disk name and cannot mount In-Reply-To: <19980926144920.04980@cm110119.cableco-op.com> from Jeff Gray at "Sep 26, 98 02:49:20 pm" To: jwg@cm110119.cableco-op.com (Jeff Gray) Date: Tue, 29 Sep 1998 00:15:05 -0400 (EDT) Cc: freebsd-questions@FreeBSD.ORG X-no-archive: yes Reply-to: djv@bedford.net From: "Woodchuck" X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jeff Gray wrote: > Decided to upgrade a system by buying a new physical server, > transfer all the files over, and then use the old system for > another purpose. > > > The console says, in caps, > bad disk name /dev/sd0se2 you mean sd0s2e, of course... > bad disk name /dev/sd0s2f > > These are the correct device nodes for /usr and /usx > > a) any idea what happened or what caused this? Yeah, I have the feeling that tar may not have created the appropriate /dev files. A FEELING. If these were on slices 3 or 4 I would say, "I KNOW". Boot back up single user, mount -u -w / ; cd /dev and do sh MAKEDEV all and then sh MAKEDEV sd0s2a Do one for each N and M in sdNsMa that you have use for. (MAKEDEV sd0s1a takes care of [r]sd0s1[a-h] ) > b) any way short of re-installing to recover and get > files and remote access back? If the preceding doesn't work, then I'm all out of ideas. > c) other suggestions appreciated. For fun, on a working 2.2.6 system: cd /dev tar cpf /dev/null . >/dev/null 2>/tmp/err.log cat /tmp/err.log sample output: tar: rsd0s3: minor number too large; not dumped tar: rsd0s3c: minor number too large; not dumped tar: sd0s3: minor number too large; not dumped tar: rsd0s4: minor number too large; not dumped tar: rsd0s4c: minor number too large; not dumped tar: sd0s4: minor number too large; not dumped (many more, and not just scsi drive stuff). Is there a magic switch for tar that avoids this? Quien sabe? Dave -- Will hack for cabbages! Every day is Groundhog Day! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message