I'm 95% certain that you've accidentally trashed your Windows installation. Evidence:
Following some online instructions, I chose the "Something else" option. I created 4 partitions from apparently "free space" (although my Windows partition was located there)
The "Something Else" option shows the disk and all current partitions. If it misidentified the disk as being empty when in fact there were current partitions, then you could easily trash your installation in this way. In fact, there's a known bug in libparted (upon which the Ubuntu installer's partitioner is based) that causes it to show the disk as empty when the partition table deviates from absolute perfection. The most likely explanation is that you started with a GPT disk but installed Windows in BIOS mode, which would have caused a GPT-to-MBR conversion that left some GPT data intact. This confuses libparted, resulting in the "blank disk" problem. See this page of mine for details and a fix (which will no longer work for you -- by setting up new partitions, you're long past the point where it can be fixed).
Incidentally, I tried looking for a bug report about this on Launchpad (Ubuntu's bug-tracker), but didn't find one, which is surprising. Perhaps I'll investigate further and file a bug report, since this problem is so serious.
Ubuntu installed fine, but after restarting my computer, it booted directly into Ubuntu, without displaying the GRUB bootloader menu that I expected.
This behavior is consistent with a completely trashed Windows, although there are also other possible explanations.
Using my Windows 7 laptop, I created a system repair disc and booted my computer from it. Strangely it displayed an error message that the disc "was not compatible with my version of Windows." This does not make sense as both my desktop and laptop are 64-bit versions of Windows 7.
This is also consistent with my hypothesis, although again, there are other explanations. Note that the "compatibility" in this quote refers (or can refer) to the partition table type -- Windows ties the Master Boot Record (MBR) partition table to a BIOS-mode boot and the GUID Partition Table (GPT) to an EFI-mode boot. If the Windows installer boots in BIOS mode and sees a GPT disk, or if it boots in EFI mode and sees an MBR disk, it will refuse to do anything with the disk, except (in some circumstances) to repartition the disk and re-install.
To test my hypothesis, you need to examine your partition table. You can do this with GParted,
gdisk, or other tools. The easiest and best for the moment is
$ sudo parted /dev/sda print
Model: ATA Samsung SSD 850 (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 524kB 1573kB 1049kB BIOS boot partition bios_grub
2 1573kB 580MB 579MB fat32 EFI System boot
3 580MB 1106MB 525MB ext4 Xubuntu /boot
4 1631MB 250GB 248GB Linux LVM lvm
The output of
parted /dev/sda print will show your partition table. The
Partition Table: line shows the partition table type -- GPT in this example. (MBR shows as
msdos.) More important is the details of the partitions. If you see one or more NTFS partitions, then I'm probably wrong and Windows may be intact. If you see nothing but Linux partitions (ext4fs, Linux LVM, etc.), as in this example, then my hypothesis is correct. (Note that the FAT32 partition in my example is an EFI System Partition (ESP), which holds boot loaders for all OSes.)
If you need help interpreting your partition table, please cut-and-paste the output of
parted to a pastebin site and post the URL to your document here.
If I'm right, you can't fix the problem -- at least, not completely. The best you can do is:
- STOP USING THE INSTALLED OS IMMEDIATELY! Every moment you use the computer from its on-disk Ubuntu is another moment in which Ubuntu may write data over the remnants of your personal files on the hard disk.
- If you don't already have one, buy a disk to use for data recovery. An external disk big enough to hold all your personal files should do fine.
- Boot to an emergency disk (like the Ubuntu installer in its "try before installing" mode). A good case can be made for Windows emergency tools, too.
- Run PhotoRec or similar software. These tools enable you to recover individual files, even from an overwritten filesystem -- which is what you've got. I've seen claims that some Windows tools can do a better job at recovering files from an overwritten NTFS partition than PhotoRec can, but I don't have specific program names or URLs. Note that you'll need to recover files to another physical disk -- hence step #2. Also, you're unlikely to recover all your files, and you may spend hours sifting through the files you recover to properly organize them. You may end up with a bunch of Windows program files, which you can throw away -- it will be easier to re-install Windows and your programs than to try to use those individual program files.
- If you want it, re-install Windows. This will require learning about EFI vs. BIOS boot modes. You may want to read this page of mine on the subject, which may help you navigate this minefield. (Note that BIOS/CSM/legacy boot issues may have been part of what set you on the path to this problem, but the most important issue, if my hypothesis is correct, was the bug in libparted.)
This procedure assumes that, like most people, you lack good backups. If you've got good backups, you can restore your personal files from them with much less fuss.
I just did some tests, and it looks like the bug that I think bit you has been fixed in Ubuntu 15.04. I'm pretty certain it was present in 14.04.