What hard drive images does grub4dos support?

I am wondering what other hard drive image type does grub4dos support that isn't VHD or raw? I have been having lots of issues with those 2 formats. For example any VHD I make seem to give me a total sector warning, that the partition table sectors doesn't seem to match what it calculates, picture below. Also I know that Raw images that I mount , anything I write to it, just disappears and I know the drive is mapped directly and not indirectly using the mem option. I believe that Raw images are better than other disk images, which I want to use but can't seem to support writing to them using direct map? I can direct map a floppy image, any change to it on the a: drive seems to be on the disk image when I reboot. or can someone help me out with my issues?

Rest assured that grub4dos correctly works with both RAW and "static" VHD's (and also with "dynamic" VHD's, but these only if --mem mapped, I believe).

 

That message is a warning, not an error.

 

Still, what grub4dos attempts to do is to "synchronize" the geometry with the actual image size.

 

If you have 31/16/63 you have 31*16*63=31248 sectors. (your actual partition table may use a fractional cylinder).

 

Your image is instead 30721 sectors, I believe that to be a VHD, i.e. a 30720 sectors * 512 bytes=15,728,640 bytes one + 1 excess sector (the VHD footer) that you created by making a 15 MB image (as 15*1024*1024=15,728,640)

 

"properly" sized RAW images will anyway throw the same error IF you make them into a VHD (because of the excess sector, so the warning will be that the image is larger (by one sector), unless you - on purpose - make the RAW image one sector less than what it should be.

 

On a 16/63 geometry the image size needs to be an exact multiple of 16*63*512= 516,096 bytes to avoid the warning (that can be ignored anyway).

 

Post an example of the EXACT way you are mapping the image, a directly mapped image is normally read/write and "persistent".

Detail also how exactly are you writing to it.

 

Wonko

Are you using a VM or a real system?

Are you using a VM or a real system?

 

I'm using virtualbox for right now , it will be transferred to one of my windows 9x based laptop very soon. I am planning to boot windows 3.1x on it through grub4dos eventually, since it have full drivers for windows 3.1x except for the onboard winmodem, so its going to be booting  I believe windows 98 and than have the ability to boot a windows 3.1x image.

Thats why writes are not working!

For VBox use DavidB's VMUB

Latest version on GitHub here

Edited by steve6375, 11 March 2018 - 01:17 PM.

Thats why writes are not working!

For VBox use DavidB's VMUB

 

well If I mount a floppy image directly It can read/write it fine, I'm only having issues with hard drive.

Edited by MichaelWeaser, 11 March 2018 - 01:17 PM.

Rest assured that grub4dos correctly works with both RAW and "static" VHD's (and also with "dynamic" VHD's, but these only if --mem mapped, I believe).

 

That message is a warning, not an error.

 

Still, what grub4dos attempts to do is to "synchronize" the geometry with the actual image size.

 

If you have 31/16/63 you have 31*16*63=31248 sectors. (your actual partition table may use a fractional cylinder).

 

Your image is instead 30721 sectors, I believe that to be a VHD, i.e. a 30720 sectors * 512 bytes=15,728,640 bytes one + 1 excess sector (the VHD footer) that you created by making a 15 MB image (as 15*1024*1024=15,728,640)

 

