Authors

James Choate (jchoate@confusionresearchcenter.org) 1 & 2

1. Confusion Research Center (http://confusionresearchcenter.org)
2. Central Texas Commodore User Group, Round Rock, TX. (http://www.meetup.com/Central-Texas-Commodore-Users-Group/)


Abstract

This document details the installation of Arch Linux onto a non-UEFI Intel i7 Server manufactured by Dell.


Installing Arch Linux (v2016.07 DVD manufactured 20 July 2016 from OSDisc.com) to a Dell XPS 9100


Image Info: Arch Linux is installed on the right machine, the left machine is running Windows 7
These are the notes taken in the planning and initial execution phase of this project from 27-29 July 2016.
This is commentary added after the installation and is intended to go into more details about why we did what we did, and what we learned.

Why did we chose Arch Linux? Because it's one of the simplest, smallest distributions out there. It comes with a minimum of applications and everything else has to be installed by the user. For professionals and hobbyist users it's probably the ideal solution. For gamers, casual users, business, and anybody else focused on the using and not the why and hows it's probably one of the worst distributions to use.

After letting these notes sit for a couple of days we came back and reviewed them. We realized there is a single important skill that a Linux beginner must gain before actually trying to install and use Linux. That is basic vi skills. The editor vi is the lowest common denominator when it comes to being able to install and configure Linux. If you don't already know how to use vi then you need to do some searching for a vi tutorial and boot the target machine on the install CD. Because it runs in a canned environment that is fixed by the CD you can play around in it and not worry about breaking anything. You'll want to at least know how to open and close a file with and without an edit (i.e. w, q, and !). You'll also want to know how to delete a line and a character, along with how to insert a character and a line in an existing file (i.e. dd, x, i, and esc).

System:

Dell Studio XPS 9100 (Intel i7 930 @2.8GHz, 12GB RAM present/ 24G Max), Non-UEFI
Toshiba 2TB 7000 rpm drive (I prefer these over the 5,000 rpm drives for reduced seek time, cache and price were identical to the other 2TB drives)

Why was this particular system chosen? They were Intel i7 systems, the opportunity was for two systems, and the cost was extremely reasonable. While the system has a reasonable selection of expansion slot types it's very limited in the number of each type. It also has plenty of bays for drive expansion, including supporting 2x DVDs. They were intended for gaming systems and came with a really nice dual slot video card as well. The only real downside is the slot issue and they are full tower systems.

When it comes to hard drives, my personal primary choice is spindle speed. The faster it spins the faster the machine can get data on/off the drive provided cache and all other factors are reasonably similar. It used to be that 7,000 rpm drives were much more than the 5,000 rpm drives, but that price differential has really shrunk to near zero today. I'm not sure why 5,000 rpm drives are still so popular.

The final factor in my use of this make and model was it is acceptable for the applications I had in mind. I intend to use it as a development box (software and hardware) and intermittently as a bastion server with firewall using dynamic DNS by adding a second network card. The high performance graphics card was a nice plus.


Initial Install Parameters:

48G Swap
Remainder for system, EXT4

How was the 48G swap decided? Historically the standard for Unix systems is twice system RAM. While it's true there is a lot of discussion about this value, there are three aspects of swap that seem to be missed in all the discussions I've seen. The first is having large quantities of swap for applications to use for data storage, yes it's still on the drive, but it's much better organized in memory pages than hard disk sectors. This means you get faster access response. The second is security in a system critical situation. For example, an application is under development and for whatever reason a memory leak occurs. The more swap you have the more time you have to resolve the issue before system crash. The final reason is if your system is connected to the internet and has a high I/O load (i.e. a lot of users and processes running) for example a web browser, RDBMS, VPN, firewall, etc. Each process will swap pages separately, if you don't have enough swap a page fault from one process can create issues for all processes. A side justification is that even with 48G, as in this example, the space taken on the hard drive is negligable compared to the total space. You really don't lose anything.

If you're not developing software or using applications with large data sets (i.e. a casual user) then you can probably get away with swap set on the small side (i.e. 0 tp 50% of system RAM). If you're a power user who doesn't write code but does a lot of business spreadshees for example, then setting swap to the same as system memory will likely be fine. If you develop, use many applications, and those applications data sets are large, then using 2x (or more) system RAM is probably a good idea. This last case includes systems that have 24x7 internet access and run servers like Apache, or VPNs.

I chose a simple filesystem layout because I won't be having multiple users, don't have any intention of exporting directory trees (e.g. NFS), and with the reliability of the drives I'll abandon this machine before the hard drive fails (knock on wood). This addresses the three usual reasons one has for creating more complex filesystems. So I don't need a /home, /export, /opt, /public, or any of the plethora of other partitions people have come up with over the years.

EXT4 is the current default for Linux, I had no reasons to pick any other. I intend to upgrade the RAM to a full 24G in the near future.


Installation Process:

Check system BIOS settings to make sure you can boot to the DVD. Check the other settings and make sure they're sane, default doesn't always mean sane :)
Make sure there is a network cable plugged in
Turn machine on and open CD tray and insert media. May need to reboot systems to get it to boot to the CD.
Select 64 bit architecture.
Display should show the boot messages and end up at a root prompt.

So, what's going on here is that the hardware and firmware have booted the system from the DVD. Once the boot loader is in RAM it cleans out a section of memory and loads the initial application loader on the DVD. That program updates the RAM and creates a RAM-disk. It then loads the kernel into RAM and creates a basic filesystem in the RAM-disk (usually it loads a default image into RAM rather than creating the tree new each time). it then transfers control to the kernel with the appropriate pointers into the RAM-disk so when the shell comes up it presents the traditional filesystem you expect. It's important to recognize this filesystem is in RAM and whatever is here is as ephemeral as the power switch. This kernel is usually not a full blow kernel like you have with a normal installation, it's usually very customized (BusyBox is a pretty common example) in that it doesn't take up a lot of space and only provides the features needed for an installation.

You should seea standard shell prompt once the system has completed it's boot process.

The first thing we want to do is verify if we're on a system with UEFI firmware installed. The following command will either show an empty or missing directory if we're on a pre-UEFI system (i.e. standard MBR boot process).


ls /sys/firmware/efi/efivars

The next two commands will usually be optional, they set the keymap for your keyboard and console fonts for the display. Unless you're using a non-English environment you can skip them. If you do happen to be a first time user of Linux and new to the default language you want to use then you should talk to somebody already familiar with the language or Linux localization, preferably both. Configuring computers for alternate or even multiple languages is a very complex process, with many caveats, at which some people make a career. This is said with some experience since we use English and Russian, and sometimes other languages, on our own machines. It's definitely beyond the scope of this document.

load keys de-latin1 (optional, see /usr/share/kbd/keymaps/**/*.mp.gz for choices, default is US)

/usr/share/kbd/consolefonts (use setfont to change)

Configuration of the network is critical during the install process and afterward as we'll be needing to update our images from remote repositories. In the majority of cases the install scripts will probe the hardware and find some default drivers that will work. If you find your system isn't able to identify the network hardware or you otherwise have issues with it auto-configuring then you should talk to somebody with network experience including dealing with Linux drivers and your brand of router. In many cases you may need to disable built-in hardware and use an expansion board. Modifying the drivers on the CD will usually not be an option without a kernel hacker. To turn on the network stack and get a network address, run the following.

dhcpcd

The machine should acquire an address, test it with a ping to a known site (e.g. ping google.com). If you do have issues always check the logs on the router to see what it may be having a problem with. Also make note of the exact error message that is output before seeking help (you should always do this by the way). Once we're online we'll need to update the date and time.

timedatectl set-ntp true

At the command line you should be able to run 'date' and see local time and date in UTC. For those not familiar with Linux / Unix style quoting, the single quote shouldn't be typed in, so you will actually just type the word date on the command line (or cli meaning command line interface). This style comes from the shell or scripting syntax which you'll become familiar as your skills progress in the future. UTC stands for Universal Coordinated Time and really the modern term for Greenwitch Mean Time or Zulu time which you may run into with older documentation.

Now we get to the meat and potatoes of the install, initializing the hard drive and getting all the bits and bytes of the install image onto it so we can boot our machine for real. Before we do anything else we need to figure out exactly which device is going to be our boot drive.


fdisk -l (note drive 1.8 TB /dev/sda)

What we're looking for is the device (e.g. /dev/sda and not partitions such as /dev/sda1) that we're going to split up into a swap partition and a single boot / root partition. Write this down. In some cases you may see other partitions on the drive, for example if it's a previoulsy used drive or if it's got some manufacturers test or recover partition on it. We suggest removing any old OS partitions but leaving any manufacturers partitions as they may be useful in some situations outside the scope of this document. Worse, case you'll make a note of them and then simply not mount them as described later in this document.

We'd like to make a note with regard to a point of confusion we experienced. A couple of the processes we reviewed for this document use cfdisk and other use fdisk. We started with a new drive and one of the first things we did was use cfdisk to review it's configuration. Automatically cfdisk recognized that this was a new drive and asked us to select either a mbr or gpt. We initially wanted to test the process with gpt and we selected that option. We ran through the process a couple of times and verified that this selection conflicted with the firmware on our test machine. The process indicated that cfdisk would allow us to change from gpt to mbr, we couldn't find that option in the version of cfdisk we were using. We fell back on fdisk and failed here as well. We then used gparted to make the change. This required selecting the advanced user options and then selecting change firmware gpt to mbr to get it to work. Don't forget to write the changes to the disk before exiting or you get to do it all over again (whick we verified several times). All three of these tools should be available on any distribution you have. It's strongly suggested that you run each utility (i.e. cfdisk, fdisk, & gparted) and become familiar with their menus before going on with this process.

To begin we need to get our two partitions created. You have two options here, the hard way and the easy way. The hard way is when in cfdisk (or fdisk) you write down the actual sector numbers (and on a 2TB drive there are a lot of sectors) and feed these in when it asks for the start and ending sectors. It's tedious and more exact than needed. The easy way is simply to tell it the size. In our case when asked for the size of the partition we used 48GB+ as the start and just hit enter on the end option. It created the 48G partition doing the math for us. Once the first partition was done we noted how much free space was left on the drive as displayed by the tool and entered that (e.g. 1.8TB+) as the start size when we created our second and final partition.


cfdisk (partition, select mbt type, grub will get upset if you use gpt)
	delete existing (none)
	create swap (2x RAM) (primary, at end of drive if given the option - which we weren't using cfdisk))
	create / (all remaining)
	mark / bootable (option b)
	mark swap as swap (type 82, didn't have to do this as I could select Linux Swap when defining the partition))
write changes to disk (note drive letters for partitions)
	/dev/sda1 /swap
	/dev/sda2 /

Should we run into problems further in the process the question we have to ask ourselves is "Do we want to start over?" and if the answer is yes then we come back to the previous step and remove and rebuild our partitions. This makes sure we have nothing left on the drive which can interact with our rebuild. This should be rare once you've built one or two machines and get the hang of the process. Linux has been using this same basic process since it was created. Certain features might be added or dropped (e.g. mbr v gpt) or else a tool will change slightly from version to version (i.e. selecting swap type by number or name). You should be able to jump from one of the tools to the other if one doesn't have the feature you need.

Now we're ready to make our two partitions able to do real work. First we have to initialize the filesystem. What this means is to arrange a set of tables on the drive which ties all the individual sectors into a organized heirarchy so we can put data on the sectors and by 'walking the tree' find the data we need when we want it. We're not going to go into the theory and dynamics of filesystems.

We start with the boot / root filesystem creating our filesystem on the raw partition (i.e. unordered group of sectors) and then mount it to our existing ramfs. Remember we created a ram based filesystem when we booted off the install media. Mounting is simply a means to allow one filesystem to gain access to another filesystem, the details are beyond this document. The ramfs that was created has a special place to mount filesystems called /mnt which will exist on our working system as well so we can mount other filesystems to that filesystem if we have a desire (e.g. mounting a SD card or USB memory stick).


mkfs.ext4 /dev/sda2 (install ext4 fs on /)
mount /dev/sda2 /mnt (make it available to install to)

Now we do the same thing for swap with one difference, instead of using the mount command we use swapon which mounts the swap to /mnt as /mnt/swap.

mkswap /dev/sda1 (install swap fs on /swap)
swapon /dev/sda1 (enable swap for install)

If you're being adventerous and you've created multiple partitions (e.g home, export, opt) you'll want to make mount points for them under /mnt. You do this by using the command mkdir. Assume we created home on /dev/sda3. You would mkfs.ext4 /dev/sda3 and then create a mount point by doing mkdir /mnt/home followed by mount /dev/sda3 /mnt/home. You could then do the same for your other partitions by replacing home with export, opt, or whatever. You'll want to aake a note of this process as it's used for accessing other media like CDs, SD cards, etc. Also be aware there are many filesystems types like EXT3, NFS, FAT16, FAT32, BSD, ISO9660, etc. When you get a new device that is accessed through the filesystems you'll want to do some research to understand how best to access and use it's features with regard to the different filesystem types. The documentation for the device should get you pointed in the right direction.

Make sure the network is still working, we're going to be using it for pacman. A package manager is a utility that is used by Linux to search for, install, and update software on your computer, you can do it manually as well. For Arch Linux that utility is called pacman. The media that we booted from won't have the latest base or core packages we'll need to boot our machine from so we get them as we need them from the internet.

The following commands are for reference only in case you need to troubleshoot the connection (we assume with experienced help if you're not).


ip link set {device} up (to mark a eth device up)
systemctl status dhcpcd.service (to get status of services)
systemctl enable dhcpcd@eth0.service (the default way to enable the first ethernet port)
dhcpcd (starts the dhcpd deamon from cli if not running)

It's time we nstall the Arch Linux packages onto our boot / root partition, remember it's mounted on /mount with swap on /mnt/swap. We're going to install the base system along with the base development tools. If you're interested in what exectly is in these packages please see the Arch Linux website for up to date information. Besides being small Arch Linux is noted for using a "rolling update" model where you use pacman to update your packages to the latest code anytime you want (it's suggested to do it weekly by default) rather than using periodic updates like many other sites. The main advanteges to this model is you only have what you need, it's the latest code, and you don't have to rebuild your system everytime there's a major release. You'll need to examine your own situation to decide if this will work for you and your environment.

Let's clarify a term we've been using a lot - boot. It comes from "pulling yourself up by your bootstraps" which means to build something up from nearly nothing. In the context of computing a computer has to go through a process when it first gets power to jump to a pre-defined address (called the cold boot vector, there is a warm boot vector also which usually leaves the contents of memory intact) which has yet another address in it. That address holds the entry point for the basic input output system (BIOS) firmware. This firmware has some volatile memory (meaning it can change unlike the firmware which is fixed) that it stores some variables. Using these variables the firmware then looks for it's boot device and on that boot device looks for a boot sector, that gets loaded into RAM and executed, starting the whole process over. Through a chain of these bootstrap programs you finally get to the operating system and able to use the system for something usefull.

Arch Linux and pacman use the command pacstrap to get the boot sector and various vectors (meaning well known addresses that point to other addresses that are not well known or specified through some standard) in place to build a bootable system.


pacstrap /mnt base base-devel (put the base and development libraries on /)

This process should take a few minutes on a fast network connection (6 minutes in our case), in most cases well under an hour. If all goes well you will now have a basic system installed and nearly ready to boot. This basic system is not fully configured and is missing some important pieces. So before we reboot the computer to make it the working filesystem we have to do some very basic configurations. The very first thing we have to do is tell it where the various components of the filesystem are located. In our example that is / and /swap (if you have other partitions they need to be configured as well). To do this we run the next two commands. The first command looks at /mnt and sees what is actually present and then copies it to the file the operating system uses when it does boot up native (meaning as the primary or working operating system, the alternative would be a guest or secondary operating system in most cases). The second command is one of the most used commands in Linux, cat which comes from concatenate. It allows you to view files among other things. Do a man cat or search it online if you want more info. It's there mainly to let you look at /etc/fstab and verify that it's correct. As a side note, /etc is the default directory in Linux where most programs keep their configuration files.

genfstab -p /mnt >> /mnt/etc/fstab
cat /mnt/etc/fstab

All the previous work will pay off here, we're going to do the final configuration before booting the system to the new Arch Linux installation. We do that by pointing the running kernel to a filesystem other than the ramfs we've been using so far. To do that we have to change the kernels root directory from the ramfs to the one mounted on /mnt of the ramfs. The process of changing root directories for a kernel is called chroot. The arch is a reference to the architecture or kernel.

arch-chroot /mnt

The prompt you should see is using the partition that will be the working or active filesystem once we reboot the system. We're currently logged in as root and not using a password. We need to fix that since we don't want just anybody in the system. Follow standard procedures and advice in regards picking root's new password.

passwd (This sets root's password so you can log into the system once it's live, don't miss this or you get to do it all over again!))

Now we're going to do some basic locale information for the working system. If you're concerned about using vi (an ecitor) or messing this up you can skip this. If you don't know how to use vi then definitely review it's documentation online, get a vi cheatsheet for the various commands, and practive using the filesystem loaded when you boot from the CD. You will need to use it to build a working system.

vi /etc/locale.gen (uncomment your locale, usually en_US.UTF-8)
echo LANG=en_US.UTF-8 >/etc/locale.conf
export LANG=en_US.UTF-8

The final step before testing the new system is to get the boot loader configured, it's called grub. It was mentioned earlier about a chain of bootloaders, grub is just another one in that chain and it deals with the hard drive. It's something along the lines of computer BIOS > hard drive controller firmware > hard drive firmware > boot sector on hard drive (which contains grub) > boot program for the fileystem > kernel and if all goes well a working system.

Before we can install and configure grub however, we have to configure pacman on this default filesystem (remember the pacman we used earlier was in the ramfs and already configured with known parameters).


vi /etc/pacman.conf
Find “Repositories” and uncomment [core], [extra], [community], and [multilib]
may need to add to bottom of config file,

[multilib]
Include = /etc/pacman.d/mirrorlist

In our install we didn't have to do anything but uncomment the line, everything was there as expected. Now we get pacman updated so we can get other software.

pacman -Sy (This should update pacman)

Then we install grub and do the basic configuration for it's locale.

pacman -S grub-bios
grub-install —target=i386-pc —recheck /dev/sda
cp /usr/share/local/en\@uaot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo (show alternate walk in tree to cp)

We also need to install a package that allows grub to boot from more than one partition, strictly not necessary but strongly advised (i.e. don't leave it out).

pacman -S os-prober (for dual booting)

The next step is to get grub to recognize the configuration of our hard drive so it knows where to go at boot time.

grub-mkconfig -o /boot/grub/grub.cfg

Get ready to reboot and test our new system.

exit (get out of the chroot)
umount /mnt
(remove the install media)
reboot

The only problem we saw was from our doing this process over and over. If the signature on the hard drive gets out of step with what's in the grub configuration file you'll need to re-run the grub-mkconfig command above to force it to re-read the drive and write the new signatures to the grub config file.

Boot from the CD or other media, mount the partitions to the ramfs /mnt, arch-chroot, and then re-run grub-mkconfig.

Assuming you don't have to do that you can log in as root using the password created above, and enable the network.


systemctl enable dhcpcd@eth0.service (Enable the network)

Congratulations, you should have a working system to begin exploring Arch Linux!

Lessons Learned

1. We initially configured the hard drive for gpt partitioning but found this did not work when trying to install Grub.

2. The description and features of the tools varies over time, so it's always a good idea to find alternative tools.

3. Being able to use vi effectively is a requirement before even attempting to install Linux.

Bibliography and References

[1] Wikipedia - Unified Extensible Firmware Interface

[2] Wikipedia - GUID Partition Table

[3] Wikipedia - BIOS

[4] YouTube - How To Install Arch Linux

[5] Arch Linux Installation Guide

[6] Lifehacker - Build A Killer Customized Arch Linux Installation and Learn All About Linux In The Process

[7] Linux.com - All About Linux Swap Space

[8] Wikipedia - EXT4