General NAS-Central Forums

Welcome to the NAS community
It is currently Sun Sep 24, 2017 1:33 am

All times are UTC




Post new topic Reply to topic  [ 36 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Fri Feb 06, 2009 8:19 pm 
Offline

Joined: Fri Feb 06, 2009 7:49 pm
Posts: 16
Hi all

I need a little bit of help. The short version is that I'm trying to figure out how to put the data back together from the two disks in an Ethernet Big Disk. The long version follows:

I'm attempting to recover data from a dead Ethernet Big Disk for somebody. Both 500GB drives look OK, but the case just seems dead. I attached the drives to my system and saw that one has a partition table, with the first partition containing the extended partitions 5-9, the embedded Linux OS on ext3 partitions 8 and 9, and the second partition with an XFS header. So far so good. However, the second disk does not appear to have a partition table. It is all zeroes up until block 1006592, which looks like another XFS header.

When I first saw all of those partitions on the first disk, I was hoping I'd be lucky and that the embedded OS would use md or something else easy and that I could just plug both disks into a GNU/Linux host and be on my way. However, the lack of partition table and the long run of zeroes on the second disk disturbs me. I've recovered data from various Big Disks whose cases have failed in the past — depending on the model I've found that the disks have been either spanned, or striped with a stripe size of 128kiB (older models) or 256kiB (some newer ones). In those cases, when the disks were working normally, recovery was as simple as concatenating the two disk images or interleaving them with the appropriate stripe size, then mounting the reconstructed image. However, I'm not sure how to put the two halves of the XFS volume back together — both disks appear to contain the beginning of an XFS volume, but at different offsets (partition 2 on the first disk starts at block 2008125, the XFS header on the second disk starts at block 1006592). The different start points (and hence different sizes, since the physical disks are both the same size) suggest to me that it's probably either concatenated, or two independent volumes, since it would be weird to stripe two different sized pieces together. xfs_check segfaults when I try to run it on the XFS partition on the first disk, which won't mount because the superblock can't be found or is invalid. I'm in the middle of imaging the two disks to try to combine the two xfs halves in a few different ways, but if anybody here has any pointers on how the disk puts the data together when it's actually working correctly, it would be much appreciated if you could lead me in the right direction.

Also, just to put my mind at rest, people who have opened your Ethernet Big Disks: is the second disk supposed to have a partition table? Do you have what appears to be an XFS volume starting at the same offset? Any help here would be greatly appreciated.

Thanks,

Daniel


Top
 Profile  
 
PostPosted: Sat Feb 07, 2009 1:31 pm 
Offline

Joined: Fri Feb 06, 2009 7:49 pm
Posts: 16
Never mind -- I figured it out.

For anybody else who might be trying to do the same thing, what I did was to concatenate the second partition of the first disk and the whole of the second disk together as a single image, then mount that image via loopback. The filesystem was slightly damaged, probably due to intermittent failures of the case during use leading up to the case finally not working at all, but running xfs_repair seems to have taken care of the problems and the data on the disk image looks good.


Top
 Profile  
 
PostPosted: Sat Feb 28, 2009 11:20 pm 
Offline

Joined: Sat Feb 28, 2009 10:29 pm
Posts: 2
Could you or someone else recommend a solution for me?

LaCie Ethernet Big Disk 1TB, dies (clicking sounds from within, no recognition on either 100BT or USB).
About 700 GB of data down the toilet. I cracked it open, took out the disks and threw them into my desktop (WinXP). Drives spun up and seemed fine. That's where I made the mistake of trying to rebuild the RAID. Didn't work (obviously, since the volume is formatted under Linux, as I learned later). Got RAID Reconstructor SW. For that to work I had to delete the RAID array I created because that app tries to put together 2 drives when they are not arranged in a HW RAID array. No dice. At that point the original RAID configuration was probably lost. Tried a couple other things with no progress. Got another known good EBD box, same as mine, swapped out the drives, no pulse. swapped out just the second drive to see if I could get the data off the tail end of the JBOD (assuming it is JBOD), but nooo... Even though the drive is still recognized (OS being on the first drive of the JBOD) the logical volume doesn't work and no data can be recovered.
At this point I don't care to re-build the EBD so much as I want to get my stuff off this doomed array. The good LaCie box could not recover it. Nothing that I could run on my WinXP box could recover it (I ran apps that can see EXT2/3 partitions and/or analyse raw HD data).
I don't have a Linux box and I am a noob in Linux. I know there are tools out there for getting raw data off a drive even after it's been formatted (which mine haven't - they lost the boot sectors). Assuming the original array was JBOD, the 2 drives should have my data contiguously, not even striped accross them, so if I get the right tool I should be able to copy it off.
The big question is - what is the right tool and how can it be used to get the data off these darn drives?
I am even considering setting my desktop as a dual boot machine with Ubuntu, but I would need step-by-step instructions on what to do after the installation is complete...
So at this point, I have 1 good EBD complete with a working set of 2 500GB drives arranged the same exact way as my original one was (down to the share names and list of users and passwords) and the gutted original EBD box with a suspect power supply, a suspect controller card and 2 raped 500GB drives with about 700 GB of stuff I am dying to get back but no good boot sector. I got a Seagate utility that can copy a drive sector by sector, but what I need (I am guessing) is a way to copy just the boot sector from the 2 good drives to the 2 raped drives. Would that work??? Anyone know how to do that???


Top
 Profile  
 
PostPosted: Mon Mar 02, 2009 2:01 pm 
Offline

Joined: Fri Feb 06, 2009 7:49 pm
Posts: 16
Hi vasechek,

I received your private message re: your problem, and am responding here because the information may be helpful to other EBD users or people helping EBD users with failed enclosures.

When I said that I concatenated the two disks and mounted them via loopback, that was my way of saying "These disks are JBOD." I see that you weren't sure whether it was JBOD or RAID-0.

It is unfortunate that you have already tried to assemble them as a RAID-0 array. Hopefully this only messed with the partition map and did not touch the actual partitions within.

I no longer have the EBD that I was troubleshooting in front of me, so I won't be able to give you detailed and complete step-by-step instructions, but I will do my best to explain what I learned about how they work and what you can do to get your data. These instructions will all assume a GNU/Linux environment, as I am pretty useless in Windows, only having a basic knowledge of its workings, and a fairly poor knowledge of the tools available in Windows. The good news for you is that you don't have to install GNU/Linux on your system: everything that I am going to explain to you uses basic utilities that are included in GNU/Linux and you can boot off of a live CD to use them.

The first and most important thing is: if you have enough space on another disk, it is always best to make disk images of devices you are trying to recover from first before doing anything to the disks, even if you *think* your methods will not change the disks. If you do not have enough space on another disk, I will continue with instructions on how to do it otherwise, but be VERY careful when copying data not to get source and destination mixed up!

The EBD, as you know, contains two disks. They form a concatenated set (aka JBOD) whose contents are seen only by the controller on the EBD. I was not able to detect and I do not believe that any metadata exists defining the JBOD -- I believe this is all handled by the controller, which sees both disks as a single 1TB-ish disk that happens to be broken up into two pieces. The disk is partitioned using MBR.

The first partition is an extended partition which contains logical partitions 5-9. Partitions 8 and 9 contain an operating system based on a Linux kernel for the embedded ARM processor, and BusyBox to provide the standard utilities (as opposed to GNU). I believe different parts of the system were on each partition, but I don't remember what exactly was contained on which partition, as I never intended to get the actual EBD running again; I just copied the data off the data partition so I could recover it for the customer, who had already purchased another NAS drive from a different vendor, details of which I also don't remember. Anyway, I believe partitions 5-7 contained temporary data and other things that were interesting but which I ignored, as everything I wanted to do was on partition 2, which you will see is the biggest partition, and obviously the one that contains the data.

This partition contains an XFS volume. I saw that you tried utilities for Ext2/3 on Windows. They won't work on XFS. I don't know why your raw data utiity didn't work -- it should still have been able to recognize file signatures, but it doesn't matter. We will focus our efforts on the XFS volume in partition 2. Partition 2 spans across two disks: the first part takes up most of the disk that has the partition table on it, and the second part is the entire second disk. If you have a large disk that you can copy data to, what you should do is to make an image (use dd -- or better ddrescue, I will explain this in a little bit) of the part of the second partition that is contained on the first disk, then when that is finished glom an image of the part of the second partition that is contained on the second disk on the end.

If you just want to copy everything to your new EBD, I would try the following, but again, BE VERY CAREFUL. If you have external enclosures for single SATA disks, I would highly recommend using them instead of putting the drives inside your computer. The reasoning for this is that you will be able to more easily determine which disks you're working on, as the access light will blink on the enclosure during use. This will greatly reduce the risk of doing something like accidentally copying the new, blank EBD onto the old EBD with all the important data, which is high, if this is the first time you've done something like this and aren't familiar with the order in which devices are enumerated on your system.

First, make sure you've labeled all four disks so you know which disks came from which EBD, and which of each of those two sets is the first and which is the second disk. I no longer remember which disk in the EBD that I took apart was the first disk, but I believe it to be the one in the front of the case. If you do not yet know which disk should be the first, now would be a good time to find out -- open your new EBD, label one disk front, and one back, and put them into your system one at a time to figure out which one has a partition table. If you're booting from a live CD, you can remove any hard drives you already have in your computer so that you don't accidentally write data from the EBD onto your internal drive, or vice versa, both of which would be quite disastrous. I don't know how you can determine whether a disk has a partition table or not in Windows, but on GNU/Linux, SATA, SCSI, and external disks appear in /dev as /dev/sdX, where X is a letter identifying your disk, starting with a, and increasing with each disk you add. If you type "ls /dev/sd*" it will show you all of your attached SCSI disk-like devices (sd stands for SCSI Disk -- all SATA and USB / Firewire drives are treated like SCSI disks in the Linux kernel; if you have IDE disks attached they will show up as hdX) and any partitions contained therein. If the device has no partition map, you will only see /dev/sdX for that device. If it does have a partition map, you will see /dev/sdX followed by one entry for each partition in the form /dev/sdXN, where X again is the identifier for the disk, and N is a number identifying the partition.

For example, if you have your Windows boot drive in your machine, which has only one partition, and you also have the first disk from the EBD inside, you might see the following when you type "ls /dev/sd*":

/dev/sda /dev/sda1 /dev/sdb /dev/sdb1 /dev/sdb2 /dev/sdb5 /dev/sdb6 /dev/sdb7 /dev/sdb8 /dev/sdb9

If on the other hand you have your windows boot drive in your machine, which has only one partition, and you also have the second disk from the EBD inside, you might see this instead:

/dev/sda /dev/sda1 /dev/sdb

In the above examples, I am assuming that your Windows boot drive will be seen as /dev/sda. This might not be the case, as this will ultimately depend on how many disks are plugged into your system and into which ports, and in which order your system enumerates those ports. It could be that a second drive you have in the machine is /dev/sda, or that the disk from the EBD ends up being /dev/sda. In any case, you will see that your Windows drive in those examples, with one partition, shows up as /dev/sda and the partition shows up as /dev/sda1. The first disk from the EBD in the example shows up as /dev/sdb and each partition as /dev/sdb1, sdb2, etc. The second disk from the EBD has no partition table, and therefore only shows up as the device with no partitions.

Anyway, I have to stop for now or I'll be late for work -- I will finish later tonight. In the meantime, please download and burn a live CD. You will be doing most of your work in the command line, and if you are comfortable with a command line only environment, I would suggest the Trinity Rescue Kit or the Ubuntu Rescue Remix. You can do a web search for either of those. Both are small images (100-200 MB) and contain a basic GNU/Linux system along with some rescue utilities. In particular, they both contain ddrescue, which is an excellent replacement for dd, which is the GNU utility that you would use to copy one disk to another. ddrescue has the advantages that unlike dd, it gives you feedback about its progress (dd just does its work without telling you that it's doing anything, then dumps a three line report when it's done ... for a large disk this could be very frustrating) and in case anything is wrong with your disks, like a bad sector, ddrescue will skip over the problem areas, while dd will just die and force you to start over from another spot on the disk.

If you want a graphical environment, you can download a bigger live CD, like the Ubuntu Desktop Live CD, but for our purposes, we will be using command line utilities for everything. You can still download a graphical desktop live CD if you want to experiment with a GNU/Linux desktop anyway. We can install ddrescue onto a graphical live CD environment, but keep in mind that because it won't actually be installed onto the CD, and only to the RAM disk that the live CD creates, you'll lose it and have to reinstall the next time you start up from the CD. Luckily, installing anything in Ubuntu (and all other Debian-based distributions) is very easy. The package name for ddrescue in Debian and Ubuntu is "gddrescue" so just type "sudo aptitude install gddrescue" in a terminal or use the Synaptic graphical package manager to select and install the "gddrescue" package.

Anyway, download a LiveCD (again, I recommend Trinity Rescue Kit or Ubuntu Rescue Remix, but you can also just download the Ubuntu Desktop CD) and play with it for a little bit. Label all your disks, and figure out which disk from each enclosure is the first and the second. Find out if your first disk from the old EBD still has a valid partition table. (This will matter.) Write back with what you discover. In the next installment, I will explain how to copy data from the old disks to the new, while keeping the OS on the new disk intact.

If at any point, you want to bail out, and you are in the NYC area, or are willing to ship your disks to NYC, private message me and I will give you the details of my repair shop. I will be glad to perform the recovery for you. We normally charge extra for a dual-disk enclosure, but I will be glad to perform the recovery at our standard rate for a single disk.

Best of luck with your recovery,

Daniel


Top
 Profile  
 
PostPosted: Wed Mar 04, 2009 1:16 pm 
Offline

Joined: Fri Feb 06, 2009 7:49 pm
Posts: 16
Okay - on to part two of how to selectively copy blocks from one disk to another using dd (or ddrescue)

You said that you suspect that the only problem might be that the MBR is messed up on your original set of disks. If this is indeed the case, then the fix will be very easy once you figure out which drive in each set is the "first" disk, which contains the MBR.

Again, the quickest way to find out whether or not a disk has a partition table is to type "ls /dev/sd*" at a command prompt. Unpartitioned disks will show up with only a listing for the device (ex. /dev/sda, /dev/sdc), while partitioned disks will also show listings for each of their partitions (ex. /dev/sdc1 /dev/sdc2).

This method is quick and can be executed as an unprivileged user, but does not give you much information besides "this disk has a partition table" or "this disk does not have a recognizable partiton table". If you want some more information, including the size and type of each partition, you can use fdisk or parted to list the partition table of each device. This will have to be done as root, however. The way to execute commands as root varies from system to system. On GNU/Linux Live CDs, this is usually done using the command "sudo", which escalates commands to super-user privileges. Live CDs usually do not require a password to use sudo, so all you have to do gain root access is to add the word "sudo" before a command that you want to run. If you will be doing several things as root, and you don't want to have to type "sudo" before each command that you want to run as a privileged user, you can type "sudo -s" to go into a root shell, and every command you type after that will be executed as root. When you enter a root shell, you will see (on bash and most other shells) the last character in your command prompt change from a dollar sign ($) to a pound sign (#). This is a visible indication that any command run in that shell will be executed as root.

For example, if somebody says, "run 'foo -bar * | baz' as root, then run 'qux' as root when finished", you can do this by either typing "sudo foo -bar * | baz" and then "sudo qux", or by typing "sudo -s", then at your root prompt you can type the two commands as originally given.

So, to list all partitions on all disks using fdisk, you can run "fdisk -l /dev/sd[a-z]" as root. Again, if you're not already at a root prompt, you can run this command as root by typing "sudo fdisk -l /dev/sd[a-z]". "fdisk -l" (that's a lowercase "ell" after the dash) will list all partitions on a disk. /dev/sd[a-z] is the parameter that tells fdisk which disks to list, in this case "scsi disks a through z" which should cover all of your SCSI (remember this includes SATA) disks up to 26. You can also use parted with the same parameters; for example: "sudo parted -l /dev/sd[a-z]" if your system has parted.

Anyway, I have digressed. Once you are sure you know which device is which, then we can begin. It's safest if you use an external case (a plain, single disk, non-RAID, non-JBOD, non-NAS external case) to attach your disks, as you can verify with certainty what the device name for that disk is by watching the blinking light when you try to read from that disk. This is very important because the two disks will look basically identical to the system, and you don't want to copy data to and from the wrong disks. To get a light to blink, do something like "dd if=/dev/sdb of=/dev/null" -- this tells dd to read all data from the input file (hence "if=") which is /dev/sdb in this case, and write it to the output file (of=) /dev/null, which is a special device that will ignore any input sent to it. Replace the "b" in "sdb" with the correct letter for whichever disk you're testing. DO NOT mix up the input file and the output file; this will destroy your data! When you run this command as given above, it will read everything from /dev/sdb and do nothing with it. If /dev/sdb is in an external case, you will see its light blinking as data is read. Once you're sure you've identified which physical disk is /dev/sdb, you can hit control-c to stop dd. Bear in mind that device names for external devices may change as they are plugged and unplugged or the system is restarted, so don't assume that just because a device was /dev/sdb when you did one thing that it will still be /dev/sdb later. If you're ever unsure, always verify what's what before you do an important operation. If you only have one external case, you can put one disk inside your machine and the other in the external case.

When you are absolutely sure you know which drive you want to copy your MBR from (the first drive from the new EBD) and which you want to copy to (the first drive from the old EBD) then we can use dd or ddrescue to copy the first block from the new disk to the old disk. If your MBR is indeed wiped out on your first disk from the old EBD, then you may not have a partition table on it anymore. If this is the case, I hope you labeled which was the first and which was the second disk when you took them out... or at least which was in the back and which was in the front.

Run "dd if=SOURCE of=DESTINATION count=1" as root. This will copy the first block from SOURCE (for example, /dev/sdc, but replace this with whichever device is your actual source) to DESTINATION (for example, /dev/sdb). The first block ("block zero") on an MBR partitioned disk contains the partition table and the boot code, if the system runs boot code from an MBR. To use ddrescue, run "ddrescue SOURCE DESTINATION -s 1b" as root, which does the same thing, except ddrescue doesn't use "if" and "of" to specify the input and output files; it just uses the first and second non-option arguments as source and destination respectively. The option -s specifies the size, and 1b means "one block", as ddrescue normally expects sizes to be in bytes. You could also say "-s 512" instead of "-s 1b".

When you're done, put the set of old disks in the new EBD enclosure and see what happens. If you're right about the MBR being the only thing messed up, this should work. I suspect that the OS on those drives might be wrecked too. If that's the case, then use dd or ddrescue to copy the first partition over from the new disk to the old one (remember that the first partition contains the extended partitions which contain the operating system).

If your old disk is attached as /dev/sdo and your new one is attached as /dev/sdn (notice that I keep changing around the letters, PLEASE do not just copy the commands I list, but substitute any drive letters I give for your actual ones!) then you can copy the first partition (the drive's operating system) from the new drive to the old drive by doing (as root)

dd if=/dev/sdn1 of=/dev/sdo1

or

ddrescue /dev/sdn1 /dev/sdo1

Make ABSOLUTELY SURE that the "n" in "sdn1" is replaced by the actual letter for your NEW EBD drive, and the "o" in "sdo1" is replaced by the letter for the OLD one. DO NOT mix them up. You'll be sorry. (Not too sorry, since this is just the OS for the drive, and I'm pretty sure you can download a fresh copy of that somewhere. You'd be more sorry if you wrote over the second partition, which contains your data. Actually, you would be really sorry if the partition table was gone on the first disk from your old set, and you ended up writing the partition table to the wrong disk from the old set, which might happen since with the partition table gone, both disks from the old set would appear without a partition table. If this happens, be very, very careful to make sure you have the right disks! If you end up in a situation without your partition table on the old disks, and you aren't sure which disk was in which bay of the enclosure, have an expert look at the disk through a hex editor before you do anything rash!)

I suggest the ddrescue option, since it will give you more visible feedback about your progress.

Once this is done, you should have a good copy of the OS on your old drives. Pop them into your new EBD enclosure and fire away. If this still doesn't work, then there's something else wrong -- likely in the filesystem of partition 2. This is where you'll have to do what I did, which is to copy partition 2 and everything from the second disk somewhere else so that we can run xfs_repair on it. To do this, you should have a 1TB or bigger disk (preferably bigger, "just in case") that you don't mind wiping. If you don't already have one, get one.

If you get to the point where you have copied the partition table and the OS and you still have no joy, then private message me (I don't check this forum regularly, but I will get an e-mail if I get a private message) and I'll come back and tell you how to piece partition 2 back together and repair it.

Best of luck again!

Daniel


Top
 Profile  
 
PostPosted: Sat Mar 07, 2009 3:04 am 
Offline

Joined: Sat Feb 28, 2009 10:29 pm
Posts: 2
Daniel,

First of all I don't know how to thank you enough for taking the time to post several kB of text in response to my plea for help. But more on that later. Let me address the technical side first:

I actually got most of my data back even before I logged in here today to check if you've replied (for some reason the "notify me when a reply is posted" doesn't seem to work for me).
It turns out that the original cause of all my problems was a faulty power supply. Now, I did suspect it and tried to measure its output levels, but they were perfect. It turns out that when the PS fails, it only fails to source enough current when the EBD is attached and turned on, so when I measured it with no EBD attached (couldn't do it otherwise without cracking either the supply, the EBD or the cable open) it gave perfect 5V and 12V, but when I turned it on it didn't source much. Suspecting that might be the case, as soon as I cracked the LaCie open I actually powered both drives from a desktop PC's supply and left the controller card working off the LaCie supply and it still didn't work. In retrospect that means that when a PS fails like that it fails suddenly and quickly loses most of its current sourcing capability. If only I knew it then... But I dug up some forum where some individual (apparently working for Runtime) claimed (falsely) that the way he fixed his LaCie is using Runtime RAID Reconstructor to rebuild the RAID-0 array which was how LaCie arranged those 2 drives. It's very easy to find those posts - any search for fixing an EBD with a failed RAID array will invariably yield a fourm thread and his post will likely be in it in all its lying glory because he posted them in at least 3 different threads that I saw. I guess Runtime will do anything to sell another license. Having said that, the eval version of their DiskExplorer for Linux tool was instrumental in my getting my data back as you will find below... Anyhow, I thought I found a great way to re-build a RAID-0 array - with my desktop PC, which has an Intel 875PBZ mommy with a HW RAID controller, so used that to create a RAID-0 array spanning the 2 drives, which of course corrupted them. I then deleted the array, but that didn't un-corrupt the drives and any other attempt to revive them failed. I was faced with 2 working disks where some of the sectors have been stomped on by the HW RAID controller. So I figured I had to know what exactly the RAID controller did to them. So I bought another used LaCie EBD and an internal 1TB SATA drive to store images of the corrupted drives before I would tinker with them again. I also had in my possession a 120GB SATA drive with no useful data on it and I got Once the shipments came in, I was ready. I used DiskExplorer to write an easily recongnizable pattern ("0xF0") to all bytes in as many sectors as I could at the beginning and at the end of both the 1TB drive and the 120GB drive. Then created a RAID-0 array using the Intel mommy's RAID controller the same way as before and deleted it the same way as before. Then examined what happened to the drives with DiskExplorer again. It turns out that this particular RAID Controller only wipes out sector 0 (Master Boot Record) and the next to last sector on each of the 2 drives. At that point I was almost certain that if I copied these sectors from the drives that came with the good LaCie EBD that I just bought to the corrupted drives I would get at least part of my data back. So I took out the experimental drives and instead hooked up drive 1 from both the working EBD and from my broken EBD to the PC. I was able to establish that sectors after sector 0 matched on both drives and at the end of the disk all sectors were 0. So I copied sector 0 from the good drive to the bad and wiped out the next-to-last sector on the bad drive so that both mathched their counterpart sectors on the good drive. On to drive 2 (by the way, drive 1 is at the back of the EBD enclosure, directly underneath the controller card, and drive 2 is at the front). Found that it was safe to wipe out the next-to-last sector since, again, at the end of both drives all sectors were 0's except for the one overwritten by the RAID controller on the bad drive. But sector 0 on drive 2 seemed to be a part of a file. From Sector 1 onwards both drives had random-looking data that didn't correlate at all between the 2 drives. Sector 0 on the good drive was more of the random-looking data, so I figured there was no sense in copying it over since it won't recover my file anyways. Other than that the array has been restored. When I put both fixed drives in a their original EBD enclosure and used the new power supply, I saw the data share on my network with all of my data intact (well, except for 512 bytes from sector 0 on drive 2). Is there a way to find out which file was using that sector???? I might have a copy of that file somewhere... If you could advise me on what to look for and where to look for it to figure out which file got affected I would appreciate it. Otherwise, I did get back all the information on the 2 drives.
A couple of thoughts in conclusion: I was able to create a makeshift power supply for the EBD by opening up the dead EBD power supply, noting which wire was 12V and which was 5V (the ground wires were predictably the black ones), then cutting off the cable and splicing it into an ATX power connector (male) so I could plug it into the power supply of my desktop PC just like you would a case fan. It's not a pretty way to power an EBD but it worked, unfortunately the drives were already corrupted at that point which required the above exercise...
...When I got the 2 drives fixed, I initially put them into the new enclosure, but even though the ethernet_bd did appear on my network, the share containing all my data didn't open. The same thing was happening earlier when I mated a working drive 1 from the new EBD and the corrupted drive 2 from the original EBD in a desperate attempt to recover at least a part of my data from drive 2 if it was indeed a JBOD array (which it was). It seems that there is something about drive 2 that makes it unique to the enclosure - maybe the partition / file table information is stored in the flash on the controller card or something silly like that, but when I put the same 2 drives into their original enclosure, they sprung right back up to life, while the other enclosure couldn't do it. I did have both enclosures set up exactly the same way with the same shares, usernames and passwords. If you know how to explain this mystery I am all ears, but this question is purely academic at this point.
So there it is - my success story. If anyone can answer the 2 lingering questions (especially the one about figuring out which file is now corrupted) please let me know.

Now as for the forums:
I posted the same question on forum.hddguru.com and here. hddguru is full of data recovery professionals who seem to use it as a fishing pool for new customers for their businesses. A handful of people responded, but it was impossible to get any useful info - all they did was try to scare/pressure/insult(!?) me into giving up and paying one of them several hundred to over a thousand $ for recovering my data. My expertise level in the subject is pretty low, so I was asking some pretty basic questions which anyone working in the industry could answer, but only one person (who appeared to be an amateur with no vested interest in my business) cared enough to reply with anything useful. Besides that enlightening experience, I already mentioned the character that gave people false information to get them to buy RAID Reconstructor - most of his posts are on hddguru.com. That's why it was really refreshing to read this thread today. As a clumsy way of thanking you for what you've done, please send me your contact info so I can refer people to you. I am on the other coast, but I have a ton of family and friends in NYC, and you've convinced me that they can do a lot worse than give you a ring if they ever have problems accessing their data. Send me an email if you don't want to post your info in the thread.
Also, rest assured that the info you posted is not going to be wasted. I recommend to anyone who owns one of these beasties to copy this thread and save off somewhere for a rainy day (I am surely going to do that) because you never know when you might need it and it is hard to get information of this quality anywhere...

Thanks for the willingness to help, rather than coerce or extort, for taking the time to educate, for making your responses dummy-proof and for not taking a condescending approach towards someone who didn't know enough to keep himself out of trouble which could have been avoided easily.
You have a fan here.

Best of luck!


Top
 Profile  
 
PostPosted: Sun May 10, 2009 2:04 pm 
Offline

Joined: Thu May 07, 2009 12:52 pm
Posts: 19
hello! i am now in the similar situation.. this thread has been really helpful so far! i was so close to setting up the drives in a RAID0 to try and get my data, thankfully i saw this thread before i did that.

i thought it could be the powersupply since my symptoms were the same as vasechek so i have also wired up the cable to the 12 and 5V on a molex, to start the lacie.. the drives do both spin up but the controller doesn't seem to work (no ping, no usb connection, and the power button on the case doesn't even work). so i guess the controller board is dead. so danek i will really appreciate some more guidance for the rest of the process which you mentioned .. that is ..
1) how to make image(s) of the data partitions before i start mucking around
2) how to concatenate the images and access the data, run xfs_repair if necessary..

