thought we only supported bximage from bochs,.
maybe specify the layout and don't trust on dosbox its autoguessing code for bootdisks not created by bximage

Ok. Sorry didn't get you - "specify the layout"...
To add, I tried converting this dsk image into other formats like ISO etc... But of no use.

imgmount 2 C:\image.img -size bps,spc,hpc,cyl -fs fat

bps=bypes per sector (512 always)
spc=sectors per cylinder
hpc=heads per cylinder
cyl=total cylinders

OK. I used this command to mount my image as the master :
imgmount 2 j:\downloads\pintos\as.dsk -t hdd -fs none -size 512,63,16,142

But, I don't know how to boot from this master!

I think the "2" was supposed to be a drive letter.

No, type it like that with the 2 and then do the normal "boot -l c"
AFAIR when you don't give the file system (-fs none) you can't mount it to a letter, you need to mount it to a number or so. I *think* in the area of mounting an image to boot from it are currently some inconsistencies or it's currently not that documented 😀

of course you cannot boot an image without system (not to mention without file system)
so
boot floppy.img -l c

huh? Before the autosize detection, it was supposed to be that you mount the image with -fs none to boot from it...
AND the purpose was to have the OP mount the hd image with the -size option, not to boot from a floppy image...

I don't know how the "-fs none" thing came to be added in this, no one recommended it. In the original post the FAT type is clearly being autodetected in the image.

You can leave out the -fs none, but then you have to imgmount it to "c" and not to "2".
So what works is
imgmount 2 j:\downloads\pintos\as.dsk -t hdd -fs none -size 512,63,16,142
boot -l c

or
imgmount c j:\downloads\pintos\as.dsk -t hdd -size 512,63,16,142
boot -l c

When you mount to number you NEED -fs none or it won't boot of it and I *think* in ancient times it wouldn't work with specifying -size, mounting to c and booting off it. That's where the -fs none comes from 😀

OK, then maybe the -fs none was added to compensate for "2" instead of "C"...

Anyway, the autosize shown in the status window log message has the standard 512,63,16 parameters with 40 cylinders being derived from the size of the image file. Makes me wonder if 142 cylinders being specified is correct...

@Dominus :
I just tried :
imgmount 2 j:\downloads\pintos\as.dsk -t hdd -fs none -size 512,63,16,40
boot -l c
and
imgmount c j:\downloads\pintos\as.dsk -t hdd -size 512,63,16,40
boot -l c

But, of no help as the dosbox doesn't move ahead after saying "Booting from drive C..."

@ripsaw8080
Oh my bad... it has to be 40 cylinders. Thanks for correcting me 😀

Specifying the same geometry as the automatic one doesn't seem like it would make a difference. 😀

From the warning messages in the status window, it seems that the partition structure of the image is not understood, so the boot sector is not found, and therefore no boot. Maybe you can compare what drive_fat.cpp is doing to analyze the partition compared to what's in your image. A bit technical, but your initial post seems fairly technical, so maybe you'll find it an interesting challenge.

btw. lock stock Dosbox did have some problems with images larger than 512 MB (or somewhere around that size). Maybe this applies here. I *think* Hal's Megabuild does have a patch applied to allow larger images http://home.arcor.de/h-a-l-9000/

FYI, multiply all the geometry parameters together to get the disk size.

Maybe hal's build has some different/improved handling of the MBR, which could help.

In fact, after executing the below assembler instructions the DosBox hangs : mov sp, 0400 <---- debug boot -l c mov bx, 0040 […]
Show full quote

In fact, after executing the below assembler instructions the DosBox hangs :
mov sp, 0400 <---- debug boot -l c
mov bx, 0040
mov ah, 4A
int 21
callback 0006 <---- Hangs here....

Please trace with f11 at that point (twice if needed), the callback should direct
the code flow to the mbr code.

Looking at the status window, your OS is most likely requiring portlevel access
to the hard disk, which dosbox does not provide.

wd : Thanks for the suggestion.

Yeah, the boot loader of my OS is indeed waiting for the data at a certain data-port of the hard-disk and hence is indefinitely waiting due to the lack of port-level access to the hard-disk which is in fact the OS-Kernel binary image mounted internally to DOSbox as a virtual hard-drive.

Actually, I tried the same on my Symbian Smartphone with the the S60 port of DOSBox by kolijoco and witnessed the same result. And I understand the respective cause to be the same as that of the Desktop version of DOSBox as mentioned above.

Cheers.