parted doesn't handle extended partitions that don't leave at least a 2 sector gap

[TJ]

Parted fails to update the kernel partition table when an extended partition starts on the sector immediately following the EBR instead of leaving two sectors for LILO. This can cause otherwise apparently fine partitions to get "lost" during installation when parted deletes the kernel partition table and tries to recreate it and fails.

[TJ (tj)]

The previous experience was with the Jaunty alpha-3 live-CD.

The daily 0203.1 live-CD (amd64) displays the same behaviour, and in a much more simplified scenario. No use of LVM or encryption, just:

/dev/sda1 Windows Recovery ntfs ~9GB
/dev/sda2 Windows Vista ntfs ~28GB
/dev/sda3 Linux swap ~4GB
/dev/sda4 extended
/dev/sda5 Linux ext3 ~125MB
/dev/sda6 Linux ext3

And during manual partitioning assign sda5 to /boot/, and sda6 to /.

When the partitioning begins it fails silently an returns to the Wizard partitioning page.

Checking /proc/partitions reveals that both sda5 and sda6 are now missing:

Before:

major minor #blocks name

   7 0 690608 loop0
   8 0 390711384 sda
   8 1 9764864 sda1
   8 2 28738560 sda2
   8 3 4194304 sda3
   8 4 1 sda4
   8 5 122880 sda5
   8 6 347889719 sda6

After:

major minor #blocks name

   7 0 690608 loop0
   8 0 390711384 sda
   8 1 9764864 sda1
   8 2 28738560 sda2
   8 3 4194304 sda3
   8 4 1 sda4

[TJ (tj)]

I can provide remote ssh access to anyone that wants to observe/examine this issue.

[TJ (tj)]

I've tested a comprehensive set of partition layouts and it looks as if this issue is triggered *when an extended partition exists*, whether or not it has logical partitions and even if they aren't used by the installation.

In eight tests I tried variations of the location of /boot/ (as a primary and as a logical in the extended), before or after root, with and without a separate /home/.

I tried different partition sizes which caused the extended to be at different locations. I tried it with no logicals, logicals defined but not used, and of course, trying to use logicals.

Whenever an extended partition exists it is deleted by the installer, which removes everything within it. Therefore if the installer has been set to use one of the logicals it gets deleted which obviously leads to the failure.

Aside from this issue, the fact the installer silently fails without notifying the user is very confusing, especially if you've looked away whilst letting the installer get on with the job and return to find it at the partitioning page again.

I'm trying to figure out *why* this occurs. Is it possible that something in the layout of this particular disk is triggering the bug, or is it more widespread? The only thing I can see that is slightly non-standard is that the first primary partition starts at sector 2048 (usually it is at 63) - this layout was inherited from the previous 200GB disk-drive and didn't cause a problem when Feisty, Gutsy, and Hardy were installed from live-CD.

Luckily I have back-ups of everything so I am next going to try a new partition table with partition #1 starting at 63 - it is possible that partman is confused by the *empty* space at the start of the disk.

[TJ (tj)]

I've tested the theory that partition #1 starting at sector 63 might be the cause but unfortunately the logical partitions still go missing and the installer silently fails.

[TJ (tj)]

Re-tested with Jaunty alpha-4 live-CD (amd64). The problem remains.

[TJ (tj)]

Tested with Jaunty alpha-4 live-CD (amd64) in a kvm-83 virtual machine with one 5368MB qcow2 disk image with empty partitions pre-defined using fdisk -u /dev/nbd0.

I decided to check the partition table created by fdisk using cfdisk. It reported problems. Unfortunately the exact message scrolled out of the terminal buffer before I could copy it, but it was something like:

 "Bad primary partition 3: Partition ends in the final partial cylinder"

Thinking back to when the physical 400GB hard disk partition table was created I realised that an fdisk induced problem must have occurred. Initially the original partition table from the 200GB disk was written to the 400GB drive using dd.
Then I used fdisk *in sector mode* (fdisk -u /dev/sda) to remove partitions 3+ and recreate them with sizes more appropriate to the larger disk.

To test my theory, on the VM guest qcow2 disk image I wiped the partition table (which was also created using fdisk -u /dev/nbd0) and recreated it with fdisk in *cylinder* mode (fdisk /dev/nbd0).

This time the manual partitioner was successful and the installation succeeded in the VM guest.

I've looked at the partman log from the failed sessions and I don't see any problems with the reported partition start/end points (they are specified in absolute byte offsets from the start of the disk). There don't appear to be any overlaps and certainly nothing that could be described as "Partition ends in the final partial cylinder".

It makes me wonder if the same libraries used by partman to write the partition table are also used by cfdisk.

It would make sense to at least capture the error in ubiquity and report it to the user.

[Colin Watson (cjwatson)]

17:16 <IntuitiveNipple> cjwatson: I found it easy to recreate the issue: create the partition table with fdisk -u and start each partition on the next availabe sector number... in 'cyclinder' mode the end and next-start will be in the same cylinder... and that was the root cause

[TJ (tj)]

Here are instructions to reproduce the issue in a KVM/QEMU virtual machine using a live-CD ISO image. They create a qcow2 image, mount it using nbd, create the 'faulty' partition table using 'fdisk -u', and then start the VM guest with the live-CD.

qemu-img create -f qcow2 ubuntu-jaunty-install-test.qcow2 3500M
sudo modprobe nbd
sudo qemu-nbd -c /dev/nbd0 ubuntu-jaunty-install-test.qcow2
echo -e "o\nn\np\n1\n\n+100M\nt\n27\nn\np\n2\n\n+250M\nt\n2\n7\nn\np\n3\n\n+250M\nn\ne\n\n\nn\n\n+400M\nn\n\n\np\nw\n" | sudo fdisk -u /dev/nbd0
sudo nbd-client -d /dev/nbd0
sudo losetup /dev/loop2 jaunty-desktop-amd64-alpha4.iso

kvm -m 512 -boot d -cdrom /dev/loop2 -hda ubuntu-jaunty-install-test.qcow2

# when finished, do:
sudo losetup -d /dev/loop2

Start the desktop installer.
When the Partitioning page is reached, select "Manual"
Assign sda3 to /boot
Assign sda5 to swap
Assign sda6 to /

Move on to the installation phase. The partitioner will start-up and then close, returning to the "Prepare disk space" page.

In a terminal "cat /proc/partitions" will show that the logical partitions in the sda4 extended container have gone missing.

[Phillip Susi (psusi)]

I had noticed this bug in parted and worked up a patch to fix it several months ago, but it was never applied upstream. I'll do some poking.