119 replies to this topic

[Vortex]

Hi,

First of all, many thanks to the authors of Firadisk and Winvblock. I am trying to install Server 2003 into an image file like the following :

title Server 2003 installation - Phase I



map /Srv03.img (hd0)

map --mem /firadisk.ima (fd0)

map --mem /2003.iso (0xff)

map --hook



chainloader (0xff)/I386/SETUPLDR.BIN

I get the infamous 7B error during the text mode phase of the installation. I remember having the same problem with Winvblock. Is there another method to install Server 2003 using one \ both of the two mentioned drivers?

Edited by Vortex, 06 January 2011 - 11:12 AM.

[Wonko the Sane]

I get the infamous 7B error during the text mode phase of the installation. I remember having the same problem with Winvblock. Is there another method to install Server 2003 using one \ both of the two mentioned drivers?

There are/were some problems in some setups with (fd0) and (fd1).

Can you try the latest beta7 of WinsetupfromUSB 1.0 and report?:
http://www.msfn.org/...omusb-with-gui/

Or maybe cdob's from_iso_in_ram?
http://www.msfn.org/...aded-iso-image/

It is also possible that you are using a version non-2003 compatible, example:
http://reboot.pro/8804/page__st__42
It seems like the issue has not (yet) been solved:
http://reboot.pro/8804/page__st__348

check the thread to see if you can find more definite info:
http://reboot.pro/8804/


Wonko

[Vortex]

Hi Wonko,

Thanks for the links. I used the latest versions of Firadisk and Winvblock. Even injecting the drivers with the necessary registry entries to an offline image didn't solve the problem. Everytime, the 2003 installation restarts itself when the Windows logo appears during boot. Disabling the system restart displays the error message 6B.

[Wonko the Sane]

Disabling the system restart displays the error message 6B.

I get the infamous 7B error during the text mode phase of the installation.

6B or 7B ?

You have to make up your mind.

Once you have done so, the only thing you can do is wait for Karyonix and/or Sha0 to check (and hopefully solve) the issue.


Wonko

[Vortex]

Hi Wonko,

Driver injection was another method I tried and this one displayed 6B. The classical installation procedure displayed 7B.

True, need to wait for the authors to solve the issues.

[agni]

Firadisk requires you to append an entry in the boot.ini

example
/firadisk=disk,vmem=X:\win.img,size=2147483648


http://reboot.pro/88...709#entry101709

and

v0.0.1.24
Now, it can search for disk image file in backing drive without knowing drive letter.
Use boot.ini option /firadisk=disk,vmem=find:\filename (instead of x:\filename)

http://reboot.pro/88...post__p__102765

Also check this
http://reboot.pro/88...349#entry102349

[Sha0]

I'm glad to read that someone is trying such an interesting scenario out: A RAM floppy, a RAM CD of the Windows installation, and a sector-mapped disk to install Windows to.

I would additionally attempt to hot-swap the sector-mapped disk to a file-backed disk by sending WinVBlock some info from your MENU.LST:

title Server 2003 installation - Phase I

  map /Srv03.img (hd0)

  map --mem /firadisk.ima (fd0)

  map --mem /2003.iso (0xff)

  #Set rd to 2048 bytes

  map --rd-size=2048

  #Copy rd to a new RAM disk with number 0x55

  map --mem (rd)+4 (0x55)

  map --hook

  #Pass some info about our image file and its drive number to WinVBlock

  write (0x55) #!GRUB4DOS\x00v=1\x00Srv03.img\x00\x80\x00

  chainloader (0xff)/I386/SETUPLDR.BIN

But to be honest, I have to reverse some code that demands a Microsoft .VHD footer on all image files (even .ISOs). It should be simple, but I need to do it. It'll be done very soon.

[maanu]

hi Shao ,

can you please link me to the latest " development " version of your winvblock driver ?


also , i could not understand the following code ,


