Alternative creation of Boot Folders (and AIO maintenance)

[deadbug]

Until now I've used flyakite's method for creating my multi-boot DVD Flyakite's multiboot DVD.

But I've seen several posts that suggest building the boot folder via some method other than running winnt32.exe.

This one http://www.msfn.org/board/index.php?showtopic=58446 (which was pointed out to me in the PM that prompted this post) for example does it. But it seems to be a bare .exe file, and I'd prefer to know what is going on under the hood, so to speak.

I've begun to put together a simple ruby script that parses DOTNET.INF and decides what to copy across and where to copy it to based on what it finds in any [FloppyFiles.*] and [RootBootFiles] sections that it sees. I was also parsing TXTSETUP.INF to determine whether these files are expected to be found compressed in I386 or not, but it seems simpler to just look for the compressed version first and then the uncompressed if the compressed one was not found.

That leaves slightly modifying the copied TXTSETUP.SIF (the SetupSourcePath line needs to be rewritten) and patching SETUPLDR.BIN (it looks like XVI32 will do what I want from a script without human intervention).

Finally, I should also produce a patched boot sector (e.g. PRO1.DAT in flyakite's tutorial iirc) but if XVI32 can patch SETUPLDR.BIN, patching a boot sector should be the same.

So am I missing anything?

Has anyone already done this (especially in an "open" way) and am I missing anything? (I guess I'll know in the next few days when I get some circular tuits ...).

My overall aim (of which this is just one part) is to be able to download an updated RyanVM pack or IE7 pack or DriverPacks (or whatever) and have a simple GUI-driven process that can update my existing MB DVD with the downloaded updates. I can do it all now with just a few clicks, but I need to wait 30-40 minutes between clicks. I would prefer to just take what I did last time (in a .ini file), point it at the new component(s) and have it update the MB DVD in place.

Again, if this is already done, please speak up now. (I expect to have to update it to account for my quirky AIO structure but that's OK as long as it's open enough for me to do that).

[jaclaz]

The link to flyakite guide it's not working, it's this one:

http://flyakite.msfn.org/

If I were you, I would use a bootmanager, like grub4dos, on the AIO and leave bootsectors alone.

Also, you should check the "Install XP from USB" section, there are a few things that may be of help for what you plan:

http://www.msfn.org/board/index.php?showforum=157

It may take some time to go through it...

Out of curiosity, any particualr reason for choosing Ruby?

jaclaz

[deadbug]

The link to flyakite guide it's not working, it's this one:

http://flyakite.msfn.org/

Thanks!

If I were you, I would use a bootmanager, like grub4dos, on the AIO and leave bootsectors alone.

Why? I had a brief look at GRUB4DOS (after being slightly distracted by GNU GRUB!) and I don't see how it avoids bootsectors? It seems to chainload them so they'll still need to exist.

The current AIO can (for example) boot Windows 2000 SP4 for a regular install, boot Windows 2000 SP4 for an unattended install, boot Windows 2000 SP4 for an unattended install and silently install a "few" apps. It can do the same for Windows XP Pro SP3. That's six boot sectors and six boot folders.

I boot the DVD, start the boot menu, pick the OS, choose partitions and it does the rest, taking however long it takes.

Short of not offering so many options (and actually I offer more ...) I don't see how I can cut down on the number of boot sectors and associated boot folders. In fact, having recently integrated DriverPacks, I now find that the initial text mode boot slows down (by a number of minutes) so I want to make that an option too. (I still want DriverPacks so that if I install on an unfamiliar machine it installs as much as possible, but on my machines I want a slimmed down version so I'm not waiting so long).

That's part of the reason I started on this odyssey. If I put together a "build" tool that does what I want but takes out the bulk of the tedium, I can investigate speeding up the process while at the same time integrating the drivers I know I need (and perhaps decompressing them too).

GRUB4DOS looks interesting, and I'm tempted to go and play with it and see if I can get an AIO DVD built that boots with it. But it looks like another tool that does pretty much the same job as ISOLINUX.

Also, you should check the "Install XP from USB" section, there are a few things that may be of help for what you plan:

http://www.msfn.org/board/index.php?showforum=157

It may take some time to go through it...

The immediate plan is just to build a boot folder manually. I already have a working exemplar on my existing AIO-DVD, so I'll definitely know when I've managed to build an adequate one. I'd just like to know whether my approach is sound or whether it'll just be a fluke if I get there. It would also be nice to have some confidence that it will work correctly when Windows XP SP4 comes out :-)

