Showing posts with label arch. Show all posts
Showing posts with label arch. Show all posts

Monday, August 12, 2024

more key nightmares

Links: Arch - package signing

TLDR: in 2024, one's system, gpg keyservers, and Arch repositories all need to be *up*, properly configured, and current, to accomplish a standard Arch pacman Syu. Solutions given in decreasing order of intervention severity.

overview

"Key" conflicts or expiry during pacman updates have become the most consistent annoyance in Arch, (alongside PulseAudio, more Linux-wide). Eg, in 2024, waiting even two weeks between system updates likely will spawn an unrecoverable, unintuitive pacman key failure during pacman -Syu. What is happening?

Pacman used to just check a hash of the application package. NOW, Arch additionally checks hashed signature keys for each application's creator/repository uploader. The shift to increased verification led to use of an additional application: gpg. A further complication -- gpg stores and retrieves keys from a dedicated repository, a "keyserver", which is separate from the application repository. A yet further complication is that gpg deposits the latest keys into user's system, in /etc/pacman.d/gnupg and does not regularly update these.

pacman is still the update manager, but gpg is now a critical adjuvant app, and which must handshake its keys with pacman during each update, yet does not update its keys between pacman updates. Immense time can be lost navigating this setup; this post only has the bandwith to list solutions. Basically, if any pacman key failures, I first attempt to update the keys (pacman-key --refresh-keys) and then I go nuclear. I don't have days to waste.

Solutions in decreasing order intervention severity.


thermo-nuclear

# nano /etc/pacman.conf
# temporary key solution: add SigLevel never and
# comment-out default "Required"
SigLevel = Never
# SigLevel = Required DatabaseOptional

A regular pacman-Syu now works. After update success, and a reboot, we reset /etc/pacman.conf back to default "Required".

We've accomplished the update, but now we find that the problem with keys still exists. That is, we still can't, eg., run pacman-key --populate, without the same error messages and Catch-22 with 'pacman-key --init' that we experienced earlier:

# pacman-key --populate
==> ERROR: There is no secret key available to sign with.
==> Use 'pacman-key --init' to generate a default secret key.
# pacman-key --refresh
gpg: error reading key: No public key

The Catch 22 is that we're driven to run 'pacman-key --init', but 'pacman-key --init' fails 100% of the time, stating we have no public key, LOL. "I can't make what you need since you don't already have it".  In 2024, I don't know a way to circumvent this keys issue without significant time-wasting alternatives. I just give it a key.

# gpg --gen-key --homedir /home/USER/.gnupg --passphrase "PASSWORD" --pinentry-mode loopback
gpg: WARNING: unsafe ownership on homedir '/home/foo/.gnupg'
GnuPG needs to construct a user ID to identify your key.
Real name:

After all of this, we'll get some success message...

gpg: /home/foo/.gnupg/trustdb.gpg: trustdb created
gpg: directory '/home/foo/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/home/foo/.gnupg/openpgp-revocs.d/BFA0F3753DA6EA552E08958F06E36EA3F9E270C0.rev'
public and secret key created and signed.
...after which...
# pacman-key --init
# pacman-key --populate

...work normally. Now we can do regular pacman updates with regular keyring checks. We have to repeat the laborious process however, typically when it's been a few weeks or longer between updates.

nuclear

stackexchange wisdom
# gpgconf --kill gpg-agent
# rm -r /etc/pacman.d/gnupg
# rm -r /root/.gnupg
# rm -r /home/foo/.gnupg
# rm -r /etc/pacman.d/gnupg
# rm -r /root/.gnupg
...after which
# pacman-key --init

light cure

A typical usual cure...

# pacman -Sy archlinux-keyring -
...after which try the stronger
# pacman-key --refresh-keys

catch-22 circular fail

Notice 100% gpg reliance.

