Install Arch Linux on ESX 5.5

I have been meaning to delve into Linux with Arch for a while. I’ve been using a VM in ESX to learn the install process. The installation has been pretty easy maybe because I have spent a fair number of years using Linux. The Arch wiki is an awesome resource and one mistake I keep making is not reading the whole page. This causes many headaches that could be avoided if I didn’t just gloss over the information.

Anyways, I wanted to provide a simple step-by-step tutorial to serve as a quick checklist. Remember that these steps can quickly get out of date as Arch moves fast. So always reference the Arch wiki first. Here are the major steps.

1. Download Arch installer
2. Create VM
3. Boot VM and install Arch

I downloaded the dual 2013.12.01 version of the installer: archlinux-2013.12.01-dual.iso. The VM I created was of “type” Red Hat Enterprise Linux 6 (64-bit) and had 2 dual-core CPUs, 2GB memory, 100GB disk, and EFI was enabled. I attached the installer ISO and started the VM. These instructions begin from when you get the root console after boot up.

Initial Steps

Check to make sure EFI is recognized and working.

efivar -l

I didn’t have DHCP running so instead used static IP. Find the name of your NIC; mine was ens32.

ip link

Setup IP address and gateway

ip addr add 192.168.0.55/24 dev ens32

ip route add default via 192.168.0.1

Configure DNS.

echo "nameserver 8.8.8.8" >> /etc/resolv.conf

echo "search codeghar.com" >> /etc/resolv.conf

Disk Partitioning

Get the name of the disk. It was sda in my case.

lsblk

I used LVM because I wanted to learn a bit more about it. I also prefer to have a single root partition because it makes things easier for me. I used parted to partition my disk into four partitions: 1 for boot and 3 for root.

parted /dev/sda print

parted /dev/sda mklabel gpt

parted /dev/sda mkpart primary 1049KB 2GB

parted /dev/sda mkpart primary 2GB 19GB

parted /dev/sda mkpart primary 19GB 49GB

parted /dev/sda mkpart primary 49GB 99GB

parted /dev/sda set 1 boot on

parted /dev/sda set 2 lvm on

parted /dev/sda set 3 lvm on

parted /dev/sda set 4 lvm on

parted /dev/sda print

lsblk

LVM

pvdisplay

pvcreate /dev/sda2

pvcreate /dev/sda3

pvdisplay

vgdisplay

vgcreate vgcodeghar /dev/sda2

vgextend vgcodeghar /dev/sda3

vgdisplay

lvdisplay

lvcreate -L 25G vgcodeghar -n lvroot

lvdisplay

modprobe dm-mod

vgscan

vgchange -ay

Format the first partition as FAT32 because we’ll use it for /boot and EFI requires(?) the boot partition to be FAT32.

mkfs.fat -F32 /dev/sda1

mkfs.ext4 /dev/mapper/vgcodeghar-lvroot

Base Install

mount /dev/mapper/vgcodeghar-lvroot /mnt

mkdir -p /mnt/boot

mount /dev/sda1 /mnt/boot

pacstrap /mnt base

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

cat /mnt/etc/fstab

Base Configuration (Start)

arch-chroot /mnt

Base Configuration – Swap File

Instead of a swap partition I decided to use a swap file.

fallocate -l 4G /swapfile

chmod 600 /swapfile

mkswap /swapfile

swapon /swapfile

echo "/swapfile none swap defaults 0 0" >> /etc/fstab

cat /etc/fstab

Base Configuration – Locale

sed -i -e 's/#en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/g' /etc/locale.gen

locale-gen

echo LANG=en_US.UTF-8 > /etc/locale.conf

export LANG=en_US.UTF-8

Base Configuration – Time

ln -s /usr/share/zoneinfo/US/Pacific /etc/localtime

hwclock --systohc --utc

Base Configuration – Network

echo codeghar > /etc/hostname

cp /etc/netctl/examples/ethernet-static /etc/netctl/ens32.cfg

Edit the file ens32.cfg and provide your static IP information.

nano /etc/netctl/ens32.cfg

Enable the configuration.

cd /etc/netctl

netctl enable ens32.cfg

Base Configuration – initram

Edit file /etc/mkinitcpio.conf and add lvm2 between block and filesystems in the HOOKS settings.

nano /etc/mkinitcpio.conf

Before:

HOOKS="base udev ... block filesystems ..."

After:

HOOKS="base udev ... block lvm2 filesystems ..."

mkinitcpio -p linux

Base Configuration – grub

mount -t efivarfs efivarfs /sys/firmware/efi/efivars

pacman -S grub efibootmgr

There seems to be a bug where I couldn’t get grub to work properly. The solution was to add an entry to the /etc/default/grub file.

nano /etc/default/grub

Add to file:

GRUB_DISABLE_SUBMENU=y

grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch_grub --recheck

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

Base Configuration – User

Set root password.

passwd root

Create new user. I tried to follow the example of a user account from Fedora.

groupadd cguser

useradd -m -g cguser -G users,wheel,storage,power -s /bin/bash cguser

passwd cguser

Base Configuration – Remote Access

pacman -S openssh

Configure SSH to disable root access and make any other changes you want.

nano /etc/ssh/sshd_config

systemctl enable sshd.service

Base Configuration (End)

I like to use vim so I install it as well.

pacman -S vim

Exit out of the chroot.

exit

umount -R /mnt

reboot

First Boot

You should now be able to boot to Arch and login via console or SSH.

Advertisements

The Importance of a Pleasurable User Experience

I’ve been thinking of getting myself a Raspberry Pi and configuring it to be my home network wireless gateway. While researching all the hardware pieces to get I thought I should try to decide on a Linux distribution. That quest prompted this post.