here is what i have done so far.. i have burnt trinity rescue kit v3.3 build 321
i was able to boot up TRK and do the fdisk -l thing. i have identified which drive has the partition table, and which does not (in my case, the drive closest to the front is the one without a partition table)
i have bought a 2TB drive to copy data too. the lacie is 1TB and it wasn't entirely full so hopefully i will be able to store both the images and the reconstruction on this single drive, is that correct?

when the problem first occured i plugged the drives into the computer directly and 'imported foreign disks' in winxp's disk management thing, and assigned them drive letters. but when i tried to access the volume it would say the disk was unformatted, would i like to format them, i said no thanks and unplugged them again. hope this hasn't stomped on my data at all.

eagerly awaiting a reply , i stupidly had no backups and if i have lost 2 years worth of music and my photos i will be heartbroken :(


Top
 Profile  
 
PostPosted: Sun May 10, 2009 10:03 pm 
Offline

Joined: Fri Feb 06, 2009 7:49 pm
Posts: 16
Hi wim,

I received your PM. Sorry to hear about your trouble, but it's good to know that you have a nice large disk to do recovery to.

There are a couple of ways you can use the same drive for the recovery effort and also to store your recovered files once you have your data. The most straightforward methods I can think of are:

1.
a. dd both disks directly to the target 2TB disk. This will copy over the data, but it will also copy partition table from the original EBD, which will have the wrong data for the new disk.
b. Delete the partition table on the target disk,
c. Create a new partition table with the original partition sizes, and use the extra space at the end to create a new partition to copy the recovered files to.
d. Format the new partition. It sounds like you use Windows XP as your primary OS. I'm going to assume that you'll want to use it in Win XP, so you should format the recovery partition as NTFS.
e. Mount partition 2 (xfs partition from the EBD), repair if necessary.
f. Mount recovery target partition (use ntfs-3g)
g. Copy files.
h. Boot into Windows, mount the drive, and check your work. If you're satisfied, you can delete the previously created partitions 1 and 2 (not your recovery partition) and create a new one in their place to reclaim the space.

2.
a. Format the new disk with one big, honking partition. Again, assuming you'll be using this on Win XP, format as NTFS.
b. Mount partition. (use ntfs-3g)
c. dd both disks to an image on the partition.
d. Attach the image via a kernel loopback device. You can specify the offset to partition 2 so that the loopback device starts at partition 2.
e. Mount your loopback device, repair if necessary.
f. Copy files to the big honking NTFS partition.
g. Boot into Windows, mount the drive, and check your work. If you're satisfied, you can delete the image file to reclaim the space.


These are outlines of the two methods I think would be most efficient. Each is simpler in some ways, and more involved in others, but overall I would rate them with about equal difficulty, so if you have more experience in working with disk images or partitions, then I would go with the method that fits your experience better. If you're equally experienced with both disk images and partitions, then I would tend to favor the disk image method, because at the end of the day you end up with one partition on your disk, without having to do lots of copying and partitioning to get there. If you would like to have multiple partitions on your disk at the end of the day, then the first method might suit you.

If the outline above is enough information to get you started, then go for it, and good luck. If you'll need some help, let me know (PM me again to let me know you replied, because I don't come here regularly, but leave your actual reply on the forum for the benefit of others who might have a similar situation in the future), and I'll flesh out the details of each step for you.


