64 replies to this topic

[was_jaclaz]

Fortunately QEMU is consistent with Hyper-V, although slightly more informative. VM fails to boot.

A disk read error occurred. Press Ctl+Alt+Del to restart

Well, we are now maybe a step ahead (or two behind ), that message is NOT in the MBR (NT/2K/2003):

Invalid partition table
Error loading operating system
Missing operating system

Not in the MBR (Vista/2008/7):

Invalid partition table
Error loading operating system
Missing operating system

Not in the bootsector (NT/2K/2003):

Invalid system disk
Disk I/O error
Replace the disk, and then press any key

Not in the bootsector (Vista/2008/7):

BOOTMGR is missing
Disk error
Press any key to restart

Not in Qemu BIOS when you map to it a "fake" image:

Booting from Hard Disk....
Boot failed: not a bootable disk

FATAL: No bootable device

or when you map to it a non-bootable image:

Booting from Hard Disk....
FATAL: No bootable device

So WHERE does this message come from?

A disk read error occurred. Press Ctl+Alt+Del to restart

jaclaz

[VeeDub]

So WHERE does this message come from?

Well it has to be user error on my part in creating the image. The command that I used was

hddimage.cmd LiveXP_Vol.img 1G /R

The image was created on an XP-SP2 system, running on the physical box.

The backup from the image is attached.

Attached Files

•  extract.zip   23.13KB   403 downloads

[was_jaclaz]

OK.

The good news are that the bootsector holds these messages:

NTLDR is missing
NTLDR is compressed
Press Ctrl+Alt+Del to restart

So we now know where at least part of the message comes from.

The bad news is that I am failing to understand what is happening.

I am trying to reproduce but I am not sure about what the problem is.

However for the moment let's go one step "sideways"

Go back to the "original" MBRBATCH/MKIMG.


Start on a fresh reboot, VDK.EXE from time to time gives problems if loaded and unloaded a number of times.

MKIMG
myimg.img
1G
16/63
07
/fsz
[ENTER]


In the Explorer windows that will open copy to the drive NTLDR NTDETECT.COM and BOOT.INI.
Close the Explorer window.
press any key to close the batch.

Try mounting the image in Qemu, it should work (or at least it works for me).


If it boots, try converting it in .vhd.

See if it works.


I'll check what can be the reason for the "wrong" behaviour of the 255/63 one....



jaclaz

[VeeDub]

@jaclaz

I did all of the above, including copying in my LiveXP image and renaming i386 to minint

In QEMU the image booted OK, started grub4dos, which successfully started LiveXP.
I edited boot.ini to remove the "dummy" entry and the QEMU VM continued work OK.

Converted the raw img to vhd and mounted in the Hyper-V VM. On start-up

A disk read error occurred. 

Press Ctl+Alt+Del to restart

[was_jaclaz]

Found the culprit.

I had overlooked the fact that you used NTFS.

WRONG MS bootsector code for NTFS and FAT32:
http://www.911cd.net...o...1702&st=129

For the experiment, try creating the image with 255/63 geometry but use 06 as partition type.

And then try again with 255/63 geometry but use 0E as partition type.

If the above works (BOTH should) you need to patch the bootsector in the NTFS image.

A small app is available:
http://www.boot-land...?...=8528&st=21

Use this (example):

dsfo veedub.img 32256 512 temp.bin

killchs temp.bin

dsfi veedub.img 32256 512 temp.bin

jaclaz

[VeeDub]

If the above works (BOTH should)

Both start in Hyper-V, but grub4dos unable to start LiveXP

you need to patch the bootsector in the NTFS image

That also works as you expected, which is progress, however grub4dos still won't start LiveXP in Hyper-V

Information reported when NTFS partition is used

Notice: number of heads for drive 80 tuned down from 16 to 255

(hd0,0)

Filesystem type is ntfs, partition type 0x7



Will boot NTLDR from drive=0x80, partition=0x0(hidden sectors=0x3f)

Then a flashing cursor

