Author’s Note on December 23, 2015
I’ve gone through and applied a long-overdue update and overhaul to these instructions. They will, do doubt, become dated again before long, though. So please continue to check for useful contributions from commenters in the thread below and to make use of the various resources linked to the text. If you want to see the old install guide, here’s a link back to it.
I’m thankful for all the nice things users have said about the past version of this guide and all the advice they’ve given in their comments—you folks are great. I’ll try to continue occasionally updating the text to reflect changes in Arch once or twice a year until it becomes unwieldy. With that said, 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 can easily see how dated the instructions may be. 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 in the past—and will hopefully continue to—add 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.
When I wrote the first iteration of this guide in 2012, I’d been a Linux user for around five years, which means I’m now going on around eight or so. 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—didn’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?
In 2012 I set up a new Arch installation and in the process got to know the distribution even more intimately. The folks behind the distro had decided to discontinue the auto-installer they had previously offered. The installation process for Arch was—and 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 has long hoped 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 my 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:
- 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.
- 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 who may know little about Linux.
- 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 (no longer online) in putting my own installation guide together, so feel free to check these out as well.
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 11-inch MacBook Air (early 2015 model, 2.2 GHz Intel Core i7, 8GB of memory) running Mac OS X 10.10.5 (Yosemite). The installation media used to install Arch was snapshot version 2015.11.01. The virtualization software used was VirtualBox 5.0.11 from Oracle (I had to install a “test build” of VirtualBox on the day I made this revision, since the latest release version was behaving janky, but typically you should just be able to install the ordinary version of the software).
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 want 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.
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, and at this point in time I run Arch as the primary operating system on my hard drive. But when I was starting out I initially chose to virtualize Arch for a number of reasons:
- 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 often isn’t noticeable unless you plan to do some hardcore gaming.
- 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.
- 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.
- Portability. When I change computers, I just copy the folder containing my virtual machine over to my new PC. Migration complete.
- 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. (Note: On the day I revised these instructions, the release version of VirtualBox was experiencing a bug, so I had to install a more recent test build instead. If you ever encounter a problem know that this may be an option.)
- 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.
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—the “recommended memory size” isn’t a bad suggestion, but it may be on the low end. Depending on how fast my computer is, I may either drag the slider to the top of the green zone, which is the upper recommended limit for the virtual machine’s memory, or simply place the slider at a value that’s half the actual memory of my machine. In the example below, my computer has 8GB of RAM, so I’ve set the slider to around 4GB. Setting the slider to a higher value will make 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 the option on 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 disk.
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 as 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 150 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. The text box at the top of this form will let you name the folder and its location on your machine where you want your virtual PC stored. You can typically just leave this as a default.
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-2015.11.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. 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 > Optical Drives > Choose disk image…
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
Input > Keyboard > Keyboard Settings… > Virtual Machine
Here you’ll see a place where you can assign the “Host Key Combination” to the hotkey 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.
I used to recommend using the 32-bit version, since it’s perhaps a bit less memory intensive for your actual computer. What I’ve gleaned from reading further since then is that there are some tradeoffs to consider. (Aren’t there always?). Choosing 64-bit allows the guest OS to access more memory resources, which can make for a faster virtual machine than using 32-bit. Of course, unless you allocate a decent amount of RAM to your virtual PC, this may not make a difference. So, long story short, from what I understand you may get a faster virtual PC by going with the 64-bit option, but to take advantage of it you may have to allocate more of your actual system’s resources to it. At least that’s what the consensus seems to be on the various Stack Exchange-style Q&A boards where people have opined on the matter. Here’s an area where I would greatly appreciate informed opinions in the comments. With all this said, I’ve tried both 32- and 64-bit installations now and don’t know how substantial the difference actually ends up being in terms of performance. In other words, choose whichever you’d like.
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 (fake) 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…
…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.
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:
- 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.
- 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.
- 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.
- 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 initial summary of your system vitals. Now, let’s create the four partitions I discussed above. To create the first partition, our boot partition…
- Type ‘n’ at the prompt and hit ‘Return’ to tell gdisk you want to create a new partition.
- When it asks for a partition number, hit ‘Return’ to accept the default (1).
- 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.
- 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.
- 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:
- Type ‘n’ at the prompt and hit ‘Return’ to tell gdisk you want to create a new partition.
- When it asks for a partition number, hit ‘Return’ to accept the default (2).
- 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.
- 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.
- 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).
- Type ‘n’ at the prompt and hit ‘Return’ to tell gdisk you want to create a new partition.
- When it asks for a partition number, hit ‘Return’ to accept the default (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.
- 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.
- 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. This is the place on the machine where all our personal files and settings will live. This one’s the simplest one yet.
- Type ‘n’ to create a new partition and hit ‘Return’ as usual.
- 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
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. These days the Beginner’s Guide seems to favor GRUB2—Syslinux is no longer mentioned there. But when I originally wrote this guide, I went with Syslinux, and so I’ll stick with it in this revision of the guide. Feel free to check out the Arch Wiki for instructions on using GRUB2. So, Syslinux…
Christoph Schniedermeier pointed out in the comments of my original guide that there’s a simpler way of installing Syslinux than I describe here. Arch Linux includes a script you can run to install and configure it largely automatically. If you’d like to use the automated method, check out the syslinux-install_update script entry in the Arch Wiki, follow the instructions there, and skip now to step eleven in this guide.
Learning the less automated procedure, I think, gives you you a bit more of a handle on how your system works. And it still includes some automation—just less than the method I link to above. To start, execute this handy installer script:
# pacstrap /mnt syslinux
As mentioned, 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:
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:
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:
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.):
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:
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:
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: 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:
Author’s Note 1/27/16: Some users have had issues with this procedure for installing syslinux. See this comment from user piagetblix below before proceeding for an alternate set of instructions. I’ll update the guide once I have confirmation from a few users that piagetblix’s instructions work as advertised.
# cd /boot/syslinux/
Inside this directory, there’s a file called ‘syslinux.cfg’. This file contains a partial 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/efi64 (or ‘/efi32’ for 32-bit installations) 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).
I should add a couple notes here about the list of comboot modules provided in ‘syslinux.cfg’. First, at the time of this writing, it’s incomplete. Based on experience, there are a few files not listed that you’ll also need to copy over to get everything working. I’ll include instructions for copying the additional files below. Second—and again, at the time of this writing—the instructions in the file that accompany the list of comboot modules give a filepath that’s no longer correct (at least for the Arch distro) when telling you where to copy the files from—it says to copy files from /usr/lib/syslinux (which used to work) rather than /usr/lib/syslinux/efi64 (which currently works; if you’re doing a 32-bit installation, replace /efi64 with /efi32).
In any case, next, we copy the specified files into the /boot/syslinux from the /usr/lib/syslinux/efi64 directory (or /efi32 for 32-bit installations) by running the following commands. Per my note above, I’ll include commands for copying all the necessary modules to /boot/syslinux, including a few not listed in the ‘syslinux.cfg’:
# cp /usr/lib/syslinux/efi64/menu.c32 .
# cp /usr/lib/syslinux/efi64/vesamenu.c32 .
# cp /usr/lib/syslinux/efi64/chain.c32 .
# cp /usr/lib/syslinux/efi64/hdt.c32 .
# cp /usr/lib/syslinux/efi64/reboot.c32 .
# cp /usr/lib/syslinux/efi64/poweroff.com .
# cp /usr/lib/syslinux/efi64/libutil.c32 .
# cp /usr/lib/syslinux/efi64/libcom32.c32 .
In case you’re keeping track, it’s the final three ‘cp’ commands that are for files not listed in ‘syslinux.cfg’. Anyway, 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/bios/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/bios/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:
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:
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…
…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:
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:
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.
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 following command, replacing both instances of ‘josh’ with whatever user name you’d like:
Note that the username you enter here should be a simple login ID, not your full name; later on you can associate this ID with your full name and other personal information. As for what the command does, it obviously creates the user account ‘josh’ (or whatever user ID you’ve chosen). Aside from that, the command we’ve entered has a couple extra flags that add bells and whistles. The flag ‘–create-home’ tells the system that you’re creating a home directory for the user, and the ‘–home-dir’ flag tells the system the path to that directory ( ‘/home/josh’).
Next give your new user account its own password with the following command (again, replacing ‘josh’ with whatever user ID you created for yourself):
# passwd josh
This command is largely self-explanatory. It’s the same command we ran above to give a password to the root account, but this time we’re specifying that we want to create a password for a particular account apart from root (i.e., ‘josh’).
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…
…to log out of the root user account and log back in with your new user ID and password.
our 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 automate this process, we’ll need to know the name that Arch is using to identify our virtual PC’s ethernet card. To find this, enter the following command:
$ ip link show
(Note that in this command I denote the prompt with a dollar sign ($) instead of a pound sign (#)—this is a common way of denoting that the person running the command is not expected to be logged in as the root user.)
The above command will spit out a list of network devices on your virtual PC. Briefly, ‘ip’ is a command for working with all sorts of stuff to do with networking on your computer. The option ‘link’ specifies that the thing you want to manipulate with the ‘ip’ command is a network interface (a ‘link’). And ‘show’ means “show me a list of my network interfaces.”
The thing you want from this output is the name of your network card, which will be a single word begins with ‘enp’. Copy down this word in its entirety, as you’ll use it again in the next command we give to the system.
To have our system automatically connect to the internet enter this command, replacing ‘enp0s3’ with whatever the name was you copied down in the previous instruction (provide your password when prompted):
$ sudo systemctl enable firstname.lastname@example.org
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, I used to recommend installing another package, called ‘mesa’, which helps with the slick 3D graphics common in newer desktop environments. However, ‘mesa’ now gets installed automatically as part of the above step, so there’s no need to install it separately.
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:
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:
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: 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 sometimes 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
I also have a separate (and far briefer) tutorial on sharing files back and forth between Arch and the host operating system. At some point I may also add one 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 in the present text.
Step Nineteen: 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!