20 replies to this topic

[Divetoxx]

I created single primary partition on my new blank HDD, formatted it as NTFS and viewed MBR: the 16-byte partition record in MBR was
80 01 01 00 07 FE BF 09 3F 00 00 00 4B F5 7F 00
Next I did "save disk contents as image file" at offset 32256 with MBR and got myimage.img: the 16-byte partition record in MBR was
80 00 02 00 06 00 05 89 3F 00 00 00 4B F5 7F 00
I haven't understood why CHS parameters are VERY different from real....

1. first head is 0th (not 1) - partition starts from the very MBR (not after 63 sectors = 1th head) ???!!!
2. Oh, I see partition starts not from MBR but from next sector after MBR - sector 2. Very interesting, but really we have offset 32256 = 63 sectors!
3. Start cylinder = 0, good

4. Partition type 06, but it's not NTFS

5. Last head is 00 - how can it be? If partition start was moved to the beginning, partition end must too! (FE _minus_ 1 head is not = 0)
6. last sector is 5 - I cannot understand it
7. last cylinder bits 0-6 are right but why does bit 7 set??? My last cylinder is NOT 137th but it IS 522th!!!!!!!!

I am sad. What is that?

Edited by Divetoxx, 11 March 2012 - 08:50 PM.

[Olof Lagerkvist]

I created single primary partition on my new blank HDD, formatted it as NTFS and viewed MBR: the 16-byte partition record in MBR was
80 01 01 00 07 FE BF 09 3F 00 00 00 4B F5 7F 00
Next I did "save disk contents as image file" at offset 32256 with MBR and got myimage.img: the 16-byte partition record in MBR was
80 00 02 00 06 00 05 89 3F 00 00 00 4B F5 7F 00
I haven't understood why CHS parameters are VERY different from real....

ImDisk really just works with raw volume images rather than images with partition tables. But just to make things easier it auto-detects MBR and translates values to offset and size when you mount an MBR prefixed image. It also provides the option to create an MBR as prefix to a volume image you save. This MBR is created from best-guessed values from the volume, not necessarily in any way related to values in physical disk MBR. This means that it will be different in many ways but should define a partition with the same size as current volume size.

Most important, the MBR built by ImDisk is not necessarily compatible with any particular physical disk. It should be treated as some kind of "best guess". If you need the MBR from the physical disk, copy that one directly instead. Use for example rawcopy -m \\?\PhysicalDrive0 D:\image.dsk or similar to get an exact copy of MBR with partition.

1. first head is 0th (not 1) - partition starts from the very MBR (not after 63 sectors = 1th head) ???!!!
2. Oh, I see partition starts not from MBR but from next sector after MBR - sector 2. Very interesting, but really we have offset 32256 = 63 sectors!

Yes, from what I recall right now that sounds correct. Volume starts right after MBR in this case.

3. Start cylinder = 0, good

4. Partition type 06, but it's not NTFS

It always puts 06 there as partition type. It could be more correct to implement some kind of auto-conversion between file system type and the most commonly used partition type for that filesystem type, but is that really needed anywhere?

5. Last head is 00 - how can it be? If partition start was moved to the beginning, partition end must too! (FE _minus_ 1 head is not = 0)
6. last sector is 5 - I cannot understand it
7. last cylinder bits 0-6 are right but why does bit 7 set??? My last cylinder is NOT 137th but it IS 522th!!!!!!!!

I am sad. What is that?

The following routine is used to build up CHS values (pseudo C-style code):

	cylinder = LBA / (heads_per_cylinder * sectors_per_track)

	temp = LBA % (heads_per_cylinder * sectors_per_track)

	head = temp / sectors_per_track

	sector = temp % sectors_per_track + 1



  if ((cylinder >= 1024) |

	  (head >= 256) |

	  (sector >= 64))

	{

	  cylinder = 1023;

	  head = 254;

	  sector = 63;

	}

[Divetoxx]

(head >= 256)

Wouln't You answer please, why 256? 0-254 are 255 heads.......

And I'm interesting in heads_per_cylinder = ?, sectors_per_track = ?
Thank You

[Olof Lagerkvist]

Wouln't You answer please, why 256? 0-254 are 255 heads.......

