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
> 

Reply via email to