From ady@warpnet.ro  Sun Sep 29 08:39:56 2002
Return-Path: <ady@warpnet.ro>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5AD5D37B404; Sun, 29 Sep 2002 08:39:56 -0700 (PDT)
Received: from ady.warpnet.ro (ady.warpnet.ro [217.156.25.2])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id C3DC243E65; Sun, 29 Sep 2002 08:39:53 -0700 (PDT)
	(envelope-from ady@warpnet.ro)
Received: from x.warpnet.ro ([217.156.25.200])
	by ady.warpnet.ro (8.9.3/8.9.3) with ESMTP id SAA22233;
	Sun, 29 Sep 2002 18:39:36 +0300 (EEST)
	(envelope-from ady@warpnet.ro)
Received: from x.warpnet.ro (localhost [127.0.0.1])
	by x.warpnet.ro (8.12.6/8.12.6) with ESMTP id g8TFYM6T024779;
	Sun, 29 Sep 2002 18:34:22 +0300 (EEST)
	(envelope-from ady@warpnet.ro)
Received: (from ady@localhost)
	by x.warpnet.ro (8.12.6/8.12.6/Submit) id g8TFYMn1024778;
	Sun, 29 Sep 2002 18:34:22 +0300 (EEST)
Message-Id: <200209291534.g8TFYMn1024778@x.warpnet.ro>
Date: Sun, 29 Sep 2002 18:34:22 +0300 (EEST)
From: Adrian Penisoara <ady@freebsd.ady.ro>
Reply-To: Adrian Penisoara <ady@freebsd.ady.ro>
To: FreeBSD-gnats-submit@freebsd.org
Cc: Greg Lehey <grog@freebsd.org>
Subject: Starting Vinum again while active corrupts the configuration
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         43475
>Category:       kern
>Synopsis:       Starting Vinum again while active corrupts the configuration
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    grog
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Sep 29 08:40:02 PDT 2002
>Closed-Date:    Mon Jun 02 21:57:56 PDT 2003
>Last-Modified:  Mon Jun 02 21:57:56 PDT 2003
>Originator:     Adrian Penisoara
>Release:        FreeBSD 4.7-PRERELEASE i386
>Organization:
>Environment:

FreeBSD yoda.warpnet.ro 4.7-PRERELEASE FreeBSD 4.7-PRERELEASE #0: Tue Sep 17 01:
12:06 EEST 2002     ady@yoda.warpnet.ro:/usr/src/sys/compile/YODA  i386

FreeBSD sauron.warpnet.ro 4.6.2-RELEASE FreeBSD 4.6.2-RELEASE #0: Wed Aug 14 21:
23:26 GMT 2002     murray@builder.freebsdmall.com:/usr/src/sys/compile/GENERIC  
i386

  Both systems have Adaptec aic78xx SCSI controllers (ahc(4)) and SCSI disks,
vinum is started and has at least one volume configured and up for the /usr
partition.

  Yoda is SMP (2x P3 450Mhz) and sauron is UP (PPro 200Mhz). If further info
is needed please let me know.

>Description:

  Running "vinum start" while the Vinum kld/daemon is already running and
configured blows up the drives configuration and even produces a panic with
SMP kernels.

>How-To-Repeat:

  While in multiuser and Vinum is already started and configured run
"vinum start" from the command line.

  Or: have Vinum started and configured in multiuser mode then shutdown
the system in single user (with "init 1"), wait for the shell prompt and
exit back to multiuser (with "exit" or "^D").

  Either way you should get a corrupted vinum configuration by now (usually
the drive/disk labels will get corrupted or deleted) or, even worse, your
system will panic (with SMP kernels).


>Fix:

  Workaround: force a "vinum stop" before starting Vinum at bootup.

--- usr/src/etc/rc      Thu May  9 20:39:01 2002
+++ etc/rc      Sat Sep 28 00:51:12 2002
@@ -122,6 +122,7 @@
 
 case ${start_vinum} in
 [Yy][Ee][Ss])
+       vinum stop
        vinum start
        ;;
 esac


  However the offendig bug should be fixed instead of appealing to workarounds.

 Adrian Penisoara
 Ady (@freebsd.ady.ro)

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->grog 
Responsible-Changed-By: schweikh 
Responsible-Changed-When: Thu Oct 3 05:18:15 PDT 2002 
Responsible-Changed-Why:  
Over to maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=43475 
State-Changed-From-To: open->closed 
State-Changed-By: grog 
State-Changed-When: Mon Jun 2 21:57:30 PDT 2003 
State-Changed-Why:  
Was already closed; there seems to be a problem with GNATS. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=43475 
>Unformatted:

Greg Lehey, 2 May 2003

This problem was caused by reinitializing already initialized drives.
Revision 1.83 of vinumio.c should fix it.

PR closed.