I cannot remember right now why. We need to look at the discussion that lead to this implementation. It should be either on this forum or somewhere else, I don't remember right now but I am sure it can be found out if it is a simple typo or if there is some reason for it.

And I'm interesting in heads_per_cylinder = ?, sectors_per_track = ?
Thank You

These values are retrieved using an IOCTL_DISK_GET_DRIVE_GEOMETRY call on the disk volume. It retrieves the CHS geometry for the disk where the volume is stored. A good way to know which values are used could be to use my devioctl tool.

C:\>devioctl geometry C:

Disk CHS geometry:

Media type	: 12

Cylinders	 : 121601

Tracks per cyl: 255

Sectors per tr: 63

Bytes per sect: 512

Total CHS size: 1000202273280 (931.5 GB)



LBA length	: 131078029824 (122.1 GB)



Partition information:

Start offset  : 32256

Partition size: 131078029824 (122.1 GB)

Hidden sectors: 63

Partition no  : 1

Partition type: 0x7

Boot indicator: 0

Recognized par: 1

C:: The operation completed successfully.

[Wonko the Sane]

@Olof
With all due respect , the behaviour is "terrible".

Basically IMDISK is getting as "input" a "balanced" CHS/LBA partition table entry and creates as "Output" an "UNbalanced" one.

IF the "input" has correct DATA in the bootsector BPB of the partition, I see NO reason why this should happen (whilst IF the bootsector has "wrong" values in the BPB this behaviour would be "normal").

@Divetoxx
JFYI, if you like "the game" you may find useful my little spreadsheets here:
http://reboot.pro/2959/

The PT entry you supplied is "perfect" assuming a 255/63 geometry:
01 80 0 1 1 521 254 63 63 8.385.867

The one IMDISK created is NOT "compatible" with any "known" geometry (and actually is not compatible with *any* possible geometry)
521*255*63+254*63+63=8385930
8385930-5=8385925 which gives, divided by 137, a non even number of Heads x Sectors.


Wonko

[Olof Lagerkvist]

@Olof
With all due respect , the behaviour is "terrible".

Basically IMDISK is getting as "input" a "balanced" CHS/LBA partition table entry and creates as "Output" an "UNbalanced" one.

IF the "input" has correct DATA in the bootsector BPB of the partition, I see NO reason why this should happen (whilst IF the bootsector has "wrong" values in the BPB this behaviour would be "normal").

I suspect that root of all this could be if geometry returned by a IOCTL_DISK_GET_DRIVE_GEOMETRY call on the volume about to be saved is different from the "BIOS geometry" stored in physical disk MBR. Or the problem might be something entirely else. Not sure really. I suppose we need someone more familiar with geometry calculation to look over the conversion routines.

In my experience it usually produces more sensible CHS values when you save an ImDisk drive than if you save some other kind of volume. Again, it should be possible to pin down what happens using the physical MBR values, the values returned by IOCTL_DISK_GET_DRIVE_GEOMETRY (my devioctl tool with geometry parameter shows that values) and then the values that actually end up in the MBR built for the saved image file.

Current C code for LBA to CHS conversion routine:

  DWORD cylinder =

	LBA /

	DiskGeometry->TracksPerCylinder / DiskGeometry->SectorsPerTrack;



  DWORD temp =

	LBA %

	DiskGeometry->TracksPerCylinder / DiskGeometry->SectorsPerTrack;



  DWORD head =

	temp /

	DiskGeometry->SectorsPerTrack;



  DWORD sector =

	temp %

	DiskGeometry->SectorsPerTrack + 1;



  if ((cylinder >= 1024) |

	  (head >= 256) |

	  (sector >= 64))

	{

	  cylinder = 1023;

	  head = 254;

	  sector = 63;

	}



  return

	head |

	(sector << 8) |

	((cylinder & 0x0FF) << 16) |

	((cylinder & 0x300) << 14);

DiskGeometry is a structure that is returned by the system in an IOCTL_DISK_GET_DRIVE_GEOMETRY call. Total size is retrieved in an IOCTL_DISK_GET_PARTITION_INFO call. The start LBA address is set to DiskGeometry->SectorsPerTrack and LBA number of sectors is set to Total size / DiskGeometry->BytesPerSector.