The XP USB stuff might help somewhat (I'll poke through it in the next few days - you never know when some seemingly irrelevant snippet will suddenly prove to be crucial) and I might even want to build an AIO-USB at some point (especially since 8GB ones are now cheap). But I expect that that's really an entirely new project, filled with its own kinds of fun!

Out of curiosity, any particualr reason for choosing Ruby?

Well it's a good deal more powerful than a BAT file :-)

Actually, I was initially going to use AutoIt for this too, but I know Ruby better so I thought it would be quicker to do this part in Ruby. I nearly went with wxRuby for the rest but (as it took too long for me to get "into" it) I now expect to do the rest of the heavy lifting (with or without a GUI) in AutoIt. If it turns out that AutoIt can't cut it, then I suppose I'll be looking to build a GUI using MS tools (always assuming the freebie Visual dev stuff can cut the mustard).

-- deadbug

[jaclaz]

Why? I had a brief look at GRUB4DOS (after being slightly distracted by GNU GRUB!) and I don't see how it avoids bootsectors? It seems to chainload them so they'll still need to exist.

Have a LONGER look at grub4dos.

One of it's features (missing in legacy GRUB and in Syslinux - but partially present in Siblo) is the ability to DIRECTLY chainboot OS system files, besides chainloading bootsectors:

http://diddy.boot-land.net/grub4dos/files/boot.htm

This is a perfectly valid menu entry in grub4dos:

title chainload \PRO1\SETUPLDR.BIN

find --set-root /PRO1/SETUPLDR.BIN

chainloader /PRO1/SETUPLDR.BIN

See?, no hands, no bootsectors.... B)

You can also rename SETUPLDR.BIN to whatever you prefer, etc., etc.

jaclaz

[deadbug]

This is a perfectly valid menu entry in grub4dos:

title chainload \PRO1\SETUPLDR.BIN

find --set-root /PRO1/SETUPLDR.BIN

chainloader /PRO1/SETUPLDR.BIN

See?, no hands, no bootsectors.... B)

You can also rename SETUPLDR.BIN to whatever you prefer, etc., etc.

OK. That saves me one file per boot foler, but I still need the boot folder.

I'll have a play with GRUB4DOS (if there's an arrow-driven text-menu system with radio buttons, I'm sold :-) otherwise I'll have to finish this project before I take on that one!)

So, am I building my boot folder properly ...?

-- deadbug

[jaclaz]

OK. That saves me one file per boot foler, but I still need the boot folder.

Sure, life is tough.

I'll have a play with GRUB4DOS (if there's an arrow-driven text-menu system with radio buttons, I'm sold :-) otherwise I'll have to finish this project before I take on that one!)

I am not sure what you mean by "arrow driven text menu with radio buttons"

Grub4dos has limited "graphical capabilities", though latest versions have gfxmenu enabled, here is screenshot (oldish version, without gfxmenu):

And here one with gfxmenu:

You can use arrows to select an entry and also program hot-keys.

If you want something really nice looking (depending on your graphical capabilities, of course ) you may want to have a look at Aerostudio, which can use grub4dos "under the hood":

http://www.boot-land.net/forums/index.php?showforum=72

http://aerostudio.boot-land.net/

Here you can find a few screenshots on how nice it can be looking:

http://www.damasgate.com/vb/810499-post31.html

jaclaz

[cdob]

@deadbug

Well, I started something at XP SP3 time.

Not finished so far. There are some manual parts still, should be automatic builded in future.

Maybe you like some ideas.

No fancy gui. Just a batch.

And I'm lazy, did choose some requirements:

no space in file or directory names, no strange chars, plain ASCII chars

Back then I choose some conditions:

small foot print at hard disk

less copy files at hard disk

some single CD XP folders: possibility to create a single CD and to create multi boot at request

As files are not copied at build time, iso creation tool has to collect files from different locations and merge them.

Another solution maybe create junction and or hard linkd at build time. This creates final multi boot soltuion at hard disk at build time.

General multi boot was described

http://www.msfn.org/board/index.php?s=&amp...st&p=814566

txtsetup.sif SetupSourcePath and BootPath is used.

That's similiar to flyakite and different.

There are three fixed file names to define basic boot

\I386\NTDETECT.COM

\I386\SETUPLDR.BIN

\I386\TXTSETUP.SIF