"properly" sized RAW images will anyway throw the same error IF you make them into a VHD (because of the excess sector, so the warning will be that the image is larger (by one sector), unless you - on purpose - make the RAW image one sector less than what it should be.

 

On a 16/63 geometry the image size needs to be an exact multiple of 16*63*512= 516,096 bytes to avoid the warning (that can be ignored anyway).

 

Post an example of the EXACT way you are mapping the image, a directly mapped image is normally read/write and "persistent".

Detail also how exactly are you writing to it.

 

Wonko

OK I am using this to mount the image for now, I need to mount the hard drive image, and load ms-dos 6.22 to format it: 

Edited by MichaelWeaser, 11 March 2018 - 02:40 PM.

How is the VM set up?

WHat is hdo, what is fd0, how are they attached to the VM?

How is the VM set up?

WHat is hdo, what is fd0, how are they attached to the VM?

The way that I am testing it right now is, I am running grub.exe directly from a installation of windows 98's ms-dos 7.1 on a very small 1Gb disk , the way its formatted is like it has a 40MB fat32 partition ( which all files are on) and the rest is formatted as fat16. The reason I don't want ms-dos 6.22 to have access to the files, So that is why I'm using windows 98's DOS, to have fat32 and once its boots the MS-DOS 6.22 hard drive image, it only has access to the 2nd partition. I really don't understand the 2nd part , don't know what you mean by hd0 or fd0, unless you are wondering about the images for grub4dos, the fd0 is a ms-dos 6.22 floppy , and hd0 ( actually for right now its hd1) is a 30M raw image. the 30M needs formatted so I have to moun the 30M , and boot ms-dos 6.22 to attempt to format it. Actually before I mounted the raw image, I attempted to format it by mounting the raw image using a program, and format it. But ms-dos 6.22 fdisk doesn't like that, fdisk says its partitioned and its weird. Also could you mean by how I say the fd0 read and writes, but the hd0 won't when mounted directly , well the fd0 was the same image but booted from grub4dos and not directly from virtualbox, and than the hd0 is the same 30M image. 

Any know why a blank 40MB VHD, 2 identical copies are different when formatted using the windows disk manager tool to create and mount VHD's and then formatted in virtualbox. If I format 1 40MB VHD in the disk manager tool when unmounted and than look at it in 7-zip, it shows as another image as disk.img , than when you open that it shows the contents of the vhd. In virtualbox its different getting the other copy of the 40MB VHD , formatting it using ms-dos 6.22 FDISK from boot floppy,  in 7-zip it shows up the contents of the VHD without disk.img like the windows disk manager tool created VHD. Also what I found out is that virtualbox possibly can't read VHDs made by windows disk manager tool? If I mount the VHD created by disk manager tool into virtualbox , load the ms-dos 6.22 boot floppy and check the disk with FDISK there is nothing there, says its a blank VHD, even if formatted it before it was mounted into virtualbox. Either Ms-dos 6.22 can't read the partition created by windows disk manager , or the VHD isn't readable in virtualbox. But of course a virtualbox created VHD reads/writes fine when mounted by windows disk manager. It seems to me there are different VHD formats?

Can't you change the CHS because I think there is a --heads setting for the config menu file? Don't remember if there are settings for the cylinders, and sectors. I was also told  you change the CHS in the partition table, or in the Bios Parameter block (BPB) ? Also you are saying my VHD is a 15MB image, its actually a 30MB image, with 1024 byte sectors,  but this is confusing though , if I mount the image directly into virtualbox , and use a program to tell me the CHS, it says it has 512 byte sectors and it tells me the CHS is higher. I know grub4dos is saying the 30M image is 1024 byte sectors because of the CHS being 31/16/63. I don't remember if it has 512 or 1024 byte sectors, I believe it's 1024, but I can be wrong. Also the DOS program I use also tells me the CHS is different from LBA as a warning.

No.

An image in itself has no sector size (unlike hardware).

There is not any media with 1024 bytes sector (I am lying there used to be a very particular and extremely uncommon floppy drive that used 1024 bytes sector, if I recsall correctly).

ALL (and I mean ALL):
1) floppy disk like devices manufactured in the last - say - 25 years have 512 bytes/sector
2) CD/DVD/optical media have 2048 bytes sectors
3) hard disks of any kind (again manufactured in the same last 25 years or so) have either 512 bytes sectors (until - say 2012 or so) or, if - and only if - they are very recent, have 4096 bytes/sector BUT most of them, like 95% or more of them, expose anyway 512 bytes/sector, native 4Kb drives are still very rare (and in any case they won't be bootable with most OS/on most machines).
4) USB sticks and the like also use 512 bytes/sector

More than that "normal" (like the standard DOS, Win9x/Me, Windows NT up to Windows 10, etc.) MBR code simply wont' support them, PBR may, but not as a bootable device.

Rest assured that any normal VM (like Virtualbox, Qemu, VirtualPC and VmWare) will see the hard disk image as having 512 bytes sector.