This LBA to CHS conversion routine quoted above is then called once for start LBA address and once for LBA start adress + LBA number of sectors - 1. Resulting CHS start and end values are then stored in the new MBR.

Do anyone notice something obvious?

[Wonko the Sane]

What I was pointing out was something slightly different.

You need "sound" H/S values in the BPB of the bootsector anyway.
NO MATTER what IMDISK "thinks" a pre-made disk image should be mounted with the H/S values in the BPB, to be consistent.
As an example this is what is normally done with VDK (which defaults to 64/32 geometry) using the VMware 2.x -pln descriptor file.
A nice feature for IMDISK could be to be able to use (optionally) such simple descriptor files or (in the mentioned case of a pre-partitioned/pre-formatted image) read these data directly from the BPB and "trust" them, using the geometry there specified.

I cannot understand what you posted, let alone the C code.
The "generic" routines are (quoted from the mentioned spreadsheet):

In batch language:

To get CHS from LBA:
CYL = LBA / (THds * TSec)
TEMPVAL = LBA % (THds * TSec)
HEAD = TEMP / TSec
SECT = TEMP % TSec + 1

Where:
LBA: linear base address of the block
CYL: value of the cylinder CHS coordinate
THds: Total number of heads per cylinder for the disk
HEAD: value of the head CHS coordinate
TSec: Total number of sectors per head for the disk
SECT: value of the sector CHS coordinate
TEMPVAL: buffer to hold a temporary value

To get LBA from CHS values:
LBA = ( ( CYL * Thds + HEAD ) * Tsec ) + SECT - 1




Where:
LBA: linear base address of the block
CYL: value of the cylinder CHS coordinate
THds: Total number of heads per cylinder for the disk
HEAD: value of the head CHS coordinate
TSec: Total number of sectors per head for the disk
SECT: value of the sector CHS coordinate

(All values are INTEGERS when using math operations in batch)

Wonko

[Olof Lagerkvist]

What I was pointing out was something slightly different.

You need "sound" H/S values in the BPB of the bootsector anyway.
NO MATTER what IMDISK "thinks" a pre-made disk image should be mounted with the H/S values in the BPB, to be consistent.
As an example this is what is normally done with VDK (which defaults to 64/32 geometry) using the VMware 2.x -pln descriptor file.
A nice feature for IMDISK could be to be able to use (optionally) such simple descriptor files or (in the mentioned case of a pre-partitioned/pre-formatted image) read these data directly from the BPB and "trust" them, using the geometry there specified.

That certainly makes sense, but this one is a little bit different. In your example, ImDisk "knows" of a complete MBR-prefixed image file, for which it can use the values stored there. This is because ImDisk itself created the volume that the user is about to save. But in the case this thread started with, ImDisk saves contents from a volume it does not know anything about, apart from what Windows system calls can tell.

For example, if you save contents of volume C:, all ImDisk can do is to call above mentioned geometry routines Windows provides and then try to use them in a "best guess" way. It has no knowledge of any "original values" that it can use and trust and not recalculate with its own guessed values. That is where the problem starts.

Now, even if we could find out and implement better calculations, I would still recommend to copy from the \\.\PhysicalDriveN object and thereby get the original MBR where possible, instead of letting ImDisk try to guess the same values.

[Wonko the Sane]

We are mixing three things.
Item #1: Having IMDISK create a proper CHS and LBA partition table entry when "exporting with MBR".
Item #2: Optionally allow to have H/S geometry set by using a configuration file for the image
Item #3: More generally have IMDISK be able to deal in a better way with Disk Images (as opposed to Partition/Volumes or Filesystems)

Item #1:
Unless you take some time explaining the C snippet you posted, I cannot help you, as I simply cannot understand the underlying algorithm.

Item #2:
Already talked about and possibly self-explaining.

Item #3:
A Volume or partition inside a disk image will have in it's BPB:
@offset 0x18 2 bytes "Sectors per Head" <- this is the S in CHS
@offset 0x1A 2 bytes "Number of Head" <- this is the H in CHS
In the case of a pre-partitioned or pre-formatted Disk Image, IMDISK could (should) use the HS geometry it finds in the BPB of the Volume/partition it is mounting and needs NOT to perform ANY calculation. This would "automatically" remove (in the mentioned case) the need for item #2 which would then only be needed when one wants to use IMDISK to create a "new" image.
In any case the number of possible geometries is in theory very high, but in practice for HD-like devices, they are a handful.
Known H/S geometries (at least to me) are:

• 255/63 <- usual/default in 2K and later
• 64/32 <- found in VDK (and possibly derived from NT 4.0 or previous) and in Iomega ZIP disks
• 128/63 <- quite rare, only found in WinHex (possibly another remainder of NT 3.x/4.x)
• 16/63 <- quite common in the old days due to the combined CHS/ATA limits of BIOS and used in smallish images by QEMU
• 240/63 <- one of the stupidiest one, found in many Lenovo laptops and also on a number of HP low-end desktops, see:

http://www.pcguide.com/ref/hdd/bios/sizeGB394-c.html
http://www.pcguide.c...izeGB738-c.html


Wonko

[Olof Lagerkvist]

We are mixing three things.
Item #1: Having IMDISK create a proper CHS and LBA partition table entry when "exporting with MBR".
Item #2: Optionally allow to have H/S geometry set by using a configuration file for the image
Item #3: More generally have IMDISK be able to deal in a better way with Disk Images (as opposed to Partition/Volumes or Filesystems)

Item #1:
Unless you take some time explaining the C snippet you posted, I cannot help you, as I simply cannot understand the underlying algorithm.

Sorry, I forgot to comment that part. I verified my C code snippet against your batch code and they seem to do the same thing as far as I can tell. That is why I did not explained it further.

Item #2:
Already talked about and possibly self-explaining.

Item #3:
A Volume or partition inside a disk image will have in it's BPB:
@offset 0x18 2 bytes "Sectors per Head" <- this is the S in CHS
@offset 0x1A 2 bytes "Number of Head" <- this is the H in CHS
In the case of a pre-partitioned or pre-formatted Disk Image, IMDISK could (should) use the HS geometry it finds in the BPB of the Volume/partition it is mounting and needs NOT to perform ANY calculation.

But it could be difficult anyway. Consider for example that you save second partition of a harddisk and select to prefix that image file with a new MBR. Currently, ImDisk just knows that you save a volume, not that this volume is stored on a particular physical disk or anything like that. It reserves 63 sectors at the beginning of the image file and uses the geometry Windows reports to calculate CHS start and end values for the partition entry to store in the new MBR. The new MBR for the image file will contain one partition entry which will point to the position in image file where the volume contents will start. So, even if it could somehow find the MBR for the physical disk where the partition is stored (should be possible) it cannot use the partition values there because it points to a second partition which does not start where it will be saved in the image file.

So, if you want to save an entire physical disk I would strongly recommend to do so, instead of saving just one volume and let the MBR be created from "best guess" values.

That said, we could of course change this behaviour to instead find and copy MBR from original physical hard disk and write the volume to be saved at the position corresponding to the position it has on physical disk (possibly leaving a gap for partitions between beginning of file and where the partition to save will begin). Another alternative would be to provide a new option for the user, an option to save entire physical disk with original MBR, partitions and everything. Or something else. I have no particular favourites among these alternatives. Any of them sounds reasonable to me. Ideas?

This would "automatically" remove (in the mentioned case) the need for item #2 which would then only be needed when one wants to use IMDISK to create a "new" image.

Absolutely. But that is where we already are, essentially. I hope you agree that for building a new MBR, it feels most correct to use the drive geometry that Windows reports for a non-ImDisk volume. The main question here is whether we can trust or not that these values are the same as the values used by BIOS for CHS calculations. There should probably not be any difference, but it would cause some problems if values cause LBA to CHS conversion to produce strange CHS values. In that case we would need to change the conversion algorithm instead. But I strongly doubt it. There could be something else wrong somewhere...

In any case the number of possible geometries is in theory very high, but in practice for HD-like devices, they are a handful.
Known H/S geometries (at least to me) are:

