Re: Recover partition table/FFS2 after overwrite?
On Thu, Sep 09, 2021 at 12:07:04PM +0200, Jan Stary wrote: > On Sep 08 16:31:36, thomaswindi...@thomaswindisch.net wrote: > > I mangaged to restore my drive using > > > > #fdisk -iy > > #disklabel -R > > #fsck > > > > Thanks Geoff and David. > > > > After reinstalling OpenBSD everything seems so be running fine. > > If you reinstalled anyway, why did you bother restoring? > I copied what I needed from /var and /usr to /home and only kept /home on the new install (by not setting a mount point for /home and latter adding it manually). > > Almost. > > > > When I now run grep I get this: > > > > $ grep > > warning: libc.so.96.0: minor version >= 1 expected, using it anyway > > ld.so: grep: can't load library 'libz.so.6.0' > > Killed > > > > I was previously running -current and I reinstalled -release 6.9. > > It seems that grep is a remnant of the old install? How come? > > > > On Wed, Sep 08, 2021 at 10:15:30PM -, Stuart Henderson wrote: > On 2021-09-08, Thomas Windisch wrote: > > I mangaged to restore my drive using > > > > #fdisk -iy > > #disklabel -R > > #fsck > > > > Thanks Geoff and David. > > > > After reinstalling OpenBSD everything seems so be running fine. > > Almost. > > > > When I now run grep I get this: > > > > $ grep > > warning: libc.so.96.0: minor version >= 1 expected, using it anyway > > ld.so: grep: can't load library 'libz.so.6.0' > > Killed > > > > I was previously running -current and I reinstalled -release 6.9. > > It seems that grep is a remnant of the old install? How come? > > If you "downgrade" you will need to clean up newer libraries, > things from packages, sometimes perl modules, etc. It is for this reason > that this is really not a supported thing to do. I did not downgrade via the "Upgrade" option but via the "Install" option. The installer running newfs should cleared all data in /usr, /var, and /, right? After rebooting I now cannot boot. The error I now get is: Abort trap > > -- > Please keep replies on the mailing list. > I guess I'll just backup /home to another drive and do clean reinstall.
Re: Recover partition table/FFS2 after overwrite?
On Sep 08 16:31:36, thomaswindi...@thomaswindisch.net wrote: > I mangaged to restore my drive using > > #fdisk -iy > #disklabel -R > #fsck > > Thanks Geoff and David. > > After reinstalling OpenBSD everything seems so be running fine. If you reinstalled anyway, why did you bother restoring? > Almost. > > When I now run grep I get this: > > $ grep > warning: libc.so.96.0: minor version >= 1 expected, using it anyway > ld.so: grep: can't load library 'libz.so.6.0' > Killed > > I was previously running -current and I reinstalled -release 6.9. > It seems that grep is a remnant of the old install? How come? > >
Re: Recover partition table/FFS2 after overwrite?
On 2021-09-08, Thomas Windisch wrote: > I mangaged to restore my drive using > > #fdisk -iy > #disklabel -R > #fsck > > Thanks Geoff and David. > > After reinstalling OpenBSD everything seems so be running fine. > Almost. > > When I now run grep I get this: > > $ grep > warning: libc.so.96.0: minor version >= 1 expected, using it anyway > ld.so: grep: can't load library 'libz.so.6.0' > Killed > > I was previously running -current and I reinstalled -release 6.9. > It seems that grep is a remnant of the old install? How come? If you "downgrade" you will need to clean up newer libraries, things from packages, sometimes perl modules, etc. It is for this reason that this is really not a supported thing to do. -- Please keep replies on the mailing list.
Re: Recover partition table/FFS2 after overwrite?
I mangaged to restore my drive using #fdisk -iy #disklabel -R #fsck Thanks Geoff and David. After reinstalling OpenBSD everything seems so be running fine. Almost. When I now run grep I get this: $ grep warning: libc.so.96.0: minor version >= 1 expected, using it anyway ld.so: grep: can't load library 'libz.so.6.0' Killed I was previously running -current and I reinstalled -release 6.9. It seems that grep is a remnant of the old install? How come?
Re: Recover partition table/FFS2 after overwrite?
On Mon, 2021-09-06 at 12:57 -0400, gwes wrote:
> This doesn't happen often but... maybe a page somewhere online?
http://akpoff.com/archive/2017/that_time_i_nuked_the_disklabel_and_recovered_the_disk.html
Cases are often slightly different depending on how you destroyed your
disk layout. But the gist of it is: If you have a backup of your
disklabel (and Thomas has, he posted it here) you're probably lucky.
The gist of it:
1. Create an image, so that you can always go back to step 0.
2. Re-create fdisk (MBR or GPT)
3a. Re-create disklabel layout, using
a) disklabel backup
b) scan_ffs
c) default installer layout or
d) other forensics tool
In the case I had recently ("fdisk -iy" on inner GPT partition) all ways
have worked, but step 2 would have been (almost) sufficient.
Because of corruptions, the disk was not usable 'as-is' any more as a
system disk afterwards, but this is probbly why you recommended re-
installing into the partitions. I just mounted and backuped the
partitions, did a fresh install and restored the data. Thanks to OpenBSD
this is not much of an act.
Re: Recover partition table/FFS2 after overwrite?
On 9/6/21 9:22 AM, Thomas Windisch wrote: I think I just overwrote my file system by using sd1 instead of sd2: # pv install69.img > /dev/rsd1c sd1 is softraid crypto device that holds the system partitions and data: $ df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/sd1a 1.9G143M1.7G 8%/ /dev/sd1f 843G734G 66.2G92%/home /dev/sd1b 9.7G 14.5M9.2G 0%/tmp /dev/sd1e 48.4G 40.8G5.2G89%/usr /dev/sd1d 19.4G 16.9G1.5G92%/var # disklabel sd1 # /dev/rsd1c: type: SCSI disk: SCSI disk label: SR CRYPTO duid: a1f07cee2aba3a55 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 121600 total sectors: 1953518528 boundstart: 64 boundend: 1953504000 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 4208960 64 4.2BSD 2048 16384 12960 # / b: 20980896 4209024 4.2BSD 2048 16384 12960 # /tmp c: 19535185280 unused d: 41945696 25189920 4.2BSD 2048 16384 12960 # /var e:104872320 67135616 4.2BSD 2048 16384 12960 # /usr f: 1781496064172007936 4.2BSD 8192 65536 52270 # /home The system is currently up and running. I'm not sure what has been overwritten. Possibly only sd1a /? Is it possible to recover from this without loosing access to the data in /home, /var, /usr? You may be in luck. Only the FDISK partition table, the BSD partition table, root, and /tmp are gone. This is what I'd do. Someone more knowledgeable could know better. Power the system down asap so that the system won't try to use the bad data. If you wrote onto the -encrypted- partition marked OpenBSD not the one holding it marked RAID in that drive's fdisk it's only painful. Install onto a -different- drive to make a rescue system. If you just nuked the -encrypted- partition, Go to part B. Otherwise, if you nuked the RAID partition: Part A: Boot the rescue system -c to disable softraid. Reset the fdisk partition table on the nuked drive. write a disklabel containing the RAID partition where the encrypted one lived. You must find someone who knows the softraid metadata. That person would have to tell you how to write -just- the metadata -only-. Reenable softraid on the rescue system. If necessary, reboot it. The encrypted disk should reappear. It has no structure. Use fdisk to establish the OpenBSD are. Use disklabel to reestablish your partitions. part B: On the encrypted partition: Use fdisk to make the OpenBSD area and disklabel to write the partition table. Mount and copy your precious data onto some other drive. Boot from bsd.rd Install on the partially recovered encrypted drive. The install program should recognize the rewritten partition table. Otherwise use a custom partition table matching your old one. Clear all the mount point names other than / and /tmp, That tells the install program to -not- newfs them. When rebooting at the end you may need to use -s to fix any custom configuration that needs to be done early. Fix the rest of your custom configuration once the system is up. Reinstall packages etc etc etc. With luck everything is back to normal. Little portable USB drives are $60 or so for 1 TB. Pretty large ones don't cost a lot more. This doesn't happen often but... maybe a page somewhere online? Geoff Steckel
Recover partition table/FFS2 after overwrite?
I think I just overwrote my file system by using sd1 instead of sd2: # pv install69.img > /dev/rsd1c sd1 is softraid crypto device that holds the system partitions and data: $ df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/sd1a 1.9G143M1.7G 8%/ /dev/sd1f 843G734G 66.2G92%/home /dev/sd1b 9.7G 14.5M9.2G 0%/tmp /dev/sd1e 48.4G 40.8G5.2G89%/usr /dev/sd1d 19.4G 16.9G1.5G92%/var # disklabel sd1 # /dev/rsd1c: type: SCSI disk: SCSI disk label: SR CRYPTO duid: a1f07cee2aba3a55 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 121600 total sectors: 1953518528 boundstart: 64 boundend: 1953504000 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 4208960 64 4.2BSD 2048 16384 12960 # / b: 20980896 4209024 4.2BSD 2048 16384 12960 # /tmp c: 19535185280 unused d: 41945696 25189920 4.2BSD 2048 16384 12960 # /var e:104872320 67135616 4.2BSD 2048 16384 12960 # /usr f: 1781496064172007936 4.2BSD 8192 65536 52270 # /home The system is currently up and running. I'm not sure what has been overwritten. Possibly only sd1a /? Is it possible to recover from this without loosing access to the data in /home, /var, /usr?
