Arch Linux

fyhuang

Member

Registered: 2010-09-30

Posts: 3

Arch has trouble with GPT disks?

Hi,

I'm new to Arch, but not to Linux. I had a NAS system set up before with Ubuntu Server and a 2 TB hard drive, formatted with GPT and two partitions. The second partition, in particular, extends to the end of the disk (or as far as GPT will allow it to go; there apparently needs to be room for a backup GPT table at the end). In my previous Ubuntu setup, this arrangement worked fine. This system also has the operating system loaded onto a separate disk.

Recently I replaced Ubuntu with Arch. I tried to access the data I had stored in my 2TB drive, but found that Arch was unable to detect the second partition. I fired up parted and was informed that the second partition extended past the end of the disk. It wouldn't even print the partition table, so I tried gdisk instead (a GPT fdisk) - it reported some errors but was able to print my partition table. I feared for the safety of my data, so I switched back to my Ubuntu disk temporarily and ran some checks there.

Turns out Arch thinks the disk is smaller than it really is, and in the process of scanning the disk detected that the backup GPT table "wasn't at the end", so therefore wrote a new backup GPT table at the new "end". That is to say, it wrote over the end of my second partition. Fortunately, no data was lost, but I did get these numbers from running gdisk on both Ubuntu and Arch:

• Ubuntu's gdisk says the disk contains 3907029168 sectors, and that the last usable sector is 3907027021. This seems sane to me.

• Arch's gdisk says the disk contains 3907027055 sectors, but that the last usable sector is 3907029134. You will note both that Arch reports fewer total sectors than Ubuntu, and that the "last usable sector" in Arch is past the end of the disk by either measure.

I triple checked the numbers in Arch - I didn't accidentally reverse the two. Parted in Arch also returns the same value for disk size in sectors, so this makes me think that there is something odd going on with the Arch kernel, possibly relating to GPT? For the record the drive is a WD Caviar Green - WD20EADS, perhaps? It's a 4k sector drive, but reports 512-byte logical sectors - could that be a factor here?

I'm just wondering if anyone else has encountered this problem and/or if anyone has discovered any clever workarounds.

Cheers!

.:B:.

Forum Fellow

Registered: 2006-11-26

Posts: 5,819

Website

Re: Arch has trouble with GPT disks?

My AppleTV needs a GPT layout on the internal HD for it to be bootable (I installed Arch on it) and I have had no trouble whatsoever. The bootloader is custom, but e.g. when I take out the HD and connect it to my laptop via USB I can manipulate data on the partitions just fine.

---

Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy

skodabenz

Banned

From: Tamilnadu, India

Registered: 2010-04-11

Posts: 382

Re: Arch has trouble with GPT disks?

I think the problem is not due to GPT but due to 4K sectors (especially when the drive reports as 512-byte logical sectors). Ubuntu's gdisk 0.5.1 is way too old (nearly a year). Arch includes gdisk 0.6.10 which has bugs squashed out. So between Ubuntu's and Arch's gdisk, trust Arch. In any case compare parted 2.3'g output with gdisk 0.6.10 (latest is 0.6.11 BTW) and report any unsual findings. Your best option would be to contact the author of gdisk Rod Smith http://rodsbooks.com/gdisk/ . He has experimented with 4K drives so he will guide you better. Unfortunately he is not a user of this forum (not an Arch user). You can reach him through his mail id in his website or as srs5694 user in Ubuntu forum or Insanelymac forum.

---

My new forum user/nick name is "the.ridikulus.rat" .

fyhuang

Member

Registered: 2010-09-30

Posts: 3

Re: Arch has trouble with GPT disks?

Well, I had originally suspected differences between the gdisks, but comparing parted's output with gdisk on Ubuntu, both report the same disk size. Also, on Arch, gdisk reports the last sector to be beyond the end of the disk as reported by gdisk - therefore, I'm currently not inclined to trust the numbers from gdisk. So unless parted and gdisk have the same bugs in their GPT code, the above leads me to suspect some kernel bug or something - I will try updating my kernel and see what happens. Thanks for the advice!