• 255/63 <- usual/default in 2K and later
• 64/32 <- found in VDK (and possibly derived from NT 4.0 or previous) and in Iomega ZIP disks
• 128/63 <- quite rare, only found in WinHex (possibly another remainder of NT 3.x/4.x)
• 16/63 <- quite common in the old days due to the combined CHS/ATA limits of BIOS and used in smallish images by QEMU
• 240/63 <- one of the stupidiest one, found in many Lenovo laptops and also on a number of HP low-end desktops, see:

http://www.pcguide.c...izeGB394-c.html
http://www.pcguide.c...izeGB738-c.html

Yes, these values should reflect what is stored in the MBR that ImDisk builds when a user saves a physical partition volume as image file, as long as Windows reports them correctly. I will do some checks and see how it converts values "in real life" and what differences there are between physical disk MBR and the one built by ImDisk.

The results that have came up in this thread actually look a little off-reasonable-deviation. I agree with that. It is just that the solution is not entirely obvious.

Anyway, thanks for your hints and great help!

[Wonko the Sane]

Item #1.
Well, if the C snippet results gives the same result, then the information about h/s geometry is either incorrect or interpreted incorrectly.
As said, not only the result posted by OP is not compatible with any "known" geometry, but it cannot result from *any* geometry.

Item #3
Your reply does not (again) take into consideration the data in the BPB.
Again, that data NEEDS to be accurate AND the geometry of the original image can be gathered by these data without any calculation, it is just a matter of reading two values.

Again, with all due respect you are going down EXACTLY the SAME path that Gilles Vollant went (with - unfortunately - not very good results ) when he extended Winimage from being able to manage ONLY floppy and superfloppy to being able to manage hard disk images.
The "export image with MBR" in Winimage produces - just like IMDISK corresponding feature has been reported to behave in this thread - something almost, but not quite, entirely UNlike a valid partition table entry.

Expecially nowadays assuming that a volume will go in a hard-disk image respecting cylinder boundary is "wrong" as "current" NT based systems, i.e. Vista and later do default to 4 Kb alignment, or, if you prefer, first partition will start at 0/32/33 LBA 2048 instead of 0/1/1 LBA 63 (still in the default 255/63 H/S geometry).

As I see it, if you want to extend IMDISK to manage "properly" disk images, you will need to go into the pain of - besides "fixing" the currently botched CHS generated entry - providing a new set of "user-selectable" choices.

As you know I am not a programmer, but I really see nothing particularly difficult in doing the above.

Basically (and IMNSHO ):

• IF the loaded volume inside a disk image is NOT resized, allow for an option to use the already existing MBR "as is" (dd or rawcopy style) including it's CODE (besides the DATA)
• IF the loaded volume is a "superfloppy" or is created within IMDISK, allow for an option to create MBR DATA (with correct values ) AND at least a switch between THREE "modes":

• Cylinder boundary aligned (old approach) with 63 "Sectors before"
• 4K aligned (new approach) with 2048 "Sectors before"
• User manual input

the above three are "LBA based" (and you have to manage it anyway in the BPB of the volume @offset 0x1C), then you can convert the values to CHS (for the MBR entry) AND use for it the SAME H/S geometry you need to manage anyway in the BPB @offset 0x18 and 0x1A.
This geometry should also be changeable by the user, as it is "vital" for bootability on a number of VBR code (notwithstanding that NT will use LBA addressing for accessing the filesystem).

See:
http://www.911cd.net...showtopic=23408
and links therein.

To become "complete" you would also need to provide a way to write to the newly created MBR at least the MBR CODE of the OS where IMDISK is used.

The alternative, as I see it, is removing the current "export with MBR" and leave IMDISK be a Volume/Partition/Filesystem related tool and NOT a DISK one....



Wonko

[Olof Lagerkvist]

Item #1.
Well, if the C snippet results gives the same result, then the information about h/s geometry is either incorrect or interpreted incorrectly.
As said, not only the result posted by OP is not compatible with any "known" geometry, but it cannot result from *any* geometry.

I will check that more closely as soon as possible. I need to follow the code and see what values each step produces to see what really happens. I will come back to that soon.

Item #3
Your reply does not (again) take into consideration the data in the BPB.
Again, that data NEEDS to be accurate AND the geometry of the original image can be gathered by these data without any calculation, it is just a matter of reading two values.

