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

Reply via email to