•••

The Internet, and much of our media landscape today, is full of suggestions: search results constructed from our keywords, movies recommended based on our personal tastes, books purchased by customers like us, news stories we might like to read, Facebook users who may be our friends, Twitter users we might wish to follow, ads for products based on our search histories and online activity, trending discussions, and restaurants in our area. These computed recommendations have become part of the wallpaper of our media culture. The software that produces them is invariably a chunk of code called an “algorithm.”

Last week, I had the pleasure of attending “Governing Algorithms,” a two day conference on algorithms in Manhattan. The event, which was sponsored by Intel and convened by researchers in NYU’s Department of Media, Culture, and Communication, was a meeting of scholars studying algorithms from different communication and social science perspectives.

One thing that became apparent at the meeting was that the definition of the term “algorithm” isn’t always clear cut. While people popularly associate the term algorithm with computer code, the idea of algorithms predates computers by at least twelve hundred years. In its most basic form, an algorithm is simply a set of logical instructions intended to solve a problem that will produce a different answer depending on the conditions it’s given. “If it’s raining, take your umbrella; otherwise, leave it at home,” is an example of a simple algorithm. It’s a set of instructions that produces a different result depending on whether or not it’s raining.

When these sorts of instructions are formalized in computer code, they can do things like show us recommendations. For example, Facebook’s friend suggestions are, in all likelihood, produced by a more nuanced version of some basic algorithm along the lines of “if two people on the site are unconnected, but share five or more friends, suggest to both users that they may wish to friend one another.”

These sorts of “if this, then that” statements are pervasive. Computer algorithms go into processes and areas as diverse as high-frequency stock market trading (“If X stock has trended downward by Y% over the last minute, sell Z shares”), computerized surveillance (“If something that looks like a person on the surveillance camera is moving through airport security in the wrong direction, sound an alert”), the safety systems on new cars (“If the driver presses the gas pedal and the brake pedal simultaneously, respond only to the brake”), and generating your credit score (“If person has missed X payments in Y months and owes greater than Z, penalize them.”).

In the world of media specifically, algorithms are big business. Many simple algorithms determine the basic behaviors of things like webpages and mobile apps (e.g., “If the user is logged in, display her email; otherwise don’t.”). But conference attendees were generally interested in more involved applications of algorithms. For example, like the mass media that went before, many of our online media are advertising-supported. As developer Claudia Perlich discussed at the conference, in the 50 milliseconds it takes your browser to load a webpage, there’s an instantaneous and fully automated auction going on between advertisers whose algorithms have determined that, based on what they know of your recent searches or browsing history, you might be receptive to a client’s ad. Billions of these auctions occur daily, helping to support the media we consume and interact with, as well as to determine which products and services become visible to us.

Likewise, algorithms play key roles in many types of online media. Social networks are more likely to achieve or maintain success if they can identify and connect you with other users you know or find interesting. Online film and television distributors like Netflix find that using algorithms to help users locate movies they like within the company’s existing catalog is often a cheaper way of raising customer satisfaction than acquiring new titles. News sites whose automated suggestions get itinerant visitors to read an extra story can generate more ad revenue. And retailers who can successfully suggest new books to avid readers will boost their bottom line.

It’s understandable, then, that we see algorithms everywhere, and why companies, software developers, and computer scientists have invested so heavily in learning how to build successful ones. As algorithms have become ubiquitous, they’ve also garnered the attention of communication researchers and social scientists, but there’s been relatively little organized conversation between these folks. A major purpose of the “Governing Algorithms” conference was to convene this community of scholars for a series of productive conversations about how best to grapple with the role that algorithms play in commerce, in politics, and in our everyday lives. A few of the interesting themes and questions raised by speakers and panelists included the following.

(1) Algorithms raise interesting questions about editorial responsibility. If an important event is left off the front page of a local newspaper, it’s the editors we hold accountable. But when it’s a computer program that’s responding to our need for information—delivering a page of search results, a list of trending topics, or an array of headlines aggregated from different news sources—whose editorial judgment is at issue?

(2) Many of the algorithms that deliver information to us via the Internet, like search results, movie recommendations, or lists of trending topics, are proprietary. Companies like Google and Twitter keep them intentionally secret, so that competitors can’t make use of them and so that users and content providers can’t employ their knowledge of the algorithms to game the results they produce. Today, when so much of our access to news and information is filtered and presented by algorithm-based technologies like search engines and news aggregators, should it concern us that we are prohibited from knowing how they work? This also traces back to the issue of accountability. As speaker Tarleton Gillespie highlighted, when Occupy Wall Street was being discussed across the country and the globe, but did not appear on Twitter’s list of trending topics, when racist or anti-semitic sites and images rose to the top of Google’s search results for common terms, and when Apple’s “Siri” search assistant for the iPhone remained strangely coy in response to questions like “Where can I get an abortion?” the initial response from Twitter, Google, and Apple has been the same: The result was determined by the algorithm and is therefore a neutral editorial attempt to represent the information available. In each case this was very likely the truth, but (a) the trade secrecy surrounding the companies’ various algorithms makes the assertion impossible to check, and (b) the nature of the claim also makes it impossible to ascertain whether or when a company has intervened more directly into the results it provides. As disconcerting as this deflection of responsibility can be when it comes to news, consider that proprietary algorithms also do things like trade stocks, identify criminal suspects, and determine credit scores.

(3) Even if we could see the algorithms that we’re intrigued by, in many cases they’d be impossible to understand. And I don’t mean that as shorthand for “without a Ph.D. in computer science.” Rather, an increasing number of contemporary computer algorithms are built through what are called “machine learning techniques,” wherein the software is given an immense amount of data and actually writes its own “if this, then that” rules for coming up with search results or answers to questions. Machine learning software like this starts out fairly stupid. The engineer runs searches or asks it to display results, the computer spits out information, and in response the engineer tells it whether it’s right or wrong. After a while, the computer learns which relationships between different sorts of data are most likely to give a correct result. Your email program’s spam filter is a simple example of machine learning. After you send enough messages to your junk folder (and pull enough of them out), the program begins to learn that emails from particular senders, containing certain combinations of words, or better yet, from certain senders that also contain certain combinations words, are likely to be junk. Eventually the computer will generate a large number of rules and exceptions for deciding whether an email message is spam or not. You as a person didn’t make those determinations, and if you were to see what the computer came up with you might well be surprised at the things it found predictive. And for complex sorting that involves more than two categories (junk and not junk), or intricate tasks such as generating search results, recommending films, or determining which people in a social network might know each other, the list of rules becomes immense and many of the things the software finds predictive seem quite confusing to a human observer. When we rely on algorithms for important information, but the sets of rules they involve become so complex that we’re incapable of holding them all in our head, how do understand the results they give us? Who or what becomes accountable for the information we receive when even the designers of the original software no longer understand what it’s doing? And do designers have particular responsibilities when they create such systems, such as precluding some sensitive categories of information that the computer might decide are predictive for particular tasks, such as race, gender, or income, in situations where we may not be able to easily understand how these factors are being used?

These were just a few of the points raised by the excellent speakers, panelists, and attendees at the conference. Here in Quinnipiac’s Interactive Media Masters program we teach a few units on algorithms and I’m already looking forward to incorporating some of the intriguing papers and conversations from this week into the next offerings of my classes. If these are questions that interest you, I recommend checking out the wonderful conference papers and participant-contributed reading list on the Governing Algorithms website. I believe portions of the conference were recorded and may eventually be available there as well.

[Image Credits: Fractal images generated by algorithms cc-by 2.0 Fractal Ken ]

Connection=wireless
Interface=wlp4s0
Security=wpa-configsection
IP=dhcp
WPAConfigSection=(
   'ssid="BobcatNet"'
   'key_mgmt=WPA-EAP'
   'eap=PEAP'
   'group=TKIP'
   'pairwise=TKIP CCMP'
   'identity="YOURUSERNAME"'
   'password="YOURPASSWORD"'
   'priority=1'
   'phase2="auth=MSCHAPV2"'
)

I’ve called the above profile file ‘qu’. To start the wireless connection, the command is ‘netctl start qu’ and to disconnect I use ‘netctl stop-all’.

I’ve been brushing up on my JavaScript skills lately and I’ve written a clone of the old BSD Unix game ‘worm’ that runs in the browser.  I’ve tried to be as faithful to the original as possible.  Try playing a few rounds and feel free to tinker with the code.  I’ve released the program under an open source MIT License.

Quinnipiac University’s IT department doesn’t support Linux, but it is, of course, possible to use a Linux machine here.  I do, and in the event that anyone else is interested in doing so, I’ll occasionally put up posts on how best to get your Linux computer working with QU’s resources.  Here’s how I got my wireless working with QU’s secure BobcatNet WiFi network.

First off, I use netcfg as my network manager.  If you use wicd or another network manager, you may have to extrapolate a bit.  With netcfg, the settings for each of your regular wireless networks is stored as a separate config file in the directory ‘/etc/network.d/’.  If you’re using netcfg, just create a new blank configuration file in the aforementioned folder—I called mine ‘qu’—and place the following in it:

CONNECTION='wireless'
INTERFACE=yourWirelessInterface
SECURITY='wpa-configsection'
IP='dhcp'
CONFIGSECTION='
   ssid="BobcatNet"
   key_mgmt=WPA-EAP
   eap=PEAP
   group=TKIP
   pairwise=TKIP CCMP
   identity="your MyQ username"
   password="your password"
   priority=1
   phase2="auth=MSCHAPV2"'

You will, of course, need to fill in your own network username and password.  To find the name of your wireless interface (usually, but not always, wlan0), run the ‘iwconfig’ command from the command line and use whatever combination of letters and numbers it identifies as being associated with your wireless card.

Once finished, you can connect to the network at any time with the command ‘netcfg qu’ (where ‘qu’ is whatever you’ve called your config file).  To disconnect, it’s ‘netcfg down qu’.  You can, of course, automate connecting and disconnecting with systemd (or initscripts, for that matter).  Check out the Arch wiki for more information on configuring and/or automating netcfg.

Lastly, no small thanks to Jon Gjengset of Bond University, who posted a WPA2 Enterprise netcfg config file for his own school that, along with netcfg’s own example files, served as an excellent guide for getting this working.

Here’s how I’ve configured shared folders on my own VirtualBox install of Arch Linux.  These instructions should work for other Linux distros used with VirtualBox as well, but the usual disclaimers apply—this worked for me, but your mileage may vary and there’s no warranty here express or implied.

The System

Everyone hates outdated instructions, so I’m going to include the version numbers I’m working with.  The instructions in this guide were executed on a 13-inch MacBook Pro (early 2011 model) running Mac OS X 10.7.5 (Lion) and VirtualBox 4.2.6.  The Arch guest OS is running Guest Additions packages from the Arch community repository, the version numbers for which are virtualbox-guest-utils 4.2.6-1 and virtualbox-guest-modules 4.2.6-3.

Setting Up Shared Folders

Note that before you can begin, you need to have installed and configured the VirtualBox Guest Additions in Arch.  These instructions assume that you’ve done so already.

