0.4.6a 2014--9-18 behaving strangely with external SSD drive

[GoogleCodeExporter]

I have 3 Easy2Boot USB drives with many ISOs on it.
There seems to be a problem with my external USB SSD drive (which is in caddy) 
and my external 80gb SATA HDD in a different caddy. The 2TB My Passprot USb HDD 
seems OK with all versions (as far as I can tell so far)

I have tried various versions:
2014-08-19 OK
2014-08-12 OK
2014-09-18 BAD

The problem occurs when booting from my Asus EeePC 904HD and on the USB HDD 
caddy also under VBox+VMUB.

Problems vary - e.g. only some ISO files are detected (or no ISO files are 
detected and added to the menu), or if I reload the /menu.lst file, hd0,0 
becomes inaccessible

e.g.
in command console
root
>> Disk I/O Error
ls (hd0,0)
>> Disk I/I Error

something is broken or at least not compatible with 0.4.5c and earlier versions 
of 0.4.6a!

To reproduce, make an E2B USB HDD/SSD drive.
Add 0.4.6a 2014-09-18 grldr to the root.
Add some ISOs to \_ISO\MAINMENU
test on a variety of systems

Original issue reported on code.google.com by Steve6375 on 19 Sep 2014 at 4:47

[GoogleCodeExporter]

Thanks for you test,I don't know why.

Please try below again ,hope both can work.

Original comment by chenall.cn on 12 Oct 2014 at 8:33

[GoogleCodeExporter]

test1 WORKS
test2 FAILS

Original comment by Steve6375 on 12 Oct 2014 at 8:37

[GoogleCodeExporter]

Ok,Thank you for your patience tested again..

workaround for this issue is remove following two lines.

if (cmd[0] == cmd[1] && cmd[2] != 0x20)
    continue;

the new version is uploaded
http://grub4dos.chenall.net

Original comment by chenall.cn on 12 Oct 2014 at 9:28

[GoogleCodeExporter]

Something odd with this new version

In VBOX I get
FATAL: int13_hardisk_ext: function 42. can't use 64bits lba

On Asus EeePC, Checkaccess.g4b (in E2B, not test version) stops on 'Checking 
last sector is accessible...' for about 2 minutes before continuing.

???

Original comment by Steve6375 on 12 Oct 2014 at 9:54

[GoogleCodeExporter]

grub4dos-0.4.5c-2014-10-12-test1.7z also fails with the same FATAL:: int13 
error.

Original comment by Steve6375 on 12 Oct 2014 at 9:58

[GoogleCodeExporter]

grub4dos-0.4.6a-2014-10-12.7z seems OK but not 0.4.5c

Original comment by Steve6375 on 12 Oct 2014 at 10:26

[GoogleCodeExporter]

if run from USB 32Gb flash drive under VBox, grub4dos-0.4.6a-2014-10-12.7z does 
hang on DPMS2 in Easy2Boot (0.4.5c does not hang and works, but get FATAL: 
error if booting from 2TB USb HDD under Vbox).

Original comment by Steve6375 on 12 Oct 2014 at 3:06

[GoogleCodeExporter]

I think issue with VBox and 2 minute delay on EeePC was caused by accessing 
sectors past the end of the disk. The code in CheckAccess.g4b uses lines like

set /a s1=*0x6001c6 & 0xffffffff >>2

This seems to work (i.e. divides number by 4) with some disks but not others 
(depending on size of partitions?)!
Changing code to remove the space to

set /a s1=*0x6001c6 & 0xffffffff>>2

works OK and always divides by 4.
So on some drives, the lba sector to access was x4 greater than the end of the 
disk and this was causing the issues in VBox and EeePC - 2 minute delay.

So 0.4.5c looks OK.

Also tested 0.4.6a 2014-10-15 and this now works with DPMS - so problems look 
fixed. I will continue to test but so far both versions look OK...
Thanks!

Original comment by Steve6375 on 15 Oct 2014 at 1:33

[GoogleCodeExporter]

If has any other problems please report issues at github.(because Googlecode is 
hard to access from china)

https://github.com/chenall/grub4dos/issues

Original comment by chenall.cn on 18 Oct 2014 at 3:18

• Changed state: Started

[GoogleCodeExporter]

so far testing is good! No problems.
Will you be releasing this new version and 0.4.6a version?

Original comment by Steve6375 on 19 Oct 2014 at 5:44

[GoogleCodeExporter]

FYI - This problem is only fixed by using

write 0x307ff4 0xC00000 && set ?_BOOT=%?_BOOT%

on first line of menu.lst

If this line is omitted then ?_BOOT is corrupted to all NNNNNs with sedillas as 
before.

Original comment by Steve6375 on 21 Oct 2014 at 7:52

[GoogleCodeExporter]

Also, if I use the 
write 0x307ff4 0xC00000 && set ?_BOOT=%?_BOOT%
line in a VM or any system, then on first boot, I get splashimage 800x600 as 
usual.
However, if I reboot VBox or QEMU then it does not change to 800x600 
graphicsmode and no splashimage! This is when using the 'reboot' command. 
Really strange!

I tried different locations - e.g. 0x1200000 and same result - boot OK first 
time but on reboot -> no graphicsmode!

Original comment by Steve6375 on 21 Oct 2014 at 8:17