From owner-freebsd-questions@FreeBSD.ORG Wed Dec 20 18:19:38 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B90216A407 for ; Wed, 20 Dec 2006 18:19:38 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9638443CA0 for ; Wed, 20 Dec 2006 18:19:37 +0000 (GMT) (envelope-from cpghost@cordula.ws) Received: from epia-2.farid-hajji.net (epia-2 [192.168.254.11]) by fw.farid-hajji.net (Postfix) with ESMTP id 63D9FDD530; Wed, 20 Dec 2006 18:47:35 +0100 (CET) Date: Wed, 20 Dec 2006 18:48:38 +0100 From: cpghost To: freebsd-questions@freebsd.org Message-ID: <20061220174838.GA10443@epia-2.farid-hajji.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Recovering bsdlabel / disklabel with scan_ffs X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 18:19:38 -0000 This is not a question, just for the archives if someone encountered a similar problem. Perhaps there's an easier way to recover a lost bsdlabel / disklabel though... While trying to rip a DVD with sysutils/vobcopy on 6.2-RC1, the system suddenly froze and could not reboot anymore. Not even the boot loader would come up after this. After swapping disks (putting a brand new FreeBSD 6.2-RC1 HDD as primary and the previous disk as secondary), only /dev/ad3s1 slice would appear, but no more /dev/ad3s1a, /dev/ad3s1d, ... partitions. Running # fdisk /dev/ad3 showed inconsistant (overlapping etc...) results for all slices as well, instead of the usual output of a fully dedicated disk, which should have looked like this: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 156360582 (76347 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 10/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: Obviously, the boot sector has been badly damanged. After restoring the partition table (allocating whole disk to FreeBSD-slice), and adding the BootMgr using /usr/sbin/sysinstall, # bsdlabel /dev/ad3s1 still didn't show the old partitions. Uh-oh. Bad news: no backups, no backup or printout of bsdlabel; and I didn't exactly remember the size and layout of the partitions on that machine. Enters /usr/ports/sysutils/scan_ffs. Calling: # scan_ffs /dev/ad3s1 showed lines like these: ufs2 at 0 size 262144 mount / time Sat Apr 10 01:08:46 2004 ufs2 at 5242880 size 4194304 mount /usr time Sat Apr 10 01:08:57 2004 ... Wonderful! There's a catch here: while the offsets (at ...) are the ones to add when editing the bsdlabel (bsdlabel -e /dev/ad3s1), the sizes aren't (the partitions wouldn't fsck -n). In fact, I had to use (size*4) here, e.g.: # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1048576 0 4.2BSD 2048 16384 8 b: 4194304 1048576 swap c: 156360582 0 unused 0 0 # "raw" part, don't edit d: 16777216 5242880 4.2BSD 2048 16384 28552 e: 16777216 22020096 4.2BSD 2048 16384 28552 [...] Obviously, this had something to do with fsize being 2048 by newfs defaults (and not 512): size*2048 bytes blocks = (size*4)*512 bytes blocks Second catch: If you can't remember the SLICE coordinates, you could run scan_ffs on the raw disk with: # scan_ffs /dev/ad3 instead of # scan_ffs /dev/ad3s1 but all offsets would be off-by-(offset-of-the-slice), e.g.: ufs2 at 63 size 262144 mount / time Sat Apr 10 01:08:46 2004 (note: 63 instead of 0; 63 was start offset of the FreeBSD slice). There's another catch: GBDE encrypted partitions can't (for obvious reasons) be detected with scan_ffs. As long as you don't have two contiguous GBDE partitions, it's possible to infer offset and size from the surrounding partitions (I was lucky enough to have such a friendly layout on this machine: one GBDE partitions in the middle of the slice, and another one at the end). Fortunately, and thanks to scan_ffs and some head-scratching, I was able to restore the whole system (and all user-data), with one notable exception: fsck choked and quit on the filesystem holding /usr/local with a message like: cannot alloc 553234321 bytes for inostathead Mounting that filesystem read-only showed that there were no valuable data in there that couldn't be recreated by newfs and recompiling all ports. To summarize: scan_ffs is a real life saver, but: * Don't put two (or more) encrypted partitions side-by-side * Remember to scale the size output of scan_ffs (I had to x 4) * Infer missing information (size/offset of swap and encrypted partitions) from surrounding partitions if possible. * Back up the output of: # fdisk /dev/ad0 (and other disks) # bsdlabel /dev/ad0s1 (and other FreeBSD slices) and GBDE/GEOM keys somewhere else. * Don't be lazy backing up valuable data... ;-) scan_ffs is such an incredibly useful emergency tool, it should really be part of the fixit and freesbie CDs... ;) Good luck! Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/