# pacman-key --populate
gpg: problem with fast path key listing: No such file or directory - ignored
==> ERROR: There is no secret key available to sign with.
==> Use 'pacman-key --init' to generate a default secret key.
# pacman-key --init
gpg: problem with fast path key listing: No such file or directory - ignored
==> Generating pacman master key. This may take some time.
gpg: Generating pacman keyring master key...
gpg: agent_genkey failed: No such file or directory
gpg: key generation failed: No such file or directory
gpg: Done
==> Updating trust database...
gpg: no need for a trustdb check

directly into gpg: gpgconf

# gpgconf --list-components
gpg:OpenPGP:/usr/bin/gpg
gpgsm:S/MIME:/usr/bin/gpgsm
keyboxd:Public Keys:/usr/lib/gnupg/keyboxd
gpg-agent:Private Keys:/usr/bin/gpg-agent
scdaemon:Smartcards:/usr/lib/gnupg/scdaemon
tpm2daemon:TPM:/usr/lib/gnupg/tpm2daemon
dirmngr:Network:/usr/bin/dirmngr
pinentry:Passphrase Entry:/usr/bin/pinentry
# gpgconf --kill gpg-agent

Thursday, July 20, 2023

arch version of latex

ARCH wiki

It's sort of a PITA, but less so than going to TUG and downlading 10G or whatever is the latest. Seems like most things can be done for approximately 1G of space, though more like 2G if adding Jabref and significant Math compiling support .

Another note: to search for a specific style, when not sure which package it's in, use the "F" option in pacman. I used this to find the "ulem" package since I wanted to strike-out some text...

$ pacman -F ulem.sty
extra/texlive-plaingeneric 2023.66594-19 (texlive)
usr/share/texmf-dist/tex/generic/ulem/ulem.sty

...and then I installed "texlive-plaingeneric" 24Mb (see below)

basic

These 4 will compile most letters and articles

# pacman -S texlive-latex texlive-basic texlive-latexrecommended texlive-plaingeneric

To include any URL's (hyperref) and some math, then additionally need (150Mb):

# pacman -S texlive-latexextra

If it fails for a font size unable to compile, then add (150Mb!):

# pacman -S texlive-fontsrecommended

math

If getting serious with math (+18MB)

# pacman -S texlive-mathscience

troubleshoot

delete old aux files

Moving from one machine to another, delete the aux file if fails for being able to, eg, locate the basic letter.cls document class.

check at command line

say I have a letter thats not compiling in my api. Try it at the command line.

