That might be helpful as sadly I do not have backups for this device. Could you share at your convenience?
On Sun, Aug 29, 2021, at 11:06 PM, gwes wrote: > On 8/29/21 10:51 PM, Kenneth Gober wrote: > > On Sun, Aug 29, 2021 at 5:35 PM Jason Morris <jas...@jasonmorris.co> wrote: > > > >> I'm in the process of recovering my drive (fat fingered dd and blew away > >> the partitions). I've obtained the following output from scan_ffs but not > >> sure how to apply this to recreate the disklabel. Running disklabel -R with > >> this output doesn't seem to work. > >> > >> fuguita# scan_ffs -lv sd2c > >> block 128673234 id a86900, 1d53400 size 30225408 > >> block 150903347 id 8,0 size 76481934 > >> block 475612813 id 502b55c2,800e9b02 size 1130083924 > >> block 587802509 id 502b55c2,800e9b02 size 1130083924 > >> block 867995213 id 502b55c2,800e9b02 size 1130083924 > >> block 1338443597 id 502b55c2,800e9b02 size 1130083924 > >> block 1638543507 id abbbeaf9, b4ab0641 size 472173501 > >> scan_ffs:_read: Invalid argument > >> > > According to the man page, scan_ffs will work only on FFS file systems, not > > FFS2. Since FFS2 > > is now the default, presumably scan_ffs wasn't able to find any file > > systems. If it had found > > something, it would have output one or more lines looking something like > > these: > > > > X: 524224 64 4.2BSD 2048 16384 1 # / > > X: 4194304 524288 4.2BSD 2048 16384 1 # /usr > > X: 1048576 4718592 4.2BSD 2048 16384 1 # /usr/local > > > > There should be a backup of your disklabel in > > /var/backups/disklabel.sd2.current (or sd0, or sd1, > > etc. as appropriate depending on how things were configured previously). > > If you have backups, > > the easiest thing to do is look through those backups to find this file. > > If you don't have backups, > > here is an example of what one of these disklabel files might look like; > > you might be able to find > > it on your disk just by reading blocks until you find it (assuming it's not > > encrypted): > > > > # /dev/rsd0c: > > type: SCSI > > disk: SCSI disk > > label: DELL PERC H700 > > duid: 26daa7a4492ed6e9 > > flags: > > bytes/sector: 512 > > sectors/track: 63 > > tracks/cylinder: 255 > > sectors/cylinder: 16065 > > cylinders: 36404 > > total sectors: 584843264 > > boundstart: 100759680 > > boundend: 584830260 > > drivedata: 0 > > > > 16 partitions: > > # size offset fstype [fsize bsize cpg] > > a: 1028160 100759680 4.2BSD 2048 16384 8000 # / > > b: 131604480 101787840 swap # none > > c: 584843264 0 unused > > d: 4112640 233392320 4.2BSD 2048 16384 12958 # /usr > > e: 2056320 237504960 4.2BSD 2048 16384 12958 # > > /usr/local > > f: 1028160 239561280 4.2BSD 2048 16384 8000 # /var > > g: 16450560 240589440 4.2BSD 2048 16384 12958 # /tmp > > h: 4112640 257040000 4.2BSD 2048 16384 12958 # /home > > i: 64197 63 unknown > > j: 51215220 64260 NTFS > > k: 197406720 261152640 4.2BSD 2048 16384 12958 # > > /var/postgresql > > > > Note that a 'normal' installation of OpenBSD will typically have a much > > smaller boundstart > > value, like 64. The system I took this sample from has both Windows and > > OpenBSD on > > it so the layout is a bit unusual. > > > > -ken > If there aren't sufficient backups I have a version of scan_ffs which > works on FFS2. > geoff steckel >
