UEFI Arch install (GPT, ESP) Single boot

My advice is not to do this. I convert everything GPT to MBR to avoid GPT labels and EFI so that GRUB installs properly. So, if I run across a GPT named volume with EFI, I go straight into cfdisk, and blow out all the partitions. Then I gdisk that empty disk, hit "r", then "g", then write it with "w". Subsequently, fdisk can be used to write a DOS partition which will then show up in cfdisk as being toggleable to "bootable", when I finally go to make the new partitions.
UEFI means partition and boot issues (eg,how to do with no boot flag or MBR?) and possible boot loader settings. This page addresses many ESP issues, and this page UEFI issues more generally (scroll to UEFI). Also of course, there is this UEFI page.

There's a lot to consider (click on photo)

The booting order is apparently the UEFI firmware contacts an ESP partition (new concept), receiving information. This process also loads the EFI specific kernel informtion, (in the form of a filesystem?) "efivarfs", into /sys/firmware/efivars.

disk 20 mins

You'll have to overburn the install CD to get 740MB onto it. Of the possible options, cdrdao cannot be used without a TOC file to direct it, and dd has its dangers, so I tend to rely on cdrecord. With cdrecord, overburning should be specified, and random DAO errors that usually only appear at the end of the operation, can be prevented by running it in root.

$ cdrecord dev= HELP [get a device list]
# cdrecord -overburn -eject -dao -dev=/dev/sr0 ~/install.iso

Load the UEFI version of Arch, and then get information (eg fdisk -l sdX), at the prompt. I will want GPT, not MBR partitions: for partitioning, use cgdisk or gdisk instead of cfdisk for partition.

cgdisk /dev/sdX

... and then be sure to assign the proper qualities. New: four digit identifiers (eg 8300 for Linux and 8200 for the swap).It appears that filetype EF00 automatically sets an equivalent of a boot flag for its partition, so we only need one EF00 partition. This partition is said to need 250MB, so 1 GB should be enough.

Here might be a list of partitions:

1. 1GB - /boot (ESP) sdb1 - ef00
2. 40GB - / (apps) sdb2 - 8300 (this will be the basic "mnt" foundation)
3. 50GB - swap sdb3 - 8200
4. 900GB - /home sda1 - 8300

For GPT partitions, can use cgdisk for ncurses, or simple gdisk

# gdisk /dev/sdX
# n [add size, type]
# w [write it]
# gdisk -l /dev/sdX [list the partitions]

After partitioning, format them, eg mke2fs /dev/sda1. However, the ESP partition needs FAT32.

# mkfs.fat -F32 /dev/sdb1

basic configuration 20 mins

# 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
# arch-chroot /mnt
# ln -s /usr/share/zoneinfo/US/[zone]
# mkinitcpio -p linux
# passwd
# pacman -Syu grub efibootmgr
# grub-mkconfig -o /boot/grub/grub.cfg
# ls -l /boot/EFI/arch [verify grubx64.efi is here or locate it]
# grub-install --efi-directory=/boot/EFI/arch --target=x86_64-efi /dev/sdb
# efibootmgr -v [verifies all bootable efi's ]
# exit
# reboot

boot 90mins

At reboot, one may have the basic GRUB2 command prompt, not the curses version. This is called "rescue mode" GRUB, with limited commands. If command "boot" does not work, then one needs to return to their install disk, mount all the partitions again, and begin at the mkinitcpio step. Mkinitcpio cannot do its job of creating the ram disk if it can't find a kernel, so it's a good litmus test that the kernel is properly installed and available. There should be some vmlinuz in /boot. So, if this is missing, reinstall the base group entirely with pacman, so the mkinitcpio step is 100% certain.

# pacman -S --needed base

If this step informs that the system isup to date, "nothing to do", then force a kernel reinstall, especially if you could find no vmlinuz in /boot. Everything must be 100% to work with UEFI.

# find /var/cache/pacman/pkg -name 'linux*'

Get the specific name of the linux package in there, eg. 4.4-4, or whatever. Then...

