Find Me On

My Homepage





RSS Feeds

My Stuff

Shared Items

Search This Blog


Josh Braun’s Blog // I have it written down somewhere . . .

A Guide to Installing Arch in VirtualBox Dec 22, 2012

I’ve now posted a revised version of this guide. Click here to go to the newer post.

Author’s Note (12/26/2012): This post has been updated to take advantage of some of the excellent corrections and constructive criticism provided by the Arch Linux community on Reddit.  Many thanks to them for their advice and suggestions.

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


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

Why Arch Linux?

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

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

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

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

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

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

Why an Installation Guide?

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

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

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

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

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

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

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

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

The System

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

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

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

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

The Setup

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

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

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

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

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

Step One: Assemble the Components

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

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

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

Step Two: Creating the Virtual Machine

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

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

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

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


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


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


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


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


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


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

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

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


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

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

Step Three: Booting Into the Arch Linux Installation Media

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

The procedure for installing Arch on a virtual machine is pretty much identical, except like the PC our installation disk is also virtual.  When we boot up our virtual PC for the first time, VirtualBox will allow us to load up the the .iso file—the one we downloaded in step one from—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—something along the lines of ‘archlinux-2012.12.01-dual.iso’—and select it.  Then, when you’re returned to the original dialogue window, go ahead and click “Start” to boot your virtual PC from this virtual installation disk:


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

FATAL: No bootable medium found! System halted.

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

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

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

Machine > Reset (Host+R)

Interlude: Some VirtualBox Terminology and Quirks Explained

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

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

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

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

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

VirtualBox > Preferences > Input

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

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

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

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


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

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

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

Step Five: Getting Started and Partitioning Your Virtual Hard Drive

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

root@archiso ~ #

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

Interlude for non-U.S. users

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

# loadkeys uk

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


…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:

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

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

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

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

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

# ls /dev

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

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

# gdisk /dev/sda

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

Command (? for help):

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

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

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

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

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

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

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

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

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

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

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

Screen Shot 2012-12-14 at 4.27.10 PM

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

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

root@archiso ~ #

Step Six: Formatting and Mounting Your New Disk Partitions

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

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

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

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

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

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

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

# mkswap /dev/sda2

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

Step Seven: Mounting the New Hard Drive Partitions

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

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

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

# swapon /dev/sda2

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

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

# mount /dev/sda3 /mnt

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

# cd /mnt

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

# mkdir boot home

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

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

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

Step Eight: Installing Arch Linux

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

# cd /

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

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

# pacstrap /mnt base base-devel

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

Step Nine: Generating the ‘fstab’ File

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

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

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

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

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

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

# more /mnt/etc/fstab

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

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


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

Step Ten: Initial Installation of the Boot Loader

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

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

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

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

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

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

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

# pacstrap /mnt syslinux

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

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

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

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

# arch-chroot /mnt

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


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

# bash

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

[root@archiso /]#

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

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

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

# nano /etc/locale.conf

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


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

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

# nano /etc/locale.gen

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

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

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

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

# locale-gen

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

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

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

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

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

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

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

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

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

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

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

# nano /etc/hostname

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

Step Twelve: Finishing the Boot Loader Installation

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

Author’s Note [11/21/2013]: If you’re following along with the procedures in Step Twelve, please note that a few specifics have changed.  I will eventually update this post to reflect this, but in the meantime, please reference the comments by Benny Kleykens and tepaleguiojo in the comment thread below.

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

# cd /boot/syslinux/

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

# more syslinux.cfg

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


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

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

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

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

# extlinux --install /boot/syslinux

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

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

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

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

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

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

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

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

# mkinitcpio -p linux

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

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

Step Thirteen:  Finishing Up the Installation

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

# passwd

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

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

# exit

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


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

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

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

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

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

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

Step Fourteen: Rebooting Into Your New Arch Linux Machine

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

# reboot

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

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

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

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

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


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

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

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

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

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

# dhcpcd

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

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

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

# adduser

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

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

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

Name []:

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

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

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

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

# pacman -S sudo

Follow any prompts provided by pacman to install the software.

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

# nano /etc/sudoers

Once the file opens, find the lines reading:

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

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

josh ALL=(ALL) ALL

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

Once back on the command line, enter the command…

# exit

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

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

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

# sudo systemctl enable dhcpcd@eth0.service

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

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

Step Sixteen: Installing X and Guest Additions

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

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

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

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

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

# sudo pacman -S mesa

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

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

To install guest additions, run the following command:

# sudo pacman -S virtualbox-guest-utils

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

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

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

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


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

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

# sudo reboot

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

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

# sudo systemctl enable vboxservice.service

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

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

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

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

# startx

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

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

Step Seventeen: Installing the GNOME3 Desktop Environment

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

# sudo pacman -S ttf-dejavu

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

# sudo pacman -S gnome gnome-extra

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

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

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

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

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

# sudo systemctl enable gdm

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

# sudo reboot

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

Step Eighteen: Fixing Some Guest Additions Weirdness

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

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

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

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

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

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

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

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

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

# sudo pacman -Ss virtualbox

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

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

