623 replies to this topic

[tinybit]

BSOD 0x000000F4

 

It could be caused by a buggy video driver of WinXP. Reports say, it can be solved by replacing the video driver with the one from Win7/Win8.

 

You may also like to workaround it with this:

 

map --e820cycles=N

 

Try N for 0,1,2,3,4,...... upto 20.

 

The "map --e820cycles=N" should be executed before the map --hook command.

[kievigreen]

 

 

You may also like to workaround it with this:

 

map --e820cycles=N

 

Try N for 0,1,2,3,4,...... upto 20.

 

The "map --e820cycles=N" should be executed before the map --hook command.

 

I don't understand why well it works, just loaded the videocard driver into VHD.

map --e820cycles=1

 

 

Everything works perfectly

 

 

 

 

Edited by kievigreen, 16 July 2015 - 12:13 AM.

[kievigreen]

Ok

I understood in what there was my mistake.
That is I passed this stage of installation
At this stage it is necessary to install the videocard Driver
 

title Start - TXT-mode XP Setup on XPSRC1.vhd - XP3_1307.iso - Size 626 MB
find --set-root --ignore-floppies /XP3_1307.iso
map /XP3_1307.iso (0xff)
map --rd-size=2048
map --mem (rd)+4 (0x55)
map --e820cycles=0
map --hook
write (0x55) #!GRUB4DOS\x00v=1\x00/XP3_1307.iso\x00\xff\x00
find --set-root --ignore-floppies /XPSRC1.vhd
map --mem /winvblock.ima (fd1)
map --mem /winvblock.ima (fd0)
map /XPSRC1.vhd (hd0)
map --e820cycles=0
map --rehook
chainloader (0xff)

But I bypassed this stage and loaded Windows XP without videocard Driver with such loading

BSOD 0x000000F4

title Boot Windows XP from Image - XPSRC1.vhd - WinVBlock driver - 2000 MB
find --set-root --ignore-floppies /XPSRC1.vhd
map /XPSRC1.vhd (hd0)
map --hook
root (hd0,0)
chainloader /ntldr

 

Or if there is no videocard driver.

So to load

title 2 XPSRC1.VHD - WinVBlock RAMDISK  - 620 MB
# Sector-mapped disk
find --set-root --ignore-floppies /XPSRC1.VHD
map /XPSRC1.VHD (hd0)
map --e820cycles=1
map --hook
root (hd0,0)
chainloader /ntldr

Thanks  tinybit

Edited by kievigreen, 16 July 2015 - 01:04 AM.

[tinybit]

 

Ok

I understood in what there was my mistake.
That is I passed this stage of installation
At this stage it is necessary to install the videocard Driver
 

title Start - TXT-mode XP Setup on XPSRC1.vhd - XP3_1307.iso - Size 626 MB
find --set-root --ignore-floppies /XP3_1307.iso
map /XP3_1307.iso (0xff)
map --rd-size=2048
map --mem (rd)+4 (0x55)
map --e820cycles=0
map --hook
write (0x55) #!GRUB4DOS\x00v=1\x00/XP3_1307.iso\x00\xff\x00
find --set-root --ignore-floppies /XPSRC1.vhd
map --mem /winvblock.ima (fd1)
map --mem /winvblock.ima (fd0)
map /XPSRC1.vhd (hd0)
map --e820cycles=0
map --rehook
chainloader (0xff)

But I bypassed this stage and loaded Windows XP without videocard Driver with such loading

BSOD 0x000000F4

title Boot Windows XP from Image - XPSRC1.vhd - WinVBlock driver - 2000 MB
find --set-root --ignore-floppies /XPSRC1.vhd
map /XPSRC1.vhd (hd0)
map --hook
root (hd0,0)
chainloader /ntldr

 

Or if there is no videocard driver.

So to load

title 2 XPSRC1.VHD - WinVBlock RAMDISK  - 620 MB
# Sector-mapped disk
find --set-root --ignore-floppies /XPSRC1.VHD
map /XPSRC1.VHD (hd0)
map --e820cycles=1
map --hook
root (hd0,0)
chainloader /ntldr

Thanks  tinybit

 

 

