How to read the data of a 3TB external hard drive in OpenSUSE Linux(32 bit)

Hi,

I have a 3TB external hard drive with some important data that was sent to
me by others. I want to read out the data, but my computer with OpenSUSE
Linux (32bit) only can find this drive but can not read the data. Are there any
solutions for me?

I really appreciate your kind help and support. Thanks very much.

How is the driver formatted? You may need to add “ntfs” to /etc/filesystems…

I just received this disk from others. It should not be in NTFS format because I can not read it in either WinXP or Win7 systems. I onle can see how much space was used and the format (ext3) in my OpenSUSE Linux(32bit), but can not read it.

This may be a permissions problem; have you tried to read it from ‘root’ or just from a ‘user’?

@honeyme: please post output of


su -c 'fdisk -l'

Yes, I tried with root account. It still does not work.

@Knurpht: the output is listed as follows:

Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0008d951                     

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         262     2104483+  82  Linux swap / Solaris
/dev/sda2   *         263        2873    20972857+  83  Linux               
/dev/sda3            2874      182401  1442058660   83  Linux               

Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0000e9d8                     

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1      182401  1465136001   fd  Linux raid autodetect

Disk /dev/sdd: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0008da91                     

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1      182401  1465136001   fd  Linux raid autodetect

Disk /dev/sde: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00019a9c                     

   Device Boot      Start         End      Blocks   Id  System
/dev/sde1               1      182401  1465136001   fd  Linux raid autodetect

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00087e1b                     

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1      182401  1465136001   fd  Linux raid autodetect

Disk /dev/md0: 6001.2 GB, 6001196924928 bytes
2 heads, 4 sectors/track, 1465135968 cylinders
Units = cylinders of 8 * 512 = 4096 bytes     
Disk identifier: 0x00000000                   

Disk /dev/md0 doesn't contain a valid partition table
Note: sector size is 4096 (not 512)

WARNING: The size of this disk is 3.0 TB (3000592977920 bytes).
DOS partition table format can not be used on drives for volumes
larger than (17592186040320 bytes) for 4096-byte sectors. Use parted(1) and GUID
partition table format (GPT).


Disk /dev/sdf: 3000.6 GB, 3000592977920 bytes
32 heads, 63 sectors/track, 363376 cylinders
Units = cylinders of 2016 * 4096 = 8257536 bytes
Disk identifier: 0xc6ce1603

   Device Boot      Start         End      Blocks   Id  System
/dev/sdf1               1      363376  2930263040   83  Linux

You now have the answer; you may be able to find out from those who sent it how they tried to partition it. start – Parted Magic may be able to reconstruct the partition table if it was validly formated; otherwise, SystemRescueCd may enable you to recover the data.

The guy who sent me this disk said it was formatted with linux ext3 filesystem. The disk includes very important data for me, can you provide some detailed solution? I don’t want to do too much tests on this disk in case of corrupting some data.

You didn’t give the exact steps you did, not enough detail. Try these steps on the command line as root, and report the output, including any error messages. The mount is read-only so should be safe.

mount -r /dev/sdf1 /mnt
mount
df
ls -al /mnt
umount /mnt

Here is the output:


***:/home/me # mount -r /dev/sdf1 /mnt
***:/home/me # mount                  
/dev/sda2 on / type ext4 (rw,acl,user_xattr)     
proc on /proc type proc (rw)                     
sysfs on /sys type sysfs (rw)                    
debugfs on /sys/kernel/debug type debugfs (rw)   
udev on /dev type tmpfs (rw)                     
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/md0 on /data type ext4 (rw,acl,user_xattr)    
/dev/sda3 on /home type ext4 (rw,acl,user_xattr)   
fusectl on /sys/fs/fuse/connections type fusectl (rw)
securityfs on /sys/kernel/security type securityfs (rw)
/dev/sdf1 on /mnt type ext3 (ro)    
                   
