Linux experiencing issues with hard drive that Windows works with

Driagan

Distinguished
Sep 11, 2011
4
0
18,510
So I'm having a rather difficult time finding the correct place on the internet to ask this about. I think maybe this forum on Tom's Hardware can help me. If this is not the correct place, and you know a better place, please direct me there!

Basically, I have five hard drives in my server computer, one 1TB hard drive and four 3TB hard drives. I purchased all four 3TB hard drives about 4 months ago with the intention of setting up a RAID. I have only been using one of the 3TB drives to store data on and haven't touched the other three drives until recently (they've just been in the computer hooked to the power/SATA ports).

root@VMHost:~# fdisk -l

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x0002f4fa

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 499711 248832 83 Linux
/dev/sda2 501758 1953523711 976510977 5 Extended
Partition 2 does not start on physical sector boundary.
/dev/sda5 501760 1953523711 976510976 8e Linux LVM

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes
256 heads, 63 sectors/track, 363376 cylinders, total 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdb1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.

WARNING: GPT (GUID Partition Table) detected on '/dev/sdc'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders, total 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdc1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.

Disk /dev/sdd: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders, total 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0xffffffff

Disk /dev/sdd doesn't contain a valid partition table

Disk /dev/sde: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders, total 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0xffffffff

Disk /dev/sde doesn't contain a valid partition table

As you can see, they are /dev/sda - /dev/sde. The computer correctly recognizes two of the 3TB hard drives as being 3TB hard drives (and the partition tables on them). However two of the 3TB hard drives do not have valid partition tables.

So, upon investigating this, the first thing I did was open parted to attempt to create a GPT disk label and create a partition on the disks.

root@VMHost:~# parted /dev/sdd
GNU Parted 2.3
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt
(parted) print
Error: /dev/sdd: unrecognised disk label
(parted) quit
Information: You may need to update /etc/fstab.

When using parted (see above) I tell it to create a disk label, and it doesn't report an error. However, it doesn't create the disk label either. When I tell it to print the partition table, it just prints that the disk label is unrecognized.

I have done some reading, and it appears that the first 512 bytes of a hard drive are what's used to define the disk label and the partition table. So, I used dd to read the first 512 bytes of the disk.

root@VMHost:~# dd if=/dev/sdd bs=512 count=1 | xxd
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000703359 s, 728 kB/s
0000000: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000010: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000020: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000030: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000040: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000050: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000060: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000070: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000080: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000090: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000a0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000b0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000c0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000d0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000e0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000f0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000100: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000110: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000120: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000130: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000140: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000150: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000160: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000170: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000180: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000190: ffff ffff ffff ffff ffff ffff ffff ffff ................
00001a0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00001b0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00001c0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00001d0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00001e0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00001f0: ffff ffff ffff ffff ffff ffff ffff ffff ................

It appears that everything is set to hex of 0xff (or, in other words, every bit is set to 1). Very peculiar. So, I then follow this up with executing a dd to write all 0's to the first 512 bytes.

root@VMHost:~# dd if=/dev/zero of=/dev/sdd bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00147388 s, 347 kB/s

And follow that up with a dd to read the first 512 bytes again

root@VMHost:~# dd if=/dev/sdd bs=512 count=1 | xxd
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00566629 s, 90.4 kB/s
0000000: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000010: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000020: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000030: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000040: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000050: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000060: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000070: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000080: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000090: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000a0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000b0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000c0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000d0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000e0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000f0: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000100: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000110: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000120: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000130: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000140: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000150: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000160: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000170: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000180: ffff ffff ffff ffff ffff ffff ffff ffff ................
0000190: ffff ffff ffff ffff ffff ffff ffff ffff ................
00001a0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00001b0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00001c0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00001d0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00001e0: ffff ffff ffff ffff ffff ffff ffff ffff ................
00001f0: ffff ffff ffff ffff ffff ffff ffff ffff ................

From here on, I don't have example command output as these are things I have done in the past, but I will attempt to explain them in as much detail as possible. If needed, I will go back through the process and produce output.

However that doesn't appear to have made a difference. So at this point, I think there's something wrong with my hard drives. I took them out of the Linux computer and put them into my main desktop computer. From there, it is actually able to recognize the hard drives and I am able to successfully create a GPT label and even add a partition to it! So the hard drives do not appear to actually be bad! Taking the hard drives back from my Windows computer and putting them back in my Linux computer, both fdisk and parted are able to list the partitions, and dd is able to read that the first 512 bytes contains data.

I then used parted to delete the existing two partitions that Windows created (one that was a few MB and one NTFS that spanned the rest of the disk). However, upon attempting to remove a partition, I all of a sudden got the "unrecognized disk label" error again. Exiting out of parted and using dd resulted in all of the first 512 bytes being set to 0xff.

Things I have tried so far:

  • ■ I have removed the hard drives and swapped the SATA port being used with the SATA port of one of the hard drives that works, thinking maybe a couple of my SATA ports were not working properly
    ■ I have placed both hard drives into an external USB hard drive enclosure and connected the enclosure to the computer

All of which has not worked.

Here's the information about the computer:

Does anyone know why Linux appears to be unable to correctly write to the hard drives, but Windows appears to have no problem reading and writing to/from the drives?

Thank you in advance for any help!
 
Solution
Try opening the drive in WinHex or another hex editor to see what's going on with the first sector. I'm pretty sure those are a 4K sector drive, so you may not have zero filled enough to completely wipe out the MBR. Not sure why it's showing all FF though if you filled with zeros. Possibly the write failed for some reason.

DataMedic

Honorable
Nov 22, 2013
384
0
10,960
Try opening the drive in WinHex or another hex editor to see what's going on with the first sector. I'm pretty sure those are a 4K sector drive, so you may not have zero filled enough to completely wipe out the MBR. Not sure why it's showing all FF though if you filled with zeros. Possibly the write failed for some reason.
 
Solution
@Driagan, your problem has to be one of the most perplexing that I've seen for quite some time.

I'm just clutching at straws, but do all 4 drives have the same firmware? Are their manufacturing dates similar?

Gigabyte motherboards with Xpress Recovery BIOS will write a backup copy of the BIOS to the end of the drive and then reduce its capacity accordingly (by around 2000 sectors). This has resulted in problems under some circumstances. That said, it doesn't appear that this is affecting your system, but I wonder if there is some other BIOS related issue. In any case, my understanding is that BIOS only looks at the boot drive, and that it does not touch USB drives.
 

TRENDING THREADS