[Siginet]

Woops... I can put my foot in my mouth now. I just realized I was using a test version of PowerPacker... and the patching of setupldr.bin was broken. The release that is online for everyone to download is working fine... but the version I was using is broken. Guess that explains why I never released it. Sorry for the trouble everybody. I have it sorted now. I guess it would have been smaart to take jaclaz advise when he said wouldn't it be easy to just check the file in aa hex editor? I was certain that wasn't my problem... but it was. All instances of i386 were not changed to XPPC.

[kDn]

very experimental version works fine

[jaclaz]

Siginet, on Oct 6 2009, 05:12 AM, said:

I guess it would have been smaart to take jaclaz advise when he said wouldn't it be easy to just check the file in aa hex editor? I was certain that wasn't my problem... but it was. All instances of i386 were not changed to XPPC.

You may want to consider that there may be REASONS, why we tried to code the approach in the "common sense advice" on boot-land :

Quote

f4.- DO NOT think you are smarter than the member who is trying to help you, even if generally speaking this might happen, it DOES NOT apply on the specific topic, nothing can upset more a willing helping member that someone that asks for advice and later does not try the given suggestions and/or does another thing. On the contrary, once the suggested steps have been tried and gave no result, your ideas are welcome, in other words we try to troubleshoot in a "logical" way, as in the famous Sherlock Holmes saying "when you have excluded the impossible, whatever remains, however improbable, must be the truth", but we like beforehand to exclude the possible, the common, the probable, and this approach solves problems in a MUCH faster way in a large amount of cases.

jaclaz

[Siginet]

jaclaz, on Oct 6 2009, 03:46 AM, said:

You may want to consider that there may be REASONS, why we tried to code the approach in the "common sense advice" on boot-land

LOL!

Ok... now I was able to make a multiboot ISO that worked. I had a couple of problems though.

1. It seems that after txtmode setup Windows Guimode setup was unable to start because the boot.ini was incorrect.

It was:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(1)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

I had to correct it like this:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

once I changed it then guimode was able to boot successfully.

2. My second issue I think may have something to do with me patching setupldr.bin files to use different winnt.sif files.
Because when guimode setup was running it ran as if there was no unattended answer file.

Here some extra info on how my powerpack install disk is setup:
In the boot folder "XPPC" which is on the root of the disk you will find all of the "boot files" (Just like in the normal method).
In there is the default setupldr.bin patched with "i386" to "XPPC".
Plus a copy of setupldr.bin which is named "XPPC.bin"
the XPPC.bin file is patched with "i386" to "XPPC" plus all instances of "winnt.sif" are patched to "wXPPC.sif"
There is a wXPPC.sif file also in the Boot folder. This is the Unattended Answer file that should be used.
On a regular multiboot disk this works fine. But in the RAM ISO boot method it doesn't seem to work.

Any ideas?

This post has been edited by jaclaz: 06 October 2009 - 12:39 PM

[cdob]

Siginet, on Oct 6 2009, 10:13 AM, said:

1. It seems that after txtmode setup Windows Guimode setup was unable to start because the boot.ini was incorrect.

Windows setup expect target drive at (hd0).

Most BIOS map boot USB drive to (hd0).
And give one internal hard disk, internal hard disk is mapped to (hd1).

Compare first post, use grub4dos map to change mapping:

map (hd0) (hd1)
map (hd1) (hd0)

Quote

In there is the default setupldr.bin patched with "i386" to "XPPC".
Plus a copy of setupldr.bin which is named "XPPC.bin"
the XPPC.bin file is patched with "i386" to "XPPC" plus all instances of "winnt.sif" are patched to "wXPPC.sif"
There is a wXPPC.sif file also in the Boot folder. This is the Unattended Answer file that should be used.

Unattended installation does work too.

I understand, there is a setupldr.bin containing winnt.sif.
And there is a XPPC.bin containing wXPPC.sif
There is a file wXPPC.sif, but no winnt.sif.

Did you call setupldr.bin or XPPC.bin?

Remember wimb's suggestion

Quote

chainloader (0xFF)/XPPC/XPPC.BIN

And remember a a:\winnt.sif (a:\wXPPC.sif) goes first. This is the floppy image in this case.
Did you add a w*.sif to floppy image. No, this is not necessary.