Top
 Profile  
 
PostPosted: Mon May 11, 2009 12:16 am 
Offline

Joined: Thu May 07, 2009 12:52 pm
Posts: 19
thanks for the prompt reply..
i will try method 2, since i am more familiar with disk images than partitions and since i will prefer a single 2TB on the new WD drive at the end of the day anyway.

2a. done
2b. ntfs-3g driver is on TRK already, right? if the 2TB disk comes up as sda, then is the following syntax correct?
Code:
mount -t ntfs-3g /dev/sda1 /mnt/windows

2c. should i be using dd or ddrescue here ? should i be copying the entire disk, including lacie's OS, or only the user data partition? what is the correct syntax to create image files on /mnt/windows or wherever.. want to be 100% sure to get this right i have been told dd does not warn you if you accidentally copied empty sectors from the source over your data.. :o

i will get onto 2d-2g once i've created the images..
i don't know what a loopback device is, is it essentially the same as what is called a virtual drive in windows? i usually mount disk images using an gui app called Alcohol 120%.
i have found the following syntax for mounting an image on wikipedia
Code:
losetup /dev/loop0 example.img
mount /dev/loop0 /home/you/dir

and it said this was equivalent
Code:
mount -o loop example.img /home/you/dir

however, i expect i would have two files lacie1.img and lacie2.img, wouldn't i? in this case, how am i able to concatenate them and mount them as 1 big directory ?


