fdisk 440 Doesn't Work - Win7 Missing BOOTMGR When I Try To Boot It

[DasFox]

I can't seem to figure out the cmds below to manually reinstall Chameleon without killing Win7 from booting.

These commands don't work this kills my Win7 from booting, it always says BOOTMGR missing.


SARs-Mac-mini:~ SAR$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *160.0 GB disk0
1: Windows_NTFS System Reserved 104.9 MB disk0s1
2: Windows_NTFS 86.9 GB disk0s2
3: Apple_HFS OSX 32.2 GB disk0s3
4: OpenBSD 40.8 GB disk0s4


Here are the cmds I'm running;


cd /usr/standalone/i386/

sudo ./fdisk -f boot0 -u -y /dev/rdisk0

sudo dd if=boot1h of=/dev/rdisk0s3

sudo cp boot /

sudo /usr/standalone/i386/fdisk -e /dev/disk0
f 3
write
y
exit


I've been messing with this for a few days and still can't get it, can someone tell me how to do this so it doesn't mess up Win7?


THANKS

[Kabyl]

The manual tells you to use fdisk440, that's probably why.

(I can't remember where to get it)

[DasFox]

I'm using nawcoms usb pkg installer and he said that in that /usr path is a modded fdisk...

I tried it again and still not working, so I don't think it's modded or he made a mistake.

I found the modded one;

http://forum.voodooprojects.org/index.php?action=dlattach;topic=1141.0;attach=767

I'll give this a try...


THANKS

[DasFox]

Ok so I put in the fdisk440 and here's a look again at everything;


SARs-Mac-mini:~ SAR$ diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *160.0 GB   disk0
   1:               Windows_NTFS System Reserved         104.9 MB   disk0s1
   2:               Windows_NTFS                         86.9 GB    disk0s2
   3:                  Apple_HFS OSX                     32.2 GB    disk0s3
   4:                    OpenBSD                         40.8 GB    disk0s4



cd /usr/standalone/i386/

SARs-Mac-mini:i386 SAR$ ls
Firmware.scap   boot      boot.sys   boot0hfs   boot1h      boot1hp      chain0      fdisk      libsa.a      machOconv
bdmesg      boot.efi   boot0      boot1f32   boot1he      cdboot      embedded.h   fdisk440   libsaio.a   vers.h


sudo ./fdisk440 -f boot0 -u -y /dev/rdisk0

sudo dd if=boot1h of=/dev/rdisk0s3

sudo ./fdisk440 -e /dev/disk0

sudo cp boot /


sudo ./fdisk440 -e /dev/disk0
f 3
write
exit

Well I still can't boot Win7 it says BOOTMGR missing...


THANKS

P.S. After posting this reply I reinstalled Windows and kept it as the active partition running this cmd;

sudo ./fdisk440 -f boot0hfs -u -y /dev/rdisk0

But I still got BOOTMGR missing when trying to boot Win7...

FDISK440 does not work...

[DasFox]

Ok It's booting but get this, I boot it with the System Reserved and I've never used that partition to boot Win7 that is typically used for the System Recovery Environment...

In the past when I've used Linux and booted with Grub and I'd boot the System Reserved it always booted the System Recovery Environment, it was a trick I learned many years back to get into a system that had a bad partition and I could at least boot that to restore it.

I've never seen the System Reserved used to boot Win7 or Vista, now after running those cmds Chameleon is causing this action to happen and that is not correct so I hope someone can fix this...

I know for a fact I've never once used the System Reserved to boot Windows because I always hide the partition, you can see in my boot.plist below;


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
   <key>GraphicsEnabler</key>
   <string>Yes</string>
   <key>Kernel</key>
   <string>legacy_kernel</string>
   <key>Kernel Flags</key>
   <string>arch=i386</string>
   <key>Rename Partition</key>
   <string>"System Reserved" Windows</string>
   <key>Timeout</key>
   <string>5</string>
       <key>Hide Partition</key>
       <string>hd(0,1)</string>
       <key>Rename Partition</key>
       <string>hd(0,4) OpenBSD</string>
</dict>
</plist>


THANKS

[Blackosx]

You're correct in saying that Chameleon will boot Windows 7 by selecting the System Reserved partition. I noticed this back in the day when I first played with Windows 7 though I haven't thought of it since as these days I always install Windows to a secondary partition to stop the installer creating the System Reserved partition.

[Azimutz]

Hi DasFox... you seem desperate with that problem ok, let's see if i can do some good here...

I see a small problem on some commands.. maybe a copy/paste typo?? You have /dev/rdisk0 and /dev/disk0;
with fdisk make sure you always do /dev/rdiskX!

About the System Reserved partition, get rid of it!!
Afaik, win 7 is the first windows system that creates it; it's were win 7 keeps the booter (amongst other things) and
it's the one that's marked as "active" (not windows partition). This partition is created only if there's no other windows
installation (e.g. if you have Vista installed on the first partition and install 7 to the second, System Reserved is not
created and the booter is installed on Vista partition) and if there's space available for "primary" partitions.
As mbr disks can only have 4 primary partitions, the easiest way to get rid of it, is by pre-partitioning the disk with
4 partitions and install windows to the first; after install you can do whatever you need with the rest of the disk.
After installing OS X set windows partition as active again and use boot0hfs so you can keep it active.
Also be careful with OS X Disk Utility; if you use it to format a partition, it will mark it as active

Besides this stuff, i don't see what can possibly be wrong..!?

Hope this helps.

[scorpius]

I see a few things that may have gone wrong.

1. When you ran fdisk in your 1st post, you overwrote the 4-byte disk signature, and so 7 wouldn't boot anymore. fdisk440 does the exact same thing as fdisk, except that it leaves the disk signature intact.

2. Then you reinstalled 7 and ran sudo ./fdisk440 -f boot0hfs -u -y /dev/rdisk0, which shouldn't have overwritten the signature.

You can check your signature with this command: sudo xxd -l4 -s440 -p /dev/disk0. If you get all zeros, then that's what's wrong.