Resizing partition results in data loss

Bug #45597 reported by Billy Charlton
This bug report is a duplicate of:  Bug #45543: Serious Data Loss resizing partitions. Edit Remove
8
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
New
Medium
Unassigned

Bug Description

Binary package hint: ubiquity

Resizing an existing partition during an ubiquity install fails, resulting in severe, unrecoverable data loss.

System:

- Fairly standard PC (HP brand-name machine, Windows XP pre-installed, 80Gb HD, 1GB RAM, Pentium 4 2.4 GHz)
- Hard disk had two partitions, a small "system recovery" FAT32 partition from the manufacturer, and a 70Gb NTFS partition with Windows XP and user files.

Steps to reproduce:

1. Booted off live CD (Dapper Beta 2, PC Version) and ran ubiquity.

2. Chose "manual partitioning" because the default option, "resize existing HD" did not give enough UI feedback for me to feel comfortable resizing. Specifically, I couldn't see how full the existing partition was so I didn't know how much I could shrink it. From past experience I knew that the manual installer gave a nice UI which showed percent freespace.

3. From manual partitioning screen, I right-clicked the existing NTFS partition, and picked "Resize". The partition was about 50% full, so I dragged the bar to around the 75% mark so the freespace would be split evenly between the existing NTFS partition and the new partition.

4. The GUI was then very confusing, it showed a list of "actions" that would take place sometime later, and some free space. I wasn't sure if I was supposed to just click "next" or actually create a partition in the free space. I chose to right-click the free space and choose "New". The dialog that popped up had partition type set to "ext2" which I figured was wrong, and we set that to ext3 and clicked OK.

5. After clicking next (or was it forward), a dialog popped up saying "resizing..." but I don't remember the exact wording. It was quickly replaced by a "Failed" dialog whose wording I also don't remember.

6. At this point the installer showed two partitions where there used to just be the NTFS partition. Both were marked type "Unknown". The first was almost the original size of the existing partition, perhaps slightly smaller. The second was very small (I think 7Mb).

7. Sensing disaster, we panicked, cancelled, and rebooted the machine. Windows would not boot.

I spent the entire evening trying to recover the lost partition, using tools such as testdisk, gpart, ntfsresize. No tool could even recognize the partition as NTFS, even when I attempted to rewrite the partition table to its original contents. It's as if the partition was partially written overwritten in some catastrophic way, but I don't have a way to verify that.

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

(This is not obviously a duplicate of bug 45543, because that other bug used a different resizing method. I would really prefer people to leave it to me to mark Ubiquity bugs as duplicates if appropriate.)

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

OK, I think I've worked out why this is happening: when we run partman to commit the results of manual partitioning, we aren't forcing it to use manual partitioning, and so it sometimes decides to do some kind of autopartitioning instead and gets horribly, horribly confused.

This is fortunately fairly easy to fix. I'm on it as a matter of urgency now ...

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

Turns out that this is a duplicate of bug 45543 after all, although it took some investigation before I could be sure of that.

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.