Solved NVME screwed, zpool dataset error: How to access and safely recover data in nvd0p4 to another device.

Attachments

  • 17315648103526467777041654496753.jpg
    17315648103526467777041654496753.jpg
    1.4 MB · Views: 46
Try to create a directory in /tmp

mkdir /tmp/mnt
Then zpool import -R /tmp/mnt -o readonly=on zroot

I forget that the live usb is readonly, hopefully /tmp is not.
 
monwarez

I have external hard drive at da1 (fat32 with MBR, da1s1)

gpart destroy -F /dev/da1
gpart create -s mbr /dev/da1
gpart add -t fat32 /dev/da1
newfs_msdos -L FILES -F 32 /dev/da1s1

mount_msdosfs -u 1001 /dev/da1 /tmp/mnt1
 
ilovehoney said:
I'm getting cp: crown: *** : invalid argument
Click to expand...
That probably has something to do with the differences between ZFS and fat32 concerning allowable characters in a filename, or other file properties like permissions.
If the fs on da1 is going to be a temporary one, you could create a ZFS fs instead of fat32; you'll preserve all ZFS properties. Take into account that you have no redundancy for your data, as is the case for your laptop drive.
 
ilovehoney said:
monwarez

I'm getting cp: chown: *** : invalid argument

#cp -iprv /tmp/mnt/usr/home/my folder/tmp/mnt1/myfiles
Click to expand...
That is because FAT does not have any idea of owners and groups.
So this is by design, if you need to preserve these information you need to tar the data together.
 
Crivens said:
That is because FAT does not have any idea of owners and groups.
So this is by design, if you need to preserve these information you need to tar the data together.
Click to expand...
Crivens
be that case it may, how can one manage to get around "readonly" corrupted ssd drive and accomplish what you are suggesting.

+concisely put as your reply was, surely you've got something.
 
There is no getting around a readonly drive. You need to copy the data off it to some other media. You can't use zfs send because you can't create a snapshot so you will need to do dd, see below.

As it's a zpool, the first thing I'd try is boot FreeBSD from a large USB. Large in the sense that there's a small partition just containing FreeBSD + a few utilities from ports (ddrescue and dd_rescue). The rest of the USB would be empty. Now create a partition of the exact same size as the dead SSD's zpool. dd it using dd, ddrescue, or dd_rescue to the newly created partition on the USB. Try dd first. If it fails ddrescue and dd_rescue will try to ignore errors, resulting in a corrupted target pool. But a corrupted target pool is better than no pool.

This will only work if you know what you're doing and avoid mistakes. Any mistakes and you're in the perpetual catch up and recover from mistakes rabbit hole.

Personally, I maintain a bootable USB disk. It's used when recovering from serious problems, like this, plus it's used to restore from backups, allowing me to recreate any of my machines from backup. I also used it to copy my UFS system partitions (/, /usr, /var) and my zpool from my old legacy BIOS MBR laptop to my new UEFI GPT laptop, creating the necessary EFI partiton and copying the data from the old laptop's SSD to the current laptop's NVME SSD. A Swiss Army Knife bootable USB. You need a smidgen of this.

As you don't have such a setup, if you want to recover your data you will need to install FreeBSD on a USB disk or SSD, large enough for the above. Be patient. This will take some time and effort.
 
ilovehoney said:
Crivens
be that case it may, how can one manage to get around "readonly" corrupted ssd drive and accomplish what you are suggesting.

+concisely put as your reply was, surely you've got something.
Click to expand...
cd /media/where/target/is
tar zcf - /tmp/where/source/is | split -b 1500M

This is from memory, so you should read the man pages. This will give you a set of xaa xab xac ... files which are all 1.5GB in size so FAT32 will bit choke on them. For extraction you can cat them back into tar.
 
Crivens said:
cd /media/where/target/is
tar zcf - /tmp/where/source/is | split -b 1500M
Click to expand...

This only works if one has not altered the mountpoint property for any datasets. i.e.

Code: 
cwsys# zfs list cwsys/export
NAME           USED  AVAIL  REFER  MOUNTPOINT
cwsys/export  90.8G   224G  4.28G  /export
cwsys# 
cwsys# zfs get mountpoint cwsys/export
NAME          PROPERTY    VALUE       SOURCE
cwsys/export  mountpoint  /export     received
cwsys#