@kDn
Another idea:
Imagine there exist a file \I386\RAMBOOT.TXT

123456\nsome text

123456 refers to RAM load sectors count.
Grub4dos menu.lst dosn't contain sector numbers by default.
Do you have a idea to boot grub4dos, read RAMBOOT.TXT at grub4dos and call

map --mem (0xFE)+123456 (0xFF)

[jaclaz]

The rdisk(1) seems pretty much like the same (z-1) problem solved for USB-multiboot:
http://www.msfn.org/board/boot-install-usb...4-page-240.html
binifix4.cmd
is both in the GUI thingy:
http://www.msfn.org/...30-t120444.html
and in the USB_multiboot:
http://www.msfn.org/...sb-t111406.html

jaclaz

[Siginet]

BTW I just thought of some more important info that may lead to the reason for my incorrect boot.ini.

My computer did have Windows 7 installed before I wiped it out to install XP from the RAM ISO boot method.
Windows 7 creates a hidden Partition and then a second patition where it installs Windows.
I remember when I was at the portion of setup to Partition the drives I noticed that Windows Setup had reccognized the Hidden Partition as the C: drive and the Windows 7 partition as a different letter.
I deleted both partitions and then continued with the XP install.

Maybe this can lead to a clue as to what happened. I will attempt to install windows XP again now that there is only one partition and see if it installs correctlly.

[ilko_t]

Siginet, on Oct 6 2009, 10:38 AM, said:

BTW I just thought of some more important info that may lead to the reason for my incorrect boot.ini.

My computer did have Windows 7 installed before I wiped it out to install XP from the RAM ISO boot method.
Windows 7 creates a hidden Partition and then a second patition where it installs Windows.
I remember when I was at the portion of setup to Partition the drives I noticed that Windows Setup had reccognized the Hidden Partition as the C: drive and the Windows 7 partition as a different letter.
I deleted both partitions and then continued with the XP install.

Maybe this can lead to a clue as to what happened. I will attempt to install windows XP again now that there is only one partition and see if it installs correctlly.

It has nothing to do with partitions. As cdob already pointed out Setup would place boot.ini at hd0 as reported by BIOS. This is the booted disk, the USB one.
Grub4Dos can manipulate that and "swap" them.
In this scenario hd1 will be the next disk according to boot order in BIOS, typically the internal hard disk. In case of two- it should be the one which is higher in BIOS boot order. This is desired behavior, it doesn't matter how many internal disks you have as long as next in boot priority is the desired one.

AFAIK behavior with USB card readers present for example is unknown. This might shift internal disk to hd2 etc.

Now the "buggy" motherboards/BIOSes, which no mather what you do display the USB stick as a FD became useful- USB stick is fd0 and internal disk is hd0, no need of extra "exercises" to get proper boot.ini.

[cdob]

Siginet, on Oct 6 2009, 12:30 PM, said:

I have never needed a winnt.sif file in the ROOT\XPPC directory on a multiboot disk. Could that be different for the new Ram ISO boot method?

I'm using the same ISO file at CD and at RAM ISO method.

However I'm used to SetupSourcePath and BootPath nowadays: XP01\I386\WINNT.SIF
http://www.msfn.org/board/index.php?s=&...st&p=814566
http://www.msfn.org/board/index.php?s=&...st&p=832507
No idea about classic flyakite's tutorial.

Quote

I wonder if I should store any w*.sif files on the floppy img?

Given renamed winnt.sif files, this seems another solution too.

Quote

I even had my DriverPacks stored on the USB instead of the iso file and the DriverPacks were installed perfectly.

Yes, BTS installer support all drives, this includes USB drive.

[Siginet]

The HD swap trick worked:

map (hd0) (hd1)
map (hd1) (hd0)

So now setup boots into guimode as normally.
But this means most of the computers I want to install will be incorrect right?

If so... I have an idea...
Couldn't we have it so that before the iso is mounted there is a 3 second option to input the swap trick? If there is no user interaction it just uses the regular method.

My sencond problem is still not working yet though. I tried putting the w*.sif files on the floppy img but it still doesn't recognize them. I'll try some other stuff and see if I can figure it out and I'll keep you posted.

