Re: Applying scan_ffs output to disklabel?

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 <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
>