1. Create a folder on your host OS to be shared with your Arch Linux guest.  Note that this folder has to be in a location that’s not “owned” by a particular user of your host OS.  There’s some weirdness to this, as it appears to be about more than just the permissions assigned to a particular folder.  I’ve found that on OS X, creating a folder either in the ~/Public folder (<–this is where I put my shared folder) or on the Desktop works, while creating a folder in the ~/Documents directory does not, despite the fact that the permissions for some of these different directories are similar.  Also, at this stage, place a text file or some other file in the folder—later on, if you can see and view the contents of this file from within Arch you’ll know the folder’s been shared successfully
2. Identify the shared folder in your VM’s VirtualBox settings. In the VirtualBox Manager window, prior to booting your VM, select your Arch Linux guest and go to “Settings > Shared Folders”.  Click the folder icon with a plus on it to add a shared folder.  For “Folder Path” open the dropdown menu and select “Other…” to launch your host OS’ file browser.  Select the folder you created on your host OS in step one.  For “Folder Name”, if it’s not autofilled, enter a name for the folder to identify it to the Arch Linux guest—to avoid dealing with escape characters and so forth later on, I generally make this something simple, like “Shared”, and avoid spaces or special characters.  For simplicity’s sake, I also usually make this name the same as the name of the folder I created in step one.  “Read Only” should be left unchecked, assuming you want to be able to add files to the shared folder from within Arch.  Also, leave “Auto-mount” unchecked—there’s an alternative configuration in which you leave this checked, but for present purposes it shouldn’t be.  Finally, check “Make Permanent” to have the folder available every time the Arch guest is booted.  When you’ve filled out the form and clicked ‘OK’ your new folder-to-be-shared should appear in the “Settings > Shared Folders” window under the list of “Machine Folders”.
3. Boot your Arch Linux VM.   Log in with your normal user account (i.e., not as root).
4. Create a mount point in Arch for the shared folder. By this, I mean create a folder in Arch where you want the contents of the shared folder on the host OS to appear.  I usually create this folder in my home (~) directory and, for consistency, name it the same thing I named the folder on the host OS, which is also the same “Folder Name” name I gave when identifying it in the VM settings.
5. Test the availability of the shared folder by manually mounting it.  Momentarily, we’ll automate this process, but before we do it’s a good idea to make sure everything’s working correctly.  This is an example of the command to run, which I’ll explain subsequently:

   # sudo mount -t vboxsf -o gid=1000,uid=1000 Shared /home/josh/Shared

   In the above command,

   • sudo is obviously to invoke administrative privileges, which are needed to mount the folder;
   • mount is the mount command;
   • -t is a flag specifying the type of thing to be mounted, which is a Virtual Box shared folder (‘vboxsf’);
   • -o is the options flag, which is there so we can invoke the option to make the folder writable for the users in the group with the number 1000 (gid=1000) and the particular user with id number 1000 (uid=1000).  Assuming this is a personal install and you created only one non-root user account for yourself, user 1000 in group 1000 will beyou, however if you’ve got multiple user accounts or have set up weird group privileges, you may need to look up the group and user id that apply to you;
   • ‘Shared’ is the name you gave as “Folder Name” in step two;
   • ‘/home/josh/Shared’ is the absolute path to the folder you created in step four (my username is ‘josh’).  Note that you have to give this filepath without any shortcuts or symlinks (i.e., ‘~/Shared’ will not work).

   Note that if you want to temporarily share a folder between your guest and host in the future, you can use this same ‘mount’ command in conjunction with VirtualBox’s “Devices > Shared Folders” menu while the VM is running.  The only difference is that the folder you share using “Devices > Shared Folders” will be added to a list of “Transient Folders” rather than the “Machine Folders” list, meaning that it will only be available for the current VM session.

6. Test the shared folder.  Once you’ve run this command, you should be able to see and view the contents of any files you’ve placed in the shared folder on the host OS by navigating to the mount-point folder you created from within Arch.  You should also try copying a file from your Arch system into the shared folder to see if it shows up on the host OS.  If not, you may not have write privileges for the folder, and you should check (1) the folder permissions on the host, as well as (2) the uid/gid you used in your command to make sure they correctly apply to your user account.
7. Add instructions for mounting the folder to /etc/fstab.  If everything’s worked up ’til now, you can go ahead and add instructions for mounting to the folder to your /etc/fstab file.  This will automatically mount the shared folder in the future when Arch boots.  At the end of my /etc/fstab file, I placed the following:

   # VirtualBox Shared Folder Shared /home/josh/Shared vboxsf uid=1000,gid=1000 0 0

   While the order is slightly different, you’ll see that all of the options set here are identical to the ones used in the ‘mount’ command above, so you should set them to whatever the personal equivalents are that you used previously.  The only exceptions are the last two zeroes, which you should just leave as is.  These turn off Linux’s file system backup (‘dump’) and file system check (‘fsck’) for the shared folder, neither of which is needed here.

8. Reboot Arch. At this point, you should be able to reboot Arch and, if everything’s worked correctly, the shared folder should be automatically mounted for you.

Alternative Configurations and an Important Note on the ‘Auto-mount’ Feature

Lastly, I should mention how the method I’ve described here is different from alternatives that some other people use, so there’s no confusion if or when you encounter a forum thread at some point in which people have done it differently.  Some other folks will use much the same process I’ve outlined, but instead of having ‘fstab’ mount their shared folder will instead create a systemd configuration file or initscript to do the same thing.

Still other folks will check “Auto-mount” in step two above, and omit my steps 4–7.  Instead, they create user privileges for Guest Additions within Arch that allow the Guest Additions software to mount volumes by itself.  Guest Additions will then automatically mount the shared folder as an external drive that shows up under the ‘/media’ directory.  I’ve never tried this method personally, but if you wanted to, you could find instructions on doing so with a bit of Googling.

Note that if you use my configuration, you should leave ‘Auto-mount’ unchecked—if you leave it checked, things will work just fine when you boot and while you’re working, but will cause problems when you try to shut down the VM.  At that point, VirtualBox’s ongoing attempt at connecting to the VM as a removable device, hitherto harmless, causes Arch to wig out as it’s unmounting and closing down all the virtual hardware.  This usually induces a slew of error messages ending in a kernel panic (on the VM), and the need for a hard shutdown of the virtual machine.

That’s it!  Hopefully this works for you, and feel free to leave your own critiques, comments, or alternative configurations in the comments.

Author’s Note (3/21/2013): I’m thankful for all the nice things users have said about this guide and all the advice they’ve given in the comments—you folks are great.  There’ve been a number of calls to update this post to reflect recent changes in Arch.  I’ve added a few updates throughout the text and will probably continue to do so once or twice a year until it becomes unwieldy.  With that said, however, given that Arch is a rolling release that changes all the time, keeping this entire post up to date for the indefinite future would be a constant, and quite possibly losing, battle.  That’s why we have the Arch Wiki, edited by the masses and not one guy. It’s also why I put dates and version numbers high up in this post—so people could easily see how dated the instructions were.  Your best experience with this guide will be to use it alongside the Arch Wiki and other resources, so you can take what’s helpful and leave what’s not.  And if you’re coming to this post for the first time, you should also most definitely check the comment thread, where users have added helpful comments and advice about changes that have occurred with Arch since the post was written.  Also, note that while I try to be helpful, I can’t necessarily provide tech support here for everyone following these instructions. Check out the Arch wiki, forums, IRC channel, and Google+ community, as these are your best resources for questions.

As the title suggests, this is a guide to installing Arch Linux in VirtualBox.  However, since there are a lot of these out there at this point, I’ve tried to make it a bit more than a utilitarian installation template, but to put together a more substantive resource for relative beginners, reflecting on why I run Arch and providing a bit more context as to what’s actually going on during the installation process.  If you are indeed a beginner, please also check out Arch Linux’s Beginner’s Guide [H/T nCrazed], a great resource which I wish I’d been aware of when I first started out.  If you know what you’re doing, on the other hand, feel free to skip directly to the instructions and take only what you need, or to find another post or YouTube video that describes the process more concisely.

Introduction

As of this writing, I’ve been a Linux user for around five years.  As with many Linux noobs who began the adventure around the time I did, I started out with Ubuntu.  As a gateway drug, Ubuntu served me well.  It’s easy to use, it installs itself with little user intervention, it familiarized me with *nix in a way that even OS X didn’t, and as with almost any Linux distro you can’t argue with the price.  But it wasn’t long before I wanted to know more about Linux than I did, or at least—given the vast number of Linux distros in the wild and the remarkable customizability of the operating system—to explore a few other options.

Why Arch Linux?

I started out very tame, installing other Ubuntu variants and then Debian (on which Ubuntu is based), before a friendly Linux user suggested that, if I ever wanted to figure out what the hell I was doing, I should try tinkering with a Linux distro that wasn’t based on Debian, just to broaden my perspective a bit.  After a little poking about I decided to try Arch, and that’s when I fell in love.

The philosophy behind the Arch distro is dubbed “The Arch Way” and it revolves around a definition of the word “simple” that diverges sharply from what Ubuntu users think of as “simple.”  For the folks behind Ubuntu, simple means a polished user experience—the idea that your whole system will install instantly, easily and out of the box with all your essential needs met.   At its best, this means that a new Ubuntu user can install the operating system in a few minutes, find the applications she needs already there, and immediately begin loading up her music and pictures, browsing the web, checking her email and working with office documents.

But the Ubuntu philosophy of “simple” can also mean that your new system is bulky, built with every contingency in mind and preinstalled with applications you may never have asked for.  While it’s true that Ubuntu installations can be customized, opening a new default installation can feel a bit like booting up an old Compaq Windows PC for the first time and finding it loaded with “crapware“—software you don’t need and would never have chosen to install yourself.  The introduction of Ubuntu’s custom “Unity” desktop—a new system interface reviled by many users—doesn’t help matters, either.

The Arch definition of “simple” meanwhile is “without unnecessary additions, modifications, or complications.”  In other words, it’s less about user friendliness and more about leanness and customizability.  You can still add a noob-friendly desktop environment to an Arch installation, of course, and as much software as you want.  But out of the box an Arch Linux distro comes without bells and whistles installed.

As with Ubuntu, it comes with a package manager that makes it easy to add new software and update your system from there (Arch is also a “bleeding edge” distribution, which sends out software updates as soon as they become available, with all the benefits—and perils—that such a release cycle involves [H/T Silentl620]), but with Arch you are able from the get-go to choose everything that you want (and don’t want) installed on your computer. Getting my first Arch installation up and running was a revelation in that, for possibly the first time, I had an OS that was exactly as I wanted it.  At its best an Arch installation fits you like a tailored garment, its capabilities and selection of software shaped to your every specification.

This is, of course, possible with other Linux distros as well.  Even Ubuntu makes a “minimal install” package available that will allow you to start small and customize.  And more broadly my treatise here is meant not as a judgment on Ubuntu or a testament to the unique superiority of Arch, but rather as a description of my personal experience switching between the two and the new horizons it opened for me.  Part of my affinity for Arch is no doubt sentimentality surrounding this experience—it’s not just about Arch itself, but about exploring an alternative approach to the OS and having my eyes opened to a greater diversity of philosophies behind Linux and open source computing.

Why an Installation Guide?

Recently, in setting up a new Arch installation, I got to know the distribution even more intimately.  The folks behind the distro have decided to discontinue the auto-installer they had previously offered.  The installation process for Arch is now largely done from the command line, which may be a bit frightening for folks whose idea of “simplicity” is more in line with Ubuntu’s.  But for those willing and interested in learning a bit more about how their OS works—in short, the user base Arch hopes to attract—it’s an interesting and educational process.  And there’s a lot of help out there to step you through it, both in the form of play-by-play YouTube tutorials, and the documentation on the Arch website itself.

Nonetheless, if you’re not an old hand at Linux/Unix, installing Arch for the first time requires a fair amount of digging and reading to learn exactly what you’re doing—especially if, like me, you were unaware of Arch’s Beginner’s Guide when you began.  Whenever I get myself into something like this, I try and take careful notes so that (a) I can easily go back and find the sources I used, and (b) I can repeat the process more easily myself in the future.

And since I’m not a Linux developer, I try to share some of this documentation as a way of giving back to the open source community and paying forward all the help I’ve gotten over the years.  My guides aren’t perfect—keep in mind that they’re inevitably written at the point when I’m still just on the cusp of knowing what the hell it is that I’m doing.  But, without any warranty, express or implied, my hope is that they can help the next person get at least as far as I did.  And often visitors to this site will do everyone a huge favor by correcting my mistakes, updating outdated instructions, and pointing out ways of doing things that are better than those I’ve contributed.  So please check the comment threads for helpful addendums.  And without further ado, here is my guide to installing Arch Linux.  Once again, this worked for me, but there’s no warranty here, express or implied.