In the short-term is it possible to start LiveXP via boot.ini? I am keen to find out whether I can install Integration Services into LiveXP

Thanks for your help so far!
VW

[was_jaclaz]

Both start in Hyper-V, but grub4dos unable to start LiveXP

Well, I want to know what happens with normal NTLDR first NOT with grub4dos.

I am confused right now , we must find a "common ground" to exchange info, otherwise it will become really difficult to help you further.

To recap, you should have by now 8 images made with MBRBATCH/MKIMG:

• with geometry 255/63 partition FAT16 partition type 06
• with geometry 255/63 partition FAT16 partition type 0E <-check the partition type with tinyhexer or other hex-editor, if needed change manually
• with geometry 16/63 partition FAT16 partition type 06
• with geometry 16/63 partition FAT16 partition type 0E <-check the partition type with tinyhexer or other hex-editor, if needed change manually
• with geometry 16/63 partition NTFS partition type 07
• with geometry 255/63 partition NTFS partition type 07
• with geometry 16/63 partition NTFS partition type 07 <- "fixed" bootsector with killchs
• with geometry 255/63 partition NTFS partition type 07 <- "fixed" bootsector with killchs

ALL OF THEM with NTLDR +BOOT.INI with two entries + NTDETECT.COM.

In Qemu, on my side:
#1 works
#2 works
#3 works
#4 works
#5 works
#6 DOES NOT work (and gives the error message)
#7 works
#8 works
(works means having the choices in BOOT.INI displayed)

Can I have from you the confirmation of the above and a similar report of what happens in Hyper-V?

Then (Further step -NO leaps or jumps!) can you add to each image ROOT: grldr, SETUPLDR.BIN and menu.lst (and NOTHING else)

And post another report with the SAME 8 images and grub4dos chainloaded through BOOT.INI with an entry like:

C.\grldr="grub4dos"

And a menu.lst with these contents (and nothing else):

timeout 30





title NTLDR

chainloader /ntldr



title SETUPLDR.BIN

chainloader /setupldr.bin

Working in this case means that first entry should bring you back to the BOOT.INI choices, second one should bring you to an error "INF file txtsetup.sif is corrupt or missing, status 14".



jaclaz

[VeeDub]

Image 1 & 2 boot in HyperV and show boot.ini menu.
Grub4dos loads OK.
Both menu options in grub4dos behave in the same way (i.e. they do not work)

Will boot NTLDR from drive=0x80, partition=0x0(hidden sectors=0x3f)

Menu options behave correctly in QEMU (i.e. as you describe)

Image 3 & 4 show flashing cursor at startup in Hyper-V (i.e. no boot.ini menu)
Menu options behave correctly in QEMU.

Image 7 boots in Hyper-V and show boot.ini menu
Grub4dos loads OK
Menu options in grub4dos do not work.

Notice: number of heads for drive 80 tuned from 16 to 255

Will boot NTLDR from drive=0x80, partition=0x0(hidden sectors=0x3f)

Menu options behave correctly in QEMU

Image 8 boots in Hyper-V and show boot.ini menu
Grub4dos loads OK
Menu options in grub4dos do not work.

Will boot NTLDR from drive=0x80, partition=0x0(hidden sectors=0x3f)

Menu options behave correctly in QEMU

I see that there is a version 3.2 of vdk, do you know whether that version is compatible with mkimg.cmd and whether or not it unmounts images without requiring a restart each time?

[was_jaclaz]

No, there is NO need to re-boot for VDK, it was just a one-time suggestion to make sure that a problem with VDK was not the cause, sorry if I misled you.
Normally you can start VDK, install and uninstall it all the times you want.
Sometimes, for reasons that have not been found it hangs, I suspect it is when one uses different instances of VDK.SYS in different paths AND that it is somehow connected with VSS (as on 2K I have NEVER experienced this problem):
http://www.boot-land...?showtopic=9195
That once-time recommendation translates to:
"now that you are sure VDK works, use it as you wish, IF it hangs, reboot."

