From owner-freebsd-geom@FreeBSD.ORG Mon Jul 5 20:21:43 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 683D016A4CE for ; Mon, 5 Jul 2004 20:21:43 +0000 (GMT) Received: from sdf.lonestar.org (ol.freeshell.org [192.94.73.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id C258F43D1F for ; Mon, 5 Jul 2004 20:21:42 +0000 (GMT) (envelope-from trampith@sdf.lonestar.org) Received: from sdf.lonestar.org (IDENT:trampith@otaku.freeshell.org [192.94.73.2]) by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id i65KLYA8009982; Mon, 5 Jul 2004 20:21:34 GMT Received: (from trampith@localhost) by sdf.lonestar.org (8.12.10/8.12.8/Submit) id i65KLWtN025594; Mon, 5 Jul 2004 22:21:32 +0200 (CEST) Date: Mon, 5 Jul 2004 22:21:32 +0200 (CEST) From: tthorsten@yahoo.de X-X-Sender: trampith@otaku.freeshell.org To: Allan Fields In-Reply-To: <20040705192618.GB74224@afields.ca> Message-ID: References: <20040705192618.GB74224@afields.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-geom@freebsd.org Subject: Re: Problem in attaching newly encrypted disk 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: Mon, 05 Jul 2004 20:21:43 -0000 On Mon, 5 Jul 2004, Allan Fields wrote: > Date: Mon, 5 Jul 2004 15:26:18 -0400 > From: Allan Fields > To: tthorsten@yahoo.de > Cc: freebsd-geom@freebsd.org > Subject: Re: Problem in attaching newly encrypted disk > > On Mon, Jul 05, 2004 at 07:31:55PM +0200, tthorsten@yahoo.de wrote: >>> Date: Mon, 5 Jul 2004 12:50:30 -0400 >>> From: Allan Fields >>> To: tthorsten@yahoo.de >>> Cc: freebsd-geom@freebsd.org >>> Subject: Re: Problem in attaching newly encrypted disk >>> >>> On Mon, Jul 05, 2004 at 06:26:34PM +0200, tthorsten@yahoo.de wrote: >>>> Hi, >>>> >>>> I have a serious problem after I have done the following steps: >>>> >>>> Initialized new encrypted disk with >>>> gbde init /dev/ad1s1c -i -L /etc/gbde/ad1s1c >>>> -> sector_size = 2048 >>>> -> one key >>>> >>>> Attached it to the kernel via >>>> gbde attach ad1s1c -l /etc/gbde/ad1s1c >>>> >>>> Created new filesystem with >>>> newfs -U /dev/ad1s1c.bde >>>> >>>> Mounted the filesystem with >>>> mount /dev/ad1s1c.bde /dsk >>>> >>>> Then I put all my private data onto the newly created encrypted disk and >>>> unmounted and detached it from kernel before halting the system. >>>> >>>> When I started the system again and tried to attach the disk again with >>>> gbde attach ad1s1c -l /etc/gbde/ad1s1c >>>> NOTHING HAPPENS! There will no /dev/ad1s1c.bde device there to mount. >>>> The Passphrase is correct! >>> >>> Hmm.. you're volume may be corrupted now, see below.. > > Before you assume so, maybe think about the password for a while. > Sometimes we can change passwords slightly depending on what hour > they were entered. > > You can't totally rule it out that you just didn't remember / type > correctly. > I first tried that. I created a list with now 146 entries and put it through gbde via the -p option. No success. I'm quite sure, that I typed it in correctly. I use the same one on my laptop and I typed it two times when initializing the disk. > > Closer examination of the usr.sbin/gbde code and some debugging could > narrow down where you are running out of luck during attach. Ok, sounds logical for me, but how to debug the process of attach the disk with gbde? Manpages don't show a switch for debugging and in /var/log there are no entries. > > >>>> What went wrong? Does anybody have an answer or is all my data lost? >>> >>> Simple answer: yes, and this is one of the risks with all encrypted >>> file systems. Probablly quite challenging to get it back absent >>> backups. > > >>>> I would be very happy, if anybody could help me with this. >>> >>> Is it possible you've written boot code on-top of the encrypted volume? >>> Those strings look to belong to boot loader. >>> >>> You probably shouldn't have used the raw partition for the encrypted >>> volume, >>> next time disklabel the disk and use /dev/ad1s1a . I don't know why you >>> want boot code on the second disk anyhow. >>> >> Hmm, seems really to be boot loader code. But I did not use fdisk or >> disklabel >> after creation of the encrypted disk. > > Maybe it isn't overwritten then and you just have boot code left-over > from when you originally labeled the disk.. unless something could > have over-writen, it's hard to think of other likely scenarios. > > >> Did not know that its better to not use the raw partition :-( > > Well, I guess it doesn't matter unless something assumes that it > can write over the first sectors containing your data. > > The good news is you still have your lock selector file (-L/-l). What can I do with it? Is it possible to rescue the data when I have the lock selector file? Thanks a lot for your support. Regards, Thorsten