Alright, I see now that we probably have misunderstood eachothers in some way. Or something like that. I did not mean that I ignore BPB values and that the MBR creating routine tries to guess the disk geometry using some kind of calculation in any way. Once again, it calls a Windows function to get the geometry values. Like I wrote (or intended to write) in my previous post, I hope that the returned values are the same as the values stored in the BIOS parameter block, but I am not yet entirely sure. But I doubt there would be any differences because there really should not be any reason to read BPB values directly from disk instead of calling IOCTL_DISK_GET_DRIVE_GEOMETRY. After all, that call is intended to return - the disk geometry. Anyway, it could be worth double-checking now during my tests because if there are differences there it could explain some strange calculation results.

So, what I meant that the MBR build routine needs to calculate, is start and end addresses for the partition entry it is about to create in the new MBR. Like I said, values there will not, after calculations, necessarily look exactly like the values found in MBR of physical disk and even if it could lookup the values there they are not necessarily useful because they could point to some entirely different place than where the volume will be written in the image file (if there are partitions before the saved one, etc).

See?
(I know that I have not expressed myself particularly clear in this thread, so I apologize for any frustration caused by that.)

Again, with all due respect you are going down EXACTLY the SAME path that Gilles Vollant went (with - unfortunately - not very good results ) when he extended Winimage from being able to manage ONLY floppy and superfloppy to being able to manage hard disk images.
The "export image with MBR" in Winimage produces - just like IMDISK corresponding feature has been reported to behave in this thread - something almost, but not quite, entirely UNlike a valid partition table entry.

Well, I think that a reasonable limitation could be to produce an MBR with some kind of default values, default boot code and CHS addresses calculated from current disk geometry (again, the geometry we get from a system call, should be same as values in BPB). For other cases I would say it is better to provide an option to save entire physical disk with MBR and all partitions. Everything in-between would be just asking for trouble, future-and-backwards-incompatibility and lots of frustration. I honestly see no sane reason for trying to implement that in the "save volume as image" features of ImDisk. It could be something for another physical disk to image conversion tool project if someone wants to start (yet another) such project, but nothing for ImDisk.

Again, thanks for your time and effort in trying to explain all this to me. I have a feeling that it is not entirely easy...

[Wonko the Sane]

No frustration whatsoever , sometimes I tend to be "direct" or plainly "blunt" just to make sure that the message "arrives" , and I also tend to see things in B/W, like in IMDISK beng either a disk related tool only OR a volume related tool ONLY.

But world is not Black and White, it has all the shades of grey :
http://reboot.pro/15878/

The "importance" of the items discussed is anyway "relative" as:

• Any value (even completely wrong ones) in the BPB will have NO consequences whatsoever if not for bootability (as LBA is used anyway).
• Any value (even completely wrong ones) in the MBR CHS part will as well have NO consequences whatsoever if not for bootability.

AFAIK anything CHS related is simply ignored and LBA only is used on NT based systems, that represent what, 99% of use of IMDISK .


Wonko

[Divetoxx]

I am planning the next experiment tomorrow:

I have physical HDD with mbr and single partition on it. This partition is created manually at 63 sectors offset. I found Diskpart in Windows 7 and Windows 8 creates first partition NOT at 63 sectors offset even align=63 was given in console command.
I hope the BIOS must support 255/63 geometry.
My partition has 522 cylinders.

I will connect my HDD to 1st computer running Windows XP SP3, install the last imdisk and capture the partition.

Then I will connect my HDD to 2nd computer running Windows 7, install the last imdisk and capture the partition.

Then I will connect my HDD to 3rd computer running Windows 8, install the last imdisk and capture the partition.

Then I will compare these three .IMG files: what MBRs they are started from? Different hardware, different operation systems - will the MBRs be different?

Edited by Divetoxx, 12 March 2012 - 07:28 PM.

[Wonko the Sane]

I have physical HDD with mbr and single partition on it. Partition is created manually at 63 sectors offset. I found Diskpart in Windows 7 and Windows 8 does not create partition at 63 sectors offset even align=63 is written by me in console command. I hope the BIOS must support 255/63 geometry.

Of course cannot say about 8, but 7 works allright from GUI disk manager with the Registry settings:
http://www.911cd.net...showtopic=21186
http://www.911cd.net...pic=21186&st=18