We have found out that Hyper-V is more picky then Qemu, if I read correctly your report (filling the gaps) we are 5/8 versus 7/8 for Qemu.

So it seems there is some kind of incompatibility betrween grub4dos (BTW which exact version you are using) and Hyper-V.

Try going "backwards":
http://nufans.net/grub4dos/
0.4.4-2009-10-16 <- this is the one you should be using right now
0.4.4-2009-05-23 <- older to try
http://nufans.net/grub4dos/history/
0.4.3-2008-05-14 <- older to try
0.4.2 <- eldest to try


What happens if you drop to command line (press "c" ) and issue an explicit boot command?
I.e.:

chainloader /setupldr.bin

[ENTER]

boot

[ENTER]
(just to make sure the boot is actually issued)

For the moment, let's remain in the images #1 & #2 (FAT)

Mount either image with VDK.

Use MakeBS:
http://www.boot-land...?showtopic=2362

To create a bootsector that loads SETUPLDR.BIN, say "myboot.bs".
Add this file inside the image.
Add to boot.ini an entry:
C:\mybootbs="Load SETUPLDR.BIN"

You should be able to get to the error "INF file txtsetup.sif is corrupt or missing, status 14". (please read as "you should be able to boot LiveXp from BOOT.INI").

jaclaz

[VeeDub]

No, there is NO need to re-boot for VDK

Yes, there is.

Normally you can start VDK, install and uninstall it all the times you want.

I wish that were the case

Sometimes, for reasons that have not been found it hangs

That has been my experience, I can use it to mount one image at a time. Then I have to restart before I can remove the driver. I tried editing mking.cmd to remove the check, but the driver won't mount two images in one session. When you're working with multiple images it starts to grate after a while.

We have found out that Hyper-V is more picky then Qemu, if I read correctly your report (filling the gaps) we are 5/8 versus 7/8 for Qemu.

Actually 4/8 with Hyper-V. Images 3, 4, 5 & 6 don't even get to boot.ini

So it seems there is some kind of incompatibility betrween grub4dos (BTW which exact version you are using) and Hyper-V

Agreed.
v0.4.3

Try going "backwards"

Actually it looks like I can try going "forwards"

What happens if you drop to command line (press "c" ) and issue an explicit boot command?

chainloader command executes OK, says it is going to boot NTLDR. Type

boot

and get a flashing cursor

For the moment, let's remain in the images #1 & #2 (FAT)

I am happy to do that, I don't have a strong preference for NTFS or FAT32. I defaulted to NTFS because when I started I was formatting the partitions via Explorer and that's what it defaulted to. Given the behaviour of vdk, less images is preferable.

I will work through the rest of the steps with interest.

I am learning a few things so it is not wasted time.

I had expected that the problems would start when I tried to install the Hyper-V drivers, perhaps that will just work once we manage to start LiveXP in Hyper-V.

Cheers
VW

[was_jaclaz]

Actually 4/8 with Hyper-V. Images 3, 4, 5 & 6 don't even get to boot.ini

This is the "queer" part, EITHER #5 OR #6 should theoretically boot in Hyper-V.

v0.4.3


Actually it looks like I can try going "forwards"

Yep.
You missed this (sticky in grub4dos forum):
http://www.boot-land...hp?showtopic=14
http://www.boot-land...?...pic=14&st=1

As it already happened to mismatch info posted with actual version of GRUB4DOS, here is the
....
Unless otherwise stated all comments, hints, howto etc., will always be related to the NEWISH experimental version.

Particularly 0.4.3 "final" hasn't been one of the versions "blessed by fortune".

jaclaz

[VeeDub]

0.4.4-2009-10-16 <- this is the one you should be using right now

If I understand correctly, to be using this version, all I need to do is update grldr in the image. If that is so, then it appears that for some reason grub & Hyper-V do not play nicely. Having updated image 1 & 2 and then converted to vhd there is no change in behaviour.

