Re: Applying scan_ffs output to disklabel?

On 8/29/21 10:51 PM, Kenneth Gober wrote:
> On Sun, Aug 29, 2021 at 5:35 PM Jason Morris <jasmor@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