JFYI
http://reboot.pro/9897/

The diskpart command align does NOT work as you seemingly used it, the parameter of align= is expressed in Kb!
http://synsol.eu/blo...rect-alignment/
http://technet.micro...5(v=ws.10).aspx
you might be luckier using the offset= parameter.


Wonko

[Divetoxx]

the parameter of align= is expressed in Kb!

Oh My God! I was mistaken! Thank You very much. I have to work less at night

Of course cannot say about 8, but 7 works allright from GUI disk manager with the Registry settings

Thanks, but I prefere more low-level editing... If I need the partition with exact parameters I will write all 16 bytes manually in hex editor If I see every hex value I can be sure that it is right value.

[Wonko the Sane]

Thanks, but I prefere more low-level editing... If I need the partition with exact parameters I will write all 16 bytes manually in hex editor If I see every hex value I can be sure that it is right value.

Should you - by any chance - trust me :
http://reboot.pro/3191/


Wonko

[Divetoxx]

Should you - by any chance - trust me : http://reboot.pro/3191/

Thank You. May I ask: How to create a "partition with exact number of cylinders" in easiest way? For example, with 522 cylinders - it's a magic number Why magic? Because 522 cylinders partition ideally fits in 4Gb RAM.
I found easiest way is using clonedisk http://erwan.l.free....edisk/body.html With this great tool It is possible to edit each byte in partition table manually. Easiest for people. As for me, this is easier:

format PE GUI 4.0

include 'includewin32a.inc'

[........ filling buf with needed values.................]

invoke CreateFile,fnam,GENERIC_WRITE,0,0,OPEN_EXISTING,0,0
mov [hhdd],eax
invoke WriteFile,eax,buf,512,hows,0
invoke CloseHandle,[hhdd]
invoke ExitProcess,0

fnam db '.PHYSICALDRIVE0',0
hhdd rd 1
hows rd 1
align 16
buf rb 512

data import
library kernel,'KERNEL32.DLL'
import kernel,CreateFile,'CreateFileA',WriteFile,'WriteFile',CloseHandle,'CloseHandle',ExitProcess,'ExitProcess'
end data

That's all source! It can be compiled with http://flatassembler.../fasmw16942.zip

[Wonko the Sane]

Thank You. May I ask: How to create a "partition with exact number of cylinders" in easiest way? For example, with 522 cylinders

With the batch?
Just input the geometry and the LBA size (or input manually the CHS data).

To have a MBR like the one you posted:

mbrbatch create test.mbr [ENTER]

then:

mbrbatch edit [ENTER]

test.mbr [ENTER]

(255/63)[ENTER]

(CHS)[ENTER]

(1)[ENTER]

07[ENTER]

(80)[ENTER]

(0)[ENTER]

(1)[ENTER]

(1)[ENTER]

521[ENTER]

(254)[ENTER]

(63)[ENTER]

YES[ENTER]

or:

mbrbatch edit [ENTER]

test.mbr [ENTER]

(255/63)[ENTER]

LBA[ENTER]

(1)[ENTER]

07[ENTER]

(80)[ENTER]

(63)[ENTER]

8385867[ENTER]

YES[ENTER]

(values in brackets need not to be typed since they are default, you can just press [ENTER]


Wonko

[Divetoxx]

Good tool! I like it (mbrbatch). Well, can I edit "drive signature" too?

Edited by Divetoxx, 13 March 2012 - 09:54 AM.

[Wonko the Sane]

Good tool! I like it (mbrbatch). Well, can I edit "drive signature" too?

No (in the sense that is not an implemented feature at the moment), but there are a lot of handy tools (besides a hex editor), namely MBRFIX or MBRWIZ would do nicely:
http://www.sysint.no...ting/mbrfix.htm
http://firesage.com/mbrwizard.php
(look for freeware CLI or for the Legacy version)
Or our "in-house" little GUI tool:
http://reboot.pro/12077/

If using a hex editor, suggestion is for tiny hexer (with my little Mbr Structure viewer ):
http://reboot.pro/8734/

Maybe we should start new thread, not to go too much OT on this IMDISK related one.....


Wonko