unable to create filesystem on 7.5TB partition with lucid beta

[BullCreek]

AMD64 Lucid BETA1 Alternate CD seems to have a problem with large filesystems. I'm thinking the kernel was probably built with the wrong options maybe, but not sure. I have another identical media server running AMD64 karmic with this setup running fine so this is something that got broken in lucid.

Setup is 12 750GB drives built into a RAID6 array using mdadm. The mdadm part works fine (in fact it works better in lucid than it ever has - I always had to Alt-F2 over to a console and build the array manually before but it works right in the GUI now - woohoo). Unfortunately, when I go to put a filesystem on the new RAID partition, I get:

ERROR!!!

partition length of 14651438080 sectors exeeds the loop-partion-table-imposed-maximum of 4294967295.

Hopefully this can be fixed before release - as quite a few mythbuntu folks have arrays > 2TB.

[BullCreek (jeff-openenergy)]

After trying some more things - I think this is a problem with the partition manager - not the kernel. If I switch over to console two during install and manually run mkfs.xfs or mkfs.ext4 or similar commands on the command line on the large partition, they work fine and I can then mount the newly created filesystem and checking dmesg everything seems fine so it seems to just be a problem with the GUI installer.

[hackeron (hackeron)]

I'm experiencing this problem as well, any workaround?

[BullCreek (jeff-openenergy)]

Well, my workaround was use the livecd and install mdadm, and configure the array manually on the command line before running the installer. It is far from a perfect install however, because you still have to manually boot into rescue mode after the install and install mdadm again and then mess with grub2 configuration to get things how they need to be. It seems that partman is broken for partitions > 2TB on the alternate install cd, but the routines that the ubiquity uses on the LiveCD works ok. I was going to try it against the latest daily build of the alternate CD to see if they fixed it but the daily builds of the alternate CD seem to be broken for the last couple days. Someone should reassign this bug to partman.

[BullCreek (jeff-openenergy)]

This bug still exist in the latest daily build. It seems that the alternate CD at present will not work with disks/partitions greater than 2TB.

[Derek Simkowiak (ubuntu-cool-st)]

This is a critical bug to me. Please fix before the 10.4 LTS release...

I've been building RAID6 6TB systems w/encryption on 8.04, 8.10, 9.04, and 9.10. What changed in 10.4 to break large file systems?

[BullCreek (jeff-openenergy)]

Yes, while it is possible to use the livecd to get a workable system with mdadm, it is a fairly involved process, and would be even more difficult to setup with encryption on top of that by hand. Hence, it would be nice to have an Alternate CD that worked like it used to! If this is just a resource issue of no one having time to look at it, if someone who is familiar with the code would have time to quickly walk me thru how to get the sources setup, I probably have cycles to fix it.

[Colin Watson (cjwatson)]

This is a parted bug. I agree it needs to be fixed for 10.04 LTS final. I'm going to wait until I get back home tomorrow and can test it on a sufficiently big disk, but in case anyone's interested I'm attaching my guess at a patch.

[Colin Watson (cjwatson)]

(Er, ignore the gnulib bit of that patch, of course.)

I've just done the calculations and I don't actually have a big enough disk to reproduce this. I'll probably upload it anyway, but would appreciate assistance with testing of a daily build after that.

[Colin Watson (cjwatson)]

I've added an erratum for this to https://wiki.ubuntu.com/LucidLynx/TechnicalOverview for the time being.

[BullCreek (jeff-openenergy)]

I will test it with the next daily build (looks like the current one out there was built on the 6th) or BETA2 whichever comes first. Thanks for looking into it!

[Colin Watson (cjwatson)]

This fix won't be in beta-2, since the images were already in final-stage testing before I started looking at this bug. Sorry.

[Cédric Dufour (cdufour-keyword-ubuntu-086000)]

In the mean time, I've been able to circumvent this bug and finish the installation process normally (using the Alternate CD beta-1 amd64 ISO image) by:

1. creating the physical partitions (fdisk) using the debian-installer's partition manager

2. [CTRL+ALT+F2] creating the RAID array manually:
mdadm --create /dev/mdX --level=5 --raid-devices=4 --chunk=256 /dev/sd[abcd]X # I chose to use 256k chunk size

3. creating LVM volumes manually:
pvcreate /dev/mdX # NB: LVM seems to recognize the chunk size and align optimally, cf. pvs -o +pe_start
vgcreate vg.raid5 /dev/md2
lvcreate -n lv.root -L10G vg.raid5
lvcreate -n lv.var -L10G vg.raid5
lvcreate -n lv.tmp -L10G vg.raid5

4. [CTRL+ALT+F1] Click on "Go Back" in the debian-installer partition manager and click on "Partition Disks" again (partition layout is refreshed); the error is still there (and the /dev/mdX itself can not be used directly) BUT the logical volumes are there and available for use. At the end of the installation, the system reboot and starts flawlessly (the RAID configuration is created successfully by the debian-installer, despite the error displayed by 'parted'

5. Create any "big" logical volumes you need (see 3.) once rebooted

PS: even though LVM was used on top of RAID5, bonnie++ performances match what can be expected of the setup (120MB/s block write, 300MB/s block read).

Still a hack, but allows to go through the installation process. Hopes this helps

[Launchpad Janitor (janitor)]

This bug was fixed in the package parted - 2.2-5ubuntu2

---------------
parted (2.2-5ubuntu2) lucid; urgency=low

  * loop-limits.patch: Remove limits on loop labels (LP: #543838).
 -- Colin Watson <email address hidden> Fri, 09 Apr 2010 15:13:57 +0100

[BullCreek (jeff-openenergy)]

Unfortunately, I just tried it with today's daily build (April 10) and assuming it has the fix, it still gives the same error. Let me know how else I can help.

[Colin Watson (cjwatson)]

Please attach /var/log/syslog and /var/log/partman from the installer.

[BullCreek (jeff-openenergy)]

Here you go.

[BullCreek (jeff-openenergy)]

And the other one.

[Colin Watson (cjwatson)]

It looks as though I missed out a necessary piece of the patch for this.

[Colin Watson (cjwatson)]

Fixed, and this time I actually managed to test it with the aid of KVM. I restored it to LucidLynx/TechnicalOverview for the RC, since I've missed the boat there.

[Luke has no name (lukehasnoname)]

If this bug is fixed in the RC release being distributed, then it should not be on the release notes for the RC as a bug.

Good job.

[Steve Langasek (vorlon)]

it's not fixed in the RC; that's why it's marked 'fix committed', not 'fix released'.

[Luke has no name (lukehasnoname)]

Apologies.

[Launchpad Janitor (janitor)]

This bug was fixed in the package parted - 2.2-5ubuntu5

---------------
parted (2.2-5ubuntu5) lucid; urgency=low

  * limit-diagnostics.patch: Fix diagnostics about exceeding partition
    limits.
  * loop-limits.patch (update): Rebuild libparted/labels/pt-limit.c from its
    gperf source (LP: #543838).
 -- Colin Watson <email address hidden> Wed, 21 Apr 2010 14:18:50 +0100