Latitude D520 Arch install

Problem: your grandparent or a teacher's assistant needs a work-a-day laptop, but you're not a first responder, professional athlete, or an investment banker. If you can carry one (5lbs), 2007 Latitude D520's are available on EBay for about $60. They are 64bit 2 core processors. Load 'em up with 2 Gigs of RAM, Arch Linux and IceWM: within an $80 budget, you've got a laptop that'll do common functions without much lag. It'll show movies, edit photos and audio. High CPU tasks like rendering Blender output, or other video editing, takes ages (so just avoid video editing).

CD (10 mins)

Download an ISO and check the MD5. Put in a fresh disc. I found it's best to burn using root -- some systems bark, even with group permissions configured, at cdrecord at user level. I typically add "eject" as a simple completion notification, but it's not needed.

$ cdrecord -scanbus
# cdrecord -dao -eject dev=0,0,0 install.iso
$ md5sum /dev/sr0

base CLI (runlevel 2) configuration :: 20 mins

There's no UEFI or other boot complexities on older systems. But if you have a newer system, get rid of UEFI. Format the disk with "fdisk -t" to create an MBR. 0x04. The only real question is whether to make multiple partitions. The instructions below include multiple partitions. If multiple partitions aren't desired, just make two primary partitions in cfdisk: a linux (83) SDA1 and a linux swap (82) SDA2, and jump from the step mounting on /mnt to the step with mkdir /mnt/etc

# mkswap /dev/sdb3
# swapon /dev/sdb3
# free -m [check swap is on]
# mount -rw -t ext3 /dev/sdb2 /mnt
# mkdir /mnt/home
# mount -rw -t ext3 /dev/sda1 /mnt/home
# mkdir /mnt/boot
# mount -rw -t ext3 /dev/sdb1 /mnt/boot
# mkdir /mnt/etc/
# genfstab -p /mnt >> /mnt/etc/fstab
# pacstrap /mnt base base-devel linux linux-firmware
# arch-chroot /mnt
# ln -s /usr/share/zoneinfo/US/[zone] /etc/localtime
# mkinitcpio -p linux
# passwd
# pacman -Syu grub
# mkdir /boot/grub
# grub-mkconfig -o /boot/grub/grub.cfg
# grub-install /dev/sda
# exit
# reboot

useradd :: 5 mins

User 500, name "foo", home directory of "foo", using bash shell.

# useradd -G wheel,lp,audio -u 500 -s /bin/bash -m foo

aur :: 30 mins

Used to be so simple, so I'm including it again here in case it returns some day:

# nano /etc/pacman.conf
[archlinuxfr]
SigLevel = Never
Server = http://repo.archlinux.fr/$arch

# pacman -Sy yaourt

However, even in past, one had to have base-devel installed, and to add oneself to the sudoers file. Unfortunately, editing sudoers is done through the visudo command, which uses those stupid vim commands:

# visudo
foo ALL=(ALL) ALL

