From owner-freebsd-geom@FreeBSD.ORG Thu Sep 2 09:14:28 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3701316A4CE for ; Thu, 2 Sep 2004 09:14:28 +0000 (GMT) Received: from fmmailgate02.web.de (fmmailgate02.web.de [217.72.192.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B00243D54 for ; Thu, 2 Sep 2004 09:14:27 +0000 (GMT) (envelope-from ilsa.gold@web.de) Received: by fmmailgate02.web.de (8.12.6/8.12.6/webde Linux 0.7) with SMTP id i829EAF9031346 for freebsd-geom@freebsd.org; Thu, 2 Sep 2004 11:14:25 +0200 Received: from 62.180.31.25 by freemailng0701.web.de with HTTP; Thu, 02 Sep 2004 11:14:24 +0200 Date: Thu, 02 Sep 2004 11:14:24 +0200 Message-Id: <1255564800@web.de> MIME-Version: 1.0 From: =?iso-8859-1?Q? "Stefan=20Krau=DF" ?= To: freebsd-geom@freebsd.org Precedence: fm-user Organization: http://freemail.web.de/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: problem reattaching GBDE-encrypted slice X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2004 09:14:28 -0000 Hi all, like some other guys on this list (have seen this in the archive) I have a problem with an already running GBDE-encrypted slice. I used this slice for about 3 months without any problems. The slice (=ad0s3a) is about 38 GB in size and about 16 GB of this were free to use (see fdisk and bsdlabel output at the end of this mail). Yesterday I just put about 9-10GB of data on this slice and everything seems to work just fine. After rebooting this morning I'm not able anymore to attache the slice to gbde. I ente r the password, no error message or something similar appears but I get now *.bde-device file under /dev. The lock-file is dated to somewhere in Feb 23, and I'm absolutely sure that I entered the right password (just tried this about 50-times ;-)). Here are the outputs of a few relevant commands: ----- # uname -a FreeBSD maui.island.net 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23 20:45:55 GMT 2004 root@wv1u.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC i386 ----- # fdisk /dev/ad0 ******* Working on device /dev/ad0 ******* parameters extracted from in-core disklabel are: cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA)) start 63, size 19551042 (9546 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 19551105, size 19567170 (9554 Meg), flag 80 (active) beg: cyl 963/ head 15/ sector 1; end: cyl 919/ head 12/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 39118275, size 78091965 (38130 Meg), flag 0 beg: cyl 919/ head 13/ sector 1; end: cyl 567/ head 15/ sector 63 The data for partition 4 is: ----- # bsdlabel /dev/ad0s3 # /dev/ad0s3: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 78091949 16 unused 0 0 c: 78091965 0 unused 0 0 # "raw" part, don't edit ----- # bsdlabel /dev/ad0s2 # /dev/ad0s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 8735009 1048576 4.2BSD 2048 16384 28552 b: 1048576 0 swap c: 19567170 0 unused 0 0 # "raw" part, don't edit d: 9783585 9783585 4.2BSD 2048 16384 28552 Is there any advice you can give me? Best regards Stefan _______________________________________________________ WEB.DE Video-Mail - Sagen Sie mehr mit bewegten Bildern Informationen unter: http://freemail.web.de/?mc=021199 From owner-freebsd-geom@FreeBSD.ORG Thu Sep 2 13:44:50 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34ABF16A4CE for ; Thu, 2 Sep 2004 13:44:50 +0000 (GMT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E5A043D5D for ; Thu, 2 Sep 2004 13:44:49 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk ([195.176.4.36]) by phk.freebsd.dk (8.12.10/8.12.10) with ESMTP id i82DiU3v062745; Thu, 2 Sep 2004 13:44:47 GMT (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i82D4AYN001671; Thu, 2 Sep 2004 15:04:10 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "=?iso-8859-1?Q? " Stefan=20Krau=DF " ?=" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 02 Sep 2004 11:14:24 +0200." <1255564800@web.de> Date: Thu, 02 Sep 2004 15:04:10 +0200 Message-ID: <1670.1094130250@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-geom@freebsd.org Subject: Re: problem reattaching GBDE-encrypted slice X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2004 13:44:50 -0000 In message <1255564800@web.de>, =?iso-8859-1?Q? "Stefan=20Krau=DF" ?= writes: >Hi all, > >like some other guys on this list (have seen this in the archive) >I have a problem with an already running GBDE-encrypted slice. I >used this slice for about 3 months without any problems. The slice >(=ad0s3a) is about 38 GB in size and about 16 GB of this were free >to use (see fdisk and bsdlabel output at the end of this mail). >Yesterday I just put about 9-10GB of data on this slice and everything >seems to work just fine. After rebooting this morning I'm not able >anymore to attache the slice to gbde. I ente r the password, no >error message or something similar appears but I get now *.bde-device >file under /dev. The lock-file is dated to somewhere in Feb 23, and >I'm absolutely sure that I entered the right password (just tried >this about 50-times ;-)). This is weird. It sounds like the master key sector has been destroyed on the disk. I've been running with GBDE on my laptop since I wrote it and I have never seen anything like this, so I am somewhat convinced that it is not a bug in GBDE, but I am also not ruling it out. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Thu Sep 2 14:18:26 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6744D16A4CE for ; Thu, 2 Sep 2004 14:18:26 +0000 (GMT) Received: from fmmailgate03.web.de (fmmailgate03.web.de [217.72.192.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id D531F43D48 for ; Thu, 2 Sep 2004 14:18:25 +0000 (GMT) (envelope-from ilsa.gold@web.de) Received: by fmmailgate03.web.de (8.12.6/8.12.6/webde Linux 0.7) with SMTP id i82EINUQ014083; Thu, 2 Sep 2004 16:18:24 +0200 Received: from 62.180.31.25 by freemailng0707.web.de with HTTP; Thu, 02 Sep 2004 16:18:20 +0200 Date: Thu, 02 Sep 2004 16:18:20 +0200 Message-Id: <1256123024@web.de> MIME-Version: 1.0 From: =?iso-8859-1?Q? "Stefan=20Krau=DF" ?= To: " StefanKrauß " , "Poul-Henning Kamp" Precedence: fm-user Organization: http://freemail.web.de/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit cc: freebsd-geom@freebsd.org Subject: Re: problem reattaching GBDE-encrypted slice X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2004 14:18:26 -0000 Hi Paul, first of all thanks for your fast reply. > >like some other guys on this list (have seen this in the archive) > >I have a problem with an already running GBDE-encrypted slice. I > >used this slice for about 3 months without any problems. The slice > >(=ad0s3a) is about 38 GB in size and about 16 GB of this were free > >to use (see fdisk and bsdlabel output at the end of this mail). > >Yesterday I just put about 9-10GB of data on this slice and everything > >seems to work just fine. After rebooting this morning I'm not able > >anymore to attache the slice to gbde. I ente r the password, no > >error message or something similar appears but I get now *.bde-device > >file under /dev. The lock-file is dated to somewhere in Feb 23, and > >I'm absolutely sure that I entered the right password (just tried > >this about 50-times ;-)). > > This is weird. It sounds like the master key sector has been > destroyed on the disk. Is there a way to test this? Maybe some litte program to check? If it is a problem with the master key sector, is there a possibility to recover from that error? Best regards, Stefan _______________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 From owner-freebsd-geom@FreeBSD.ORG Thu Sep 2 14:21:02 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D420516A4CE for ; Thu, 2 Sep 2004 14:21:02 +0000 (GMT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26A1E43D69 for ; Thu, 2 Sep 2004 14:21:02 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk ([195.176.4.36]) by phk.freebsd.dk (8.12.10/8.12.10) with ESMTP id i82EKj3r063354; Thu, 2 Sep 2004 14:21:00 GMT (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i82EKiaY003612; Thu, 2 Sep 2004 16:20:44 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "=?iso-8859-1?Q? " Stefan=20Krau=DF " ?=" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 02 Sep 2004 16:18:20 +0200." <1256123024@web.de> Date: Thu, 02 Sep 2004 16:20:44 +0200 Message-ID: <3611.1094134844@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-geom@freebsd.org Subject: Re: problem reattaching GBDE-encrypted slice X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2004 14:21:02 -0000 In message <1256123024@web.de>, =?iso-8859-1?Q? "Stefan=20Krau=DF" ?= writes: >> This is weird. It sounds like the master key sector has been >> destroyed on the disk. > >Is there a way to test this? Maybe some litte program to check? trying to attach with gbde and the right passphrase and failing is a pretty good test. >If it is a problem with the master key sector, is there a possibility >to recover from that error? If you have a copy or if you have configured multiple keys -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Thu Sep 2 20:06:01 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E86F16A4CE for ; Thu, 2 Sep 2004 20:06:01 +0000 (GMT) Received: from afields.ca (afields.ca [216.194.67.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id E078843D53 for ; Thu, 2 Sep 2004 20:06:00 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (localhost.afields.ca [127.0.0.1]) by afields.ca (8.12.11/8.12.11) with ESMTP id i82K5vx7097580; Thu, 2 Sep 2004 16:05:57 -0400 (EDT) (envelope-from afields@afields.ca) Received: (from afields@localhost) by afields.ca (8.12.11/8.12.11/Submit) id i82K5u8B097579; Thu, 2 Sep 2004 16:05:56 -0400 (EDT) (envelope-from afields) Date: Thu, 2 Sep 2004 16:05:56 -0400 From: Allan Fields To: DOT Message-ID: <20040902200556.GG34157@afields.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline User-Agent: Mutt/1.4i cc: freebsd-geom@freebsd.org Subject: Can't reattach gbde slice [testing] X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2004 20:06:01 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 22, 2004 at 02:47:45PM +0200, DOT wrote: > God damn, it happen's again.. >=20 > Hi, > this time my passphrase works for few days, only few days. And I didn't > use any software that could cause this. I'm sure that it's not accident, > probably I'm doing something wrong so please point me where it is, > because restoring data again has no sense unless the problem is solved. I've created a 30GB test slice configured as above and I think I can reproduce under certain circumstances / after reboots, I will test it out further. > Durning installation of FreeBSD I've created 4 partitions: ad0s1 for > Windows, ad0s2 for Freebsd, ad0s3 for my encrypted home directory and > ad0s4 for future purposes. Didn't label ad0s3. > Then I've initialized encrypted partition (gbde init /dev/ad0s3 -i -L > /etc/gbde/ad0s3.lock) with one key, sector size 2048, filled with ^^^^^^^^^^^^ Can you indicate your number_of_keys parameter you are using in -i? Anyone using anything other than default 4? If using non-default please try to reproduce with number_of_keys set to 4. > Michal Bartkowiak Thanks, --=20 Allan Fields, AFRSL - http://afields.ca 2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541 --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQFBN30j90UNcjm0VUERAtwXAJ9ZuSv0XIGSJUGjDoauxz1QS9wANQCgt8KJ /0wL1cbJXt/EinTxaWAoKKs= =ks7l -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-geom@FreeBSD.ORG Fri Sep 3 12:11:34 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 085B716A4CE for ; Fri, 3 Sep 2004 12:11:34 +0000 (GMT) Received: from v05184.home.net.pl (v05184.home.net.pl [212.85.117.104]) by mx1.FreeBSD.org (Postfix) with SMTP id DEC0E43D1F for ; Fri, 3 Sep 2004 12:11:32 +0000 (GMT) (envelope-from kris@home.pl) Received: from bm.unizeto.pl (HELO kris) (kris@home@213.222.192.3) by matrix11.home.net.pl with SMTP; 3 Sep 2004 12:11:30 -0000 Message-ID: <00d701c491af$253ebf30$fe78a8c0@kris> From: =?iso-8859-2?Q?Krzysztof_Ciep=B3ucha?= To: Date: Fri, 3 Sep 2004 14:11:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: problems with GEOM_MIRROR X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 12:11:34 -0000 Hi, I am testing mirroring using GEOM_MIRROR and have found several a little bit strange behaviours. But first my configuration (in short): The server is using adaptec scsi controller with two scsi disks: ibm235# camcontrol devlist at scbus1 target 0 lun 0 (pass1,da0) at scbus1 target 1 lun 0 (pass2,da1) The kernel is compiled from fresh cvsup-ed 5.3BETA2 sources with statically added GEOM_LABEL and GEOM_MIRROR. On top of this disks I have put a labels using GEOM_LABEL: label/disk0 on da0 and label/disk1 on da1. Then I have made a mirror (GEOM_MIRROR) using those labels, with hardcoded providers: mirror/mirror0 using label/disk0 and label/disk1. On top of the mirror I have created a standard bsdlabel (with boot loader), set up filesystems and moved the whole system from the third disk using dump and restore. ibm235# bsdlabel /dev/mirror/mirror0 # /dev/mirror/mirror0: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 524288 0 4.2BSD 2048 16384 32776 b: 5191376 524288 swap c: 71096638 0 unused 0 0 # "raw" part, don't edit d: 524288 5715664 4.2BSD 2048 16384 32776 e: 524288 6239952 4.2BSD 2048 16384 32776 f: 64332398 6764240 4.2BSD 2048 16384 28552 So finally I have running system booting and running from mirror/mirror1: ibm235# cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/mirror/mirror0b none swap sw 0 0 /dev/mirror/mirror0a / ufs rw 1 1 /dev/mirror/mirror0e /tmp ufs rw 2 2 /dev/mirror/mirror0f /usr ufs rw 2 2 /dev/mirror/mirror0d /var ufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 The mirror is fully synchronized (at least I think it is): ibm235# geom mirror list Geom name: mirror0 Components: 2 Balance: split Slice: 4096 Flags: NONE SyncID: 3 ID: 993051015 Providers: 1. Name: mirror/mirror0 Mediasize: 36401478656 (34G) Sectorsize: 512 Mode: r5w5e1 Consumers: 1. Name: label/disk0 Mediasize: 36401479168 (34G) Sectorsize: 512 Mode: r5w5e2 State: ACTIVE Priority: 0 Flags: DIRTY, HARDCODED SyncID: 3 ID: 2288148496 2. Name: label/disk1 Mediasize: 36401479168 (34G) Sectorsize: 512 Mode: r5w5e2 State: ACTIVE Priority: 0 Flags: DIRTY, HARDCODED SyncID: 3 ID: 3740254788 Geom name: mirror0.sync Finally the list of problems: 1. After server restart the mirror is being rebuilding form the beginning, even if before restart it was fully synchronized. Here is a fragment from dmesg: Sep 3 07:30:47 ibm235 kernel: SMP: AP CPU #1 Launched! Sep 3 07:30:47 ibm235 kernel: GEOM_LABEL: Label for provider da0 is label/disk1. Sep 3 07:30:47 ibm235 kernel: GEOM_LABEL: Label for provider da1 is label/disk0. Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0 created (id=993051015). Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0: provider label/disk1 detected. Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0: provider label/disk0 detected. Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0: provider label/disk0 activated. Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0: provider mirror/mirror0 launched. Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0: rebuilding provider label/disk1. Sep 3 07:30:47 ibm235 kernel: Mounting root from ufs:/dev/mirror/mirror0a Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0: provider label/disk1 disconnected. Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0: rebuilding provider label/disk1 stopped. Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0: provider label/disk1 detected. Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0: rebuilding provider label/disk1. Sep 3 08:17:42 ibm235 kernel: GEOM_MIRROR: Device mirror0: rebuilding provider label/disk1 finished. Sep 3 08:17:42 ibm235 kernel: GEOM_MIRROR: Device mirror0: provider label/disk1 activated. 2. sysctl -b kern.geom.conftxt shows BSD labels like label/disk0a ... disk0f which shouldn't exist, should they? ibm235# sysctl -b kern.geom.conftxt 0 DISK da1 36401479680 512 hd 255 sc 63 1 LABEL label/disk1 36401479168 512 i 0 o 0 2 MIRROR mirror/mirror0 36401478656 512 3 BSD mirror/mirror0f 32938187776 512 i 5 o 3463290880 ty 7 3 BSD mirror/mirror0e 268435456 512 i 4 o 3194855424 ty 7 3 BSD mirror/mirror0d 268435456 512 i 3 o 2926419968 ty 7 3 BSD mirror/mirror0c 36401478656 512 i 2 o 0 ty 0 3 BSD mirror/mirror0b 2657984512 512 i 1 o 268435456 ty 1 3 BSD mirror/mirror0a 268435456 512 i 0 o 0 ty 7 0 DISK da0 36401479680 512 hd 255 sc 63 1 LABEL label/disk0 36401479168 512 i 0 o 0 2 BSD label/disk0f 32938187776 512 i 5 o 3463290880 ty 7 2 BSD label/disk0e 268435456 512 i 4 o 3194855424 ty 7 2 BSD label/disk0d 268435456 512 i 3 o 2926419968 ty 7 2 BSD label/disk0c 36401478656 512 i 2 o 0 ty 0 2 BSD label/disk0b 2657984512 512 i 1 o 268435456 ty 1 2 BSD label/disk0a 268435456 512 i 0 o 0 ty 7 2 MIRROR mirror/mirror0 36401478656 512 3 BSD mirror/mirror0f 32938187776 512 i 5 o 3463290880 ty 7 3 BSD mirror/mirror0e 268435456 512 i 4 o 3194855424 ty 7 3 BSD mirror/mirror0d 268435456 512 i 3 o 2926419968 ty 7 3 BSD mirror/mirror0c 36401478656 512 i 2 o 0 ty 0 3 BSD mirror/mirror0b 2657984512 512 i 1 o 268435456 ty 1 3 BSD mirror/mirror0a 268435456 512 i 0 o 0 ty 7 Does anybody have working configuration like this? Is there a bug in GEOM implementation, or it is a problem with my configuration. -- kris-at-home-dot-pl From owner-freebsd-geom@FreeBSD.ORG Fri Sep 3 12:52:23 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DEF816A4CE for ; Fri, 3 Sep 2004 12:52:23 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2AD343D1D for ; Fri, 3 Sep 2004 12:52:22 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id B7827AC969; Fri, 3 Sep 2004 14:52:20 +0200 (CEST) Date: Fri, 3 Sep 2004 14:52:20 +0200 From: Pawel Jakub Dawidek To: Krzysztof =?iso-8859-2?Q?Ciep=B3ucha?= Message-ID: <20040903125220.GP30151@darkness.comp.waw.pl> References: <00d701c491af$253ebf30$fe78a8c0@kris> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v4JVG24VLqw37Edn" Content-Disposition: inline In-Reply-To: <00d701c491af$253ebf30$fe78a8c0@kris> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-geom@freebsd.org Subject: Re: problems with GEOM_MIRROR X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 12:52:23 -0000 --v4JVG24VLqw37Edn Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 03, 2004 at 02:11:30PM +0200, Krzysztof Ciep=B3ucha wrote: +> Finally the list of problems: +>=20 +> 1. After server restart the mirror is being rebuilding form the beginnin= g, +> even if before restart it was fully synchronized. +> Here is a fragment from dmesg: +>=20 +> +> Sep 3 07:30:47 ibm235 kernel: SMP: AP CPU #1 Launched! +> Sep 3 07:30:47 ibm235 kernel: GEOM_LABEL: Label for provider da0 is +> label/disk1. +> Sep 3 07:30:47 ibm235 kernel: GEOM_LABEL: Label for provider da1 is +> label/disk0. +> Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0 created +> (id=3D993051015). +> Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0: provider +> label/disk1 detected. +> Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0: provider +> label/disk0 detected. +> Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0: provider +> label/disk0 activated. +> Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0: provider +> mirror/mirror0 launched. +> Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0: rebuilding +> provider label/disk1. +> Sep 3 07:30:47 ibm235 kernel: Mounting root from ufs:/dev/mirror/mirror= 0a +> Sep 3 07:30:47 ibm235 kernel: GEOM_MIRROR: Device mirror0: provider +> label/disk1 disconnected. Yes, I know this problem. It is fixed in -CURRENT. Could you get g_mirror.c, g_mirror.h and g_mirror_ctl.c files from HEAD branch and try it? --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --v4JVG24VLqw37Edn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBOGkEForvXbEpPzQRAvjzAJ9B8gsMcPyow/oQs76/I064i3xW+gCbBGGD 8jcUIv3AeUejWY/jNEI2KNU= =mEOq -----END PGP SIGNATURE----- --v4JVG24VLqw37Edn-- From owner-freebsd-geom@FreeBSD.ORG Fri Sep 3 19:28:48 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7129A16A4CE for ; Fri, 3 Sep 2004 19:28:48 +0000 (GMT) Received: from v00058.home.net.pl (data.pl [212.85.96.58]) by mx1.FreeBSD.org (Postfix) with SMTP id 86E9843D1D for ; Fri, 3 Sep 2004 19:28:47 +0000 (GMT) (envelope-from dot@data.pl) Received: from localhost (HELO nonSpace) (dot.data@home@127.0.0.1) by matrix01.home.net.pl with SMTP; 3 Sep 2004 19:28:42 -0000 Date: Fri, 3 Sep 2004 21:41:33 +0200 From: DOT To: Allan Fields Message-Id: <20040903214133.144779e2.dot@data.pl> In-Reply-To: <20040902200556.GG34157@afields.ca> References: <20040902200556.GG34157@afields.ca> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-geom@freebsd.org Subject: Re: Can't reattach gbde slice [testing] X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 19:28:48 -0000 On Thu, 2 Sep 2004 16:05:56 -0400 Allan Fields wrote: > Can you indicate your number_of_keys parameter you are > using in -i? Anyone using anything other than default 4? In both situations my device was initialized with number_of_keys set to 1 (one). > If using non-default please try to reproduce with number_of_keys > set to 4. Allright, this time I leave it unchanged and my drive works hard now. If something happens I'll definitely let You know. Despite I'm not sure that You should wait ;) Michal Bartkowiak From owner-freebsd-geom@FreeBSD.ORG Fri Sep 3 23:18:41 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C326716A4CE; Fri, 3 Sep 2004 23:18:41 +0000 (GMT) Received: from maui.ebi.ac.uk (maui.ebi.ac.uk [193.62.196.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8C4C43D4C; Fri, 3 Sep 2004 23:18:40 +0000 (GMT) (envelope-from kreil@ebi.ac.uk) Received: from puffin.ebi.ac.uk (puffin.ebi.ac.uk [193.62.196.89]) by maui.ebi.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id i83NIdF28852; Sat, 4 Sep 2004 00:18:39 +0100 (BST) Received: from puffin.ebi.ac.uk (kreil@localhost) by puffin.ebi.ac.uk (8.11.6/8.11.6) with ESMTP id i83NIcu05679; Sat, 4 Sep 2004 00:18:38 +0100 Message-Id: <200409032318.i83NIcu05679@puffin.ebi.ac.uk> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: "Vijay Kaul" , freebsd-fs@freebsd.org, freebsd-questions@freebsd.org, freebsd-geom@freebsd.org In-Reply-To: Your message of "Fri, 03 Sep 2004 18:05:14 CDT." X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Sep 2004 00:18:38 +0100 From: David Kreil X-EBI-Information: This email is scanned using www.mailscanner.info. X-EBI: Found to be clean X-EBI-SpamCheck: not spam, SpamAssassin (score=-8, required 5, HABEAS_SWE -8.00) cc: David Kreil Subject: Re: gbde blackening feature - how can on disk keys be "destroyed" thoroughly? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 23:18:42 -0000 Dear Vijay, > I guess I took this off the list. It's OT, in my oppinion. Oh. Anywhere more appropriate to send it to that you could suggest at all? Now also trying freebsd-geom - would that have been the better place to send this to to start with? > I don't know much of anything about data recovery. But, if you can recover > data under 20 layers of random writes or 20 iterations of 0s, then how > *can* you wipe a hard drive? Short, preferably, of setting fire to it :D Sigh, tricky, yes. Apparently wiping with >20 repeats of random noise does the trick (say from /dev/random or arc4random generated). The difficulty with modern file systems / operating systems / disk drives is actually getting the patterns written to the magnetic media. I'm writing to the list because both assessing whether there really is a risk and how to fix it requires quite a bot of knowledge that I lack, like knowing where to look in the gbde code (maybe I misunderstood?), or writing code that is disk driver/hardware caching aware and can hence force a flush. I'd be most grateful for any help or suggestions. With best regards, David. > > > > Hi, > > > >> From what I can see so far, they are simply overwritten with zeros - is > >> that > > right? If so, the blackening feature would be much weakend, as once can > > read > > up to 20 layers of data even under random data (and more under zeros). I > > would > > be most grateful for comments, or suggestions of where/how one could > > extend > > the code to do a secure wip of the key areas. Also, I know practically > > nothing > > of how I could to best get FreeBSD to physically write to disk > > (configurability of hardware cache etc permitting). > > > > With best regards, > > > > David. > > > >> > >> Hello, > >> > >> I was wondering whether someone knowledgable about gbde internals could > >> tell > >> me how the keys are being destroyed on request under the "blackening > >> feature". > >> Ideally, I'd like them to be overwritten with random data at least 20 > >> times > >> independently, but I suspect it may well be done in a different way. > >> I'd be > >> grateful for learning how the blackening works (and why!). > >> > >> With many thanks for your help in advance, > >> > >> David Kreil. > >> > > > > ------------------------------------------------------------------------ > > Dr David Philip Kreil ("`-''-/").___..--''"`-._ > > Research Fellow `6_ 6 ) `-. ( ).`-.__.`) > > University of Cambridge (_Y_.)' ._ ) `._ `. ``-..-' > > ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' > > www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' > > > > > > _______________________________________________ > > freebsd-questions@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to > > "freebsd-questions-unsubscribe@freebsd.org" > > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ > ------------------------------------------------------------------------ Dr David Philip Kreil ("`-''-/").___..--''"`-._ Research Fellow `6_ 6 ) `-. ( ).`-.__.`) University of Cambridge (_Y_.)' ._ ) `._ `. ``-..-' ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' From owner-freebsd-geom@FreeBSD.ORG Fri Sep 3 23:40:37 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D82916A4CE; Fri, 3 Sep 2004 23:40:37 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAD8B43D1F; Fri, 3 Sep 2004 23:40:36 +0000 (GMT) (envelope-from zettel@acm.org) Received: from [192.168.0.4] (bgp966574bgs.derbrn01.mi.comcast.net[68.41.108.205]) by comcast.net (sccrmhc13) with ESMTP id <2004090323403501600i43oce>; Fri, 3 Sep 2004 23:40:36 +0000 From: Len Zettel To: freebsd-questions@freebsd.org Date: Fri, 3 Sep 2004 19:41:18 -0400 User-Agent: KMail/1.6.2 References: <200409032318.i83NIcu05679@puffin.ebi.ac.uk> In-Reply-To: <200409032318.i83NIcu05679@puffin.ebi.ac.uk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409031941.18668.zettel@acm.org> cc: freebsd-fs@freebsd.org cc: David Kreil cc: freebsd-geom@freebsd.org cc: Vijay Kaul Subject: Re: gbde blackening feature - how can on disk keys be "destroyed" thoroughly? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 23:40:37 -0000 On Friday 03 September 2004 07:18 pm, David Kreil wrote: > Dear Vijay, > > > I guess I took this off the list. It's OT, in my oppinion. > > Oh. Anywhere more appropriate to send it to that you could suggest at all? > Now also trying freebsd-geom - would that have been the better place to > send this to to start with? > > > I don't know much of anything about data recovery. But, if you can > > recover data under 20 layers of random writes or 20 iterations of 0s, > > then how *can* you wipe a hard drive? Short, preferably, of setting fire > > to it :D > While i am not an expert in this area, I can not help but wonder--- Who are you worried about recovering the data, under what circumstances? My best guess is that recovering anything from even _one_ data over-write is going to require that the recoverer have physical posession of the drive and very sophisticated equipment indeed. That means they have to be some branch of a govermnment. If you are going to attract attention of that caliber there are likely a lot of other easier means of finding out what you are up to. Otherwise, a good hot fire ought to be pretty final even for the CIA. -LenZ- > Sigh, tricky, yes. Apparently wiping with >20 repeats of random noise does > the trick (say from /dev/random or arc4random generated). The difficulty > with modern file systems / operating systems / disk drives is actually > getting the patterns written to the magnetic media. > > I'm writing to the list because both assessing whether there really is a > risk and how to fix it requires quite a bot of knowledge that I lack, like > knowing where to look in the gbde code (maybe I misunderstood?), or writing > code that is disk driver/hardware caching aware and can hence force a > flush. > > I'd be most grateful for any help or suggestions. > > With best regards, > > David. > > > > Hi, > > > > > >> From what I can see so far, they are simply overwritten with zeros - > > >> is that > > > > > > right? If so, the blackening feature would be much weakend, as once can > > > read > > > up to 20 layers of data even under random data (and more under zeros). > > > I would > > > be most grateful for comments, or suggestions of where/how one could > > > extend > > > the code to do a secure wip of the key areas. Also, I know practically > > > nothing > > > of how I could to best get FreeBSD to physically write to disk > > > (configurability of hardware cache etc permitting). > > > > > > With best regards, > > > > > > David. > > > > > >> Hello, > > >> > > >> I was wondering whether someone knowledgable about gbde internals > > >> could tell > > >> me how the keys are being destroyed on request under the "blackening > > >> feature". > > >> Ideally, I'd like them to be overwritten with random data at least 20 > > >> times > > >> independently, but I suspect it may well be done in a different way. > > >> I'd be > > >> grateful for learning how the blackening works (and why!). > > >> > > >> With many thanks for your help in advance, > > >> > > >> David Kreil. > > > > > > ----------------------------------------------------------------------- > > >- Dr David Philip Kreil ("`-''-/").___..--''"`-._ > > > Research Fellow `6_ 6 ) `-. ( ).`-.__.`) > > > University of Cambridge (_Y_.)' ._ ) `._ `. ``-..-' > > > ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' > > > www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' > > > > > > > > > _______________________________________________ > > > freebsd-questions@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > > To unsubscribe, send any mail to > > > "freebsd-questions-unsubscribe@freebsd.org" > > > > -- > > Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ > > ------------------------------------------------------------------------ > Dr David Philip Kreil ("`-''-/").___..--''"`-._ > Research Fellow `6_ 6 ) `-. ( ).`-.__.`) > University of Cambridge (_Y_.)' ._ ) `._ `. ``-..-' > ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' > www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-geom@FreeBSD.ORG Fri Sep 3 23:56:38 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C57616A4CE; Fri, 3 Sep 2004 23:56:38 +0000 (GMT) Received: from ms-smtp-03-eri0.ohiordc.rr.com (ms-smtp-03-smtplb.ohiordc.rr.com [65.24.5.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BFBA43D4C; Fri, 3 Sep 2004 23:56:37 +0000 (GMT) (envelope-from vkaul@ma.rr.com) Received: from gogobera.ma.rr.com (dhcp024-160-209-216.ma.rr.com [24.160.209.216])i83NuUVd020712; Fri, 3 Sep 2004 19:56:30 -0400 (EDT) To: "Len Zettel" , freebsd-questions@freebsd.org References: <200409032318.i83NIcu05679@puffin.ebi.ac.uk> <200409031941.18668.zettel@acm.org> Message-ID: From: "Vijay Kaul" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Fri, 03 Sep 2004 18:55:47 -0500 In-Reply-To: <200409031941.18668.zettel@acm.org> User-Agent: Opera M2/7.54 (Win32, build 3869) X-Virus-Scanned: Symantec AntiVirus Scan Engine cc: freebsd-fs@freebsd.org cc: David Kreil cc: freebsd-geom@freebsd.org Subject: Re: gbde blackening feature - how can on disk keys be "destroyed" thoroughly? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 23:56:38 -0000 On Fri, 03 Sep 2004 19:41:18 -0400, Len Zettel wrote: > While i am not an expert in this area, I can not help but wonder--- > Who are you worried about recovering the data, under what > circumstances? My best guess is that recovering anything from > even _one_ data over-write is going to require that the recoverer have > physical posession of the drive and very sophisticated equipment > indeed. That means they have to be some branch of a govermnment. > If you are going to attract attention of that caliber there are likely a > lot > of other easier means of finding out what you are up to. Otherwise, a > good hot fire ought to be pretty final even for the CIA. > -LenZ- I used to work in a lab and a co-worker had be a submarier for the US. He said that one of their projects was to figure out how to best destroy CDs for the government. Supposedly the CDs were recoverable even after cross-shredding. They either decided that melting them over a "heatsink" (coffee mug) in a microwave (also makes a nice ash tray) or going at them with an acetaline torch was the final solution. From owner-freebsd-geom@FreeBSD.ORG Sat Sep 4 00:36:52 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87B9416A4CE; Sat, 4 Sep 2004 00:36:52 +0000 (GMT) Received: from maui.ebi.ac.uk (maui.ebi.ac.uk [193.62.196.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF76E43D48; Sat, 4 Sep 2004 00:36:50 +0000 (GMT) (envelope-from kreil@ebi.ac.uk) Received: from puffin.ebi.ac.uk (puffin.ebi.ac.uk [193.62.196.89]) by maui.ebi.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id i840alF08011; Sat, 4 Sep 2004 01:36:47 +0100 (BST) Received: from puffin.ebi.ac.uk (kreil@localhost) by puffin.ebi.ac.uk (8.11.6/8.11.6) with ESMTP id i840ahM15268; Sat, 4 Sep 2004 01:36:43 +0100 Message-Id: <200409040036.i840ahM15268@puffin.ebi.ac.uk> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: Len Zettel In-Reply-To: Your message of "Fri, 03 Sep 2004 19:41:18 EDT." <200409031941.18668.zettel@acm.org> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Sep 2004 01:36:43 +0100 From: David Kreil X-EBI-Information: This email is scanned using www.mailscanner.info. X-EBI: Found to be clean X-EBI-SpamCheck: not spam, SpamAssassin (score=-8, required 5, HABEAS_SWE -8.00) cc: freebsd-fs@freebsd.org cc: David Kreil cc: freebsd-geom@freebsd.org cc: freebsd-questions@freebsd.org cc: Vijay Kaul Subject: Re: gbde blackening feature - how can on-disk keys be "destroyed" thoroughly? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2004 00:36:52 -0000 Dear LenZ, > Who are you worried about recovering the data, under what circumstances? The value of the blackening feature should be that you can give away the drive and your password, say, under pressure by the [court|mafia|whoever], without compromising any confidential information on the drive. > My best guess is that recovering anything from > even _one_ data over-write is going to require that the recoverer have > physical posession of the drive and very sophisticated equipment > indeed. That means they have to be some branch of a govermnment. Hmm, I much doubt that. True, you need a clean room and a magnetic force microscope. Even standard data recovery firms like www.dataclinic.co.uk, however, can recover data under up to 8 overwrites. (NB: No affiliation or recommendation there.) Government agencies can go deeper (20x or possibly more but it gets increasingly more difficult). > If you are going to attract attention of that caliber there are likely a lot > of other easier means of finding out what you are up to. Sure, like pointing an antenna at my computer while its running ;-) I guess my main point is: If there is a blackening feature which is designed to give users peace of mind about disclosing their password under pressure, and it is known that data can be recovered underneath simple overwrites for a pack of $$ but that writing a random pattern, say 30x, makes the delete safe, I'd much argue in favour of doing the latter. As the areas are small, this should be really quick, too. The problem is getting the multiple overwrites out to the magnetic media, rather than them sitting somewhere in a cache buffer in computer or drive memory. > Otherwise, a good hot fire ought to be pretty final even for the CIA. Actually, the above firm specializes in "Track 0 damage, fire damage, flood damage, impact damage and overwritten data"... So, if a commercial enterprise can offer this, I don't think I'm unduly concerned. Depending on the country, dissolving the magnetic layer in acid or finely grinding it off are considered "final" for classified materials. Now, I'm not interested in an exercise of extreme paranoia. If overwritten keys can, however, easily be recovered then I'd consider this a relative weakness compared to all the sophisticated effort that has gone into the design of gbde and its encryption algorithms. My question hence remains, can someone more knowledgable than me maybe comment on whether I have misunderstood what gbde does, or else how the strength of the blackening could please be improved (i.e., how to do a 30x random wipe bypassing cache in a hardware independent manner)? With best regards, David. ------------------------------------------------------------------------ Dr David Philip Kreil ("`-''-/").___..--''"`-._ Research Fellow `6_ 6 ) `-. ( ).`-.__.`) University of Cambridge (_Y_.)' ._ ) `._ `. ``-..-' ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' From owner-freebsd-geom@FreeBSD.ORG Sat Sep 4 17:46:52 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03F0016A4CE for ; Sat, 4 Sep 2004 17:46:52 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-161-125.dclient.hispeed.ch [80.219.161.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E53943D39 for ; Sat, 4 Sep 2004 17:46:50 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:a17d:0:220:afff:fed4:dbcb]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i84Hkh401007 verified NO) for ; Sat, 4 Sep 2004 19:46:47 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i84HkgQ01006; Sat, 4 Sep 2004 19:46:42 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Sat, 4 Sep 2004 19:46:42 +0200 (CEST) Message-Id: <200409041746.i84HkgQ01006@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma References: <200408142223.i7EMNdY00919@Mail.NOSPAM.DynDNS.dK> <20040815184030.GD21307@afields.ca> <1092597931.18338.25.camel@zappa.Chelsea-Ct.Org> To: freebsd-geom@freebsd.org Subject: Re: GEOM and NetBSD compatibility question X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2004 17:46:52 -0000 [as usual, sorry for the delay in this reply, and as usual, keep replies to the list and I'll catch up later, thanks] Allan Fields wrote: > > a solution, and now I'm experiencing this again when trying to > > use my NetBSD partition under FreeBSD-CURRENT and GEOM. > Which, all things considered, isn't an entirely outlandish proposition. Works fine with 4.whatever... $ mount [ ... ] /dev/da0s1a on /DragonFly (ufs, local, read-only) /dev/da0s1g on /DragonFly/usr (ufs, local, read-only) /dev/da0s1f on /DragonFly/var (ufs, local, read-only) /dev/da0s2a on /NetBSD (ufs, local, read-only) /dev/da0s2e on /NetBSD/usr (ufs, local, read-only) /dev/da0s2f on /NetBSD/var (ufs, local, read-only) /dev/da0s3a on /FreeBSD-CURRENT (ufs, local, read-only) /dev/da0s3e on /FreeBSD-CURRENT/usr (ufs, local, read-only) /dev/da0s3f on /FreeBSD-CURRENT/var (ufs, local, read-only) [ ... ] No problem changing the mounts to read-write. I keep as much as possible read-only in order to reduce time in `fsck' after the inevitable panic. > > I've applied a hack (first proposed a couple years back) which > > allows GEOM to recognize the NetBSD ID. However, GEOM is getting > Can you email the patch (and/or post url to list)? I'll post it here as it's trivial. The entire extent of my hacks to GEOM source at the moment is as follows [cut-n-pasted so tab damage is the result] : cat /dist/src/FreeBSD6-src/source-hacks/sys/geom/geom_bsd.c-patch --- geom_bsd.c-ORIG Sat Feb 14 18:59:44 2004 +++ geom_bsd.c Tue May 11 18:56:01 2004 @@ -513,7 +513,8 @@ */ error = g_getattr("MBR::type", cp, &i); if (!error) { - if (i != 165 && flags == G_TF_NORMAL) + /* if (i != 165 && flags == G_TF_NORMAL) */ + if (i != 165 && i != 169 && flags == G_TF_NORMAL) break; error = g_getattr("MBR::offset", cp, &ms->mbroffset); if (error) This does little more than allow FreeBSD to treat NetBSD ID as one of its own. Without this, nothing shows up at all. > I think it should be possible to access both NetBSD and OpenBSD > labels/partitions from FreeBSD as GEOM is designed to accommodate > such layouts. Note too that my systems have all been built from FreeBSD-4, then changing the ID to 169, and I use the lowest common denominator of UFS1 filesystems everywhere. > out. All of the BSDs have diverged on disklabel support. Even > DragonFly now has some differences in how it handles labels (while > FreeBSD can currently read them still(?) it doesn't work the other > way around from my experience). Hm? This is news to me, as I've just installed DFly (cross-built under FreeBSD-4) into a disk created under FBSD-4, and I don't remember any problems accessing anything. (Unless I didn't mount anything else yet; need to check that) And indeed, I have no problem accessing DFly from FBSD-4 and vice versa. (There may be a long-standing hack I've had in FBSD-3/4 that allows this which is present in DFly and NetBSD -- can't say for sure.) I'm not sure what problems you may have had, but I have none so far. > > Here's what GEOM has to say about the NetBSD partition of my > > disk: > Can you fill this out as to which slices are which: > s1: FreeBSD > s2: NetBSD? > s3: ? > s4: ? > Or is the important point that s2 is the NetBSD label? Yeah, the most important thing is that s2 is devoted to NetBSD, but here's my `mount -F' fstab entry as seen from a FBSD-4 system, just so you know what I've put where and what I intend to do with everything: ## CVSup disk /dev/da0s1e /mnt ufs ro 0 0 ## work directories /dev/da0s4e /work ufs ro 0 0 ## source /dev/da0s4f /stand ufs ro 0 0 ## obj dirs and hacks /dev/da0s4g /stand/obj ufs ro 0 0 ## WAV and ogg files /dev/da0s4h /cdrom ufs ro 0 0 ## Home directories # /dev/da0s1h /usr/home ufs ro 0 0 ## New DragonFlyBSD /dev/da0s1a /DragonFly ufs ro 0 0 /dev/da0s1g /DragonFly/usr ufs ro 0 0 /dev/da0s1f /DragonFly/var ufs ro 0 0 ## NetBSD partition /dev/da0s2a /NetBSD ufs ro 0 0 /dev/da0s2e /NetBSD/usr ufs ro 0 0 /dev/da0s2f /NetBSD/var ufs ro 0 0 ## Another FreeBSD partition -CURRENT /dev/da0s3a /FreeBSD-CURRENT ufs ro 0 0 /dev/da0s3e /FreeBSD-CURRENT/usr ufs ro 0 0 /dev/da0s3f /FreeBSD-CURRENT/var ufs ro 0 0 s1, s3, and s4 have IDs 165; in order for NetBSD to see itself, s2 has ID 169. Now, as seen under FreeBSD-4, the NetBSD partition `disklabel' command is uninformative as it rejects those partitions which aren't within what it feels should be the limits. Seen under NetBSD, those partitions become visible again and allow me to access parts of the disk outside the boundaries of the NetBSD DOS-partition ID, which otherwise don't exist. Under my FreeBSD-4 (slightly modified): 16 partitions: # size offset fstype [fsize bsize bps/cpg] a: 524288 0 4.2BSD 1024 8192 26 # (Cyl. 0 - 32*) b: 1048576 524288 swap # (Cyl. 32*- 97*) c: 12578895 0 unused 0 0 # (Cyl. 0 - 782) e: 9961472 1572864 4.2BSD 2048 16384 102 # (Cyl. 97*- 717*) f: 1044559 11534336 4.2BSD 2048 16384 106 # (Cyl. 717*- 782*) As seen by NetBSD-current (the same disk slice): 16 partitions: # size offset fstype [fsize bsize cpg/sgs] a: 524288 100663290 4.2BSD 1024 8192 26 # (Cyl. 6266 - 6298*) b: 1048576 101187578 swap # (Cyl. 6298*- 6363*) c: 12578895 100663290 unused 0 0 # (Cyl. 6266 - 7048) d: 490232832 0 unused 0 0 # (Cyl. 0 - 30515*) e: 9961472 102236154 4.2BSD 2048 16384 102 # (Cyl. 6363*- 6983*) f: 1044559 112197626 4.2BSD 2048 16384 106 # (Cyl. 6983*- 7048) g: 10485760 157266980 4.2BSD 2048 16384 0 # (Cyl. 9789*- 10442*) h: 20971520 167752740 4.2BSD 2048 16384 0 # (Cyl. 10442*- 11747*) i: 262144 63 4.2BSD 1024 8192 26 # (Cyl. 0*- 16*) j: 10485760 65273919 4.2BSD 1024 8192 26 # (Cyl. 4063*- 4715*) k: 2097152 63176767 4.2BSD 2048 16384 107 # (Cyl. 3932*- 4063*) l: 24903611 75759679 4.2BSD 2048 16384 102 # (Cyl. 4715*- 6265) m: 20971520 136295460 4.2BSD 1024 8192 26 # (Cyl. 8484 - 9789*) n: 62914560 262207 4.2BSD 2048 16384 97 # (Cyl. 16*- 3932*) o: 524288 113242185 4.2BSD 1024 8192 26 # (Cyl. 7049 - 7081*) p: 301508572 188724260 4.2BSD 32768 65536 4664 # (Cyl. 11747*- 30515*) Note that the NetBSD label uses absolute offsets from the beginning of the disk, while that shown by FBSD4 uses offsets relative from the beginning of s2. The sizes of a,b,c,e, and f match; the offset shown in the NetBSD label should correspond to the byte-offset that my original message giving what GEOM had to say about the disk quoted. As the absolute offsets of s2g-s2p above seen in the NetBSD label are outside the boundaries of s2c, FBSD4 pretends they don't exist and refuses to display them. This works, as noted, under NetBSD to give me access to other parts of the disk that are not in the NetBSD slice. (I'll assume the g and h partition cpg values mean something that I don't know. Forget what they are. That might be an incompatibility I'm overlooking. I've seen no problems reading from these particular partitions so far.) > > da0s2 works fine for what would be da0s2a. Years ago when > > I tried this, the NetBSD swap partition turned out to be > > translated by GEOM into the NetBSD /usr and as a result, > > I've been wary of -current until now. > And I'd also be wary of unsing a NetBSD partition from FreeBSD, at > this point: it's not -current per se, but the differences in formats. > Have you looked at the NetBSD disklabel code for anything that > stands out? I have no problems with FreeBSD-4, and as I note, I can mount da0s2 as /NetBSD, but not da0s2a as /NetBSD. I point to the `start' (seen in my earlier message) that is different between the two -- even though it should be the same, as it is for the other s1/3/4 DOS partitions. > > I had tried a while back to hack in an absolute/relative > > offset toggle, but never was able to make all of GEOM > By toggle do you mean it can turn on/off with differing > disklabel ID or just manually? I hoped to get GEOM to understand that certain disklabels (FreeBSD) would be relative, while others (NetBSD) might be absolute. The trigger seemed to be the `d' partition which extended beyond the `c' partition boundaries. It wouldn't be manual or ID-dependent, because it seemed that upon tasting the label, GEOM seemed to decide which to use, but had no way to store that information for later access. As you can see from the numbers I posted earlier, da0s1 and da0s2 are absolute offsets, while da0s1* are all relative, and da0s2* are all absolute offsets. However, later accesses all assume da0s?* to be relative to da0s? Looking again through the code, it seems that geom_bsd.c has the concept of a rawoffset which is set to 0 if part of the disklabel oversteps its bounds, otherwise is what you would expect. But I can't see that it's used anywhere other than where it is set. Not that I'm familiar with the code. And I haven't looked deeply. And then, Paul Mather clarified: > > > It's a property of the NetBSD disklabel that the `d' partition > > > covers the whole disk. Additionally, I use the additional > > right > Well, mostly right. I believe most NetBSD ports treat the "c" partition > as covering the whole disk and only the i386 (and related?) port applies > this semantic to the "d" partition instead (due to historical > precedent?). Probably due to the (unique-to-?) i386 ability to have several DOS partitions / IDs on a drive. NetBSD itself does not have the i386-port-specific ability to distinguish the different DOS partitions. It only recognizes its own last time I looked into it with detail. For other Real Architectures without multiple DOS-partitions and IDs, there's no need to differentiate between the whole disk and the part of the disk devoted to NetBSD. In any case, for my i386 machines, the NetBSD `c' partition should be identical with what FreeBSD would see as `da0s2' in my case, and `d' would be `da0'. This is picking at nits, but I believe is the source of the problems between GEOM relative offsets and the on-disk absolute offsets -- most likely a dedicated NetBSD disk would not have this problem. And I suspect that if I were to manipulate an on-disk disklabel so that da0s1h were to be physically within the da0s4 boundaries, I'd see the same sort of problem. (As I note, I do that under NetBSD as a workaround for my convenience to access non-NetBSD areas) Once again, I doubt that there are gross incompatibilities between the on-disk disklabels or filesystems, as I have no problems accessing any of the filesystems of any other OS from FreeBSD-4, NetBSD, or DragonFlyBSD (UFS1, of course). Only the introduction of GEOM a couple years back broke my access to NetBSD from what-was-then -current. Going back a few days from that gave me access to NetBSD again. Read- only access would make me happy; at present I have none at all, except to da0s2a only when specified as da0s2 where it works, but obviously I can't do the same for s2b on up. thanks barry bouwsma From owner-freebsd-geom@FreeBSD.ORG Sat Sep 4 20:42:08 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BF1016A4CF for ; Sat, 4 Sep 2004 20:42:08 +0000 (GMT) Received: from v05184.home.net.pl (v05184.home.net.pl [212.85.117.104]) by mx1.FreeBSD.org (Postfix) with SMTP id 2435343D4C for ; Sat, 4 Sep 2004 20:42:07 +0000 (GMT) (envelope-from kris@home.pl) Received: from localhost (HELO ?81.219.131.10?) (kris@home@127.0.0.1) by matrix11.home.net.pl with SMTP; 4 Sep 2004 20:42:03 -0000 Message-ID: <413A28A5.4010902@home.pl> Date: Sat, 04 Sep 2004 22:42:13 +0200 From: =?ISO-8859-2?Q?Krzysztof_Ciep=B3ucha?= User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <00d701c491af$253ebf30$fe78a8c0@kris> <20040903125220.GP30151@darkness.comp.waw.pl> In-Reply-To: <20040903125220.GP30151@darkness.comp.waw.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-geom@freebsd.org Subject: Re: problems with GEOM_MIRROR X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2004 20:42:08 -0000 Pawel Jakub Dawidek wrote: > +> 1. After server restart the mirror is being rebuilding form the beginning, > +> even if before restart it was fully synchronized. > > Yes, I know this problem. It is fixed in -CURRENT. > Could you get g_mirror.c, g_mirror.h and g_mirror_ctl.c files from HEAD > branch and try it? > I have upgraded to 6-CURRENT, rebuild kernel and world. # uname -a FreeBSD krisbsd 6.0-CURRENT FreeBSD 6.0-CURRENT #1: Sat Sep 4 10:44:10 CEST 2004 root@krisbsd:/usr/obj/usr/src/sys/KRIS5 i386 sysctl -b kern.geom.conftxt still shows labels like da0a .. da0f, and the mirror is still starting synchronization after every restart. #dmesg GEOM_LABEL[0]: Label for provider da0 is label/disk0. GEOM_LABEL[1]: UFS2 file system detected on da0. GEOM_LABEL[0]: Label for provider da1 is label/disk1. GEOM_LABEL[1]: UFS2 file system detected on da1. GEOM_LABEL[1]: UFS2 file system detected on da0a. GEOM_LABEL[1]: UFS2 file system detected on da0c. GEOM_LABEL[1]: UFS2 file system detected on da0d. GEOM_LABEL[1]: UFS2 file system detected on da0e. GEOM_LABEL[1]: UFS2 file system detected on da0f. GEOM_MIRROR[1]: Creating device mirror1 (id=1132938933). GEOM_MIRROR[0]: Device mirror1 created (id=1132938933). GEOM_MIRROR[1]: Adding disk label/disk0 to mirror1. GEOM_MIRROR[1]: Disk label/disk0 state changed from NONE to NEW (device mirror1). GEOM_MIRROR[0]: Device mirror1: provider label/disk0 detected. GEOM_LABEL[1]: UFS2 file system detected on da1a. GEOM_LABEL[1]: UFS2 file system detected on da1c. GEOM_LABEL[1]: UFS2 file system detected on da1d. GEOM_LABEL[1]: UFS2 file system detected on da1e. GEOM_LABEL[1]: UFS2 file system detected on da1f. GEOM_MIRROR[1]: Adding disk label/disk1 to mirror1. GEOM_MIRROR[1]: Disk label/disk1 state changed from NONE to NEW (device mirror1). GEOM_MIRROR[0]: Device mirror1: provider label/disk1 detected. GEOM_MIRROR[1]: Using disk label/disk1 (device mirror1) as a master disk for synchronization. GEOM_MIRROR[1]: Device mirror1 state changed from STARTING to RUNNING. GEOM_MIRROR[1]: Disk label/disk1 state changed from NEW to ACTIVE (device mirror1). GEOM_MIRROR[0]: Device mirror1: provider label/disk1 activated. GEOM_MIRROR[1]: Disk label/disk0 state changed from NEW to SYNCHRONIZING (device mirror1). GEOM_MIRROR[0]: Device mirror1: provider mirror/mirror1 launched. GEOM_MIRROR[0]: Device mirror1: rebuilding provider label/disk0. GEOM_LABEL[1]: UFS2 file system detected on mirror/mirror1. GEOM_LABEL[1]: UFS2 file system detected on mirror/mirror1a. GEOM_LABEL[1]: UFS2 file system detected on mirror/mirror1c. GEOM_LABEL[1]: UFS2 file system detected on mirror/mirror1d. GEOM_LABEL[1]: UFS2 file system detected on mirror/mirror1e. GEOM_LABEL[1]: UFS2 file system detected on mirror/mirror1f. Mounting root from ufs:/dev/mirror/mirror1a GEOM_MIRROR[1]: Disk label/disk1 (device mirror1) marked as dirty. GEOM_LABEL[1]: UFS2 file system detected on mirror/mirror1e. GEOM_LABEL[1]: UFS2 file system detected on mirror/mirror1f. GEOM_LABEL[1]: UFS2 file system detected on mirror/mirror1d. <... and after synchronization finished...> GEOM_MIRROR[1]: Disk label/disk0 state changed from SYNCHRONIZING to ACTIVE (device mirror1). GEOM_MIRROR[0]: Device mirror1: rebuilding provider label/disk0 finished. GEOM_MIRROR[1]: Disk label/disk0 (device mirror1) marked as dirty. GEOM_MIRROR[0]: Device mirror1: provider label/disk0 activated.krisbsd# krisbsd# sysctl -b kern.geom.conftxt 0 DISK da1 2147483648 512 hd 255 sc 63 1 LABEL label/disk1 2147483136 512 i 0 o 0 2 MIRROR mirror/mirror1 2147482624 512 3 BSD mirror/mirror1f 1100176384 512 i 5 o 1047306240 ty 7 3 BSD mirror/mirror1e 268435456 512 i 4 o 778870784 ty 7 3 BSD mirror/mirror1d 268435456 512 i 3 o 510435328 ty 7 3 BSD mirror/mirror1c 2147482624 512 i 2 o 0 ty 0 3 BSD mirror/mirror1b 241999872 512 i 1 o 268435456 ty 1 3 BSD mirror/mirror1a 268435456 512 i 0 o 0 ty 7 0 DISK da0 2147483648 512 hd 255 sc 63 1 BSD da0f 1100176384 512 i 5 o 1047306240 ty 7 1 BSD da0e 268435456 512 i 4 o 778870784 ty 7 1 BSD da0d 268435456 512 i 3 o 510435328 ty 7 1 BSD da0c 2147482624 512 i 2 o 0 ty 0 1 BSD da0b 241999872 512 i 1 o 268435456 ty 1 1 BSD da0a 268435456 512 i 0 o 0 ty 7 1 LABEL label/disk0 2147483136 512 i 0 o 0 2 BSD label/disk0f 1100176384 512 i 5 o 1047306240 ty 7 2 BSD label/disk0e 268435456 512 i 4 o 778870784 ty 7 2 BSD label/disk0d 268435456 512 i 3 o 510435328 ty 7 2 BSD label/disk0c 2147482624 512 i 2 o 0 ty 0 2 BSD label/disk0b 241999872 512 i 1 o 268435456 ty 1 2 BSD label/disk0a 268435456 512 i 0 o 0 ty 7 2 MIRROR mirror/mirror1 2147482624 512 3 BSD mirror/mirror1f 1100176384 512 i 5 o 1047306240 ty 7 3 BSD mirror/mirror1e 268435456 512 i 4 o 778870784 ty 7 3 BSD mirror/mirror1d 268435456 512 i 3 o 510435328 ty 7 3 BSD mirror/mirror1c 2147482624 512 i 2 o 0 ty 0 3 BSD mirror/mirror1b 241999872 512 i 1 o 268435456 ty 1 3 BSD mirror/mirror1a 268435456 512 i 0 o 0 ty 7 krisbsd# any ideas? -- kris-at-home-dot-pl