Who is This Written For and What Should I Know in Advance?

This tutorial is written for three “typical users,” including:

1. Current users of a beginner-friendly Linux installation like Ubuntu or Linux Mint, who aren’t necessarily computer science nerds, but have gotten comfortable with their OS and would like to branch out and explore another Linux distribution.
2. Web developers and/or Mac users who’ve spent some time in their system’s terminal program and gotten comfortable using the command line, but know little about Linux.
3. Any motivated novice who’s not afraid of looking up terms or tools they don’t yet know based on these instructions.

Generally speaking, I’m assuming you know something about how directory structures (e.g., /path/to/file) are represented in Linux and Unix, and are comfortable doing basic tasks on the command line like changing directories or making new folders.  But even if you aren’t, these are ideas and tasks you can learn in as little as 15 minutes.  So whatever your skill level, feel free to follow along, as well as to add your experiences in the comments to help future readers.

I’ve also borrowed heavily from YouTube tutorials by Sean Bruen and Jonathan Vasquez in putting my own installation guide together, so feel free to check these out as well.

The System

Everyone hates outdated instructions, so I’m going to include the version numbers I’m working with.  First off, as indicated in the title of this post and in the directions below, I’m virtualizing Arch Linux (running it within my existing operating system).  If you don’t know what this means, hang in there—I’ll explain this and other terms below.

The instructions in this guide were executed on a 13-inch MacBook Pro (early 2011 model) running Mac OS X 10.7.5 (Lion).  The virtualization software used was VirtualBox 4.2.4 from Oracle, and the installation media used to install Arch was snapshot version 2012.12.01.

If you’re reading this two years from the date it was written, your mileage may vary.  In theory, these instructions should work on any machine capable of running a recent version of VirtualBox—which currently includes PCs running Windows, Linux, OS X, and Solaris—however it should be noted that virtualizing an operating system tends to require a good deal of system memory and hard disk space.  So if you’re using an older computer or one with fewer resources you may wish to demur, or to install Arch Linux directly to a physical hard drive partition.  In the latter case you may wish to find an installation guide that describes this process more directly.

Lastly, as mentioned previously, while I’m going to attempt beginner-friendly step-by-step instructions for getting Arch Linux working in VirtualBox, advanced users can skip the mundane stuff and grab the things they need.

The Setup

There are numerous ways to run Linux at this point in time.  You can install it directly to your hard drive, either as your only operating system or alongside your existing one.  When the latter is the case, you’re able to decide when you boot up your PC which operating system to use at that time—hence the common name for such a set-up, a “dual-boot system.”  You can also install Linux on an external hard drive, like a USB stick, and then boot your computer from this drive when you wish to run Linux.  You can even use a Linux operating system installed elsewhere on a computer network—so-called “netbooting.”

Or, lastly, you can use the method I describe here, which is to “virtualize” Linux, meaning you can set it up to run as an application within your existing operating system.  Virtualizing Linux—or any other operating system—requires the help of some additional software.  This virtualization software—in our case, VirtualBox—runs as a program on your existing operating system, and its role is create a sort of virtual reality for the new operating system you wish to install.  The idea here is that the new operating system—Arch—will think it’s running on a physical computer, when in fact the “machine” Arch is running on is a fake PC simulated by VirtualBox.  Simply put, VirtualBox dupes Arch into believing it’s running on its own computer, rather than as an application loaded inside of OS X or Windows.

As I’ve said before, there are lots of ways to put Linux on your computer, but I personally choose to virtualize Arch for a number of reasons:

1. OS switching.  When Arch is running inside of OS X, I can seamlessly switch back and forth between applications on both operating systems.  While I’d love to use Linux as my only OS, my work makes this impossible.  And since I’m always tied to OS X, it makes my workflow a lot simpler to be able to use both operating systems simultaneously, rather than having to shut down my computer and reboot into the second OS.  It’s true that a virtualized operating system is slower than one that’s running directly from your physical machine, but on a sufficiently fast computer the difference generally isn’t noticeable unless you plan to do some hardcore gaming.
2. Ease of “hardware” setup. One thing about Linux that’s notoriously difficult for beginners is getting the operating system to play nice with your particular PC’s hardware. I don’t want to exaggerate these difficulties, but one advantage of virtualizing is that the fake computer VirtualBox presents to Arch tends to have fewer quirky hardware compatibility issues to be solved than the actual, physical hardware of your PC.  As we’ll see, getting Arch working with the virtual PC’s hardware presents its own quirks, but in general the setup is comparatively simple when we’re working with a “virtual” computer as opposed to a real one.
3. Failure is free.  If you screw up your virtual machine, it’s a lot easier to repair than your physical one.  Again, I don’t want to overplay this—if you make a mistake installing an operating system to your actual hard drive, it’s easy enough to wipe the partition and start over.  But with a virtual machine, if you screw up the installation process, you can start over instantly.  The “machine” is just a folder of files managed by your existing operating system, which can be deleted in two clicks and recreated again nearly as easily.  This folder also gets backed up by Time Machine (or whatever your system’s backup tool is), so if you break your Linux installation at any point, you can roll back to a working version simply by restoring an older version of the folder from your backup disk.  You can also take “snapshots” of your OS in VirtualBox itself that you can roll back to if you get yourself in trouble—though I admit I generally haven’t made use of this functionality.
4. Portability.  When I change computers, I just copy the folder containing my virtual machine over to my new PC.  Migration complete.
5. Freedom to experiment.  Because you’re not infinitely partitioning your hard drive to install new OSes, and because setting up new virtual machines is so simple, it’s very easy to experiment and try new operating systems.  Try as many Linux distros as you like.  Install Windows 98 and get your Starcraft CD working again.  When I first discovered virtualization, I got carried away and was running a fork of Solaris and some experimental OS from Bell Labs within the week.  You learn a lot by experimenting, and experimenting is a lot simpler and more fun when you’re not worried about destroying your computer.

And, while it may go without saying, all this makes virtualization a great way for beginners to try out Arch Linux, or any other OS for that matter, which makes it well suited to an installation guide for beginners.

Step One: Assemble the Components

All right, that’s probably enough about why I virtualize Arch.  Let’s get down to how to do it.  First, you will need to download two things, both of which are free:

• The VirtualBox Software; download the version that will run on your existing operating system (a.k.a. the “host”).  While the download page lists a number of available tools, there’s no need to grab anything beyond basic VirtualBox—i.e., no extensions or developer kit.
• The Arch Linux Install Media; this is the file normally used to make an installation disk when you’re installing Arch on a physical computer.  Since we’re virtualizing, we won’t need to make an install disk, but we’ll still need the file.  Download it as a torrent or directly from any of the mirrors provided on the Arch download page.

Once you’ve downloaded both of these things, go ahead and install VirtualBox on your computer.  It installs like any other program you’re used to working with, so this part’s easy.

Step Two: Creating the Virtual Machine

After we’ve installed VirtualBox, we get to use it to create the virtual machine on which we’ll be installing Arch.  Again, VirtualBox’s role is to dupe Arch into thinking it’s running as the primary operating system of a physical PC, when in fact it’s running as an application inside your existing operating system.  To do this, we first need to create our fake PC using VirtualBox.

To begin, launch the VirtualBox application as you would any program on your computer.  In the application, there’ll be a series of friendly icons at the top, one of which reads “New”.  Click the “New” icon to create our new virtual machine.

Author’s Note: As I was writing this guide, VirtualBox 4.2.6 came out.  The process for setting up a virtual machine is the same, as are all the options to be selected, however some of the forms depicted below in screenshots have now been combined.

You’ll then be greeted by the following form screen.  You can fill the form out as shown, but VirtualBox should helpfully autofill all of the fields the moment you begin typing “Arch” into the text box.  You can name your machine anything you like, incidentally—I just usually begin the machine name with “Arch” because I’m lazy and I enjoy having VirtualBox fill everything out for me…

Click “Continue” when you’ve filled out this form, and you’ll be taken next to the following form.  Here you adjust the slider to determine how much memory (RAM) your virtual machine is going to have.  You can set the slider to whatever value you like—256 MB isn’t a bad recommendation, but it is on the low end.  My computer’s fast enough that I generally drag the slider to the top of the green zone, which is the upper recommended limit for the virtual machine’s memory.  This makes the virtual computer run faster, but it will also hog more of your real system’s resources, so beware.

Click “Continue” again when you’ve completed the form, and you’ll be presented with the next screen.  Leave this screen as the default—you’re creating a new virtual PC, not loading an existing one, so you want to create a new virtual hard drive.

Click “Create” when you’re done.  You’ll be presented with yet another form (but fear not, you’re nearly done with this part).  In this screen, you’re asked what “hard drive file type” you want.  Again, you can generally leave the default selection, which is .VDI, VirtualBox’s native filetype.  The other options are there in case you want to create a virtual machine that can also run in other virtualization software.  But unless you’re planning on porting your virtual machine to something other than VirtualBox, like Parallels or QEMU, you can use .VDI.

Click “Continue” to move to the following and penultimate form.  This one is asking how much space on your actual hard drive you want your virtual machine to take up.  Choose the default, “Dynamically Allocated”, which means that when you’re only using, say, two gigabytes of your virtual machine’s fake 40 GB hard drive, VirtualBox will only ask for around two gigabytes of actual disk space on your computer, rather than demanding space for the entire fake drive up front before you’ve even used it.  The actual disk space taken up by your virtual machine will, of course, grow as you fill up more of the virtual machine’s hard drive.

Click “Continue” again when you’ve made your selection.  You’ll be presented with one last screen, which asks how big your virtual PC’s fake hard drive should be.  This needs to be at least big enough to fit the operating system with a little room to spare—10 GB is probably a reasonable minimum in this regard.  With that said, you should really set a value that’s big enough that you can actually do useful stuff with your virtual machine—add applications, store photos, collect music, etc.  At the same time, remember that if you fill up your fake hard drive, it’s going to take up space on your real computer.  So don’t set a value that’s bigger than the amount of space on your actual hard drive that you can spare.  Forty GB is probably a reasonable compromise here, though I’ve gone as high as 100 GB when I had the physical hard drive space to spare.  Remember that the OS doesn’t take up this much space at the beginning, it’s just an upper limit on how much the size of the file containing your virtual PC can grow.

Click “Create” to create your new virtual PC.  You should now see it listed among the available virtual machines in VirtualBox’s home window (or perhaps as the only one, if this is your first virtual PC).

We’re not quite done setting up our virtual hardware, however.  Before we boot up our virtual computer for the first time, we still need to configure a couple options that weren’t presented to us in the initial setup process.  Single-click on the name of your new virtual machine in VirtualBox to select it (double-clicking will boot it, we don’t want to do that yet).  Then click the “Settings” icon in the VirtualBox window.  This will bring up a window that shows us all all of the specs of our virtual PC.  On this new window, click on the tab marked “Display”.  This will reveal a view of the machine’s video card specs.  By default these specs are abysmally low—they would prevent us from running a graphical desktop environment in Linux or any software with nice visuals.  So naturally, we’ll want to increase them to something reasonable.

I generally drag the “Video Memory” all the way up to 128 MB and check “Enable 3D Acceleration”, as shown in the following image (3D acceleration is required should you later choose to use some of the newer graphical desktop environments, like GNOME 3).  Note that the 3D and 2D acceleration options were not meant to be used simultaneously, so check only “Enable 3D Acceleration.”

Click “OK” to finish up.  You’re now done setting up the hardware of your virtual PC.  Next, we begin the process of installing Arch Linux.

Also, at this point make sure your PC is connected to the internet, because we’re going to need this connection periodically throughout the remainder of the setup process.  Since some parts of this process are also likely to be memory-intensive, it might not be a bad idea to close up any applications and browser tabs that you aren’t going to need during the installation.

Step Three: Booting Into the Arch Linux Installation Media

