Jump to content











Photo
- - - - -

Issue with Imdisk and bootsector?

imdisk bootsector

  • Please log in to reply
12 replies to this topic

#1 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2278 posts
  • Location:Nantes - France
  •  
    France

Posted 08 April 2014 - 07:16 PM

Hi There,

 

I'd like to report the following issue I am experiencing.

 

When running the below steps with ImDisk I end up with a non booting disk image whereas when using other mounting softwares (MS virtdisk, Arsenal driver) I do end up with a booting image.

 

1-Create a raw disk image (here test.img=64 MB)
2-Retrieve file size in sectors (here 131072)
3-Modify partition table : chs end/start=1023/254/63, sectors before=2048, total sectors=129023 (131072-2048-1)
4-Write nt6 mbr
5-Turn into vhd (optional / non relevant)
6-Mount disk image (ImDisk auto detect offset=2048)
7-Format to NTFS
8-Boot (in qemu or virtualbox)
 
In step 6, if I use ImDisk, image wont boot (in step 8) and I notice that hiddensec=1 in my boot sector.
Whereas, if I use MS Virtual Disk or Arsenal, image will boot and hiddensec=2048 (as it should).
 
Would this be a bug in ImDisk or is my above scenario flawed in some way?
As if ImDisk driver was wrongly reporting MBR datas to the format function.
 
Thanks for reading :)
 
Regards,
Erwan


#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14132 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 April 2014 - 07:44 PM

 

Would this be a bug in ImDisk or is my above scenario flawed in some way?
 

Part and part. :w00t: :ph34r:

The imdisk is a "volume" only virtual disk.

Olof made a provision to save with a MBR and hidden sectors, but this won't work in your scenario.

Basically when you mount a volume from a disk image IMDISK uses the info that it finds in the MBR to find the actual beginining of the volume, but once done that, what is mounted is just the volume (and the MBR is never accessed later) so that it doesn't "know" how many hidden sectors are present before, and the "format" finds a volume and sets the hidden sectors "wrongly".

Additionally you "risk" this kind of issue (JFYI):

http://reboot.pro/to...inixp/?p=178702

http://reboot.pro/to...e-4#entry178705

 

(depending on the actual boot sector code used and size of the image)

 

And, if the above was not enough, check, right after having formatted the volume if you can find in the last sector of the "backing" file, for the presence of the NTFS $Boot mirror. ;)

 

You remember this:

http://reboot.pro/to...ated-with-dsfo/

don't you? :dubbio:

 

 

:duff:

Wonko



#3 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2278 posts
  • Location:Nantes - France
  •  
    France

Posted 09 April 2014 - 07:18 AM

Indeed, I understand ImDisk is a "volume only" virtual disk as opposed to Arsenal (for example) which is a "harddrive" virtual disk.

But may be Olof could save the 16 bytes partition information (or even the full 512 bytes MBR) when mouting the image for later reuse hence ensuring a correct bootsector later on ?

 

I checked the ImDisk formatted image : backup boot sector is there at the end of the image.

So this part is consistent.

 

I checked the ImDisk saved image (with MBR option) : MBR does not match (no surprise as it is a generated one) the original:

-the partition type gets changed (from 07 to 06)

-the sectors before gets changed (from 2048 to 63)

 

Ideally, the original MBR should be preserved.

 

As for  :

 

You remember this:

http://reboot.pro/to...ated-with-dsfo/

don't you?  :dubbio:

 

I use MS GetDiskLength for physicaldrives and TotalSectors from the BS for volumes, so I "should" be fine there in all cases.



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14132 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 April 2014 - 10:46 AM

I checked the ImDisk saved image (with MBR option) : MBR does not match (no surprise as it is a generated one) the original:
-the partition type gets changed (from 07 to 06)
-the sectors before gets changed (from 2048 to 63)
 
Ideally, the original MBR should be preserved.

Yep :), I told you how it would not have worked in that case ;).
 
I see the "save with MBR" (and I believe that Olof shares this thought :unsure:) as an "afterthought" and "commodity" totally OUTSIDE the actual scope of IMDISK, implemented only because people had difficulties in creating new, simple, basic hard disk images (with just one partition/volume), the offset is "fixed" to 32256 bytes and the MBR code is "generic" (and the Disk Signature is NOT generated).
 
But I don't understand the featuritis. (in this case it is the reverse form of asking for features to a tool).
Mind you I was the one that originally asked Olof to add an "automagic" selection of "sectors before" and choosing the partition on multipartition disk image, but that is only something which is useful to quickly access the volume.
 
Imdisk mounts a volume, and does not interact with some parts of the NT storage subsystem.
The same Author wrote another tool (the Arsenal image mounter) which is specific to mount hard disk images.
 
Why should the first have the same features of the second? :dubbio:
 
I mean, usual layman approach, you have a hammer and a screwdriver (both manufactured by - say - Stanley)
Do you write them asking why you cannot drive nails into wood with the screwdriver and how they should add this feature to the screwdriver?
 

I checked the ImDisk formatted image : backup boot sector is there at the end of the image.

So this part is consistent.

