FiraDisk (latest = 0.0.1.30)

...but I don't quite understand the remainder of the solution

Txtsetup.sif has a few lines added in order to change boot and source paths:

Has anyone a bit of time to investigate and perhaps shed more light on this ?

The remainder is part of a method, should be unrelated to the issues you are after:
http://www.msfn.org/...aded-small-iso/

The remainder is part of a method, should be unrelated to the issues you are after:

Ilko, many thanks for your feedback !!
So what you're saying is that in our case not using --mem should be enough to solve the problem ?
As a matter of fact, I first had this freeze when "windows is starting" on the very same machine as you (Dell Latitude 6400), but I'm also seeing the same on other machines, and wimb has also reported the same, most likely on different machines again ! Any ideas what is going wrong ?

Steve6375 :
http://www.msfn.org/...post__p__957491

This sounds like the BIOS e820h memory map function is returning incorrect memory size data. grub4dos will place the iso at the top of RAM. It is quite common for BIOSes to incorrectly report the size of memory and so grub4dos may load the ISO into memory locations that are being used for something else - shared UMA graphics memory for instance - and then the code gets trashed by the BIOS before it can be run!

MemTest86+ reports e820h memory size parameters when you run it - but for this test you should not load it into memory using --mem via grub4dos or it may crash or itself modify the parameters returned - I would recommend booting from CD and running it. MemTest86+ may even fail if it tries to test memory near the top which is not there...

I have reported many such errors to mainboard and notebook manufacturers over the years! Basically, Int 15h e820h reports free memory - if you try to use all the memory reported as 'free' and then test it, it fails because the values returned by the BIOs were incorrect. See this post for an explanation of what this does http://www.masm32.co...21&topic=1399.0

Here in boot-land , oops, BSOD 0x7B, reboot.pro was also ongoing discussion about the possible causes, can't quite remember where the topic was.

Hi

Karyonix, since you made it possible to add parameters in menu.lst (about path and all), is it possible that firadisk can accept extra settings and mount G4D ramdisk to custom drive letter? for example R:\ ???

My options are:

01. Somehow change drive letter of existing windows install on image (some offline registry update?)

02. Maybe an already installed windows on hard drive letter C:\ cannot be changed AFTER installation but I recall you had a guide? to install XP from ISO to FileDisk? So? using WinNTSetup2_x86.exe to [integrate your driver + change install path] and existing G4D menu instructions in your guide does the trick in theory?

03. Use my 9x trick: make 1 Primary partition, and too many logical partitions till Q: and then R: as another Primary partition on FileDisk.img



edit: still,... firadisk has to tell windows setup to mount specific filedisk {drive+partition} to %custom% drive letter (from menu.lst) right???

edit2: I'm also having similar problem on newly released Ubuntu 11.4,... I was hoping to use G4D to map a filedisk but.... no FiraDisk out there.... (to directly install ubuntu on *.IMG)...

01. Somehow change drive letter of existing windows install on image (some offline registry update?)

I'm pretty sure that Firadisk doesn't know anything about drive letters and leaves it up to Windows as to which drive letter gets assigned to which partition. You can use normal Windows functions such as Disk Management and MOUNTVOL.EXE to change drive letter assignments.

A disk driver provides a disk, not a partition. Partitions come from a higher level driver. So it seems that such a feature request would be asking for a lower-level driver to manipulate a higher-level driver's creations/decisions.

Contrast with ImDisk which provides partitions and controls which drive letter is used.

Have a look at HKLM\SYSTEM\MountedDevices\

It's not the smartest idea in the world, as it is tricky and prone to errors.

Mind you changing the drive letter editing the offline registry is trivial, the problem is having *everything* working afterwards (due to hardcoded drive letters paths to applications and what not).

Some details/hints:
http://www.petri.co...._windows_xp.htm
http://www.msfn.org/...stem-partition/

This might be a "better" approach:
http://www.911cd.net...showtopic=19663
(pre-assign drive letter during setup) though cannot say if needs changes/tweaks to work for ionstalling in .img files.


Wonko

I'm pretty sure that Firadisk doesn't know anything about drive letters and leaves it up to Windows as to which drive letter gets assigned to which partition. You can use normal Windows functions such as Disk Management and MOUNTVOL.EXE to change drive letter assignments.

Windows cannot modify the drve letter of system volume or boot volume and if I go to another windows (installed on different partition2), it is meaning less because Disk Management there, will save settings on it's own windows partition2 and not on partition1).

A disk driver provides a disk, not a partition. Partitions come from a higher level driver. So it seems that such a feature request would be asking for a lower-level driver to manipulate a higher-level driver's creations/decisions.

Contrast with ImDisk which provides partitions and controls which drive letter is used.

Not sure how imDisk is related with system volume's drive letter.

Have a look at HKLM\SYSTEM\MountedDevices\

At the time of fresh install, it is not possible for "a new feature" to calculate existing number of drives, map some memory, and reserve all remaining drive letters till %custom% specified drive letter in menu.lst so Windows mounts that exceptional %custom%: drive letter? After installation all reserves are removed (by choosing normal menu item from menu.lst?)

It's not the smartest idea in the world, as it is tricky and prone to errors.

Mind you changing the drive letter editing the offline registry is trivial, the problem is having *everything* working afterwards (due to hardcoded drive letters paths to applications and what not).

Some details/hints:
http://www.petri.co...._windows_xp.htm
http://www.msfn.org/...stem-partition/

This might be a "better" approach:
http://www.911cd.net...showtopic=19663
(pre-assign drive letter during setup) though cannot say if needs changes/tweaks to work for ionstalling in .img files.


Wonko

This is why I've aborted to go after existing C:\Windows... but I'm interested from Fresh start and installation (which will cut the errors)

edit: reading the rest of the links....

S, READ the given links BEFORE stating something that sound almost, but not quite, completely UNLIKE "right".

It is possible to change "on the fly" a drive letter of a booted system.
On a "base" install, it is relatively easy to correct the hardcoded paths, but once you have installed to the OS a zillion apps, it may become a tadbit more difficult.


Wonko

S, READ the given links BEFORE stating something that sound almost, but not quite, completely UNLIKE "right".


Wonko

ok... you're fast and wrote reply... though i did edit....

Windows cannot modify the drve letter of system volume or boot volume and if I go to another windows (installed on different partition2), it is meaning less because Disk Management there, will save settings on it's own windows partition2 and not on partition1).

I suggest you use Disk Management and/or MountVol.exe from within the the OS whose drive letters you wish to change. It seems that you are interested in choosing the drive letter for the boot volume before ever booting the OS. Is that correct?

Not sure how imDisk is related with system volume's drive letter.

It isn't. By "contrast," I meant that you can observe how Firadisk and ImDisk differ. The former provides disks, the latter provides single-partition "disks," which are essentially partitions. Since drive letters are associated with volumes (partitions, in this case), that is why it can make sense for ImDisk to choose drive letters, but not Firadisk.

It's not impossible, but it seems out-of-scope for a disk driver to work with partitions. There are different partitioning schemes, for example: MBR, GPT, APM, etc. Should Firadisk have to know about each of those? Should an Intel SATA driver have to know about each of those? Should a vanilla IDE driver have to know about each of those? That is why partitions are provided by a higher-level driver.

At the time of fresh install, it is not

Did you mean to type "is it not"?

possible for "a new feature" to calculate existing number of drivers, map some memory, and reserve all remaining drive letters till %custom% specified drive letter in menu.lst so Windows mounts that exceptional drive letter? After installation all reserves are removed (by choosing normal menu item from menu.lst?)

Disk versus partition! Drive letters are for partitions, not disks! Why should a disk driver know anything about partitions or manipulate which drive letters are assigned to partitions? A disk might not even have any partitions on it, or be entirely one partition (like a "superfloppy").

You could potentially partition a disk image as per your option 03 in order to control drive letter assignments before installing the OS. However, my impression was that Windows NT gives primary partitions drive letters before logical partitions.

If you want a feature that manipulates drive letter assignments, it ought to co-operate with the normal components responsible for assigning drive letters, and it shouldn't be a feature for a SCSI disk driver, in my opinion.

.... It seems that you are interested in choosing the drive letter for the boot volume before ever booting the OS. Is that correct?

yes... but since you're saying....

You could potentially partition a disk image as per your option 03 in order to control drive letter assignments before installing the OS. However, my impression was that Windows NT gives primary partitions drive letters before logical partitions.

If you want a feature that manipulates drive letter assignments, it ought to co-operate with the normal components responsible for assigning drive letters, and it shouldn't be a feature for a SCSI disk driver, in my opinion.

now I'm thinking to... create empty x.img with 1 primary partition (label fake) and map it again, and again for 15 times in grub4dos. Ultimately, hd16 is 2GB image (which windows NT setup will assign R:???) while hd17 will be real hard disk+ partitions? (which i can delete from mountedDevices in registry and it re-enumerates after the installation?

map --mem /X.img (hd0)

map --mem /X.img (hd1) 

map --mem /X.img (hd2) 

........ 

 map --mem /X.img (hd14) 

c: = hd0
d: = hd1
e: = hd2
f: = hd3
g: = hd4
h: = hd5
i: = hd6
j: = hd7
k: = hd8
l: = hd9
m: = hd10
n: = hd11
o: = hd12
p: = hd13
q: = hd14
r: = hd15

edit: In future maybe i've to use map --mem /ramdisk.img (hd15) forever.... but will this work in Theory? I know of limitation of 4 Primary partitions in a disk but not sure of any limitation in the number of disks....

now I'm thinking to... create empty x.img with 1 primary partition (label fake) and map it again, and again for 15 times in grub4dos.

Once the drive letters are established the way you want them, leave them intact and don't delete them. It's MBR disk signature, partition offset and partition size which are tied to a drive letter, so you wouldn't need to worry about mapping those G4D disks for subsequent boots.

Unfortunately, you are limited to 8 GRUB4DOS disks. Otherwise, that seems like a great idea to achieve your goal.

Once the drive letters are established the way you want them, leave them intact and don't delete them. It's MBR disk signature, partition offset and partition size which are tied to a drive letter, so you wouldn't need to worry about mapping those G4D disks for subsequent boots.

Unfortunately, you are limited to 8 GRUB4DOS disks. Otherwise, that seems like a great idea to achieve your goal.

8 Disks is a limit? Oh.... So then I can create [1 Disk + 4 Primary partition] given the rule of 4 primary allowed in disk....

hd0,1 = c:
hd0,2 = d:
hd0,3 = e:
hd0,4 = f:
hd1,1 = g:
hd1,2 = h:
hd1,3 = i:
hd1,4 = j:
hd2,1 = k:
hd2,2 = l:
hd2,3 = m:
hd2,4 = n:
hd3,1 = o:
hd3,2 = p:
hd3,3 = q:
HD4 = R:

So the command is like???

map --mem /X.img (hd0,1)

map --mem /X.img (hd0,2) 

...

map --mem /ramdisk.img (hd4)

8 Disks is a limit? Oh.... So then I can create [1 Disk + 4 Primary partition] given the rule of 4 primary allowed in disk....

hd0,1 = c:
hd0,2 = d:
hd0,3 = e:
hd0,4 = f:
hd1,1 = g:
hd1,2 = h:
hd1,3 = i:
hd1,4 = j:
...

NOW you've got it. Seeing as how disks don't get drive letters, but partitions, do.

However, your numbering is wrong.

So the command is like???

map --mem /X.img (hd0,1)
map --mem /X.img (hd0,2)
...
map --mem /ramdisk.img (hd4)

No.

map --mem /4parts.hdd (hd0)

map --mem /4parts.hdd (hd1)

map --mem /4parts.hdd (hd2)

map --mem /3parts.hdd (hd3)

map --mem /ramdisk.hdd (hd4)

Actually, CAREFULLY reading about the way XP assigns letters "by default" could provide a "better" solution even with this (in my simple mind so convoluted to be eligible to being called "perverted" ) idea and within the 8 disks available. (though creating a migrate.inf when installing is still IMHO the most simple and straightforward ):

http://www.msfn.org/...ion/page__st__1
(AND links within)

Hint: there is no actual *need* that the partition inside the .img is a Primary one, you can use a volume inside an extended (correcting the "sectors before" field)


Wonko

Cool and thanks guess its all set (as far as information goes). If only IMG_XP package could allow custom drive letter by calculating existing number of partitions hey there WIMB

Wonko: with your too many links, it gets confusing and when i'm back, i'm lost nevertheless, I'm also going to read that page... but i see no harm in better short cuts

I think WinNTSetup2_x86.exe of JFX has built-in the Checkbox option that you need.

Mount installationdrive as R:

Did you try this option ?

I think WinNTSetup2_x86.exe of JFX has built-in the Checkbox option that you need.

Mount installationdrive as R:

Did you try this option ?

yep loool

Wonko: with your too many links, it gets confusing and when i'm back, i'm lost nevertheless, I'm also going to read that page... but i see no harm in better short cuts

Well, I am trying to point you to information so that you can think about it, learn and decide your way - whatever it is/will be - in an informed way.


The idea is still to induce people to do their homework, and learn from the available info as opposed to theorize "better" ways before knowing what solutions to their problem have already been implemented.


Wonko

I think WinNTSetup2_x86.exe of JFX has built-in the Checkbox option that you need.

Mount installationdrive as R:

Did you try this option ?

IMG_XP_Compact.exe and VHD_W7_Compact.exe use this letter to set MountedDevices registry key used to boot Image file

$DosDev_Value = $DiskSignatur & Binary(Number($PrecedingSectors) * 512) & '00000000'

.....

$letter = StringLeft(RegRead('HKLM\softwaredst\Microsoft\Windows NT\CurrentVersion', 'SystemRoot'), 2)

......

RegWrite('HKLM\systemdst\MountedDevices', '\DosDevices\' & $letter, 'REG_BINARY', $DosDev_Value)

So I expect Image file (IMG for XP or VHD for W7) will boot with drive letter R:

After Install in Image file, did you make use of IMG_XP_Compact.exe or VHD_W7_Compact.exe ?

In Win7 OS you can use WinNTSetup2_x86.exe for direct Install of Win7 in VHD Image file (use mounted Win 7 Setup ISO as Source)
and use option Mount installationdrive as R:

I guess this is about what you are looking for .....



1. Install XP in partition on HDD using WinNTSetup2_x86.exe and use option Mount installationdrive as R:
2. Install WinVBlock Bus driver in XP
3. In other OS run IMG_XP_Compact.exe to make Portable XP Image file of 1 GB
4. Boot from Grub4dos menu - title Port XP-3.img - WinVBlock RAMDISK - 1.0 GB

I could realize it with WinVBlock driver, but with FiraDisk driver then booting hangs just before Desktop would appear ....

Also to create Grub4dos FiraDisk Menu, I needed to update IMG_XP_Compact.exe (please redownload IMG_XP package)

...
I could realize it with WinVBlock driver, but with FiraDisk driver then booting hangs just before Desktop would appear ....

Also to create Grub4dos FiraDisk Menu, I needed to update IMG_XP_Compact.exe (please redownload IMG_XP package)

You're telling me firadisk driver hanged when you added many drives? in my test few days back, winvblock hanged around... generally Time for retests? I was really trying to avoid that a this time...

I can boot with XP from RAMDISK and using simple Grub4dos menu.lst entry as

title Load XP-1.img in RAMDISK and Boot Windows Image 

find --set-root --ignore-floppies /XP-1.img

map --mem /XP-1.img (hd0)

map --hook

root (hd0,0)

chainloader /ntldr

Here is the nice result with XP booting from FiraDisk RAMDISK drive R:

You're telling me firadisk driver hanged when you added many drives?

No. I did not add many drives. It is my default config.
I used WinNTSetup2_x86.exe with option Mount installationdrive as R:

It seems to me that simple menu.lst entry as given is required for booting from FiraDisk RAMDISK

In case of booting XP Image file as FiraDisk FILEDISK, then booting is freezing with running Windows Logo.

I could solve this issue for version 0.0.1.30 by changing the LoadOrder Group to SCSI miniport instead of originally Boot Bus Extender

In older versions e.g. 0.0.1.18 then SCSI miniport was used.
That version was not yet suitable for booting as FiraDisk FILEDISK, but when trying such Group setting in version 0.0.1.30, I had succes.

Presumably the Group was changed in favor for booting Windows 2003

http://reboot.pro/13...986#entry120986

But for XP I think SCSI miniport is the right setting

title Mini XP-6.img - FiraDisk  FILEDISK - 0.8 GB

map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)

map /XP-6.img (hd0)

map --hook

write (99) [FiraDisk]\nStartOptions=disk,vmem=find:/XP-6.img,boot;\n\0

rootnoverify (hd0,0)

chainloader /ntldr

map --status

pause Press any key . . .

 XP_FD_FILE_2.png   874.81KB   24 downloads