The reinstall would not reset anything on partitions it did not write to. Ubuntu just looks at what the partition boot record and file system tables show. My guess is that the boot record still contains elements copied from the iso file.

Ok, now I'm thinking of just starting over, wiping it all completely.

I saw in another thread http://www.linuxquestions.org/questi...=554533&page=2

that I can maybe preserve my Windows XP install using dd to clone my Windows partition. However, since my goal is to get rid of these pesky MBR/partition problems, is there a way to do this that will ensure a fresh start when I copy everything back?

e.g. I want to keep my Windows apps, data, settings, but have it all be on a freshly partitioned drive.

Before going through allot of work, you should try Windows System Restore and restore it to a time prior to the incident, you can reverse any restore back to where you are now if it does not pan out. The dd copy will be exactly the same as the original. I don't think the partition table in the MBR is preventing Ubuntu from mounting Windows, rather it is errors in the NTFS partition.

One of the ideas behind a journaling file system is to avoid the lengthy times it takes for a file system integrity check utility to check the file system on a very large drive/partition. Because of journaling, file system check utilities just check the changes that were last implemented as reported in the journal.

EDIT: You can also run scandisc manually in Windows XP by opening My Computer and right clicking on the drive and select "properties/tools/error checking"

You can use udevinfo to examine the present uuid on the filesystem. One of the ntfstools programs may be able to create a new UUID number for your ntfs filesystem.

udevinfo -q env -n /dev/sda1
Look at what the label on the partition says as well.

http://packages.ubuntu.com/warty/otherosfs/ntfstools

Here's the output from udevinfo:

I'll try the ntfstools also.

I just tried using dd to overwrite the MBR completely to be zeros using

Ubuntu booted up after that, so maybe I should have done /dev/sda instead of /dev/sda1. I'm trying obliterate the MBR and partition table and rebuild it, hopefully removing traces of the "vmware tools" iso.

Thing is, the Windows partition works OK (After fixboot), it's mountable, writable in ubuntu, boots into Windows ok, but it shows up as a joliet filesystem.

If you wipe out the mbr, you won't be able to boot, and you will loose the partitioning information.

You could relabel the disk either in windows for a windows partition or using ntfslabel.

What does "sudo file /dev/sda1" say about the filesystem?
Look at "sudo /sbin/fdisk -l". Is the filesystem ID a 7? (Although there isn't an iso9660 filetype entry, so maybe that isn't where the system is thinking the fs is iso9660.)

Example:
If the files are now readable, you might want to backup the files, reformat the partition, and restore the files you need.

If you actually did this, you wiped out the boot record on that partition. This will keep you from accessing that partition. You'll need to fix that. This is your ntfs partition, right? There are tools to fix it. I believe testdisk will fix it.

You don't want to eliminate the partition table.

Well, I did the overwriting the MBR of /dev/sda. I then used GPartEd and testdisk to rebuild the partition table.

Still the same (though I had to reinstall grub to the MBR). Where on earth is Ubuntu getting the information it lists in the Device Manager and properties->volume?

"sudo fdisk -l" shows the partition as type 7 and "sudo file /dev/sda1" comes back "/dev/sda1: block special (8/1)"

Sorry, I missed an option.
sudo file -s /dev/sda1

Ok, I think I was able to repair what was wrong. Instead of just wiping the MBR, I used dd to write zeros to the first 13.8mb of the disk, the same size as the iso I accidentally copied to /dev/sda1. Then I did the same stuff as before, repaired the partition, MBR, fixboot. I haven't checked to see if Windows boots yet, but I'm confident that I can get that working.

Now in ubuntu, things appear to be correct. The volume now mounts as "sda1" instead of "vmware tools" and it reports the volume as NTFS in both properties and the device manager.

Here's the output of "file -s /dev/sda1" before the changes (I made a clone with dd):

Here's after the changes:

Now the only thing that I'm wondering is if I need to set a UUID for the NTFS volume somehow. I think prior to the mishap, there was a UUID, but I haven't been able to find anything on how to set UUIDs for NTFS volumes (lots of stuff on how to set them for ext2/3). Is setting a UUID even necessary or preferred? What I'm reading around the forums is that it's a choice?

One thing's for sure-- I have learned more about partitions and MBRs than I ever expected or cared to!

Try running GParted, navigate to SDA1 (or whatever drive you killed), menu>device>attempt data rescue

This has about a 50% success rate for me, good luck .

I would doubt (over 9 years later) the OP cares anymore.
Try to avoid resurrecting long-dead threads.