Nice to hear one more story of success. Thanks.

[reboot12]

I don't understand why well it works, just loaded the videocard driver into VHD.
map --e820cycles=1
Everything works perfectly

It seems that you are using direct mapping for ISO and VHD.
In topic XP Setup freezes with versions after 0.4.5b-2011-07-14 tinybit writes:

Older grub4dos'es than 2011-7-14 will never hook int15 on a non-mem mapping, so they might encounter no problems.

Please make two tests with my driver FIX_INF_WinVBlock_0.0.1.8_(June-1-2010)_no_direct_map.zip:
First test:

• for ISO image use map --mem xp.iso
• for VHD image use map /winxp.vhd without e820cycles

Second test:

• for ISO image use map --mem xp.iso
• for VHD image use map /winxp.vhd with e820cycles

Of course please use GRUB4DOS 0.4.5c or above.
Probably e820cycles is not necessary if use map --mem ISO and map /winxp.vhd

[kievigreen]

Who used  Drive EWF for VHD ?

[Sha0]

Hello, all.  I know that WinVBlock hasn't been developed for more than two years, so I apologize.  I am hopeful that valuable business dealing with I. T. outsourcing, virtual servers, domain-names, e-mail, web-sites, etc. will help to provide an opportunity to further WinVBlock.  (And other awesome open source projects, too.)

 

I hope to see you, soon!

[Wonko the Sane]

Hello, all.  I know that WinVBlock hasn't been developed for more than two years, so I apologize.  I am hopeful that valuable business dealing with I. T. outsourcing, virtual servers, domain-names, e-mail, web-sites, etc. will help to provide an opportunity to further WinVBlock.  (And other awesome open source projects, too.)

 

I hope to see you, soon!

Nice to know you are still around and well

 

Wonko

[Sha0]

Nice to know you are still around and well

Thank you, and like-wise, Wonko the Sane. 

[L A M A]

I thought you guys gave up completely (you and karyonix). Good to see you here...<br /><br />

[kievigreen]

Hi all

 

Why WinVblock can't be loaded with Dynamic hard disk image ( VHD ) ?

[Wonko the Sane]

Hi all

 

Why WinVblock can't be loaded with Dynamic hard disk image ( VHD ) ?

Because both grub4dos and Winvblock cannot mount/access .vhd's

 

Actually they can only access/mount RAW images BUT coincidentally a "static" .vhd is a RAW image with a single sector appended (which is ignored).

Thus a static .vhd (please read as a RAW image with an extra sector appended) can be mapped/accessed/mounted.

 

Wonko

[mr_jrt]

wvblk32.sys 0.0.1.8 (SHA-1: 140da786b9f132ba8711e97e8453837c7fb2b542)
firadisk.sys 0.0.1.30 (SHA-1: f250ed1bd29fa639196599cd6ed41768db9dcd6f)

Hi. Apoligies, but this post is a bit backwards. I typed it out as I was experimenting, and came to a workable solution right at the end, but figured the experimentation might come in useful for people having trouble in the future, so put the end at the top and left the rest down below, should people be interested, if that makes sense.

Right, the summary is that I want to use WinVBlock's AoE support (because it seems to be the best), but use FiraDisk for file-mapped emulated optical support during boot (mainly because I've tested FiraDisk much, much more than WinVBlock).

Now, I know it's not advised to mix the two due to the overlap, but I can disable Firadisk by supplying a null config (via a small mem disk) from GRUB4DOS, but I can't seem to disable WinVBlock from picking up the emulated discs, the only way seems to be to physically stop the driver from loading in my txtsetup.sif. Basically, I ideally want to be able to have two menu options to use one or the other with the same ISO, so that if one does not work for whatever reason on a particular piece of hardware the other driver can be tried without wastefully having to have multiple ISOs for this one difference.

It seems my problems with WinVBlock stemmed from the ramdisks used to support Firadisk - for whatever reason it's picking them up as drives of some sort it need to handle and it's messing up something (coming up as multiple dud optical drives, maybe?) leading to the ASMS error, whilst removing them all completely enables it all work as expected, but I then don't have the ability to control what functionality I want from the driver (i.e. don't touch drive 0xff as FiraDisk's supposed to be handling that one).