[kDn]

Maybe this can be usefull:

Quote

timeout 30
default /default

# After execute this commands -> usb-drive always (hd0)
# Nested calls like configfile /menu.lst is ignored
errorcheck off
# Try to supress unneeded messages
debug off
serial --unit=0 --speed=115200
terminal --silent serial
# Clearing mappings...
checkrange 0x00,0x01 read 0x8280 && map --unmap=0:0xff
checkrange 0x00,0x01 read 0x8280 && map --floppies=2
# Shifts (hd) devices (4 hdd by default)
checkrange 0x00,0x01 read 0x8280 && map (hd3) (hd4)
checkrange 0x00,0x01 read 0x8280 && map (hd2) (hd3)
checkrange 0x00,0x01 read 0x8280 && map (hd1) (hd2)
checkrange 0x00,0x01 read 0x8280 && map (hd0) (hd1)
# Maybe USB-ZIP like (fd1) or (fd0) ?
checkrange 0x01 read 0x8280 && map (fd1) (hd0)
checkrange 0x00 read 0x8280 && map (fd0) (hd0)
checkrange 0x00 read 0x8280 && map (fd0) (fd1)
checkrange 0x00 read 0x8280 && map (fd1) (fd0)
# Mapping changes
checkrange 0x00,0x01 read 0x8280 && map --hook
checkrange 0x00,0x01 read 0x8280 && rootnoverify (hd0,0)
# Try to hide unnecessary floppies
ls (fd1)/menu.lst && map --floppies=1
geometry (fd0) || map --floppies=0
# Enable messages output
terminal console
terminal graphics
debug normal
errorcheck on

gfxmenu /boot/_splash/message.gz
configfile /boot/_lst/2menu_en.lst

title
...

cdob, on Oct 6 2009, 09:07 PM, said:

@kDn
Another idea:
Imagine there exist a file \I386\RAMBOOT.TXT

123456\nsome text

123456 refers to RAM load sectors count.
Grub4dos menu.lst dosn't contain sector numbers by default.
Do you have a idea to boot grub4dos, read RAMBOOT.TXT at grub4dos and call

map --mem (0xFE)+123456 (0xFF)

cdob
I dont know good solution, or universal way...
But I try thinking about it

This post has been edited by kDn: 06 October 2009 - 04:03 PM

[Siginet]

You know what... I feel so dumb. The unattended answer files I was using were blank. LOL! So I guess this just hasn't been my week. I've been troubleshooting creating a USB Bootable RAM ISO all week and most of my issues were my own fault. If someone wants to remove my useless posts in this thread it's fine by me. I feel so embarressed that I'd even let the simplest things like this slide by me. LOL! This is what I get for being out of the loop for so long. Guess it's time for me to start coding something again.

[Siginet]

Here's a few questions I have:

1. If I loaded an iso to ram... and then loaded a second iso to RAM again... would existing files be overwritten?

The reason I ask is this.

We know that all different editions of XP Pro use the same exact files... except a small amount of files are different.
If we could load an ISO of XP Pro Corp to RAM... and then load another small ISO on top of it which only contained the different files for XP Pro OEM... would it actually change the ram install into XP Pro OEM?

2. Also... can I mount an ISO onto a HD instead of into RAM?

for instance if we could... then we could create a normal USB XP install stick with XP Pro Corp...
and then mount a small iso with the different files for XP Pro OEM conversion. Which would overwrite the ones on the hd.

3. And my last question...

Is there any way possible to use a cd/dvd... and somehow mount that small iso into RAM in a way that would map those files to trick windows setup into thinking the files in ram where the files on the disk. Since CD/DVD ROM's are not writeable... this would be really cool if we could utalize the memory to make it look like the drive is writeable. I doubt this is possible right now. But it would be something cool to think about for those who have created drivers like this which allows us to do things we normally couldn't do in the past.

[jaclaz]

Siginet, on Oct 7 2009, 01:23 AM, said:

I feel so embarressed that I'd even let the simplest things like this slide by me. LOL!

Well, NO, it doesn't work this way.
What would we have (when old and retired, and forgetful ) to point you to, which reference would we have for "You remember that time you completely messed up...."