grub states that it is going to boot NTLDR, but nothing happens.

Will try makeBS

[was_jaclaz]

Will try makeBS

Good.

Please note that on a NTFS image you have a max 5 characters for the name of the loader, if you try with them, rename SETUPLDR.BIN as PELDR.

jaclaz

[VeeDub]

Unfortunately I am doing something wrong with makebs because it's not working in QEMU let alone Hyper-V.

Trouble is I don't know what I am doing wrong

I am using beta 010 of makebs.
I have tried both image 1 & 2, and get a flashing cursor after selecting the myboot.bs entry in boot.ini

I have to admit I find the "help" for makebs a little hard to follow. My understanding is that I need to create a destination file on the partition before I execute makebs.cmd

For example, when say image1 is mounted, it is assigned to G:
So in the root of G: I create myboot.bs (a renamed txt document)
Then

makebs g:\myboot.bs

Output from makebs

BackupBS.ori existing and valid...

...

...

...

Current bootsector appears to be FAT16, "NTLDR" string found at offset 417.

...

...

New bootsector g:\MYBOOT.bs created succesfully

....

Press any key to continue . . .

Boot.ini

[boot loader]

timeout=30

default=C:\myboot.bs

[operating systems]

C:\myboot.bs="LiveXP"

multi(0)disk(0)rdisk(0)partition(1)\minint="LiveXP - dummy"

I close the image. When I start in QEMU, the boot.ini menu appears. Select LiveXP and get a flashing cursor.

[was_jaclaz]

Well, you seemingly made a bootsector invoking file "Myboot".

Sorry if it's not clear, but I cannot find better words:

::<Command line usage:
::<MakeBS Driveletter:\NewLoader [/W] [/A] [BootIniEntryText]
::<Where:
::<Driveletter can be any letter assigned to a partition from C: to Z:
::<
::<Newloader is the filename of the loader, it must already exist on root
::<of the given Drive
::<
::<The output file will have the first part of the 8(+3) DOS given
::<name for NewLoader with the .BS extension
::<
::<If you add the /W switch, the created bootsector will be written to
::<the given drive, the use of the /W switch prevents the use of the /A
::<one, as it makes no sense.
::<
::<If you add the /A switch, the program will attempt adding
::<an entry to the BOOT.INI file on the given partition (if any)
::<
::<If you add the [BootIniEntryText] as parameter, the program will use the
::<supplied string instead of the default "Load Newloader bootsector"
::<
::<The supplied string MUST be enclosed in double quotes!
::<
::<A copy of Original Bootsector is made on root of Drive as "BackupBS.ori"
::<
::<Examples:
::<MakeBS C:\SETUPLDR.BIN
::<Will create a file C:\SETUPLDR.BS and a file C:\BackupBS.ori
::<
::<MakeBS C:\MYLDR /A
::<Will create a file C:\MYLDR.BS,a file C:\BackupBS.ori and add an entry in
::<BOOT.INI as this: C:\MYLDR.BS="Load MYLDR bootsector"

If you want to create a bootsector invoking SETUPLDR.BIN you run:

makebs g:\SETUPLDR.BIN

If you want to create a bootsector invoking PELDR you run:

makebs g:\PELDR

The result will be respectively a files SETUPLDR.bs and a file PELDR.bs.

With all due respect , nowhere is written "create a new arbitrary file on the root of the device and use it as the target of the batch"



jaclaz

[VeeDub]

I have restored ntldr from my original copy
setupldr.bin is in the root
So I do makebs g:\setupldr.bin

Which creates g:\SETUPLDR.bs

boot.ini

[boot loader]

timeout=30

default=C:\SETUPLDR.bs

[operating systems]

C:\SETUPLDR.bs="LiveXP"

multi(0)disk(0)rdisk(0)partition(1)\minint="LiveXP - dummy"

Close image and test in QEMU.

Same behaviour as before.

That's it for tonight.

[was_jaclaz]

Hmm

Really cannot say what is not working.