I’ve been using Fedora 19 with KDE for a good while now in an ESX VM. It does all the things I need and then some. But beyond that it’s been a pleasure working with it. I love the organized output yum provides. Other features like delta rpms and yum ps are also useful and just nice. I find the systemd user experience to be fantastic. It’s easy and simple to use. SELinux hasn’t bothered me so far. I can’t wrap my head around firewalld just yet but it stays out of my way as well. Fedora’s policy of sticking to upstream defaults means I get a purer upstream experience in an integrated distro. This is not always a good thing because KDE really has cumbersome or missing default settings. But once set up properly, KDE just runs and runs. I am in a Windows environment at work and RDP is just natural to use. Fedora 19 with KDE runs well enough over RDP using the xrdp package. I do get some harmless(?) error messages when first logging in over RDP but my work continues unabated.

With the release of Fedora 20 Beta I decided to give GNOME a try. My first impression is that it has a really good design for the shell, albeit on the minimalist side, and has great keyboard shortcuts. Some default settings don’t make sense to me but exploring gsettings has fixed some of the ones I care about. For the kind of work I do I have found GNOME Shell 3.10 to be an absolute pleasure to work with. It stays out of my way and I can focus on the things that really matter. Unlike all the hoopla about “power users” disliking GNOME Shell’s minimalism I found it to be very refreshing.

Coming back to Raspberry Pi, I’m quite comfortable with Fedora these days. In fact, when I use CentOS 6.4 I miss a lot of the things I’ve gotten used to in Fedora. So my first choice for RPi is Fedora, or Pidora, the spin specially made for it. The downside is that Pidora is tracking Fedora 18 and I want something new. I had hoped Fedora 20 would support RPi out of the box but can’t find any information on it.

My second option for RPi is Raspbian, a spin of Debian. Having gotten used to yum and systemd I find apt-get/aptitude and /etc/init.d to be far less pleasurable to work with. They get the job done equally well but I don’t like using them all that much. It’s just a matter of preference. I tried to dabble with creating deb and rpm packages and my initial take was that rpm is easier to create and manage. I’ll keep Raspbian as a second option for my RPi because I have experience with Debian. But I’d also like the Debian project to focus a bit more on making their tools more “fun” to use. Adopting systemd will be a good first step.

Ubuntu isn’t an option for RPi since they don’t support it just yet. I installed Ubuntu 13.10 in a VM to see how much it has changed since 12.04. I have to say the first thing I did was disable online searches in Dash, remove the Amazon icon from the launcher, and enable workspaces. These three things mean that Unity is no longer the same pleasurable experience it was in 12.04. Having used GNOME Shell 3.10 I missed the HUD but Unity’s “feature” of hiding the menu items became annoying quickly. It wasn’t so when I used 12.04 but KDE and GNOME Shell have made me realize you don’t really need to hide menu items even if you have HUD.

Ubuntu also has the issue of Upstart. It’s great to be able to use start/stop commands but not all services recognize them. I have to use start/stop, /etc/init.d, or service to start or stop my services. There’s no single method to do so. Enabling and disabling services is also cumbersome. I also dislike the policy of starting services right after installing or upgrading. Given these issues I find Ubuntu to not be a pleasurable experience anymore.

openSUSE 13.1 released today and it has some great things going for it. I haven’t tried it out but it’s because of one main thing: YaST. At the core of my being I find YaST to be a redundant tool for a lot of things, especially networking, firewall, and package management. I’d be very happy to skip YaST and just use CLI tools to manage most core things. I find those tools to provide a better experience than YaST’s CLI. I asked Jos Poortvliet, openSUSE’s community manager, on Twitter whether YaST was necessary and he said it wasn’t. I’ll take his word and try out openSUSE again, especially since they have a special build for RPi. I’ll revise my stance and make openSUSE my first choice for RPi. Maybe YaST will be helpful in creating my wireless gateway.

I also tried out Arch for the first time. It took me about 3-4 hours to make a customized list of steps to do a UEFI install as well as a BIOS install in a VM. I can say with all honesty that it wasn’t hard to install Arch at all since the wiki is so helpful. The wiki could be better but it’s still very useful. I thought that Arch’s simplicity and DIY nature would be a perfect fit for my RPi. I can install only the things I need and nothing more. I was excited.

And as I configured my VM further I realized I really have to do everything myself. Even the useradd command needs all the flags, compared to Fedora where you just provide the username. This brought me to my first crossroads: do I really want to create my own distro (so to speak) or have fun with setting up a wireless gateway? I think I’ll choose the latter. I want a distro to work out of the box which I can then use to do things other than creat emy own version of a Linux distro. Arch is a pleasure to use if you want to learn Linux but a burden if you want to use Linux to build something. I also feel like I want to go beyond re-inventing the wheel every time I do a new install, instead I want to build on top of the thousands of hours volunteers have spent building a solid distro, be it Fedora, openSUSE, Ubuntu, Debian, or whatever. I want to build a solution not a distro. I’ll still keep Arch as a candidate for my RPi because its simplicity is a very compelling factor.

So there you have it. I have tried to describe a pleasurable user experience by intertwining reviews of different distros with my needs for a wireless gateway using RPi. I find Fedora to be the most pleasurable distro today. It represents the hard work of a lot of upstream contributors in a package that’s friendly. It may not be the distro for new users but if I’m setting up a system for someone new to Linux, and I had to provide support for it, I’d use Fedora. For my RPi I’ll use openSUSE, Pidora, Raspbian, and Arch in that order. I’ll stop when I find the most pleasurable distro for that use case.