Jump to content











Photo
- - - - -

XP-from-RAM with firadisk crashing

firadisk winxp ramdisk grub4dos

  • Please log in to reply
14 replies to this topic

#1 HarrisonWalker

HarrisonWalker
  • Members
  • 7 posts
  •  
    Germany

Posted 05 July 2018 - 12:47 AM

Hi there,

I am playing around with firadisk and grub4dos to load a WinXP-Image to RAM and boot from it. I'm using virtualbox for my experiments. I found interesting tutorials about it, here on reboot.pro.

However, there are some things I still don't understand. My Windows is booting up but crashes after a few seconds. Before that happens, I can see the desktop and acces drives, though I'm still not sure if C:\ is from RAM or from the real harddrive.

Step-by-step:

1.) Because I'm using a special-configured XP in Vbox, I can't use the VHD-method, as often suggested. The partition-size is about 3,15 GB but the vbox-image is set to 10 GB dynamic-space. So after conversion to VHD or img, I would get a 10GB file, unsuitable for grub4dos.

2.) Therefore I made a 2nd partition in Vbox, booted with partedmagic-live-cd and copied the first 3152 MB from partition1 to an image-file on the 2nd partition. I did that to include MBR, partition-table and PBR into the image.

3.) Gparted can't read the image-file afterwards, because the partition-table is wrong. I then used testdisk to recover the partition-table in the image-file because now there is only one partition inside the file, instead of two at the origin. However, testdisk is doing it wrong for some reason. The found partition is a few MB too big in size.

4.)grub4dos is throwing errors because of this. XP is booting into RAM but, as mentioned before, is crashing after a while.

5.)I then booted with a MiniXP-live-cd to run DiskGenious and load the image-file. The program identified partition-table-errors and fixed them. Afterwards, grub4dos was not throwing errors anymore. However, XP-from-RAM still is crashing...

Forgot to mention: I did install the firadisk-driver in XP, before creating the image.

What I don't understand:

1) Do I need to configure firadisk somehow, in addition? I found some registry-values in some tutorials, to tweak around with. However I don't know if they apply for Ramdisk-usage. Shouldn't firadisk detect a grub-ramdisk by itself, after bootup?

2) Why is there a disc-image neccesary? Just using a partition-image with a bootloader in PBR would make things a lot easier.

3) I found something about the creation of a small ramdisk in grub4dos just to hand-over some configuration-options to firadisk. Basically they are the same options, someone can configure with the registry-tweaks. The small-ramdisk did not work, unfortunately. Grub4dos complains about a unknown device when trying to create the ramdisk. Can show you the command-line later.

4) The reg-key for mounted-devices (HKLM\SYSTEM\MountedDevices) holds signature and an offset of a volume. Some tutorials recommend replacing this key in the image file with the data from the image file. How do I get signature and offset from the image-file? Shouldn't they be identical as signature and offset from the original hdd?

I can give more details upon request, especially the menu.lst. Right now, I'm on a different computer, the text already got too long and it's really late already.



#2 HarrisonWalker

HarrisonWalker
  • Members
  • 7 posts
  •  
    Germany

Posted 05 July 2018 - 11:42 AM

Here my menu.lst:

#timeout 15
default 0

title XP_SP2 im RAM
map --mem (md) 0x800+4 (99)
map --hook
write (99) [FiraDisk]\nStartOptions=disk,vmem=find:\XP_SP2_Bugfix_5.4.img,boot;\n\0
find --set-root --ignore-floppies --ignore-cd /XP_SP2_Bugfix_5.4.img
map --mem ()/XP_SP2_Bugfix_5.4.img (hd0)
map --hook
root (hd0,0)
chainloader /ntldr

title XP_SP2
find --set-root --ignore-floppies --ignore-cd /ntldr
map () (hd0)
map (hd0) ()
map --rehook
find --set-root --ignore-floppies --ignore-cd /ntldr
chainloader /ntldr