$ pdflatex fooletter.tex
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Arch Linux)
(preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
(./fooletter.tex
LaTeX2e <2022-11-01> patch level 1
L3 programming layer <2023-02-22>

! LaTeX Error: File `letter.cls' not found.
I found the answer here I think I can put paths in .Xinitrc.

bibtex

Goes in oK with the latex versions above, but consider two additionals 1, additional styles, and 2) jabref.

$ yay -S jabref-latest
$ jabref

This 280MB behomoth allows a person to easily edit their BibTex files and check for integrity of formatting and so on. Really helps with large bibliographies.

Thursday, April 9, 2020

2016 Latitude E7270 6600U Install

Safety: BitLocker (encryption), UEFI, Fingerprint. Uninstall packages:

# pacman -Rsn

NB:Headphones (also hands-free) Mijiaer/Langsdom JM26 3.5mm earbuds


Problem: your situation requires reliable Zoom (or other) teleconferencing but you're not a first responder, professional athlete, nor an investment banker. If you can carry one (2.74 lbs), 2016 carbon fiber, non-touch screen version Latitude E7270's are available on EBay for about $250 delivered. These are not display showoffs, w/ 12.5" screens, and only integrated Intel HD Graphics(520), but they are solid business grade: 16 GB DDR4, i7 6600U Skylake w/100Mhz FSB, and 1080P webcam: they will do the job reliably. Think 256G PCIe3 SSD, Arch Linux and IceWM: for that $250, one has a laptop which will teleconference, plus audio might be edited -- a single 3.5mm combined jack. Watching movies or editing pics on a 12.5" however, is suboptimal.

upgrade/replacement notes: Please scroll down to bottom for sections on replacement, esp batteries and SSD. The laptop takes an M.2 card style NVME SSD so its a little complicated.

Packaging appeared good, visual inspection was clean and the charger and battery tests went well (1 hr). The subsequent Arch installation was an additional 4 hours.

bootable USB :: 20 mins

  1. Download the latest ISO. Necessary or the signature keys might error during install.
  2. # fdisk -l find the drive name, eg /dev/sdc OR...
  3. $ lsblk | grep -i sd
  4. # cfdisk /dev/sdc, delete all partitions and write, exit
  5. # dd bs=4M if=/home/foo/Downloads/archlinux-2020.03.01-x86_64.iso of=/dev/sdc oflag=sync The sync flag takes a little longer but you can be sure it will be properly on the usb.

BIOS shifts :: 15 mins

Two equally important adjustments must be made in BIOS: 1) booting from USB for install and, 2) when booting from HDD, non-windows, non-secure, booting and no disk encryption.
  • Enter BIOS, press F12 repetitively during power up.
  • Secure Boot Enable -> "Disabled"
  • General -> Advanced Boot Options -> "Enable Legacy ROM's"
  • General -> Boot Sequence -> Enable "Legacy"
Also, I noted I luckily had the latest BIOS version 1.20.3 (7/2016) but there's a process if not. Link: configure BIOS for USB boot :: update the BIOS

GRUB/safety problem :: 15 mins

Currently (2020) however, GRUB 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.)
  1. # fdisk -l determine the drive name, eg /dev/nvme1
  2. # cfdisk /dev/nvme1, delete all partitions, which eliminates EFI. Write this partitionless drive and exit
  3. # gdisk /dev/nvme1 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/nvme1, all (MBR, BSD, APM, and GPT) were not present. This is correct, but "x,z,y" again to be sure.
  4. # cfdisk /dev/nvme1, select DOS label, and proceed. The main is a linux (83) nvme1p1 and a linux swap (82) nvme1p2,
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.

base CLI (runlevel 2) configuration :: 20 mins

# mkswap /dev/nvme1p2
# swapon /dev/nvme1p2
# free -m [check swap is on]
# mke2fs /dev/nvme1p1
# mount -rw -t ext2 /dev/nvme1p1 /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
# mkdir /boot/grub
# grub-mkconfig -o /boot/grub/grub.cfg
# grub-install /dev/sda [no partition]
# exit
# reboot

go back to install disk

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 ext2 /dev/nvme1p1 /mnt
# arch-chroot /mnt
# pacman -Syu dhcpcd wireless-tools
# 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/nvme1p1 /media
$ cd media
[do whatever operations]
# umount /dev/nvme1p1

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 :: 30 mins

Used to be so simple with yaourt, however it hasn't been maintained since 2018. The best option now is yay, built on the 300Mb behomoth go dependency. This first part is the same:
# nano /etc/pacman.conf
[archlinuxfr]
SigLevel = Never
Server = http://repo.archlinux.fr/$arch

# pacman -S go wget git base-devel
$ git clone https://aur.archlinux.org/yay.git
To build and install they do it through fakeroot, which looks at the god-damned sudoers file. Unfortunately, editing sudoers is done through the visudo command, which every stinking website tells users not to circumvent, and which uses the ridiculous VIM editor. Here's the workaround...
# nano /etc/sudoers
foo ALL=(ALL) ALL
... and once that's done...
$ cd yay
$ makepkg -si
If you have to hand install the TAR.XZ, use 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.
# pacman -U package-query[version]tar.xz
And then the same with yaourt thereafter.

limit journalctl size :: 5 mins

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.

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. 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

replacement info

batteries - 55wh(4 Cell) LPD-J60J5 $30

Li-Ion, power is 7.6VDC. These go bad. When I first opened the case, the battery was swollen and pushing against the case cover. The charging circuit is built-in, which might have failed. Or the battery has a place for heat paste on the bottom, which might not have been seated. If only there were a LiPo which fit it for less than $100. Replacement Li-Ion J60J5 costs $25 (2022) but 2.5 bucks tax, then thermal paste and cleaner another $15. We're looking at $40+.

After install, there are several ways to check the battery, but this is perhaps the easiest way:

$ upower -i /org/freedesktop/UPower/devices/battery_BAT0

Thermal paste application (8:48) Laptop Performance Tricks, 2019. Appears this is solution video with all relevant tips. Vid is for a Dell G7 rather than the Dell E7270.

storage: ssd pcie $30

Nowadays, we're not dealing with 2.5" SATA HDD's that spin-up. The installed card is a 256Gb NVMe PCIe Gen3 x 4, so 2 lanes are not used. That's because PCIe bus (FSB) is standard 100Mhz, but is discount model with 2 lanes. It's upgradeable to 1TB for probably $70, and to simply replace the 256Gb Gen3 about $30.

Sunday, December 11, 2016

espeak - alsa and hdmi environment

Overview: Speech synthesis has become nearly trivial, but a typical ALSA setup relies on sound card definitions from the config files ~/.asoundrc or /usr/share/alsa/alsa.conf (I typically delete the former and modify the latter). A complex hardware situation will almost always require some modifications to the config file. Installing espeak into such an environment often requires yet further config file modifications. I often wish OSS were still developed. Note: espeak uses the PortAudio library, specifically relying upon libportaudio. Verify installation in Arch with $ pacman -Ss portaudio.

symptom

Attempted espeak statements provide pcm error messages and no audio. Environment: Two sound "cards" -- one Intel MB chip, one NVidia graphics card sound chip. NVidia card selected b/c HDMI cable. ALSA HDMI configuration working flawlessly with all input and output apps (except espeak). ALSA espeak errors:
$ espeak "hello world"
ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib confmisc.c:1281:(snd_func_refer) Unable to find definition 'cards.HDA-Intel.pcm.front.7:CARD=1'
ALSA lib conf.c:4371:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4850:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2450:(snd_pcm_open_noupdate) Unknown PCM front
ALSA lib pcm.c:2450:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2450:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2450:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib confmisc.c:1281:(snd_func_refer) Unable to find definition 'cards.HDA-Intel.pcm.surround51.7:CARD=1'
ALSA lib conf.c:4371:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4850:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2450:(snd_pcm_open_noupdate) Unknown PCM surround21
ALSA lib confmisc.c:1281:(snd_func_refer) Unable to find definition 'cards.HDA-Intel.pcm.surround71.7:CARD=1'
ALSA lib conf.c:4371:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4850:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2450:(snd_pcm_open_noupdate) Unknown PCM surround71
ALSA lib confmisc.c:1281:(snd_func_refer) Unable to find definition 'cards.HDA-Intel.pcm.iec958.7:CARD=1,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib confmisc.c:1281:(snd_func_refer) Unable to find definition 'cards.HDA-Intel.pcm.modem.7:CARD=1'
ALSA lib conf.c:4371:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4850:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2450:(snd_pcm_open_noupdate) Unknown PCM phoneline
ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
attempt to connect to server failed
At least two issues jump out: espeak sound is (inexplicably) attempted through the Intel card instead of the NVidia card, so that's probably why all the other subassemblies are also unreachable and spawning errors. "Dsnoop" may also be an issue.

To solve the first problem, we can easily change the values inside /usr/share/alsa/alsa.conf further than my previous post on ALSA HDMI agreement. That is, per this post, comment the line for pcm.front, and each additional line of fail as follows:
# nano /usr/share/alsa/alsa.conf
# pcm.front cards.pcm.front
pcm.front cards.pcm.default
This reroutes dynamic loading on a per command basis to the default card, eliminating the error. But this means lines and lines of corrections. Note that it appears all of these are due to HDA-Intel (instead of NVidia), being called as during dynamic loading. Let's see if we can just rewrite one line to fix the called card to NVidia, instead of doing line-by-line edits on downstream results from calling the HDA-Intel.

First let's try to specify the hardware device, as we can do in:
$ aplay -D plughw:1,7 /usr/share/sounds/alsa/Front_Center.wav
We know ALSA is thus working. So we can do a two-step method using ALSA to be sure espeak is working:
$ espeak "Hello world" --stdout |aplay -D plughw:1,7
If nothing comes out of this, or if there is no content inside a WAV produced with
$ espeak "Hello world" -w somefile.wav
... then it's time to strace.

Friday, November 18, 2016

pacman: update archlinux-keyring to solve corruption

I recently ran an update which did fine except for...
error: udiskie: signature from "Ambrevar " is unknown trust
:: File /var/cache/pacman/pkg/udiskie-1.5.1-1-any.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] Y
error: failed to commit transaction (invalid or corrupted package)
Errors occurred, no packages were upgraded.

After attempting several fixes and checking Arch forums, I stumbled across this manjaro forum. Sure enough:
# pacman -S archlinux-keyring
Following this, it was a simple
# pacman -S udiskie
to catch it up.

Wednesday, July 20, 2016

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 Qt1, 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
1Nokia sold Qt trademark to Digia in 2012

Saturday, March 12, 2016

[solved] wpa_supplicant following system update

Looking at friend's monitor (running Arch), I saw his clock was behind, so I wanted to # ntpdate pool.ntp.org his system. It turned-out ntp hadn't been installed. I started with #pacman -S ntp, but dependency errors appeared -- the typical sign that a system needs updating. So, # pacman -Syu, and sure enough, it was at leas 4GB out of whack. Afterwards, all was good for adding ntp and running ntpdate. His clock updated.

The problem was, the first time he cycled power, his wifi didn't connect. I found I could easily connect his system manually (CLI) with
# wpa_supplicant -Dwext -iwlp1s0 -c/etc/wpa_supplicant/wpa_supplicant.conf &
or better...
# wpa_supplicant -Dnl80211 -iwlp1s0 -c/etc/wpa_supplicant/wpa_supplicant.conf &
So, WTF? One possibility was that, beginning in 2016, dhcpcd stopped connecting its built-in wpa_supplicant hook during dhcpcd install. It has to be done manually. There's also a second option, giving at least two solutions.

two solutions

  1. # systemctl disable wpa_supplicant.service
    # cp /usr/share/dhcpcd/hooks/10-wpa_supplicant /lib/dhcpcd/dhcpcd-hooks
    This puts dhcpcd in charge, calling and restarting wpa_supplicant, as needed. Make sure the right PID directory (if needed) and password are in /etc/wpa_supplicant/wpa_supplicant.conf, so it can negotiate security. Also, if dhcpcd is hanging looking for an IPV6 connection, a person can add the "-4" flag to the "ExecStart" command in /usr/lib/systemd/system/dhcpcd.service. Problem solved; back to rock solid wifi connection.
  2. Instead of putting dhcpcd in charge, put wpa_supplicant in charge, calling dhcpcd. This is not recommended since it requires a bunch of complicated custom shit described below

unit file

I checked systemd (systemctl list-unit-files) and, as expected, I saw that wpa_supplicant was no longer enabled. When I enabled wpa_supplicant, it created symlinks which were not straightforward ("epitest.fi"?), which I did not trust as helpful. So I wrote him a straightforward service unit file specific for initializing his wifi:
# nano /etc/systemd/system/johndoewifi.service

# custom wifi connect
# Arch location: /etc/systemd/system/johndoewifi.service
[Unit]
Description=wpa_supplicant wext wifi
Wants=network.target
After=network.target
# Before=network.target

# execute and run in background
[Service]
Type=forking
PIDFile=/var/run/wpa_supplicant.pid
ExecStart=/usr/bin/wpa_supplicant -Dwext -iwlp1s0 -c/etc/wpa_supplicant/wpa_supplicant.conf
# ExecStop=/usr/bin/wpa_supplicant -x

[Install]
WantedBy=multi-user.target

restart from user

You can get wpa_supplicant to run from user, with eg
# nano /etc/wpa_supplicant/wpa_supplicant.conf
# Allow users in the 'wheel' group to control wpa_supplicant
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
If John Doe is in the wheel group he can start wpa_supplicant no problema. However, it will fail, since he doesn't have authority to bring the interface UP or DOWN from userspace. That requires another kludge.
(source: Gentoo wiki)

Thursday, June 25, 2015

[solved] screen blanking

Link: Excellent Blanking Overview

The Linux solutions in forums seem to me to often lack some necessary detail. And if something is missing, a person doesn't even know this, of course, until they entirely overcome whatever was left out. That might be hours or days later, if ever. It can be frustrating.

For screen blanking management, the key detail, unstated in any forum solution I found, was to first be sure blanking was disabled in runlevel3. Screen blanking settings are baked into the kernel, and if they're not first managed in runlevel3, prior to startx, blanking cannot be narrowed down to X settings. Rule-out half of the possible screen blanking problems by disabling runlevel3 blanking.

Run Level 3 (Non-GUI blanking isolation)

Again, do this first, prior to working on X, since terminal blanking is baked into the kernel and must be defeated before any X solution will work. In runlevel3 terminals, the setterm command controls several terminal settings, among them blanking times. To stop blanking in the terminal:
$ setterm -blank 0
The setterm command is not permanent when used in a terminal -- the next boot will reset to default kernel settings. To permanently stop blanking users can: disable blanking using their GRUB/LILO configuration, add a bootline flag, or make a systemd command. But another permanent option, which I considered the easiest hack for my installation, was to add a setterm line into /etc/profile. In other words:
$ nano /etc/profile
setterm -blank 0
This arrangement survived reboots. And, with the runlevel3 managed, I could attempt various X session solutions. Ideally, I wanted a 2.5 hour blank-out so I could watch a film while going to sleep and have it blank soon after.

X session failed configurations

Typically, the primary file for X configuration is ~/.xinitrc. If you're running Arch, multiple options are described here. Users may have to try several configurations or combine them. In my case, no suggested settings within ~/.xinitrc was successful. Even a suggested combination of runlevel3 and x commands did not work, for example:
$ nano .xinitrc
setterm -blank 0 -powersave off -powerdown 0
xset s off

X session successful configuration

Per the same link, after failures with ~/.xinitrc, I created a DPMS file to place into /etc/X11/xorg.conf.d/. The file was named, 10-monitor.conf. Here is one way to set it up.
# nano /etc/X11/xorg.conf.d/10-monitor.conf
Section "Monitor"
Identifier "LVDS0"
Option "DPMS" "false"
EndSection

Section "ServerLayout"
Identifier "ServerLayout0"
Option "BlankTime" "150"
Option "StandbyTime" "155"
Option "SuspendTime" "160"
Option "OffTime" "0"
EndSection
This worked for me. As described here, one can tweak these entries. Trial and error revealed that times in the ServerLayout are in units of minutes. I left "OffTime" as 0, to disable automatic power-down.

Summary: Manipulating blanking requires two files, one to stop runlevel3 blanking, and a second to adjust X session blanking.

Saturday, November 29, 2014

[solved] arch - update and java

Following Oracle's purchase of Java (2010), Java users can't be certain when Oracle attorneys or developers might make users' lives uncomfortable. If one wants Java functionality however, Oracle can't be avoided entirely. I am not a lawyer, but Oracle's open-source version of Java, OpenJDK, may be the most legally prudent Java option. That said, not every application plays nice with OpenJDK, of course, or Oracle wouldn't be able to profit from licensing its more user-friendly proprietary versions of Java.

What has the above meant to me operationally? When upgrading Arch with OpenJDK onboard, I've sometimes experienced conflicts which required a solution of, 1) uninstalling Java, 2) running the Arch update(s), and, 3) reinstalling or upgrading to the latest OpenJDK.

Arch update Java conflicts may look something like these (during pacman -Syu):
error: failed to commit transaction (conflicting files)
java-runtime-common: /usr/bin/java exists in filesystem
java-runtime-common: /usr/bin/keytool exists in filesystem
java-runtime-common: /usr/bin/orbd exists in filesystem
java-runtime-common: /usr/bin/pack200 exists in filesystem
java-runtime-common: /usr/bin/policytool exists in filesystem
java-runtime-common: /usr/bin/rmid exists in filesystem
java-runtime-common: /usr/bin/rmiregistry exists in filesystem
java-runtime-common: /usr/bin/servertool exists in filesystem
java-runtime-common: /usr/bin/tnameserv exists in filesystem
java-runtime-common: /usr/bin/unpack200 exists in filesystem
java-runtime-common: /usr/lib/jvm/default exists in filesystem
java-runtime-common: /usr/lib/jvm/default-runtime exists in filesystem
Errors occurred, no packages were upgraded.

The shortest path appears to be removing "java-common". Not so fast: OpenJDK requires java-common as a dependency; pacman typically will not allow its removal. The solution is to remove OpenJDK (at this writing version 7), update the system, and then reinstall OpenJDK:
# pacman -Rns jre7-openjdk
# pacman -Syu
# pacman -S jre7-openjdk

Applications (eg, geogebra, icedtea-web) that bark at this removal may also have to be removed prior to the Arch update, and then reinstalled (after jre).

location in system

$ ls -an /usr/bin/java
/usr/bin/java -> /usr/lib/jvm/default-runtime/bin/java

$ locate /bin/java
locate /bin/java
/usr/bin/java
/usr/bin/javaws
/usr/lib/jvm/java-8-openjdk/jre/bin/java
/usr/lib/libreoffice/ure/bin/javaldx
/usr/share/icedtea-web/bin/javaws

$ ls /usr/lib/mozilla/plugins
IcedTeaPlugin.so libflashplayer.so [missing java-plugin libnpjp2.so]

# find -name libjava.so
/usr/lib/jvm/java-8-openjdk/jre/lib/amd64/libjava.so
You can't find libnpjp2.so because you don't have normal java installed. Typically, you make a soft link between libnpjp2.so and the mozilla plugin directory. But in this case WITH OPEN JDK, our java soft link for mozilla (when we need it) is the icedtea plugin so we're actually set. All you have to do is go into "Add-Ons" in your browser and enable/disable it.


LibreOffice

After an Arch OpenJDK update, the LibreOffice portion sometimes still will notice you...
Optional dependencies for libreoffice-still
java-runtime: adds java support
java-environment: required by extension-wiki-publisher and extension-nlpsolver
...telling you for sure LibreOffice didn't detect OpenJDK. I opened LibreOffice -->Tools --> Options --> Advanced.



I selected the radio button for the Oracle option and then "OK". These actions seemed to activate Java.

Blackboard and Pipelight apps

Only Firefox has the stuff needed to process Moonlight, instead of Silverlight. Software must be installed that allows geolocating and so forth. These can be turned on and off by creating a softlink.

On the Blackboard account, also use Firefox (JRE).
ln -s /usr/lib/pipelight/libpipelight-silverlight5.1.so /usr/lib/mozilla/plugins/libpipelight-silverlight5.1.so