If you open BackupBS.ori and SETUPLDR.bs in a hex editor and compare them they should be identical exception made for the values at offset 0x01A1 (the name of the loader).

jaclaz

[VeeDub]

I have made some progress, I have image 2 starting in Hyper-V via boot.ini

I re-did the makebs.cmd but made sure that when referring to the boot loader SETUPLDR.BIN that I matched the case. Initially I just used lowercase in the makebs.cmd.

This worked for image 2, but re-tried the same on image 1 and no change (?)

At least image 2 is working. This does support your approach of using multiple images which I must admit earlier on I was thought was just unnecessary extra work.

[was_jaclaz]

Good.

Now it's time to try creating the "same" image #2, let's call it image #2v entirely inside Hyper-V and compare it with the #2 working, there must be something related to geopmetry, as 0E is the LBA mapped (and it's working) whilst #1 should be identical, but being 06 is CHS mapped.

Normally, in a properly made image with the right geometry for the (virtual) BIOS used and with "balanced" CHS and LBA, you can change 06 with 0E all the times you want, actually that single byte is the only difference.

The report about case is "strange", I seem to remember I put a "capitalize" routine for case in the batch, maybe it's not working. I'll check.


jaclaz

P.S.: I do look sometimes like a heartless sadist bastard inducing people to do completely unneeded and overly complex things just for the fun of it, but there are REASONS (usually ) compare with point #f of "common sense advice":
http://www.boot-land...?showtopic=9101

[VeeDub]

Now it's time to try creating the "same" image #2, let's call it image #2v entirely inside Hyper-V and compare it with the #2 working, there must be something related to geopmetry, as 0E is the LBA mapped (and it's working) whilst #1 should be identical, but being 06 is CHS mapped.

I want to make sure that I understand you correctly here. So in an XP VM running under Hyper-V, I re-create image #2 which we shall refer to as image #2v. Having done this I then copy image #2v to the Hyper-V host and then use image #2v in a new VM to determine whether it behaves the same way as image #2.

Assuming that image #2v does behave the same way as image #2, at that point will we use a hex-editor to convert #2v to #1v and see whether image #1v works?

[was_jaclaz]

I want to make sure that I understand you correctly here. So in an XP VM running under Hyper-V, I re-create image #2 which we shall refer to as image #2v. Having done this I then copy image #2v to the Hyper-V host and then use image #2v in a new VM to determine whether it behaves the same way as image #2.

Assuming that image #2v does behave the same way as image #2, at that point will we use a hex-editor to convert #2v to #1v and see whether image #1v works?

Yes.

The point is that image #1 and #2 are exactly (or should be) exactly the same image, only with FAT 16 partition type set respectively to 06 (CHS mapped) and 0E (LBA mapped).

You could also try making a copy of the #2 and change only the 0E to 06 (thus creating image #1bis) and see if it behaves like #1 or like original #2.

Theoretically a BIOS (real or virtual) should:

• use only CHS if it finds a 06
• use only LBA if it finds a 0E

The LBA mapping is "sequential" thus it completely ignores geometry, BUT there is some data in the bootsector that is anyway geometry related.
This should NOT be a problem with the FAT16 bootsector (while as seen it is one on FAT32 and NTFS).

Once you have made image #2v entirely with tools provided together with Hyper-V you check whether it behaves like our "hand-made" #2 or not, and, in both cases, you compare the MBR's and the bootsectors of images #2v and #2.

Then again you try making a copy of #2v (let's call it #1v) and change the 0E in 06 or viceversa (and of course if viceversa it means that #2v is actuall #1v and viceversa).

I do know it does sound confusing , but the ultimate goal is finding out the answer to these questions:

• How is an image created under Hyper-V?
• Will it be partitioned respecting WHICH CHS geometry?
• Will it have a 06 or a 0E type of partition?

And all the above to try and understand why your first attempt with NTFS resulted in a blinking cursor.....:
http://www.boot-land...?...=9776&st=12

Or maybe it was the use of Acronis.