map --mem (rd)+4 (0x55)
map --hook
#Pass some info about our image file and its drive number to WinVBlock
write (0x55) #!GRUB4DOS\x00v=1\x00Srv03.img\x00\x80\x00
chainloader (0xff)/I386/SETUPLDR.BIN

i remember i have seen (0x55 ) somewhere before , but now cant recall what was it for ,

also , why we need to " deliver " info to winvblock and what ?

related to srv03.img ???

@ original topic ,

so technically what are the benefits are we getting out of this type of install ?

i mean , if i understand correctly we already have a way of " speedy windows NT5 install " by copying iso to ram . so why now this type ??

can anyone please provide points here for my dull brain ?

[Sha0]

...can you please link me to the latest " development " version of your winvblock driver ?

Please see this post.

also , i could not understand the following code...
...i remember i have seen (0x55 ) somewhere before , but now cant recall what was it for...

Please see this post.

also , why we need to " deliver " info to winvblock and what ?

related to srv03.img ???

GRUB4DOS doesn't store any filenames. For its sector-mapped disk feature, it simply maps a virtual disk to a range of sectors on another disk. WinVBlock can find such sector-mapped disks. If you were booted from such a disk and defragmented the filesystem on the backing disk where that sector range was, then you could suddenly find your boot disk "swept out from underneath you." Using a filename and locking a particular file is safer. Since G4D doesn't remember any filesnames, that's what the additional MENU.LST code is for. WinVBlock will try to "hot-swap" from the sector-mapped disk to the file as a file-backed disk, which is safer than continuing to use the sector-mapped disk. So I recommend passing the filename.

@ original topic ,

so technically what are the benefits are we getting out of this type of install ?

I don't know about benefits, but it's interesting! Essentially you have an .ISO and your HDD image file, but everything in the filesystem on the HDD is left clean; only the image file is touched.

i mean , if i understand correctly we already have a way of " speedy windows NT5 install " by copying iso to ram . so why now this type ??

can anyone please provide points here for my dull brain ?

I don't know.

[maanu]

so nice of you to respond dear Shao ,

can you plz confirm if you add changelog along with the alpha builds ? so that user can understand what changes are being made ?

i could not see it in zip file thats why asking ,

also , have you yet checked out the bug where direct maping img file using file-disk do BSOD or freeze at windows loading screen WHEN img is on removeable disk ? in order to use wimb's tool and make universal xp img and ability to direct boot it on low ram systems so that the changes are made dynamically .

i will check above in a day or two from usb-hdd to double check ...


have nice time .

[Sha0]

...have nice time...

I'd be happy to respond to your questions in their own thread.

[maanu]

ok no problem. i will make one if got any issue in above regard./...

[Vortex]

Hi Sha0,

I got the latest development version of Winvblock and tried again to install Server 2003 into the image file but no any luck. The installation from the .iso file begins but it displays a BSOD with the error 7B after the message of Windows 2003 setup : Setup is starting windows I modified the menu.lst file according to your example above. Another trial to do an unattended install ended with the same BSOD displaying the 7B error.

[Sha0]

...I got the latest development version of Winvblock and tried again to install Server 2003 into the image file but no any luck...the same BSOD displaying the 7B error.

It just occurred to me to ask how you know that your 2003.iso is being mapped as an optical disc drive. Please try the GRUB4DOS command-line and enter each one of the commands manually, inspecting the output of each. If the .ISO is not being mapped as an optical disc drive, that would explain it! You could try mapping it to drive (hd32) instead of (0xFF).

--- EDIT ---

I just tried in QEmu and could not reproduce the problem using the same, latest, development version that you tried. The test looked like this:

qemu -fda wvf6.vfd -hda 1g.hdd -m 900 -serial pipe:com_2