And legacy mounts in fstab:

Code: 
cwsys/var/mail                  /var/mail       zfs     rw 0 0

Otherwise you'll only tar the datasets mounted under the zpool's mountpoint.
 
cy@ said:
Otherwise you'll only tar the datasets mounted under the zpool's mountpoint.
Click to expand...
My assumption was that the pool was imported under a new root directory. Also, all of that was "from memory", so reading up on the man pages is strongly advised.
 
Crivens said:
My assumption was that the pool was imported under a new root directory. Also, all of that was "from memory", so reading up on the man pages is strongly advised.
Click to expand...
Even imported under a new directory, mountpoint properties are still honoured. This won't work without the extra effort of copying those mountpoints separately. The point is this will be painstakingly slow and detailed work.
 
cy@ said:
Personally, I maintain a bootable USB disk. It's used when recovering from serious problems, like this, plus it's used to restore from backups, allowing me to recreate any of my machines from backup. I also used it to copy my UFS system partitions (/, /usr, /var) and my zpool from my old legacy BIOS MBR laptop to my new UEFI GPT laptop, creating the necessary EFI partiton and copying the data from the old laptop's SSD to the current laptop's NVME SSD. A Swiss Army Knife bootable USB. You need a smidgen of this.
Click to expand...
I found lots of how-tos for making a Linux-based, swiss army knife, bootable USB stick. Can you point me to a how-to for doing so with FreeBSD, please? Thank you.
 
Bucky said:
I found lots of how-tos for making a Linux-based, swiss army knife, bootable USB stick. Can you point me to a how-to for doing so with FreeBSD, please? Thank you.
Click to expand...
There is no how-to that I know of. I've been working with computers for ~50 years (19 with mainframe, 31+ with UNIX). I cobbled up a disk myself.

I used to build rescue systems for Solaris. Same concept. At $JOB we have a rescue VM. We put the VM into a VLAN, PXE boot the affected system and repair. One could also do this with FreeBSD. My network at home isn't that big so, a rescue USB is just fine.

What you need to do is install onto a USB instead of an internal disk, or clone your FreeBSD O/S (I did this). Then, install some ports. Keep the rest of the USB disk "empty." I maintain backups on the remainder of the disk; in the worst case I can use it to restore my laptop or servers downstairs (using an additional disk for backups).

The other thing I do is on my servers downstairs & previous laptop (haven't set this up on my current laptop yet), is install FreeBSD on a second partition. Should the first partition fail to boot, simply boot the second partition. Data and /usr/local is in a third partition (ZFS). I can use the base system and the tools on the third partition to rescue the primary partition.

As a developer there are times something I'm working on results in an unbootable system. I've learned over the years to have many layers of belt and suspenders to avoid getting into a pickle.

There is no how-to for FreeBSD. Someone needs to write it. I would except I have way too much other FreeBSD work on my plate.
 
cy@ said:
There is no how-to that I know of. I've been working with computers for ~50 years (19 with mainframe, 31+ with UNIX). I cobbled up a disk myself.

What you need to do is install onto a USB instead of an internal disk, or clone your FreeBSD O/S (I did this). Then, install some ports. Keep the rest of the USB disk "empty." I maintain backups on the remainder of the disk; in the worst case I can use it to restore my laptop or servers downstairs (using an additional disk for backups).

There is no how-to for FreeBSD. Someone needs to write it. I would except I have way too much other FreeBSD work on my plate.
Click to expand...
Thank you and understood. The second paragraph may point the way!
 
Assuming dead SSD stuck on readonly...I'm not sure what to make of that. (out of my league)
if data can be copied off it, then why shouldn't it allow for say write or specifically format the drive without possible hazard.
 
Crivens

I tried to force install new version in the same ssd (presumably dead, stuck on readonly),

Error:gpart
gpart: Operation not permitted

well the drive isn't encrypted,
maybe it's just safety factor concern or zfs redundancy at work,

can I just wipe the whole disk and install a new filesystem? what prevents from write?

how would you to play it out?
 
You must log in or register to reply here.
Back
Top