The issue with CHS geometry sensed comes from BIOS and it is dependent on size of the image (and on the specific BIOS of the VM).

Typically small images will be having 16/63 geometry (up to a size that exhausts CHS addresses with that geometry), i.e. 1024*16*63*512=528,482,304 i.e. the first CHS limit of around half a GB.
Although there used to be drives and BIOSes using a 128*63 geometry, usually the next step is the common 255*63 geometry. and of course, while the HS geometry remains, the CHS addressing is exhausted at 1024*255*63*512=8,422,686,720, i.e. the infamous arounf 8 GB CHS limit.
 
Windows XP and later will default to 255/63 geometry, doe mounted images unless you use a particular driver capable of specifying the geometry (that would be the VDK by Ken Kato, when using yet another kind od VMWare descriptor, the .pln ).

Different BIOS and OS's or tools may "decide" to use even for very small images the 255/63 geometry, or go down to the 16/63 one, and as well different tools and OS's may assume something depending on the contents of the MBR or of the PBR or of both.

Use a BLANK (all zeroes) image and have it partitioned/formatted "natively" inside the VM.

You don't need grub4dos for this.

The "read only" issue you are having is because you are not mapping directly (as you should) the image in the VM, but you are attempting to access a file on a "real" hard disk mapped in the VM.

Virtualbox cannot directly mount a RAW image (and you should be careful with which type of VHD you are making).

IMHO you'd better use a RAW image, creating a VMDK descriptor for it, in my experience Virtualbox has no issues whatever with such images, see:
https://www.forensic...wtopic/t=15861/
use the batch/info I posted here:
https://www.forensic...590531/#6590531

If you don't feel confident with the batch or you have issues with the concepts, provided that your BLANK, RAW image is called "image.raw" and it is say (you can change the number to the EXACT size in 512 bytes sectors here I am using the 31248 seen before), you can copy and paste this:
 

# Disk DescriptorFile
 version=1
 createType=
 RW 31248 FLAT "image.raw" 0
 ddb.uuid.image="00000000-0000-0000-0000-000000000001"

Copy the above to a new file in Notepad (change if needed the number after RW to the EXACT size of your image in 512 bytes sectors) and save it where your image.raw is as "image_raw.vmdk".
Then add to the VM a "IDE controller" and under it choose to add a new hard disk, choose existing disk and point to  "image_raw.vmdk".
 

Wonko

No.
 

 

When I talking about changing the CHS using --heads, in the .VHD image I used for GRUB4DOS in the menu.lst, I was talking about this - another forum post on this website : http://reboot.pro/to...rmat-with-grub/

 

This is about changing the heads amount : map --read-only --heads=10 (hd0,5)/oses/dosbase.raw (hd0)

 

its near the bottom of the post. I am thinking you can change the cylinders and sectors as well, since you can change heads.

 

-- I am going to try your suggestion , as soon as I can 

Edited by MichaelWeaser, 11 March 2018 - 08:30 PM.

The "read only" issue you are having is because you are not mapping directly (as you should) the image in the VM, but you are attempting to access a file on a "real" hard disk mapped in the VM.

 

 

 OK , I got that fixed , I can now read/write VHDs now, But I am now confused now the same thing that happened to the VHD is now happening to the raw image, now they won't write. FDISK will attempt to partition the disk , than ms-dos tells me you need to reboot , it reboots , I use grub, its not there in fdisk. I am using qemu-img to create the raw image this command : qemu-img create -f raw -o size=40M xxxx.raw 

 

Using this menu.lst now : 

 

By default the MBR boot sector is protected, meaning that you cannot write to it with the int13 BIOS call.

 

Please use map option of --unsafe-boot , as follows.

 

  map --unsafe-boot (hd0,0)/image.vhd or .raw (hd1)

No, the issue remains IMHO the same.
@MichaelWeaser

You are still not telling us how EXACTLY you are attaching WHAT to the VM.

From the menu.lst that you are posting it seems to me like you are attaching the real physical drive and then mount via grub4dos an image on it.

This won't work, per Steve6375's and my previous notes.

Alternatively, try to explain EXACTLY what you want to obtain (final goal) and we will try to give you appropriate instructions.


