Sysprep and Boot.ini

  • Thread starter Thread starter JeffR
  • Start date Start date
J

JeffR

Hi,

I am wondering how to alter the boot.ini in the sysprep.inf. Here is our
situation:

A piece of software (Deepfreeze Enterprise) causes Windows to startup every
time with a "windows did not startup properly" screen. The workaround is to
uncheck the following boxes in Startup and Recovery

"Time to display list of operating systems - 30 seconds"
"Time to display recovery options when needed - 30 seconds"

Our problem is that every time we run sysprep, it puts these check marks
back in. Is there a line we can put in our sysprep.inf that will keep these
boxes UNchecked, or, force the time in the boot.ini to 0 seconds?

Any help would be greatly appreciated, and would keep me from pulling our
all of my hair.

Thanks

Jeff Rosenburg
Bluewater District School Board
Client Services Technician
 
Yuck, spose it's a bandaid work around, but I'd be more inclined to sort
out the problem of why it is happening in the first place. By doing this
you're masking out a source of warnings when something has really gone
wrong, because any real problem that would give you this warning will
now be hidden.

You sure the error isn't just a case of "some services did not startup
correctly"? If it is just find the faulty service and remove it or at
least disable it prior to making your image.
 
Actually the changing the boot.ini setting is the fix from the software
vendor causing the problem, we just needed a way to make it stick after
sysprep. And unfortunatly, the software is crucial to our operations.
Hopefully their next version doesn't have this bug, and everyone will whistle
a happy tune.

Thanks

JeffR
 
Fair enough. First thing I'd be saying to vendor is "that's pretty
piss-poor, hope you guys are planning on getting your act together".
Guessing that there's no fair alternative at a fair price, so you're
stuck with it. Know that feeling.

Guessing the big prob for you is that it needs to be done prior to the
first real bootup as otherwise you're going to hit that menu. Presuming
that the mini-setup all runs fine, and it's not until the final bootup
into windows proper that the problem occurs you should be able to sort
this easily.

