Setting up Arch Linux on an old Alienware

8 Jun 2023 • ~1500 words • ~7 minute read

My trusty Dell XPS 13 (9350), which I got in early 2016, has an issue with its monitor and has been out of commission since January (I will get it sorted one of these days).

I use my laptop a great deal, so really felt its absence and recently decided to revive an old Alienware gaming laptop that has been gathering dust over the years.

I've been using Arch Linux as my main distribution on both my desktop and laptop for about three years now. I have a set up which I know and keep under control (in theory) and replicate fairly easily, but obviously its three years or more since I last did an installation from scratch.

I thought I'd jot down a few of the things I (re-)learned along the way.

Installation

Arch's installation guide (Arch Wiki)

I've always found the Arch Linux docs to be thorough and clear. I've pretty much used them as my main source of informtion on anything Linux-y since forever.

On the whole, their installation guide remains clear and concise, with links out to pages on specific topics/tools which need some additional clarification. Just what you expect from the Arch Wiki.

One minor thing that caught me out: in the partitions section, it says:

The following partitions are required for a chosen device:

  • One partition for the root directory /.
  • For booting in UEFI mode: an EFI system partition.

As I was planning on booting into legacy mode (BIOS), I read this to mean just one partition was needed. But when it came to one of the final steps (installing the boot loader), I had to go back and create a second partition for GRUB.1

This is as much a fault of mine, as I should have planned ahead and read up before starting the install - instead I just dived in. It was no matter though, it took little time to correct.

Kernel choice

All my existing Arch installations use the LTS kernel, but I felt like mixing things up a bit this time and decided to go with the zen kernel.2 In reality, it will make no difference to my lightweight computer use - but this choice did throw a few things up. More on those later.

Beyond those two things, it wasn't a very eventful installation :)

Post-installation

The Arch Wiki has a nice set of general recommendations to follow, if needed.

Once the OS and boot loader are installed, it's all about setting up the system. I didn't install much during the installation, I prefer to install on an as-needed basis. I think the only thing I added to the pacstrap command was neovim (as a text editor is required), and Git.

For me, the first thing is to create a user and give them sudo privileges. Then I install the xdg-user-dirs.

Graphical environment

Wayland

I have been using XMonad as my window manager for several years now, but the fresh install got me thinking that I might try out Wayland.

There was a list of Wayland window managers on the AW. First one that caught my eye: Vivarium (not sure why, maybe because it's inpired by XMonad!).

I noticed it was in the AUR so installed Aura, an AUR helper, and tried to install Vivarium. Aura flagged up a message about PGP signatures not being verified.

I cloned down the source control from GH and tried compiling from source, but there was some issue with the XCB package (I can't remember what).

So I tried Hyprland, as this was just in Arch's core package manager so should be straightforward. It installed, but paniced when I tried running it.

I then tried River, also from the core packages. Same issue.

X (i)

At this point, I figured I'd stick with what I know and pulled my dotfiles down so I could compile my XMonad binary. When running stack install, the compiler kept hitting an error relating to missing X11 stuff (Haskell stuff, not system packages).

By now, it was around 1am and I shut the laptop and went to bed!

Hyprland

In the morning, I came back and tried stack install again (which failed again), so tried Hyprland once more and, which worked. (Just to make clear - during the initial process of trying to set up a graphical environment, I was doing regular reboots to see if this helped, following some form installation or config change. It made no difference at the time.)

Anyhow, following the successful setup of Hyprland, I tinkered around a bit. I quite liked what I saw, I played with the configuration a bit, installed some more of the standard packages I use (Emacs, a browser, etc).

XMonad

The apparent randomness of Hyprland working got me wondering if I could get XMonad compiling okay.

I tried stack install again and got the same error. I then looked into the stack.yaml file and wondered whether I needed to bump the resolver URL to a more recent version (it was on /lts/19/3, but from what I could see the most recent version was /lts/20/24). I figured that this, together with working on the most recent commits in the xmonad repositories, it should work (?).

Running stack install again, I got a lot further, but hit a different set of errors. I then deleted the generated stack.yaml.lock file and tried again, and finally got a compiled XMonad binary. Obviously something had been captured into that lock file when commits and resolver versions were a bit out of sync. (I guess, anyways.)

X (ii)

With XMonad installed, I expected to just be able to run startx from the TTY after logging in. It exited with the message: unable to connect to X server: Connection refused. Turned out that in my context switching between getting Wayland and XOrg working, I hadn't been paying attention to ensuring packages were installed. So I installed xorg-server (I already had xorg-xinit), which fixed that issue.

Package management

I've been using Paru as my AUR helper for the last couple of years and I thought I'd give Aura a go. It's written in Haskell and, like Paru, acts as a wrapper around Pacman as well as an AUR helper.

So far, I quite like it. I've even started using it as a wrapper around Pacman, which I never do with Paru. I find it's intuitive to use and I really like the way it presents things out the box (the layout of info, the colour, etc).

Networking

I used ethernet for the installation and the day or so after. Setting up the wifi was a little bit more fiddly than with my Dell XPS: I couldn't get my wireless card showing for a wee while.

When I ran lspci -vnn -d 14e4: I was seeing my device, but nothing wifi-related would show from ip link (ethernet was of course showing).

This Alienware laptop has a Broadcom wireless adapter. Turns out Broadcom are a bit awkward and it seems that this particular chipset (BCM4352) is one of the few which doesn't have a native driver.3

As a side note, I discovered that the linux-firmware package has been slimmed down, with various targeted firmware offshoots needing installed specifically, depending on what's in your machine.4

The typical Broadcom chipset driver (brcm80211) is baked into the kernel, but this wasn't driving my wireless adapter. After searching around, I read that my chipset needed the broadcom-wl package, though because I opted for the zen kernel, I need the broadcom-wl-dkms version,5 which is kernel agnostic.6

The AW also flagged that this would need the linux-headers package for the installed kernel too (so linux-headers-zen, in this case). I installed all this and ran lspci -vnn -d 14e4: again and noticed that this time the 'kernel driver in use' section read wl. After a reboot, I could see that Network Manager was picking up my wireless adapter. All was plain sailing from there.

Things for next time

I'm hardly using this laptop, so am not precious about wiping it and doing a new installation. A few things I've always meant to tinker with but not done yet include:

  • Encryption
  • LVM - Logical Volume Mounting

So I may give that a go over a rainy weekend and report back.

Footnotes

1

This has possibly not been an issue for me before because I think all my other installations are on UEFI systems.

2

Officially supported kernels page on the AW.

3

See the Linux Kernel page on this for more details.

4

Arch Linux news update

5

I believe the non-DKMS version would have been fine if I had gone with either the standard kernel or the LTS one

6

See the AW page on Broadcom wireless for more information