Top
 Profile  
 
PostPosted: Mon May 11, 2009 3:41 am 
Offline

Joined: Fri Feb 06, 2009 7:49 pm
Posts: 16
Good, you've been doing your homework. :)

Yes, TRK comes with ntfs-3g, which will allow you to do read/write on NTFS. The mount invocation you provided would be correct if ntfs-3g were a "normal" filesystem driver, but it is a little bit different in that it actually runs in userspace and ntfs-3g is the name of the command you use to mount your volume. (You don't use the standard "mount" utility.)

So, if your 2TB disk is sda, and you want to mount the first and only partition, which is NTFS, using ntfs-3g, you would do

Code:
ntfs-3g /dev/sda1 /path/to/your/mountpoint


Once this is done, then files you write to /path/to/your/mountpoint will be written to your NTFS partition, and files on the NTFS partition can be read from /path/to/your/mountpoint. Note that when mounting volumes in UNIX-like operating systems, the mountpoint generally has to exist before you invoke your mount command. So if you want to mount your volume at /2tbdisk, then do

Code:
mkdir /2tbdisk
ntfs-3g /dev/sda1 /2tbdisk


For the actual imaging part, I recommend always using ddrescue instead of dd whenever it is available. TRK comes with ddrescue. ddrescue does everything dd does, and more:

1. ddrescue prints its status on the screen, so you can tell how much data has been copied, and how fast it's copying. dd doesn't print status until after the copy is complete. For a large disk, this can mean a very long time without knowing what's going on.
2. If any of your disks have bad sectors on them, ddrescue will skip over the bad sectors and retry them later. dd will abort the entire operation if bad sectors are encountered.
3. ddrescue lets you optionally specify a log file, which it can use to resume the copy if for any reason you need to stop it or if something goes wrong and it stops prematurely.

Anyway, using ddrescue (or dd if you really want to, but seriously, use ddrescue) you can make images of the two disks, then concatenate them together, or you can image the first disk, and have ddrescue append the second disk to your image of the first disk. Obviously, I recommend doing the latter, since it means less shuffling of stuff. Another thing you can do to cut down on work later is to image only the second partition from the first disk, since the first partition just contains the logical partitions containing the OS and stuff from the EBD, which you probably don't need or care about.

Assuming that your new 2TB disk is at /dev/sda, that you have /dev/sda1 mounted at /2tbdisk, that your first disk from the EBD is at /dev/sdb, and the second disk is at /dev/sdc, do something like the following (obviously, change things as appropriate, and verify all of your device names before you start anything!):

Code:
ddrescue /dev/sdb2 /2tbdisk/ebd.img /2tbdisk/ebd_1.log


This tells ddrescue to image partition 2 of /dev/sdb, saving the image to /2tbdisk/ebd.img. The third argument is the optional log file. You don't have to do this, but it doesn't hurt to do it, and you'll be really grateful in case anything interrupts the transfer. If the transfer does get stopped intentionally or accidentally, you can resume it by calling the same command (if the device name changes you will need to change it in your invocation, of course) and ddrescue will use the log file to determine where to start so it can pick up where it left off.

Now go eat lunch while ddrescue copies the first half of your EBD. When it's done, youll want to find the exact size, in bytes, of your image. Easy way to do this is with ls:

Code:
ls -l /2tbdisk


The -l flag is for "long" and it tells ls to list the directory (in this case our mount point for the 2TB disk) showing long attributes, including filesizes. Let's pretend that by doing this you discovered that your image is exactly 4987654321 bytes long. Now we tell ddrescue to image the second disk at /dev/sdc, appending its data to the image we've already made of the first one:

Code:
ddrescue /dev/sdc /2tbdisk/ebd.img /2tbdisk/ebd_2.log -o 4987654321


Notice here we are imaging all of /dev/sdc, since obviously our second disk doesn't have a partition map. Notice that we are writing to the same output file /2tbdisk/ebd.img but we are using a different logfile (if you decide to use one). Most crucially, notice the extra option -o 4987654321 -- the "-o 4987654321" tells ddrescue to set its position in the output file to 4987654321 (which we earlier determined to be the size of the image of the second partition from the first disk; obviously, substitute your real size).

If you do end up making two images for whatever reason (let's call them /2tbdisk/ebd_1.img and /2tbdisk/ebd_2.img) you can just use cat to glue them together with something like "cat /2tbdisk/ebd_2.img >> /2tbdisk/ebd_1.img". But you won't need to do this because you'll use ddrescue's output offset to write everything to one file to begin with.

The loopback is a way to map a regular file as a loop device. In UNIX and operating systems that behave like it, including GNU/Linux, "everything is a file", including block devices like hard drives. Normally, you can't mount a filesystem contained in a "regular" file, so you map it as a loop device first. If you don't understand, don't worry; all you need to know is that there are two usual ways to do this, both of which you discovered on Wikipedia.

"mount -o loop /path/to/file.img /path/to/mountpoint" is certainly the simpler and easier way to do this, if your system supports it. Basically, the "mount" utility will accept the "-o loop" option, automagically performing the usual first step of setting up the loop device for you. Not every version of mount does this, but it's worth trying it first, and I have to assume the TRK "mount" does this. I usually recommend doing it the two-step way, because this will work regardless of whether or not your "mount" supports the "loop" option.

So again, if TRK supports it (it probably will) then just do

Code:
mkdir /ebd
mount -o loop,ro -t xfs /2tbdisk/ebd.img /ebd


Notice that I created the mountpoint first. I also added "ro", or "read only" to the options for mount. I also specified the filesystem type with -t, but you probably don't have to do this because TRK's "mount" should be smart enough to figure it out. It's always a good idea to mount things read only whenever you're dealing with a data recovery. If for whatever reason TRK's mount doesn't do "-o loop" then do the following before you set up your loop device:

Code:
losetup -f


This will print the first available loop device, which is particularly important when booting from a Live CD such as TRK, since I do believe the first loop device (/dev/loop0) is used by the Live CD itself, if not more than one loop device. Let's pretend that "losetup -f" tells you that the first available loop device is /dev/loop1. Go ahead and do
Code:
losetup /dev/loop1 /2tbdisk/ebd.img
mkdir /ebd
mount -o ro -t xfs /dev/loop1 /ebd


OK, if you've gotten this far with no errors, then go ahead and explore your mount point /ebd (or whatever you end up using) to see how everything looks. I'm assuming you know how to use ls and cd. If your filesystem is undamaged, then go ahead and copy everything over. If you don't care too much about permissions, you should be able to get away with something like cp -R /ebd /2tbdisk -- otherwise, try something like rsync -a /ebd /2tbdisk. Windows hardly ever uses permissions, so you should be OK with cp.

If your filesystem is damaged, you'll need to repair it first. If you did manage to mount it, then you should unmount first before running xfs_repair. This is as easy as

Code:
umount /ebd


Then do

Code:
xfs_repair -fv /2tbdisk/ebd.img


The "-fv" tells xfs_repair to repair a filesystem in a regular file, and to be verbose.

If this finishes successfully, go and mount your image again. If there are problems, poke around in xfs_repair's manpage and see if you can find something appropriate to your situation. If you don't think you can repair the filesystem, then it's time to turn photorec on your disk image (also helpfully included in TRK), but for now we'll assume your filesystem is either fine or easily repairable, as photorec is a whole other story.

Anyway, I hope you find these tips helpful. If you are unsure about anything, don't hesitate to ask. The good thing about doing this with disk images is that it's a little harder to screw things up... as long as you are reading FROM disk and writing TO image, the worst thing you can do is screw up your image, in which case you just delete it and start over, since you were only ever reading from the original disks. Well, I guess a worse thing that could happen is that one of your original disks could die, but that wouldn't be your fault. Just always make sure that when you use ddrescue, the first argument after ddrescue is the device you are reading from, the second argument is the file you are writing to, and the third argument is your log file. Keep all of these in mind, and even if you screw up and put in the wrong input device, you can always scrap your file and start over.


Top
 Profile  
 
PostPosted: Mon May 11, 2009 3:59 am 
Offline

Joined: Thu May 07, 2009 12:52 pm
Posts: 19
thanks danek! this sounds promising..
i'll have a shot at it when i get home from work tonight, and post my result here later


Top
 Profile  
 
PostPosted: Tue May 12, 2009 5:00 am 
Offline

Joined: Thu May 07, 2009 12:52 pm
Posts: 19
ok i had a try last night, but there were a few wrinkles..

when i booted up with the trinity rescue kit, and 2tbdisk along with both the 500gb disks from the ebd plugged in, and executed the "ls /dev/sd*" it listed the following:
Code:
/dev/sda /dev/sda1 /dev/sdb /dev/sdb1 /dev/sdc /dev/sdc1 /dev/sdd
i was able to determine using "fdisk -l" that
  • a: ebd part 1 (partition table)
  • b: 2tb disk
  • c: ebd part 2 (no partition table)
i do not know what /dev/sdd is??? i have no other hard drives plugged in. i suppose it could possibly be the dvd drive, because it is a usb drive and you mentioned previously that all SATA and USB / Firewire drives are treated like SCSI disks in linux.

here is where the first problem is.. if a is the first disk from the ebd i was expecting to see more partitions i.e. /dev/sda /dev/sda1 /dev/sda2 /dev/sda5 /dev/sda6 /dev/sda7 /dev/sda8 /dev/sda9, but this was not the case. and, though i was able to mount the 2tbdisk as described, i was not able to execute the command
Code:
ddrescue /dev/sda2 /2tbdisk/ebd.img /2tbdisk/ebd1.log
because /dev/sda2 doesn't seem to exist. however, i went ahead and did
Code:
ddrescue /dev/sda1 /2tbdisk/ebd.img /2tbdisk/ebd1.log
anyway and ended up with a file which was 500105217024 bytes and then i did
Code:
ddrescue /dev/sdc1 /2tbdisk/ebd.img /2tbdisk/ebd2.log -o 500105217024
both of which seemed to work (the TRK background image blanked out a few times but the process seemed to continue fine). i now have an ebd.img file on the big drive which is 1 000 213 079 040 bytes in filesize. here are the contents of the log files ebd1.log and ebd2.log respectively
Code:
# Rescue Logfile. Created by GNU ddrescue version 1.8
# current_pos  current_status
0x10C37C00     +
#      pos        size  status
0x00000000  0x10C35000  +
0x10C35000  0x00003000  -
0x10C38000  0x745FD48400  +
Code:
# Rescue Logfile. Created by GNU ddrescue version 1.8
# current_pos  current_status
0x7470C00200     +
#      pos        size  status
0x00000000  0x7470C06000  +

now, i went and did
Code:
mkdir /ebd
mount -o loop,ro -t xfs /2tbdisk/ebd.img /ebd

but this didn't work, i got the error message: "mount: wrong fs type, bad option, bad superblock, on /dev/loop1, or too many mounted file systems (could this be the IDE device where you in fact use ide-scsi so that sr0 or sda or so is needed?)". so then i tried the other method, and by the way neither "losetup -f" nor "losetup --find" worked for me, f was not a valid argument and it printed usage message. however i was able to identify which loop devices were in use by using "losetup -a" (only loop0 was in use, by TRK) and use the next available number in my case loop1. so i executed "losetup /dev/loop1 /2tbdisk/ebd.img" and that seemed to work, but when i did
Code:
mount -o ro -t xfs /dev/loop1 /ebd
i got a similar error message "mount: wrong fs type, bad option, bad superblock, on /dev/loop1, or too many mounted file systems" without the part in parentheses this time. so then i did "umount /ebd", though i guess it never got mounted, and went "xfs_repair -fv /2tbdisk/ebd.img" but it seems my TRK does not have xfs_repair on it because i got "_bash: xfs_repair: command not found". i had a poke around on these forums and found this thread which suggested to type "sudo apt-get xfsprogs" to install xfs_repair, but that didn't work either (this time apt-get not found). where do i get xfs_repair? i did a quick google search and also could not find a download, only man pages. is it on TRK somewhere and i'm simply not doing it right? if not, is it going to be as simple as downloading it somewhere and storing it on the 2tbdisk (since i am able to access files on there with it mounted using ntfs-3g thing).

by the way, i have another couple of weird questions, my 2tbdisk had a few files on it already and some of them were not visible from the command prompt (neither using ls nor ls -l) when booted up with the TRK.. these files were

fanfare ciocârlia-mig mig (jony iliev).mp3
fanfare ciocârlia-sandala (saban bajramovic).mp3

and i'm guessing they're not shown because of the funny character â in the filenames? there were other mp3s on the 2tbdisk which were listed fine with ls. this got me a bit worried, because a lot of my music on the ebd is going to have funny characters in the filenames like that! does it mean that cp will not see them at all?? :?

also another thing i noticed was that from the command prompt in TRK, the letters o and u were swapped around !! from the keyboard! at first i kept making typos over and over again until it became evident that when i pressed o, i actually got a u, and vice versa?! of course it didn't stop me from entering commands after i found out that was happening, but.. wtf?? is it a known issue? :lol:

regarding my first question, here is some more information that might be useful, here are the contents of the files

sda.txt
sda1.txt
sdc.txt
sdc1.txt

after i executed the commands

fdisk -l /dev/sda >> sda.txt
fdisk -l /dev/sda1 >> sda1.txt
fdisk -l /dev/sdc >> sdc.txt
fdisk -l /dev/sdc1 >> sdc1.txt

Code:
Disk /dev/sda: 500.1 GB, 500106780160 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1       60801   488384001   42  SFS

Code:
omitting empty partition (6)

Disk /dev/sda1: 500.1 GB, 500105217024 bytes
255 heads, 63 sectors/track, 60800 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

     Device Boot      Start         End      Blocks   Id  System
/dev/sda1p1               1          16      128457   82  Linux swap / Solaris
/dev/sda1p2              16          17        8032+   5  Extended
/dev/sda1p5              17          17        8001   83  Linux

Code:
Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1       60801   488384001   42  SFS

Code:
Disk /dev/sdc1: 500.1 GB, 500105217024 bytes
255 heads, 63 sectors/track, 60800 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes


Top
 Profile  
 
PostPosted: Tue May 12, 2009 12:26 pm 
Offline

Joined: Fri Feb 06, 2009 7:49 pm
Posts: 16
wim,

It looks like there's more than one way to arrange the data on an EBD... your partition maps are vastly different from what I saw, so we can no longer assume anything that was true about the EBD that I had worked with. I'm glad that you were able to find solutions to some of your roadblocks on your own, but it looks like we might have a bit of work cut out for us here. Anyway, there are a few other concerns here:

Quote:
/dev/sda2 doesn't seem to exist.


Indeed /dev/sda2 doesn't exist. We'll have to approach this completely differently.

Quote:
here are the contents of the log files ebd1.log and ebd2.log


It seems you have some bad sectors on your first EBD disk! Luckily the size of the unreadable area is quite small (0x3000), which is 48 sectors of 0x200 each, or a total of 24 KiB. Nothing to worry about too much. It's about 268 MiB into your disk. I wouldn't worry too much about it at this point.

Quote:
i got the error message: "mount: wrong fs type, bad option, bad superblock, on /dev/loop1, or too many mounted file systems (could this be the IDE device where you in fact use ide-scsi so that sr0 or sda or so is needed?)". so then i tried the other method, and by the way neither "losetup -f" nor "losetup --find" worked for me, f was not a valid argument and it printed usage message. however i was able to identify which loop devices were in use by using "losetup -a"


Yes, because it's not XFS. Strange that losetup -f didn't work, but you did use the correct workaround. :)

Quote:
i ... went "xfs_repair -fv /2tbdisk/ebd.img" but it seems my TRK does not have xfs_repair on it because i got "_bash: xfs_repair: command not found". i had a poke around on these forums and found this thread which suggested to type "sudo apt-get xfsprogs" to install xfs_repair, but that didn't work either (this time apt-get not found). where do i get xfs_repair? i did a quick google search and also could not find a download, only man pages. is it on TRK somewhere and i'm simply not doing it right? if not, is it going to be as simple as downloading it somewhere and storing it on the 2tbdisk (since i am able to access files on there with it mounted using ntfs-3g thing).


Well, so it seems TRK doesn't come with xfsprogs, which is the package of utilities for XFS. "sudo apt-get xfsprogs" is the way you would install xfsprogs on a Debian-based system (think Debian, Ubuntu, Xandros, Knoppix, MEPIS, Linspire, AGNULA, and literally dozens of others). APT is the package manager for Debian and its derivatives (arguably the best package manager in GNU/Linux, which is part of the reason why Debian-based distributions are so well loved, and why I personally use Debian on my machines) and if your system does not have apt-get, then it probably not Debian-based and you will have to install software using a different package manager, or by building it yourself.

I don't know what the base distribution of TRK is. I suspect it is probably actually a completely custom distribution, in which case you will be out of luck when looking for a package manager. I'm a little surprised that TRK doesn't include xfsprogs, but not totally shocked; it's a bit of a niche filesystem and I think TRK mainly focuses on helping people rescue Windows-based systems, anyway. If you need xfsprogs, I don't recommend trying to build it from source; it will be a distraction from your current goal, and TRK, being a highly specialized system, may not come with the toolchain anyway, making this a bit difficult. Instead you might want to try a different boot CD, like the Ubuntu Rescue Remix. URR is based on Ubuntu, which is based on Debian, so if URR doesn't include xfsprogs, then "sudo apt-get install xfsprogs" will work just fine for you. At any rate, it dosn't matter at the moment, since we are not sure right now if we're still dealing with XFS...

Quote:
and i'm guessing they're not shown because of the funny character â in the filenames? there were other mp3s on the 2tbdisk which were listed fine with ls. this got me a bit worried, because a lot of my music on the ebd is going to have funny characters in the filenames like that! does it mean that cp will not see them at all?? :?

also another thing i noticed was that from the command prompt in TRK, the letters o and u were swapped around !! from the keyboard! at first i kept making typos over and over again until it became evident that when i pressed o, i actually got a u, and vice versa?! of course it didn't stop me from entering commands after i found out that was happening, but.. wtf?? is it a known issue? :lol:


I don't know why you can't see those files. I don't know how Windows/NTFS stores filenames, but it's probably Unicode, which should be fine. The filename itself might show up with escape sequences in place of the UTF-8 character, but you should still see it. I suspect it might be ntfs-3g, but I really don't know. If it is indeed ntfs-3g, then you should be able to see your files with extended characters once you get your filesystem from the EBD mounted, but you may or may not be able to copy them to the ntfs-3g mounted filesystem. If this is the case, there are a couple of ways we can work around it, but we'll cross that bridge when we get to it.

By the way, you can add the "-a" flag to ls to list "all" files. Files with certain characters at the beginning or end (mainly files that begin with '.', end with '~', or begin and end with '#') are hidden by default. I doubt your files fall under this category, but it's worth a shot.

That is weird that your o and u are swapped. Weird keymap.

Anyway, here we can see that /dev/sdc *does* have a partition table... otherwise there would be no sdc1! Both sda and sdc have a single partition taking up the whole disk. sda1 seems to have its own partition table in turn, defining some subpartitions, but strangely, with quite a bit of unpartitioned space in the PBR...

I'd actually like to see the first sector of /dev/sda1 and /dev/sdc1... Can you do

Code:
dd if=/dev/sda1 count=1 | xxd > sda1b1.txt
dd if=/dev/sdc1 count=1 | xxd > sdc1b1.txt


and post the contents of those files?


Top
 Profile  
 
PostPosted: Tue May 12, 2009 1:56 pm 
Offline

Joined: Thu May 07, 2009 12:52 pm
Posts: 19
hi daniel,
re: the bad sectors 268MB into the disk..
when i was experimenting i also tried to do "ddrescue /dev/sda /2tbdisk/ebda.img /2tbdisk/ebda.log". (note source is /dev/sda not /dev/sda1) the process seemed to hang after a few seconds, so i did ctrl+C and rebooted.. no log file was generated, but i did get an ebda.img file which is 268 megabytes in size, i guess that's no coincidence.

you say that the filesystem may not be XFS. i noticed that fdisk -l shows a table column called "system", and has such entries as Linux swap / Solaris, Extended, Linux, and SFS. would you expect to see XFS here?

i mentioned previously that i went 'import foreign disks' and assigned them drive letters in windows disk manager previously. is it possible this could have stomped over the partition map you saw originally, and my disks were actually originally the same partition maps as you expected?

i have solved the mystery of o and u being swapped, but i feel a bit sheepish to explain the answer here.. :oops: the keys were physically swapped on my keyboard. it must have happened years ago when i cleaned the keys. the reason i have only noticed, now, is because i usually use a dvorak keyboard mapping.. but when booting up into TRK it of course goes back to qwerty and i had to actually look at the keyboard to see how to type properly!! :lol:

i was not able to execute the commands you sent, because xxd not found. see attachment below ..

Image

edit: found that xxd is on ubuntu rescue remix.. i'll try again after work tonight


Top
 Profile  
 
PostPosted: Wed May 13, 2009 3:10 pm 
Offline

Joined: Thu May 07, 2009 12:52 pm
Posts: 19
ok i was able to execute the commands in ubuntu rescue remix. and, by the way, those files with funny characters in the filenames were also now visible when i booted with ubuntu rescue remix. i have no idea what this is going to tell you, but here are the contents of the text files for disk 1 and disk 2 respectively :

Code:
0000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001b0: 0000 0000 0000 0000 0000 0000 0000 0002  ................
00001c0: 0100 82fe 3f0f 3f00 0000 92eb 0300 0000  ....?.?.........
00001d0: 0110 05fe 3f10 d1eb 0300 c13e 0000 0000  ....?......>....
00001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.


Code:
0000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 36 posts ]  Go to page 1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group