So I can proceed for now by just using WinVBlock (aka. commenting out Firadisk) with no ram config disks, and in the future could maybe have a stab at tweaking the code to be able to exclude specified GRUB discs from the driver handling (or just look at explicitly specified ones), but I read a lot of material that suggested I needed one of those config drives for it to even work, and I even found the bit in the source that seems to handle it!

So I'd appreciate a bit of clarification of what's meant to happen and what I'm getting wrong there, if anyone would be so kind, please.

---- Original post below ----

Hello.

I'm trying to get the AoE functionality of WinVBlock working, but am having a few difficulties. To date I've been using Firadisk to map an emulated optical drive to a multiboot ISO on my USB stick, and that all works fine. However, to get AoE support, I need to use WinVBlock, so I've integrated that into my source.

All subsequent boots from here on in are using iPXE to sanhook an iscsi target until I sort the WinVblock error out, and this is all fine.

Now, text mode completes fine, but GUI mode gives the classic ASMS cannot be found error. The weird thing is, I can access the emulated optical disc fine from the command line as the G:\ drive. Setup just seems to be looking at the wrong path for some reason? i.e. BootPath is \O264\I386 in txtsetup.sif (and according to $winnt$.sif, dospath=g:\) but it's defaulting to g:\i386, it seems. When I give it the correct path for every single prompted file then setup completes just fine.

Initially I was hoping to continue using Firadisk as my disc emulation (as I've tested it so much more) and just use WinVBlock as my AoE driver, but when this didn't work as WinVBlock is picking up the optical drive mapping I started trying to first tell WinVBlock to ignore my mapped ISO by giving it an explicit empty rd config:

map --mem (md)0x0800+2 (98)
map --mem (md)0x1200+2 (99)
<snip>
write (98) #!GRUB4DOS\x00v=1\x00\x00\x00
write (99) [FiraDisk]\nStartOptions=cdrom,vmem=find:/multiboot/ISOS/xp.iso;\n\0

...but that didn't work, it continued to fail, so I tried the other way around, explicitly disabling Firadisk with a config:

map --mem (md)0x0800+2 (98)
map --mem (md)0x1200+2 (99)
<snip>
write (98) #!GRUB4DOS\x00v=1\x00/multiboot/ISOS/xp.iso\x00\xff\x00
write (99) [FiraDisk]\n\n\0

...but that didn't work either. So I progressed to actually disabling the drivers in the ISO by commenting out their respective [SCSI.Load] lines, and as expected Firadisk fails when I explicitly give it an empty config (in text mode with 0x7B and GUI mode) and works when I give it a normal one (which is something, I guess), but even with the Firadisk driver inactive a GUI boot with WinVBlock active still fails with the missing ASMS error (I suspect this is because it doesn't like the small config ram disks).

One thing I have noticed is that $winnt$.sif seems to have a discrepancy in the sourcepath. With Firadisk it's "\device\cdrom0\O264\", with WinVBlock it's "\device\cdrom1\O264\", even when only one driver is active and my USB optical drive is physically disconnected.

...the other thing I've noticed is that WinVBlock seems to work even when I give it an explicit empty config, the opposite of FiraDisk. Whilst this initially caught me out with FiraDisk (memory-mapped disks work without a config, file-mapped ones do not), it's actually quite a useful bit of control, and I'm not sure how I can hide the emulated optical mapping from WinVBlock with that behaviour?

Edited by mr_jrt, 14 March 2016 - 01:52 AM.

[Wonko the Sane]

