On August 29, 2021 11:06:03 PM EDT, gwes <g...@oat.com> 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
I feel like that'd be good to have in base in general now that ffs2 is default.
Any reason the patch isn't in?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
