Mike Levin SEO

Future-proof your technology-skills with Linux, Python, vim & git... and me!

Debootstrap, HowTo in Debian and QEMU

by Mike Levin SEO & Datamaster, 07/27/2010

Now that we have used the LiveCD to prepare the hard drive, we can use a piece of software called debootstrap. The “de” in debootstrap stands for Debian. Debian is ideal for making bare-bones Linux systems, in-part because this utility exists, also in-part due to the wide array of hardware Debian supports, and also in part due to how easy it is to build-up on top of a bare-bones Debian installation, using it’s apt-get command.

The “bootstrap” portion of debootstrap stands for the process of turning an otherwise useless lump of hardware into a computer that can start doing things. QEMU lets us emulate different lumps of hardware, x86-Intel-style in this case, which we “power on” whenever we run that command line. It gets bootstrapped every time we do. Bootstrapping comes even before loading what we traditionally think of the operating system. When power hits the hardware, a program called a “boot loader” starts running from firmware built into the hardware.

Actually, there are 2 phases in bootstrapping, since a minimal boot loader in the hardware hands over control to a larger boot loader found on the hard drive. The tiny boot loader is sometimes called the initial program loader or IPL, built into the firmware. This runs the same way whether you’re booting into Windows, OS X, Linux, or any other operating system. For example, to get the PC you’re working on booted, your IPL turned control over to the Windows boot loader. QEMU has a software-based emulated boot loader, which we can hand control over to any operating system’s larger hard drive-based boot loader. We will hand control over to a program called Lilo or Grub, the two most popular boot loaders in Linux.

We could just as easily turn control over to a Windows or Mac boot loader. So, our QEMU virtual computer could actually be a little Windows or Mac running in a box on our PC based on what we do next. But per the name of the tool we’re using to do the next step, debootstrap, all we’re going to do is boot an extremely bare-bones Debian system, which still won’t really even boot yet. There will still be a few more steps. All debootstrap does is create the Linux directory structure on a destination drive, and copy a bunch of files over, but not a Linux kernel, users, or network configuration. We’re still going to install a kernel, setup users and network configuration files ourselves.

So go ahead and trigger off debootstrap telling it what architecture we’re installing on, what version of Debian Linux (or Ubuntu) that we want, and where to download it from. It’s going to retrieve and validate a ton of files.

And remember if you rebooted since the last step, the sda1 location needs to be mounted first: mount /dev/sda1 /mnt/sda1

debootstrap –arch i386 squeeze /mnt/sda1 http://ftp.us.debian.org/debian

It’s going to take quite some time for this to finish, as it actually is pulling down all the files from the repository. When it’s done (about 10 minutes), it should look something like this:

Remember, your system still won’t be able to boot. It has the following issues:

There is no Linux kernel installed. That’s right! Even after all this file copying, the core most important piece of the operating system isn’t automatically installed. I think this is because debootstrap is so frequently used to install base Linux systems on detachable media booting from other CPUs and devices. While the –arch (architecture) parameter of debootstrap is enough to make a base Debian install, there are so many nuances in choosing the correct kernel (less hardware abstraction), that they make you make the deliberate choice.

And there is also no hard drive-based boot loader. The initial program loader (IBL) is there, but it doesn’t have the larger boot loader to hand control over to. So if you rebooted now, the IBL wouldn’t find the boot loader, and even if it did, the boot loader wouldn’t find the kernel.

But wait, there’s more! Even if the boot loader and kernel were found, it wouldn’t know what devices to mount and use as swap drives, etc. The boot loader will only go as far as to tell the system the location of the boot drive and the kernel. The rest has to be set by editing a file called /etc/fstab (file system table). This is where you can mount non-auto-mounting devices, namely your swap partition. So we will have to edit a text file. Maybe I will introduce you to vi (vim) this early. Hmmmm.

Oh yeah, did I mention that there’s no users set up other than root, and root has no password set, so that even if you did install the boot loader and kernel, you’d be locked out. So we’re going to have to create a user that can be promoted to admin privileges with sudo, or alternatively give root a password, and log in as root–a practice that is generally discouraged so that hackers are wasting their time on root instead of an account whose name they’d have to guess.

And one more thing. The files that configure the network are not set up. So, we will have to create an /etc/network/interfaces file where you set up little details like you’re going to be using the DHCP service on your network. You can set it up with a static IP, but given the fact we’re probably going to carry this thing around on a thumb drive, it’s best to set it up to use DHCP.

Okay, on to the next post where we take care of these pesky details. The good news is that this is precisely the kind of stuff you want to be learning as an introduction to Linux.