Other files are redirected and defined by BootPath and SetupSourcePath

Sed.exe is used to create a multi boot txtsetup.sif.

Mkisofs is used to redirect files.

That's the basic windows multi boot solution.

Bootloader is a difficult decission.

Grub4dos can chainload setupldr.bin. No boot sector file required.

Grub4dos is developed currently.

BCDW can chainload setupldr.bin. No boot sector file required.

In addition BCDW hexedit setupldr.bin in RAM. No hexediting setupldr.bin at build time.

However BCDW isn't developed since 2004. Does fail at some current hardware.

Isolinux is developed currently. Tested at a lot of hardware.

Can chainload setupldr.bin at (USB) hard disk, but not at CD so far.

Hence require a boot sector file.

As for grub4dos and isolinux:

Gsar.exe can be used to hexedit setupldr.bin at build time.

A example, create a multi boot XP PRO CD:

Given XP source files at XP_PRO.

d:\bcd\multi\XP_PRO

Files are at a NTFS partition.

Batches are at D:\Bcd\multi\build.

Binaries are at D:\Bcd\multi\build\bin.

BatchLink.exe

mkisofs.exe

cygwin1.dll

gsar.exe

sed.exe

Integrate BTS driverpacks drivers:

First step: create a second d:\bcd\multi\XP_PRO_BTS

Create hard links instead of copy: mk-link.cmd D:\Bcd\multi\XP_PRO D:\Bcd\multi\XP_PRO_BTS

Integrate BTS driverpacks drivers manually.

D:\Bcd\multi\build\mk-link.cmd

@echo off
setlocal EnableExtensions EnableDelayedExpansion
set path=%~dp0;%~dp0.\bin;%path%


rem Create hard links for XP driver integration

rem BatchLink Utility
rem Copyright © 2000 Mike Woodring
rem [url="http://www.bearcanyon.com"]http://www.bearcanyon.com[/url]

rem ### parameters ####################################################
set Source=%~1

set Destination=%Source%_BTS
if not %2.==. set Destination=%~2
rem ###################################################################


if not exist "%Source%" (
  echo error: source directory %source% not found
  echo. &  echo Syntax: %~nx0 source [destination]
  goto :eof)
if not exist "%~dp0.\bin\BatchLink.exe" (echo error: BatchLink.exe not found &goto :eof)

md "%Destination%"

call :calc_string_length %Source%
set /a new_dir_start=%string_length%+1


echo create hard links at %Destination%

pushd %Destination%
BatchLink.exe %Source% /q
popd

pushd %Source%
for /D /R . %%a in (*) do call :mklink %%a
popd

goto :eof


:mklink
 set Source=%~1
 call :exec set Target=%%Source:~%new_dir_start%%%
 echo %Target%
 pushd "%Destination%"
 md "%Target%"
 cd /d "%Target%"
 BatchLink.exe "%Source%" /q
 popd 
goto :eof


:calc_string_length
set string=%*
set string=%string: =#%
set string_length=-1

echo %string%

for /L %%a in (0,1,255) do ( 
  call :exec set Char=%%string:~%%a,1%%
  if !Char!.==. (set string_length=%%a & goto :eof)
)
goto :eof


:exec
%*
goto :eof

Create a config file: d:\bcd\multi\build\multi01.txt

@echo off
setlocal EnableExtensions EnableDelayedExpansion

REM +=================================================================+
REM | Multi-Boot CD                                                   |
REM |                                                                 |
REM | bootpath solution                                               |
REM |                                                                 |
REM |  based on:  DVD [url="http://flyakite.msfn.org/"]http://flyakite.msfn.org/[/url]                       |
REM |                                                                 |
REM |--- created by cdob ---------------------------------------------|
REM |                                                                 |
REM +--- under construction  ver -272 --------------------------------+

set path=%~dp0;%~dp0.\bin;%path%

set multi_lst=%~dp0multi01.txt
if not %~1.==. set multi_lst=%~1

rem mkisofs sort file
set sort_lst=%~dp0multi_sort.txt

rem mkisofs parameter file
set mkisofs_par=%~dp0mkisofs.par

pushd "%~dp0.."

echo -o multi_bootpath\XP_multi.iso > %mkisofs_par% 

(echo -iso-level 3 -U -D
 echo -force-uppercase
 echo -volid "XP_MULTI"
 echo -b BCDW/loader.bin -hide loader.bin -hide boot.catalog
 echo -no-emul-boot -boot-load-size 4
 echo -duplicates-once
 echo -graft-points -cache-inodes -follow-links
) >> %mkisofs_par%

