2.6.20 in feisty can't mount EIT/GPT Partition Tables with more then 2TB size

Bug #127125 reported by Stephan Rügamer
This bug report is a duplicate of:  Bug #107326: non working gpt labels. Edit Remove
4
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Incomplete
Undecided
Unassigned
Declined for Feisty by Henrik Nilsen Omma
Declined for Gutsy by Henrik Nilsen Omma
linux-source-2.6.20 (Ubuntu)
Won't Fix
Undecided
Unassigned
Declined for Feisty by Henrik Nilsen Omma
Declined for Gutsy by Henrik Nilsen Omma

Bug Description

Binary package hint: linux-source-2.6.20

Update: It's 64bit Ubuntu :)

The following hardware configuration was used to install feisty, which failed (not completly):

1. OEM Hardware, 2x Dual Core Opteron, 16GB Ram, Areca SATA Raid6 Controller, 16x500GB Drives in RAID6 mode, with two volumes
    First Volume: 73 GB
    Second Volume: 6.3TB

2. HP Series:
    2.1. HP DL365, 16GB Ram, 2x Dual Core Opteron P800 SmartArray Controller, 4 Internal SAS drives, external MSA 60 Storage with 12x 750GB Drives attached
           3 Volumes:
               - First Volume: Raid1 over 2 Sata drives, 120GB, (Internal)
               - Second Volume: Raid1 Over 2 Sata drivers: 120GB (Internal)
               - Third Volume: Raid6 over 12x 750GB Drives (external storage)
     2.2. DP DL320s, P400 SmartArray, 1x Dual Core Xeon, 12x 500GB internal SATA Drives
            2 Volumes in Raid6 Mode:
               - First Volume: 80GB
               - Second Volume: The rest (more then 4 TB)

As install media a feisty server cd image was used, d-i recognized all controllers and volumes without any problems.
Creating the necessary partitions on the volumes works, too, even on the >2TB ones. The partition tables are for <2TB partitions: msdos lable, for the >2TB ones they are EIT/GPT tables, which is also correct.

The reboot into the production system failed with mounting every >2TB Partitions. Logfile told me (as only error report), that the superblock on those partitions is corrupted. On all >2TB partitions, XFS as filesystem was used. The same applies to all other partitions but the boot partitions, which is ext2.

Recreating the partition manually with parted and reformating the partition with mkxfs works again, and the volume is mountable. Rebooting it afterwards results in the same error message.

Deleting the EIT/GPT table from the volume, and creating the XFS FS directly on the blockdevice (e.g. /dev/sdb (areca) or /dev/cciss/c0d1 (smart array controller) and changing fstab and rebooting, the volume is mounted without any error and works as expected.

This setup but worked with dapper (at least with the OEM machine, because dapper doesn't know anything about the p400/p800 controller and doesn't recognize the large volumes (means >2TB), HP changed the cciss driver after dapper release).
So, regarding Feisty, this is a regression. I didn't tested edgy, because we use normally dapper as Ubuntu Distro (hint on LTS).

I know that this setup is not the standard, but since most DCs are in need in cheap storage solutions (SAN is not cheap ;)) machines like the DL320s from HP will become more popular. You can't even compare those machines (and their setups) with Suns X4500 (6 Raid7 Controller with 8 Drives per controller, so 48 drives in one cage).

If you need more information, please contact me directly via this bug report or by eMail/jabber, the contact infos are on my launchpad page.

Regards,

\sh

description: updated
Revision history for this message
Stephan Rügamer (sruegamer) wrote :

Some more informations:

Doing all this with a vanilla kernel (2.6.19.2 over 2.6.20.x to 2.6.22.1) (using EIT/GPT tables/labels) works as expected. Just installing feisty with a individual kernel is a mess regarding d-i recompilation.

Revision history for this message
ngregory (ubuntu-openenterprise) wrote :

This sounds like the same issue I've had on a number of servers using x86_64 feisty with a Areca 1160 and 16 500GB+ drives. Install goes fine however on booting from array the kernel complains of corrupted superblocks on larger TB filesystem (/dev/sda3).

After a bit of googling tracked issue back to follow ubuntu bug #107326 - parted is creating corrupt gpt labels for large filesystems. Parted on dapper is able to spot and fix the corruption (grub needs a re-install after the fix).

Revision history for this message
Stephan Rügamer (sruegamer) wrote :

Well,

I just tested SLES10 Service Pack1 and ran into the same error.

Regards,

\sh

Revision history for this message
James Troup (elmo) wrote :

I can't speak to the rest of the bug, but I can confirm, for what it's worth, that 2.6.21 (upstream) (and thus presumably, gutsy) fixes the cciss driver to handle >2TB devices.

Revision history for this message
Stephan Rügamer (sruegamer) wrote :

@James,

feisty can handle cciss and 64bit LBA properly...just eit/gpt tables are borked.

Regards,

\sh

Revision history for this message
Chuck Short (zulcss) wrote :

I just checked and the patches were applied for gutsy: These are the patches mentioned:

http://lkml.org/lkml/2006/9/11/242
http://lkml.org/lkml/2006/9/11/245

Revision history for this message
Stephan Rügamer (sruegamer) wrote :

@Chuck,

as I said before, feisty does know everything about cciss and 64bit LBA support.
This is not the problem.

I think more it's a problem with parted...

I found this:
http://parted.alioth.debian.org/cgi-bin/trac.cgi/ticket/43
http://parted.alioth.debian.org/cgi-bin/trac.cgi/ticket/30

Revision history for this message
Launchpad Janitor (janitor) wrote : This bug is now reported against the 'linux' package

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this bug to the new "linux" package. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. Thanks!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.