2

I have an external hard disk that I share between my Linux laptop and my Windows 10 desktop. The disk has a GPT table, with a NTFS partition and a partition encrypted with Truecrypt.

The disk works absolutely perfect with Linux. I can see and modify all data on both partitions. Whenever I plug the drive into my Windows machine, it seems to be functioning fine, I get no errors or warnings of any kind.

When I remove the disk from my Windows computer and plug it into my Linux, the laptop doesn't even try to mount the drive, and no errors are given. I looked in gParted and it told me the primary GPT table was corrupt. I proceeded to use gdisk (fdisk for GPT) to repair the GPT table from the backup. This is successful, and I can use the drive normally. That is, until I plug it into my Windows computer again. EVERY time I plug into my Windows I need to repair the primary GPT table to use it in Linux.

What I'm really asking is, what is causing this and how can it be stopped? It's VERY annoying to have to repair the disk all the time.

EDIT: The disk is a 320 GB (so a little under 300 formatted) and is manufactured in 2012. Logical Sector Size is 512 bytes. The first partition is a 128 MB partition starting on sector 34 (first usable) with the msftres flag. I'm assuming this was automatically created by Windows. The output of sgdisk -v /dev/sdb after Windows damages the GPT has only a few interesting points:

 Warning! Main partition table CRC mismatch! Loaded backup partition table instead of main partition table!
 Problem: The CRC for the main partition table is invalid. This table may be corrupt. Consider loading the backup partition table ('c' on the recovery & transformation menu). This report may be a false alarm if you've already corrected other problems.
 Caution: Partition 1 doesn't begin on a 8-sector boundary. This may result in degraded performance on some modern (2009 and later) hard disks.

sgdisk -p /dev/sdb shows partition table to be as follows:

 Disk /dev/sdb: 625142448 sectors, 298.1 GiB
 Logical sector size: 512 bytes
 Disk identifier (GUID): 3747C42F-4A37-41D4-AF66-1A56BA4B347C
 Partition table holds up to 128 entries
 First usable sector is 34, last usable sector is 625142414
 Partitions will be aligned on 8-sector boundaries
 Total free space is 4717 sectors (2.3 MiB)

 Number  Start (sector)    End (sector)  Size       Code  Name
   1              34          262177   128.0 MiB   0C01  Microsoft reserved part
   2          264192       409864191   195.3 GiB   0700  Basic data partition
   3       409864192       625139711   102.7 GiB   0700  Basic data partition
  • I have my Windows on a SSD so I disabled hibernation entirely with powercfg. – NickS Jul 10 '16 at 5:24
  • Darnit, worth a shot. – mchid Jul 10 '16 at 5:38
  • What size is the disk? Does it use 512-byte or 4096-byte logical sectors? (The physical sector size is unimportant.) The output of sudo sgdisk -v /dev/sdb (or whatever the device filename is) after Windows has damaged it might be helpful in identifying the problem. Likewise, sgdisk -p /dev/sdb (or gdisk -l /dev/sdb) might provide some clues. Add this output to your original question, placing four spaces before each line of the text-mode programs' output. – Rod Smith Jul 27 '16 at 18:30
  • "The disk works absolutely perfect with Linux. I can see and modify all data on both partitions. Whenever I plug the drive into my Windows machine, it seems to be functioning fine, I get no errors or warnings of any kind. " seems to be a problem in windows... and possibly a bug. off topic?! – Rinzwind Jul 28 '16 at 19:57
  • It could be a bug in Windows GPT partitioning somewhere, but the disk works fine in Windows and not Linux. Perhaps I should clone my partitions and rebuild the disk using Linux? – NickS Jul 28 '16 at 20:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.