Installer: ntfs resize of second partition with non-cylinder boundary start point creates incorrect partition table/broken ntfs partition.

Bug #19000 reported by Ublinux
8
Affects Status Importance Assigned to Milestone
partman-base (Ubuntu)
Fix Released
Medium
Colin Watson

Bug Description

Ok,

My partner and I purchased a pair of Samsung X15 Plus laptops last weekend, and tried resizing
the ntfs windows partitions on the machines using the Hoary Installer. This caused the
partitions to be unusable, although the base filesystem appeared to be successfully resized.
Being as we preferred fat32 partitions anyway, was no big deal in the end as we simply
reinstalled windows on a recreated fat32 partition instead.

As far as I could tell, the reason for the error is that these notebooks came with a default
10Mb partition from Samsung immediately before the ntfs partition. This first partition did not
end on a cylinder boundary. There was no gap between the first partition and the ntfs one.

When the ntfs partition was resized, the start point of the ntfs data was not moved, but the
partition start point written to the partition table refused to begin at a point that was not
the beginning of a cylinder boundary. So, the partition table stated that there was a 0.3Mb gap
between the first and the second partition. This chopped off the first 0.3Mb of ntfs data,
rendering the partition unbootable/unusable.

Using an ubuntu live cd (and later a knoppix one as well), I could mount and gain read access to
the broken ntfs partition in knoppix, and verify that it had indeed been resized. I tried using
cfdisk to "recreate" the partition in the partition table, but it would not generate the
partition starting at the end of the first one, still insisting on leaving a 0.3Mb gap between
them (silently, I may add - the gap was only visible when rerunning cfdisk; it did not get shown
on the process that regenerated the parition).

I assume here that the failure is due to the layout of the original ntfs partition not starting
on that cylinder boundary; while not a problem for us this bug is a potential system destroyer
for anyone who has a hidden manufacturer's "system change" partition at the beginning of the
drive, since the start point of the ntfs partition is unpredictable.

Unfortunately I'm no longer in a position to be able to test this further having replaced the
ntfs partitions with fat32, but I hope that reporting the failure and it's apparent cause may be
of use/benefit in improving the installer for future use.

Feel free to ask any further questions if needed, and I'll answer to the best of my ability to
remember :).

Cheers,
Dawnmist.

Revision history for this message
Ante Karamatić (ivoks) wrote :

NTFS resizing in Ubuntu? Hm... I don't think there is an option for that in
installer.

Revision history for this message
Ublinux (ublinux) wrote :

(In reply to comment #1)
> NTFS resizing in Ubuntu? Hm... I don't think there is an option for that in
> installer.

Hmm...

If you read the ubuntu forums, in several posts it says that the Hoary installer is capable of resizing
ntfs partitions,and that this was something new to hoary.

In the installer, the partitioning tool does permit the user to select an ntfs partition, and then to
choose to resize it. It warns that changes will be written to the disk, etc; but at no point does it say
"oops, cannot resize this partition cause it's ntfs".

From the official installation doc:
http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-i386/current/doc/manual/en/ch03s05.html

3.5.1.1. Lossless Repartitioning When Starting From DOS, Win-32 or OS/2

One of the most common installations is onto a system that already contains DOS (including Windows 3.1),
Win32 (such as Windows 95, 98, Me, NT, 2000, XP), or OS/2, and it is desired to put Ubuntu onto the same
disk without destroying the previous system. Note that the installer supports resizing of FAT and NTFS
filesystems as used by DOS and Windows, and in most cases you should not need to use the method
described below, unless you need to move the start of the filesystem.

So either there are some serious documentation problems and misinformation being given out in the
forums, or yes, resizing ntfs partitions is an option in the installation process.

Revision history for this message
Szabolcs Szakacsits (szaka) wrote :

Nice description Dawnmist.

As being the ntfsresize author, I can confirm this Partman problem. Several
other frontends (e.g. QTparted, YAST) had or still has the same problem.
Ntfsresize can not do anyhting about this because it's a partitioner bug.

One of the ways to restore the right partition table is using fdisk and setting
the work unit as sector, not cylinder. Sadly, most people think that the
filesystem was damaged, not the partition table and they destory the original
filesystem themself by reinstalling Windows.

Revision history for this message
Colin Watson (cjwatson) wrote :

While I'm not sure that it's a duplicate, this reminds me of bug 32529. I suspect a parted problem ...

Revision history for this message
Colin Watson (cjwatson) wrote :

This was a parted_server bug, and should be fixed in Feisty.

partman-base (105) unstable; urgency=low

  * Correct mode in mkfifo call. Thanks to Ben Hutchings. Closes: #412769.
  * Fix the way libparted is called when resizing partitions with a file
    system that libparted does not support. Many thanks to Ben Hutchings
    for the patch. Closes: #380226.

 -- Frans Pop <email address hidden> Wed, 7 Mar 2007 22:47:26 +0100

Changed in partman-partitioning:
status: Unconfirmed → Fix Released
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.