9 replies to this topic

[erketre]

Hello

I have a 12MB HDD image with FreeDOS installed on it (fdos.img). The image is on a bootable USB pendrive (/boot/fdos.img). It has valid MBR and one active partition. Grub4Dos is installed on this pendrive with this menu entry for dos:

title FreeDOS

	map --mem (hd0,0)/boot/fdos.img (hd0)

	map (hd0) (hd1)

#	map --a20-keep-on=0

#	map --int13-scheme=0

	map --hook

	rootnoverify (hd0)

	chainloader +1

	map --floppies=0

	map --harddrives=2

	boot

If I boot this pendrive in qemu it works fine. Drive C: is FreeDOS (fat12) and D: is pendrive (fat32). Both disks are accessible from dos.

But in my real PC there is a problem. I boot it with option USB-HDD. FreeDOS loads fine but disk D: (USB pen) is empty! It looks like valid, it's size is valid but no files are shown with DIR command. If I use syslinux+memdisk instead of grub4dos the same problem occurs. What can it be? I need an access to other files on USB too.

Second issue is a crash of Jemm386 (freedos mem emulator) exception 06. Also no problem under qemu, only under real PC (and only with grub4dos, memdisk works fine here)

[Wonko the Sane]

Some points:

• Which version of grub4dos are you using?
• Your menu.lst entry is overcomplex (and besides the final boot statement is not needed when in a menu.lst, it is only needed on command line), you don't normally "need" to set floppies and harddisk numbers
• Why using the rootnoverify on whole (hd0)?

If you map the fdos.img to the whole (hd0) and you exchange the mapping of (hd0) with (hd1), you should be able to see in grub4dos command line (on PC) THREE drives:

• the mapped fdos.img (hd0)
• the USB stick (hd1)
• the internal HD of the PC (hd2)

Try in command line:

map --mem (hd0,0)/boot/fdos.img (hd0)

map (hd0) (hd1)

map --hook

and run:

geometry (hd0)

geometry (hd1)

geometry (hd2)

to make sure which is which.

Then try:

root (hd0,0)

root (hd1,0)

root (hd2,0)

To make sure that the actual partitions on the drives are read correctly.

Report.

Wonko

(it is probably a freedos issue, in some cases I have seen "weird things" with geometry detected by freedos)

[erketre]

• Which version of grub4dos are you using?
• Your menu.lst entry is overcomplex (and besides the final boot statement is not needed when in a menu.lst, it is only needed on command line), you don't normally "need" to set floppies and harddisk numbers
• Why using the rootnoverify on whole (hd0)?

• 0.4.4
• I know but I tried every possible option
• Because my image is a whole drive image (with MBR and parts table)

If you map the fdos.img to the whole (hd0) and you exchange the mapping of (hd0) with (hd1), you should be able to see in grub4dos command line (on PC) THREE drives:

No, only 2 drives: USB and image. Original drives are hidden by BIOS when boot from USB (USB-HDD boot option)

Try in command line:

map --mem (hd0,0)/boot/fdos.img (hd0)

map (hd0) (hd1)

map --hook

and run:

geometry (hd0)

geometry (hd1)

geometry (hd2)

to make sure which is which.

Then try:

root (hd0,0)

root (hd1,0)

root (hd2,0)

hd0 geom looks OK
hd1 geom looks OK
hd2 "cannot find drive"

hd0 "cannot mount"
hd1 "cannot mount"
hd2 "cannot find drive"

[Wonko the Sane]

[hd0 geom looks OK
hd1 geom looks OK
hd2 "cannot find drive"

hd0 "cannot mount"
hd1 "cannot mount"
hd2 "cannot find drive"

Ok, since you don't have hd2 those errors are allright.

What appears as "wrong" is the cannot mount on (hd0,0) and (hd1,0) as it means a problem pf some kind i the partitioning.

Are you sure you used root (hdn,0) and NOT root (hdn)?

Wonko

[erketre]

Yes. My mistake. Here is corrected output:
root (hd0,0) - fat, type 0x01
root (hd1,0) - fat, type 0x0B

I can even "ls" both partition from grub shell and all looks fine here... so it's not grub but DOS/BIOS issue for sure.

[Wonko the Sane]

Yep.

Now try:

map --mem (hd0,0)/boot/fdos.img (hd0)

map (hd0) (hd1)

map --hook

root (hd0,0)

chainloader /kernel.sys

boot

This way we by-pass the PBR or bootsector and directly chainload the freedos kernel, cannot say if it can make a difference.

Then, try verifying that the CHS and LBA data in the MBR of the stick are "balanced", then try changing the partition type from 0B (FAT32 CHS mapped) to 0C (FAT32 LBA mapped).
I hope you know what I mean with the above, if not read here:
http://www.911cd.net...showtopic=23147
http://www.boot-land...?showtopic=7592
before asking related questions.

Wonko

[erketre]

chainloader /kernel.sys makes no difference.

What tool should I use to "balance" USB disk? Does it involves formatting the disk?

[Wonko the Sane]

chainloader /kernel.sys makes no difference.

What tool should I use to "balance" USB disk? Does it involves formatting the disk?

Not necessarily.
It is well possible that the data is already correct, and even if it is "unbalanced" it shouldn't create a problem, for now I would simply check, not change the CHS/LBA data.

Anyway, changing a single byte in the MBR from 0B to 0C won't do any harm, if it works, good, if it doesn't you simply revert it to 0B.

You can use Tiny Hexer:
http://www.boot-land...?showtopic=8734

Or, easier beeblebrox or PTEDIT32, though lately I received a couple of reports they have problems running on XP SP3 (for unknown reasons):
http://www.msfn.org/...o...138553&st=5
or if you freak out at hexediting, you may create a backup of the MBR with HDhacker, compress it in a .zip and attach it to your next post, and I'll have a look at the "balancing" and anyway change the partition type for you.



Wonko

[erketre]

This is it! CHS->LBA hack works. Thanks a lot

[Wonko the Sane]

This is it! CHS->LBA hack works. Thanks a lot

Good to know we have another happy bunny :
http://www.msfn.org/...o...28727&st=10



Wonko