After sitting through several tedious installs, and Stewart Smith's tedious lecture on Debian installation, I have been thinking about a different way to get debian on someone's computer.
This method has a number of advantages, the two biggest being speed (I've got a machine up and running in 20 minutes, running everything the latest unstable offers - kde, gnome-2.2, galeon, circle, gimp-1.3, you name it!) and avoiding the endless maze of configuration options (all alike) each novice gets asked at start time.
This really only applies to desktops, and I've only written it for IDE based systems, although SCSI should work the same. The technique works fine on ppc based machines (the tricky part, fixing up the boot parms is made much simpler with Apple's wonderful use of OpenFirmware).
The idea is to copy all the debian state across from a known working machine. To do this we need a machine that is set up with a good debian installation, and preferably one that hasn't been exposed to the internet to minimise chance of infection with pathogenic rootkits.
I am going to refer to the two machines as dumbledore and grainger1. dumbledore is the source machine, grainger aspires to be like dumbledore.
Put the disk intended for grainger to boot from into dumbledore. It might be faster to make sure that the partitions on dumbledore that contain the base system (/, /usr, /var, /etc..) are on the other controller if you have a choice.
It depends on what disk you have - in my test case I had a blank 2.1GB disk proudly presented to the owner of dumbledore and grainger (mds) and about 20GB disk on dumbledore, 2GB of which appeared to be system files.
Clearly I was not going to get everything on there. However,
because dumbledore is an experimental system and has been
'dist-upgrade'd happily for probably a year, it probably has an excess
of .debs in /var/cache/apt/archive. Sure enough, there
were 550MB of the critters. Now I could just use apt-get
clean, but that would affect dumbledore unnecessarily.
Instead, I'm just going to not copy any files of the form
*.deb
Firstly, I partitioned up /dev/hdb, grainger's main disk, in this
case I creates a small 10MB file at the start, just because in the
past accidents have occured in this range, and it can be useful for
some machines that have crappy bioses (you put the bootstrap code
there where it can be reached by retarded bioses that can only index
640bytes, or whatever). The rest of the disk is one huge ext3
filesystem (create with mke2fs /dev/hdb2 followed by
tune2fs -j /dev/hdb2)
Now in this case I intend to combine all the separate partitions into a single partition, as this is better in tight spaces. Mount grainger's root into target and copy with:
rsync -ax / /target
-a means archive quality (exactly copys things like
hard links and device files), and -x means only copy
things on that disk. In my case I wanted all the usr and var and so
on partitions, so I followed with:
rsync -ax /usr/ /target/usr/ rsync -ax --exclude="*.deb" /var/ /target/var/
The exclude line obviously prevents rsync from copying the large pile of debs. Read the rsync manual and test things with -vn to confirm you got it right first.There's a good bit near the end on how to include and exclude things.
You can now 'log in' to grainger's system using the chroot command:
chroot /target
this means you are now running as if you had booted grainger's machine. Try a few commands - if things fail the most likely explaination is you forgot to copy something. Also, check the free disk space(df). In my case I got the trailing /s wrong (been using rsync since 98, and I still get it wrong sometimes!) and I had had /usr/usr by mistake.
At this point grainger's disk is an exact copy of dumbledore's. There are a few spots which we need to update if things about the system have changed. In particular, we need to make sure that /etc/fstab accurately reflects not the state the system is in currently (which is will, because it was copied from dumbledore, whose /etc/fstab is managed by the OS) but that which it will be in when the system is run on grainger.
For example, dumbledore's /etc/fstab is:
# /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> /dev/hda5 / xfs defaults 0 0 /dev/hda11 none swap sw 0 0 proc /proc proc defaults 0 0 /dev/fd0 /floppy auto user,noauto 0 0 /dev/cdrom /cdrom iso9660 ro,user,noauto 0 0 /dev/hda6 /var xfs defaults 0 0 /dev/hda7 /home xfs defaults 0 0 /dev/hda8 /usr xfs defaults 0 0 /dev/hda9 /usr/src xfs defaults 0 0 /dev/hda10 /mnt/astro xfs defaults 0 0
I changed the file system table to:
dumbledore:~# cat /etc/fstab # /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> /dev/hda2 / xfs defaults 0 0 proc /proc proc defaults 0 0 /dev/fd0 /floppy auto user,noauto 0 0 /dev/cdrom /cdrom iso9660 ro,user,noauto 0 0
dumbledore:~# cat /target/etc/mtab /dev/hda2 / xfs rw 0 0 proc /proc proc rw 0 0 devpts /dev/pts devpts rw,gid=5,mode=620 0 0 usbdevfs /proc/bus/usb usbdevfs rw 0 0
If we simply ran lilo at this point (inside the chroot
environment), then lilo would put the boot information at the begining
of /dev/hda, which is correct for the existing situation,
but useless for booting grainger. What we do is run lilo, but tell it
that the place that the boot loader is to be stored is /dev/hdb:
dumbledore:~# chroot /target # you probably already have done this - in my case I had to try several things to make it work :-( dumbledore:~# lilo -b /dev/hdb
Obviously you need to make sure that
/target/etc/lilo.conf is set correctly.
At this point it is a good test to swap the master and slave over and see if the system still boots. To quote mds:
[mds >> njh] its
bootttinnnngggg 04:54 PM
Needless to say we had got the system up and running in less that 1 hour, and he took it home a happy person indeed. I did the entire thing remotely through ssh.
1Named for a (the?) famous Australian Composer who learnt a lot by copying english folk tunes