Date: Wed, 20 Dec 2006 18:48:38 +0100 From: cpghost <cpghost@cordula.ws> To: freebsd-questions@freebsd.org Subject: Recovering bsdlabel / disklabel with scan_ffs Message-ID: <20061220174838.GA10443@epia-2.farid-hajji.net>
next in thread | raw e-mail | index | archive | help
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:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061220174838.GA10443>