Installer corrupting partition table

[steve.horsley]

Installer for Ubuntu Dapper flight 4 corrupted my partition table by changing the starting cylinder of my windows partition. I am not really sure if this bug should be against the installer or against parted.

Here is the output of fdisk -l before installing dapper:

Disk /dev/hda: 80.0 GB, 80026361856 bytes
16 heads, 63 sectors/track, 155061 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot Start End Blocks Id System
/dev/hda1 1 1938 976720+ 83 Linux
/dev/hda2 52801 155056 51536520 5 Extended
/dev/hda3 * 1939 52801 25634920+ c W95 FAT32 (LBA)
/dev/hda5 52802 62491 4883728+ 83 Linux
/dev/hda6 62492 72181 4883728+ 83 Linux
/dev/hda7 72182 74126 979933+ 82 Linux swap / Solaris
/dev/hda8 74126 155056 40789003+ 83 Linux

Partition table entries are not in disk order

And here it is after running the dapper installer:

Disk /dev/hda: 80.0 GB, 80026361856 bytes
16 heads, 63 sectors/track, 155061 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot Start End Blocks Id System
/dev/hda1 1 1938 976720+ 83 Linux
/dev/hda2 52801 155056 51536520 5 Extended
/dev/hda3 * 1945 52801 25631707+ c W95 FAT32 (LBA)
/dev/hda5 52802 62491 4883728+ 83 Linux
/dev/hda6 62492 72181 4883728+ 83 Linux
/dev/hda7 72182 74126 979933+ 82 Linux swap / Solaris
/dev/hda8 74126 155056 40789003+ 83 Linux

Partition table entries are not in disk order

I can provide 512 byte images of the bootsector before and after if required.

Current usage of the partitions is:
1 /boot with grub on it
3 windows
5 Mandrake - now overwritten with Ubuntu dapper flight 4
6 Ubuntu Breezy
7 swap
8 /mnt/data

When I first ran the Ubuntu dapper installer, I chose manual partitioning. I was presented with a menu offering partitions 1, 5, 6, 7, 8. I was surprised not to see #3 listed, but carried on. I told the installer not to mount 1, 6, 8, and to format 5 and use it as root. Looked like this:
1 K ext2
5 F reiserfs /
6 K reiserfs
7 F swap
8 K reiserfs

Strangely, When choosing OK, I got a warning saying: "This ext2 file system has a rather strange layout! Parted can't resize this (yet)." This was a little worrying, since I didn't ask to resize anything, I said not to mount #1.

Anyway, I chose to continue and got this message:
"Test of ext2 partition #1 had uncorrected errors. Go back to correct?" and I chose not to go back.

After all that, #1 was not re-sized, but #3, my windows partition was. By moving the start cylinder (something I understand parted can't do yet).

I admit that the partition entries are unordered due to previously deleting windows and splitting the space into two, but I don't think that's an excuse for this. It may be the cause of the confusion though.

P.S. the original partition table was (IIRC) last edited by cfdisk.

[Colin Watson (cjwatson)]

Did you complete this installation in the end? If so, could you attach /var/log/installer/partman to this bug, so that I can get exact information about what partman/parted thought they were doing between them?

[steve.horsley (steve-horsley)]

AS requested, partman log file.
I am 95% sure this is the right log file. There is a small chance I installed again but don't remember having done so. Sorry I can't be 100%, and I hope I'm not leading you up the garden path.

[Colin Watson (cjwatson)]

Well, this log is perfect. Thanks a lot! It shows pretty clearly that the GET_RESIZE_RANGE command to partman's parted_server command, issued while building the autopartitioning menu, is changing the start offset of hda3. From partman's point of view I think this is Not Supposed To Happen (GET_RESIZE_RANGE is meant to be essentially a read-only command, modulo some fiddling with extended partitions and constraints), and something is therefore rotten in the state of libparted.

[mannheim (kronheim)]

I don't know if this is exactly the same bug, but it might be: there are several reports today (one day after dapper was released) of people "losing" their NTFS partitions after the installer tried to resize them. See the thread at

http://www.ubuntuforums.org/showthread.php?t=186395

Shouldn't the severity of this bug be higher than "normal" if the installer is causing new users to lose their data.

[Colin Watson (cjwatson)]

http://bugs.debian.org/379835 seems similar to this one.

[Martin Andersen (msandersen)]

Seems to be the same as bug#19000
https://launchpad.net/distros/ubuntu/+source/partman-partitioning/+bug/19000
The author of ntfsresize confirms a problem in Partman and other partitioners like gParted and QTparted. I don't know the status with the current gParted 0.3, though.

[Rolf Leggewie (r0lf)]

I guess something is indeed wrong. But what struck me when reading through the report report is: Don't partitions 2 and 3 overlap at cylinder 52801 (which is not used in the end in the hda2 container, but nonetheless)?

[steve.horsley (steve-horsley)]

If end is last-used rather than first-free, then so do partitions 7 and 8.

I think the table had been manually edited with cfdisk to create those
partitions, and then Linux installed into the existing partitions, but I'm
not certain - it's been a long time.

This doesn't necessarily mean that the partitions actually overlap though,
it just means that the partitions don't start and end on a cylinder
boundary. I think this is what the + symbol means. They may well end halfway
through a cylinder and the next one start on the following sector, still in
the middle of the same cylinder. To know exactly, you need the detailed
partition table rather than this summary printout. Is anyone interested in
the 512 byte bootsector images of before and after if I can still find them?

On 27/10/06, Rolf Leggewie <email address hidden> wrote:
>
> I guess something is indeed wrong. But what struck me when reading
> through the report report is: Don't partitions 2 and 3 overlap at
> cylinder 52801 (which is not used in the end in the hda2 container, but
> nonetheless)?
>
> --
> Installer corrupting partition table
> https://launchpad.net/bugs/32529
>

[Rolf Leggewie (r0lf)]

Steve and Colin, what are we gonna do with this one?

[Colin Watson (cjwatson)]

Well, Rolf, you assigned it to yourself so I guess you're volunteering. ;-) This bug is not Incomplete as far as I know, unless there's some particular piece of information that you are requesting from the submitter. If so, you should say what it is. If not, please undo your change and leave it at Confirmed.

To be frank, I was rather hoping that upgrading to a more current version of parted in 8.10 would do the trick ... we are rather behind there, and this is buried in very deep magic inside parted with which I'm not familiar.

[Rolf Leggewie (r0lf)]

Colin, it was my impression that for bug triaging purposes and to ascertain whether or not an old bug was still valid, one would mark a bug as incomplete, assign it to oneself and wait for confirmation that the issue is still present. So particular piece of information I am requesting remains "Steve and Colin, what are we gonna do with this one?" ;-) I found it strange for such an important bug (we are talking data here!) to still be present but without activity for 18 months. I was wondering if the issue hadn't been dealt with in the meantime.

[Colin Watson (cjwatson)]

Incomplete is for requesting more information *from the reporter*, not for nagging developers; so I'll revert your changes and set it back to Confirmed (i.e. "enough here for a developer to work on"). Of course, help on this would be welcome.

[Phillip Susi (psusi)]

This bug is extremely old and I find it hard to believe that it would still be happening without many people reporting it, so I am going to venture a guess that it was fixed a long time ago. Is anyone still able to reproduce this?

[Launchpad Janitor (janitor)]

[Expired for parted (Ubuntu) because there has been no activity for 60 days.]