SDI2HD doesn't create a bootable disk

[Jim Langston]

OK, I'm at the end of my rope here.

I have a complete, working image that I have manually tested by copying it
over to an NTFS-formatted partition, as well as a Bootprep-modified FAT32
partition. Works great, no issues noted.

Built a Win98 Boot Floppy. Put CDROM access stuff on it. Copied SDI2HD.EXE
to it. Burned a CD with the SDI file on it. Put the CD into the CDROM
drive on the target. Rebooted the target device using the floppy. Started
SDI2HD.EXE. SDI2HD.EXE chews on the drive for a good while, announces it's
done, and when I reboot I get a blank screen with a blinking cursor. No
"Missing NTLDR", or "Read Error", nothing. Wow, I have a boat anchor!

If I inspect the target HDD by connecting it to my development PC, it
appears to have a full NTFS partition, with all of the files that I expect
to see. It's marked as Active, no problems I can see, anywhere. It just
won't boot.

Is there something I am missing in my settings in Target Designer that might
be causing this? Could it be that I am creating time-limited image (still
waiting to get some licenses)? Has anyone actually gotten SDI2HD.EXE to
actually work?

Jim

 

[KM]

Jim,

You may be experiencing MBR damage problem. I think sdi2hd (launched with an sdi with DISK blob in it) replaces the entire disk
content include MBR.
I guess you would need to repair the MBR (with a command like fdisk /mbr from DOS).

 

[Jim Langston]

Sounds plausible enough.. but if I do an FDISK /MBR, won't it add the DOS
MBR? Wouldn't I want to run BOOTPREP instead to get an MBR that looks for
NTLDR?

Thanks,
Jim

Jim,

You may be experiencing MBR damage problem. I think sdi2hd (launched with

an sdi with DISK blob in it) replaces the entire disk

 

[KM]

Jim,

Bootperp rewrites FAT boot sector so that it knows where to load ntldr from. It does not touch mbr (unless you backup/restore the
mbr with bootprep).
MBR reads and jumps to a boot sector code. Boot sector code is looking for the ntldr.

NTFS boot sector does not have to be bootprep'ed as it knows how to search for ntldr.

Fdisk /MBR... Well... it does change the MBR but it does not alter partition table and signatures. The point was to change MBR to a
"DOS MBR" version (to write DOS pre-bootstrap code part of the MBR). It may help you to make disk bootable if it is not now.

There is still some disk geometry factors but you could give it shoot (you can always backup your MBR first)

 

[Jim Langston]

Thanks, I'll go beat on it some more. The lack of any error messages is the
most frustrating part -- I can usually fix most anything if I can just
figure out what is broken :-/

Jim

Jim,

Bootperp rewrites FAT boot sector so that it knows where to load ntldr

from. It does not touch mbr (unless you backup/restore the

mbr with bootprep).
MBR reads and jumps to a boot sector code. Boot sector code is looking for the ntldr.

NTFS boot sector does not have to be bootprep'ed as it knows how to search for ntldr.

Fdisk /MBR... Well... it does change the MBR but it does not alter

partition table and signatures. The point was to change MBR to a

"DOS MBR" version (to write DOS pre-bootstrap code part of the MBR). It

may help you to make disk bootable if it is not now.

There is still some disk geometry factors but you could give it shoot (you

can always backup your MBR first)

 

[gmiller]

I too am having the exact same problem.
I was able to use PTEDIT the dos based partition editor included with
Partition Magic 8.0 to see the problem. For some reason although SDI2HD
correctly formatted the CompactFlash as NTFS, it marked the partition as
a bootable FAT partition (type 6) instead of a bootable NTFS partition
(type 7). I used ptedit to change the type to 7 and had to change the
ending head to 63 before it would let me save the changes. I was then
able to boot from my CompactFlash drive. Running Partition Magic on the
newly booted drive now showed an error because I had edited the number
of heads, but PM was able to automatically fix the errors.

Obviously this is not a great way to get the thing into production, but
it at least explains the somewhat painful mystery. Bottom line it looks
like an SDI2HD bug.