I am not sure to understand (actually I am pretty sure I don't understand). 

Why don't you create only one ramdisk and connect it  to Winvblock only?

 

Something *like*:

...

map --rd-size=2048
map --mem (rd)+4 (0x55)
map --e820cycles=0
map --hook
write (0x55) #!GRUB4DOS\x00v=1\x00/multiboot/ISOS/xp.iso\x00\xff\x001\x00\x00\x00
...

 

with just one memory drive and no connection for Firadisk to "hook" it?

 

Why since the original suggestion by sha0 is to use a 4 sector disk at the beginning of the (rd), why are you using a 2 sector one at offset 0x800? (maybe irrelevant, but why introducing changes unless they are needed or documented?)

 

Also, please post your WHOLE menu.lst entries, snippets are easier to read, but don't tell the whole story, with the whole entry maybe someone may be able to spot an issue, this way it would be guessing,

And which OS is that, XP, right?

 

The path issue is something that *sometimes* happen, there is some trick that SetupWindowsfromUSB uses (or used), but cannot remember what it was:

http://www.msfn.org/...omusb-with-gui/

 

Wonko

[wimb]

Some examples of working menu.lst entries for WinVBlock and FiraDisk are here

 

http://reboot.pro/to...ct-make-mini-7/

http://reboot.pro/to...tall-xp-in-vhd/

http://reboot.pro/to...twork-via-ipxe/

[Wonko the Sane]

Some examples of working menu.lst entries for WinVBlock and FiraDisk are here

 

http://reboot.pro/to...ct-make-mini-7/

http://reboot.pro/to...tall-xp-in-vhd/

http://reboot.pro/to...twork-via-ipxe/

Sure , but they are not different from the several ones in this thread or better explained/detailed/documented, and since mr_jrt is attempting to experiment the method with AoE what would be interesting is the actual "why" rather than the "how".

 

Do you have, specifically on any of the three linked threads an example of an XP install .iso booted through Winvblock and AoE?

If yes, can you point to it specifically?

 

Your topics contain a wealth of information , but in each of them there are so many possible variations/possibilities and even some "complications" that make them very difficult to read and understand or to find relevant info inside them. 

 

Wonko

[reboot12]

I have not tested Firadisk but tested WinVBlock and is enough to install WinXP. Choose one driver - WinVBlock or Firadisk. Do not use both at once.

[mr_jrt]

I am not sure to understand (actually I am pretty sure I don't understand). 
Why don't you create only one ramdisk and connect it  to Winvblock only?
 
Something *like*:
with just one memory drive and no connection for Firadisk to "hook" it?

The reason for trying to do it with both drivers is I don't know anything about WinVBlock's file mapping, but I've spent months using Firadisk. I know what works, what doesn't, etc. I can't say the same for WinVBlock at all as I've only just picked it up having previously successfully integrated iSCSI support in. I'm only looking at WinVBlock for the AoE support, and I don't want to invalidate all of my previous testing by having to redo it all using WinVBlock - it just seems strange I can't just pick and choose what bits I want to use, that's all. As said previously, I can disable Firadisk easily enough with a null memdisk-held config, but WinVBlock doesn't actually seem to need one, and actually has issues when I give it one, and that's the tidbit I find confusing.
 

Why since the original suggestion by sha0 is to use a 4 sector disk at the beginning of the (rd), why are you using a 2 sector one at offset 0x800? (maybe irrelevant, but why introducing changes unless they are needed or documented?)

Well, the sector size is 0x200 (512) bytes, and given the contents of those mem drives are 57 and 67 bytes, a single sector each should be more than enough, but GRUB4DOS unequivocally warns you not to have single-sector memdisks, so I went for 2 sectors. Low-RAM is not to be wasted....I'll give it a go with 4 sectors and see if it makes a difference though, it's certainly worth a punt.
 

Also, please post your WHOLE menu.lst entries, snippets are easier to read, but don't tell the whole story, with the whole entry maybe someone may be able to spot an issue, this way it would be guessing,
And which OS is that, XP, right?
 
The path issue is something that *sometimes* happen, there is some trick that SetupWindowsfromUSB uses (or used), but cannot remember what it was:
http://www.msfn.org/...omusb-with-gui/

 
If you insist...

title Continue Windows XP Install from xp.iso (Stage 2-WinVBlock Direct)
map --mem (md)0x0800+2 (98)
map --mem (md)0x1200+2 (99)
find --set-root /multiboot/ISOS/xp.iso
map (hd0) (hd1)
map (hd1) (hd0)
map /multiboot/ISOS/xp.iso (0xff)
map --hook
write (98) #!GRUB4DOS\x00v=1\x00/multiboot/ISOS/xp.iso\x00\xff\x00
write (99) [FiraDisk]\n\n\0
chainloader (hd0)+1

...and that gives me dummy drives in GUI Windows setup, but text-mode seems to work fine. Removing the memdrives lets it all work fine, but obviously I can't disable the WinVBlock driver without one. More tinkering needed, clearly.

 

I have not tested Firadisk but tested WinVBlock and is enough to install WinXP. Choose one driver - WinVBlock or Firadisk. Do not use both at once.

Thanks, but I'm more than well aware of that. I'm not doing this to a schedule, I'm doing it to learn. Being told "don't do x" without also stating "why" isn't that helpful. There's no reason they shouldn't be able to co-operate if they're accessing different things. The trick of course, is to make sure that they are.

[mr_jrt]

Answering my own question, I've determined from a few handy sources that indeed WinVBlock does not require the memdisk config. It will find the sector-mapped images automatically and use them just fine, but if you supply the config file it will switch to a file-backed mapping instead, which is better for various reasons.

 

The additional drives I'm seeing are indeed related - somewhat unexpectedly both Firadisk and WinVBlock map them as emulated floppy drives, meaning that when I stick both in I lose my A: and B: drives and my actual USB floppy ends up on drive H: ...and of course, the mapped optical image gets picked up by both, so two drives there as well. Would probably be better if they just read the configs and ignored the config drives after reading the values, but you can't have everything.

 

So in conclusion, there's no way (short of modifying the code to support it) to use those configs to control WinVBlock to do anything other than switch from sector-mapped to file-mapped disks by associating drive numbers to filenames.

...and in my particular use case, if you want to use WinVBlock's AoE support you have to use it's image mapping as well since you can't disable it.

[Wonko the Sane]

You mean that if you map --mem the hook is automatic, but if you map (without --mem) the .iso you need to pass the parameters to both?

This is "normal" AFAICR.

 

But overall, if the "title" of the entry is "Continue Windows XP Install from xp.iso (Stage 2-WinVBlock Direct)" I am failing to understand why you have any reference to firadisk in it. You can have another menu entry (or a sub-menu.lst) allowing you to choose between firadisk based and Winvblock based setup.

Or could you use some "conditional" sintax to load the one or the other.

Am I missing something?

 

The mapping of the (rd) to (98) or (99) seems like automatically doubling as (fd0) and (fd1), but normally these latter are occupied by winvblock.ima (if the driver is not integrated/installed), so the configuration devices should not be needed (as floppy), maybe you can try some fake mapping and/or "map --floppies=0" ?

 

Wonko

[steve6375]

This is the code I use XP Step 2 WinVBlock in Easy2Boot

I found that if you don't load the ISO into memory, it can BSOD on some systems, so I always try to load it into memory if it will fit.

#echo XP INSTALL - STEP 2
#echo ===================
echo
set ISO=/XP.ISO
# load winvblock anyway!
map --mem (bd)/%grub%/NewWinVBlock.ima.gz (fd0) > nul
map --mem (bd)/%grub%/NewWinVBlock.ima.gz (fd1) > nul
#hd0 is USB
#hd1 is real HDD
# note: --mem is used first - if not enough memory then retry try without loading iso into ramdrive (but may get BSOD)
# we must load the ISO into memory, so it will be slow to load here ...
map --mem %MFOLDER%/%ISO% (0xff) || map  %MFOLDER%/%ISO% (0xff) > nul
# If user installs to hd2 then we must shift all drives or else ntldr/boot.ini will try to boot to wrong drive
set /a HDCNT=*0x475 & 0xff - 1 > nul
set topmap=(hd%HDCNT%)
if %HDCNT%>=1 map (hd0) %topmap% > nul && map (hd1) (hd0) && echo Mapping (hd0) to %topmap% and (hd1) to (hd0)
if %HDCNT%>=2 map (hd2) (hd1) > nul && if %HDCNT%>=3 map (hd3) (hd2) > nul && if %HDCNT%>=4 map (hd4) (hd3) > nul  && if %HDCNT%>=5 map (hd5) (hd4) > nul && if %HDCNT%>=6 map (hd6) (hd5) > nul && if %HDCNT%>=7 map (hd7) (hd6) > nul && if %HDCNT%>=8 map (hd8) (hd7) > nul
map --hook > nul
map --rd-size=2048 > nul
map --mem (rd)+4 (0x55) > nul
map --rehook > nul
write (0x55) #!GRUB4DOS\x00v=1\x00%MFOLDER%/%ISO%\x00\xA0\x00 > nul
root (hd0,0) > nul || root (hd0,1) > nul || root (hd0,2) > nul || rootnoverify (hd0,0) > nul
chainloader (hd0)+1 > nul

[mr_jrt]

You mean that if you map --mem the hook is automatic, but if you map (without --mem) the .iso you need to pass the parameters to both?
This is "normal" AFAICR.

That is indeed what I expected, but it seems to work absolutely fine without the config, even without mapping to memory(aka. sector-mapped directly), (unlike Firadisk which DOES require the config drive when mapped directly.)

Edited by mr_jrt, 15 March 2016 - 08:47 PM.

[reboot12]

That is indeed what I expected, but it seems to work absolutely fine without the config, even without mapping to memory(aka. sector-mapped directly)

You're wrong notion!

 

Memory mapping is map --mem option e.g.

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

Direct mapping is map option e.g.

map /xp.iso (0xff)

[mr_jrt]

reboot12, I think you've misunderstood me, but I'm not going to get into an argument over it.

 

Moving on...I've been experimenting further, and have made a couple of curious "discoveries". First up, I realised I was using reboot12's "modified" driver, specifically, the direct access version. When I boot this driver, I can indeed directly map the ISO on my USB stick and it works fine, BUT: aoe32.sys fails to load: "The file aoe32.sys is corrupted." Given the filesizes are vastly different from the stock WinVBlock 0.0.1.8 (reboot12's is 42,112 bytes, SHA-1: 140da786b9f132ba8711e97e8453837c7fb2b542, Sha0's offical 0.0.1.8 is 19,584 bytes, SHA-1: b908b7d9b5ae72e54098c7694020dafc033ef7d3), what did you change to make it work? When I use the stock driver I get BSOD 0xA (0xE11F5000, 0x2, 0x1, 0x80913D15).

 

Now, here's the REALLY interesting bit: Everything I've read (and I've read a lot, but could have missed something important!) suggests that you cannot install XP using the AoE driver - it won't work in text mode, and you have to install to a physical disk, then install the AoE driver, and then transfer it to the AoE target.

 

...well, here's the thing. I just installed XP directly in text mode straight to an AoE server, all netbooted.

 

As mentioned above, with the stock WinVBlock driver direct mapping fails with BSOD 0xA, but the fall-back of memory-mapping works, and when I use that and proceed with setup the AoE target appears as a valid install target, but curiously, under the iScsiPrt! My install medium already has iSCSI support installed and working, but I can confirm 100% that despite setup's confusion, it does in fact install and work with my AoE target as my test iSCSI targets aren't even running right now, (and I gave them all different disk sizes to make double sure!)

 

So that's quite interesting. It dies with 0x7B when it reboots into GUI mode, but I've not even tried fixing that yet - I'm still fiddling with text mode drivers...but it's an excellent (and unexpected) start. It even shows up correctly as booting over AoE using iPXE in the XP startup logo screen as it does with iSCSI (which makes me confident this is just undocumented but has been explicitly implemented - I find the chances of this all just randomly working as a bit of a stretch of the imagination!)

[mr_jrt]

...and once again, answering my own question - I just realised the significance of the dates on reboot12's earlier posts. When you said you didn't change the source code, I suspect what you meant was that you didn't do any coding yourself, but you built the post-0.0.1.8 coding Sha0 had done, and those bugfixes were what fixed direct-mapping. I don't have a build environment handy - don't suppose anybody could please build the repo again, but include all the drivers? There's a few more commits after Feb 14th 2011 as well - the most recent one is the 4th of Aug 2011.

 

I'll have a stab at sorting one out at the weekend if nobody has managed to do so by then.

Edited by mr_jrt, 17 March 2016 - 01:57 AM.