[kDn]

Another bugfix needed in file mkISO_RAMload_sort.cmd :

Quote

...
echo ./WIN* 9978
echo ./win* 9978
echo ./BOOTFONT.BI? 9978
echo ./%boot_x64%/* 1100
...

Bold - line to insert

FOR %%a in (WIN* bootfont.bi?) do (call :sort_boot %%a)

change to:

rem FOR %%a in (WIN* bootfont.bi?) do (call :sort_boot %%a)

or remove, becouse that line not useful and provide wrong sorting like that:

Quote

.//WIN51 9899
.//WIN51IP 9898
.//WIN51IP.SP3 9897
.//BOOTFONT.BIN 9896

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

[cdob]

Siginet said:

but then the computer just restarts

This indicates: setupdlr.bin dosn't find ntdetect.com.

Siginet said:

using Windows XP PowerPacker

Which bootloader do you use by default? Can you try grub4dos?
Do you hexedit setupldr.bin? i386 --> XPPC

I wonder, does some configurations require root (0xFF) ?
Try

root (0xFF)
chainloader (0xFF)/XPPC/SETUPLDR.BIN

Try the CD image bootloader too

chainloader (0xFF)

@kDn
Thanks for ISOimage.ini corrections. Yes, change this settings.

Correct or false sorting is confusing.
The sort file is one part only. The builded ISO image is importand.

Mentioned function :mk_sort_list_static is not used anymore. This is a reference from last year.
I'll check .//BOOTFONT.BIN again, as far as I remember // is replaced by / internally.

[kDn]

cdob

Quote

Mentioned function :mk_sort_list_static is not used anymore. This is a reference from last year.

I see that, but I say about :mk_sort_list_dynamic function. With original script generated file sort.txt like that:

Quote

...
./WIN* 9978
./win* 9978
...
.//WIN51 9899
.//WIN51IP 9898
.//WIN51IP.SP3 9897
.//BOOTFONT.BIN 9896
...

files WIN51, WIN51IP, WIN51IP.SP3 sorted correct becouse have line ./WIN* 9978, but BOOTFONT.BIN not correct and have too hight LBA in ISO. Check this, please.
FYI: I using mkisofs 2.01.01a65 (i686-pc-cygwin) Copyright © 1993-1997 Eric Youngdale © 1997-2009 Jцrg Schilling.

[Siginet]

cdob, on Oct 5 2009, 04:56 AM, said:

Siginet said:

but then the computer just restarts

This indicates: setupdlr.bin dosn't find ntdetect.com.

Siginet said:

using Windows XP PowerPacker

Which bootloader do you use by default? Can you try grub4dos?
Do you hexedit setupldr.bin? i386 --> XPPC

I wonder, does some configurations require root (0xFF) ?
Try

root (0xFF)
chainloader (0xFF)/XPPC/SETUPLDR.BIN

Try the CD image bootloader too

chainloader (0xFF)

It works when I create a cd/dvd. If I remember correctly powerpacker uses bcdw for the boot menu. It references SETUPLDR.BIN files to launch each os.

The only main difference with powerpacker and the normal method is powerpacker has no need for the XPPC.BIN files on the root of the disk. It launches directly from the setupldr.bin files. Just like grub4dos is. So I can't figure out what may be going wrong. I tried my old SP2 disk and it works fine. But whenever I try a powerpack disk it doesn't.

Could someone else verify if they have the same prob with powerpacker? If it is a bug in powerpacker then I can fix it.

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

[jaclaz]

Siginet, on Oct 5 2009, 07:00 PM, said:

It works when I create a cd/dvd. If I remember correctly powerpacker uses bcdw for the boot menu. It references SETUPLDR.BIN files to launch each os.
The only main difference with powerpacker and the normal method is powerpacker has no need for the XPPC.BIN files on the root of the disk. It launches directly from the setupldr.bin files. Just like grub4dos is. So I can't figure out what may be going wrong. I tried my old SP2 disk and it works fine. But whenever I try a powerpack disk it doesn't.

Could someone else verify if they have the same prob with powerpacker? If it is a bug in powerpacker then I can fix it.

You joking right?

BCDW fixes hardcoded paths in setupldr.bin on-the-fly.

You need to hexedit SETUPLDR.BIN yourself, unless you use \i386 (CD/ISO) or /minint (HD).


jaclaz

This post has been edited by jaclaz: 05 October 2009 - 12:36 PM

[wimb]

Siginet, on Oct 5 2009, 07:00 PM, said:

The only main difference with powerpacker and the normal method is powerpacker has no need for the XPPC.BIN files on the root of the disk. It launches directly from the setupldr.bin files.

I think, there is no SETUPLDR.BIN in folder XPPC
The XPPC.BIN file is a renamed SETUPLDR.BIN located in XPPC folder.
So I think it should be

chainloader (0xFF)/XPPC/XPPC.BIN

[cdob]

kDn, on Oct 5 2009, 09:56 AM, said:

BOOTFONT.BIN not correct and have too hight LBA in ISO.

Thanks for the reminder. Sorry, haven't used bootfont.bin in years myself.
I'm using codepage 850 and won't detect a big difference.

It's a real pleasure do find another 'mkisofs -sort' user.

Attached is a updated version:
status is changed from experimental to very experimental

There is a new function call :patch_sort_iso despide unresolved unresolved grub4dos questions http://www.boot-land...?showtopic=9306
A fake file RAMBOOT.ISO should be patched to a RAM load ISO image.
Third party applications gsar.exe and dd.exe are used.

@Siginet
BCDW is a fine bootloader, because setupldr.bin is loaded to RAM, patched in RAM and executed.
Grub4dos dosn't support this. Patch setupldr.bin before.
I'm using:

gsar.exe -o -si386 -r%boot_4_char% multi_bootpath\%boot_4_char%\SETUPLDR.BIN

Attachment removed, use version from XP_INST_v05.7z at first post.

This post has been edited by cdob: 14 January 2012 - 02:57 PM

[Siginet]

I'm pretty sure powerpacker does patch the files. It's been a long time since I have coded powerpacker. But I remember I had to patch setupldr.bin files. PowerPacker actually uses multiple setupldr.bin files in its boot directories. And it patches them so that each one can use a different winnt.sif file. So basically a setupldr.bin file renamed to xppc.bin could use a winnt.sif file named wxppc.sif and another setupldr.bin file would be named xopc.bin and use wxopc.sif and so on.

You guys may be right though. It could be possible that in the later versions of powerpacker I did not need to patch the setupldr.bin files. But I am almost positive it does. Guess I gotta look into the code.

Edit:
OK... I have confirmed that PowerPacker does not need to patch the Windows XP x86 setupldr.bin file. But it does patch 2003 SP1 setupldr.bin files. But I could not find any information on how to patch Windows XP SP3 setupldr.bin files. So is there a place to patch these files? When I use my XP SP2 setupldr.bin file it does work. But is there a file hack available for SP3 setupldr.bin files? As far as I can find the XP setupldr.bin files only need to have i386 changed to another 4 characters plus winnt.sif changed if you wish to use other answer files. I can just use my SP2 setupldr.bin files for now... but I would like to use SP3 setupldr.bin files. Are you guys using SP3 setupldr.bin files in your tests? If so... I'd like to compair my setupldr.bin files with someone's who is working.

Thanks!

This post has been edited by Siginet: 05 October 2009 - 05:24 PM

[jaclaz]

cdob, on Oct 5 2009, 10:55 PM, said:

Attached is a updated version:
status is changed from experimental to very experimental

VERY good.
Next one may be called PRE-ALPHA or PLANNING.....

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

You guys may be right though. It could be possible that in the later versions of powerpacker I did not need to patch the setupldr.bin files. But I am almost positive it does. Guess I gotta look into the code.

Wouldn't it be easier to check inside the chainloaded loader with a hex editor?

jaclaz

[Siginet]

jaclaz, on Oct 5 2009, 06:22 PM, said:

Wouldn't it be easier to check inside the chainloaded loader with a hex editor?

I did... but my setupldr.bin file is from sp3 which is much different then the one from sp2.

I allready know that i386 is to be changed. Which is also done in powerpacker. What I mean is... is there an area that needs to be specifically patched like is done to 2003 SP1 files. At 0x2060 "74 03"needs to be changed to "EB 1A" on 2k3 sp1 setupldr.bin files. But on my xp sp3 setupldr.bin file it does not need to be patch like this in any way and it works just fine on a cd/dvd. But for some reason does not work using the iso ram boot method used in here. So I have narrowed down it is not an error with powerpacker per say... but if there is a patch for xp sp3 setupldr.bin files that is needed differently then the way I do it in powerpacker I am curious to know it.

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

[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.