Where wvf6.fda was a floppy I just built with wvblk32.sys, txtsetup.oem, winvblk.inf. The -serial option was so that I could attempt to connect WinDbg if it crashed. The HDD image had only Windows 98 DOS, GRUB.EXE and the Windows Server 2003 .ISO on it. So it booted the DOS and I ran GRUB.EXE. From there, I did:

map --mem /wsrv2003.iso (0xff)

map --hook

root (0xff)

chainloader /I386/SETUPLDR.BIN

boot

So there are some slight differences in comparison to your original post, including the fact that I used a "real F6 floppy" instead of mapping it as a RAM disk. I'll try that next.

--- ANOTHER EDIT ---

Very interesting! I was able to reproduce the bug when I used G4D to map the F6 floppy image as a RAM disk. I should be able to fix this bug easily. For now, please move your .ISO-mapping line first before the other mappings. Then please report success.

[Vortex]

Hi Sha0,

I tried the configuration below but I got again the blue screen displaying 7B :

title 2003 setup - Phase I



map --mem /W2K3STD.ISO (hd32)



map /Srv2003.img (hd0)



map --mem /winvblock.ima (fd0)



map --hook



root (hd32)



chainloader (hd32)/I386/SETUPLDR.BIN

My other attemp was to do an unattended install. Listing of \I386\$OEM$\Textmode :

txtsetup.oem
winvblk.exe
WinVBlk.INF
WVBlk32.sys

The I386 folder is placed on the root of my C drive. Mounting the .img file with imdisk and starting the setup with :

Srv2003.img -> H:

winnt32.exe /syspart:H /tempdrive:H /makelocalsource /unattend:unattend.txt

Under the OEMBootFiles section of unattend.txt, I specify the four files above. ( Probably, there is no need for winvblk.exe ) The installer creates the temporary directories. Moving to the second phase of the installation displays BSOD with 7B :

title Continue 2003 installation



map /Srv2003.img (hd0)



map --hook



root (hd0,0)

chainloader /ntldr

The text mode phase starts normally but like in the .iso mapping methode above it ends with a BSOD & 7B

[Wonko the Sane]

Is there any difference by:

• direct mapping of the F6 floppy i.e. map /winvblock.ima (fd0)
• using memdisk for the floppy loading? i.e. kernel /memdisk and initrd /winvblock.ima

Which EXACT version of grub4dos was tested?


Wonko

[Sha0]

Hi Sha0,

I tried the configuration below but I got again the blue screen displaying 7B...

Please try the latest development version (just now published).

Now then, the tricky part about why the installation is failing in your latter method (pre-installing to the image file) is: There's not really a good way to know what backing disk to use for a G4D sector-mapped disk. I remember now that when this came up in discussion before, WinVBlock wound up demanding that image files (including .ISOs) have a .VHD footer appended to them. Otherwise, there'd be no magical way to know if we found the right backing disk or not.

For example, suppose you have two HDDs, both 150 GB. Now suppose you have a 4 GB HDD image file on one of those disks. Suppose you wish to attach it with G4D and WinVBlock. When WinVBlock goes looking for the backing disk, it has your two internal HDDs to choose from. Both of them are larger than the image file, so the image file could be on either of them. How then can we know which backing disk is the right one to use? There is no information passed from G4D about which one to use except for the BIOS drive number. But Windows doesn't use BIOS drive numbers at all!

So if you append a .VHD footer to your image (and populate it with the correct details), the current development version of WinVBlock should work for you. Otherwise, let's talk (again) about how we can choose the right backing disk for a G4D sector-mapped disk.

Thanks for your report. I did find and fix some bugs.

[Wonko the Sane]

For example, suppose you have two HDDs, both 150 GB. Now suppose you have a 4 GB HDD image file on one of those disks. Suppose you wish to attach it with G4D and WinVBlock. When WinVBlock goes looking for the backing disk, it has your two internal HDDs to choose from. Both of them are larger than the image file, so the image file could be on either of them. How then can we know which backing disk is the right one to use? There is no information passed from G4D about which one to use except for the BIOS drive number. But Windows doesn't use BIOS drive numbers at all!