Have a look around for info on using commandlines.txt, it basically does
its thing during the mini-setup so you could have a batch file that
copies a replacement boot.ini over at that time, before any real bootup
happens, and that should resolve the problem. Something like this should
do the trick (and here I'm just guessing that boot.ini doesn't come into
play until minisetup has completed, but I could be totally wrong, never
had any probs with it in the past to find out with.. Hmm, also boot.ini
could potentially be created after the phase it processes the
commandline.txt file which would also stuff up this approach, but I
truly dunno, you'd need to try this to see):


* In directory c:\sysprep\i386\$oem$ put a file called cmdlines.txt, and
in that put the following text:

[Commands]
"Fixboot.cmd"


* Also in that directory put a copy of your fixed boot.ini


* Create another file in there called Fixboot.cmd with the following text:

@echo off
copy /Y boot.ini c:\boot.ini


And that should hopefully do the trick. Don't quote me on this, fairly
maggotted after a good night out on the grog, but this looks right to
me, and the reason I call a batch file from commandlines.txt rather than
just throwing the stuff directly in there is cos I think we had problems
when we didn't use that approach, and the @echo off is purely because I
can't remember a time I didn't use that in a batch file except in
testing, so it's all habit more than anything else and probably not
required, but either way here's a possible solution for ya to play
around with.

Shit, to further muddy the waters I seem to remember having nightmares
with pathing from commandlines.txt, we use it to install a couple of
things prior to first boot and it works fine, but I think we needed to
put all the stuff into that directory, cos it wouldn't work from
alternate paths on the image. That being the case it may have a problem
with the copy command, but if that's so there will be ways around that,
alternatively perhaps I'm too drunk and this will just work.

There's probly much better ways, but that's the way I'd probly bodge it.
Let us know if it works (yay), it doesn't work (will see what I can dig
up) or you just don't trust this drunken bastard and didn't bother
trying it (fair enough, don't blame ya at all!)
 
Hunter01 said:
Fair enough. First thing I'd be saying to vendor is "that's pretty
piss-poor, hope you guys are planning on getting your act together".
Guessing that there's no fair alternative at a fair price, so you're
stuck with it. Know that feeling.

Guessing the big prob for you is that it needs to be done prior to the
first real bootup as otherwise you're going to hit that menu. Presuming
that the mini-setup all runs fine, and it's not until the final bootup
into windows proper that the problem occurs you should be able to sort
this easily.

Have a look around for info on using commandlines.txt, it basically does
its thing during the mini-setup so you could have a batch file that
copies a replacement boot.ini over at that time, before any real bootup
happens, and that should resolve the problem. Something like this should
do the trick (and here I'm just guessing that boot.ini doesn't come into
play until minisetup has completed, but I could be totally wrong, never
had any probs with it in the past to find out with.. Hmm, also boot.ini
could potentially be created after the phase it processes the
commandline.txt file which would also stuff up this approach, but I
truly dunno, you'd need to try this to see):


* In directory c:\sysprep\i386\$oem$ put a file called cmdlines.txt, and
in that put the following text:

[Commands]
"Fixboot.cmd"


* Also in that directory put a copy of your fixed boot.ini


* Create another file in there called Fixboot.cmd with the following text:

@echo off
copy /Y boot.ini c:\boot.ini


And that should hopefully do the trick. Don't quote me on this, fairly
maggotted after a good night out on the grog, but this looks right to
me, and the reason I call a batch file from commandlines.txt rather than
just throwing the stuff directly in there is cos I think we had problems
when we didn't use that approach, and the @echo off is purely because I
can't remember a time I didn't use that in a batch file except in
testing, so it's all habit more than anything else and probably not
required, but either way here's a possible solution for ya to play
around with.

Shit, to further muddy the waters I seem to remember having nightmares
with pathing from commandlines.txt, we use it to install a couple of
things prior to first boot and it works fine, but I think we needed to
put all the stuff into that directory, cos it wouldn't work from
alternate paths on the image. That being the case it may have a problem
with the copy command, but if that's so there will be ways around that,
alternatively perhaps I'm too drunk and this will just work.

There's probly much better ways, but that's the way I'd probly bodge it.
Let us know if it works (yay), it doesn't work (will see what I can dig
up) or you just don't trust this drunken bastard and didn't bother
trying it (fair enough, don't blame ya at all!)
Click to expand...


Another thought, if the boot.ini is created during the initial sysprep
process prior to booting up for minisetup just use what ever form of
image explorer you've got with your imaging software and dump the fixed
boot.ini file straight over the top of the existing one within the
image, easiest fix of all. But this and everything above I spose is
entirely dependant on what point the boot.ini is created/modified by
sysprep. Just something else to try, and probly the first thing I'd try
as it's the easiest of the lot and wont require you to re-sysprep your
image, whereas the stuff above will. Actually the stuff above might not,
you could also potentially inject the stuff I mentioned above into the
image too.... Just beware of potential NTFS permission screwups when
injecting files into images, we've had major hassles with that in the
past too...

Shit, I'm babbling... Think it's time to sleep off the grog.
 
How did you actually add that to the registry? Can you post the text
from the registry key export so we can see how you added it? I am a
little confused how to add it as we are experiencing the same issue.

Thanks.
 
Actually the fix ended up taking a bit of a turn since then, but I did
eventually get it solved (I think). Turns out that the fix I posted only
partially fixed the problem. I discovered through a different MS KB article
that the "Windows did not startup properly" error if more related to a system
file called bootstat.dat. Here is the link to the KB article the got me
sniffing in the right direction.

http://support.microsoft.com/default.aspx?scid=kb;en-us;309481&Product=winxp

So in the end, what I ended up doing was adding the following lines to the
sysprep.inf instead of using the registry "runonce". At this point, it
appears to have solved the problem.

[GuiRunOnce]
command1="cmd /c del /A:S %systemroot%\\bootstat.dat"
command2="bootcfg /timeout 0"

The first command deletes the bootstat.dat (the /A:S allows it to delete a
system file) and the second command sets the timeout in the boot.ini to 0.

JeffR
 
JeffR said:
So in the end, what I ended up doing was adding the following lines to the
sysprep.inf instead of using the registry "runonce". At this point, it
appears to have solved the problem.

[GuiRunOnce]
command1="cmd /c del /A:S %systemroot%\\bootstat.dat"
command2="bootcfg /timeout 0"

The first command deletes the bootstat.dat (the /A:S allows it to delete a
system file) and the second command sets the timeout in the boot.ini to 0.
Click to expand...


So it is better!

[SetupData]
OsLoadTimeout=0
Click to expand...
 
Back
Top