jaclaz

[VeeDub]

When you say

Once you have made image #2v entirely with tools provided together with Hyper-V

Do you mean I re-create image #2 in the Hyper-V VM using mkimg.cmd, vdk, rawtovhd etc.?
Or do you mean I create a FAT partition using Disk Management in the Hyper-V VM and just go as far as I can using standard Windows tools? (i.e. basically to boot.ini calling ntldr)

And all the above to try and understand why your first attempt with NTFS resulted in a blinking cursor.....
Or maybe it was the use of Acronis.

Negative on Acronis. I initially create NTFS partition via Disk Management. I switched to Acronis when the NTFS partition failed via Disk Management. As it turned out Acronis made no difference.

In any event, I thought that you identified the reason that the NTFS partition failed initially in post 30

[was_jaclaz]

Do you mean I re-create image #2 in the Hyper-V VM using mkimg.cmd, vdk, rawtovhd etc.?
Or do you mean I create a FAT partition using Disk Management in the Hyper-V VM and just go as far as I can using standard Windows tools? (i.e. basically to boot.ini calling ntldr)

The second you said.

Negative on Acronis. I initially create NTFS partition via Disk Management. I switched to Acronis when the NTFS partition failed via Disk Management. As it turned out Acronis made no difference.

Well, with all due respect for the Acronis apps I do not trust them "fully", in the sense that these kind of "automagical" apps tend to do things that they "think better" instead of what you asked them to do (or wanted to get as result).
(and yes this includes also windows Disk Management and Format)
There is NO apparent reason (or at least I cannot find one ) why Windows Format changes the Partition ID :
http://www.boot-land...?...=3191&st=26
In my personal opinion, if the good guys at MS would have been more "friendly" or "openminded" they would have

• added a switch like /force with parameters 06 or 0E for FAT16 and with parameters 0B and 0C for FAT32
  and/or
• added a warning message like:
  

  For reasons that you are too damn stoopid to understand we decided that the partition type currently in your MBR needs to be changed, and we'll do so.

(or a more polite version to the same effect )
I personally believe that a technical expert that names the Hyper-V iso:

GRMHVxFRE1_DVD.iso

or the Windows 2003 trial iso:

x09-22207.iso

managing to create something that noone in his right mind would associate with the corresponding product and anyway breaking (if it still exists) the DOS 8.3 naming convention, is capable of any crime against logic and rational thinking.
BTW even the paths on the Windows 7 DVD must have been created by a fugitive from the local asylum, example:

\sources\boot.wim\2\Windows\winsxs\x86_microsoft-windows-wimgapi_31bf3856ad364e35_6.1.7600.16385_none_88d1f88d76321f27\

In any event, I thought that you identified the reason that the NTFS partition failed initially in post 30

Yes and No.
I identified the reason, but provided a "generic" solution.
If you re-format the partition, you will have to re-apply the patch, it is possible that some tools will report the bootsector as "corrupted" or "wrong".

I mean "hacking" the bootsector for FAT32 or NTFS is a "workaround", you are basically telling the bootsector: IGNORE CHS!

But the bootsector has been working nicely, as-is, with "proper" CHS geometry supplied, for the last 10 years at least, so that solution is actually a (working ) "workaround", I am interested in understanding which are the correct CHS values in the MBR and HS in the bootsectors that allow the "untouched" bootsector to work, for two reasons:

• learning something new about this Hyper-V thingy and how it manages disk images
• keeping things as "compatible" as possible

jaclaz

[was_jaclaz]

The report about case is "strange", I seem to remember I put a "capitalize" routine for case in the batch, maybe it's not working. I'll check.

Checked, it works for me.

I.e. having EITHER SETUPLDR.BIN or setupldr.bin or SeTuPlDr.BiN in root and running makebs <driveletter>:\setupldr.bin or any variation of it INVARIABLY produces a bootsector with SETUPLDRBIN on FAT16.

Something else is the cause of your report.

jaclaz

[VeeDub]

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.