Setting up Arch on UEFI laptop

A good friend had mentioned to me that he used Arch linux in one of his recent installs. I’ve never tried it. I have this old HP laptop that a different friend gave me, when he replaced it. It isn’t that old! I decided to try installing Arch on it.

I had a bunch of issues, and ultimately today I resolved to reinstall the thing again, and record my experience. One of the issues – as usual a self-inflicted wound – is that this is a UEFI capable laptop, but the disk that is in it is MBR partitioned, not GUID partitioned. It probably would have been smarter to just partition the disk with a GUID table. But I didn’t. Below is the description of what I did.

Here starts an additional edit, recounting how, my first (actually my second, and even my third) attempt went wrong, after appearing to work. I eventually figured out why, so before describing what worked, it may be useful to review the mistakes for the lessons they give.

I was following an installation guide on the net for installing Arch, because I had no experience with Arch or pacman. But I had some differences in my environment so I was modifying the instructions as I went along and adapting. I adapted a little too aggressively, and alas incorrectly.

On almost all the boxes I build I have gotten into the habit of having a separate /boot partition. I suppose this really isn’t all that necessary anymore, particularly if one is using UEFI but I got into the habit long ago. The instructions I was following did not create a separate /boot (so I adapted). Also, the instructions were for bios rather than uefi, and this box is uefi so I had to adapt that too – had to create an efi system partition etc. So early on in my adventure, I partitioned the disk with 4 partitions: an esp a /boot, / and swap.

When one installs the basic arch one apparently doesn’t automatically get an /etc/fstab, and the instructions at one point called for generating one, with a command genfstab, which I have never had to use on any other distribution. Being unfamiliar with it, and because I was unfortunately just following along by rote at that point, I failed to think about the fact that neither the /boot nor the esp was actually mounted at that point in the instructions. The upshot is that therefore no fstab record got created in fstab for the /boot partition.

Later in the instructions I had to “adapt” and mount /boot before I wrote the grub onto the disk, and before I installed the grub config — and I adapted those parts “correctly”, so that the system booted up just fine. However, because there was no automount in fstab for /boot, it wasn’t being mounted after a reboot. Well this was fine, the system boots just fine without mounting /boot. Right up to the time you need to write something on the /boot partition. 

The problem comes when at some point you do some update which updates the kernel (or probably if you install anything that has to build a new initramfs). Because now the “real” /boot partition is not mounted. When grub or mkinitrd or whatever writes new stuff to reflect the new kernel (or whatever) onto /boot, it is not writing it on the boot partition but on a local /boot directory.

So what ends up happening is something like this: a new kernel n+1 (vmlinuz and initramfs) is written on the /boot local directory, but not on the missing /boot partition. A /lib/modules directory is written with the modules directory for kernel n+1.

Speculation: the /lib/modules directory for kernel n seems at this point to have been removed, because it isn’t there later on, and I’m guessing that this is because at this point there is no kernel n visible (because the /boot partition containing it isn’t mounted). We don’t need /lib/modules/n if there is not a kernel/initramfs for release n. I’m not sure of that part, I just know there was no /lib/modules/n later on.

When the actual boot takes place, grub is still loading from the /boot partition, and so it actually still loads kernel n. But now there aren’t any modules for kernel n to load anymore. With no modules the system comes up as a basic module free system, no graphics driver, no network driver, etc.

I am pretty sure this was my problem, although I haven’t worked through all the details of exactly what happens, and how it gets to the state it is in. But it was certainly true that uname -r gave me a release name which was not present in /lib/modules. I am a little surprised that it was able to bring up gdm at all.

So here are the revised instruction. I am not creating a /boot partition at all.

Partition the hard disk

  • /dev/sda1 /efi 512MB type efi
  • /dev/sda2 extended
  • /dev/sda5 /root all but 15G type linux
  • /dev/sda6 swap 15G type swap

Format the disks:

  • mkfs.fat -n EFI /dev/sda1
  • mkfs.ext4 /dev/sda5
  • mkswap /dev/sda6

And mount the root partition to-be so we can mess with it.

mount /dev/sda5 /mnt
swapon /dev/sda6 

Install the basic system

pacstrap /mnt base base-devel 

Create fstab

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

Now chroot into the newly created root partition

arch-chroot /mnt 

Generate locale info.

uncomment US.UTF-8 in /etc/locale.gen
echo LANG=en_US.UTF-8 > /etc/locale.conf
export LANG=en_US.UTF-8

Set the timezone and set hardware clock

rm /etc/localtime
ln -s /usr/share/zoneinfo/America/Denver \    
hwclock –systohc –utc 

Update the software:

pacman -Syu 

Set password for root

Create user dee

useradd -mg users -G wheel,storage,power \
   -s /bin/bash dee 

Set the password for dee

Now install additional software we need. I’m an emacs user, so I need that early. I need subversion because I pull a lot of config stuff out of my repository, including a setup script that builds a lot of stuff (sshd, postfix, samba, nfs, and much more).

pacman -S sudo subversion emacs \ 
   grub os-prober mtools efibootmgr \ 
   xorg xorg-server networkmanager \
   gnome gnome-extra 

I like to not have to type in a password when I sudo. Fix group wheel to be no password.

export EDITOR=emacs 

Now the booting stuff.

Mount the efi partition before trying to write grub.

mkdir /efi; mount /dev/sda1 /efi 

Install grub onto the new disk

grub-install  --target=x86_64-efi \
    –efi-directory=/efi \
    –bootloader-id=GRUB /dev/sda 

And generate the grub config file for grub to drive off of

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

Now exit out of the chroot, back to the live image. Then unmount and reboot.

umount -a

When the system comes back up, which it should do unless I screwed something up, login as root and start and enable gdm.

systemctl enable gdm; systemctl start gdm 

At this point, I can get my setup scripts from my repository, and run them to set up sshd, mail, samba, nfs, vnc and whatever else I need.