title commandline
commandline

These lines cause trouble:

map --mem (md) 0x800+4 (99)
map --hook
write (99) [FiraDisk]\nStartOptions=disk,vmem=find:\XP_SP2_Bugfix_5.4.img,boot;\n\0



#3 HarrisonWalker

HarrisonWalker
  • Members
  • 7 posts
  •  
    Germany

Posted 05 July 2018 - 03:14 PM

I think one of my problems was the thing with the disk-signature: I opened the image with linux' hexedit and went to address 000001B8

There are four bytes at this position which are the disk-signature in reverse!

I altered them and noted down the new signature (I chose "1F 2F 3F 4F").

Afterwars, I booted into windows, mounted the disk-image with imdisk (offset 63 blocks, that's the start of the partition, right after MBR and partition-table) and opened regedit to change the image's Registry.

 

Then, click on "HKEY_LOCAL_MACHINE", then on File >> "load hive", browse to I:\Windows\system32\config\system and entered a new name "Offline-Registry". Drive I:\ was the mount-point of the image, created by imdisk. The image's registry was now loaded and editable.

 

I then went to HKEY_LOCAL_MACHINE/Offline-Registry/MountedDevices and looked for "\DosDevices\C:". I compared the value of the key with the values of the keys starting with "\??\Volume{". I then deleted the one with the identical value. Windows should automatically recreate it upon boot.

Afterwards, I changed "\DosDevices\C:" in the following way:

 

4F 3F 2F 1F 00 7E 00 00 00 00 00 00

 

The first four bytes are the disk-signature, followed by "00". "7E 00" is hex for the offset: 63 blocks x 512 Bytes per block = 32256 Bytes (=7E 00 in hex). I knew that from this tutorial.

 

To close the image's registry I went to "HKEY_LOCAL_MACHINE\Offline-Registry" and then on File >> Unload Hive. I also created a file "This is the image.txt" in the root of the image to identify it as the image-file.

 

I also removed the troublemaking lines in menu.lst, mention in my last post. So now, there is no mini-ramdisk-anymore, passing options to firadisk.

 

I unmounted the image, rebooted, chose booting XP into RAM and....

 

...It's still crashing! However, when I'm fast enough, I can open C:\ with explorer and can see my textfile "This is the image.txt"! So windows is mounting the ramdisk to C:\ !

 

How do I prevent XP from crashing?


Edited by HarrisonWalker, 05 July 2018 - 03:25 PM.


#4 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 05 July 2018 - 06:42 PM

Well, when it crashes, it should crash with a BSOD (blue screen of death) featuring a STOP ERROR (that may help in troubleshooting the issue).
If instead it reboots (and thus you cannot read the STOP ERROR) you should disable the automatic reboot on error.

Now back to (some of the many) issues.
XP is born to be booted from partitioned media, while there may be way to have it work from unpartitioned media, most probably these workarounds (if possible) wont really work as before or later you would find some issue with some programs that *need* a partitioned media.

Overall you did a lot of "right" things :) but you sort of did them "backwards".

Right now since the disk has been (with all due respect :)) created in a "wrong" way (and then "fixed", one way or the other) we don't really have any proof that the disk (in itself) is "correct" before and besides the Firadisk loading (i.e. it is possible that the issue is related to Firadisk but it is well possible that it is connected to *something* that wasn't corrected in the procedure used to "fix" the image - or however is not correct for *whatever* reason) .

Also, only as a side note, more than 3 Gb of image to be RAM mounted sounds like a very large amount :dubbio:, a "plain" (not reduced in any way) "full" install of XP should be around (at the most) 1.5 Gb and - usually - we tend to make reduced images ( in the 200 to 500, maybe 600 MB range) when the idea is to boot them in RAM (for several reasons, including that the grub4dos copying them to RAM will take some time for large images).

A few questions:
1) How big is in size the XP_SP2_Bugfix_5.4.img file?
2) Where does it reside? (I mean, does it reside directly on hard disk or is it within another image file that is mounted to a (virtual) hard disk in Virtualbox)
3) Which OS are you running? (I mean the system in which you run Virtualbox)
4) How much RAM have you assigned/is available in VirtualBox?
5) Which EXACT version of grub4dos are you using?

About disk signature:
1) to check disk signature you can use *any* hex/disk editor[1] in Windows/Linux or *any* of the many suitable tools[2], if you are in grub4dos you can use the cat command as follows (example):
cat --hex --skip=440 --length=4 (hd0)0+1

The above means:
cat --hex = parse showing result as hex values
--skip=440 starting from offset 440 (you can use 0x1B8 if you prefer)
--length=4 only the first 4 bytes starting at the specified offset
(hd0)0+1 the object to be parsed, in this case this means first disk (hd0) starting from sector at offset 0 (the MBR) for the length of 1 sector

Another way is to use (shameless plug ;) ) this small grub4dos batch (use the newer mbrview-no-wenv.zip ) :
http://reboot.pro/to...l-for-grub4dos/

:duff:
Wonko


[1]another shameless plug, but - if you are on a suitable Windows OS - good ol' Tiny Hexer can use my small "Structure viewers":
http://reboot.pro/to...-hexer-scripts/
[2] Clonedisk comes to mind:
http://reboot.pro/fi...e/24-clonedisk/
https://labalec.fr/erwan/?page_id=42


  • Nuno Brito likes this

#5 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 459 posts
  •  
    Thailand

Posted 07 July 2018 - 02:23 AM

1.) Because I'm using a special-configured XP in Vbox, I can't use the VHD-method, as often suggested. The partition-size is about 3,15 GB but the vbox-image is set to 10 GB dynamic-space. So after conversion to VHD or img, I would get a 10GB file, unsuitable for grub4dos.

Here is how to do the conversion easily.
Make a new VHD of suitable size (in another VHD mounted on host if you want to avoid copying later).
Attach to VM alongside the old vbox-mage, boot into gparted in VM and clone your windows partition from old vbox-image to new VHD.
 

1) Do I need to configure firadisk somehow, in addition? I found some registry-values in some tutorials, to tweak around with. However I don't know if they apply for Ramdisk-usage. Shouldn't firadisk detect a grub-ramdisk by itself, after bootup?

I think no configuration is needed.
 

2) Why is there a disc-image neccesary? Just using a partition-image with a bootloader in PBR would make things a lot easier.

It is not a necessary. It is a choice.
Why people want to use disk image ? Disk images are files you can copy around, put many of them in the same partition, avoid automatic mounting when not in use.
If you want to load from a partition image, it should be possible to construct virtual disk with partition table in memory but it will take more steps.
You may create "blank" mem disk (using map --mem (md)base+size (hd0) and map (hd0) hd1)), then map --hook, then copy MBR with partition table from a file or disk (using dd), copy from disk partition to mem disk partition (using dd).
If Windows see 2 disks with the same disk signature, it will probably automatically change one disk signature to a random number you don't know in advance. You avoid that by setting different disk signatures for mem disk and source disk.
If the source partition has been assigned C: and you don't detach source disk before booting, Windows see the original partition as C:. You may avoid it by editing the source disk signature or editing registry, but then you may have to edit it back before booting the source partition directly.
Use disk image with its own MBR with different disk signature from container disk signature to avoid this problem.
 

3) I found something about the creation of a small ramdisk in grub4dos just to hand-over some configuration-options to firadisk. Basically they are the same options, someone can configure with the registry-tweaks. The small-ramdisk did not work, unfortunately. Grub4dos complains about a unknown device when trying to create the ramdisk. Can show you the command-line later.

It can be used for booting from disk image without mem disk. Changes are written to disk image.
Don't mix it with mem disk from the same image. When Windows in RAM see the second virtual disk have the same disk signature, disk signature of the disk image will change.
 

4) The reg-key for mounted-devices (HKLM\SYSTEM\MountedDevices) holds signature and an offset of a volume. Some tutorials recommend replacing this key in the image file with the data from the image file. How do I get signature and offset from the image-file? Shouldn't they be identical as signature and offset from the original hdd?

They are equal when you copy both MBR and partition without changing partition start sector.
Disk signatures are not equal if a new MBR is created on a new disk image.
Offsets are not equal if you copy/move/resize partition to different start sector.
 

I altered them and noted down the new signature (I chose "1F 2F 3F 4F").
Afterwards, I changed "\DosDevices\C:" in the following way:

4F 3F 2F 1F 00 7E 00 00 00 00 00 00

I think disk editor and registry editor have the same byte order.
"1F 2F 3F 4F" and "4F 3F 2F 1F" do not match.
How can it get C: if its disk signature does not match ?
When Windows see a "new" partition/volume and drive letter "C:" is available, the new partition/volume can have C: assigned.
If you want to use this behavior, you should provide the following conditions.
1.There is no "DosDevices\?:" entry in MountedDevices key that match the partition/volume.
2.There is no "{guid}" entry in MountedDevices key that match the partition/volume.
3.There is no partition/volume in the machine that match the "DosDevices\C:".
4.The Windows partition you are booting is the first partition/volume to get assigned a new drive letter. -- Detach all other disks, the only new partition in the only remaining disk is sure to be the first to get assigned.
The correct value in "\DosDevices\C:" helps avoid the hassles of having to detach all the other disks, especially on real PC.

These still don't explain the last crash.

How much memory does the VM have ?
How much memory are free under 4GB address (where Windows XP 32-bit can use) after loading the disk image ?

#6 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 July 2018 - 09:37 AM

I think disk editor and registry editor have the same byte order.
"1F 2F 3F 4F" and "4F 3F 2F 1F" do not match.

Yes :) , that is confirmed, it is one of those fields that everyone choses to represent as he/she wishes, but in the Registry the sequence of bytes representing the disk signature is verbatim the byte sequence as written to disk (and seen in a disk editor), the them has been discussed on one of the given links, starting here:

http://reboot.pro/to...b4dos/?p=206748

 

As a side note, there is a new kid on the block:

http://reboot.pro/to...r-for-grub4dos/

that could represent an alternative to Firadisk (provided that the issue at hand is actually Firadisk related).

It could represent also a valid troubleshooting approach, trying the svbus driver - all the rest unchanged - would either confirm that the issue is connected to Firadisk (and/or to the settings used) or that the issue is in the image or *somethign else*.

 

:duff:

Wonko



#7 HarrisonWalker

HarrisonWalker
  • Members
  • 7 posts
  •  
    Germany

Posted 07 July 2018 - 01:17 PM

Wow, so much information!  :blink:  Thank you!

 

A few questions:
1) How big is in size the XP_SP2_Bugfix_5.4.img file?
2) Where does it reside? (I mean, does it reside directly on hard disk or is it within another image file that is mounted to a (virtual) hard disk in Virtualbox)
3) Which OS are you running? (I mean the system in which you run Virtualbox)
4) How much RAM have you assigned/is available in VirtualBox?
5) Which EXACT version of grub4dos are you using?

 

1.) The image file is 3150 MB in size.

2.) It resides on the second primary partition inside the virtualbox-image. Windows is accessing it as drive D:\

3.) I'm runngin Virtualbox on a 64-Bit-Slackware-Fork.

4.) My Computer has 8 GB of RAM, 5 GB are assigned to Virtualbox, Grub4Dos can access 3,5 GB of them. I *think* Windows can access the same amount as grub4dos...so there should be 400 MB of RAM available for windows (3,5 GB acessible RAM minus 3,1 GB for the RAMDisk).

5.) GRUB4DOS 0.4.6a 2014-03-27

 

Regarding to the image-file: In the end, I'm confident I got a good image since the partition inside the image starts exactly at sector 63. I found out when mounting it with imdisk and just used the factory-settings. All files are accessible and the disk-Signature is at the desired position, exactly 440 Bytes from the start of the image (and hence inside the MBR). Of course I'm talking about the desired position inside the image-file and not inside the imdisk-mounted-volume.

 

Regarding to the windows-crashing: Can one or more of the following facts be the cause?:

 

  • I forgot turning-off system-recovery before creating the image
  • Swapfile-issues. (I turned swap off completely. Later, I edited the image's registry to make a swapfile on D:\).
  • NTFS-Kompression is turned on to reduce image-size.
  • Wrong disk-signature in registry (propably it shouldn't be in reverse-order, as mentioned)

The way of crashing is not always the same. Sometimes I'm getting error-messages before windows crashes, reading something about device-errors. I forgot to mention that windows tries to install drivers, after boot-up. There is the hardware-driver-icon in the system-tray and sometimes a yellow sign with an exclamation mark.

However, sometimes it's just crashing right away, sometimes a driver-install-wizard shows up, before. Sometimes I get a short bluescreen (I really should turn-off auto-reboot). Sometimes it's rebooting directly. During booting windows did offer a checkdisc of drive c:, in one of my many trials with different versions of the image. If I allowed it, it was crashing, of course...with a bluescreen (something with win32k.sys or alike, don't remember correctly).

 

...I just realize, I should write down the errors exactly. It doesn't make sense this way. Will report back later...

 

Edit:

 

The Bluescreen of a windows-crash reads:

 

STOP: 0x000000F4 (0x00000003, 0x89F4B240, 0x89F4B3B4, 0x805FAF48)

 

I just rebooted. Now, windows just freezes. Another reboot, the virtual-computer shut down!

 

I will do another image, this time with system-recovery disabled and reversing the disc-signature in registry, as suggested.


Edited by HarrisonWalker, 07 July 2018 - 02:17 PM.


#8 HarrisonWalker

HarrisonWalker
  • Members
  • 7 posts
  •  
    Germany

Posted 07 July 2018 - 02:26 PM

This time an Error-Message occurred (translated by me):

 

 

RUNDLL

On execution of "newdev.dll,ClientSideInstall\\.\pipe\PNP_Device_Install_Pipe_0.{650A3EF4-5612-407B-B918-565455A4B395}" an exception occurred.



#9 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 July 2018 - 05:01 PM

Well, if it starts at 63 it can hardly be the "second" partition in that image. (unless your first partition is only 62 sectors)

 

At first sight you are a tadbit "tight" with space *everywhere*.

 

Of course it depends on the Windows XP specific install and on what you run in it, but I would not even THINK :ph34r: of having a "normal" (not tweaked/reduced/etc.)  with less than 512 MB available (of "real" RAM) and a swapfile of double that (or 1.5 GB of "real" RAM).

Of course specialized builds can work with much less RAM and even with no swap file, but if (say) you run a browser in it you will soon find that even my minimm of 1.5 GB is tight.

 

And I would try to use not NTFS compression, never really used/tested it intensively, so I really cannot say, but most probably it implies using some more RAM.

 

What I would suggest you would be to make the actual image smaller (as said an XP can fit in *anything* between 400 MB and 2 GB, including all the *needed* programs) WITHOUT NTFS compression, or, if you really need that huge amount of space, setup the machine so that what is loaded in RAM (via Firadisk or similar) is the less possible amount of bytes and have a second disk image (or another volume n the same disk) mounted "plainly" with the "rest". (it will BTW be way faster when booting, due to the time grub4dos uses to dd the image to RAM).

 

No matter the changes you did when experimenting to your disk or to the Registry about the disk signature, IF the "boot/system" volume gets drive letter C: in Explorer, it is now "right" and you can leave that alone.  :)

 

About the grub4dos version, you have a recent enough version[1], so I would totally exclude that being connected to the issue at hand, but since you are experimenting, the version you are using makes little sense :w00t: I mean:
GRUB4DOS 0.4.6a 2014-03-27

is not the latest of the "stable" "old" 0.4.5c which is 0.4.5c-2016-01-18 http://grub4dos.chen....5c-2016-01-18/

nor the latest of the "experimental 0.4.6.a which is 0.4.6a-2018-07-01 http://grub4dos.chen....6a-2018-07-01/

it is only an old version of the 0.4.6a series.

 

 

:duff:

Wonko

 

[1] For a number of reasons a deprecated, non-final version of 0.4.4 is very common among those that start experimenting with grub4dos

 

P.S. and the 0x000000F4 STOP ERROR is actually "compatible" with a situation where there are disk read fails due to not enough resources, examples:

https://msfn.org/boa...r-on-overnight/

https://msfn.org/boa...ror-0x000000f4/

and if this is the case, then they would be "semi-random".



#10 HarrisonWalker

HarrisonWalker
  • Members
  • 7 posts
  •  
    Germany

Posted 07 July 2018 - 09:51 PM

Well, if it starts at 63 it can hardly be the "second" partition in that image. (unless your first partition is only 62 sectors)

Nobody said it was the second partition. The first 62 sectors are MBR and partition-table, of course. The image has only one partition, by the way.

 

 

I would not even THINK :ph34r: of having a "normal" (not tweaked/reduced/etc.)  with less than 512 MB available (of "real" RAM).

That's your problem, since you are not well informed. Windows XP can run with 128 MB RAM already. 256 MB was the usual amount of RAM to run the OS with official system-recommendations. At the time XP was sold, 512 MB was expensive and guaranteed super-smooth usability of the OS. There is a tweak for instance to run the desktop and taskbar in an own explorer-process to speed-up the file-browsing-explorer. This tweak was usually applied at computers with more than 256 MB of RAM. Going higher than 512 MB was actually something XP wasn't designed for. The time-gap between Windows XP and Windows Vista was 5 years! Nobody knew that XP would lack a successor for so many years. Vista was a fail, afterwards. So until the release of Win7 2009, XP was the most used OS on the market and ran with memory-amounts it was never designed for. Computers meanwhile came with 2 GB of RAM for an OS that was 7-8 years old!

it will BTW be way faster when booting, due to the time grub4dos uses to dd the image to RAM

 

No idea why you have speed-issues but my experimental XP is unbelievable fast! The copy-to-RAM-process needs about 20 seconds, afterwards I see the windows-logo for 3 seconds and then immediately the desktop. The whole boot-process is a lot shorter than on a regular machine: 2 minutes are usual.

 

Anyway, thanks for the links. I didn't find a more recent version of grub4dos than the one I already had.

Reducing the image-size is a good idea. For some reason I have 700 MB free space inside the image-file.

Also, I will look into the msfn-articles.


Edited by HarrisonWalker, 07 July 2018 - 10:19 PM.


#11 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 08 July 2018 - 10:00 AM

Maybe I misunderstood this, my bad:

2.) It resides on the second primary partition inside the virtualbox-image. Windows is accessing it as drive D:\

 

 

 

That's your problem, since you are not well informed. Windows XP can run with 128 MB RAM already. 256 MB was the usual amount of RAM to run the OS with official system-recommendations. At the time XP was sold, 512 MB was expensive and guaranteed super-smooth usability of the OS. 

Thanks for so gracefully highlighting my ignorance :w00t: on the very topic (running windows 2000/XP on a reduced amount of disk and RAM space) that I played a lot with for the last 17 years or so.

 

Maybe I am well informed but unable to undestand the information I have. :dubbio:

 

Of course it can run on much less RAM, but a fully updated XP SP3 "without tweaks/changes", depending on the (unknown) programs the user may run, will very likely crash (unexpectedly and randomly) with 512 MB and no swap file. 

 

 

The dd-like operation that grub4dos performs to copy the "source" image to RAM is usually (as always it depends on the hardware in use and a Virtual Machine may have some caching mechanisms that helps) the slowest part of a RAMdisk booting, and you just confirmed that (though the 20 seconds are not that much):

grub4dos: 20 seconds (for a 3 GB image)

booting to desktop: 3 seconds

Total 23 seconds.

 

If the image was half that size, 1.5 GB those times would likely become (say) 11 seconds + 3 seconds = 14 seconds

 

Just think how long this would take .... :

http://reboot.pro/to...fs-below-10-mb/

 

A bit extreme/of limited use, of course, but this:

http://reboot.pro/topic/16765-minixp/

http://mistyprojects...niXP/index.html

is already a good basic "recovery environment" within the 100 MB mark and these:

http://reboot.pro/to...t-make-mini-xp/

are almost fully functional miniXP's, at 600 MB or 1.2 GB.

 

 

:duff:

Wonko



#12 tinybit

tinybit

    Gold Member

  • Developer
  • 1078 posts
  •  
    China

Posted 10 July 2018 - 06:10 AM

STOP: 0x000000F4

 

This BSOD code 0xF4 seems related to a bug in a WinXP driver(reportedly, a buggy video driver; there are also reports saying the problem could be solved by replacing the problematic XP driver with a Win7 video driver).

 

Possible workaround:

 

Firstly, use the latest release of grub4dos 0.4.6a(download from chenall's site).

Secondly, add a map option of --e820cycles=0(if still failed, you may try --e820cycles=1 or 2 or 3 or ... upto 20), just as the following:

 

map  --mem  (md)  0x800+4  (99)
map  --hook
write  (99)  [FiraDisk]\nStartOptions=disk,vmem=find:\XP_SP2_Bugfix_5.4.img,boot;\n\0
find  --set-root  --ignore-floppies  --ignore-cd  /XP_SP2_Bugfix_5.4.img
map  --mem  ()/XP_SP2_Bugfix_5.4.img  (hd0)
map  --e820cycles=0
map  --hook
root  (hd0,0)
chainloader  /ntldr


#13 tinybit

tinybit

    Gold Member

  • Developer
  • 1078 posts
  •  
    China

Posted 10 July 2018 - 06:22 AM

Forgot to mention:

 

"map  --e820cycles=0" will take effect after the next "map --hook" or "map --rehook". So usually you want to use

 

map  --e820cycles=0

 

followed by a line of

 

map --hook

 

or a line of

 

map --rehook



#14 tinybit

tinybit

    Gold Member

  • Developer
  • 1078 posts
  •  
    China

Posted 10 July 2018 - 06:37 AM

Sorry! Again, I forgot to mention, you must use --top option with newish grub4dos versions. Just this way:

 

map  --mem  (md)  0x800+4  (99)
map  --hook
write  (99)  [FiraDisk]\nStartOptions=disk,vmem=find:\XP_SP2_Bugfix_5.4.img,boot;\n\0
find  --set-root  --ignore-floppies  --ignore-cd  /XP_SP2_Bugfix_5.4.img
map  --mem  --top  ()/XP_SP2_Bugfix_5.4.img  (hd0)
map  --e820cycles=0
map  --hook
root  (hd0,0)
chainloader  /ntldr

 

If --top is not specified, then the IMG will load at somewhere below the 4GB boundary; or it will fail if there is no enough memory below the 4GB limit.



#15 HarrisonWalker

HarrisonWalker
  • Members
  • 7 posts
  •  
    Germany

Posted 12 July 2018 - 12:57 PM

Thank you! I will try that. I'm just a little bit short on time, at the moment. Please don't wonder that I answer so late. Might take a while until I report back.







Also tagged with one or more of these keywords: firadisk, winxp, ramdisk, grub4dos

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users