Re: Applying scan_ffs output to disklabel?
On 8/30/21 7:53 AM, Danny Wilkins wrote: On August 29, 2021 11:06:03 PM EDT, gwes wrote: 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? It didn't get an OK. I believe the latest version is a minimal change to the current version. If there is interest from the core team I'll resubmit it and ask for criticism. geoff steckel
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 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: 1028160100759680 4.2BSD 2048 16384 8000 # / > >b:131604480101787840swap# none > >c:5848432640 unused > >d: 4112640233392320 4.2BSD 2048 16384 12958 # /usr > >e: 2056320237504960 4.2BSD 2048 16384 12958 # > > /usr/local > >f: 1028160239561280 4.2BSD 2048 16384 8000 # /var > >g: 16450560240589440 4.2BSD 2048 16384 12958 # /tmp > >h: 411264025704 4.2BSD 2048 16384 12958 # /home > >i:64197 63 unknown > >j: 5121522064260NTFS > >k:197406720261152640 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 >
Re: Applying scan_ffs output to disklabel?
On August 29, 2021 11:06:03 PM EDT, gwes wrote: >On 8/29/21 10:51 PM, Kenneth Gober wrote: >> On Sun, Aug 29, 2021 at 5:35 PM Jason Morris >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: 1028160100759680 4.2BSD 2048 16384 8000 # >/ >>b:131604480101787840swap# >none >>c:5848432640 unused >>d: 4112640233392320 4.2BSD 2048 16384 12958 # >/usr >>e: 2056320237504960 4.2BSD 2048 16384 12958 # >> /usr/local >>f: 1028160239561280 4.2BSD 2048 16384 8000 # >/var >>g: 16450560240589440 4.2BSD 2048 16384 12958 # >/tmp >>h: 411264025704 4.2BSD 2048 16384 12958 # >/home >>i:64197 63 unknown >>j: 5121522064260NTFS >>k:197406720261152640 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.
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 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: 1028160100759680 4.2BSD 2048 16384 8000 # / b:131604480101787840swap# none c:5848432640 unused d: 4112640233392320 4.2BSD 2048 16384 12958 # /usr e: 2056320237504960 4.2BSD 2048 16384 12958 # /usr/local f: 1028160239561280 4.2BSD 2048 16384 8000 # /var g: 16450560240589440 4.2BSD 2048 16384 12958 # /tmp h: 411264025704 4.2BSD 2048 16384 12958 # /home i:64197 63 unknown j: 5121522064260NTFS k:197406720261152640 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
Re: Applying scan_ffs output to disklabel?
On Sun, Aug 29, 2021 at 5:35 PM Jason Morris 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: 1028160100759680 4.2BSD 2048 16384 8000 # / b:131604480101787840swap# none c:5848432640 unused d: 4112640233392320 4.2BSD 2048 16384 12958 # /usr e: 2056320237504960 4.2BSD 2048 16384 12958 # /usr/local f: 1028160239561280 4.2BSD 2048 16384 8000 # /var g: 16450560240589440 4.2BSD 2048 16384 12958 # /tmp h: 411264025704 4.2BSD 2048 16384 12958 # /home i:64197 63 unknown j: 5121522064260NTFS k:197406720261152640 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