***:/home/me # df                           
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2             20641788  13992688   5600460  72% /         
udev                   8238180       332   8237848   1% /dev      
/dev/md0             5768583056 230552876 5245002988   5% /data   
/dev/sda3            1419429880 1074981500 272345448  80% /home
/dev/sdf1            2884281560 2558715432 181352052  94% /mnt

***:/home/me # ls -al /mnt
ls: cannot access /mnt/ancil: Input/output error
ls: cannot access /mnt/dumps: Input/output error
ls: cannot access /mnt/read_me: Input/output error
ls: cannot access /mnt/lbc: Input/output error
total 16
drwxrwxrwx  7 root   root  4096 2011-12-05 18:18 .
drwxr-xr-x 22 root   root  4096 2011-07-24 14:43 ..
d?????????  ? ?      ?        ?                ? ancil
-rw-------  1 precis users   49 2011-12-03 16:23 .directory
d?????????  ? ?      ?        ?                ? dumps
d?????????  ? ?      ?        ?                ? lbc
drwx------  2 root   root  4096 2011-11-21 02:46 lost+found
d?????????  ? ?      ?        ?                ? read_me

***:/home/me # umount /mnt
***:/home/me #

The filesystem appears to be corrupted or damaged.

On 2011-12-07 09:06, ken yap wrote:
>
> The filesystem appears to be corrupted or damaged.

That’s assuming that openSUSE can read GPT partition tables.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

if it’s a GPT partitioned disk could it be that openSuse has issues reading it as questioned by robin_listas? if so you could find out what distro was used to partition and write the disk and use that distro’s live cd to copy it to a standard drive. Fedora in it’s latest release, 16, supports it.

Carlos E. R. wrote:
> On 2011-12-07 09:06, ken yap wrote:
>> The filesystem appears to be corrupted or damaged.
>
> That’s assuming that openSUSE can read GPT partition tables.

google01103 wrote:
> if it’s a GPT partitioned disk could it be that openSuse has issues
> reading it as questioned by robin_listas? if so you could find out what
> distro was used to partition and write the disk and use that distro’s
> live cd to copy it to a standard drive. Fedora in it’s latest release,
> 16, supports it.

No, this is a red herring. opensuse certainly does support GPT partition
tables. I don’t remember when support was introduced but certainly at or
before 11.2.

The issue is (was?) that some of the tools couldn’t deal with them
(cfdisk for one, IIRC) and perhaps grub couldn’t (don’t remember). And
yes, the tools in Red Hat-derived distros were more up to date.

On 2011-12-08 12:00, Dave Howorth wrote:
> The issue is (was?) that some of the tools couldn’t deal with them
> (cfdisk for one, IIRC) and perhaps grub couldn’t (don’t remember). And
> yes, the tools in Red Hat-derived distros were more up to date.

Legacy grub can not. Fdisk can not, and it says so in the printed output
from this disk. The partition layout we are working with may be wrong.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Carlos E. R. wrote:
> On 2011-12-08 12:00, Dave Howorth wrote:
>> The issue is (was?) that some of the tools couldn’t deal with them
>> (cfdisk for one, IIRC) and perhaps grub couldn’t (don’t remember). And
>> yes, the tools in Red Hat-derived distros were more up to date.
>
> Legacy grub can not. Fdisk can not, and it says so in the printed output
> from this disk. The partition layout we are working with may be wrong.

Hmm. You won’t want to read these articles about how to boot GPT disks
with legacy grub then:

http://www.wensley.org.uk/gpt
http://www.rodsbooks.com/gdisk/booting.html

But personally I use grub2 from Ubuntu to boot systems with GPT disks. I
gave up on opensuse grub a while ago, since I had so much trouble
configuring it. So I have three systems installed - Ubuntu, older
opensuse, newer opensuse. That way, I can usually find at least one that
will boot :slight_smile:

The principle when trying to recover data is not to do anything to the apparently damaged disk but to make a copy to another disk, normally with dd. Then you try to recover the data from the copy. This is explained very well in the System Rescue manual.

Given the information in the earlier posts, you really should read Online-Manual-EN - SystemRescueCd before you go any further.