# pacman -U /var/cache/pacman/linux[specifics].pkg.tar.xz
# ls /boot [verify a vmlinuz present]
# mkinitcpio - p linux
# grub-mkconfig -o /boot/grub/grub.cfg
# ls -l /boot/EFI/arch [verify grubx64.efi is here or locate it]
# grub-install --efi-directory=/boot/EFI/arch --target=x86_64-efi /dev/sdb
# nano /etc/systemd/journald.conf
SystemMaxUse=200K
# exit
# reboot

This should get us to Runlevel 2. Network configuration (eg, hosts, hostname, wifi arrangements, etc) is usually first since one needs a "pacman" configuration. Then perhaps pacman servers and keys, and then apps. For example, nearly every fresh install experiences dhcpcd time outs because it can't obtain an ipv6 dhcp address from a router.

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

# useradd -G wheel,lp,audio -s /bin/bash -m foo
# pacman -S wpa_supplicant wireless-tools jre8-openjdk jdk8-openjdk
# export LANG=C

nVIDIA or Nouveau

Still the same old story -- nVIDIA won't release the code (2016). If using nVIDIA drivers, some have to blacklist the i915 driver. To blacklist, create any file with a ".conf" extension in /etc/modprobe.d/, eg /etc/modprobe.d/blacklist.conf, then

# nano /etc/modprobe.d/blacklist.conf
blacklist i915

To review all drivers prior to selection...

# pacman-Ss xf86-video |less
# pacman -S xf86-video-nouveau mesa-vdpau libva-mesa-driver

I took the vdpau since the card's an nVidia. Also, I ultimately went with the nouveau drivers so we'll see. I dunno. Now for 50MB of xorg

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

Went entirely without the nVidia and so chose the mesa-libgl when the choice appears. We'll see. I can check it with, say

# pacman -Qqs nvidia

... to see if I put nVidia in by mistake. The other thing is I have a simple mouse and keyboard input, so I went with xf86-input-evdev instead of the more cutting edge xf86-input-libinput. We'll see, again. Note that no /etc/X11/xorg.conf is automatically created these days (2016) but users can create one. Example: a specific display problem requires it, viz to specify a BusID, etc.

I like IceWM. Hearkens back to the old days with its use of only a couple classic text config files: .xinitrc and Xresources. Those two X files are read at start-up and then there are a couple of text files internal to icewm also read during startx: ~/.icewm.preferences and ~/.icewm/startup. Preferences is like 1300 lines, with about 500 options. Love it.

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

45MB of thunar and its dependencies. For USB drives and so forth, I don't like gvfs at all, since to me it's a kludge, it includes PAM, I don't need a trash bin, and on. So udiskie (116 MB) is a good substitute.

# pacman -S thunar thunar-media-tags-plugin thunar-volman udiskie dosfstools ntfs-3g parted

Let's do 2MB of xterm, 45MB of geany, 78MB of vlc (caveat: vlc is Qt¹, so not gnome (gtk) friendly, and if you go with Qt, you eventually end up with PyQt, dunno why but it's true. All told ~ 400MB more for PyQt and Qt), 380MB of openshot (used ttf-bitstream-vera note:smbclient is part of the openshot install - yuck), 112MB of evince, and 150K of recordmydesktop.

ffmpeg or libav

What to do here? Michael Niedermeyer resigned from ffmpeg August 5, 2015. I still am most used to it and I know it typically has more features, if perhaps unstable. Ffmpeg, currently.

GRUB2 note

GRUB2 is one of the few linux boot managers that works with UEFI, but it is a horrible bootloader:

1. will not locate kernels
2. numbers disks differently than linux, eg, "hd" There is no intuive correlation between them. If I have only two hard drives, mounted as three partitions, sda1, sdb1, and sdb2, these may show as hd0, hd5, hd6. That would work, but GRUB wants the partition number as well, and there are only 2 physical drives. You will have to map this by trial and error.
3. requires as much or more configuration than the underlying OS installation
4. continuing on the configuration point, one cannot directly edit GRUB's configuration file, /boot/grub/grub.cfg

