'copy data' corrupts HD table

Bug #27916 reported by Henrik Nilsen Omma
8
Affects Status Importance Assigned to Milestone
debian-installer (Ubuntu)
Fix Released
Medium
Colin Watson

Bug Description

While performing an install of an i386 system on an amd64 machine, I made
several changes to the partition structure before saving to disk, including
setting up a separate /home partition, leaving some empty space and tried to
copy data from another drive. I'm not sure which of these caused the problem,
but there is the approximate chain of events (or steps to reproduce if you are
so inclined ...):

1. Started with a Maxtor 250GB IDE drive formatted with a single ext2 partition,
filled with physics data.
2. physically installed it in the machine as a secondary slave
3. Booted with a Live CD to look at the content -- the disk seemed fine (but the
data was no longer of use to me)
4. Ran the Ubuntu installer to completion with standard options, but elected not
to install Grub (because in the meantime I remembered that I wanted to partition
it differently) -- no errors were reported
5. Ran the installer again to set it up with more customised options
 * a small (20GB) ext3 partition for the system, a large (200GB) ext3 partition
for /home, the normal swap partition and some free space (20GB) for future test
installs of dapper
6. Selected 'copy data from another drive' to get the /home files from an
existing drive
 * The installer said it needed to write the changes to disk first, OK
7. The installer then fails to format the drives
8. Gparted running from a Live CD fails to remove the existing partitions citing
broken disk tables.
9. Running the installer again finds the disk and lets you partition it but not
write changes to disk

I'm not able to wipe the disk in any way, leaving it basically broken. I could
probably wipe it with a low-level formatting tool provided by the manufacturer,
but it might be good to keep it for forensic study (I can send it to someone by
post or bring it to the next Ubuntu sprint). As it happens I have several more
disks (from physics data collection) so I've since replaced it and reinstalled
Ubuntu, with more standard settings this time.

I admitedly did some very strange things during this install, changing my mind
several times, though I did try to complete each step, never switching off the
computer mid-process. I guess rendering an HD completely unuseable is
undersireable behaviour no matter how clumsily he goes about the install :)

Other information: The system is an AMD64 with 2GB RAM and an an existing 200GB
SATA drive with WinXP and Breezy AMD64 (which were unaffected). The attempted
install was an i386 Breezy CD (same CD worked fine on a new HD). Unfortunately
it is in the nature of the problem that there are no logs.

Revision history for this message
Henrik Nilsen Omma (henrik) wrote :

I believe this has been fixed some time ago. Closing.

Changed in debian-installer:
status: Unconfirmed → Fix Released
Revision history for this message
Colin Watson (cjwatson) wrote :

Erm, OK; what makes you think it has been fixed? Did you retest with Dapper? I wasn't aware that any of that code had been changed ...

Revision history for this message
Henrik Nilsen Omma (henrik) wrote :

Eh, sorry. I thought you had said that this had been fixed, though I don't remember the context now. It's obviously wasn't via bugzilla/malone. I have not tested this case again with Dapper, no.

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.