64 replies to this topic

[was_jaclaz]

OK I have created a new virtual disk which I have setup from within Hyper-V

• joined the virtual hard disk to an existing XP VM
• used Disk Management to create primary partition
• formatted as FAT
• copied ntldr, boot.ini and ntdetect.com from XP VM
• shutdown VM
• disconnected virtual disk (image2v)
• create new VM and link to image2v
• boot BartPE ISO in new VM so could make partition active (used Acronis to do this, can use something else if you prefer)
• boot from image2v and boot.ini loads OK. Tries to start Windows entry correctly

If you want me to investigate how this image has been created under Hyper-V would appreciate if you could direct me to some links to give me a head-start.

Well, it seems to me like you have replicated the same procedure that initially caused the flashing cursor:
http://www.boot-land...?...=9776&st=12
or not?

Simply get tiny hexer and my scripts:
http://www.boot-land...?showtopic=8734


Compare the newly created MBR with the one of the image created manually.
Compare the newly created botsector with the one of the mage created manually.

Check the MBR and bootsector of the new image (just to make sure the geometry is 255/63).(MBRview on first sector+BSview on sector at offset 32256)

Check the MBR and bootsector of the image that initially failed to boot (the one of post #13).
BSview is still UNfinished and "looks ugly" on NTFS bootsectors)

In the MBR the END Head should be 254.
In the Bootsector the Number of heads should be 255.

jaclaz

[VeeDub]

Well, it seems to me like you have replicated the same procedure that initially caused the flashing cursor

But with one key difference, partition formatted as FAT rather than NTFS (the default).

[was_jaclaz]

But with one key difference, partition formatted as FAT rather than NTFS (the default).

Yes, but the points I am trying to understand are:

• disk management normally creates the partition with the right (on the given system, real or virtual) CHS geometry
• we can recreate (at our will) the same thing manually with any given geometry
• whatever geometry the Hyper-V uses , it should be able to generate internally a "valid" image, no matter the filesystem

Now that you have a working FAT image, I would like to know which geometry it has generated (which I presume it is 255/63).
Then I would like that same image, be re-formatted as NTFS (inside Hyper_V) and see if it continues working or not (without the bootsector patch)

jaclaz

[VeeDub]

Simply get tiny hexer and my scripts

OK, done.

However the rest of the exercise requires that one knows how to "drive" Tiny Hexer and at the moment I don't have a "license". And also that the driver understands how to interpet what he is looking at (e.g MBR entries), which at the moment I don't.

Compare the newly created MBR with the one of the image created manually.
Compare the newly created bootsector with the one of the mage created manually.

Check the MBR and bootsector of the new image (just to make sure the geometry is 255/63).(MBRview on first sector+BSview on sector at offset 32256)

Check the MBR and bootsector of the image that initially failed to boot (the one of post #13).
BSview is still UNfinished and "looks ugly" on NTFS bootsectors)

In the MBR the END Head should be 254.
In the Bootsector the Number of heads should be 255.

I've managed to load the partition and the different viewers, but I'm not clear on exactly what fields I am looking for - or for instance how to get to the offset 32256 (had a go at this but clearly did something wrong as Tiny Hexer said I was trying to go out of bounds).

It might be safer, and faster if I just do a binary extract of the partition and upload for you to review. I have had a look for a newbie guide to Tiny Hexer but did not find anything particularly helpful.

If you have a link to a useful guide, that assumes no specific knowledge, then I don't mind having a go at learning how to drive Tiny Hexer and obtain the info. But if it's likely going to take another 20 posts back-and-forth then it might be easier just to send you a binary extract from the partition.

I have used a sector editor with Apple II (a long time ago) so I do understand some of the concepts - and I knew the Apple file system structure quite well. But I am not familiar with PC file system structure or how to operate Tiny Hexer.

The structure viewers are certainly a good idea, far more user-friendly way to present the information than just a raw dump.

[was_jaclaz]

It's not really difficult.
You have three ways to access your images:

• plain: File->Open->...
• mounted disk: File ->Disk -> Open Drive -> ...
• Disk image: File -> Disk -> Open disk image or large file as drive ->....

