BBS水木清华站∶精华区
发信人: reden (鱼 ～ 看流星和她的故事), 信区: Linux
标 题: Linux Remote-Boot mini-HOWTO(5/7)
发信站: BBS 水木清华站 (Sun Oct 18 20:42:39 1998) WWW-POST
4.6 Setting up Windows 95
In previous versions of this document, we used the Microsoft server-based
installation of Windows 95, but it was really too much
pain and not much worth:
It is very, very bogus
Many software package do not support it and their install will fail.
Among them, Microsoft Internet Explorer, OnNet 32,
Novell's Protected-mode client (which is MUCH more secure than Microsoft
Client for Netware).
It cannot be used with the Microsoft Network client over TCP/IP, since
Microsoft provides no real-mode driver for
TCP/IP compatibe with Windows 95. That means, it cannot be used with
Samba
It makes software upgrades almost impossible since every client turned
on will lock many DLLs on the server, and thus
produce sharing violations if you try to upgrade them.
Consequently, we throwed away of this document all the informations and
bug-workaround collected during months (you can still
find them as a HTML document at http://cuiwww.unige.ch/info/pc/remote-boot/win
95old/win95old.html) and turned to our new
disk-based remote-boot concept. Basically, the configuration for Windows 95
is now almost as easy the configuration for DOS.
Setting up a Stand-Alone Client
Setup a regular Windows 95 client, either starting from scratch as explained
in the configuration of a DOS client, starting from the
DOS client and installing over the network (that is what we did). You can
also start with a preconfigured Windows machine, but
you will probably have less knowledge of what stuff is on the hard disk.
Proceed as described above for a DOS client. It is usually NOT necessary to
use EMM386 with Windows 95. If you are using
Windows 95 OSR2 (alias MSWIN 4.1, alias Windows 95 service pack 1, alias
Windows 95 with Internet Explorer), you should
add the following line in the [Options] section of MSDOS.SYS (yes, it is a
text file):
AUTOSCAN=0
This will let Windows know that you do not want ScanDisk to be runned
automatically at boot time.
If you want to reduce network and server load (which will improve your system
performances) while keeping all softwares on the
server, you should consider installing the excellent Shared LAN Cache, from
Measurement Techniques, Inc (see
http://www.lancache.com). This software runs on each client computer, and
caches to the local hard disk every data obtained
from the network. Even MS-Office starts much faster the second time you run
it... You need one license per client computer, but
it is not very expensive, and the firm make special prices for universities
and colleges. The best thing to do is to go to their Web
site and download the free evaluation copy.
Building the Disk Image
Your MrZip script will be named zipwin95.mrz and contain:
showlog
filter -"temp/*"
filter -"*.swp"
fullzip "c:/" "L:/tftpboot/win95.imz"
To build the image, mount the admin volume on drive L:, go to your utils
directory and type the following command:
mrzip -b zipwin95
A few minutes later, you will have a new file if the server /tftpboot
subdirectory called win95.imz, which is a compressed
image of your hard disk. If your compressed image was bigger than 87 MB, it
has probably been splitted in two or more
fragments. These fragments will automatically loaded one after the other when
needed. Note that an image bigger than 87 MB
will usually take More than one minute to uncompress and may irritate your
users. Our Windows 95 image is only 70 MB big,
because most software (except Office and Explorer) completely reside on the
server. Only 45 seconds are needed to uncompress
the image and restore the full disk.
Copy the following batch file to /tftpboot/win95.bpb:
hidelog
setpartitions "bigdos:1024"
setbootpart 1
fullunzip "win95.imz" 1
hidebootprom
hdboot :1
Your remote-boot Windows 95 configuration is ready ! You can now either set
the BOOTP-option-155 to "win95", or type
include "win95.bpb" from within BpBatch to test it.
Adapting the configuration for other Machines
The big difference between Windows 3.1 and Windows 95 is that the later
includes code for Plug-and-play , ie. automatic
detection of your hardware. This not a bad thing in itself, but the trouble
is that it is often too sensible, and that it sometimes fails.
If you try to start another client with exactly the same boot image, you will
probably get several messages during startup telling
that Windows has detected new hardware: a new sound card, a new hard-disk, a
new network card, and even a new mouse...
There can be two reasons for that:
the devices may not use the same ressources (for instance the mouse is
not connected on the same port, or the sound card
is not connected in the same slot - yes, that is detected)
the devices may tell to Windows 95 their personal serial number (for
instance, every Windows 95 differenciate every
network card on the basis of its world-wide unique ethernet address)
The fact that Windows 95 discover that the hardware has changed may not be a
problem if the plug-and-play works as-is, but it
become a problem when the plug-and-play does not work. For instance, Windows
95 plug-and-play for our Logitech PS2/aux
mouse does not work, and result in no mouse at all. To solve such kind of
problems, arrange to have all computers as similar as
possible, or make different images for different hardware. Later, you will
discover that you can simply use the same image and
just have several copies of the registery, that you can copy after having
restoring the disk image but before booting.
The thing you cannot avoid to differ between computers is the network card.
PCI cards usually do not mind, but ISA Plug and
Play do. Bad luck for us, the plug-and-play code for our SMC EtherEZ card
hangs the computer. The only solution is to let
Windows 95 believe that it already know the network card, and that it is not
necessary to trigger plug-and-play. The trick for doing
that is to automatically insert an entry for the network card in Windows 95
registery, before starting it. Note that this trick is not
any more needed with most PCI cards.
Move the autoexec.bat to the server as described above for DOS. Edit it (on
the server) and add the following lines:
rem --- Patch Windows registery in order to avoid plug-and-play detection
regedit /L:c:\windows\system.dat /R:c:\windows\user.dat c:\temp\patch.reg
regedit is a standard Windows 95 program that let you browse the registery if
you start it from within Windows 95, or do
simple operations on the registery if you call it from DOS. Run regedit under
Windows 95, search for your network card,
usually under
HKEY_LOCAL_MACHINE\Enum\ISAPNP
and export the branch using the File menu. This will create a text file, that
you should same as patch.ref in the server
/tftpboot diretory. Edit this file and find out where the card ethernet
address is stored (do that on two different machines and
compare the files if you can't find it by yourself). Replace it by a pettern
in the form ${MACID}. Then add lines to the
win95.bpb script like this:
set macid = "$BOOTP-Client-ID"
patch "patch.ref" "{:1}temp/patch.reg"
(do any necessary string manipulation for setting MACID if it is not exactly
the client Ethernet address). That's all, your clients
should not any more try to autodect the network card.
Once again, this whole trick is not necessary when using PCI network
adapters. Incidentally, we can use the same mechanism for
automatically configuring the hostname, which Windows 95 does not seem to
take into account when configuring through DHCP.
We just add the following line to our patch.ref file:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETSUP]
"ComputerName"="${BOOTP-Host-Name}"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
"HostName"="${BOOTP-Host-Name}"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\ComputerName\Compute
rName]
"ComputerName"="${BOOTP-Host-Name}"
Using this small registery trick, your configuration should normally be
portable for all machines with similar configurations. If you
cannot avoid that Windows detect some hardware as new on one machine, try to
rebuild the disk image from this machine. This
will include the registery configuration specific to this machine into the
image, and hopefully supress the problem.
System Maintenance and Upgrades
If you want later to upgrade software, install bug fixes and security fixes,
proceed as follow:
Remote-boot a client computer to get a fresh install
Make your changes
Redo the disk image
Copy the new image in place of the old one on the server
That means, you can upgrade software on your server-based configuration as if
it were a purely local install.
4.7 Setting up Windows NT
We do not use Windows NT for remote-boot client computers but we have tested
our system to ensure that it work as well. And
it works.
As our utilities currently have no support for NTFS (we neither have the
documentation nor the time to do that, but I would be
happy to help anyone who is interested in doing it), you will have to install
NT on FAT16 (simply do not convert your partitions to
NTFS during the setup).
Copy your win95.bpb boot script to winnt.bpb. Change the setpartitions line
in winnt.bpb to the following:
setpartitions "BIGDOS:512 BIGDOS:512"
Then boot Windows 95 using this script, and install your NT client on drive
C. Do not worry about the second partition for now.
Do not install too much stuff, or you will get a really large and
slow-to-uncompress image. Remove Windows 95 from the disk disk
C, you do not need it in a Windows NT image (the boot menu is handled by the
bootprom, not by NT boot loader).
Reboot your computer in without overwriting the hard disk, ie. do not execute
the winnt script but just
hidebootprom
hdboot
Your NT station should start-up correctly. Make any necessary customization.
Building the Disk Image
The trouble with Windows NT is that direct disk access is prohibed by the
kernel. That means, MrZip will not even be able to
read the boot sectors. The best way to do an image is then to boot Windows 95
and to run MrZip from a DOS window. To do
that, change the winnt.bpb script so that the Windows 95 image is not
restored on the first but on the second partition:
hidelog
setpartitions "BIGDOS:512 BIGDOS:512"
setbootpart 2
fullunzip "win95.imz" 2
hidebootprom
hdboot :2
(if you have any supplementary patch, change the "{:1}" to "{:2}"). Boot with
this script; you should have Windows 95
running, but a new drive D: should be available, with Windows NT inside.
Make your disk image as usual (but on D:, of course), and save it as
winnt.imz on the server /tftpboot directory. Edit
one last time the winnt.bpb script like this:
hidelog
setpartitions "BIGDOS:512 BIGDOS:512"
setbootpart 1
fullunzip "winnt.imz" 1
clean 2
#fullunzip "win95.imz" 2
hidebootprom
hdboot :1
Your Windows NT remote-boot configuration is ready. Of course, if you do not
like to have two partitions, you can setup a single
partition instead. But when you have to rebuild the image, you will have to
setup the second partition again for booting Windows
95.
System Maintenance and Upgrades
If you want later to upgrade software, install bug fixes and security fixes,
proceed as follow:
Remote-boot a client computer to get a fresh install
Make your changes
Edit winnt.bpb: comment the clean and winnt fullunzip, uncomment win95
fullunzip
Redo the disk image
Copy the new image in place of the old one on the server
That's all, folks !
4.8 Troubleshooting
This section lists most frequently encountered problems.
The image download never ends
You are probably using a standard TFTP server, and it cannot handle more
than 65535 packets of 512 bytes (or even 32767
packets for the Solaris server). That is, your image must be fragmented
in pieces of no more than 30 MB (or 15 MB for
Solaris). See under CopyArchive for instructions on fragmenting an
existing image. But you should seriously thing about
using InCom's extended TFTP server, as it is much more efficient (it
uses packets of 1408 bytes instead of 512 bytes).
The archive decompression fails immediately
There are two possibilities. Either the image is really corrupted on the
server (try use MrZip to see if it is the case), or the
file transfer has failed because of TFTP timeout. TFTP timeout occurs
when the network is too heavily loaded (for
instance if you try to download a huge image with more than four clients
at a time). In this case, BpBatch does not retry
indefinitely because it would not help. Shut down a few computers and
retry with no more than four computers (or maybe
even three). If you often need to download images for a lot of
computers, you can try our special Broadcast TFTP server
(see the section dedicated to it).
The computer hangs instead of downloading/unzipping
May be your computer has a bad VESA support. Try giving the -v
command-line argument or setting the VESA variable
to "OFF".
VESA scrolling is broken
We use a VESA 1.1 function for scrolling. If your video adapter does not
support VESA 1.1, forget it. If the scrolling
works for one page, but then produces a strange strippled pattern, do
not worry. This is a known bug, I will fix it as soon as
I have time for it (VESA scrolling is not really essential...)
There is a corrupted file in the cache
When a file in the cache is corrupted by an external program, it is
automatically removed from the cache. When a file in the
cache is not fully written (because the computer is turned off during
the file transfer), it is also automatically removed. But
if the server transmits a corrupted file or if the transfer aborts from
the server side, it is possible that this file stays in the
cache. You can clean-up the cache simply by holding both shift down
while BpBatch access it for the first time.
Alternatively, you can evaluate clean -1 in interactive mode.
The EXIT command does not work in a batch file
This is not a bug. Exit is not a command. There is no exit or quit
command because it does not make any sense to exit from
a boot script without booting. And MrBatch is really the same program as
BpBatch. What you can do instead is calling
HdBoot. This makes sense, and the DOS version will cleanly exit instead
of rebooting. Note that you can exit from the
DOS version at any time by pressing Ctrl-Break. This will restore all
hooked interrupts before leaving.
The Print command does not print
If you try to print something and immediately enter interactive mode,
you may not see your text. This is because your text
was written on the runtime screen and the Interact command has switched
the display to the Log screen. Just put a
GetKey after the print commands and you will see the text output.
MrZip says Malloc failed
MrZip needs a lot of conventional memory to run. If you encounter this
problem, first ensure that you have unloaded the
bootprom either using HideBootprom or using InCom's bputil. If you run
MrZip from bare MS-DOS (not within
Windows 95 DOS box), you should use EMM386 to load the network drivers
high in order to get as much conventional
memory as possible. From a Windows 95 DOS box, there is usually no
problem (as long as you have not left your old 16-bit
stuff in your autoexec.bat when you installed Windows 95).
MrZip aborts while reading directories
This bug has already been fixed once. Get the latest release of MrZip.
If the problem persists, try to build your image with
Trace set to "ON" (and usually PauseLog set to "OFF"); this will let you
discover which file causes the problem. Send
a detailled bug report.
MrZip cannot access some file
MrZip is probably trying to read a locked, open or special file, such as
Windows swap file. Such files should usually not be
included in the image and should be filtered out (using the filter
command). It is also possible that the operating system
is playing you a trick. If MrZip does not tell you what file causes the
problem, try to build your image with Trace set to
"ON" (and usually PauseLog set to "OFF"). You can also try to use direct
disk access (that is, do not refer the source
partition as "C:" or "/" but as "{:1}" or whatever partition it is).
Using direct disk access is usually slower because
we have less buffers than the operating system, but it may be sometimes
more reliable.
Disk images are always reloaded from the server
Disk images are stored in the special cache area and should not be
reloaded if they have not changed on the server.
However, as the cache area always starts after the last used partition,
changing the total size of partitions will move the
location of the cache and thus destroy its content. Another possible
reason for a file disappearing from the cache is that the
previous file has grown more than one-and-an-half times its initial
size. The file would then have been overwritten and need
to be downloaded once again. This should almost never occurs. A third
possible reason is a too small cache area. If the
free space left outside the partitions is less than one-and-an-half
times the sum of all compressed image sizes, only the most
recently used images will be present in the cache and the other will
have to be reloaded on demand.
Red Hat Linux 5.1 does not boot properly
This distribution assumes Linux was booted using lilo and checks for the
BOOT_IMAGE command line argument (in
/etc/rc.d/rc.sysinit). Simply add it in the linuxboot call, or change
your rc.sysinit.
The broadcast TFTP ramdisk hangs (Got in bound state)
Linux dhcp client is a program that dynamically changes the IP address
of the client according to DHCP offers. If the
address is offered forever (infinite lease time), the DHCP client just
set the address and returns (this is what we expect).
However, if the lease time is limited, the DHCP client must remain
loaded and ask for new addresses every few minutes.
And if the DHCP client does not return, MrBatch will never be loaded...
The solution is to give an infinite lease time
(sometimes encoded as -1).
File access hangs under BpBatch, but not under MrBatch
This problem occured on an AMI BIOS dated 94/07/25. We investigated a
little bit, and found no solution. It seems that this
problem is due to a bug in this BIOS (some register or memory location
must be destroyed).
Unzip of a fragmented archive fails (Malloc failed)
This problem was introduced with PXE compatibility, but has now been
fixed. Please get the latest version.
MrBatch and MrZip complain about the terminal under RedHat 5.x
This problem has been fixed in the 9th of August version of
MrBatch/MrZip. There was a problem with a new version of
ncurses which has been released with RedHat 5.1.
"libncurses.so.3.0: cannot open shared object file" under Linux
MrZip has been linked to the version 3.0 of libncurses. You can use
other versions of libncurses only if they are newer than
version 3.0. To use a newer libncurses, all you have to do is to create
a soft link from libncurses.so.3.0 to your
libncurses.so.xx file. With RedHat 5.1, you can use the following
command : cd /usr/lib ; ln -s
libncurses.4.2 libncurses.3.0
MrBatch and MrZip do not start under Linux (file not found)
This problem is the reverse of the previous one. Now that the
distribution is libc6 ready, it cannot be used any more with
libc5. If you encounter this problem, simply upgrade your Linux box
(Well, if we hear too much complaints, we might try to
keep two distributions...).
I can not access other mode than the default 800x600 VESA mode
You should first display the contents of the VESA-Modes variable, to see
if your hardware support the mode you would
like to use. Then, try one of the two ways to select a special VESA mode
∶
InitGraph "mode": Try InitGraph "1024x768", and then run the
graphical primitive you are interested in (e.g
DrawGif).
VESA-Modes: The first field of the VESA-Modes variable is the name
of the default mode. If you change the
VESA-Modes variable, all graphical primitive will use the mode you
specified.
BpBatch prints a "Malloc failed" message when restoring multiple fragments
images
We corrected a bug in the memory allocation functions of BpBatch. You
should make sure that you have a version of
BpBatch which has been released after september the 22nd 1998.
Fullunzip using the Linux version of MrBatch always fails
We corrected this problem in the 09/22/1998 release.
--
白马带著她一步步的回到中原。白马已经老了，只能慢慢的走，
但终是能回到中原的。江南有杨柳、桃花，有燕子、金鱼……
汉人中有的是英俊勇武的少年，倜傥潇洒的少年……但这个美
丽的姑娘就像古高昌国人那样固执:
「那都是很好很好的，可是我偏不喜欢。」
※ 来源:·BBS 水木清华站 bbs.net.tsinghua.edu.cn·[FROM: 202.99.18.67]
BBS水木清华站∶精华区