Good :), I seemed to remember that in some cases when playing with images there was an issue with this (since that sector is OUTSIDE the volume), the reference to the thread was because of this, as said there, Clonedisk deals fine with the issue.

:duff:
Wonko



#5 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2278 posts
  • Location:Nantes - France
  •  
    France

Posted 09 April 2014 - 10:59 AM

 

 

Why should the first have the same features of the second?  :dubbio:

 

Totally aggree.

This is indeed very tempting to turn a tool into a swiss knife / "does it all" tool.

 

ImDisk is perfect for what it does : mount volumes.

 

May be one last remark, and only for consistency (or maybe because I am stubborn!) : since the MBR generated has a hardcoded offset of 63 (32256 bytes), may be it would be a good idea to have the same hardcoded value in the hiddensector field of the BS BPB ? :)

 

But as whole, I got my answer : steps listed in first thread are fine but I am misusing ImDisk.

 

If I want to create a drive image, I should be using drive (vs volume) mounting tools.

 

Thanks again Wonko for sorting this out  :thumbsup:



#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14132 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 April 2014 - 11:07 AM

 

If I want to create a drive image, I should be using drive (vs volume) mounting tools.

 

Thanks again Wonko for sorting this out  :thumbsup:

If you use "disk" (and not "drive") mounting tools it would even be better ;).

I know I am picky :ph34r:, but it has been years that there is this confusion, because the *whatever* gets a drive letter under windows is a volume.

disk= "whole thing", including the MBR, hidden sectors and (multiple) partition(s)=hard disk drive (or image of it)

drive=volume=partition if primary=logical volume inside extended<- this is what gets a drive letter under Windows

 

(and Imdisk's name did not help much in clarifying that what is mounted is a drive or volume :whistling: )

 

:duff:

Wonko



#7 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1358 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 09 April 2014 - 12:37 PM

It also does not help much that both physical disks and disk volumes/drives/etc are handled by "Disk Driver" level, using just device objects with different naming convention, in Windows storage driver stack. Where ImDisk is a "Disk Driver" that does not handle disks. Pretty much.
:cheers:

#8 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2278 posts
  • Location:Nantes - France
  •  
    France

Posted 09 April 2014 - 05:28 PM

About this UUID thingy, Steve6375, did you mean this thread ?

No harm done thus :)

 

Just to avoid confusion for future readers.

 

/Erwan



#9 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1358 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 09 April 2014 - 05:56 PM

About this UUID thingy, Steve6375, did you mean this thread ?
No harm done thus :)
 
Just to avoid confusion for future readers.
 
/Erwan


I assume "yes" on that question and I have now moved the posts about UUID/serial numbers to the other thread. Thanks!

#10 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2278 posts
  • Location:Nantes - France
  •  
    France

Posted 11 April 2014 - 11:54 AM

Updating this thread, the following steps worked for me using ImDisk and CloneDisk.

 

Note that this is purely a "for fun" exercice or lab exercice as there are tons of other ways/tools to perform the same task.

 

1-Create a raw disk image (here test.img=64 MB)
6hUhopf.png
 
2-Retrieve file size in sectors (here 131072)
7l8Ganb.png
 
3-Modify partition table : chs end/start=1023/254/63, sectors before=2048, total sectors=129023 (131072-2048-1)
3POjfAl.png
 
4-Write NT6 mbr
umyjsTE.png
 
5-Mount disk image (ImDisk auto detect offset=2048, size of disk=129023)
v5gMe3S.png
 
6-Format to NTFS
 
7-Change Hidden Sectors in Boot Sector
oZqEjb1.png
 
8-Boot (in qemu or virtualbox)


#11 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14132 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 April 2014 - 12:14 PM

 

 
8-Boot (in qemu or virtualbox)

 

Being picky :ph34r:, allow me (respectfully) to doubt :dubbio: that it will boot on most Qemu versions, as the CHS is wrong and the geometry will default to 255/63 (which is normally not suited for a smallish image).

See:

http://reboot.pro/to...nedisk/?p=74089

http://reboot.pro/to...inixp/?p=178705

 

:duff:

Wonko



#12 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2278 posts
  • Location:Nantes - France
  •  
    France

Posted 11 April 2014 - 12:29 PM

Correct, I am a bit lazy on the CHS side and I did not spent too much time there as the image worked on qemu-0.12.2 and Virtualbox.

 

Out of curiosity I'll test an older version and a new version.

 

I suspect that only some older version may complain about this.

 

Edit : works with qemu 0.9.0, 0.13.0, 0.14.0, 0.15.0 as well.

Could it be that latest versions of QEMU (at least since 0.9.0) now use the LBA instead of CHS ?



#13 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14132 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 April 2014 - 01:10 PM

I suspect that only some older version may complain about this.

 

Edit : works with qemu 0.9.0, 0.13.0, 0.14.0, 0.15.0 as well.

Could it be that latest versions of QEMU (at least since 0.9.0) now use the LBA instead of CHS ?

It is also well possible that the combination of "NT60" MBR and PBR code works and that the issue will re-present itself if the "NT52" or the DOS/FreeDos codes are used.

I seem to remember :unsure: that the NT60 PBR behaves "better than the older version.

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users