Sorry Sha0, but I don't get it.
The 4Gb HDD image is inside a volume inside one of the two 150 Gb hard disks, right?
Thus it can be identified in grub4dos by it's UUID? (or maybe make use of the "default" grub4dos file)
Cannot WinVblock parse the menu.lst and get the UUID of the entry?
Or have WinVblock use a "WinVblock.ini" (or a setting in the Registry) with same UUID?


Wonko

[Sha0]

Sorry Sha0, but I don't get it.
The 4Gb HDD image is inside a volume inside one of the two 150 Gb hard disks, right?

That was what I meant for the example, yes.

Thus it can be identified in grub4dos by it's UUID?

What UUID? If you mean a volume UUID, I'm trying to find a backing disk, not backing volume. If we imgine that Windows has a "disk phase" followed by a "volume phase," then WinVBlock would be working in the "disk phase," before it (WinVBlock) is able to access volumes. So WinVBlock's sector-mapping strategy actually maps to a range of sectors on a backing disk, regardless of filesystems anywhere.

For example, consider this: Use Syslinux and MEMDISK to concatenate several disk images together (using Syslinux' initrd concatenation feature) as a single RAM disk. The fist disk image in that set might then boot GRUB4DOS. Then GRUB4DOS might map a non-RAM, sector-mapped disk to one of the other disk images in the MEMDISK RAM disk (maybe a floppy image following an HDD image?). So WinVBlock will provide the MEMDISK, but then also needs to map the G4D [floppy] disk to the MEMDISK backing disk.

Is that complicated enough? The point is that in that scenario, there are no filesystems involved at all; just sector ranges.

(or maybe make use of the "default" grub4dos file)
Cannot WinVblock parse the menu.lst and get the UUID of the entry?

This is a good idea, and on a to-do list. Putting a parser in a Windows driver would be unfortunate, but maybe that's as good as it gets.

Or have WinVblock use a "WinVblock.ini" (or a setting in the Registry) with same UUID?...

Well, then you can't expect the image file to be portable to other HDDs. One would have to port the image by opening it up and adding in a signature for the target disk, or by applying the same signature to the target disk, etc. An empty image file like the original post wouldn't have a Registry. A file (on the F6 floppy, maybe) would require FS support... Disk phase versus volume phase again... It's a tough one.

For now, I'm going to simply require the MBR 16-bit magic in the image file's first sector for HDD images, and "CD001" in the first ISO9660 Volume Descriptor for optical disc images. Ugly (to me), but easy.

[Sha0]

Vortex, the latest development build (just now published) should be able to support any combo of RAM- or sector-mapped HDD and .ISO images. You should be able to boot your HDD image now. You could even try sector-mapping the Windows Server 2003 .ISO (instead of making it a RAM disc). That should work, too. There's [currently] no code for G4D sector-mapped floppies, but they're pretty cheap to map as a RAM disk, anyway. I didn't think you'd mind.

There's a huge advantage to using a sector-mapped Windows Server 2003 installation .ISO, and that's that it avoids loading the whole image to RAM. As long as your storage controller is either driven by Windows' included drivers or you specify an additional F6 floppy with the driver, WinVBlock should be able to establish the "installation CD".

Enjoy! (Or report a problem.)

P. S. By the way, since you used ImDisk to format and pre-copy the Windows Server 2003 installation files into your image, did you remember to give the disk image an MBR and partition it?

[Wonko the Sane]

What UUID? If you mean a volume UUID, I'm trying to find a backing disk, not backing volume. If we imgine that Windows has a "disk phase" followed by a "volume phase," then WinVBlock would be working in the "disk phase," before it (WinVBlock) is able to access volumes. So WinVBlock's sector-mapping strategy actually maps to a range of sectors on a backing disk, regardless of filesystems anywhere.

Then we are back at square one.
We do have a way, which is Disk Signature, to identify a disk.
This data is available at sector level (offset 440,441,442 and 443 of the MBR)
Cannot WinVblock scan all hard disks for the "right" signature?
This is what NTLDR (or NTDETECT.COM) does when booting (as well as doing the checksum check that allows the "XP Kansas City shuffle").
The same data is available in the Registry in Mounted Devices. (if that same "hosting 150 Gb HDD was mounted before by the booted "WinVblock system")
So, if I get it right the problem is that grub4dos does not pass a "parameter" somehow that WinVblock can use, right?
If this is so, the only problem is - as I see it - when you move the "4 Gb image" from the "150 Gb HDD" to another HD device.
It seems to me not too bad (pragmatically and not philosophically) "hardcode" the "hosting HDD" signature somewhere inside the "hosted image" where Winvblock can read it, and use an "external utility" to update this data when this image is moved to another disk device or to "syncronize" the image to the "hosting disk".

For example, consider this: Use Syslinux and MEMDISK to concatenate several disk images together (using Syslinux' initrd concatenation feature) as a single RAM disk. The fist disk image in that set might then boot GRUB4DOS. Then GRUB4DOS might map a non-RAM, sector-mapped disk to one of the other disk images in the MEMDISK RAM disk (maybe a floppy image following an HDD image?). So WinVBlock will provide the MEMDISK, but then also needs to map the G4D [floppy] disk to the MEMDISK backing disk.

Is that complicated enough? The point is that in that scenario, there are no filesystems involved at all; just sector ranges.

No , it is more complicated than needed.
I mean, I know that solving theoretical problems in theory is a nice activity , but sometimes solving actual practical ones practically gives more results.



Wonko

[maanu]

ok , well ,

i just come to think that why we do not face the above " technical " issues while booting / dealing with our best friend (xp ) ??

what is so special in 2003 , that is causing such issues ? excessive security " somewhere " ???

[Sha0]

ok , well ,

i just come to think that why we do not face the above " technical " issues while booting / dealing with our best friend (xp ) ??

what is so special in 2003 , that is causing such issues ? excessive security " somewhere " ???

As far as I know, XP and 2003 get the same treatment from WinVBlock. The same bugs would apply to both and the same fixes would apply to both. Maybe you are talking about something else.

[maanu]

hmm , ok can you please explain why the SAME method worked OK by the original poster ??

i mean he install xp onto .img file OK using your driver and it did not give him 0x7B .

even i encounter this issue while making recovery console .img file from usb . SAME method using winvblock or firadisk worked ok with xp , NOT for 2003 , and gave the exact same BSOD .


also the issue with server 2003 and firadisk reported so many times , and if im not wrong with your driver too.

[Sha0]

hmm , ok can you please explain why the SAME method worked OK by the original poster ??

i mean he install xp onto .img file OK using your driver and it did not give him 0x7B .

Is that right? The original post doesn't mention XP, does it? Maybe I've missed it while reading. Maybe you mean in another thread that you've read, but that I haven't read.

even i encounter this issue while making recovery console .img file from usb . SAME method using winvblock or firadisk worked ok with xp , NOT for 2003 , and gave the exact same BSOD .

That's bad news. Maybe it's just bugs. Please note that WinVBlock has had a ton of development during my vacation a few weeks ago. That included some bug-fixes. Even today had a bug fix. I'd really enjoy if you could report failure/success with the current development binaries. WinVBlock is tested pretty well after every code change, but everyone has a different scenario. It was recently tested (today) with XP Recovery Console: Both HDD image and .ISO. It was also tested with Windows Server 2003 installation .ISO as GRUB4DOS RAM disk and sector-mapped disk.

also the issue with server 2003 and firadisk reported so many times , and if im not wrong with your driver too.

It has been? Oops. I haven't kept up. Sorry about that.