Siginet, on Oct 7 2009, 02:27 AM, said:

1. If I loaded an iso to ram... and then loaded a second iso to RAM again... would existing files be overwritten?

NO. separate addresses are used.

Siginet, on Oct 7 2009, 02:27 AM, said:

2. Also... can I mount an ISO onto a HD instead of into RAM?

NO.
You cannot mount an ISO to a HD.
BUT, hopefully, in the future we may be able to load directly (NOT in ram) a HD image (.ima/.img) as HD.
This is a requsted feature that will probably be added to Firadisk or to WinVblock:
http://www.boot-land...?showtopic=8168
http://www.boot-land.net/forums/index.php?...=8168&st=11
http://www.boot-land.net/forums/index.php?...=8804&st=77

For the record there is a "filedisk" driver that should be able to do that as it has no size limits and is a real miniport one:
http://www.boot-land...?showtopic=8468
(it seems like there are no takers for experimenting with this one)

Siginet, on Oct 7 2009, 02:27 AM, said:

for instance if we could... then we could create a normal USB XP install stick with XP Pro Corp...
and then mount a small iso with the different files for XP Pro OEM conversion. Which would overwrite the ones on the hd.

There could be a way through using graft-points (sort of hardlinks) in the making of the .iso.

Siginet, on Oct 7 2009, 02:27 AM, said:

3. And my last question...

Is there any way possible to use a cd/dvd... and somehow mount that small iso into RAM in a way that would map those files to trick windows setup into thinking the files in ram where the files on the disk. Since CD/DVD ROM's are not writeable... this would be really cool if we could utalize the memory to make it look like the drive is writeable. I doubt this is possible right now. But it would be something cool to think about for those who have created drivers like this which allows us to do things we normally couldn't do in the past.

Sure, Firadisk (and grub4dos) can load HD images allright (actually it is what it is intended and used for) but you will have to deal to same "queer" behaviour theat were found (and solved) for the "normal" Install XPfrom USB.

jaclaz

[kDn]

cdob
What you think about that?

title Test generating menu
#(fd1) optional, required at some BIOS
#map --mem /Boot/XP_INST.gz (fd1)
map --mem /Boot/XP_INST.gz (fd0)
ls /Boot/XP_RAM.ISO || find --set-root /Boot/XP_RAM.ISO
map /Boot/XP_RAM.ISO (0xFE)
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
# EMPTY512.LST content 512 spaces
write --offset=0x00 (fd0)/EMPTY512.LST default 0\n######
write --offset=0x10 (fd0)/EMPTY512.LST \ntimeout 0\n\n##
write --offset=0x20 (fd0)/EMPTY512.LST \ntitle TOFF\n###
write --offset=0x30 (fd0)/EMPTY512.LST \nmap --mem (0xFE)					  (0xFF)\n#
write --offset=0x60 (fd0)/EMPTY512.LST \nmap --hook\n###
write --offset=0x70 (fd0)/EMPTY512.LST \nmap --unmap=0xFE\n#####
write --offset=0x88 (fd0)/EMPTY512.LST \nchainloader (0xFF)/I386/SETUPLDR.BIN\n#
# RAMBOOT.TXT content like "+12345667" without quotes
dd if=(0xfe)/RAMBOOT.TXT of=(fd0)/EMPTY512.LST seek=0x44 count=0x0A
configfile (fd0)/EMPTY512.LST

[maanu]

reply to post#70

can you please explain the grub4dos entries in code box plz ?

[kDn]

maanu, on Oct 7 2009, 09:50 PM, said:

reply to post#70

can you please explain the grub4dos entries in code box plz ?

This an idea to construct menu entry on-the-fly... Look to the post #59 or #66

This post has been edited by kDn: 07 October 2009 - 01:21 PM

[cdob]

@kDn
Thanks, I like the idea.
The (fd0)/EMPTY512.LST offers a universal solution.
EMPTY512.LST settings can be adjusted to special needs.
Have to do some tests. There are different approaches to create RAMBOOT.TXT.
Maybe I add a ramload.lst to ISO image too. ramload.lst offer a basic setting with swap hd0 hd1 and without map.
Haven't made a final decision so far.

