The "Live" Environment
When you first boot off of the Arch Live CD ISO, you get dropped into a command prompt, as root, with a little message on the screen that reads:
To begin installation, run /arch/setup
You can find documentation at /usr/share/aif/docs/official_installation_guide_en
i18n: Use the 'km' utility to change your keyboard layout and console font.
If you encounter issues and want to report them or seek help, run /arch/report-issues
If you are looking to install Arch on something more exotic, such as your kerosene-powered cheese grater, please consult http://wiki.archlinux.org.
Thankfully, I don't have a kerosene-powered cheese grater. Recall that I have switched myself over to a Dvorak keyboard layout, and I have replaced my old QWERTY-labeled keyboard with an awesome blank-keyed Das Keyboard. So of course the first thing I did was to run km and select a Dvorak layout. Ah, much better.
Steps 1-3
Then I ran /arch/setup, and was greeted with this screen (click for a full-size view):
One might be tempted to jump around, but the installer won't allow that; so I started with the first step. The "select source" task gave me some cryptic warnings about making sure to use the right repositories, lest I hasten The Singularity. Not knowing what was the right or wrong choice, I just chose what was pre-selected by default. We haven't been enslaved by our computers yet, so I guess it wasn't a terrible choice. Back I came to the main menu, with "2 Set editor" helpfully pre-highlighted for me. Choosing this gave me a choice of "vi" or "nano". I'm a vi man, so that one was easy.
The next one was "set clock". I ended up having to run this installer several times for reasons unrelated to the clock, and eventually I came to the conclusion that getting too wrapped up in setting the clock from here, at least in a VirtualBox Guest, was a sucker's game. So, in my ideal install, I skipped this step.
Step 4
"4 Prepare hard drive(s)" may not look ominous to the uninitiated, but I knew from years of experience that this is where the partitioning would happen, and stuff would get tougher. As I explained last time, I have two storage devices in my main desktop computer: a 100GB SSD for fast booting and operating system use, and a 2TB hard drive for main storage. I don't want to devote a multi-gig chunk of my precious SSD to testing an Arch installation, and performance isn't the point of this test. The point is to have two hard drives, one large, one small, and to make sure I know where I want what, and that all my partitions and whatnot work out right. So both of my "drives" are actually contained in files on the 2TB drive. I proceeded with some trepidation to the Prepare Hard Drive sub-menu:
I put Arch on the laptop for a couple of days for fun a few weeks ago, and when I selected the first entry: "Auto-Prepare", everything worked out great. But that choice isn't appropriate for a multi-drive setup like my test machine. So that means I have to manually partition and configure the filesystems and mountpoints. This is never fun.
My simulated 8GB SSD mapped to /dev/sda, and my simulated 100GB hard drive mapped to /dev/sdb under the Arch system. By looking at the layout chosen by the auto-prepare option on a single hard drive installation, I determined that Arch likes to have a separate /boot partition. So I created the following partitions and mapped them to various filesystems and mountpoints:
- /dev/sda1, bootable, 580MB, type="Linux", mounted at /boot, ext2 filesystem. This partition gave me the most problems. I wasn't sure what the right type was, because there were a few options that seemed reasonable, and I wasn't sure what filesystem to put on it. If I chose any combination other than the ones listed here, everything would seem fine until the very last step (8 Install bootloader), and then GRUB would refuse to install.
- /dev/sda2, remaining 7.5GB, type="Linux", mounted at /, ext4 filesystem. This is the main filesystem root, where all the operating system stuff goes, so that should be on the SSD for maximum performance.
- /dev/sdb1, 96GB, type="Linux", mounted at /caviar, ext4 filesystem. This is the main storage partition, which in real life would be 1.88TB. Using softlinks, I can map whatever I want into this drive as I use the system in the future. In case you're curious, it's called "caviar" because it is a Western Digital Caviar hard drive.
- /dev/sdb2, 4GB, type="Linux swap / Solaris", swap. The swap partition on Linux is just like C:\Pagefile.sys on a Windows machine: it's where memory gets written to disk if you start running out, or if you put your machine into hibernate. I located this on the slow hard drive instead of the SSD because I don't expect to use it very often. I can avoid using it by installing more memory, and many people choose to have no virtual memory at all. I prefer to have it available for exceptional circumstances, but I don't want to devote precious SSD space to it. And on a real SSD, there is no real speed gain from putting your machine into hibernate instead of just shutting it down. My desktop machine currently boots into Ubuntu, ready to be used, in about 6 seconds.
Bear in mind that the choices above were finally determined to be the right ones after many annoying attempts. After each, the Arch Installer would format my hard drives, create the filesystems, and set up the mountpoints. I usually didn't know something had gone wrong for about an hour.
Step 5-6
Next are a couple of simple steps. Selecting the packages was easy, since I had no idea what most of them were, and I knew I could install them later if I realized I needed them. However, a couple of extra non-default packages turned out to be a good idea:
- pacman-mirrorlist - the Arch package management application is called "pacman", and it downloads software packages during install or upgrade from a repository mirror specified in the /etc/pacman-mirrorlist file. If you don't install this off the installation CD, I don't know how you're supposed to use pacman post-installation.
- sudo - the ability for a normal but authorized user (like the "mark" user) to elevate his privileges to be indistinguishable from "root" without having to type in the root password is very valuable. It's more secure, and it's more convenient. I found I needed it immediately after installing Arch, so it was a no-brainer to put a tick next to this package during the installation process.
Step 6 - Install Packages is the easiest of all. It tells you to be patient, you hit Enter, and you watch it install stuff without having to do anything yourself.
Step 7
In the next step, I needed to create the initial system configuration files. Much of this can be skipped, but it's a good idea to cruise through each file and see if anything jumps out needing changing.
Arch has a simple System V-style configuration model, where most of the main configuration options are stored in the /etc/rc.conf file. I made a few changes:
- I changed the TIMEZONE line to read "America/Chicago", which makes my system clock work out right.
- Under the NETWORKING section, I changed "Interface=" to read "Interface=eth0", which is my one-and-only ethernet card on the machine. By not setting anything else here, I let it use DHCP to get its networking details. In the real world, I can start this way, but I'll want to change it to a static private IP so that other machines on the McHouse Enterprise Network can find it.
- I set the machine name to "arch64test" here, and also in /etc/hosts.
- I did not have to change my keyboard layout, because the installer automatically propagated my choice of "dvorak" into the rc.conf. But if I hadn't bothered before, I could have set it system-wide here.
There are several other configuration files that are available for adjustment at this stage, but rc.conf is the main one of importance. I added "arch64test" to the /etc/hosts file so it would match the rc.conf, and I also set a root password in this step, so I don't forget to do it later.
Step 8
Installing the bootloader (GRUB) is an infuriating step. The installer fails cryptically if it doesn't like something about the partitions chosen way back in Step 4, and your only choice is to effectively start over. Also, the Arch Installer makes a big deal about forcing you to look at the /etc/grub.conf, even though the contents never need changing. The first time I landed here I felt this sense of responsibility, like I had to verify every line in the file for correctness - tough when I didn't even understand every line! After going through this step five or six times, I became pretty comfortable with just instantly exiting out of the file when it popped up on the screen.
Success!
Eventually everything went well, and I kept my fingers crossed during the GRUB installation, and the installer exited successfully. That let me remove the install CD and reboot into my brand new Arch installation, which looks like this:
Now what? It's not exactly the multimedia experience we have all come to expect from our PCs these days. That's the thing about Arch, though: it is exactly what you make it. It doesn't try to guess what you want your desktop to look like - it gives you the power and the responsibility to do it yourself.
No comments:
Post a Comment