From owner-freebsd-questions@FreeBSD.ORG Wed Oct 15 09:57:13 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BE0616A4B3 for ; Wed, 15 Oct 2003 09:57:13 -0700 (PDT) Received: from front3.mail.megapathdsl.net (front3.mail.megapathdsl.net [66.80.60.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A62943FBF for ; Wed, 15 Oct 2003 09:57:11 -0700 (PDT) (envelope-from aarong@megapathdsl.net) Received: from [64.32.182.44] (HELO megapathdsl.net) by front3.mail.megapathdsl.net (CommuniGate Pro SMTP 4.1.3) with ESMTP id 103756619 for freebsd-questions@freebsd.org; Wed, 15 Oct 2003 09:57:10 -0700 Date: Wed, 15 Oct 2003 09:56:43 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: aarong To: freebsd-questions@freebsd.org Content-Transfer-Encoding: 7bit In-Reply-To: <20031015055546.GK13080@wantadilla.lemis.com> Message-Id: <8E3529BE-FF30-11D7-8995-000393A364C4@megapathdsl.net> X-Mailer: Apple Mail (2.552) Subject: Re: clearing Vinum configurations X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2003 16:57:13 -0000 On Tuesday, October 14, 2003, at 10:55 PM, Greg 'groggy' Lehey wrote: > On Tuesday, 14 October 2003 at 22:45:02 -0700, aarong wrote: >> I found my problem, I would obliterate a configuration and not >> saveconfig. > > No, that's not only not necessary, it doesn't work. saveconfig saves, > well, configurations. resetconfig obliterates configurations, so > there's nothing left to save. Which is what I thought as well, but it is my continued experience that if I don't tell Vinum to explicitly write "nothing" it will keep the previous configuration written. It's a bit late on my side of the world and as such, firing up the loud beast that is my test box to get some informative output is out of the question. I'll send the relevant stuff along tomorrow. > >> It is my experience that resetconfig will obliterate only the >> configuration currently read into memory, and NOT clear the Vinum >> configuration written to Vinum disks - in my case da0 and da1. > > As I showed in the example, you don't need a saveconfig. I realize that's not how its supposed to act, but its the only way I've gotten it to listen. Again, I'll have some output tomorrow morning my time. > > I'm getting confused here. A bit of the output of vinum(8) would go a > long way. What does 'vinum list' say? (this is on the remote, IDE box exhibiting the new problem of not remembering configurations after reboot) vinum -> list 1 drives: D alpha State: up Device /dev/ad0s1h Avail: 0/76316 MB (0%) D beta State: referenced Device Avail: 0/0 MB 4 volumes: V swap State: up Plexes: 2 Size: 1023 MB V root State: up Plexes: 2 Size: 125 MB V var State: up Plexes: 2 Size: 4096 MB V usr State: up Plexes: 2 Size: 69 GB 8 plexes: P swap.p0 C State: up Subdisks: 1 Size: 1023 MB P root.p0 C State: up Subdisks: 1 Size: 125 MB P var.p0 C State: up Subdisks: 1 Size: 4096 MB P usr.p0 C State: up Subdisks: 1 Size: 69 GB P swap.p1 C State: faulty Subdisks: 1 Size: 1023 MB P root.p1 C State: faulty Subdisks: 1 Size: 125 MB P var.p1 C State: faulty Subdisks: 1 Size: 4096 MB P usr.p1 C State: faulty Subdisks: 1 Size: 69 GB 8 subdisks: S swap.p0.s0 State: up PO: 0 B Size: 1023 MB S root.p0.s0 State: up PO: 0 B Size: 125 MB S var.p0.s0 State: up PO: 0 B Size: 4096 MB S usr.p0.s0 State: up PO: 0 B Size: 69 GB S swap.p1.s0 State: crashed PO: 0 B Size: 1023 MB S root.p1.s0 State: stale PO: 0 B Size: 125 MB S var.p1.s0 State: stale PO: 0 B Size: 4096 MB S usr.p1.s0 State: stale PO: 0 B Size: 69 GB vinum -> I'll then rm beta, rm -f swap.p1 ..., rm -f swap.p1.s0 ..., create /vinum.mirror which specifies beta and the *.p1 plexes, start each plex, then savecconfig, dumpconfig to double check, reboot, and I'm back to that list output right there. I've done this three times, one without the saveconfig step, and twice with the saveconfig. I find "dumpconfig" shows some very interesting output: vinum -> dumpconfig Drive alpha: Device /dev/ad0s1h Created on at Mon Sep 29 21:33:56 2003 Config last updated Thu Oct 16 10:37:45 2003 Size: 80023708672 bytes (76316 MB) volume swap state up volume root state up volume var state up volume usr state up plex name swap.p0 state up org concat vol swap plex name root.p0 state up org concat vol root plex name var.p0 state up org concat vol var plex name usr.p0 state up org concat vol usr plex name swap.p1 state faulty org concat vol swap plex name root.p1 state faulty org concat vol root plex name var.p1 state faulty org concat vol var plex name usr.p1 state faulty org concat vol usr sd name swap.p0.s0 drive alpha plex swap.p0 len 2096871s driveoffset 265s state up plexoffset 0s sd name root.p0.s0 drive alpha plex root.p0 len 256000s driveoffset 2097136s state up plexoffset 0s sd name var.p0.s0 drive alpha plex var.p0 len 8388608s driveoffset 2353136s state up plexoffset 0s sd name usr.p0.s0 drive alpha plex usr.p0 len 145554562s driveoffset 10741744s state up plexoffset 0s sd name swap.p1.s0 drive beta plex swap.p1 len 2096871s driveoffset 265s state crashed plexoffset 0s sd name root.p1.s0 drive beta plex root.p1 len 256000s driveoffset 2097136s state stale plexoffset 0s sd name var.p1.s0 drive beta plex var.p1 len 8388608s driveoffset 2353136s state stale plexoffset 0s sd name usr.p1.s0 drive beta plex usr.p1 len 145554562s driveoffset 10741744s state stale plexoffset 0s Drive /dev/ad0s1h: 74 GB (80023708672 bytes) Drive beta: Device /dev/ad3s1h Created on santosfc at Thu Jan 1 02:59:55 1998 Config last updated Thu Oct 16 03:31:44 2003 Size: 80023708672 bytes (76316 MB) volume swap state up volume root state up volume var state up volume usr state up plex name swap.p0 state up org concat vol swap plex name root.p0 state up org concat vol root plex name var.p0 state up org concat vol var plex name usr.p0 state up org concat vol usr plex name swap.p1 state up org concat vol swap plex name root.p1 state up org concat vol root plex name var.p1 state up org concat vol var plex name usr.p1 state up org concat vol usr sd name swap.p0.s0 drive alpha plex swap.p0 len 2096871s driveoffset 265s state up plexoffset 0s sd name root.p0.s0 drive alpha plex root.p0 len 256000s driveoffset 2097136s state up plexoffset 0s sd name var.p0.s0 drive alpha plex var.p0 len 8388608s driveoffset 2353136s state up plexoffset 0s sd name usr.p0.s0 drive alpha plex usr.p0 len 145554562s driveoffset 10741744s state up plexoffset 0s sd name swap.p1.s0 drive beta plex swap.p1 len 2096871s driveoffset 265s state up plexoffset 0s sd name root.p1.s0 drive beta plex root.p1 len 256000s driveoffset 2097136s state up plexoffset 0s sd name var.p1.s0 drive beta plex var.p1 len 8388608s driveoffset 2353136s state up plexoffset 0s sd name usr.p1.s0 drive beta plex usr.p1 len 145554562s driveoffset 10741744s state up plexoffset 0s Drive /dev/ad3s1h: 74 GB (80023708672 bytes) vinum -> > >>>> 2) why doesn't dd if=/dev/zero of=/dev/da0 seek=16 count=265 work? >>>> What's in those 265 sectors that I can't touch? >>> >>> The second sector on the disk is protected. You can't write to it. >>> If you start at sector 2, it will work. >>> >>> The Vinum label is at sector 8. That's the only sector you need to >>> clear to manually obliterate a Vinum configuration. >> > >> Then the command should look something like: dd if=/dev/zero >> of=/dev/da0 seek=18 count=263 ? > > No, > >> Sector eight after the sixteen sector bootstrap, correct? > > No. Just sector 8: > > dd if=/dev/zero of=/dev/da0 seek=8 count=1 > I see. > But you shouldn't need that. Agreed. However nothing is acting the way it should be, and aside from wanting to gain a better understanding of Vinum, I also want my setup to just work. Regards, -aarong > > Greg > -- > When replying to this message, please copy the original recipients. > If you don't, I may ignore the reply or reply to the original > recipients. > For more information, see http://www.lemis.com/questions.html > See complete headers for address and phone numbers. >