@Siginet
I don't know a reliable solution with two single ISO files.
Remember grub4dos dd is more a hex editor. You can copy sectors, but file system is not adjusted.
You may mount a second ISO file, and dd oembios.cat to RAM ISO.
Given different oembios.cat file sizes results are interesting. Try and report.

A multi session CD (or fake multi session as growisofs) may get a approach too.
dd file system parts to RAM. However this is rather difficult at two single ISO images.

A multi boot ISO file gives reliable results.

To 3: It should be possible to load a small iso into RAM (textmode boot files, about 10mb), mount the big ISO file to a virtual CD drive and continue installation.
Setup search all CD drives for source files, does work at U3 fake CD drive. No need to add a special search.
I don't know a setupldr.bin textmode driver to mount the big ISO file.

[cdob]

kDn, on Oct 7 2009, 03:08 AM, said:

What you think about that?

I created two approaches finally:
mkISO_RAMload_sort.cmd creates a grub4dos menu RAMboot.lst.
Example:

Quote

#183934 #

timeout 1

title Install Windows - no map
map --mem (0xFE)+183934 (0xFF)
map --hook
chainloader (0xFF)/I386/SETUPLDR.BIN

Recognice the first line, this contain the sector numbers.

The RAMboot.lst is called from main menu.lst.

First approach: configfile, use preconfigured RAMboot.lst.

 
title Loading XP RAM install - swap hd0 hd1 \n loading N sectors configfile RAMBOOT.LST
ls /Inst/XP_RAM.ISO || find --set-root /Inst/XP_RAM.ISO
map --mem /Inst/XP_INST.IMA (fd0)
map /Inst/XP_RAM.ISO (0xFE)
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
map --unmap=0xFE
configfile (0xFE)/I386/RAMBOOT.LST

title Loading XP RAM install - no map hdN \n loading N sectors configfile RAMBOOT.LST
ls /Inst/XP_RAM.ISO || find --set-root /Inst/XP_RAM.ISO
map --mem /Inst/XP_INST.IMA (fd0)
map /Inst/XP_RAM.ISO (0xFE)
map --hook
map --unmap=0xFE
configfile (0xFE)/I386/RAMBOOT.LST 

Second approach: universal solution, read sectors from RAMboot.lst

 
title Loading XP RAM install - no map hdN \n loading N sectors from RAMBOOT.LST
ls /Inst/XP_RAM.ISO || find --set-root /Inst/XP_RAM.ISO
map --mem /Inst/XP_INST.IMA (fd0)
#optional, (fd1) required at some BIOS
#map --mem /Inst/XP_INST.IMA (fd1)
map /Inst/XP_RAM.ISO (0xFE)
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
#kDn [url="http://www.msfn.org/board/index.php?s=&showtopic=137714&view=findpost&p=886626"]http://www.msfn.org/board/index.php?s=&...st&p=886626[/url]
# EMPTY512.LST content 512 spaces
write --offset=0x00 (fd0)/setup/EMPTY512.LST default 0\n
write --offset=0x10 (fd0)/setup/EMPTY512.LST \ntimeout 0\n\n
write --offset=0x20 (fd0)/setup/EMPTY512.LST \ntitle RAM load\n
write --offset=0x30 (fd0)/setup/EMPTY512.LST \nmap --mem (0xFE)+        (0xFF)\n
write --offset=0x52 (fd0)/setup/EMPTY512.LST \nmap --hook\n
write --offset=0x60 (fd0)/setup/EMPTY512.LST \nmap --unmap=0xFE\n
write --offset=0x72 (fd0)/setup/EMPTY512.LST \nchainloader (0xFF)/I386/SETUPLDR.BIN\n
# RAMBOOT.* content like "#123456" without quotes
dd if=(0xfe)/I386/RAMBOOT.LST of=(fd0)/setup/EMPTY512.LST skip=1 seek=0x42 bs=1 count=0x07
#cat (fd0)/setup/EMPTY512.LST
configfile (fd0)/setup/EMPTY512.LST 

EMPTY512.LST is included in XP_INST_v04.7z, attached to first post.

[kDn]

cdob
All works pretty good. Thanks a lot for yours work.