Wonko

No, the issue remains IMHO the same.
@MichaelWeaser

You are still not telling us how EXACTLY you are attaching WHAT to the VM.

From the menu.lst that you are posting it seems to me like you are attaching the real physical drive and then mount via grub4dos an image on it.

This won't work, per Steve6375's and my previous notes.

Alternatively, try to explain EXACTLY what you want to obtain (final goal) and we will try to give you appropriate instructions.


Wonko 

Well , I don't know what I did , but read/writing VHDs seem to work, but with raw it's no luck. 

 

this works for VHD's for me, I swear that i'm not lying to you:  

 

So you are outright confusing me since I know what is working and what is not working for me

 

 

So you are outright confusing me since I know what is working and what is not working for me

 

I don't in any way doubt that you know what is working and what is not working, I am plainly stating that you are completely failing at explaining/reporting your setup and what you are actually doing.

 

Nothing was farther from my intention than confusing you, but without any meaningful, exact, detailed description of your setup, of what you are doing and what is your final goal anyone attempting to help you can only mean making (more or less educated) guesses, which could have been anyway more graciously received.

 

No problem, I won't risk being accused of confusing you anymore, and won't insist on wringing out of you the basic needed info, the whole stuff has suddenly become a S.E.P. :

https://en.wikipedia..._else's_problem

 

Wonko

Virtualbox cannot directly mount a RAW image (and you should be careful with which type of VHD you are making).

IMHO you'd better use a RAW image, creating a VMDK descriptor for it, in my experience Virtualbox has no issues whatever with such images, see:
https://www.forensic...wtopic/t=15861/
use the batch/info I posted here:
https://www.forensic...590531/#6590531

If you don't feel confident with the batch or you have issues with the concepts, provided that your BLANK, RAW image is called "image.raw" and it is say (you can change the number to the EXACT size in 512 bytes sectors here I am using the 31248 seen before), you can copy and paste this:
 

# Disk DescriptorFile
 version=1
 createType=
 RW 31248 FLAT "image.raw" 0
 ddb.uuid.image="00000000-0000-0000-0000-000000000001"

Copy the above to a new file in Notepad (change if needed the number after RW to the EXACT size of your image in 512 bytes sectors) and save it where your image.raw is as "image_raw.vmdk".
Then add to the VM a "IDE controller" and under it choose to add a new hard disk, choose existing disk and point to  "image_raw.vmdk".
 

Wonko

 

 

 First off, I did finally figure how to get a raw image working , now I am sure I don't need anymore help

 needed unsafeboot  in grub4dos : map --unsafe-boot (hd0,0)/xxx.raw (hd1)

 

I couldn't get the VMDK descriptor you gave me working but I got this one working though (this descriptor is copied from a VMDK made by virtualbox): 

 

# Disk DescriptorFile

The "reduced" or "minimal" version worked for me at the time, but it is well possible that some Virtualbox version needs more fields, aka all the ones in the "canonical" version.

 

The batch "as is", should however be able to produce a correct "canonical" version.

 

Wonko

The "reduced" or "minimal" version worked for me at the time, but it is well possible that some Virtualbox version needs more fields, aka all the ones in the "canonical" version.

 

The batch "as is", should however be able to produce a correct "canonical" version.

 

Wonko

Yeah I can't seem to get the batch script to work, does it require DOS , or should it work in windows? In windows 10 64 bit, the batch errors out , tells me an error occurred.

Yeah I can't seem to get the batch script to work, does it require DOS , or should it work in windows? In windows 10 64 bit, the batch errors out , tells me an error occurred.

Windows 10 and 64 bit? 

 

At first sight there is nothing that shouldn't work on it.

 

Or not providing a parameter (the name of the image file)? <- that is the only reason why the batch would stop with a message:

DOn't you like when all you get is:
an Error occurred!

You need to open a command prompt and invoke it from command line providing the name of the image.

i.e. if the batch is called mybatch.cmd and the image name is image.raw you would invoke that as:

mybatch.cmd image.raw

the batch needs to be in the SAME directory as the image or you need to provide the full path to the image.

 

Wonko