However, yaourt hasn't been maintained since 2018, so the (only) way to get it is to build it from scratch out of AUR source, as in olden times. The AUR website has aur source. Be sure you've got wget installed (# pacman -S wget), retrieve the package, untar it, morph it into a pacman version ("makepkg"), then install it using pacman with a "U" flag. The "U" flag has pacman looking into the current directory instead of out over the Net. Prior to building any AUR helper (yaourt, aurman), you'll need to first build "package-query", also from the AUR.

Also there is a wikipedia page and reddit conversations. In spite of its weaknesses, I continued to use yaourt. I downloaded aurman, but was unable to compile it.

$ mkdir pkgs
$ cd pkgs
$ wget https://aur.archlinux.org/cgit/aur.git/snapshot/package-query.tar.gz
$ wget https://aur.archlinux.org/cgit/aur.git/snapshot/yaourt.tar.gz
$ tar xzvf package-query.tar.gz
$ cd package-query
$ makepkg -s
# pacman -U package-query[version]tar.xz

And then the same with yaourt thereafter.

dhcpcd timeouts/limit journalctl size :: 5 mins

If you're having dhcpcd timeout problems, they can show up in pacman and curl, and are usually due to IPV6. This ipv6 request mod has to be re-accomplished after every dhcpcd package update.

# nano /etc/dhcpcd.conf
# custom to stop ipv6 service request timeouts
noipv6rs

Systemd will log GB's and GB's of data if not limited

# nano /etc/systemd/journald.conf
SystemMaxUse=200K

X install :: 20 mins

These Dells have the Intel integrated graphics 945GM; the correct xf86 driver is the Intel VA driver.

# pacman -S xf86-video-intel
This driver now uses DRI3 as the default Direct Rendering
Infrastructure. You can try falling back to DRI2 if you run
into trouble. To do so, save a file with the following
content as /etc/X11/xorg.conf.d/20-intel.conf :
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "DRI" "2" # DRI3 is now default
#Option "AccelMethod" "sna" # default
#Option "AccelMethod" "uxa" # fallback
EndSection

# pacman -S xorg-server xorg-apps xorg-xinit xorg-xrandr

If you scroll down this Arch page discussing Xorg, we can see that we'll want the mesa for Open GL and lib32-mesa for older apps. Also, Intel chips, as we know (scroll down to about item 13), do not support VDPAU, viz:

"Intel Embedded Graphics Drivers do not support VDPAU. VDPAU stands for video decode and presentation API for UNIX*. VDPAU is an open source library and API originally designed by NVIDIA that provides an interface to support hardware-accelerated video decode."

... and so Intel sez libVA is correct. More specific to Arch, there's additional information in their video acceleration page, if you like to read. The only problem with the VA-API is it can't decode MP4 and FLASH containers, but it does all other common formats, and all codecs, including H264 and the new VP8 and 9. I just use MKV and AVI containers and set the VLC codec to VA (instead of its default VDPAU). In spite of inefficiencies on the Intel hardware, some may wish to overlay VDPAU functionality onto their Intel chip, which is an installation beyond this post. If a person does that, any mistakes will defeat X working properly -- no harm, just revert to runlevel 2 and reconfigure until Xorg is working well. FYI, one of the tweaks I've seen for VIDPAU overlaid onto VA, is adding "export VDPAU_DRIVER=r600"in one's ~/.xinitrc file. Anyway, back to pure libVA...

# pacman -S libva libva-intel-driver libva-utils libva-mesa-driver

... then check the install with "$ vainfo".

window manager :: 10 mins

On an old system, I don't waste memory with display managers, instead I login and "startx" from runlevel 2. I like Ice Window Manager, a light interface with simple text configuration, wallpaper, and menu files (look inside ~/.icewm ). Efficient on older systems: perhaps 150M usage after logging-in, connecting to network, and starting X. In Arch, the template files are inside /usr/share/icewm/, including the themes. See the main Arch file.

# pacman -S icewm
$ cp /etc/X11/xinit/xinitrc .xinitrc
$ nano .xinitrc
exec dbus-launch icewm-session
$ startx

I also looked here to get the names of additional drivers, for example to solve the pesky touchpad problem. I couldn't stop the Dell touchpad with synclient TouchPadOff=1 until I # pacman -S xf86-input-synaptics.

wifi digression :: 60 mins

Some of these old Latitudes have the dreaded Broadcom 43 series card. For example, if users run lspci and the wifi readout line is this or similar...

Network controller: Broadcom Limited BCM4311 802.11b/g WLAN (rev 01)

... then it's unlikely the typical fix for older cards, # pacman -S wireless_tools will have effect. It's also unlikely anything will appear in either of these two verification steps...

# iw dev
# cat /proc/net/wireless

If this is the case, the easiest move is installing yaourt and building a b43 driver, but take note:

"BCM4306 rev.3, BCM4311, BCM4312 and BCM4318 rev.2 have been noticed to experience problems with b43-firmware. Use b43-firmware-classicAUR for these cards instead."

During that b43-firmware-classic^AUR install, the following warning was displayed...

Please add $VISUAL to your environment variables
for example:
export VISUAL="vim" (in ~/.bashrc)
(replace vim with your favorite editor)

...and you may also encounter

~/.config/aurvote must have username and password. Run: aurvote --configure

...if you installed the yaourt rating app but hadn't configured it. You can use any username and pass you like. Reboot after this install, and something like this is normal:

# iw dev
phy#0
Interface wlan0
ifindex 3
wdev 0x1
etc..

QT or Gtk

I try to stick with one or the other to keep a smaller install and shorter update. Sometimes both become necessary. I prefer GTK (except gvfs), but VLC requires QT. QT is about 400MB, and typically pulls in PyQT. But since I'm a fan of VLC ... QT became my baseline API.

# pacman -S qt4

However, you're going to see that udiskie (to avoid gvfs) brings in about 80MB of shit, including basic Gtk.

sound

I avoid PulseAudio as much as I can. See my post from 2016. ALSA is now built-in, so that all that's required is alsamixer in order to control the sound levels (unmute, etc)

# pacman -S alsa-utils

Done.

rc.local

A consolidated place for random startup shit too lazy to configure individually. It's like an initrc in X, but for runlevel 3.

# nano /etc/rc.local
#!/bin/bash
wpa_supplicant etc
dhcpd etc
exit 0

# systemctl enable rc-local.service should make it happen next boot, but you also have to create the service file before enabling it.

# nano /etc/systemd/system/rc-local.service

# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.

[Unit]
Description=/etc/rc.local Compatibility
ConditionPathExists=/etc/rc.local

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target