Archlinux VM -- Part the Sixth -- Big Breath Before the Plunge

We left off in Part Five having just finished getting ALL TEH FIELS for our new Arch system.

Good news is, we're almost done!

Bad news is, we're not done.

As mentioned before, we still have a couple of things to do:

1. Tell Arch how to mount our drives automatically at boot-time -- just like what we did manually in Part Four
2. Set up the VM's hostname (i.e., "what do other systems call this one?") and timezone (so as to read the system clock properly)
3. Make sure that the new system will be able to connect to the Internet when we turn it on.
4. Configure the bootloader, so the computer can find the operating-system at all.
5. Create the "RAM-disk", so the bootloader can have something to load right away.

#1 -- Mounting drives automatically

We had to mount each of our partitions manually back in Part Four. Each time, we executed the mount command followed by some parameters -- the device name ("/dev/sda7"), the destination ("/mnt/var") -- and we could have put some options, too, if we'd wanted.

Well, Arch has a way to automate this process every boot-time. It involves creating a file, fstab ("file-system-table" -- get it????), which contains all the options and parameters we would otherwise have to give to mount by hand.

Furthermore, Arch has a way of doing this basically automatically.

Execute:

genfstab /mnt -U

Bedad, Louise, whass'possa mean???

genfstab generates an fstab for us. In this case, it looks for all drives mounted under /mnt, and includes only those (besides any non-mountable drives, like our swap partition).

The final -U means "include drive UUIDs, just in case we want them". (This can be useful, as the /dev/... device-name can change in certain situations -- in which case our fstab wouldn't work any longer! The UUID, on the other hand, is an ID that's "hardwired" into the drive itself, and can't change nearly so easily.)


Of course, this command just spits out what the fstab would be. It's up to us to save it.

And that's almost as easy.
Execute:

genfstab /mnt -U > /mnt/etc/fstab

This just does the same thing, except that we take the output of genfstab and redirect it to a file -- in this case, /mnt/etc/fstab

And, yes, the fstab needs to be put inside /etc. It's standard, it's expected, and it'll basically make everything you love go up in flames if you don't put it there.

Cool!

But there's one thing we still need to do. Our fstab is complete -- except for a /tmp partition.

The hell do I care for, you say?

Because you absolutely need a /tmp partition.

/tmp is used to hold really, really temporary files -- stuff you don't want to last through the next reboot. That's why we didn't make a hard-disk partition for it like we did for /var.

And that's why we'll make our /tmp partition be entirely in RAM as a tmpfs.

We'll need to add a few lines to our new fstab.
So, execute:

nano /mnt/etc/fstab

Move the cursor down to the very end of the file, and add these new lines:

Cool. Save and exit the file by typing: [Ctrl+X] [y] [Enter]

And that's it for the fstab.

#2 -- Setting the hostname and timezone

The hostname is the name this system will answer to on our local network. So, you should choose a name that'll be unique, catchy, memorable.

You should totally choose "snowjakatron".

Anyway: choose yourself a hostname, and then execute:

echo snowjakatron > /mnt/etc/hostname

(or whatever other hostname you chose)

Now for the timezone.

You need to represent the system's timezone by creating a symlink -- a symbolic link, a pointer that looks like a file -- to a particular zone-file.

There are a lot of zone-files -- and this would be a lot harder without Arch's auto-complete!

Yeah, maybe I should have said something about that sooner.

See, Arch -- well, the shell that Arch uses (NERRRDDD) -- attempts to auto-complete whatever you're typing when you hit [Tab]. If there's more than one possibility, hitting [Tab] [Tab] will show you all available auto-completions.

So: start typing:

ln -s /mnt/usr/share/zoneinfo[Tab]

Easy-peasy. You can type a little more, hit [Tab], backspace a bit, hit [Tab] again, ...

Then just proceed along until you come to a good match for your current time-zone.

For example, linking to my time-zone looks like:

Then, just create the link and be done with it.

And that's the end of that.

#3 -- Configure the network-to-be

Out of the box, Arch uses a program called netctl to ... well, control networks. It makes a simple job of giving us control over individual network interfaces (in case you have more than one, like a NERRRRRRDDDDD), and is pretty easy to set up.

But before we make any changes -- the basics of network configuration.

There are two basic ways to configure your network:

1. The easy way -- everything is auto-configured
2. The custom way -- manual everything

Most of the time, you can get by perfectly well with the easy way. This means that the Arch system will talk to something else -- say, your router -- for an address, the best way to get to the Internet, and a few other details. This is just right for most things.

You'll want a custom configuration if you need something special -- say, a server whose address never changes.

But this is our first set-up, and we want to stick with simple for now. We'll go with auto-config.

Let's use one of the pre-configured netctl profiles.

Execute:

cd /mnt/etc/netctlcp examples/ethernet-dhcp ./

(This changes focus to the netctl directory, and then copies one of the pre-config'd configs into it -- thus making it available to use.)

We'll want to make sure that this netctl profile will activate our network interface properly. So we need to know the device-name of the network interface.

ip link

You'll see (at least) two interfaces:

• lo -- the "loopback" interface -- represents this system. Anything we send down it, we immediately get back.
• enp0s3 -- an Ethernet interface -- actually, Arch can name this whatever; but, in my experience, these are usually either enp0s3 or enp0s8

Of course, if you configured your VM with more than one VNIC ["virtual network interface card"], you'll see more than one enp... -- in which case, you need to do some detective work to figure out which is which ... But that's another story for another time!

So we know the name of our NIC! Let's edit that netctl profile!

nano ethernet-dhcp

Edit the line beginning with "Interface=...", so that it has the device-name we discovered earlier:

Everything else is fine -- leave it alone.

Type [Ctrl+X] [y] [Enter] to save your changes and exit.

And that ... should be that.

#4 -- Set up the bootloader

The bootloader is responsible for finding the operating-system right when the system powers on. It can give the user a menu --say, if you wanted to "dual-boot" Linux and Windows. And without it, the system simply won't work at all -- there'd be no connection between "turning the power on" and "this program-file getting loaded into memory".

First of all, you'll want to change your focus, from the temporary Arch we're running off the CD, to the system-in-progress that we're building. (We want to install Syslinux onto the in-progress system, not the temporary one!)

arch-chroot /mnt

You'll notice that immediately it looks ... stupider. Less colorful. Less friendly.

chroot means "change root". It says, "spawn a new sub-shell, and treat /mnt as our new /". And it looks ugly because it's using a very, very basic shell -- more primitive than the one that Arch launches by default.

Anyway: you've changed root. Fortunately, the Syslinux install script is pretty easy to run:

syslinux-install_update -i -a -m

The script copies a few files, sets up the "boot me!" flag on the right drive, and -- last of all -- points the Master-Boot-Record toward the Syslinux program.

Simple on the outside -- horribly complicated under the surface.

#5 -- Generate the "RAM-disk"

Once Syslinux actually executes, it in turn tries to load Arch -- or, at least, the core parts of Arch. What we want to do is bundle all those core parts together, to make it easier for Syslinux to load them all into memory upon boot-up.

The install-process we ran in Part Five should have given us all the right settings, at least for our simple set-up. So all we have to do is trigger said generation:

mkinitcpio -p linux

 Lots of things start happening.
Some modules are assembled ...

... and packaged and compressed ...

... and stored away.

And that's basically it. Our system is fully prepared, installed, and configured. We should be good to go to turn it on for the first time.

But that'll have to wait 'til Part Seven ...