An experiment in collective intelligence. Stupidity. Whatever.
Debian GNU/Linux offers a number of installation options. These are well documented in the Debian Installation Instructions. Instructions for a remote Debian chroot install are available in HOWTO - Install Debian Onto a Remote Linux System.
If you're new to Debian and are looking for a standard installation process, please turn there. The material here is meant largely as a supplement to Chapter 5 Methods for Installing Debian. If you're looking for an easy install, your best bet is to buy, borrow, beg, steal, or download a set of installation disks. Quoting the Installing Debian GNU/Linux 2.2 manual:
Get a set of Debian GNU/Linux CDs. Boot off them if you can.
The instructions here have been largely incorporated into Installing Debian GNU/Linux 3.0 For Intel x86 also covers this as Installing Debian GNU/Linux from a Unix/Linux System, describing a "zero downtime" Debian install. The primary difference is use of debootstrap rather than the Potato base filesystem image to bootstrap the process. I've tried both, both work well.
On the other hand, if you're experience with Debian, bored with convention, interested in a new challenge or feel that this method suits your current situation, read on. This method works in instances where a traditional Debian install doesn't, or would not be appropriate.
The goal is to end up with an unpacked tarball of the base system on a partition, with a working, bootable, kernel, and networking, from which additional configuration may be performed. The means:
- Booting some other OS on the system.
- Partitioning the system as desired.
- Transferring the base image.
- Unpacking the base image.
- Chrooting into the base system.
- Completing installation tasks normally handled by the Debian installer.
- Further OS configuration and package installs.
My preferences for bootable systems are Tom's Root Boot (TRB), the LNX-BBC bootable GNU/Linux Business Card (LNX-BBC), and Knoppix, a bootable desktop-oriented GNU/Linux CD.
TRB is 1.7 MiB of GNU/Linux and utilities on a floppy disk. It's pretty minimal, but can get you a console, and usually networking, on a system, as well as a surprising number of utilities and kernel modules. As it runs in a RAMdisk, you can modify all the underlying storage. You can also create up to 13 additional RAMdisks of 4 MiB each (TRB itself runs in three), for a total of 52 MiB storage (memory permitting). Its main limitation is in not being compatible with ext2 filesystem features available in 2.2 and later kernels.
LNX-BBC is far more capable, packing about 110 MiB of utilities, including an X server, web browsers, games, and much, much more, onto a small-format CDROM that fits in the "singles" CD slot of a typical CDROM drive. At this writing (Jan, 2003), version 1.618 is the current stable release, with a new stable release imminent.
Knoppix is like LNX-BBC but more so. On one 700 MiB full-sized CDROM are nearly 2 GiB worth of GNU/Linux utilities and applications. This is a desktop-replacement system, on a bootable CD. It's discussed elsewhere here.
Or, you can use an existing GNU/Linux install as your starting point. This is the source of the comment "not all non-Debian GNU/Linux distros are useless -- some of them make very acceptable Debian installers". If you've been curious about trying out Debian but aren't ready to part with your current system, this is a way to sculpt in your Debian distribution while retaining full use of your existing system.
Still other possibilities, including installation onto non-GNU/Linux systems, are available via UserModeLinux. This is left as an advanced exercise for the reader at present.
Note that this really is an exercise in flexibility. That is: there's more than one way to do it. Adapting methods to your circumstances is encouraged, though we're going to try providing instructions which, if followed, result in a working Debian GNU/Linux install.
Also note that there's more than one way to do it. A method for installing Debian under an existing GNU/Linux or other Unix system, remotely, is described at http://trilldev.sourceforge.net/files/remotedeb.html, as well as the official Debian installation documentation mentioned earlier.
In a word: flexibility.
A key feature of GNU/Linux (and free software in general) is the choice it gives the user. This (and other installation methods) are simply not thinkable for users of proprietary OSs. And while there's no obligation for you to use this method, just knowing you can should give you a nice warm glow.
The advantage to this method is that you're working in a chrooted environment. Outside this "chroot jail", you've got a fully capable GNU/Linux system -- more so if you're using KNOPIX, the LNX-BBC, other bootable "desktop" GNU/Linux systems, or an existing install. If you're booting from removable media, you can modify any fixed storage (aka hard drives) on the installation system without affecting the system that's running -- TRB, LNX-BBC, and Knoppix each run either completely in RAM, or in RAM plus a live CDROM filesystem.
Once you've got the new Debian system configured to your preference, you can migrate your existing user data (if any) to it, and keep on rolling. Thus this is also a "zero downtime" GNU/Linux install. It's also a damned good way for dealing with hardware that otherwise doesn't play friendly with various boot or installation media.
It helps greatly to have a network-accessible live GNU/Linux system available, or better, a physically accessible one if you need to do a floppy-based transfer.
The following section discusses the basic steps in a chroot installation.
Note that this is still a little rough, and one of the motivations of posting these notes is to solicit feedback and improve the method. While the steps presented should result in a Debian GNU/Linux installation, additional or out-of-sequence steps may be required.
A chroot changes the system root for the chrooted process (your chroot
shell) and its children. You're in an environment, not a "new instance" of GNU/Linux -- you're running the original system kernel, and have access to resources such as networking, device drivers (kernel modules) and (if you provide mountpoints) removable or fixed media as well. What you do have is a new "effective" top level root directory for the purposes of the install.
It's possible to break out of a chroot, particularly as root. Which you are running for the purposes of the install. So do be careful.
Your host environment will provide you much of the support that's difficult to get during a standard install. So while you will be configuring, say, networking and module support for the new install while in the chroot, you won't actually be applying these configurations until after you boot into the chroot (or move the chroot drive to a target system and boot it).
Services are a special concern. Debian likes to start up services after they've been installed. Running a chroot, you may find yourself with two instances of, say, Apache running. Since network ports are external to the chroot (they're a kernel interface), you can run into problems. Use care when setting up services, especially if your host is a production box of some sort.
Whatever your bootable system choice, boot one that works and you're comfortable with. If you're going to repartition the hard drive, do it now. My suggestions on partitioning may be found in the NixPartitioning topic.
Create ext2 filesystems (Potato doesn't support ext3fs or reiserfs out of the box, more later), and a swap partition, as needed.
I strongly recommend creating at least two filesystems, plus swap, You'll use one of these filesystems as the locate for saving the base image tarball prior to unpacking it. Mount one partition as /mnt/debinst (the installation point, to be the root (/) filesystem on your new system) and the other as /mnt/utility (the names are strictly arbitrary, but I'll refer to them as such for the remainder of this document).
My preference is for separate partitions, in order of preference for creation: /, swap, /boot, /usr, /home, /tmp, /var, and /usr/local. If not created as partitions, I prefer putting /tmp and /var as symlinks to /usr/tmp and /usr/var. Creating separate partitions provides several advantages, including insulating your system against harmful situations, setting filesystem options (writable, executable, SUID privileges, etc.) on a per-partition basis, demonstrated in the /etc/fstab below. As usual with GNU/Linux, there are many opinions and options, but this is my advice, based on my own experiences.
If you want to install to a filesystem other than the standard ext2/ext3 GNU/Linux filesystems, e.g.: reiserfs, jfs, xfs, etc., you may create these filesystems at this time, if your host system has support for same. Note that you will probably want to stick with ext2/3 for your root and/or /boot partitions as these are supported by most bootloaders and rescue disks.
Mount two of your partitions to /mnt/debinst and /mnt/utility. While you're at it, make sure a /mnt/floppy directory exists on the installation system if you're planning on transferring the base image by floppy.
# To create an ext2 filesystem:
mke2fs /dev/partition
# Initialize and activate swap:
mkswap /dev/partition # e.g.: /dev/hda2
sync; sync; sync
swapon /dev/partition # e.g.: /dev/hda2
Note: if you are performing a debootstrap install, this section does not apply to you, as debootstrap obtains the base installation system by different means. Please see the Debian Installation Manual for this step
Transfer the base image tarball to the system. If you can get networking configured under your install system (e.g.: TRB, LNX-BBC, Knoppix, etc.), this is your best bet. It may be possible to configure a PLIP (laplink) connection, but I find this to be temperamental, uneven, and usually unsuccessful endeavor. You're likely better off swapping floppies (or other recordable, removable, media) between the two systems. If you use two floppy disks, you can write one while reading the other. The transfer takes about 11 disks.
The base image itself is found here:
http://archive.debian.org/dists/Debian-2.2/main/disks-i386/current/base2_2.tgz
(Note that as of 10 October 2003, the old location of http://http.us.debian.org/debian/dists/potato/main/disks-i386/current/base2_2.tgz is no longer valid .)
You can use 'split', 'cp', and 'cat' to split up, transfer, and recombine the tarball.
On the source system:
# Creates files base2_2.tgz-aa, base2_2.tgz-ab, etc.
split -b 1440K base2_2.tgz base2_2.tgz-
# This will copy each fragment to a floppy disk without your having
# to type each filename. It will *DELETE* the contents of the floppy
# disk.
# You may need root permissions to run this.
# This won't make up for you hitting '<return>' at the wrong time,
# so stay sharp.
for file in base2_2.tgz-*;
do
echo -e "Insert floppy and hit <return> \c"
read ans
mount /mnt/floppy
rm /mnt/floppy/*
cp $file /mnt/floppy
umount /mnt/floppy
echo -e "\aRemove floppy\n"
done
echo "Completed"
On the target side, things are easier, type <ctrl>-C when done. You may need to create the /mnt/floppy mount point. Run this from where you want the bits to land. Again, I'd suggest you create at least two partitions, a place to install the base (at least 40 MiB, 64 MiB is generally sufficient), and a place to unpack the tarball (at least 20 MiB).
cd /mnt/utility
while :
do
mount -t auto /dev/fd0 /mnt/floppy
cp /mnt/floppy/* .
umount /mnt/floppy
done
...when the above has completed, on the target system:
cat base2_2.tgz-* > base2_2.tgz
# You're done with the pieces:
rm base2_2.tgz-*
# Change to the installation root and unpack:
cd /mnt/debinst
# TRB's tar doesn't handle gzipped archives natively...
zcat < /mnt/utility/base2_2.tgz | tar xvf
When you're sure you're done with the image tarball itself, you can delete it. This can happen at any later time.
Note: deboostrap folks can largely follow the remaining instructions in this article.
You've now got a real Debian system, though rather lean, on disk. Chroot into it:
chroot . bin/bash
OK. You've got a few things to configure that would ordinarily be handled by the installed (dbootstrap):
- partitioning
- networking
- keyboard
- language
- time zone
- user account
- apt sources
You've already dealt with partitioning, no need to revisit this. You need to create /etc/fstab, however. While you don't need mount additional filesystems, this is a good time to do so. You'll probably want to activate swap and the proc filesystem.
A sample /etc/fstab -- modify to suit:
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/XXX / ext2 defaults 0 0
/dev/XXX /boot ext2 ro,nosuid,nodev 0 2
/dev/XXX none swap sw 0 0
proc /proc proc defaults 0 0
/dev/fd0 /mnt/floppy auto noauto,rw,sync,user,exec 0 0
/dev/cdrom /mnt/cdrom iso9660 noauto,ro,user,exec 0 0
/dev/XXX /tmp ext2 rw,nosuid,nodev 0 2
/dev/XXX /var ext2 rw,nosuid,nodev 0 2
/dev/XXX /usr ext2 rw,nodev 0 2
/dev/XXX /home ext2 rw,nosuid,nodev 0 2
You can mount the proc filesystem multiple times and to arbitrary locations, though /proc is customary. It will make certain other tasks easier, so do this now:
mount -t proc proc /proc
Mount any additional filesystems. Note that these filesystems are mounted under the chroot.
# If this mount point is referenced in your /etc/fstab:
mount /path # e.g.: mount /usr
I'll assume you've got networking handled through your boot system, for
the duration of your chroot installation process. This section mostly
covers configuring networking for use after installation, when you
actually boot your newly installed system.
It's possible that name resolution won't work until /etc/resolv.conf
is properly configured. Under Knoppix, this may be symlinked outside
the chroot. You'll have to break (delete) the link and create a regular file with your nameserver(s), and (optionally) domain and search directives.
You still likely don't have networking configured to come up on the installed system. This requires hand edits of:
-
/etc/resolv.conf -- your nameserver(s) and search directives go here.
-
/etc/network/interfaces -- see /usr/share/doc/ifupdown/examples for examples. This configures your interfaces. In general, you need to know your IP, network, netmask, network, broadcast, and gateway.
-
/etc/hostname -- your system's host name -- 2 - 63 characters.
-
/etc/hosts -- 127.0.0.1 your_system's_host_name (required for some services)
Note: Applying these settings will affect both the chroot and host environment, though the configuration files themselves are persistant only in the chroot install.
Basics of system setup are handled by base-config
dpkg-reconfigure base-config
base-config
# (You may have to run 'dpkg --install --reinstall base-config'
# instead to force this).
And, if the system hasn't already prompted you, set up a nonpriviledged user account:
adduser <username> # ...and follow prompts.
passwd <username>
OK, now, munge /etc/apt/sources.list to your preference. You can use apt-setup or edit the file by hand. If you want to run a 'testing' or 'unstable' system, you can make this switch now. After the edits (and setting the $http_proxy environment variable if necessary:
apt-get update
apt-get dist-upgrade
...will update your system.
I'd suggest a set of packages which I like installed in all instances:
apt-get install aptitude w3m screen ssh lftp vim gpw
You probably want a Linux kernel and a bootloader1. I've become partial to GRUB these days, though LILO's an old standard. apt-get install your preference.
*Note: Not sure this applies in a deboostrap install, but make sure the
file isn't present.*
The file /sbin/unconfigured.sh will prevent your system from starting up normally if it exists (it is checked for in /etc/init.d/rcS). Delete or rename this file prior to rebooting your system.
You'll need to umount any filesystems mounted under the chroot manually, before exiting your chroot process. Your chroot mountpoint itself is generally not mounted under the chroot, but under the host system. Remember which environment you're in when running your shutdown or reboot command, particularly if your host is a live install. Bootable CD distros are considerably more tolerant to unclean shutdowns.
Reboot to confirm your settings. If your system doesn't come up, you've got your boot disk (TRB/LNX-BBC) to salvage you. Chroot into the installation, mess with your bootloader, and try again.
Common boot errors include:
- Not installing a kernel.
- Not installing a bootloader.
- Not configuring your bootlader ('lilo', or 'grub-install; vi * /boot/grub/menu.list; update-grub', or whatever's appropriate for your bootloader).
- Not properly specifying your root, boot, or kernel image filesystems.
- Not properly configuring initrd support in your bootloader.
- Not properly configuring filesystem modules in your kernel, initrd, or base system.
If you need to interrupt, or are interrupted, in your installation, you can for the most part pick up from where you left off. Once you've begun package installation. Both downloads and installation are idempotent. Downloads will continue from where they left off. Package configuration will proceed correctly if repeated.
Note that if you are using the dbootstrap method detailed in the offical installation manual, this process is not idempotent, per Joey Hess, and you are best advised to restart an interrupted installation. In general, this is a brief part of the full process. Once you've reached the package selection or initial reboot, you should be able to resume an installation if necessary.
Once your system is booted, you can try converting to a journaling filesystem if you prefer -- e.g.: ext3fs, reiserfs. I recommend ext3fs on filesystems with less than about 150-200 MiB, and reiserfs above this value. Reiserfs is unsuited to small partitions due to the fixed size of its 32 MiB journal file. Its benefits are somewhat limited on small filesystems anyway, so ext3fs /boot, /, and /tmp are generally recommended. For large partitions, reiserfs offers some performance benefits, particularly for directories with many files.
For ext3fs, there's no major hassle. Make sure your kernel supports ext3fs, and run for each partition:
tune2fs -j /dev/<partition>
...you may also want to set the '-c' (mounts between fs checks) or '-i' (interval between fs checks) options, and possibly the '-m' (reserved blocks percentage) options. FIXME: recommended values?
For reiserfs, the solution is a dance called the reiserfs shuffle. Note that if you've (re)partitioned your system, it's best to reboot before attempting to create reiserfs filesystems following the repartitioning.
The procedure for converting /usr to reiserfs would be something like::
# tar the partition to be converted to alternate storage (if you've
# created a fair number of partitions, you can "park" it elsewhere --
# e.g.: =/home= or =/usr=, usually). For /usr,
# living on =/dev/hda7=, archived to =/home=:
tar czvf /home/usr.tar.gz /usr
# ...and verify:
tar tzvf /home/usr.tar.gz
# ...the exit value ($?) should be 0.
# Unmount the partition:
umount /dev/hda7
# Create reiserfs:
mkreiserfs /dev/hda7
# Mount the partition
mount -t reiserfs /dev/hda7 /usr
# Unpack the archive to the target:
cd /
tar xzvf /home/usr.tar.gz
...repeat for each partition, and you're set. You'll also want to update your /etc/fstab file to specify reiserfs rather than ext2 (or the prior filesystem) for this partition)
From here, you can build out the system by:
# On other box:
dpkg --get-selections > file
$EDIT file
# Transfer file to your new system (floppy, network, carrier
# pigeon, whatever).
dpkg --set-selections < file
# In theory, the following works, though I had to kick it a few
# times to make it go right:
apt-get dist-upgrade # This should work.
apt-get dselect-upgrade # This is what I ended up using.
These include:
- APT front ends -- dselect, aptitude, synaptic, etc.
-
aptitude install _package_ from the command line -- this method is surprisingly effective and useful. Note that aptitude offers several distinct advantages over apt-get and should be used where possible.
- Other method of your choosing.
1 That's not a completely facetious, though I've been told more than once that it's bamboozled people who think American's don't know from irony. If you're building a bog standard, standalone, bootable system, install a kernel. However there are conditions in which this may not be necessary: you're dual booting with another Linux install whose kernel you share, you're booting from floppy or other removable media, you're booting via LOADLIN.EXE, you're creating a chroot build or compatibility environment that uses the host's kernel, you're building a UML system. So, if you don't need to install a kernel, don't. If you're confused by all of this, install a kernel package.
Thanks to:
- Richard Cobbe for review and corrections to this document.
- Joey Hess for the base-config tip, among many others.
- Duncan MacKinnon?, Nick Moffitt, and Seth Schoen, and others, for the LNX-BBC project. http://www.lnx-bbc.org/, also a major ass saver.
- Tom Oehser author of Tom's Root Boot, for saving my ass more times than I can recall, and giving us a really useful 1.7 MiB of sweetness. http://www.toms.net/rb/
- Rob Walker formerly of VA (Research|Linux|Software), who inspired the original concept when he mentioned how the Debian project was being supported under a chroot shell on a Red Hat box at VA, leading to my initial investigation of chroot installs.
© 2002-2004 Karsten M. Self (kmself@ix.netcom.com)
This document may be freely distributed, copied, or modified, with
attribution, this notice, and the following disclaimer:
THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY
KIND.
IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES.
-- KarstenSelf - 23 Jan 2003
|
|
Copyright © 2001-2006 by the contributing authors.
All material on TWikIWeThey is the property of the contributing authors. This content may be freely distributed, copied, or modified, with attribution, and this notice.
Works are provided AS IS with NO WARRANTY and NO LIABILITY for consequences of use.
Ideas, requests, problems regarding TWikIWeThey? Send feedback.
|
"There is nothing new under the sun, but there are lots of old things
we don't know yet."
-Ambrose Bierce