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.
After writing this, at one point I lost the laptop again and had to restore. Some of my instructions were wrong, and in any case I changed the laptop over to a GPT partition table, and reinstalled. I had some trouble, so I want to get the revised instructions down.
Partition the hard disk
- /dev/sda1 /efi 512MB type efi
- /dev/sda2 /root
- I didn’t need a swap
Format the disks:
- mkfs.fat -n EFI /dev/sda1
- mkfs.ext4 /dev/sda2
And mount the root partition to-be so we can mess with it.
mount /dev/sda2 /mnt
Install the basic system
pacstrap /mnt base base-devel linux \ linux-firmware emacs NetworkManager
genfstab -U -p /mnt >> /mnt/etc/fstab
Now chroot into the newly created root partition
Set the hostname in /etc/hosts and hostname and $HOSTNAME
Generate locale info.
uncomment US.UTF-8 in /etc/locale.gen 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 \ /etc/localtime hwclock –systohc –utc
Update the software:
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 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 \ 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 visudo
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.
exit umount -a reboot
When the system comes back up, which it should do unless I screwed something up, login as root and start gdm. Don’t enable it yet, be sure everything is working in graphical.target before doing so.
systemctl start gdm
Log in as dee, be sure everything is working, have network, terminal, sudo, etc., then enable gdm.
Now retrieve the scripts to finish setup. Ensure /usr/local/bin is empty the remove it. Pull in the scripts, ensure everything is executable, use a script to make symlinks for all the “common” local bin scripts (used by all my boxes).
cd /usr/local rm bin svn co \ https://svn.wmbuck.net/svn/adminscripts/localbin\ /<hostname> bin chmod +x ./* cd common chmod +x ./* ./commonlocalbin
The last step is the script which finishes the setup.