¹Nokia sold Qt trademark to Digia in 2012

systemd: time-outs, journal size, Xorg terminals

I prefer SysVinit to Systemd, in the same way I prefer OSS to ALSA, and ALSA to PulseAudio: the newer stuff creates problems where there were none. Among these problems are locating configuration commands or files in the face of opaque memory or CPU hogging defaults.

time-outs

During shut down and start-up, systemd will wait too long to kill or initialize internet connections, among other things. Set the systemd time-out restrictions...

dhcpcd tries to initialize

After an update, dhcpcd occasionally is re-enabled at boot. Since it tries all interfaces, it will hang on any that are not connected. Furthermore, the process is partly obscured, so it's tricky to find. The standard "list-unit-files" does not give a complete syntax. So although one disables dhcpcd.service, the other service is not fully named and is cryptically called by a different name in boot.

# systemctl list-unit-files |grep dhcpcd
dhcpcd.service disabled disabled
dhcpcd@.service indirect disabled

$ systemctl status dhcpcd*@*.service
* dhcpcd@enp4s0.service - dhcpcd on enp4s0
Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Tue 2020-06-09 04:32:17 PDT; 7min ago
Process: 362 ExecStart=/usr/bin/dhcpcd -q -w enp4s0 (code=exited, status=1/FAILURE)

The name you need here is dhcpcd@enp4s0.service, it cannot be disabled as the first name given, simply dhcpcd@.service. To stop this hang...

# systemctl disable dhcpcd@enp4s0.service
Removed /etc/systemd/system/multi-user.target.wants/dhcpcd@enp4s0.service.

journald logs

Prior to systemd, boot-ups used to log to /var/log, pretty much auto-magically via rsyslog (syslog). The only thing one had to configure was chron's timeline for rotating old logs into the trash. Suckily, journald logs grow until they take over something like 10% of disk space by default. To me, it's yet another mistake of the last 8 years of Linux -- adding boggy new application layers instead of improving and simplifying long-standing daemons¹. At any rate, journald must be configured if you want anything reasonable and intelligible. Secondly, you must use "journalctl" the read them, because they are stored in a binary format.

Since there are about 30 settings in /etc/systemd/journald.conf, an hour is wasted researching journald's settings.

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

When I want an ASCII record for grepping, etc, I use journalctl -r -o short-iso ("r" reverses time to put most recent on top, "short-iso" is for giving normal clock timestamps), and save screen output to text:

$ journalctl -r -o short-iso 2>&1 file.txt

Alternatively, one can output other formats such as the apparently standard JSON format. It cannot however export directly to text unless it's to another application.

This the file when the system is running well and no logging is needed:

Storage=none

notes

• 200K of logging seems to cover about the last 10 boots.
• journalctl --verify checks logs for corruption

xorg terminals

If systemd is not restricted, it will open 40+ terminals when you open X, buring hundreds of unnecessary MB's of memory. Seven terminals is sufficient for operations inside X

# nano /etc/systemd/logind.conf
NAutoVTs=6

---

¹It's as stupid as when PulseAudio took hold of Alsa (which itself overlaid OSS)

xdm - installing and customizing

Links: Linux Journal 1999(!)

---

I strongly agree with this post's comment that kdm and gdm are lib-laden and overall bloated. To simply login, we just might want a different background photo than the the standard x box, but that's all the customization I need. In fact, I prefer runlevel 3 at startup, but if I'm helping someone with Linux that prefers a window-esque GUI right from the start, then it's got to be runlevel 5.

install - file changes

One can just download xdm with pacman. There are only two important file changes: 1) xdm (and all display managers) read .xsession instead of .xinitrc. 2) changing to runlevel 5 means altering /etc/inittab I organized a working xdm on a friends system with the following...

# nano /etc/inittab
x:5:respawn:/usr/X11R6/bin/xdm -nodaemon -config /etc/X11/xdm/archlinux/xdm-config

$ cp .xinitrc .xsession

customizing

One of the best instructions on this remains from 1999 (link at top). XDM goes way back.