6

I have recently installed Windows 7 64 bit on a new SSD using UEFI boot and GPT. The system worked fine. After adding my old system HD to the system (that uses MBR), Windows will no longer boot correctly: When booting from the SSD, the normal boot screen appears and Windows tells me that it is loading files. Then the boot screen disappears and I am in an EFI shell, unable to boot. When I unplug the old HD, Windows boots again without complaints.

Can I somehow boot with this configuration without formating my old hard disk first?

I have an MSI Z77-G65A board. It is configured for UEFI boot, booting from the SSD. Both drives are set as independent HDs (no accidently activated RAID). The SSD is connected to a SATA-6G port and the old drive to a SATA-3G port.

2
  • Have you tried to delete the MBR boot code from the HDD?
    – Robert
    Aug 15, 2012 at 14:58
  • How can I do this? I read that I can use dd if=/dev/zero of=/dev/hda bs=440 count=1 on a linux machine to overwrite the boot code - if /dev/hda is my old HD. Is this the only option (and is it correct for that matter?)
    – shiin
    Aug 15, 2012 at 21:24

2 Answers 2

6

Deleting the disk signature solved the problem. This can be done with the command

dd if=/dev/zero of=/dev/sdb bs=1 count=4 seek=440 conv=notrunc

in a linux shell with root rights.

Background:
Starting with Windows 2000, Microsoft writes a 4-byte value -the disk signature- into the MBR of each disk so that it can identify each disk. When two disks have the same identifier problems ensue. The afore mentioned command replaces this signature with zeroes which prompts Windows to assign new, unique values.

Note that before overwriting the disk signature, I also tried to replace the bootloader (bytes 0-439 in the MBR) with zeroes. By itself, this didn't help to solve my problem.

EDIT: This solution solved the problem for only one boot-up. When trying to boot a second time, the same issues reappeared. By overwriting the disk signature again, I was able to boot, but again only for one time.
Judging from the provided background above, it seems that Windows chooses an inappropriate disk signature so that the problem reappears...

EDIT 2: It seems that when booting in UEFI mode Windows 7 64bit cannot deal correctly with extended partitions on disks with MBR. The bug is explained here:

hotfix-1 hotfix-2

Apparantly an extended partition is wrongly recognized as an UEFI partition. These two hotfixes should solve the problem, but they have to be already integrated into the install media.

2
  • I ran into something very similar. I think the easiest way to solve it is by converting the second drive to GPT (with gdisk under linux, do back up the MBR with sfdisk or similar). Have to boot from the install media a few times and do the various boot repairs, after that I got it to boot.
    – wds
    Dec 27, 2012 at 9:51
  • Another note: you should be able to change the identifier with diskpart (list disks, select disk #, uniqueid disk ...), so no need to zero it out manually. I only found this out after already converting to GPT.
    – wds
    Dec 27, 2012 at 9:52
0

I had a similar problem. I had added an extra primary partition and an extended partition to my second disk drive using Windows Disk Manager - 4 partitions in total. After that I could no longer boot up Windows and none of the repair options would work.

A workaround was to disable the second disk drive in the BIOS.

My solution was to use the diskpart command running from an Emergency Repair Disk to convert the second disk drive from MBR to GPT. In hindsight when I installed Windows I only formatted the first disk drive (an SSD) which must have defaulted to GPT. I formatted the second drive using Windows Disk Manager and the software must default to MBR.

I am glad I found this post as it identifies the problem as being in the software, and not in one of my two disk drives or the motherboard.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .