Jump to content

A plea for help, Windows 7 32/64 bit AIO iso


Recommended Posts


@RickRollNW

I am not sure to understand your last report. :unsure:

If I get it right you have discovered that the actual "base" .iso is "botched"? (it doesn't work also on DVD?)

Can you try with another source (possibly, in order to replicate, a SP0 one)?

jaclaz

Link to comment
Share on other sites

@RickRollNW

I am not sure to understand your last report. :unsure:

If I get it right you have discovered that the actual "base" .iso is "botched"? (it doesn't work also on DVD?)

Can you try with another source (possibly, in order to replicate, a SP0 one)?

jaclaz

The method behind it is botched. I burned the .iso in question to a DVD to test if it really worked as advertised. I booted from it in a computer. select the "x64 Recovery Mode" option, clicked Install (because that's my goal, to get a functioning 64-bit bootloader that actually manages to install) and it prompted me with the same missing CD/DVD driver error. Being that it's a DVD I can probably go into a VM and take snapshots if necessary.

In terms of source, I created two .iso's straight from OEM copies of Windows, the April batch. That's as untainted as possible, but if need be I can attempt again with other sources. So, my question is, what does a 64-bit dvd itself have that allows it to boot and load drivers correctly, that the bootloader we've made in this .iso not have?

Link to comment
Share on other sites

In terms of source, I created two .iso's straight from OEM copies of Windows, the April batch. That's as untainted as possible, but if need be I can attempt again with other sources. So, my question is, what does a 64-bit dvd itself have that allows it to boot and load drivers correctly, that the bootloader we've made in this .iso not have?

I cannot say specifically, but it is not the first time that something that worked allright with a given "level" becomes non-working after a SP (or some particular update) is applied.

As an example we had this issue with fujianbc fast installer:

http://reboot.pro/10126/

http://reboot.pro/10126/page__st__250#entry135150

http://reboot.pro/14186/

And, as another example, this issue with BOOTMGR and ramdisk entries:

http://reboot.pro/index.php?showtopic=11442

So, as already said, your next step should be to try replicating (hopefully successfully) what has been already tested (to the T, and this means WITHOUT *any* change of *any* type) with an older source, and from it check the differences when you re-do, still without any change with the "new" source.

If you insist of introducing a change, any one, even a teeny tiny one, there is simply no way to find what exactly the issue is.

What I always recommend is - when attempting to replicate a tutorial like the one linked to - to (temporarily) forget everything you know or learned from other sources and simply do what is written, if something is not clear, do not "invent" a way to overcome the difficulty, stop and ask for clarifications instead.

The primary quality of a tutorial is that it is (or should be) replicable exactly as it is.

Please also note how Steve6375 posted a couple of questions to which you have yet to reply :whistle: .

Generally speaking questons and advice are posted in order to actually try and help you, and it would be nice if you could reply/comply to them :).

jaclaz

Link to comment
Share on other sites

I cannot say specifically, but it is not the first time that something that worked allright with a given "level" becomes non-working after a SP (or some particular update) is applied.

As an example we had this issue with fujianbc fast installer:

http://reboot.pro/10126/

http://reboot.pro/10126/page__st__250#entry135150

http://reboot.pro/14186/

And, as another example, this issue with BOOTMGR and ramdisk entries:

http://reboot.pro/index.php?showtopic=11442

So, as already said, your next step should be to try replicating (hopefully successfully) what has been already tested (to the T, and this means WITHOUT *any* change of *any* type) with an older source, and from it check the differences when you re-do, still without any change with the "new" source.

If you insist of introducing a change, any one, even a teeny tiny one, there is simply no way to find what exactly the issue is.

What I always recommend is - when attempting to replicate a tutorial like the one linked to - to (temporarily) forget everything you know or learned from other sources and simply do what is written, if something is not clear, do not "invent" a way to overcome the difficulty, stop and ask for clarifications instead.

The primary quality of a tutorial is that it is (or should be) replicable exactly as it is.

I am in the process of acquiring non-SP1 images to attempt this again. I will follow everything to the letter, no changes.

Please also note how Steve6375 posted a couple of questions to which you have yet to reply :whistle: .

Generally speaking questons and advice are posted in order to actually try and help you, and it would be nice if you could reply/comply to them :).

I had only seen one question from him, and I thought I'd answered it, but apparently I missed the second half.

Not to sure what is going wrong but this menu makes bootmgr load BC2 not BCD. I can't see any mention of making a BC2 in your posts?

title Windows 64-bit OS Install Menu (bc2)\nIf you want to install a 64-bit OS
map --mem /bootmgr (rd)
write --offset=0x105E (rd)+1 \xEB\x08
write --offset=0x54696 (rd)+1 2
chainloader (rd)+1
root ()

Once you are booted to WInPE, can you detect whether you have booted to a 32-bit OS or a 64-bit OS (look at SET variables?).

So as to be more clear, since it didn't 'click' you were the Steve in question, apologies.

title Windows 32-bit OS Install Menu (bc1)
map --mem /bootmgr (rd)
write --offset=0x105E (rd)+1 \xEB\x08
### write unicode BC1
write --offset=0x54735 (rd)+1 1
chainloader (rd)+1
root ()

title Windows 64-bit OS Install Menu (bc2)
map --mem /bootmgr (rd)
write --offset=0x105E (rd)+1 \xEB\x08
### write unicode BC2
write --offset=0x54735 (rd)+1 2
chainloader (rd)+1
root ()

That was taken exactly from the WinISO tutorial, and edited for the SP1 bootmgr, as also laid out in the tutorial. It covered the creation and implementation of the bc1 and bc2 files.

In regards to the second half of your question, I don't know how to check, if you could inform me as to how I will give you know the results.

Link to comment
Share on other sites

In regards to the second half of your question, I don't know how to check, if you could inform me as to how I will give you know the results.

I presume it is "SHIFT+F10" -> get a command prompt

Type:

SET PROG

[ENTER]

You should get the values of

%PROGRAMDATA% %SystemDrive%\ProgramData

%PROGRAMFILES% %SystemDrive%\Program Files

%PROGRAMFILES(X86)% %SystemDrive%\Program Files (x86) (only in 64-bit version)

http://en.wikipedia.org/wiki/Environment_variable

http://ss64.com/nt/syntax-variables.html

or possibly running reg.exe:

http://support.microsoft.com/kb/556009/en-us

BTW NOT on the suggested:

HKLM\SYSTEM\CurrentCongtrolSet\Control\Session Manager\Envirornment.

;)

More:

http://superuser.com/questions/68452/detect-windows-server-version-32-64-bit-in-cli

I don't think there is WMI available in the PE setup :unsure:, but maybe this other way is handy:

http://social.technet.microsoft.com/Forums/nl/ITCG/thread/8e38d98e-e67f-429c-a98f-da34346f1480

more:

http://superuser.com/questions/321988/how-do-i-determine-if-my-windows-is-32-bit-or-64-bit-using-a-command

jaclaz

Link to comment
Share on other sites

Type:

SET PROG

[ENTER]

You should get the values of

%PROGRAMDATA% %SystemDrive%\ProgramData

%PROGRAMFILES% %SystemDrive%\Program Files

%PROGRAMFILES(X86)% %SystemDrive%\Program Files (x86) (only in 64-bit version)

http://en.wikipedia.org/wiki/Environment_variable

http://ss64.com/nt/syntax-variables.html

or possibly running reg.exe:

http://support.microsoft.com/kb/556009/en-us

BTW NOT on the suggested:

HKLM\SYSTEM\CurrentCongtrolSet\Control\Session Manager\Envirornment.

;)

More:

http://superuser.com/questions/68452/detect-windows-server-version-32-64-bit-in-cli

I don't think there is WMI available in the PE setup :unsure:, but maybe this other way is handy:

http://social.technet.microsoft.com/Forums/nl/ITCG/thread/8e38d98e-e67f-429c-a98f-da34346f1480

more:

http://superuser.com/questions/321988/how-do-i-determine-if-my-windows-is-32-bit-or-64-bit-using-a-command

jaclaz

Apologies for the late reply, had a busy weekend. I ran the x64 recovery mode and did the following, and got these results.

X:\Sources>set prog
ProgramData=X:\ProgramData
ProgramFiles=X:\Program Files
ProgramFiles(x86)=X:\Program Files (x86)
ProgramW6432=X:\Program Files

When running in 32-bit, these were the results.

X:\Sources>set prog
ProgramData=X:\ProgramData
ProgramFiles=X:\Program Files

I didn't see you mention anything of a fourth entry, so, that threw me off a little. Downloaded and compiled a non-sp1 image last night, going to test it today and post the results when I can.

Edited by RickRollNW
Link to comment
Share on other sites

I didn't see you mention anything of a fourth entry, so, that threw me off a little.

Yes, my bad, the suggestion was "generic" about 32/64, Windows 7 64 bit has the ProgramW6432 variable added allright (XP and Vista :ph34r: have it not):

