| From a Second Machine With a Micro Linux On a Floppy
Because of their small or non-existent footprint, micro-Linuxes are
especially suited to run on laptops, particularly if you use a
company-provided laptop running Windows9x/NT. Or for installation
purposes using another non Linux machine. There are several
micro Linux distributions out there that boot from
one or two floppies and run off a ramdisk. See appendix A for a listing
of distributions.
I tried the following with muLinux ( available at
muLinux
) to clone my HP OmniBook 800 to a COMPAQ Armada 1592DT.
Thanks to Michele Andreoli, maintainer of muLinux for his support.
Since muLinux doesn't support
PCMCIA yet, you may use TomsRtBt
instead. In turn TomsRtBt doesn't support
PPP but provides slip.
Note: Since version 7.0 muLinux
provides an Add-On with PCMCIA support.
I have described how to copy an already existing partition, but it might
be also possible to achieve a customized installation. Note: Usually you
would try to achieve an installation via NFS, which is supported by many
distributions. Or if your sources are not at a Linux machine you might
try the SMB protocol with SAMBA, which is also supported by
muLinux .
You need two machines equipped with Linux. With the laptop
(client/destination) on which you want to install Linux use the muLinux
floppy. The other machine (server/source) may be a usual Linux box or
also using muLinux. Though its low transfer rate I use a serial null
modem cable because its cheap. You may apply the appropriate method
using a PCMCIA network card and a crossover network
cable or a HUB, or a parallel "null modem" cable and PLIP. As the basic
protocol I used PPP, but you may also use SLIP. For the data-transfer I
used nc. Note: this is an abbrevation for
netcat, some distributions use this as the program
name. You may use ftp, tftp,
rsh, ssh, dd,
rcp, kermit,
NFS, SMB and other programs
instead.
Basic requirements are:
A good knowledge about using Linux. You have to know exactly what you
are doing, if not you might end destroying former installations.
A nullmodem serial cable.
At your source machine issue the following commands
(attention: IP address, port number, partition and tty are just
examples!):
Edit /etc/ppp/options, it should contain only:
/dev/ttyS0
115200
passive
With muLinux versions 3.x you may even use the convenient command
setup -f ppp .
Start PPP: pppd .
Configure the PPP network device: ifconfig ppp0 192.168.0.1 .
Add the default route: route add default gw 192.168.0.1 .
Check the network connection: ping 192.168.0.2,
though the destination machine isn't up yet.
Start the transfer from another console, remember
<LEFT-ALT><Fx>:
cat /dev/hda2 | gzip -c | nc -l -p 5555 .
After the transfer (there are no more harddisk writings) stop the ping:
killall ping .
At the destination machine issue:
Edit /etc/ppp/options, it should contain only:
/dev/ttyS0
115200
passive
With muLinux versions >= 3.x you may even use the convenient command
setup -f ppp .
Start PPP: pppd .
Configure the PPP network device:
ifconfig ppp0 192.168.0.2 .
Add the default route:
route add default gw 192.168.0.2 .
Check the network connection, by pinging to the source machine:
ping 192.168.0.1 .
Change to another console and get the data from the server: nc
192.168.0.1 5555 | gzip -dc >/dev/hda4 .
400 MB may take app. 6 hours, but YMMV.
Stop the transfer, when it is finished with:
<CTL><C> . This can probably be avoided
(but I didn't test it) by adding a timeout of 3 seconds using the
-w 3 parameter for nc at the
destination machine nc -w 3 192.168.0.1 5555 | gzip -dc
>/dev/hda4
After the transfer is completed, stop the ping: killall ping .
Configuration of the Destination Machine after the Transfer
Edit /etc/fstab .
Edit /etc/lilo.conf and
/etc/lilo.msg and start lilo .
Set the new root device to the kernel: rdev image root_device .
You may use bzip2 the same way as gzip (untested).
Since rshd, sshd,
ftpd daemons are not available with muLinux you have
to build your own daemon with nc also known as
netcat, as described above.
I had to set up both PPP sides very quick or the connection broke, I
don't know why.
Speed optimization has to be done, asyncmap 0 or
local?
I checked this only with a destination partition greater than the source
partition. Please check dd instead of
cat therefore.
Or do the following (untested): At the destination machine
cd into the root directory / and
do nc -l -p 5555 | bzip2 -dc | tar xvf -. At the
source machine cd into the root directory
/ and do
tar cvf - . | bzip2 | nc -w 3 192.168.0.2 5555.
This should shorten the time needed for
the operation, too. Because only the allocated blocks need to be
transfered.
Don't mount the destination partition.
|