rem exclude some folders
(echo -x win9xmig 
 echo -x win9xupg
 echo -x winntupg 
 echo -x COMPDATA
) >> %mkisofs_par%

rem add multi_bootpath\root folder
echo multi_bootpath/root >> %mkisofs_par%

if exist multi_bootpath\root\win51* del multi_bootpath\root\win51*

FOR /F "eol=; tokens=1,*" %%a in (%multi_lst%) do call :add_multi %%a %%b

rem fix: replace multi_bootpath\root\win51* files by 0 byte size
for %%a in (multi_bootpath\root\win51*) do (
  echo /%%~nxa=nul: >> %mkisofs_par%
  del %%a
)

echo on
mkisofs.exe @%mkisofs_par%
@echo off
popd

goto :eof =============================================================


:add_multi ============================================================
set boot_4_char=%~1
set source_inst_files=%~2

echo. &echo add: %boot_4_char% %source_inst_files%

if not exist multi_bootpath\%boot_4_char%\I386 md multi_bootpath\%boot_4_char%\I386

rem collect flag files at root. And create empty flag files at %boot_4_char%
for %%a in (%source_inst_files%\win51*) do (
  copy /y %%a multi_bootpath\root >nul 2>&1
  echo /%boot_4_char%/%%~nxa=nul: >> %mkisofs_par%
)

rem add I386 files, remap to new four char name
(echo /%boot_4_char%/I386=multi_bootpath/%boot_4_char%/I386
 echo /%boot_4_char%/I386=%source_inst_files:\=/%/I386
) >> %mkisofs_par%


rem add available $OEM$ OEM folder
for %%a in ($OEM$ OEM) do (
 for %%b in (multi_bootpath\%boot_4_char% %source_inst_files%) do (
  if exist %%b\%%a (
    echo %%b\%%a
    set read_path=%%b\%%a
    echo /%boot_4_char%/%%a/=!read_path:\=/! >> %mkisofs_par%
  )
 )
)

rem patch txtsetup.sif SetupSourcePath: set \XP_INST_%boot_4_char%\
if not exist multi_bootpath\%boot_4_char%\txtsetup.sif (
 sed.exe -e s/"^SetupSourcePath.*=.*$"/"SetupSourcePath = \"\\%boot_4_char%\\\\\"\nBootPath = \\%boot_4_char%\\I386\\ "/g %source_inst_files%\I386\txtsetup.sif> multi_bootpath\%boot_4_char%\TXTSetup.SIF
)

rem add \%boot_4_char%\ files
(echo /%boot_4_char%/TXTSETUP.SIF=multi_bootpath/%boot_4_char%/TXTSetup.SIF
 echo /%boot_4_char%/NTDETECT.COM=%source_inst_files:\=/%/I386/NTDETECT.COM
 echo /%boot_4_char%/SETUPLDR.BIN=%source_inst_files:\=/%/I386/SETUPLDR.BIN
) >> %mkisofs_par%


rem todo dosnet.inf

goto :eof =============================================================

Example creates a mkiosfs.par parameter file

-o multi_bootpath\XP_multi.iso
-iso-level 3 -U -D
-force-uppercase
-volid "XP_MULTI"
-b BCDW/loader.bin -hide loader.bin -hide boot.catalog
-no-emul-boot -boot-load-size 4
-duplicates-once
-graft-points -cache-inodes -follow-links
-x win9xmig 
-x win9xupg
-x winntupg 
-x COMPDATA
multi_bootpath/root 
/XPR1/WIN51IP=nul: 
/XPR1/WIN51IP.SP3=nul: 
/XPR1/I386=multi_bootpath/XPR1/I386
/XPR1/I386=XP_PRO/I386
/XPR1/TXTSETUP.SIF=multi_bootpath/XPR1/TXTSetup.SIF
/XPR1/NTDETECT.COM=XP_PRO/I386/NTDETECT.COM
/XPR1/SETUPLDR.BIN=XP_PRO/I386/SETUPLDR.BIN
/XPR2/WIN51IP=nul: 
/XPR2/WIN51IP.SP3=nul: 
/XPR2/I386=multi_bootpath/XPR2/I386
/XPR2/I386=XP_PRO_BTS/I386
/XPR2/OEM/=XP_PRO_BTS/OEM 
/XPR2/TXTSETUP.SIF=multi_bootpath/XPR2/TXTSetup.SIF
/XPR2/NTDETECT.COM=XP_PRO_BTS/I386/NTDETECT.COM
/XPR2/SETUPLDR.BIN=XP_PRO_BTS/I386/SETUPLDR.BIN
/WIN51IP=nul: 
/WIN51IP.SP3=nul:

XP use flag files win51* by default.

Adjust batch if you use Windows 2000.

As for driverpacks there is antother decision to be taken.

Method 2 use \OEM folder. That's one OEM version for hole CD/DVD.

I prefer OEM at each windows installation \ABCD\OEM. Driverpacks presetup.cmd has to be edited.

[deadbug]

I am not sure what you mean by "arrow driven text menu with radio buttons"

Well I've just found that I don't know how to put a screen shot in here!

I've attached the images instead, maybe that'll actually work!

The DVD boots to an ISOLINUX splash screen (main.jpg).

I hit return to boot the DVD (rather than timing out and booting HD1) and then I get to the screen in install.jpg. I can now select menus with the usual left/right/up/down arrow mechanism until I get to apps.jpg. Here I've got what I want and I hit return. Now it will fire up XP and I'll end up (after manually partitioning) with Windows XP SP3 + updates + apps.

I don't have radio buttons yet, but if I did I'd compact thing somewhat and have a window with [sP0/SP1/SP2/SP3/SPextra] with exactly one selectable at a time and a separate radio button to choose DriverPacks or No DriverPacks. Just a small matter of programming.

-- deadbug

[deadbug]

Back then I choose some conditions:

small foot print at hard disk

less copy files at hard disk

some single CD XP folders: possibility to create a single CD and to create multi boot at request

As for driverpacks there is antother decision to be taken.

Method 2 use \OEM folder. That's one OEM version for hole CD/DVD.

I prefer OEM at each windows installation \ABCD\OEM. Driverpacks presetup.cmd has to be edited.

@cdob

Thanks for posting that - there's plenty to work through! But that's good, plenty of useful ideas.

I've not really played much with hard links under XP so I've yet to work out what the gotchas might be.

I do like the idea though of being able to create various flavours of DVD or CD on demand, so I'll have to look into that.

As for DriverPacks, any reason for prefering \ABCD\OEM to \OEM? I've not really done much with DriverPacks yet other than integrating it into my MB DVD for XP Pro + Home.

-- deadbug

[cdob]

As for DriverPacks, any reason for prefering \ABCD\OEM to \OEM?

\OEM: that's one version for a multi boot DVD.

How to try different driverpacks versions at one DVD?

How to support 2000, XP x86, XP x64, 2003 at one DVD?

\ABCD\OEM allows above examples at one DVD.

Well, driverpacks dosn't support x64 drivers so far, but maybe in future.

[deadbug]

I'm in the process of fiddling with my AIO build process anyway, so I though I might have a go with hard links.

XP won't allow a hard link of a directory (it does have junctions, but I'm not considering those at this stage), which I guess is why you hard link each file individually.

So my initial plan was that I would have a stable source tree with things like \AIO-SRC\SETUP\XP\Pro\SP3.

Then if I decide that I want SP3 on my DVD but with (for example) boopggy's WMP11, then I would hard link all files in that first tree to my final DVD tree under \AIO-DVD\SETUP\XP\Pro\SPX and apply boooggy's slipstreamer to it.

But if I do that, then surely any files that are patched by that slipstreamer become altered in my supposedly stable source tree?

Is there some part of the method I'm missing or is this a feature? Is there any way to create a "copy-on-write" style of hard link?

-- deadbug

[cdob]

But if I do that, then surely any files that are patched by that slipstreamer become altered in my supposedly stable source tree?

Good catch. Yes, that's the danger of hard links.

It depends how a application does change files.

Does it patch a existing file? stable source tree is changed too

Does it create temorarily a new file, delete old file, and rename new file back?

stable source tree is not changed.

That's how hard links works.

Driverpacks base created a new txtsetup.sif.

Source tree txtsetup.sif is different to target tree txtsetup.sif.

Other applicaitons may behave different.

Applicaiton behaviour reports are highly welcome.

Is there some part of the method I'm missing or is this a feature? Is there any way to create a "copy-on-write" style of hard link?

I don't know such a feature. That won't hard links anymore.