# sudo nano /etc/pacman.conf

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

#IgnorePkg =

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

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

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

Step Nineteen: Configuring the GNOME Desktop

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

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

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

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

# sudo pacman -S flashplugin

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

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

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

# pacman -Syu

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

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

# sudo pacman -Ss yourkeyword

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

# sudo pacman -S packagename

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

# sudo pacman -Rs packagename

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

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

This entry was posted in Journalism, New Media & Digital Culture and tagged , , , , . Bookmark the permalink.
  • Quite nice.  Would you please mind changing your font so it is the same family as the text font? text stands out, while it shouldn’t.

    • meant the <em> font — congrats Disqus.  Wondering if I can throw some JS there.

      • The free font I’m using doesn’t have an italic typeface.  Eventually, I’ll probably just change to another font family altogether.

  • Dekela

    Thanks for the guide, but when I finished the installation of gnome and rebooted the machine I login into gnome and a few seconds later the machine crash.

  • Hemantu

    I have installed arch linux as per ur instructions till point number 17 in virtualbox as guest on windows XP as host. Now when I reboot my arch, it shows blank screen and nothing happens after initial steps as I have enabled gdm using  systemctl enable command. Now I am unable to see basic command line interface. Also I saw output of grep EE /var/log/Xorg.0.log command it is blank. I think it is unavle to start xorg server. What should I do ?

    • Hi Hemantu, yes you’ve pinpointed the problem correctly.  It’s a bug that has cropped up recently.  VirtualBox Guest Additions is in conflict with the latest version of the glibc package.  I’ve filed bug reports here and here.

      Until the bug is fully resolved, you can do one of three things:

      (1) Disable the virtualbox video module.  You’ll lose 3D acceleration if you do this, so you may have to run Gnome in fallback mode or use a different desktop that doesn’t require 3D acceleration.  Disabling the video module is as simple as deleting or commenting out ‘vboxvideo’ in the ‘virtualbox.conf’ file you created above.  This will also lose you true fullscreen mode, but it’s arguably the most technically correct solution in that it disables the offending software, while allowing you to keep the rest of your machine up to date.

      (2) Roll back to earlier versions of glibc and its dependencies.  This is a tad harder to do on a fresh install of Arch because there will be no cached versions of earlier the earlier packages on your computer.  You’ll instead need to download them from the Arch Rollback Machine.  With that said, once you’ve downloaded them, installing them is as simple as ‘sudo pacman -U /path/to/package/1 path/to/package/2 path/to/package/3 path/to/package/4’.  Downgrading to glibc-2.16.0-5, binutils-2.23.1-1, gcc-4.7.2-2, and gcc-libs-4.7.2-2 should do the trick.  Then add these packages to the ‘ignorePkg’ line in your ‘pacman.conf’ file to have the system stop trying to update them until you’re ready.

      (3) This not a recommended solution, since it’s in no way officially supported, but it’s possible to overwrite the new, offending glibc package with one of the versions from the Arch bug troubleshooting thread that doesn’t induce the conflict.

      • Hemantu

        Thanks a lot !!! 🙂
        I followed first solution and now able to see GDM/GNOME desktop without 3D effect.
        Thank you very very much.
        I posted my question on official arch community but no one was able to give answer. 
        Now How will I know that bug is solved ? 

        • No problem.  You can check the bug reports I linked to in the above post.  When one or the other of them gets marked as “resolved” you should be good to go.  The other thing to look for is updates to glibc.  It’s currently at version 2.17-1 in the repositories.  At some point, they’ll update to a new version and you can check to see if it solves the issue.  I’m thinking this is going to happen before the problem gets solved on VirtualBox’s end, as they appear to be treating it as a low priority.  However, I guess we’ll see.  Lastly, there’s a good Arch community on Google+ that’ll probably post about the issue once it’s been resolved.

          • I also tried solution 1, however when i “startx” the window resizes briefly just to go back to the “none-x” it were before typing “startx”..

            Any suggestions?

    • P.S. If you’ve already looked at the Xorg.0.log file, I’m assuming that you’ve figured out how to get back to the command line despite X hanging.  But if not, here’s what you can do:

      Use the instructions I’ve provided above to boot your VM from the Arch installation disk, mount your VM’s ‘root’ partition, and “arch-chroot” into your installed OS from the command line.  At this point, you can run…

      # systemctl disable gdm

      …to stop the OS from attempting to boot directly into the desktop in the future.  That way you’ll no longer get hung up on a blank screen when you start your VM after it’s tried and failed to start X.

      Then you can go ahead and reboot into your VM normally, and make any other changes you need to make (see my other comment) to get things working again before re-enabling gdm.

      Alternatively, until the issue is resolved, you may wish to start your desktop from the command line every time.  In that case, you can skip re-enabling gdm create a new file in your home directory called .xinitrc.  The contents of that file will be one line:

      exec gnome-session

      Once you’ve saved the file with these contents, you can in the future boot to the command line and run the command ‘startx’ to launch into your gnome desktop environment.  If you want to run a different desktop environment, either out of choice or because you’ve disabled 3D acceleration and Gnome is no longer playing nice, you can install the desktop of your choice replace ‘exec gnome-session’ in the above line with ‘exec awesome’, ‘exec startlxde’, etc.

  • Kurisu

    Let me just say, this guide is picture perfect! i mean seriously, there is nothing like it! All I can say is thank you!

    • Kurisu

      One thing you could add to your tutorial is that if users are having problems downloading the db files (in my case extras.db) 

      “error: failed retrieving file ‘extra.db’ from : Operation too slow. Less than 1024 bytes/sec transferred the last 10 seconds”

      add noipv6rs to /etc/dhcpcd.conf using nano and retry fetching the install files. 

      • Benny Kleykens

        If users are behind a proxy server they will have to check a couple of things before the pacstrap /mnt base base-devel :
        1) with ifconfig -a check that the system got an IP address. If not the command dhcpd may help get one from the DHCP server
        2) check if /etc/resolv.conf contains at least one line with the IP address of the DNS server. If not edit the file and add at the very least the line :
        nameserver [server ip address]
        3) set the variable http_proxy so the system knows how to get over the proxy :
        syntax :
        user= your proxy user
        password= your proxy password
        proxy=hostname of the proxy (check with nslookup that this resolves)
        port=proxy port (ussually 8080 or 80)
        and then
        ‘export http_proxy’

    • Thanks much, though it’s going to prove hard to keep up to date with Arch’s rolling release schedule—”adduser” for example wasn’t available during my last install and so forth. But I’m glad it’s proving useful for people!

      • Benny Kleykens

        It still works. Only step Twelve needs a slight review because you now have /usr/lib/syslinux/bios and /usr/lib/syslinux/efi32 instead of /usr/lib/syslinux from which to copy menu.c32. It worked for me by copying from /usr/lib/syslinux/bios.
        The dd later on in the document also needs a minor update for the same reason :
        dd conv=notrunc bs=440 count=1 if=/usr/lib/syslinux/gptmbr.bin of=/dev/sda
        needs as input file : if=/usr/lib/syslinux/bios/gptmbr.bin.

        • Thanks immensely for pointing this out. I’ll update the document with it the next time I get a chance to comb through it.

          • Raymond Covey

            OK, so I don’t want to sound like a complete n00b/idiot here, but can you either (a) post the updated steps in a reply, or (b) update the guide to show said updates? I’ve tried following both Benny Kleykens’ and tepaleguiojo’s steps, to no avail.

            I feel like I’m doing something really dumb here -_-;;

          • I’ll take a quick look at the issue if I have an opportunity, but I can’t make a promise to you that I’ll have a chance right away. This is a spare time project and I don’t have much spare time right now—new kid, full time job, and I’m finishing a book on an unrelated subject.

            The brief answer is that the files that used to reside in /usr/lib/syslinux/ now reside in /usr/lib/syslinux/bios/, so you should modify the cp commands near the beginning of Step Twelve accordingly.

            Then later on, the command previously written as:

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

            Should now be:

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

            I’m not going to update the instructions above until I’ve tested all this myself, but other users, like tepaleguiojo have reported it works.

          • Raymond Covey

            Thank you sir! If I came off as ” ME WANT ANSWER NOW OR GROGG SMASH! “, I apologize. Congrats on the newest addition to your family, and I wish you luck with everything in your future. Oh, and of course, thank you for responding in a quick fashion!

          • You’re most welcome and no worries!

          • Andrei

            “” doesn’t seem to be found or working, even with the updated path. Don’t ask why, I’m a total noob, no idea what I’m doing actually.

          • Shawn

            There is a “poweroff.c32” in the “/usr/lib/syslinux/bios/” directory. Maybe we are supposed to use that instead of “”?

          • Hi Shawn, the answer is yes When I followed the step above, I encountered the same problem. so I copied “poweroff.c32” instead of “”. And as tepaleguiojo mentioned, another file “libutil.c32” also required. Finally it works.

        • Frank Eugene Johnson

          I made the recommended change proactively but still encountered the same error that @tepaleguiojo:disqus did. I opted for this guide because it’s more explanatory and thorough but I may have to restart the process according to the archlinux wiki in order to avoid more errors.

      • sanji

        really awesome tut but it would be very cool if you updated it to a very recent release of the OS 🙂

        • Scott Westerlund

          I just implemented this tutorial (almost) to the letter with Arch 2015.11.01. The only exception was that I used syslinux-install_update instead of the manual option, like the man suggested. Great work, thank you.

    • Brian Wei

      Totally agree!!!

  • bevolution

    I’m following your instructions exactly, but after the pacstrap command, it ends with ERROR: Failed to install packages to new root
    pacstrap /mnt base base-devel [snip]
    Failed to write entry, ignoring: Argument list too long
    Also, the prompt root@archiso / # ends with a sad face 🙁 whenever Enter is pressed.

    What to do?

    • Don’t know off the top of my head.  Wish I could be more helpful, but I’d search the Arch forums for similar error messages, and if that doesn’t work you may wish to try the #archlinux IRC channel on freenode.

  • Mason

    I am stuck at the part right before installing gnome. Whenever I try to run the clock command, it keeps failing. I was also not able to use the adduser command. It says that it is not a command.

    Thanks for the help though! it has been great!

    • Thanks much!  The issue starting the X environment (the clock bit) may be due to a recent VirtualBox bug (see my other comments).  As for the adduser command, it was removed recently.  You’ll have to use the more traditional, though slightly less user friendly command, “useradd”.  You can Google for helpful examples of how useradd works.

    • Majinjoko

      adduser is not provided with standard Arch package system. You could install it from AUR or using packer, yaourt, ..

  • Guest

    Wow, very thorough! I did want to point out that on your “# sudo systemctl enable dhcpcd@eth0.service” line, the Zero looks very much like an Oh on the bolded font, which could be trouble for those of us who type things in instead of copy/pasting.

    And, although I’m less knowledgeable about it, I’d been running into a problem before landing here where net-tools was recently deprecated and systemd changed some naming conventions and I needed to use “enp0s3” instead of “eth0”. Might not be necessary here, or it might help future readers. Nice tutorial!

    • Majinjoko

      you can tell Udev to rename enp0s3 in eth0, if you want. Or just use enp0s3 for net configuration.

  • Indcraig

    I followed the instruction to the letter but couldn’t boot with my first attempt. Upon my second attempt I got to the reboot stage and then had an boot error. All I had to do is tab the Launch Arch OS and change hd 0 0 to hd 0 1. 

    Could you include that in your guide for any other  arch newbies 🙂

  • This guide was a huge helper, thanks. But why aren’t you using the convenient script `syslinux-install_update -i -a -m`? It automates some of the steps and is less error prone.

  • Kirk Erickson


  • All I can say is Thank you, Thank you, Thank you.  After installing the “old” Arch Linux on a laptop, virtual machine and USB I was really starting to feel like a failure because of my inability to follow the steps at the official Arch Wiki for this new version.  This did the trick.  Perfect.

  • Majinjoko

    Thank you, with this and archlinux begginers guide I set up a Arch on virtualbox.

    Two interesting thing:
    – containts useful information to “clone” a system. I used it to reinstall all the packages used on another desktop pc
    – adding information about how to mount virtualbox shares in the virtual Arch will make this guide more complete.


  • I got it to boot and everything, got my internet set up (I think), installed virtualbox guest stuff, and then had to reboot.
    I try to do sudo pacman -S xorg-twm xorg-xclock xterm so that I can test X before installing a desktop enveiroment..
    It then asks me for my password, the Y/N thing, etc.
    then I get a whole bunch of lines saying “error: failed retrieving file
    [filename] from [somewhere] : could not resolve host (nil); Unknown
    And after that it says error: failed to commit transactions (download library error)

  • Kirk Erickson

    # sudo systemctl enable dhcpcd@eth0.service
    there was a change in systemd where this create a broken symlink.


    sudo systemctl enable dhcpcd.service

    if you already added the eth0 symlink then remove first

    sudo systemctl disable dhcpcd@eth0:twitter .service

  • Bill O’Dwyer

    This is a really useful guide, but there are a few points that are out of date now, so it’s good to use this alongside the beginners’ wiki 🙂

  • Nano

    First of all: Great guide, I love it.

    I’ve only one problem: I’m stuck at the “startx” command. When I try to run that command it says “Fatal error: No screens found”. I followed every step of the guide… Any guesses what might have gone wrong and how I should fix that? Thanks.

  • DOC

    Hey josh,

    thanks a lot fot the guide by the way!i have been having some issues with useradd command, it gives me the error: useradd: cannot lock /etc/passwd; try again later..

    i tried everything looking for the passwd.lock shadow.lock…etc files did not help at all

  • Fanarito

    In the end of step 16 when i am supposed to type # startx.

    after i type that in my window re-sizes but nothing else happens it just stays black.

    Do you know what causes that?

    • nilnil

      You probably need to run VBoxClient-all &

      • Fanarito

        That did not work, but I cant see anything about X on that wiki page… I have to keep looking i guess or start from scratch again

        • praveen

          Hi I have the same problem how did u get around it.

    • Akutaj

      I am also facing same issue as @Fanarito, wouldn’t like to give up at this stage. Anyone any answers plz. Thanks.

    • Akutaj

      @Fanarito:disqus, try “sudo startx” mine worked.

  • Juan Bta.

    Thanks a lot for this post! however, I had problems related to keymap forcing me to type “# loadkeys es “, it was fixed after creating the file “/etc/vconsole.conf” with my local values:


  • Jonathan

    Josh, thanks for the awesome guide. Was able to get my VB Arch setup humming along without much issue.

  • J.A.R.V.I.S.

    Hi, im completely new to Arch linux and have been running ubuntu for about a year now.

    Thank you very much for this tutorial, i have made a virtual machine and got it up to the startx command and was having a lot of trouble with adding an alternate user. (i was using root for everything) I then spent about an hour trying to figure ‘useradd’ out. when you use the comand useradd and want to add a specific user dir ( /home/[user_name_here] ) you have to use ‘ user add -m [user_name_here]’ to finally get a dir.

  • I just want you to know it worked. You’ve got a bright future writing tutorials. Great, great work. Now I can start building my virtual Arch box and learn a thing or two.

  • Andrew Townsend

    What a great guide – thanks very much for your hard work! Buzz

  • kilij

    My two cents – this is one of the most well thought-out and executed guides on any discipline that I’ve read in a long, long time. Thank you VERY much for your diligence; it made the process of installing Arch into a vbox actually enjoyable. The only problem I encountered was relatively simple to fix; at the time of writing, it is not possible to install the guest additions from either a newly downloaded ISO or via the ISO included with VirtualBox4.2.4. The process aborts when it tries to query the distribution it’s being run on and fails to get an answer. Now I’m not at all sure about this but I think this is happening on account of Arch moving to systemd and rc.conf becoming deprecated. One thing I attempted was to touch rc.conf as a workaround, but it had no effect. So perhaps this is why the wiki insists that you only install via pacman; in any case, I did eventually get it working via a pacman install.

    • kilij

      I forgot to say that I needed to remove and reinstall virtualbox-guest-utils in order to get an entry for virtualbox.desktop to appear in the folder that GNOME checks for autoload scripts. Once I figured that out, I had access to the dynamic screen size + shared clipboard on startup.

    • Thanks so much, and thanks for the update!

  • i get after rebooting “Root device mounted successfully but /sbin/init doesn’t exist . Bialing out you are on your own. good luck
    then promt comes like this:[rootfs /] #

    • xor

      I had the same issue. The following solution worked for me:
      Edit the /boot/syslinux/syslinux.cfg file so it points to the correct partitions:
      LABEL arch
      MENU LABEL Arch Linux
      APPEND boot=/dev/sda1 ro #this is the /boot Partition
      APPEND root=/dev/sda3 ro #this is the / Partition
      LINUX ../vmlinuz-linux
      INITRD ../initramfs-linux.img

  • Ken S.

    Great tutorial. One thing about /etc/sudoers. It’s better to edit it with visudo. Eg.

    EDITOR=/usr/bin/nano visudo

    When it exits, it makes sure you didn’t get yourself into a state where you can no longer sudo by, for example, introducing a syntax error in the file.

  • Jaff

    Worked like a charm for actually installing Arch, learnt a truckload more about linux than I did trying out ubuntu 13.04. Definitely gonna keep playing around with the install after this.

    One thing I’d mention which is just down to the date this was written vs. new changes I guess.

    Once I got Arch booting on its own there was no iwconfig/ifconfig to find out my eth0 device address until I’d added ‘net-tools’ with pacman. Confused me for 5-10mins as a 100% linux noob but easily fixed.

    Thanks for the guide man, latest addition to my bookmarks.

    • Thanks so much! I’ll fix the iwconfig issue next time I update this post.

  • Toni

    Great guide, helped me a lot… thanks so much! As a possible improvement I’d suggest using ls /sys/class/net to find out the name of the network adapter, since iwconfig is not included in the base packages and must be installed separately.

  • confuddled

    Your tutorial is terrific. Everything has been working so far until I got to installing Guest Additions.
    When I type the command:
    “# sudo systemctl enable vboxservice.service”

    I get:
    “Failed to issue method call: No such file or directory”

    I have also gotten this error:

    “I have arch linux installed on my system… then i tried to install virtual box through pacman…. every thing goes fine until following errors are displayed..
    (2/2) checking package integrity [###########################################] 100%
    error: virtualbox-host-modules: key “38DCEEBE387A1EEE” is unknown
    error: key “38DCEEBE387A1EEE” could not be looked up remotely
    error: virtualbox: key “38DCEEBE387A1EEE” is unknown
    error: key “38DCEEBE387A1EEE” could not be looked up remotely
    error: failed to commit transaction (invalid or corrupted package (PGP signature))
    Errors occurred, no packages were upgraded.”

    Do you have any suggestions?

  • tomks

    thx a lot for this very helpful man! first time i get arch to run without headache!

  • Tim Dykes

    A note that might come in useful to someone, if you set up the partitions differently (for example leaving out the swap partition) you should also ensure in your /boot/syslinux/syslinux.cfg file the root partition labelled correctly – it defaults to /dev/sda3

    If you dont do this then when you boot your new arch system you will likely receive the error:

    Root device mounted successfully but /sbin/init doesn’t exist

    Simply boot back to the cd, remount the boot partition and edit sysconfig.cfg to change /dev/sda3 to the correct partition (your root partition). If you went without swap this would probably be /dev/sda2.

    • Lei Xu

      You did save me today!


    • Thanks for adding this!

  • beanie

    great guide. i’m getting fairly comfortable with linux but i picked up some things i never knew before. many thanks!

  • bernd

    hi! iwconfig doesn’t seem to work. to find out the network interface name use command “ip a”

  • bernd

    oh yeah, and adding a new user worked by “useradd -m username”
    you should add that the password for the new user must be set by “passwd username”

    • Excellent, thanks. I’ll add this update to the guide next revision.

  • Ronnie

    One of the best guides I’ve ever worked with …. thanks a ton, Sir!!

    • Much appreciated, I’m so glad it was helpful.

  • Ronnie

    Hey.. I was trying to install Arch once again, and I noticed that the ‘extinstall –install /boot/syslinux’ command does add the ‘ldlinux.sys’ file to the ‘/boot/syslinux’ folder

    It says so in the Arch Wiki :

    Also, ‘sudo’ is already installed in the ‘base-devel’ group, so there is no need to install it again…

  • shinuza

    For some reason, the `sgdisk` command failed for me. I ended with an error like “Missing operating system”, so I booted the iso again and ran `gdisk` one more time, went to expert mode ( x ), then attribute mode ( a ), chose the first disk ( 1 ) and changed its attribute to “Legacy BIOS Bootable”, write ( w ), reboot and it was fixed. This could probably be done in the “gpart” section of the tutorial

    • Great to know! Next time I update this, I’ll try adding it in.

  • Nitin Mewada

    Modification for step 15.

    type “ip link” in command prompt, u will se that port name has been changed from eth0 to enp0c3. So, use # sudo systemctl enable dhcpcd@enp0c3.service instead of original # sudo systemctl enable dhcpcd@eth0.service.


  • john

    You are awsome 🙂

  • tepaleguiojo

    I have a problem when I rebooted vbox. The error I encountered is

    Failed to load libutil.c32
    Failed to load COM32 file menu.c32

    How can I fix this?

    Thanks in advance

    • See the comment above by Benny Kleykens:

      There’s been a change to Arch since the guide was written that affects step twelve.

      • tepaleguiojo

        Thanks for the reply.

        Should I repeat the whole installation process or I just mount again the .iso and follow the steps that you gave?

      • tepaleguiojo


        What I did is to copy the libutil.c32 on /boot/syslinux and repeat the process on step twelve. And it’s done.

        Thank you

      • Juraj Petrík

        I have encountered this same error. That is after following Benny’s instructions.

        • See the updated guide, linked to at the top of the post. Cheers!

  • Lindsay Tupper-Creed

    Great tutorial
    Most of the time arch boots up fine but some times it just blank screens when it gets to gnome?

  • Sovietskya Sovietskya

    Good stuff

  • Oswald Cobblepot

    Two words: THANK YOU!

    Best, easiest to follow, and most comprehensive instructions I have found.

    • Really glad this was helpful, thanks!

  • holyyouknow

    IN vbox, when I do refresh the system, it cant resolve the mirros!.

  • WS Warthog

    This seems to have worked but for one thing. When trying to boot from my virtualbox hd without the cd I got the error “failed to load libutils.c32”. I put the arch iso back into the virtual cd drive, booted into it, and poked around in /usr/lib/syslinux/bios and sure enough libutils.c32 was there. I also copied libmenu.c32 since the error message complained that it couldn’t find menu.c32 even though that had been copied. Figured it couldn’t work. Restarted the VM and it booted.

  • WS Warthog

    Also I had some trouble with user permissions when trying to execute ‘startx’.
    If you get a message saying something like “.xauthority timeout in locking authority file”, it could be that during the creation of your personal user (as separate from root) that you didn’t get set as the owner of your home folder. I think this happened to me because I neglected to create the folder before assigning it as the home folder of my user, so I had to create it afterwards, and so the permissions never got updated. This is how I fixed it anyway.

    Navigate to /home:
    cd /home
    and then do:
    sudo chown yourusername yourhomefoldername
    to set yourself as owner

    • Havard

      Thank you for sharing. Before i did this the ‘startx’ command would just make the screen black, but now it works. My username was ‘havard’ so I did:

      cd /home

      sudo mkdir havard

      sudo chown havard havard

  • Cheers for the guide Josh.

    I had to alt tab over to the Arch Linux Install Wiki a couple of times to figure out some things.

    I’ve written up a “type this and get it Arch on VirtualBox” guide, depending on when you look at it might be a work in progress 😉

    Simple to the point no fluff install Arch Linux on VirtualBox

    • OK all done – Amazing how fast Arch Linux is to boot, love it!

    • Josh

      Hey, thanks much. This is great. Hoping to have time to make a full revision of the guide this summer, but I’m neck-deep in my day job right now. 🙂

  • marmy


  • Marcus

    first thanks for the tutorial
    but theres a problem:
    hi ive used Benny Kleykens settings for efi32 on syslinux !
    but when iam reboot at step 14 syslinux said_
    Failed to load libutil.c32
    Failed to load COM32 file menu.c32
    and then always the same 😀
    plz somebody could tell me how to fix the issue ?

  • bancaldo

    thank you for the awesome guide!!

  • Adniwhack

    This is a very good guide. I did everything up to installing the x window part but it doesn’t work…

    it asks for sudo password, ask to proceed with installation. I type y and press enter.

    it gives me a load of error messages and then it gives the following message:

    error: failed to commit transaction (download library error)

    what can I do to fix this, and is it necessary to proceed with installing x window if I want to use this in command line?

    • Alexandria Ostrem

      Also having this problem. If I find a solution before anyone answers, I’ll post it.

    • Alexandria Ostrem

      1) Run dhcpcd as root!
      2) Follow the tweak for step 15, replacing the eth0 with the port name you find from running ip link (should be similar to enp0c3).
      3) Run dhcpcd as root again (probably unnecessary).
      4) Make sure your mirror list is up to date, and with your preffered mirrors first.

      I did that, ran pacman -Syu, and everything worked.

  • enthusiast

    This works fine on VirtualBox. No issues. However, when I repeat the
    process on a real hardware with USB drive (/dev/sdc is my USB – I
    replaced all instances of /dev/sdaX in the tutorial with /dev/sdcX ) I
    get the following errors

    modprobe: FATAL: Could not load /lib/modules/3.15.5-2-ARCH/modules.deb, no such
    file or directory.

    Wondering what it could be? Any help is appreciated. Thanks in advance.

  • Etescartz

    Still the most complete and noob friendly Arch setup guides I’ve read in years. I’ve come back for this guide so many times I can’t remember. It saved me every time I praised Arch to people who were previously oblivious to Arch’s awesomeness. I just referenced this guide and I find myself here yet again.Thank you for the time you put into this 🙂

    • This is awesome of you, thanks so much. I know it’s dated in places and I plan on updating it once I’ve finished getting my current book project off to the publisher, so I hope it will continue to be useful through to the future.

  • Thanks a lot for your guide.
    I found that after ejecting virtual installation CD, we can just go to the VirtualBox menu bar and select: Machine > insert Ctrl-Alt_Del Instead of starting the virtual machine one more time. It will restart again.

  • Opethfan89

    Hey Josh,

    I have no idea if you still actively monitor this, but I wanted to thank you for such a DETAILED guide on getting Arch installed on VirtualBox!!!

    I ran into a slight problem and don’t know if you can help…..after installing my desktop environment of choice (and I tried both Gnome and Enlightenment), I see a black desktop, I see my mouse, but the machine doesn’t load my desktop itself. After a few seconds it just resets back to the login screen.

    Any idea what might be causing this behavior?


  • @smokemyhashtag

    Not my end all guide for my install but I really enjoyed the article and found a lot of elements helpful. Thanks and hello from Middletown! 🙂


  • caron gangoo

    Hi !s

    Thank you very much for this very explicit tutorial : it’s like a light in dark tunnels of linux learning curves !
    I humbly need your help.
    I run A vm archLinux x86_64 as host on a mint 17 guest and I am in the 1sr category you stated at the beginning…lol!
    I succeded to share folders between Mint and Archlinux but I am unable to run pacman -S to update packages but worse … I cannot open any browser whatver the Archlinux included browser or even Firefox . I am even unable to install Opera !!!!
    So what must I do ?

    Thank you so much again.

    Cheers from the Sunny … and overheating Republic of Mauritius !


  • Pazuzu156

    I would like to add that while syslinux is an amazing bootloader solution, grub is so much easier to install. It’s also much easier to configure a dual booted machine.

    To use grub, simply install the bios package and os-prober if you are dual booting so grub will recognize the other systems

    # pacman -S grub-bios os-prober

    Now install grub

    # grub-install –target=i386-pc –recheck /dev/sda

    And add the configuration

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

    If you installed os-prober, grub will recognize the other systems and automatically write them to the configuration.

  • chis

    Excellent tutorial and it all worked like a charm with a bit of help from the comments. I found the main documentation for this very convuluted and found myself jumping from page to page and was very glad to find this!

  • Miguel

    I just wanted to thank you for this awesome guide!

  • icamys

    Thank you so much for this great work, Josh! You saved many hours(if not days) of my life.

  • Arvi

    hey friends visit here and get club penguin codes. this is the right place where these codes are available so hurry up and get these codes.
    free codes for club penguin membership

  • Shash

    Thank you! It was a very detailed and well written which helped me a lot.

  • Akash Gupta

    This is the ultimate guide!Helped me at each and every step.I read each and every line and even though its long but totally worth it.But if you find some time pls integrate the comments in the guide you referenced to make it up to date.Also during install i got corrupt file errors which is fixed by sudo pacman -Syy.Thanks a lot!

  • Ugly Duck

    Hi Josh! You are awesome!!!
    This is an awesome guide!!! Just what i was looking for!

    Btw, something i wanted to mention here is:
    In step 12, I copied only the files mentioned in my /boot/syslinux/syslinux.cfg file and it failed to reboot afterwards. I got the following error saying
    Failed to load libutil.c32
    Failed to load COM32 file menu.c32
    Failed to load libutil.c32
    Failed to load COM32 file menu.c32
    … and it kept on.

    I restored the VM to step 12 and copied libutil.c32 in the same way i copied the other files. It rebooted without any error after that.

  • Lobo Rojo

    First of all, I want to thank the author for going through the effort of writing this.

    If you’re having issues installing Arch, try this
    I ran into several issues while following the instructions here. After 4 hours, I finally managed to resolve them, by deleting the entire thing and switching to a distro that comes with a GUI installer. I tried a half dozen of them – as they are plentiful and I like options – and not a single one gave me any errors, confusion, or took longer than 20 minutes to complete. I didn’t need a user guide or have to look-up anything, since everything was intuitive or explained well enough within the installer.

    • Aliyan Gohar


  • Pablo

    Great tutorial. The ArchLinux tutorials are pretty confusing and hard to follow (many links). This guide is excelent and simple, like everything should be. I hate to read documentation generally because everything is made complicated; so you turn to google and you find simple, excelent tutorials like this.


    You are so cool. I don’t think Ive read anything like this before.
    free itunes music codes

  • Bhokali Kali

    The marketing beginning day Make certain everything goes live at as quickly as for massive visibility for hacking service of facebook. free facebook account hack

  • Manu Kr

    If you wanna free codes of xbox live game then you should visit on this site and enjoy your payable game absolutely free Thank you xbox live gold accounts

  • Manu Kr

    wow what an amazing site for xbox user this site provide us free codes of xbox live game here visit for free xbox gold codes

  • henry

    thank you thank you thank you thank you
    thank you so much josh for this. i am a total newb on this and was frustrated on what i should do for weeks and cannot really find a good and comprehensive guide, that actually explains things in detail and lead my way through a brand new system for me. it is really helpful and truly grateful for all your time and effort put into this masterpiece.
    awesome and bookmarked!!

    • So happy it’s useful! Be aware if/when you follow it that a lot of sections are probably getting a bit dated. I’ve been meaning to update this for quite a while, but life keeps getting in the way. 🙂

  • dgvsedvg

    marvel contest of champions cheats and hacks for contest of champions

  • Puneet Chhabra

    Thanks a lot Josh for this article. But i came across this article looking for steps to install arch Linux from network directly, without having to download image file. Can you help in that regard please.

  • Bhokali Kali

    This program just produces a brand-new code each month. You could use it when per account. gift card google play

  • Raj Arya

    free marvel contest of champions tips and tricks here… marvel contest of champions hack

  • Raj Arya

    free itunes gift coupans and codes here try this and win lots more…. free itunes codes

  • OB7

    This guide is so well written I’ve been using it to install arch linux straight onto hard drive, not even using virtualbox. Thanks.

    • That’s terrific, thanks so much for the kind words! I’m glad this was helpful.

  • Daniel

    I am deeply grateful for you taking your time compile such a thorough guide, which took me so nicely through installation and taught me quite a few things I didn’t know about computers/linux. Your awesome.

    • Thanks so much, I’m so glad it was helpful and appreciate your kind comment.

  • Ben Pietras


    On 24/9/15 I needed to use the syslinux-install_update script – no luck without it.

    To get the internet working automatically

    # sudo ip link show

    gave me blah blah “enp0s3” blah

    So, I used
    # sudo systemctl enable dhcpcd@enp0s3.service

    Works fine. mate ftw for a desktop env btw.

  • Arun

    Thank you is the word !!

  • serg

    1/26/2016 hit a snag on step twelve after I went ahead without syslinux update script, and not knowing where to go next (the comments you referenced didn’t help), I just abandoned ship altogether. You ever gonna rewrite that part?

    • There’s a link at the very top of the post to the rewritten and updated guide.

      • serg

        seen’t it, thanks. sorry for not noticing those were links 😛

  • Sue Piatte

    Good to know. Has anyone ever wondered how to fill out forms online? I have, and found a simple service. Maybe you would be interested in an online service with a ton of Form templates (tax, real estate, legal, business, insurance forms, etc..) I used it to fill out

  • anirtek

    Even after installation, I got an error stating boot loader missing. And I am not able to find out where did I went wrong.

  • Imane E.

    Thank you Sir, for real, it was straight forward, keep up the good work.

  • Bradley Baysinger

    Thanks for the tutorial. I got to step thirteen and had problems. ‘umount /mnt/boot’, ‘umount /mnt/home’, and ‘umount /mnt’. All said ‘mount point not found’. I tried ‘umount boot’ and ‘umount home’, and they both seemed to do something, but I couldn’t figure out the last one for ‘umount /mnt’.

    Then I got to ‘sgdisk /dev/sda –attributes=1:set:2’, and it said ‘command not found’. sgdisk doesn’t seem to exist?

    Please help!

  • Bradley Baysinger

    I got through all the steps and got “Failed to load ldlinux.c32”.

  • Nix

    Guide needs updating “cp /usr/lib/syslinux/menu.c32 .” strings don’t work at all.

  • Haruna

    Well, Maybe it is sure late comment, but this guide helped me a lot. Well, For now I will be having fun with Arch on Virtualbox, but soon.. will install it on main rig.

  • daraghfi

    F-ing AWESOME. Thank you.

    Only 2 asks:
    a) update when you get a chance (please) so that it retains it’s value; and
    b) I’m doing this to take advantage of the latest kernel, and KDE Plasma instead of Gnome, which would have installed with Ubuntu anyway. I would also note that the performance-sensitive among us would go for XFCE. I’m sure you know this stuff, but the N00bs who need this guide might appreciate it.

    However, did I say THANK YOU!!!?