Flashing cursor after install

[Tripredacus]

Ah but it took so much work!

Anyways, so I am guessing it is supposed to have some code in it then? I have come up empty on finding any white papers or support documentation for POSReady 2009. I suppose for now I can just report this as a bug, but it is strange that I would find it considering the age of the product.

I attached them anyways.

Mbrs.rar

[jaclaz]

Ah but it took so much work!

Anyways, so I am guessing it is supposed to have some code in it then? I have come up empty on finding any white papers or support documentation for POSReady 2009. I suppose for now I can just report this as a bug, but it is strange that I would find it considering the age of the product.

I attached them anyways.

The "aftermbrfix.bin" is obviously the same as "back1bin" BUT with the CODE in it.

The "ide_setup.bin" is "queer" it has the same disk signature BUT it has a slighly larger partition. (976768002 sectors instead of the previous 976751937)

Since 976768002 - 976751937=16065

And 1x255x63=16,065

It is a whole cylinder difference.

I have no idea why the setting RAID/IDE may make such a difference.

jaclaz

[allen2]

It think it's the partition alignment which is reducing the partition size.

[jaclaz]

It think it's the partition alignment which is reducing the partition size.

Since entries in BOTH partition tables start at LBA 63 I find this highly unprobable.

I wonder if your was a random guess, or an educated one.....

I mean when the "new" partition alignment thingy is used (and this AFAIK only applies to Vista and 7) it is the start of the partition that is aligned, not it's size, and anyway both sizes do not divide evenly by 4 or 8

jaclaz

Edited September 3, 2011 by jaclaz

[allen2]

It was a random guess as i've seen in some case that vista or 7 or windows 2008 would create a smaller partition than when you would create one with XP or 2003 and i always though it was due to alignment.

[Tripredacus]

Here is an idea about why it could be different. In each case (RAID or IDE mode) there is one difference in the setup. Since we are using the default pressed CD, it will get a 0x7B STOP error if we boot off the SATA ODD with RAID enabled.

If we make a USB Key to install instead, the included WinPE will read the USB key as a hard disk. The "browse for Mass Storage driver" function that this Setup has is not a literal browse. It will search for a USB key with INF files in a folder called "drivers" and just shows a progress bar during this. Because of the limitation stated before, the browse will fail and the drivers cannot be loaded.

So when doing a RAID install, we have to boot off a USB ODD and have a USB key inserted that just contains the drivers.

When I do an IDE install, I can use the original CD in the SATA ODD.

Seeing how it is already obvious to me that there are flaws in this entire process (USB key boot) is it possible that this is related to the MBR being written incorrectly?

[jaclaz]

It was a random guess as i've seen in some case that vista or 7 or windows 2008 would create a smaller partition than when you would create one with XP or 2003 and i always though it was due to alignment.

Yes, this is correct.

An "untouched" (up to XP/2003) NT will use "orthodox" traditional Cylinder alignment, i.e. first partition will start at 0/1/1 (LBA 63) and end at n/254/63, and subsequent ones will start at x/0/1 and end at y/254/63, in practice, any non first primary partition will be a multiple of 1x255x63=16,065 sectors or 8,225,280 bytes and can be enlarged or shrinked in 8,225,280 steps, first partition (which has the first "hidden" MBR track) as well as logical volumes (that have the "hidden" EPBR track) will satisfy equation SIZE=n*255*63-63 (but still enlarged or shrinked with the same "step" size).

Starting from Vista an untouched system first partition will start at 0/32/33 or LBA 2048 and then it will try to mantain a size that is multiple of 4 Kb or 8 sectors.

So in the case of a single whole partition, usually there is a difference a the start (the 2048-63=1985 sectors) BUT since the "old" paradigm created some "never used" space at the end of the disk (since NO modern disk is a multiple of 16065) and the "new" one has not this "limit" some space could be "stolen" from this ending previously never used space.

Here is an idea about why it could be different. In each case (RAID or IDE mode) there is one difference in the setup. Since we are using the default pressed CD, it will get a 0x7B STOP error if we boot off the SATA ODD with RAID enabled.

If we make a USB Key to install instead, the included WinPE will read the USB key as a hard disk. The "browse for Mass Storage driver" function that this Setup has is not a literal browse. It will search for a USB key with INF files in a folder called "drivers" and just shows a progress bar during this. Because of the limitation stated before, the browse will fail and the drivers cannot be loaded.

So when doing a RAID install, we have to boot off a USB ODD and have a USB key inserted that just contains the drivers.

When I do an IDE install, I can use the original CD in the SATA ODD.

Seeing how it is already obvious to me that there are flaws in this entire process (USB key boot) is it possible that this is related to the MBR being written incorrectly?

It is possible, but it's anyway strange.

I will have to do some tests, but AFAICR when *any* "FDISK" like Windows NT program (disk management, diskpart, text mode setup) accesses a disk and finds it without the 55AA magic bytes it writes to it, besides the 55AA also the disk signature (the disk signature is written ANYWAY if missing when the device is accessed/mounted, if missing) AND the MBR CODE.

This is what happens in disk management when you get the question "Do you want to initialize this disk?"

If any of the said programs ALREADY find the magic bytes 55AA they will IGNORE the MBR CODE and leave bytes 0÷440 of the MBR untouched.

So a nice, possible explanation, is that somehow the "install winpe" is somehow "triggered" by the need to detect the USB and in this process it finds the disk without the 55AA and writes just those two bytes, and subsequent accesses, seeing that the disk is seemingly already initialized, skips the MBR CODE "install" step.

jaclaz

[Tripredacus]

Consider that I had used MBR to zero out the "mbr" on the disk (array) before attempting my test run of the RAID install prior to doing it. The subsequent IDE install was don't after both the MBRFix as well as deleting the array. Surely, deleting the array would have the same effect of erasing the MBR as well, then again it is Intel's IRST (Desktop) RAID which isn't the greatest in the world and is also primarily software based, especially the fact that if you use non RE drives you can break a mirror by simply restarting Windows.

I will do an additional test tomorrow of zeroing the mbr, then capture the first track again. It could be that the mbr program is lacking in removing enough data?

Since I brought it up, the test machine we are using has 2 WD RE4 drives in it.