[ilko_t]

A few tests on Latitude E6400:
The ~BT & ~LS USB method and starting setup from a CD worked.

What didn't help, hangs on blank screen when partitions are supposed to show up:
-newer BIOS, A25
-various grub4dos versions- 0.4.5a 2010-02-09, 0.4.5b 2010-08-12, 0.4.4 2009-03-30
-small ISO method, also usb drivers moved to bus extender and input devices groups
-ISO + firadisk method
-SD card in the reader
-XP CD in the DVD drive
-DVD drive removed
-no hd0-->hd1 and vice versa mapping
-modified ntdetect.com
-some devices turned off in BIOS
-IDE/AHCI mode
-2003 SP2 source

Running out of ideas...


@jaseuk
Check in Program directory\winsetup\files\PyronSetup\I386 if setup.ex_ exist. Most likely an antivirus program either deleted it or doesn't let copying it. Download fresh copy of the program or turn off your antivirus.
http://www.msfn.org/...-xp-inst-v047z/

@jaclaz
These rumours and jokes must be based on true stories

[ilko_t]

I am still chasing this one...

Dell released new BIOS, A27- same issue.
Tried to start Setup from a floppy image with setupldr.bin, ntdetect.com and txtsetup.sif in it mapped to fd0 and fd1- setup hangs the same way, this works on other machines.
Use latest chenalls grub4dos build- http://code.google.c...21.zip&can=2&q= - same result.

Interestingly, the firadisk method hangs the same way.

What the heck is wrong with these Dells...

Any ideas and clues are more than welcome

[ilko_t]

Success, at last.

It seems loading the ISO image in memory causes the hang. Mapping it with no ---mem option seems to do the trick. Of course the file has to be contiguous.

The only change is in winsetup.lst:

map  /WINSETUP/XPpSP2.ISO (0xff)

As a side note- Syslinux memdisk also seem to work on this system:

title Boot memdisk
kernel /memdisk
initrd /flp.img

flp.img is an image of floppy disk with SETUPLDR.BIN, NTDETECT.COM and TXTSETUP.SIF and bootsector invoking SETUPLDR.BIN.

Txtsetup.sif has a few lines added in order to change boot and source paths:

[SetupData]
...
SetupSourcePath ="\WINSETUP\XPpSP2\"
SetupSourceDevice=\ArcName\multi(0)disk(0)rdisk(0)partition(1)
BootPath="\WINSETUP\XPpSP2\I386\"
BootDevice="multi(0)disk(0)rdisk(0)partition(1)"
...

Memdisk was used just for testing purposes, it won't be suitable as we cannot change on the fly rdisk values according to th enumber of hard drives connected as we can do with grub4dos and

cat --locate=rdisk(X) --replace=rdisk(Y) (0xff)/I386/TXTSETUP.SIF

I am going to open a new thread in grub4dos support forum at boot-land.net and check if the good guys there have a workaround or clue what's going on.

[steve6375]

This sounds like the BIOS e820h memory map function is returning incorrect memory size data. grub4dos will place the iso at the top of RAM. It is quite common for BIOSes to incorrectly report the size of memory and so grub4dos may load the ISO into memory locations that are being used for something else - shared UMA graphics memory for instance - and then the code gets trashed by the BIOS before it can be run!

MemTest86+ reports e820h memory size parameters when you run it - but for this test you should not load it into memory using --mem via grub4dos or it may crash or itself modify the parameters returned - I would recommend booting from CD and running it. MemTest86+ may even fail if it tries to test memory near the top which is not there...

I have reported many such errors to mainboard and notebook manufacturers over the years! Basically, Int 15h e820h reports free memory - if you try to use all the memory reported as 'free' and then test it, it fails because the values returned by the BIOs were incorrect. See this post for an explanation of what this does http://www.masm32.co...21&topic=1399.0

This post has been edited by steve6375: 26 March 2011 - 04:15 AM

[ilko_t]

Thanks Steve, quite useful explanation. Must have missed this post.