When ramdisk boot formats NTFS CF, it won't boot

[Mark K Vallevand]

I boot a ramdisk image from a USB device to initialize the IDE CF device. I
use diskpart to clean, partition and activate the partitions on the CF.
Then I use command line format to format them as compressed NTFS. Then I
copy files to the partitions. The resulting image will not boot.

If I do the format on another XP Pro machine, the resulting image will boot.
Diskpart and file copy are done while running from the ramdisk.

I've checked the master boot sector and partition boot sector. They are the
same as a booting CF.

I've updated the boot.ini file on the CF that doesn't boot so that I can see
if ntldr is reading boot.ini. It isn't getting that far.

I've deleted ntldr to see if partition boot sector is reading ntldr. It
isn't getting that far either.

I've made the partition non-active, and the BIOS (or master boot sector)
complains. So, it is getting that far.

Any one have any ideas what could be wrong with the format?

 

[Slobodan Brcin \(eMVP\)]

Have you ever tried to format your OS partition on CF with this type of
device?

I mean do you have one device like this with Windows XP that can be used for
testing format command.

Also try to boot USB SDI on your development (device that format your CF
correctly) and use it for preparing CF.
Then try if it will work.

On different hardware platforms, format sometimes behave differently.

Regards,
Slobodan

 

[KM]

Mark,

Have you tried to format the CF as non-compressed NTFS (FAT?)? Any
difference? Does the ntldr get loaded (see timeout?)?

Also, it may sometimes be a good idea on compress system volume to have
uncompressed ntldr and boot.ini (shouldn't be a "must do", though).

 

[Mark K Vallevand]

Compressed/non-compressed doesn't matter. Fails to boot in either case.
Ntldr does not get loaded. I deleted Ntldr and it behaved the same.
Its like the boot sector gets lost looking for Ntldr.

 

[Mark K Vallevand]

I have many CF devices that work when formatted on my "media-build" machine.
CF formatted on any XP Pro machine with IDE-CF adapter will boot. But, one
difference:
I always use disk manager on XP Pro and diskpart/format command line on XPe.

Maybe I'll build a CF on XP Pro using diskpart/format command lines.

 

[Mark K Vallevand]

Don't have FAT on my ramdisk image. Don't have bootprep either. Its a good
test to try, but I really need format to do the right thing (if the problem
turns out to be format).

 

[Mark K Vallevand]

Building the CF on XP Pro with diskpart/format command lines is OK.

I still cannot get format command line to create a bootable CF when running
from XPe. Everything on the CF looks bootable, and the file system is OK.
But, it doesn't boot.

Does format try to align things in the file system along drive geometry?
Maybe the partition boot sector is getting lost because of some alignment
problem.

I noticed that XP Pro and XPe have different disk geometry. At least
diskpart won't partition the same sizes on the two systems. But, the drive
geometry that is reported by a test program I have seems to be the same.
And the diskpart program is the same version on both XP Pro and XPe.
Format.com is the same, too.

 

[Slobodan Brcin \(eMVP\)]

Disk geometry can be reported differently between different hardware.
But both XP and XPe should report same values.

Like I said you should try to run XPe on your development computer and use
it to prepare CF.
This will not solve your problems, but at least it can tell you that XPe is
not a problem.


Regards,
Slobodan

 

[Mark K Vallevand]

What I've just found is very interesting.

When running from ramdisk the geometry of the IDE CF is not that same as the
geometry of the CF when running from the CF. Same hardware. Same BIOS.
Same CF.

Does the BIOS provide the geometry, or is it from the disk itself?

Maybe I'm missing some component in the ramdisk image that handles disk
geometry.

 

[Slobodan Brcin \(eMVP\)]

Mark,

Disk has is own geometry that it reports.
But BIOS and Windows translate(convert) that geometry to new values.

This geometry is written to CF MBR/PBR and it is used by BIOS,MBR,PBR and
ntldr during the boot process.
After ntoskrnl.exe and disk drivers take over load process they use they own
geometry (not one written on CF).

Using tools like DOS fdisk, format will write one set of values to your CF.
And using XPe can write other values.
Since DOS relies on int 13 there is a greater chance that this values will
be more appropriate (for this platform) then values reported by XPe.

You conclusion about ramboot and CF boot on same hardware and BIOS is very
strange, could it be related to problems you had in past with configuring
your ramboot?
Perhaps something else remains in your image, that causes this wrong
geometry report.

Regards,
Slobodan

 

[Mark K Vallevand]

OK. I found it.

The disk geometry reported by my device is different than other machines.
However, that shouldn't matter, because every one is using logical
addressing anyway. The partition and format done by my device on the CF is
perfectly legal in every way. There is no reason to expect that it wouldn't
boot. Some of the disk geometry is saved in the master and partition boot
sectors, and that seems to be ignored, probably because logical addressing
is used. But, one byte of data in the NTFS partition boot sector is
significant: tracks per cylinder (or heads). If tracks per cylinder is 255,
it will not boot.

I'm guessing that the BIOS is reporting the disk geometry in a
DOS-compatible format. In the DOS world, you need to keep the number of
cylinders to less than 256. The BIOS does this by increasing the number of
tracks per cylinder, usually to 255. In the non-DOS world this doesn't
matter, because you can have 65536 cylinders. And, almost everything uses
logical sector addressing anyway. But, you will see that some devices, like
removable CF cards, will still reported with the DOS-compatible geometry.
And, something in the boot sequence of doesn't like 255 tracks per cylinder
in the NTFS partition boot sector. It likes 16.

Using the BIOS that comes with some system, you can change the large-disk
mode from DOS to non-DOS. In the non-DOS mode, it seems to report the same
geometry as other machines. If changed to DOS mode, it reports the same
geometry as the my device.

Why should anything care that the number of tracks per cylinder is 255.
Magic number?

I've confirmed that a CF with tracks per cylinder = 255 in the partition
boot sector will not boot in any machine I've tested.