To install Arch on a physical computer, we’d need to insert an install disk into our PC’s CD tray and turn it on.  The computer would then boot from the CD, and from there we could install Arch to our computer’s hard drive.  In concept, it’s pretty much the same as most operating system upgrades and installations you’ve done over the course of your life.

The procedure for installing Arch on a virtual machine is pretty much identical, except like the PC our installation disk is also virtual.  When we boot up our virtual PC for the first time, VirtualBox will allow us to load up the the .iso file—the one we downloaded in step one from archlinux.org—as though it were a physical installation CD.

So, at this point, go ahead and double-click on the name of your new virtual PC in VirtualBox to boot it for the first time.  A dialogue window should appear (if it doesn’t fear not and read on) asking you to select a start-up disk.  Click the little folder icon in the dialogue window and it will bring up your computer’s file browser.  Browse to the installation media file that you downloaded earlier from archlinux.org—something along the lines of ‘archlinux-2012.12.01-dual.iso’—and select it.  Then, when you’re returned to the original dialogue window, go ahead and click “Start” to boot your virtual PC from this virtual installation disk:

If everything so far has worked as advertised, you can skip ahead to the next step.  But occasionally, for reasons beyond me, VirtualBox may not offer you the dialogue box allowing you to choose a start-up disk, and may instead try to boot directly into your new virtual PC, which as yet has no data on the hard drive—so unsurprisingly, when it does this it doesn’t get very far.  This state of affairs results in a window displaying an unhappy blank screen reading:

FATAL: No bootable medium found! System halted.

Don’t panic.  Simply go up to the menu bar and select

Devices > CD/DVD Devices > Choose a virtual CD/DVD disk file…

This will bring up a file browser, again allowing you to select the installation media file you downloaded earlier.  Once you’ve chosen it, go to the menu bar again and this time select the following to reboot your machine using the newly selected virtual CD:

Machine > Reset (Host+R)

Interlude: Some VirtualBox Terminology and Quirks Explained

Before proceeding, it’s worth taking a moment to discuss some important terminology and some quirks of VirtualBox.  First, when you’re running an operating system on a virtual machine in VirtualBox, the system running on that virtual PC is called the “guest” operating system.  Your actual everyday operating system, meanwhile, is called the “host” operating system.

The reason I explain this is that when using VirtualBox, you’ll see frequent references to the “Host key.”  As you may already have noticed, your guest OS is displayed inside an application window on your host OS.  And by default, when you begin typing in the window displaying your guest OS, all your keystrokes are directed at that guest OS.  This makes intuitive sense, but it can sometimes produce results that seem alarming unless you remember what’s going on.

For example, when you’re typing in the guest OS and you want to, say, change to another program on your host operating system, you may instinctively type Alt-Tab or Command-Tab, only to be surprised when nothing happens.  This is because the keystrokes, Command-Tab, were registered by the guest OS, not your normal host OS.  In VirtualBox lingo, your keyboard has been “captured” by the guest OS.

Luckily, this isn’t as scary as it sounds.  VirtualBox reserves one key on your keyboard to be a hotkey that, when pressed, will tell the system that whatever you type next is directed at the host operating system (i.e. your everyday computer).  This key is called the “Host Key.”  So, for example, to jump back to your host operating system and use Command-Tab after typing in the guest OS, you would first hit the Host Key, and then type Command-Tab.

By default, the Host Key is your keyboard’s left-hand “superkey”—a.k.a. the command key on a Mac or the Windows key on a Windows PC.  But you can reassign the host key to be whatever key you like.  To do so, first return to your VirtualBox application (note that while it’s running, a virtual machine registers on your computer as a second application separate from VirtualBox, though you should know that both applications must be running at the same time).  Once back in VirtualBox, go to the menu bar and select

VirtualBox > Preferences > Input

Here you’ll see a place where you can assign the Host Key to the key of your choosing.  I use the right-hand command key on my Mac keyboard, since it’s not a key I generally use for anything else.

Now that you know where your Host Key is, you can also use it to perform various keyboard shortcuts defined in the menu bar accompanying your virtual machine as “Host-Somekey.”  For example, Host-F toggles your virtual machine between windowed mode and fullscreen mode (though we’ll have to install some more stuff before fullscreen mode begins to look nice; hold tight a few minutes).

Step Four: Select a 32- or 64-bit Version of Arch Linux

Once you’ve successfully started up your new virtual PC using the virtual installation disk, you’ll see a welcome screen presented.

The screen includes a menu that you can navigate using your keyboard’s arrow keys (no mouse just yet).  The first two options here are the ones that are important to us at present.  They’re asking us to select which version of Arch from the CD we’d like to boot into and ultimately install.  The first, ‘x86_64′, is a 64-bit version of the operating system, while the second, ‘i686′, is a 32-bit version of the OS.  While in a few years time everyone will want to choose 64-bit, at present I typically choose 32-bit for a couple reasons.

First, while 64-bit operating systems and their ability to handle more memory, are undoubtedly the future, at the moment there’s more software available for 32-bit operating systems.  And second, since virtualizing a 64-bit system is a bit more memory intensive, I find that I get slightly better performance when virtualizing 32-bit Arch on my computer.  However, if you select the 64-bit version of Arch, you should still be able to follow along with the rest of this tutorial.  When choosing between the two, here’s a slightly dated, but helpful tutorial.

When you’ve selected the version of Arch you’d like to install, hit the ‘Return’ key to boot the computer from the installation disk.

Step Five: Getting Started and Partitioning Your Virtual Hard Drive

After you’ve selected a version of Arch to install, your new virtual PC will finish booting Arch for the first time from the CD.  You’ll see the OS spitting out a bunch of notifications as the system boots.  And eventually, Arch will present you with a command prompt, signifying it’s ready to take your instructions:

root@archiso ~ #

As experienced Linux users will know, by displaying ‘root@archiso ~’, the command here is telling you that you are currently using the system as the ‘root’ user (i.e., as the all powerful superuser, capable of making any desired change to the system), that the name of the system you’re using is “archiso” (your cue that you’re currently running Arch off the CD; later once Arch is on our virtual hard drive, we’ll get to set our own system name), and finally that you’re currently operating from the root user’s home directory (the home directory of the logged-in user is always nicknamed ‘~’ for brevity).  Lastly, the ‘#’ symbol simply means, “your command goes here.”

Interlude for non-U.S. users

By default, Arch assumes you’re using a U.S. keyboard.  But if you’re typing on something other than a standard U.S. keyboard, the first command you’ll want to issue is the “loadkeys” command, which tells Arch the nationality of your keyboard.  For example…

# loadkeys uk

…should load up a British keyboard.  ’loadkeys be’ should do Belgian, ‘loadkeys cf’ Canadian French, and so forth.  If you’re not sure the letters to use for the keyboard of your nationality, the Arch Wiki has a guide that may be useful.  Generally speaking, where the wiki table says something like…

KEYMAP=fr-latin1

…you’ll want to use the lettering right of the equal sign and left of the hyphen.  So in the above example, ‘loadkeys fr’ for French.

</interlude>

Again, we’re currently running Arch off a virtual CD, but we’d like to copy it over to our virtual machine’s hard drive.  But before we can do that, we need to prepare that hard drive, first by dividing it into the partitions where our Arch installation will live, and then by formatting those partitions so that they’re ready to use.

Partitions are basically different sections of your hard drive that your operating system will treat as distinct drives.  Generally speaking a Linux system uses several partitions, but over the years I’ve gathered that just how many and how they should be organized is something of a religious debate.  As one primer on the matter states, “The question of ‘how many partitions’ continues to spark debate within the Linux community and, without any end to the debate in sight, it is safe to say that there are probably as many partition layouts as there are people debating the issue.”

I’m going to skip this debate entirely and present what I’ve gathered is one of the more common partitioning schemes out there.  Though if you’re interested, you should check out Arch’s primer on partitioning and do a bit of Googling to learn more.  Presently, for the sake of this guide, I’m going to make four partitions:

1. The boot partition // This partition is where your virtual computer’s “boot loader” will live.  More on what this is and does later, but suffice to say we’ll need a boot loader if we want the operating system to start at all.
2. The swap partition // Linux uses this space as extra memory—when the operating system takes on a lot of tasks, it can actually make use of this hard drive space to free up some RAM (i.e., the swap partition provides Linux with “virtual memory”).  If you put your computer to sleep, Linux can also use this swap partition as a temporary place to store the tasks you were working on, and load them back up when you wake up the computer.
3. The root partition // This is the partition that serves as the highest level of your computer’s file system—when other partitions, like “boot” and “home” are loaded up (“mounted”), they will appear as subdirectories of the root partition.
4. The home partition // This is the partition where all the user’s files and personal settings will be stored.

The last thing to discuss before we go and make these partitions is what sort of ‘partition table’ to use.  Basically, a partition table is the system’s ledger for keeping track of how many partitions there are on the hard drive, as well as where each begins and ends.  But this ledger can be kept in different formats.  Two commonly used types of partition tables are MBR (which stands for Master Boot Record) and GPT (which stands for GUID Partition Table).

While I’ve done some reading on the subject, I do not pretend to be an expert with regard to all the ins and outs of choosing one over the other.  MBR is older and some argue out of date.  GPT is newer and apparently addresses some of MBR’s shortcomings.  The Arch documentation recommends the use of GPT over MBR, so that’s what I’ve used and what I’ll demonstrate here.

To create a GPT partition table, we’ll use a command line utility that speaks GPT.  There are several you can choose from, but I’m going to demo the one I’ve used most, called ‘gdisk’.

The only other thing we need to know before getting started is how the install disk we’re running is representing our virtual PC’s hard drive.  The drive shows up just like a file; if you look at the contents of the CD’s /dev directory, by entering the command…

# ls /dev

…it will be displayed as an object called ‘sda’, which stands for SATA Drive A.  (If we had a second hard drive, it would be listed as ‘sdb’ for SATA Drive B, and so on.)

Now that we know the program we’ll be using to create our partition table (gdisk) and we know where to find the hard drive we’ll be partitioning, it’s time to go ahead and create the partition table for our virtual PC’s hard drive.  To do this we’ll fire up gdisk and tell it we want to work with ‘/dev/sda’—enter the following on the command line:

# gdisk /dev/sda

The gdisk partitioning program will start, offering a prompt that looks like this:

Command (? for help):

Type ‘p’ at the prompt and hit ‘Return’ to see an intial summary of your system vitals.  Now, let’s create the four partitions I discussed above.  To create the first partition, our boot partition…

1. Type ‘n’ at the prompt and hit ‘Return’ to tell gdisk you want to create a new partition.
2. When it asks for a partition number, hit ‘Return’ to accept the default (1).
3. When it asks for a “first sector”, hit ‘Return’ to accept the default.  This will start the partition at the beginning of your virtual hard disk.
4. When it asks for a “last sector”, type ‘+250M’ (without quotes).  This will make the boot partition 250 megabytes in size, which is large enough for the boot loader software we’ll be installing there in a few minutes. Hit ‘Return’ to continue.
5. When it asks for a “hex code”, it’s asking you to give it a number that corresponds to the type of filesystem you’d like that partition to use.  As you may have guessed from the prompt, you can leave the default (8300 for “Linux File System”) and hit ‘Return’.

At this point the boot partition has been drafted—gdisk knows what you want—but, importantly, it hasn’t yet been implemented.  We’re first going to create all of our partitions in gdisk, and then when we’re done drafting them, we’ll end by asking gdisk to write them to our virtual hard disk.

So it’s now time to create the second of our four partitions, the swap partition.  Before we create this one, I should add a few words of context.  In the instruction that follows, I create a 2 gigabyte swap partition.  Be aware, though, that if you gave your virtual system a small amount RAM when you created it in VirtualBox, you may be able to get away with a smaller swap partition.  And if you gave your virtual system 2 gigabytes or more of RAM, you may not need a swap partition at all (though for better or worse, I’ve generally created one anyway, despite configuring my virtual machine with quite a bit of memory, and I’m demoing it here).  For some pointers on how large your swap partition should be,  check out the guide in the Arch wiki.  Now, assuming you’re with me, let’s create the swap partition:

1. Type ‘n’ at the prompt and hit ‘Return’ to tell gdisk you want to create a new partition.
2. When it asks for a partition number, hit ‘Return’ to accept the default (2).
3. When it asks for a “first sector”, hit ‘Return’ to accept the default.  This will put the start of the new partition right next to the end of the previous one on the hard disk.
4. When it asks for a “last sector”, type ‘+2G’ (without quotes).  This will make the swap partition 2 gigabytes in size, which is plenty of room in almost all cases (see the note above).  Hit ‘return’ to continue.
5. When it asks for a “hex code”, it’s asking you to give it a number that corresponds to the type of filesystem you’d like that partition to use.  In this case, we don’t want the default.  Type ’8200′, which is the hex code for ‘Linux swap’ and hit ‘Return’.  (For those who are interested, here’s a link to a list of the different hex codes for all the various file types gdisk can create.)

The third partition we want to create is the ‘root’ partition.  This partition should be sizable, because when you start downloading applications they’re going to live here and some of them will be large.  I’ve made the mistake of making this partition too small before, and suffice to say that it’s not enjoyable when you run out of space.  It’s often a year or two into using the system that this partition fills up, resizing it turns out not to be as simple as you’d like, and at that point you’ve already put a bunch of files onto your system and won’t be thrilled about the idea of migrating to a new virtual machine.

In this tutorial, I created a machine with a 40 gigabyte hard drive.  I’m going to give the root partition 15 gigabytes of that space (though you could probably get away with 10 GB, or less if you don’t plan on installing too much stuff).

1. Type ‘n’ at the prompt and hit ‘Return’ to tell gdisk you want to create a new partition.
2. When it asks for a partition number, hit ‘Return’ to accept the default (3).
3. When it asks for a “first sector”, hit ‘Return’ to accept the default. This will put the start of the new partition right next to the end of the previous one on the hard disk.
4. When it asks for a “last sector”, type ‘+15G’ (without quotes).  This will make the boot partition 15 gigabytes in size, which is roomy enough for our applications and system updates. Hit ‘Return’ to continue.
5. When it asks for a “hex code”, it’s asking you to give it a number that corresponds to the type of filesystem you’d like that partition to use.  In this case, you can once again leave the default (8300 for “Linux File System”) and hit ‘Return’.

All right, we’re now almost done with the partition scheme.  We have one last partition to create, which is the ‘home’ partition, which is the place on the machine where all our personal files and settings will live.  This one’s the simplest one yet.

1. Type ‘n’ to create a new partition and hit ‘Return’ as usual.
2. Then just go through and hit ‘Return’ repeatedly to accept the default partition number, first sector, last sector, partition size, and hex code.  This will create a final partition with a Linux filetype that fills the remainder of our virtual hard drive.

Now type ‘p’ and hit ‘Return’ to see the finished partition scheme. It should include all your newly defined partitions with the information you entered.  Mine looks like this:

Make a note of the different partition numbers (i.e., which is the boot partition, which is the root partition, and so on)—as you might expect, they’re going to be important again soon.  Also make a note of which numbered partitions have been prepared for a ‘Linux filesystem’ and which partition number is the ‘Linux swap’ partition.

Now that we’ve drafted all our partitions, type ‘w’ at the gdisk prompt and hit ‘Return’  to write the partition scheme to the disk. When gdisk asks whether you’re sure you want to do this, type ‘Y’ and hit ‘Return’ to say yes.  Gdisk will implement your partition table and then quit, leaving you back at the command line:

root@archiso ~ #

Step Six: Formatting and Mounting Your New Disk Partitions

Next, back at the command line, we’re going to format our new disk partitions so that we can begin using them. This is not unlike formatting any other disk, except perhaps that you may be used to doing this with a mouse and a desktop GUI.  We’ll be doing the same thing from the command line.

The partition numbers you jotted down above should now correspond to new objects in the /dev directory, each with the prefix ‘sda’.  So, for example, partition one can now be manipulated from the command line using the handle ‘/dev/sda1′.  Partition 2 is ‘/dev/sda2′ and so on.

We’re first going to format the partitions for which we anticipated using a Linux filesystem (which, if the instructions above were followed, are sda1, sda3, and sda4).  There are actually multiple types of ‘Linux filesystem’ that can be used in formatting your drive.  You can read about all the choices here, but note that the filesystem type ‘ext4′ is the one recommended by Arch, so this is what we’ll use.

Again, in the partition scheme I’m using, partitions 1, 3, and 4 each need to be formatted with a Linux filesystem (‘ext4′).  To format them, I’ll run the following commands from the command line:

# mkfs -t ext4 /dev/sda1
# mkfs -t ext4 /dev/sda3
# mkfs -t ext4 /dev/sda4

To briefly break down what’s going on here, the command ‘mkfs’ is short for “make file system”, the flag ‘-t’ means “of type”, I then specify “ext4″ and finally, I give it the location of the particular partition I want to format (e.g., /dev/sdax).  In summary, each command translates to “make file system of type ext4 on partition /dev/sdax“.

We’ve now formatted all the partitions using a Linux filesystem, but we still have to format the swap partition (in the above scheme, ‘/dev/sda2′).  To do this, we now run the command:

# mkswap /dev/sda2

We’ve now formatted all the partitions on our virtual hard drive.

Step Seven: Mounting the New Hard Drive Partitions

Even after formatting the hard drive partitions, though, we’re presently still running Linux off a CD.  We still need to install Linux to the drive we’ve just formatted.  And the final step before putting Linux on our new virtual machine is to mount our new hard drive partitions—i.e., load them up—so that we can access them and write files to them.  Once we have access to our new hard drive partitions, we can finally put Linux on the hard drive.

First, we’ll load up our swap partition—since it serves as virtual memory, it’s a bit of a funny partition, and the command for loading it is unique.  Rather than “mounting” a swap partition, we “turn it on.”  One thing to know is that, since the swap partition serves as memory, not as file storage we won’t actually be loading files onto it.  However, we still need it turned on at this point because we’ll soon be generating a file called ‘fstab’ that will—in the future—automatically mount all our computer’s partitions when our Linux system boots.  To generate the fstab file, the system is going to take a census of all the mounted partitions so it knows what they are and can include instructions in the fstab file for loading them up.  The swap partition needs to be turned on beforehand, so that it will be counted in this census.

To do so, run this command (if you’ve partitioned your drive differently than I’ve done in this tutorial, you can replace ‘/dev/sda2′ with the location of your own swap partition):

# swapon /dev/sda2

Next, we’ll mount our root filesystem and make it accessible under the directory /mnt. Doing this means that—at least temporarily—when we browse to the /mnt directory on the CD, we’ll be able to view and add files to the root partition of our system’s hard drive.  In unix lingo, we’re using /mnt as the “mount point” for the root partition.

To mount the new root partition on /mnt, run this command:

# mount /dev/sda3 /mnt

Now, the root partition is accessible to us.  Let’s navigate to it on the command line by cd’ing over to /mnt:

# cd /mnt

We’d also like to be able access our boot partition and our home partition. So within /mnt we’ll create two new directories to use as mount points for these additional partions (i.e., the ‘boot’ partition and the ‘home’ partition).  Note that in making these directories inside /mnt, we’re actually creating them on the hard drive itself.  As such, they’ll be able to be used as the mount points for these partitions in the future, when we’re running Linux from the hard drive instead of from a CD.  Make the ‘boot’ and ‘home’ directories now using this command (note that if you’re using a partitioning scheme that doesn’t include ‘home’ or is arranged differently from my example, you’ll need to change this command accordingly and make folders that correspond to your own partitioning scheme):

# mkdir boot home

Next, while still in the /mnt directory, run the following commands to mount the remaining partitions to the directories we just created.  In this example, /dev/sda1 is the boot partition we created and formatted earlier, so it gets mounted on the ‘boot’ directory, while /dev/sda4 was the home partition we created and it gets mounted on the ‘home’ directory.  Again, if your partition scheme is different than what I’ve been using in the example, change, add, or omit the commands accordingly:

# mount /dev/sda1 boot
# mount /dev/sda4 home

Since sda1, sda3, and sda4 have now been mounted and swap is on, all four partitions I created in this example are now accessible.  You should similarly have loaded all of your own partitions.  It’s time to install Arch.

Step Eight: Installing Arch Linux

While it’s not strictly necessary, I tend to navigate back to the root level on the command line at this point:

# cd /

Now that we have access to all the partitions on our virtual machine’s drive, we can go about installing Arch Linux.  The good folks behind Arch provide a number of installer scripts that are already available to us as shell commands on the CD we’re running (in English this means they’ve automated a lot of the setup for us).  These scripts will do a lot of the work for us of installing the operating system to our virtual machine.  The first installer script we’ll use is called ‘pacstrap’.  We’ll run this command to download and install the ‘base’ and ‘base developer’ packages to our hard drive.  The ‘base’ package contains the bare essentials of Linux, while the base developer, or ‘base-devel’,  package contains tools that are ostensibly for developers, but which tend to come in handy in a lot of contexts.  These tools occasionally get used indirectly by other software as well, and as such may be useful even when you’re not aware you’re using them.

We want to put Arch Linux on our root partition, which remember is currently available to us as /mnt.  To install the ‘base’ and ‘base-devel’ packages to the root partition, run the following command:

# pacstrap /mnt base base-devel

Since we’re currently installing the whole operating system, this command may take a few minutes to execute.  You can stick around and watch the progress bars if this sort of thing fascinates you, or you can go get a cup of coffee and come back when it’s finished.

Step Nine: Generating the ‘fstab’ File

Arch Linux is now technically installed!  But don’t go trying to reboot into it just yet or you’ll be in for a nasty surprise.  While most all the files necessary to run Arch are now in place on your virtual machine’s root partition, if you reboot your machine, it’s not going to know where to find that partition (or even how to start up, but we’ll take care of that, too, momentarily).

As mentioned previously, when Arch Linux boots, it will need to make use of a file called ‘fstab’ that contains instructions on starting up all your Linux system’s various partitions.  We still need to create this fstab file.  Quite handily, this process can be automated as well by another Arch installer script called ‘genfstab’.

To generate your system’s fstab file, run the following command:

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

This will analyze your virtual machine’s hard disk partitions, currently loaded up under /mnt, and write out an ‘fstab’ file.  This fstab file will, from now on, reside in the /etc folder on your virtual machine’s root partition, and the file’s job is to automate the process of mounting all your system’s hard drive partitions in the future when your virtual computer is booted up.  The script will also detect the swap partition you turned on earlier and include instructions in fstab for loading it up, too.

To check and see that the fstab file was generated correctly, you can display the contents of the file using the ‘more’ command:

# more /mnt/etc/fstab

This will display the contents of ‘fstab’ on the screen and return you to the command prompt (occasionally you may have to hit the space bar a time or two to see the whole file before being returned to the command prompt).  Even if you’re not quite sure what a proper ‘fstab’ file looks like, you should be able to tell if the process worked, (a) because when you execute the ‘more’ command a file turns up with stuff in it (which means that the genfstab command did something), and (b) the file contains mentions of all the hard disk partitions you created earlier (in my case, ‘/dev/sda1′, ‘/dev/sda2′, ‘/dev/sda3′, and ‘/dev/sda4′).

The fstab file spit out by ‘genfstab’ on my system looks like this:

Note that even if you’re following along with this tutorial in lockstep, the UUID numbers included in your fstab file may be different than the ones in this screenshot.  These are unique to every machine and partition.

Step Ten: Initial Installation of the Boot Loader

Now we’ve installed Arch Linux and told it how to load up the various partitions we created.  Aside from a bit of configuration, which we’ll get to momentarily, there’s one really important component that’s still missing before our virtual machine will run correctly, and that’s the “boot loader.”  What, you might wonder, is that?