#1 needs quite a bit of memory/time, as it will load the whole file.
#2 will access the mounted image, thus it will be fastish and have all the image available, besides you can mount it two times, one loading "PhysicalDrive" (and you will have the MBR as first sector) and one loading "Drive Letter" (and you will have the bootsector as first sector)
#3 is the most complex, but the "best one", as it allows you to load any number of sectors from the unmounted image and "move" forward and back without loading too much at a time.

Use #3:
point to the image
set "First Sector" 0x00
set "Load" 0x01
you have loaded the MBR

A small bug in tinyhexer :
point to the image
set "First Sector" 0x3F
set "Load" 0x01
you should have loaded the bootsector, but you get a sector full of 00's
Close the window.
Re-do Disk image: File -> Disk -> Open disk image or large file as drive ->....
NOW you have loaded the bootsector, it seems like when you change the value in "First Sector" the change is not really taken into account until you re-access the dialog.

If you load just first sector (MBR) you can also go to:
File -> Disk -> Load Next Sector
(or press Shift+F8) 62 times to get to sector 63 (the bootsector)
In the status bar you will see that you are on sector 63/xxxxxxx and in the offset column you will be on 32256 DEC or 0X7E00 HEX (read as 63*512=32256)
Or, better
File -> Disk -> Goto Sector and enter 63.


Once you have opened the MBR, Tools ->Structure Viewer -> MBRView
Save the file as .htm (I attached one).

Try again, Tools ->Structure Viewer -> PTView
Save the file as .htm (I attached one).

Same thing goes for the bootsector, though the BSview WON'T look nice (Unfinished script ), I am attaching a file as an example, but you can use the built-in "FAT16 Boot Structure", I am attaching an example of the latter too.



jaclaz

Attached Files

•  veedub_sample.zip   6.35KB   358 downloads

[VeeDub]

• plain: File->Open->...
• mounted disk: File ->Disk -> Open Drive -> ...
• Disk image: File -> Disk -> Open disk image or large file as drive ->....

I ended up using option 2 on the drive within Hyper-V. Perhaps I could have tried option 3 on the vhd file.

(or press Shift+F8) 62 times to get to sector 63 (the bootsector)

Thanks for the examples, hopefully I've obtained the correct info.

Attached Files

•  image2v.zip   5.43KB   377 downloads

[was_jaclaz]

Well, you managed to have a 64/63 geometry.

And of course completely missed to state WHICH image the posted files refer to (it is FAT16 type 06 1,071,415,296 bytes in size)

Something that I didn't think it was possible.

Most probably the Hyper-V "Virtual BIOS" is "picky" with size of images.

With known HS geometries:
255/63
128/63
64/63
16/63
64/32
240/63 <- stoopid geometry that some laptop use (lenovo for sure, but others too)

We have CHS limit at:
255/63->1024*255*63*512=8,422,686,720<-Current geometry on "modern" BIOS and OS, say since 1998
128/63->1024*128*63*512=4,227,858,432<- Rarely used (default in WinHex if I remember right)
64/63->1024*64*63*512=2,113,929,216<-Really rarely used (cannot remember a single system/OS that used it)
16/63->1024*16*63*512=528,482,304<-Old geometry and first HD size barrier
64/32->1024*64*32*512=1,073,741,824<- this was "old" NT 3.51/4.00 default
240/63->1024*240*63*512=7,927,234,560<- only stoopid laptops AFAICR

The fields you are interested are:
in PTview:

• eHead (eHead+1=H geometry)
• eSec (eSec=S geometry)
• StartSector (StartSector=S geometry)

in MBRview:

• End Head: (End Head:+1= H geometry)
• End Sector: (End Sector:= H geometry)
• Start LBA:(Start LBA:= H geometry)

In BSview:

• Number of Heads: (Number of Heads:= H geometry)
• Sectors per Head: (Sectors per Head:= S geometry)

jaclaz

[VeeDub]

Well, you managed to have a 64/63 geometry.

