Date: Sun, 3 Jun 2001 17:50:56 +0930 From: Greg Lehey <grog@FreeBSD.org> To: Steve Price <steve@havk.org> Cc: freebsd-stable@freebsd.org Subject: Re: vinum panic Message-ID: <20010603175056.H85812@wantadilla.lemis.com> In-Reply-To: <20010603012207.A15922@bsd.havk.org>; from steve@havk.org on Sun, Jun 03, 2001 at 01:22:07AM -0500 References: <20010602121353.N688@bsd.havk.org> <20010603101756.P87716@wantadilla.lemis.com> <20010603012207.A15922@bsd.havk.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, 3 June 2001 at 1:22:07 -0500, Steve Price wrote: > On Sun, Jun 03, 2001 at 10:17:56AM +0930, Greg Lehey wrote: > >>> vinum >>> vinum -> resetconfig >>> vinum -> saveconfig >>> vinum -> stop >>> newfs /dev/da1s1e >>> newfs /dev/da2s1e >>> newfs /dev/da3s1e >>> newfs /dev/da4s1e >>> newfs /dev/da5s1e >> >> So far all of this is unnecessary. > > Right. I realize that now after having tried to no avail to get > vinum to forget about previous attempts that failed or crashed > this box. It essentially went like this. > > Try to create a RAID5 volume. Panic. Okay so take a couple of > steps back and create a RAID1 volume. That worked. Okay now > try to get vinum to forget about that configuration and do a > RAID10 configuration now. No dice. It refused to forget about > the previous RAID1 configuration. I did all of the above in > a number different orders and nothing worked. Not even redoing > the RAID1 configuration that had worked before. Hmm. I'd like to see the audit, and in particular the dump. This shouldn't panic the machine. >> Well, I'd start off by reading the section DEBUGGING PROBLEMS WITH >> VINUM in vinum(4), or http://www.vinumvm.org/vinum/how-to-debug.html, >> or both. Basically, I have almost no information to go on. What was >> the panic? > > Thanks for the reply Greg. I finally figured out how to make it > work. Basically I newfs'd the partitions, ran 'vinum create', and > then changed the type to vinum. newfs makes no difference. It just writes data to the disks, and Vinum ignores it. On the other hand, you *must* change the type to Vinum, though possibly it will work afterwards. It's not the way to do it, though. > This was the only way I could get vinum to not try to "add on" to my > previous failed attempts. It seems to work great so I'm going to > leave well enough alone until I get another box with a similar setup > that I can play with. Sounds reasonable. But when you do, please try to get me the info I ask for. > Is there a better way than 'vinum resetconfig' to get vinum to > forget everything you've told it about volumes, plexes, disks, ... > than resorting to what I did? Well, you can remove all objects. That's the preferred way. People abuse resetconfig so often that I'm thinking of removing it. > The nature of the description in the manpage that I read at least a > dozen times in the last couple of days lead me to believe this would > do what I wanted, but try as I might it didn't do what I expected > nor what I interpreted the manpage said it did. Well, without output I can't comment. > One thing that I failed to mention in the previous post was that > despite having run 'vinum resetconfig', 'vinum dumpconfig' still > returned information that looked like it was from previous attempts. Yup, with a minor difference: it shows a different magic number (NO VINO instead of IN VINO). This is a feature, not a bug: Vinum ignores such a config, but if you do it by accident, you can easily recover it. > Not setting the partition/slice type to vinum until after I ran > 'vinum create' seems to have worked around this. That has to be bogus. I wish I knew what's biting you, but I'm going to need a dump to find out. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010603175056.H85812>