When a computer boots up and the hardware first kicks into action, it’s momentarily a body without a brain.  Until it can load up the software installed on the hard drive, it has no idea what it’s supposed to be doing.  But how does a brainless machine go about finding its brain?

The process is akin to how those of us with poor eyesight go about finding our glasses in the morning—by putting them on the nightstand, or some other place we can quickly and reliably find them without thinking about the problem.  For the computer, this means having some special software placed at the very beginning of the system’s hard drive (i.e. the first place the computer looks when the hardware kicks into action) whose only job is to help the computer load up the rest of the operating system.  In other words, if the hardware can find the boot loader in the expected place, it can load up the rest of its brain.

So, what that means for us is that before trying to boot into our system for the first time, we need to install a boot loader and put it in the place the computer expects to find it.  The fact that our “computer,” in this case, is a virtual rather than an actual machine makes little difference in how it operates in principle.

There are several commonly used boot loaders out there.  Most people use either GRUB2 or Syslinux.  You can read up on the selection, but for a relatively basic setup like the one I’ve been describing here, it matters relatively little which you choose.  Here I’m going to describe setup using Syslinux.

Author’s Note [3/21/2013]: As Christoph Schniedermeier pointed out in the comments, and as I discovered myself since writing this guide, there’s a simpler way of installing Syslinux.  Read on, but check out the Beginner’s Guide for a look at the syslinux-install_update script and, if you choose the Beginner’s guide method, skip from here to Step Eleven at this point.

To begin installing Syslinux, we’re going to use another handy installer script, which can be executed as follows:

# pacstrap /mnt syslinux

Note that we’ve still got some work left to do before we’ve finished installing the boot loader, but we’ve now completed the first step.

Step Eleven: Configuring the New Linux Installation on Your Hard Drive

Again, we’re not quite done installing the boot loader.  To finish up, we’re going to log into our new system for the first time, and while we’re there we’re going to take care of some other important configuration as well.

Luckily (since our boot loader’s not configured yet), it’s possible to log into our new Arch Linux install without rebooting the machine, but by instead using the command ‘arch-chroot’.  This command will transport you, at least temporarily, from the version of Arch Linux that you’re currently running off the CD into the new Arch Linux installation that you’ve just placed on your hard drive.  To be thusly air-dropped into the root partition of your new installation, run the command as follows:

# arch-chroot /mnt

You’ll get a new command prompt, different from the one you’ve been using up ’til now, which signifies that you’re now logged into, and using, the Linux installation on your hard drive.  Depending on your installation media, it’s possible that the command prompt will look something like this:

sh-4.2#

If that’s the case, it means that you’re currently using the most basic shell (command line interface) Linux has to offer.  You’d probably rather use the BASH shell, which is a command line interface that is a bit more fully featured [H/T Railmaniac].  To use BASH, run the following command:

# bash

This will give you a version of the command prompt that looks like this instead, and which gives you the greater functionality of the BASH shell:

[root@archiso /]#

Now that we’re logged into the new Arch Linux installation on our hard drive for the first time, it’s time to configure it.  We’ll get back to completing the installation of the Syslinux boot loader momentarily, but first we’ll set up a few other things that are also important.

First, your Arch Linux install wants to know where you live.  Not in a creepy stalker kind of way, but rather so it can present text to you in your own language and so forth.  So let’s set up our locale preferences.  To do this, we first need to create and/or edit a couple files—’/etc/locale.conf’ and ‘/etc/locale.gen’—that contain this information.  Like most configuration files on Linux, both of these are plain text files, and to edit them we’ll use the command line text editing program, “nano”.

First, we’ll create the file ‘/etc/locale.conf’ in nano.  To do so, enter the following on the command line:

# nano /etc/locale.conf

This will open a blank text file in nano that, when saved, will become ‘/etc/locale.conf’.  Assuming you are a U.S. user with American English as your preferred language and dialect, type the following in this blank document (If you’re working in a different language, search the Arch Wiki in your language for instructions on what to put instead.):

LANG="en_US.UTF-8"

To save your changes and exit back to the command line, type Control-X to quit nano, and when asked if you want to save your changes, type ‘Y’ for ‘yes’.  Finally, hit ‘Return’ to confirm that you want to save the file with the pre-filled filename.  The file will be saved and you’ll be dropped back to the command prompt.

Next, we’ll edit ’/etc/locale.gen’, again using nano.  To do so, enter the following command:

# nano /etc/locale.gen

This file already exists, so you’ll see a long text file open in nano and fill up your screen.  You can move your cursor and scroll throughout the file using the arrow keys on your keyboard.  Find the two lines that correspond to your language and dialect.  For English-speaking Americans, these would be:

#en_US.UTF-8 UTF-8
#en_US ISO-8859-1

Delete the ‘#’ preceding each of these lines (i.e., “uncomment” them).  This will cause the system to pay attention to these two lines specifying your language of choice, while continuing to ignore the rest.  At this point, save the file and exit back to the command line.  Again, in nano this is done by typing Control-X to quit nano, then ‘Y’ for ‘yes’ when asked if you want to save your changes, and finally ‘Return’ to accept the suggested filename.

Now that you’ve gone through and arranged Arch Linux’s configuration files to use your language of choice, you lastly need to implement these changes.  This can be done by running this command, back at the command line:

# locale-gen

Next, we’re going to tell Linux what time zone we’re in.  To do this, we’ll be typing some version of the following command (which, if run as-is would set your time zone to correspond to the time in New York City/US Eastern):

# ln -s /usr/share/zoneinfo/America/New_York /etc/localtime

Chances are, though, that you don’t live in the Eastern time zone.  Luckily, there’s still help for you.  To find your time zone, begin typing the above command, but don’t run it yet.  Instead, assuming you’re in North or South America, type the command only up to the this point…

# ln -s /usr/share/zoneinfo/America/

…and then hit the ‘Tab’ key a couple times.  The BASH interface will ask you if you want to display all the available possibilities.  Type ‘y’ for “yes” and it will display a list of cities you can use to identify your timezone.  Make a note of the city you want to use.  This list is long enough that it’s paginated and you may have to hit the spacebar once to see the whole list.

Once the whole list has been displayed, you’ll be dropped back at the command line, where you can finish typing the rest of your command, which again should look like my example above, but with your own city of choice inserted.  For example, if you chose the city of Anchorage, your command would look like this:

# ln -s /usr/share/zoneinfo/America/Anchorage /etc/localtime

If you live outside the Americas altogether, you can similarly find your time zone by hitting tab repeatedly after ‘zoneinfo’ to find your continent, then filling this in and doing the same thing to find your nearest city.

However you get there, once you’ve found your reference city of choice, run the command to set your timezone.  What’s actually happening here, is that you’re creating a “symbolic link”—akin to a desktop shortcut or alias if you’re used to Windows or OS X—that refers Linux to the the specific timezone configuration file you’ve identified whenever it looks for the file ‘/etc/localtime’.

Now we’ll set up one last aspect of our system before we finish configuring our boot loader and boot into our new Arch Linux machine for the first time.  The thing we’re configuring next is our machine’s “hostname,” which is the name that traditionally identifies your system to your local computer network.  This can be pretty much anything, but it’s generally something descriptive, like “archlinux” or “joshscomputer”.  Think up whatever you’d like.  Generally speaking, it should have no spaces in it and be something simple and straightforward.

To set the the hostname, create the file ‘/etc/hostname’ in nano with the following command:

# nano /etc/hostname

This will bring up a blank file in nano.  Type your hostname as the only line in the file.  Then quit to the command line in the usual way, saving your changes as you go.

Step Twelve: Finishing the Boot Loader Installation

Author’s Note [3/21/2013]: If you’re using the ‘syslinux-install_update’ method from the Beginner’s Guide to install Syslinux, you can skip from here to the paragraph on ‘mkinitcpio’ below.

 Now, while we’re still logged into our hard drive’s Arch Linux installation, let’s configure the boot loader. On the command line, navigate to the /syslinux directory, which resides in your /boot partition:

# cd //boot/syslinux/

Inside this directory, there’s a file called ‘syslinux.cfg’.  This file contains a list of other support files that must be copied over to the /boot/syslinux directory from another directory on your system called /usr/lib/syslinux/ in order for the boot loader to work correctly. To see this list, we’ll take a look at the contents of ’syslinux.cfg’ by  using the ‘more’ command:

# more syslinux.cfg

Near the top of the file, you should see a list of “comboot modules”, similar to that pictured below.  This is the list files we’re going to need to copy over to the present directory.

Make a note of the filenames in this list, and then type Control-C to quit to the command line (or press the spacebar continuously to page through the file, which will drop you back at the command line once it’s finished displaying).

Next, we copy the specified files into the /boot/syslinux from the /usr/lib/syslinux directory by running the following commands:

# cp /usr/lib/syslinux/menu.c32 .
# cp /usr/lib/syslinux/vesamenu.c32 .
# cp /usr/lib/syslinux/chain.c32 .
# cp /usr/lib/syslinux/hdt.c32 .
# cp /usr/lib/syslinux/reboot.c32 .
# cp /usr/lib/syslinux/poweroff.com .

Once this has been done, we run the following command to install Syslinux to the /boot partition, which you’ll recall is at the beginning of the hard drive, where the hardware looks when it wakes up:

# extlinux --install /boot/syslinux

A few notes on the above command.  First, why is the command titled ‘extlinux’, rather than ‘syslinux’, since it’s Syslinux that we’re installing?  The answer is that, while Extlinux was at one time a spinoff of Syslinux, the two versions of the boot loader software have since been merged.  So in fact, they’re the same thing.  The ‘extlinux’ command thus installs the files required for ‘syslinux’.

Second, didn’t we install Syslinux previously with the ‘pacstrap’ command in step ten?  And if so, why are we installing it again here?  This is a subject I’m a bit less clear on, and which I haven’t been able to find a terrific answer to yet (please provide one in the comments if you know!).  The best answer I have is that (a) with the pacstrap command we previously installed Syslinux files to our hard disk’s root partition (though syslinux.cfg did end up here), whereas now we’re installing them to the /boot partition, and (b) since we’ve already been copying files over to /boot from the root partition, the files on the root partition must serve as a resource for installing the boot loader to the boot partition, which I take it also means (c) that the ‘extlinux’ command was probably made available to us by the ‘pacstrap’ installation we did earlier.

Still, when I list the files in the /boot/syslinux directory after running this command, I don’t see anything we didn’t put there ourselves, so I confess I’m not sure what’s going on with the ‘extlinux’ command, beyond the fact that running it was a necessary part of the other, more terse installation guides I read through.  Suffice it to say that (a) this works, and (b) I have a good deal more to learn about Syslinux.

In either case, now that we’ve finished configuring the boot loader, we’ve still got a few steps left to go to get our new virtual PC ready to boot.  In order to tell the computer what’s what, Syslinux is going to need to have something called the “booting protocol”—instructions to run in order to boot the system—ready to hand.  The sort of boot protocol Syslinux requires depends on the method you’ve used to partition your hard drive.  Since we’ve partitioned using GPT, Syslinux is going to need a boot protocol that works with GPT partitioning.

There is such a file available, called ‘gptmbr.bin’, and at this point we’re going to write a copy of it to the very beginning of our hard disk, so it’s the first thing that the machine’s hardware sees when it boots.  To do this, use the following command—be very careful to enter this one correctly, as a mistake could screw up your virtual PC for reasons that will become apparent in the subsequent explanation:

# dd conv=notrunc bs=440 count=1 if=/usr/lib/syslinux/gptmbr.bin of=/dev/sda

The ‘dd’ command above is a special unix command capable of reading and writing data to and from hardware devices.  In the above command, it’s taking data from the input file (if) ‘/usr/lib/syslinux/gptmbr.bin’ and writing it to the hard drive, which you may recall is represented in the file system as the object ‘/dev/sda’ (the ‘output file’, or of).  As the other portions of the command get a bit esoteric, I’m not going to bother to explain their intricacies, but if you want to know more, you can read up on the ‘dd’ command on Wikipedia and on this specific use of the command on the Syslinux wiki.