And of course completely missed to state WHICH image the posted files refer to (it is FAT16 type 06 1,071,415,296 bytes in size)

The details are in post 50 (in my defence I thought the archive name was self-explanatory, it was to me at least. For the record, the partition was formatted as FAT

Most probably the Hyper-V "Virtual BIOS" is "picky" with size of images.

I wonder if this is due to how the partition is being created. Process used to create the partition:

• create a virtual hard disk using the Hyper-V wizard (1GB)
• join the virtual hard-disk to a VM that has XP as the guest OS
• Start XP guest and use disk management to partition and format the disk

64/63->1024*64*63*512=2,113,929,216<-Really rarely used (cannot remember a single system/OS that used it)

Perhaps if I create a 2GB or 4GB vhd via the Hyper-V wizard then perhaps the CHS geometry may be more "standard", and this might allow grub4dos to boot successfully.

[was_jaclaz]

Perhaps if I create a 2GB or 4GB vhd via the Hyper-V wizard then perhaps the CHS geometry may be more "standard", and this might allow grub4dos to boot successfully.

Yep , is a test that needs to be made, though I don't think that the grub4dos problem is geometry related,

jaclaz

[VeeDub]

Results from tests with a 4GB partition.

Procedure:

- create 4GB vhd via Hyper-V Wizard
- assign 4GB vhd to XP guest VM
- start XP guest VM, partition disk as primary
- format partition (1 disk formatted as FAT, 1 disk formatted as NTFS)
- copy across boot.ini, ntldr, ntdetect.com
- shutdown XP VM
- disconnect 4GB vhd from XP VM and join to new VM
- start BartPE in new VM, use Acronis Disk Director to set partition Active. When performing operation on FAT partition, Acronis reported read errors on sectors
- restart VM and boot from 4GB partition
- both partitions started correctly and loaded boot.ini, both partitions attempted to load Windows which was not present

Info from Tiny Hexer

FAT 4GB

MBR View
End Head: 254
End Sector: 63
Start LBA: 63

PT View
eHead: 254
eSec: 63
StartSector: 63

BS View
Number of Heads: 255
Sectors per Head: 63


NTFS 4GB

MBR View
End Head: 254
End Sector: 63
Start LBA: 63

PT View
eHead: 254
eSec: 63
StartSector: 63

BS View
Number of Heads: 255
Sectors per Head: 63

[was_jaclaz]

Good.
So image size determines geometry in Hyper-V.

What happens with those image and grub4dos?

What is the End Cylinder?
521?
522?

jaclaz

[VeeDub]

What happens with those image and grub4dos?

Same as before, after chainloader /ntldr, a flashing cursor.

What is the End Cylinder?

521 for both.

[was_jaclaz]

Same as before, after chainloader /ntldr, a flashing cursor.

This should definitely mean an incompatibility of some kind between grub4dos and Hyper-V.

I don't think there is a way out, short of finding it and change grub4dos.

Have you tried a few semi-random old releases, like:
http://nufans.net/gr...-2008-05-14.zip
http://nufans.net/gr...r_dos-0.4.2.zip

Do they behave the same?

Can you try with a grldr floppy or with a grldr as no-emulation bootsector from CD?
(just to see if it is a "general" incompatibility or if it is limited to HD device)



jaclaz

[VeeDub]

Have you tried a few semi-random old releases, like:
http://nufans.net/gr...-2008-05-14.zip
http://nufans.net/gr...r_dos-0.4.2.zip

Do they behave the same?

Yes

Can you try with a grldr as no-emulation bootsector from CD?

Same behaviour

This should definitely mean an incompatibility of some kind between grub4dos and Hyper-V.

I don't think there is a way out, short of finding it and change grub4dos.

I think you're right.

It would have been better if I could have used grub4dos with Hyper-V, but there are ways to make VM's start without grub, even if it is a little more convoluted.

Thanks for all of your help, I have learnt quite a bit.

VW

[was_jaclaz]

Thanks for all of your help, I have learnt quite a bit.

VW

You are very welcome, I have learned quite a bit (about this Hyper-V thingy) too in the process.



jaclaz