Part 1 basic install: working CLI
| 1. overview | standard install, except touchscreen configuration |
| 2. modify bios | OS loads into device from USB. BIOS will not allow that unless UEFI disabled and legacy ROM enabled. Reactivate UEFI after installation, if desired. |
| 3. prep disk | UEFI and GPT clearing. Used MBR to avoid GRUB errors. |
| 4. installation | various basic configurations |
customize: /etc/systemd/system/rc-local.service
Part 2 GUI and tweaks
| 5. X86 install | tweaks to processor specific, other configuration, icewm |
| 6. touchscreen | special software and configuration |
customize: ~/.xprofile, ~/.xinitrc, ~/.icewm/startup
A person likes to have a touchscreen with their music library near the bed: the SO can select whatever music she's looking for.
These old 2-in-1, 2.3GHz i5's will do the trick. Can be found for about $125 (2024) online or about $160 delivered. A person *might* want to upgrade the basic 8Gb DDR4 2133MHz SDRAM (60 pin) to 32Gb, and 128Gb Liteon CV3-8D128-11 (SATA 1) to a Liteon CV3-8D512-11 (SATA 1). The 512Gb M2 ($70) and 32GB RAM ($60) would make the system fully configured for a $300 total. But this isn't necessary to play the movies and music our SO wants to select with her fingertips. $160 does the trick. Put the library on the hard drive and run a 3.5mm connector to a decent speaker system. She might complain, but it's better than nothing.
If a person just wants to do earbuds in bed, the inexpensive Mijiaer/Langsdom JM26 3.5mm earbuds are comfortable, and also good for a hands-free in a vehicle if cut-off one bud.
Touchscreen is an ELAN 283.2mm x 176mm.
1. nothing special... except
The install mostly is the same as a 2020 install into a non-touchscreen Latitude e7270. There are some package updates since that time, and touchscreen-specific packages. I shifted to the XFS file system from EXT2, learned how to add XFS partition labels, but the swap partition remained the annoying UUID. I used a USB tethered phone for the install -- no internet/dhcpcd issues.
The touchscreen. First touchscreen install is time-consuming for enabling right and double click. Ie, kernel recognizes finger touches "out of the box" --using xf86-input-evdev -- but didn't translate these into application functions. The only reasonable answer appeared to be Touchégg to configure touchscreen effects.
2. bios security adjustments :: 15 mins
To install from the USB, we have to disable UEFI and make the device friendly to an inserted USB.
- Enter BIOS
- Secure Boot -> Secure Boot Enable: Disable, Apply
- Security -> PTT (Platform Trust Technology) Security: Uncheck "PTT On", Apply
NB: No need to check "Clear", but if a person does check it, the warning: "Data encrypted with keys stored in the TPM will be lost. Are you sure you want to clear all keys from the TPM?" I don't know if it's good/irrelevant to delete these keys.
- General -> Advanced Boot Options: check "Enable Legacy Option ROMS". I also uncheck "Enable UEFI Network Stack" in case it causes Network over-security issues, even beyond PAM and other ridiculous 'safety' issues.
- General -> Boot Sequence: check "Legacy"
After all this, the boot order menu becomes available. Users can then promote "USB" to the top of the menu, and install the OS from the USB. I put the M2 SATA SSD second so that after install, I can remove the USB and it will boot from the SSD.
3. GRUB/disk prep :: 15 mins
Currently (2024) GRUB still seems finnicky when using a GPT ("globally unique identifier partition table") disk. So, in addition to eliminating EFI, I convert all GPT to MBR. This requires three applications:
cfdisk (delete all partions),
gdisk (to detect GPT and revert to MBR) and
fdisk ("fdisk -t" to create an MBR. 0x04.)
- # fdisk -l determine the drive name, eg /dev/nvme1
- # cfdisk /dev/sda, delete all partitions, which eliminates EFI. Write this partitionless drive and exit
- # gdisk /dev/sda note whether GPT is present and MBR protected. Mine notes both and that "using GPT". I selected "x" for "expert command", then "z" to zap the entire GPT structure, which was confirmed. Then it asked if I want to "Blank out MBR"?, to which I replied "yes". When i then retried # gdisk /dev/sda, all (MBR, BSD, APM, and GPT) were not present. This is correct, but "x,z,y" again to be sure.
- # cfdisk /dev/sda, select DOS label, and proceed. The main is a linux (83) sda1 and a linux swap (82) sda2,
The only real question is whether to make multiple partitions for different parts of the OS. For this example, I've put them all in a single partition.
4. base CLI (runlevel 2) configuration :: 20 mins
# mkswap /dev/sda1
# swapon /dev/sda1
# free -m [check swap is on]
# mkfs.xfs /dev/sda1
# xfs_admin -L "labelname" /dev/sda1 [optional]
# mount -rw -t xfs /dev/sda1 /mnt
# 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 dhcpcd xf86-input-evdev
# mkdir /boot/grub
# grub-mkconfig -o /boot/grub/grub.cfg
# grub-install /dev/sda [no partition]
# exit
# reboot
if oversights or mistakes
Let's say I forget to
# pacman dhcpcd after pacstrap, and now I'm booting straight off the drive. It's extremely difficult to setup even a wired connection, let alone WiFi with just the tools in
# So go back to
arch-chroot and install from there.
# mount -rw -t xfs /dev/sda1 /mnt
# arch-chroot /mnt
# pacman -Syu dhcpcd wireless-tools ntp nano xf86-input-evdev [this last for the touchscreen]
# exit
# reboot
Similarly, you want to pull window manager menus and so on prior to starting X the first time...
$ mkdir media
# mount -rw -t ext2 /dev/sda1 /media
$ cd media
[do whatever operations]
# umount /dev/sda1
locale :: 0 mins
I don't set a locale, but here's
some information if interested.
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 access - yay :: 20 mins/200Mb of other files
AUR access was simple during the yaourt years, but the archlinuxfr repo isn't around since 2023. The best now is yay, albeit built on the 300Mb slug "go" dependency.
To build and install they do it through fakeroot, which ejects if sudoers is not configured.
# nano /etc/sudoers
foo ALL=(ALL) ALL
Then retrieve, compile, and install
# pacman -S git go wget
$ git clone https://aur.archlinux.org/yay.git
$ cd yay
$ makepkg -si
$ yay --version [verifies installed OK]
limit journalctl size :: 5 mins
Systemd will log GB's and GB's of data if left unresetricted.
# nano /etc/systemd/journald.conf
SystemMaxUse=200K
5. X install :: 20 mins
Dells have 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.
QT or Gtk
I used to stick with one or the other to keep a smaller install and shorter update. Nowadays both seem necessary. I prefer GTK (except gvfs), but VLC requires QT. QT is about 400MB, and typically pulls in PyQT, whereas GTK3 is a slick 100MB. 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
6. touchscreen issues
This is really the crux of it. I'd never had a touchscreen and it looked like some of it was system dependent, and with mutual solutions.
When the keyboard is still flipped-out, Shift + F10 emulates R click on mouse. Of course there's no keyboard once we go to touchscreen. The Arch Touchscreen Wiki has some relevant touchscreen info.
Management *may* be possible with synclient, but Touchégg seems to be the best app for managing touchscreen actions. The system runs in two parts, a daemon that gathers clicks, and a client that says what to do with them. The first part, the daemon, is simple enough.
# pacman -S touchegg
# systemctl enable touchegg.service
# systemctl start touchegg
The client spawns connection errors if the daemon is overlooked.
Once the daemon is running, a person runs the client. Eureka, we can use an old skool .config/touchegg/touchegg.conf file to configure the client. There's Touché, a GUI, for this, but I prefer ye olde conf file so as to be portable across installs, and to be sure. It's a basic XML format. The developer's configuration page.
