DD Rescue issue

T

Tintin

Hi,

I have an issue with a locked system based on freebsd on an intel NUC ( I don't know whats version is), the DD (NVME) crashed Friday (input/output error...)

I'm not new to linux based systems so i did a DDrescue copy on a brand new SSD with 99.96% rescued with systemrescue live.

Now when i boot on it it says ENTER FULL PATH for /bin/sh or press return etc.. when pressing return, it says that it can't find /bien/sh because Device is not configured (i'll can screen for full error soon)

I don't have a boot menu (it goes directly on FreeBSD logo for a while).

Is there somebody who knows how to repair it ?

Thank you
 
Oh okay, I thought it was.

So i did, it says the same things :

_secure_path : cannot stat /etc/login.conf : Device not configured
login_getclass : unknow class 'daemon'
can't exec /bin/sh for /etc/rc : Devis not configured
Enter fullpathname of shell or RETURN for /bin/sh:
 
...hard to tell.
Depending on your actual current situation there are several choices:

- you may take a look at the rescue disk to check if you got all your data rescued
(if it contains any data of any value, naturally there are backups, of course, right?)
then simply nuke it and start all over.

- you did the rescue by the dd-command? If so I presume the rescue disk is not of the exact same size as your toasted nvme.
Get another disk of the exact same size (best an identical disk).
Ensure it's really clean.
Then dd again from your rescue disk to that one.
Chances are good system will come up again only slightly damaged if even, if the damages on your nvme were not that bad.

- also you may start a live system (USB stick with FreeBSD installer image will do; just chose "Live" instead of "Install".
You may have at least be able to edit some files on your rescueDD, furthermore make a gpart show (and other things), to get more information for the current situation.
Otherwise it's a bit guessing, and try-and-error.

You may also run some tests about what or how big the damage is.
If the nvme is toast, there is data lost.
Also the rescue disk will of no much use then, because copying rubbish delivers rubbish.

But first things first.
 
i'm trying to mount the DD in a livefs, it asks for a passphrase, i think the DD is encrypted but i don't have the passphrase ...

i am googling for a solution to bypass it
 
It makes sense..

So, with some Bios manipulations, i think it was a keyfile for geli encryption, now i have :
Can't exec /bin/sh for /etc/rc : input/output error
Enter full pathname of shell or RETURN for/bin/sh,

typed /bin/sh then i have :

can't exec /bin/sh for single user : input/output error
 
Looks like /bin/sh may have been part of the 0.04% that was corrupt, or the 99.96% percent did succeed but captured corrupted files. Try /rescue/sh instead, maybe that still works.

In any case, I'd take the image as a file, reinstall a fresh new OS on the device and load the image (mdconfig(8)) to get your data off it. The OS is not important (you can reinstall that), it's your data that's important.
 
Tintin said:
i think it was a keyfile for geli encryption
Click to expand...
If the key can be got uncorrupted for sure, and if the encrypted partition is for sure also uncorrupted, or its copy is for sure exactly 1:1 byte-by-byte and uncorrupted,
then there is at least a theoretical chance to get access to that partition again; but you also need to have some knowledge about partitions, geli, the filesystem, and other stuff ...it's not a newbie's task.

But if any of those is not given, e.g. the encrypted partition has a single corrupted block:
Not a chance.

Anyway it's (always) a trade-off only you have to weigh up about
how many hours work you need to spent on this to get it fixed,
and how valuable the needed to be rescued data is, for what may no backups exist,
or to redo the lost work.
 
So,

For /rescue/sh : no such file or directory

I made that since :

-removed the nvme to be sure booting on the ssd usb cloned > Boot loop
- Booted on live usb, i could mount boot partition, i saw in loader.conf 3 lines : Boot_mute "YES", boot disk = "ada0p1" and a line initk=(lot of numbers)

So i understood that it wanted to boot on the nvme, supressed the 2 first lines, and now i'm stuck on freebsd screen
 
Tintin said:
boot disk = "ada0p1"
Click to expand...
in /boot/loader.conf ? :-/
Well if any then change it to /dev/nvd0p1 ....if this the partition to be booted.
but just comment that line would mean "no boot disk at all".
If I would do any editing within this at the moment, I'd recommend to place a
verbose_loading="YES"
boot_verbose="YES"
in it now,
because what you need at the moment is all the information you can get.

But I guess you mounted the EFI partition and tinkered within there.

But one step after the other.
First things first.
I see no need to edit anything within the bootloader yet.
That's step three at the earliest.

You are trying to boot a system that is obviously not coming up by its own anymore.
Before there can be done any repairs, first needed to be checked is
if there is anything left, that can be repaired, or accessed to, at all.

I guess your partition scheme on the nvme was GPT.
As I also guessed,
you made a backup of the nvme (nvd0?) to a rescue-copy (SDD/HDD?) disk with dd
One can do that. But there are some things one needs to know.
You can only produce a 1:1 working copy of a disk on another disk with dd
if the disks are exactly the same size,
and - of course - if the former disk was without failures.
Copying a corrupted disk does not fix the errors; especially not with dd.
If the SSD/HDD - the one you copied to - is larger as the nvme, than it's also not bootable, because with GPT the last GPT-Block has to close the last block of the drive.
But you could mount not corrupted partitions, and get at least access to your data,
if the damage of the former nvme was limited - that's what needed to be checked first.
And if, of course the according partition is not encrypted, or you are capable to get it decrypted.

So I recommend to get first more information on the situation.
Boot a live-system, neither the damaged, nor the copy of the damaged disk, because those are obviously not bootable anymore.
Then look at those disk.
Do at least some gpart show [/dev/diskname]
This way you figure out if there are even any partitions on the disks,
if there is anything on the disks at all,
or if they are toast (dd bravely also copys toast to toast.)

If the partition you want to get access to is encrypted,
but you don't have neither the passphrase, nor the key,
nothing could be done at all.
 
You must log in or register to reply here.
Back
Top