http://msdn.microsoft.com/en-us/library/windows/desktop/aa384274(v=vs.85).aspx

Downloaded and compiled a non-sp1 image last night, going to test it today and post the results when I can.

Good, let's see what happens.

jaclaz

Link to comment
Share on other sites

My attempts resulted in failure once more gentlemen.

I compiled non-SP1 images following the guideline posted earlier with zero deviation. My first attempt was through my standard firadisk map, resulted in failure.

My second was to use the winiso tutorial method seen here: http://www.rmprepusb.com/tutorials/winiso

My menu.lst contained the following:

title Windows 32-bit OS Install Menu (bc1)
map --mem /BOOTMGR (rd)
write --offset=0x105E (rd)+1 \xEB\x08
write --offset=0x54696 (rd)+1 1
chainloader (rd)+1
root ()

title Windows 64-bit OS Install Menu (bc2)
map --mem /BOOTMGR (rd)
write --offset=0x105E (rd)+1 \xEB\x08
write --offset=0x54696 (rd)+1 2
chainloader (rd)+1
root ()

My RunISO's contained the following:

TITLE WINDOWS 32-BIT OS INSTALL
@echo off
cls
echo.
echo.
echo A = Win 7 SP1 64-bit Enterprise
echo B = Win 7 SP1 64-bit Starter\Home Premium\Professional\Ultimate

REM add more here




SET /P ANS="Which ISO do you want? : "




IF /I "%ANS%"=="A" SET MYISO=\ISO\en_windows_7_enterprise_with_sp1_x64_dvd_620201.iso
IF /I "%ANS%"=="B" SET MYISO=\ISO\7_AIO.iso


call \imdisk\MountDrive.cmd %MYISO%

TITLE WINDOWS 32-BIT OS INSTALL
@echo off
cls
echo.
echo.
echo A = Win 7 SP1 32-bit Enterprise
echo B = Win 7 SP1 32-bit Starter\Home Premium\Professional\Ultimate

REM add more here




SET /P ANS="Which ISO do you want? : "




IF /I "%ANS%"=="A" SET MYISO=\ISO\en_windows_7_enterprise_with_sp1_x32_dvd_620201.iso
IF /I "%ANS%"=="B" SET MYISO=\ISO\7_AIO.iso


call \imdisk\MountDrive.cmd %MYISO%

(Take note I didn't even edit the 32-Bit install title error in the 64-bit .cmd)

The firadisk map prompted me with a missing cd/dvd driver error (after loading x64 Recovery Mode and trying to install, standard setup still works but I ran the set prog in the command, and it returned with a 64-bit loadout. The Winiso map prompted me with the "The subsystem required to support the image type is not present." error. I also ran set prog there, and it returned 64-bit lines. Is it a signature in the iso/disc itself that cannot be overcome? I made absoloutely no deviations this time and it's still not working, even with a non-SP1 image.

Link to comment
Share on other sites

RickRollNW, I am really not qualified to reply to your problem, but have seen the CD/DVD driver missing message in another thread. This says simply that it is not a missing CD/DVD driver but a driver needed to locate an HDD to install Windows. It is just another example of bad MS Windows messaging. I was also curious what format of disk you are attempting to use - GPT or MBR? Will this affect your results? Enjoy, John.

Link to comment
Share on other sites

The Winiso map prompted me with the "The subsystem required to support the image type is not present." error. I also ran set prog there, and it returned 64-bit lines. Is it a signature in the iso/disc itself that cannot be overcome? I made absoloutely no deviations this time and it's still not working, even with a non-SP1 image.

But it is a different error.

It "sounds" like you have not the "right" version of IMDISK installed or that *somwhow* the install fails :unsure:

Can you try to run manually the mountdrive.cmd:

Echo Mounting %1

pushd \ImDisk

call setupimdisk

call setupcdrom %1 > x:\setup.log

find /I "Created device" x:\setup.log > x:\t.log

REM get line 3 item 4 (drive letter)

FOR /F "skip=2 tokens=4 delims= " %%A IN (x:\t.log) DO SET ISODRIVE=%%A

%ISODRIVE%

SETUP.EXE

and/or the SetupImDisk.CMD:

rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 132 .\imdisk.inf

and/or the SetupCDROM.CMD:

Set fullname=%~1
imdisk -a -f "%fullname%" -m #:

to understand which command actually produces the error message: "The subsystem required to support the image type is not present."?

jaclaz

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...