Next, we’ll run another handy script called ‘mkinitcpio’, which is going to set up the initial ramdisk (memory) environment for our virtual PC.  This serves as the computer’s memory when it first boots up, before it finds the rest of its brain.  If you want to customize this environment, you can read up on mkinitcpio and modify ‘/etc/mkinitcpio.conf’.  But if you’re not doing anything fancy, you can skip making any modifications and simply run the command:

# mkinitcpio -p linux

In English, this translates to “Make an initial ramdisk environment (mkinitcpio) using presets (-p) suitable for Linux”.

We’re now very nearly finished installing Arch Linux.  There are still a couple loose ends to be tied up, which will be covered in the next step.

Step Thirteen:  Finishing Up the Installation

We’ve got a couple loose ends to tie up as we back out of the system we’ve just installed and prepare to reboot our virtual PC.  First, now that we’re preparing to boot into a fully functional system for the first time, we’d like a bit of security.  It’d be best if, in the future, no one could log in and make the sorts of changes we’ve just made without first entering a password.  To set a password for your system’s “root” user—the all powerful super user—enter the following command:

# passwd

You’ll be prompted to enter and re-enter a password.  Make sure to remember it, as you’ll need it in both the near and foreseeable future.

We’re now done making changes from within our virtual PC’s Arch Linux installation. The next step will be to transport back to working from the Arch Linux Install CD.  To do so, type the command:

# exit

If you entered the ‘bash’ command earlier to work with the BASH command line, this may only drop you back to the standard command prompt.  If you still see this…

sh-4.2#

…then enter the ‘exit’ command one more time to get back to the CD environment.  What you want is to see the original colorful command prompt beginning with ‘root@archiso’ that you first saw when you booted Arch from the CD, and absent the square brackets we’ve been seeing as part of the prompt since we first entered the ‘arch-chroot’ command.   When you’re back to this prompt, it will indicate that you’re once again working from the Arch Linux installation CD, rather the copy of Arch on your hard disk.

Once you’ve returned to the CD’s command prompt, it’s time to unmount all the partitions we mounted earlier.  If you’re using the partitioning scheme I’ve been demonstrating, the commands will be as follows (you can alter these as needed for your own partition scheme).  Note that you should unmount the root directory, mounted at /mnt, last since other partitions are mounted within it:

# umount /mnt/boot
# umount /mnt/home
# swapoff /dev/sda2
# umount /mnt

Once this has been done, we’ve only one last command to run before rebooting into our new system.  Before rebooting, run this command from the installer disk’s command prompt, which will set the /boot partition’s BIOS flag to “bootable”—basically, tell the computer’s lizard brain which partition to boot—and allow your new system to boot on restart:

# sgdisk /dev/sda --attributes=1:set:2

For context, sgdisk is a disk utility program similar to gdisk, which we used earlier, but which can take instructions directly from the command line, rather than by entering into an interactive mode (i.e., engaging in a Q&A with the user).  The command, in English reads “Using sgdisk, examine the device found at /dev/sda (which is our hard drive).  Give partition 1 the attribute of being bootable (’2′ means ‘legacy BIOS bootable’).”  The reason we didn’t simply do this earlier in gdisk is that gdisk doesn’t appear to offer this option—probably because under GPT, we’re not supposed to have to set a boot flag (one of its advantages).  Unfortunately, not all hardware is smart enough to realize this, so we have to set it anyhow.

Step Fourteen: Rebooting Into Your New Arch Linux Machine

And that’s it!  Your virtual PC is now completely set up and Arch Linux has been installed and configured.  It’s time to reboot into your new system!  To do so, just enter the command:

# reboot

When the virtual machine reboots, it will boot from the CD again, which isn’t what you want from now on.  So, when the CD’s boot screen comes up, go to the VirtualBox menu bar and select:

Devices > CD/DVD Devices > Remove disk from virtual drive

Now, attempt to close the application window in which your virtual machine is running.  A dialog panel will come up asking what you’d like to do.  Select ‘Power off the machine’ and click ‘OK’.

Now that the virtual installation CD has been “ejected” from our virtual machine, we can boot it up directly from the hard drive, which is what we’ll be doing every time in the future.  To do this, just double-click on the virtual machine in VirtualBox to start it once more.

This time, when the system starts up, you’ll be presented with a boot menu, created by Syslinux, which asks you what you’d like to do:

Hit ‘Return’ to select the first option, ‘Arch Linux’, which will continue booting you into Arch Linux.  Note that if you don’t make a selection, this option will be chosen automatically and the boot process will begin after five seconds.

Once your system has booted, you’ll be asked to log in.  Sometimes the login prompt will come up, only to be followed by a few more status messages from the boot process.  If this happens, just hit ‘Return’ to see the login prompt again.

Since you’ve yet to create any user accounts, your login name should be ‘root’ to log in as the root user.  The password will be the one you set at the beginning of step thirteen.  Once you’ve entered these credentials, you’ll be given a command prompt.  Your new Arch Linux system is ready and awaiting your instructions.

Step Fifteen: Some Housecleaning that Will Make the System More Usable

First, when we booted from the CD, Arch automatically connected to the internet for us in anticipation of our needing it to install the system.  But this time around, we have to tell the system to connect to the internet.  We’ll automate this momentarily, but for now, to connect to the internet run the command:

# dhcpcd

One beautiful thing about using virtualization software like VirtualBox is that it saves us having to configure wireless internet from the command line, which is never very fun.  Our virtual computer drafts off our real computer’s internet connection (wireless or otherwise), while thinking its connected to the ‘net via an ethernet cable.

Update [3/21/2012]: As noted in the comments, a little while ago Arch got rid of the ‘adduser’ script, which is basically just an interactive interface for the command ‘useradd’. So you’ll now need to use the ‘useradd’ command to create a new non-root user.  There’s a helpful guide to how to do this here. When following the examples, though, remember to add the ‘-d’ flag to the command or your new user account will have no home directory.

Next, it’s more secure and more convenient to create yourself a user account, rather than continuing to use your Linux install as ‘root’.  To create a user account for yourself, run the command:

# adduser

This will start an interactive program that will take you through the process of adding a user.  If your Linux install is for personal use, however, not all the questions it asks are going to be necessary or relevant.

You should definitely enter a username when prompted.  This will be the name you use to log in to your system in the future.

You can then just continue hitting ‘Return’ to accept all the defaults, including when you’re asked whether you’re sure you want to create the account.  The next prompt you’ll want to pay attention to is the one reading…

Name []:

Your response to this prompt will determine how the system displays your name whenever it’s not using your login ID.  So I generally put my full name, ‘Josh Braun’.

After you’ve entered your name, you can start hitting ‘Return’ again to accept defaults until the system asks for your password.  Here, you’ll enter—and then subsequently reenter—the password that you want to use to log in to the system in the future.  Once you’ve entered this information, you’ll be dropped back to the command line.  You’re finished creating a new user account for yourself.

Though you now have a new user account for yourself that’s separate from ‘root’, you’ll occasionally want to perform administrative tasks without having to log out of your personal account and log back in as the root user.  To do this, you can use the ‘sudo’ command, which means “perform my command as the root user.”  However, before we can take advantage of the ‘sudo’ command, we have to install the ‘sudo’ on our system.

Arch Linux has a handy package manager, called ‘pacman’ that automates the process of installing, uninstalling, and updating software on your computer.  You’ll be using it frequently in the future.  The command ‘pacman -S somesoftware’ tells pacman to install ‘somesoftware’ on your machine.  In this case, to install ‘sudo’, we use the following command:

# pacman -S sudo

Follow any prompts provided by pacman to install the software.

Once ‘sudo’ has been installed, we need to tell it that your new user account is one that should have access to administrative privileges.  To do this, we’ll need to edit a configuration file called ‘sudoers’, located in the /etc directory.  Again, since this configuration file is just a text file, we’ll use nano to edit it:

# nano /etc/sudoers

Once the file opens, find the lines reading:

##
## User privilege specification
##
root ALL=(ALL) ALL

Below the line beginning with ‘root’ shown above, add an identical line, but this time replacing ‘root’ with the new username you just created.  For example, if I created the login ID ‘josh’ above, the new line I would add would look like this:

josh ALL=(ALL) ALL

Once this line has been added, exit to the command prompt by typing Control-X, answering ‘y’ for ‘yes’ when you’re asked whether you’d like to save your changes, and then hitting ‘Return’ to confirm the suggested filename.

Once back on the command line, enter the command…

# exit

…to log out of the root user account and log back in with your new user ID and password.

Update [3/21/2012]: An update to systemd has changed how network interfaces are named.  Whereas your virtual machine’s ethernet card used to generally go by ‘eth0′, it will now have a custom name assigned by the system—a longer ID that looks like a serial number (e.g., ‘enp0s10′ or some such). To find this new name, run the command ‘iwconfig’.  The output will show you your virtual machine’s various network devices and their names. There should be only one or two; copy down the six-character code from the first column and use this instead wherever I have written ‘eth0′ below.  See also the helpful comment from Kirk Erickson below.

Next, from here on out, we’d also like Arch Linux to automatically start an internet connection on login, so we don’t have to keep typing ‘dhcpcd’ or ‘sudo dhcpcd’ to get online.  To have our system automatically connect to the internet, we’ll use this command (provide your password when prompted):

# sudo systemctl enable dhcpcd@eth0.service

Some context for the above command: As mentioned previously, ‘sudo’ is used to execute an administrative task without using the root account.  ’Systemctl’ is a command that works with Arch Linux’s default “service manager,” which is called “systemd.”  Systemd is the tool that’s behind the scenes with regard to much of our system’s configuration.  With the ‘systemctl’ command, we’re telling systemd to enable an internet connection for us automatically using the ‘dhcpcd’ command via our ‘eth0′ device, which is the virtual PC’s wired ethernet card.

Now, in the future, whenever your virtual machine boots, it will automatically connect to the internet.

Step Sixteen: Installing X and Guest Additions

Arch Linux should be working wonderfully at this point.  But chances are, you don’t want to live your entire computing life on the command line.  You’d like a slick GUI desktop environment, with beautiful icons, where you can your favorite programs and—oh, I don’t know—use a mouse.  You’d probably also like it if you could use your new Arch Linux installation in full screen mode, such that it was more like working with your native OS.  All this is possible, of course, and we’ll get to it now.

To begin with, we need to install a software suite called “X”, which is a “window system”—software that supports draggable, droppable windows and the like—that serves as the underpinning of most of Linux’s GUI desktop environments. We’ll start by installing the basic X packages.  Once again, we can use ‘pacman -S’ to install all the software we’re looking to add:

# sudo pacman -S xorg-server xorg-xinit xorg-server-utils

Provide your password if asked, and follow the prompts pacman provides to install the software.

Next, since we’d like to be able to use a really slick GUI desktop, we also need to install another piece of software called “mesa,” which is required to support the 3D graphics common to many newer desktop environments:

# sudo pacman -S mesa

Once again, provide a password if asked, and follow the prompts to complete the installation.

Normally at this stage, we’d install the hardware drivers for our computer’s graphics card, but since our PC is virtual we’re instead going to install VirtualBox’s “Guest Additions”—a collection of software packages that will enable our virtual machine to take advantage of full screen graphics and hardware acceleration.  The Guest Additions also more generally enable our Arch Linux guest OS to integrate more fully with the native host OS running VirtualBox.

To install guest additions, run the following command:

# sudo pacman -S virtualbox-guest-utils

At this point you’re likely getting used to working with both sudo and pacman, so I’ll stop with the spiel about entering your password if asked and following the prompts.

Once Guest Additions are installed, we need to make sure that the various components of this software are loaded automatically each time the system boots. To do this, we’ll use nano to create a new configuration file called ‘virtualbox.conf’.  This file will go in the ‘/etc/modules-load.d’ directory, which contains files that need to be loaded when Arch boots up.  Since adding a file to this directory requires administrative permissions, we’ll need to precede our command with ‘sudo’ once again:

# sudo nano /etc/modules-load.d/virtualbox.conf

When nano brings up the blank file, add these three lines to it:

vboxguest
vboxsf
vboxvideo

As usual, when you’re finished entering text in nano, type Control-X to exit to the command line, and answer ‘y’ for yes when you’re asked whether you want to save your work, and then hit ‘Return’ to accept the filename.

At this point, reboot your machine for the Guest Additions to take effect.

# sudo reboot

Upon rebooting, your system should automatically connect to the internet, and Guest Additions should load up as part of the boot process.

By installing Guest Additions, we’re working toward better integration between our host and guest OSes.  One example is that we can sync our Arch Linux install’s clock with that of the host system by entering the following command. This will enable synching on the next boot:

# sudo systemctl enable vboxservice.service

But enough with the clock.  At this point, we want to see if X is working, since we need it to be functional before we can install and use a GUI desktop.

To this end, we’ll install a few software packages that will help us test X:

# sudo pacman -S xorg-twm xorg-xclock xterm

After these software packages have been installed, we can test that Xorg is installed correctly by running the command:

# startx

This will launch a test environment that relies on X.  At this point, a few things should happen.  Your guest OS screen should resize, your mouse should work, and you should see some draggable windows.  This all means that both Guest Additions and X are working properly.

Note that the each of the draggable windows in the test environment should include a command prompt.  At one of these prompts, type ‘exit’ to quit out of the test environment and back to the ordinary command line interface.

Step Seventeen: Installing the GNOME3 Desktop Environment

Now that we know X is working, we can install a GUI desktop environment. But that desktop is going to look pretty ugly unless we have some presentable fonts.  So before installing the desktop, let’s first quickly install the Deja-Vu font set, which is a good set of starter fonts:

# sudo pacman -S ttf-dejavu

Now, we’ll install our desktop environment.  There are numerous to choose from, and which you go with is largely a matter of taste.  A few popular ones are KDE, GNOME, and XFCE.  I enjoy GNOME, so it’s the one I’m going to demonstrate here.  To begin with, we’ll install the main sets of software packages for the GNOME desktop, ‘gnome’ and ‘gnome-extra’:

# sudo pacman -S gnome gnome-extra

Note that there are several hundred individual software packages in ‘gnome’ and ‘gnome-extra’, so they’re going to take a while to download and install.  Speaking from experience, the installation of these packages also hogs a bit of memory and can be temperamental if it’s competing for that memory with other activity on your computer.  So now would be a good time to step away from your computer and get a cup of coffee.

Occasionally, you may see a warning message crop up during the installation, reading something along the lines of:

GConf-WARNING **: Client failed to connect to the D-BUS daemon

According to what I’ve read on various support forums, these messages can safely be ignored.

Once the installation is complete, you can streamline your setup a bit.  Most likely, you’ll want your desktop environment to come up immediately when you boot your computer.  The following systemd configuration command will enable the “GNOME Desktop Manager (GDM)” (one of the numerous programs that you just installed along with GNOME), which in the future will send you directly to a GUI login screen and then on to your desktop when you boot your virtual machine:

# sudo systemctl enable gdm

At this point, you should be done.  Rebooting your virtual machine…

# sudo reboot

…should launch you into your new GUI login screen and GNOME desktop.  And thanks to Guest Additions, you should now be able to use this environment full screen by typing Host-F or selecting “View > Switch to Fullscreen” from the VirtualBox menu.

Step Eighteen: Fixing Some Guest Additions Weirdness

If you find that your GNOME desktop works beautifully at this point, skip this step and go straight on to step nineteen.  Unfortunately, though, from what I’ve experienced, GNOME 3 sometimes starts behaving in a janky fashion when it first starts up.  Windows don’t refresh until the user clicks and drags them, at which point they’ll display any typing or changes in content you entered since the last time you clicked and dragged.  If you experience this or other strange behavior, you may choose to overwrite the Guest Additions packages you installed using pacman with the version provided with the VirtualBox software.  Note that this is not recommended by the folks at Arch, who clearly state that pacman should be used to install the VirtualBox Guest Additions software.

Be that as it may, in my own Arch Linux installations the version of the Guest Additions software packaged with VirtualBox has sometimes worked better than that provided through the Arch Linux repositories.  So, with the understanding that I’m about to veer from the Arch Wiki’s best practices, I will provide a bit of instruction on how to overwrite the pacman-installed Guest Additions with the version provided with VirtualBox.

If you’ve been following the instructions up ’til now, you currently have the Arch repository’s version of Guest Additions installed, and you’re presumably able to boot into your GNOME desktop environment, even if this environment isn’t working for you very well at the moment (again, if things are going smoothly, skip this step and go on to step nineteen).

Boot into the janky desktop environment anyhow.  Then, from the VirtualBox menu, select “Machine > Install Guest Additions (Host+D)”.  This will insert a virtual install CD into your machine’s virtual CD drive containing an installer for Guest Additions.  The Guest Additions installer will launch automatically (click ‘Run’ in the dialogue that pops up to allow it to start) and ask for the root password.  Enter the root password and when prompted allow the installer to overwrite your existing Guest Additions installation.  Follow any other installer prompts, and hit ‘Return’ when asked to close the installer window.

When the installer has finished, eject the installer CD from your machine’s virtual drive by selecting ’Devices > CD/DVD Devices > Remove disk from virtual drive’ from the VirtualBox menu.  Allow VirtualBox to force-eject the disk if necessary.  Then shut down your virtual machine and restart it.

When the machine reboots into GNOME, you should find the performance of your desktop greatly improved.  Play with the desktop for a while and figure out how to open a Terminal window, because there’s still trouble on the horizon that needs to be resolved before it crops up.

The trouble now is that, because you installed Guest Additions earlier using pacman,  and pacman is responsible for keeping your system up to date, eventually pacman is going to want to “update” the version of Guest Additions you’ve installed with a later version from the Arch repository.  When that happens, your VirtualBox-provided version of Guest Additions will be overwritten again by the version from the Arch repository, and things will go back to behaving strangely again.

To prevent pacman from trying to update the version of Guest Additions you’ve installed via VirtualBox, we need to edit a configuration file called ‘/etc/pacman.conf’, through which we can tell pacman to stop looking for updates to the Guest Additions software.

First, open a Terminal window in GNOME and from the command line, use the following command to figure out what VirtualBox-related packages have been installed by pacman:

# sudo pacman -Ss virtualbox

This command will search for all software related to VirtualBox (or, more specifically, containing the keyword “virtualbox” as metadata) that’s available from the Arch repositories.  It will list all these software packages, and more importantly, it will tell you which ones you already have installed.  Make a note of the already-installed packages (most likely they include ‘virtualbox-guest-modules’ and ‘virtualbox-guest-utils’).

Next, edit ‘/etc/pacman.conf’…

# sudo nano /etc/pacman.conf

…and uncomment (remove the ‘#’ from) the line that reads:

#IgnorePkg =

As you may have guessed, pacman will ignore any packages named on this line in future system updates.  Next, after the equal sign on this line, add the names of the installed VirtualBox packages you made a note of just now, like so:

IgnorePkg = virtualbox-guest-modules virtualbox-guest-utils

Type Control-X to quit to the command line, and as usual type ‘y’ for yes when you’re asked whether you want to save your changes, then hit ‘Return’ to accept the filename.  Now pacman won’t futz with your preferred Guest Additions installation.

Step Nineteen: Configuring the GNOME Desktop

The GNOME3 desktop environment is highly customizable and you can fiddle with it to no end.  But when you first get it up and running in VirtualBox there are a few things you’ll likely want to do immediately.  One of these is to get the sound working. To do this, go to the GNOME menu bar and unmute the audio, which is muted by default. Then, if you still don’t hear the confirmatory “pop” sound, open your audio settings from the same menu and select different audio configurations until you hear the system’s test audio through your computer’s speakers.

Next, you may wish to install your favorite browser, like Chromium (the open source version of Google Chrome) or Firefox.  To install these, open a Terminal window and run the following commands:

# sudo pacman -S chromium
# sudo pacman -S firefox

You may also notice when browsing the web or attempting to play a YouTube video or Pandora station that the required Adobe Flash plugin isn’t yet installed.  Rather than installing it manually, which is what the Adobe plugin page will suggest, you can quickly install the Flash plugin using pacman:

# sudo pacman -S flashplugin

Sometime down the road, I may also (far briefer) post tutorials on sharing files back and forth between Arch and the host operating system, and on customizing your desktop with the Gnome Tweak Tool.  But I think this tutorial has gotten long enough already, so I’ll refrain from offering yet more customization advice here.

Step Twenty: Installing Software and Maintaining Your System in the Future

Finally, Arch Linux’s handy package manager, pacman, will largely automate the process of updating your system software in the future.  To run a full system update (which you should do somewhat regularly), run the following command from the command line:

# pacman -Syu

…and follow the prompts it presents you with.  Note, however, that you shouldn’t do this blindly.  Check the homepage of archlinux.org first, prior to any system-wide update, to see if there are any disclaimers or instructions for manual intervention in updating your system.

On a more day to day basis, you’ll likely want to install or remove particular pieces of software.  While there are GUI interfaces for doing so, the simplest method (in my view, anyhow) is still to use pacman from the command line.  Typing the command…

# sudo pacman -Ss yourkeyword

…will search Arch’s software repositories for software matching your search term. By default, you have access to the ‘core’ repository, which contains the essential components of your OS; the ‘extra’ repository, which contains other arguable essentials like X and GNOME that aren’t technically required by the operating system, but are important nonetheless; and the ‘community’ repository, which contains other popular, but optional, software packages.  It’s also possible to add additional repositories, but that’s a topic for another day.  In the meantime, when you search the repositories by keyword, make a note of the names of programs, font sets, etc. that you’d like to install.  You can then install any piece of software that you want with the command…

# sudo pacman -S packagename

…where ‘packagename’ is simply the name of the thing you want installed.  Incidentally, when using this command, you can leave off version numbers and simply use the one-word name of the software in question.  If you decide later that you want to remove a piece of software, you can do so by using the command…

# sudo pacman -Rs packagename

There is, of course, more to know (I recommend looking at the Arch Wiki documentation on pacman).  But this should get you started.  Until next time, enjoy Arch and feel free to ask and answer questions, as well as to improve upon this guide, in the comments!

P.S. [3/21/2013] Some time ago I added a post on how to get shared folders working to easily transfer files between your host operating system and your Arch guest OS.  At least one user in the comments was asking about this, so here’s a link.

For end users, the extension will function the same as always, however the new version will now be safely compatible with future versions of Chrome.  Also, since Chrome no longer auto-installs extensions offered outside the Google Chrome store, please refer to this guide when installing new versions of the plugin.  I think you’ll find the installation process is still quite simple, even if it’s no longer automated.

Lastly, since there was some interest, I’ve released the source of the extension [tar.gz] under an open source MIT license.  Enjoy!

[ Image Credit: Books Icon cc-by 2.0 Nishad Muhammad]

Good news!  My article, “Going Over the Top: Online Television Distribution as Socio-Technical System” was recently accepted to the ICA journal, Communication, Culture & Critique.  The piece uses some analytical tools from science and technology studies to examine an early controversy surrounding streaming television distribution, specifically a tussle between Hulu and Boxee that presaged many of the dust-ups and heated arguments surrounding TV Everywhere and television distribution to interntet-connected set-top boxes like Google TV.

It also examines the agency of users in the online distribution chain—how user modifications to Boxee’s software impacted the flow of content and the discourse surrounding the technologies and relationships behind online television distribution.  I’m particularly fond of this article in a paternal sort of way, as it’s one of the first in which I really begin to lay out my research perspective in earnest, which I hope will be well received.

No word on a publication date yet, but I’m happy to share a draft of the article with those who are interested.