Having to re-install recently mac OS High Sierra 10.13 from a USB flash drive I got stuck getting the following error message:

macOS could not be installed on your computer.

No packages were eligible for install. Contact the software manufacturer for assistance.
Quit the installer to restart your computer and try again.

This happened repeatedly and I had recently used that same USB flash successfully.

It seems that the macOS installers will only work within a very defined time period after release. You can overcome this by changing the date during the installation.

After booting up and before selecting the volume where you want to install macOS you need to open the Terminal and change the date with the date command. Then proceed with the installation.

I am sure this issue happens with other macOS releases but I haven’t tested them all. It is a safe bet to change the date to a date not far from the original release date.

These examples below set the date to one day after the official release date of each version.

[OS X 10.11 El Capitan]
# date -u 1001000015

[macOS 10.12 Sierra]
# date -u 0921000016

[macOS 10.13 High Sierra]
# date -u 0925000017

[macOS 10.14 Mojave]
# date -u 0925000018

Feedback and confirmation if any of the above didn’t work for you is appreciated.

Server and minimal installs are normally headless and have no graphical interface.

If needed you can add a GUI manually. The process is slightly different depending on the distro.

RedHat / CentOS 7.x

# yum update
# yum groupinstall "Server with GUI"

RedHat / CentOS 8.x

# dnf update
# dnf groupinstall workstation

Ubuntu 18.04.x LTS

# apt update

[Install minimum GNOME desktop]
# apt install --no-install-recommends ubuntu-desktop

[Install full desktop with associated applications]
(Long process and too many extras installed)

# apt install ubuntu-desktop

[There are other alternative desktops and installations possible:]

[Generic Gnome desktop]
# apt install vanilla-gnome-desktop

[Mate]
# apt install ubuntu-mate-desktop

[Xfce]
# apt install xubuntu-desktop

[KDE]
# apt install kubuntu-desktop

[LightDM]
# apt install --no-install-recommends lightdm

Debian 9.x

# apt update
# apt install gnome-core

Debian 10.x

# apt update
# apt install gnome-core

All the above distros use systemd as their init system and you set the default run level with the same set of commands.

[Enable run level 5 by default]
systemctl  set-default graphical.target

[Enable run level 3 by default]
systemctl  set-default multi-user.target

Despite systemd you can still use init to start the graphical interface without having to reboot.

# init 5

If you install Firefox via repositories it might not install with your preferred language/settings. If your distro is in English it will default to American English as the main language and other English variations as additional spelling dictionaries.

You can change this from the CLI. The below examples will leave British English as the default buy it can be easily be adapted to your needs.

Be warned that the spellchecker is shared with other applications like LibreOffice.

Check which spellchecker is installed on your system. Older versions used myspell and current ones use hunspell.

$ apt list --installed | grep myspell
$ apt list --installed | grep hunspell

Older versions

# apt remove myspell-en-au myspell-en-us myspell-en-za myspell-en-ca

# apt install myspell-en-gb

Current versions

# apt remove hunspel-en-au hunspell-en-us hunspell-en-za hunspell-en-ca

# apt install hunspell-en-gb

Sometimes a process is taking a lot of CPU time and it isn’t clear what the cause is.

For example, at times it is common to see the kworker process consuming a lot of CPU. kworker is a placeholder process for kernel worker threads. These threads perform most of the actual processing for the kernel and you might want to see what device is involved.

You can run a CPU backtrace in Linux that records in dmesg what each one of the CPUs in the system are doing. This can be very useful to determine what specific process is hogging the CPU and in some cases to which module/driver it is related.

This is done using the magic SysRq key. This is a key combination that allows you to communicate directly with the kernel and perform several low level commands regardless of the state of the system. An exception would be a kernel panic, for obvious reasons.

When the magic SysRq key is enabled you can use the key combination Alt+SysRq+command key. There are many options and worth writing a future article just on it. The Wikipedia article explains some of them.

Because the magic SysRq key provides direct access to the kernel and the deep security implications of this it is disabled by default; if not in all, in most distros.

When the magic SysRq key is disabled and a backtrace is requested dmesg will not display any backtrace. So you can temporarily activate the magic SysRq key with:

# sysctl -w kernel.sysrq=1

or

# echo 1 > /proc/sys/kernel/sysrq

Be aware that this won’t persist between reboots. To turn it off you use:

# sysctl -w kernel.sysrq=0

or

# echo 0 > /proc/sys/kernel/sysrq

You can generate the backtrace with the Alt-SysRq-L key combination . If you need to script the backtrace or are accessing the system remotely, there is a CLI alternative to do the same:

# echo l > /proc/sysrq-trigger

And you can then check the results with:

$ dmesg

[ 3966.375451] Call Trace:
[ 3966.375463]  dump_stack+0x63/0x8b
[ 3966.375468]  nmi_cpu_backtrace+0x94/0xa0
[ 3966.375473]  ? lapic_can_unplug_cpu+0xb0/0xb0
[ 3966.375478]  nmi_trigger_cpumask_backtrace+0xe6/0x130
[ 3966.375482]  arch_trigger_cpumask_backtrace+0x19/0x20
[ 3966.375487]  sysrq_handle_showallcpus+0x17/0x20
[ 3966.375491]  __handle_sysrq+0x9f/0x170
[ 3966.375495]  write_sysrq_trigger+0x34/0x40
[ 3966.375500]  proc_reg_write+0x45/0x70
[ 3966.375504]  __vfs_write+0x1b/0x40
[ 3966.375508]  vfs_write+0xb1/0x1a0
[ 3966.375511]  SyS_write+0x55/0xc0
[ 3966.375517]  do_syscall_64+0x73/0x130
[ 3966.375521]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 3966.375525] RIP: 0033:0x7feca7544154
[ 3966.375528] RSP: 002b:00007ffedf5764b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3966.375532] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007feca7544154
[ 3966.375535] RDX: 0000000000000002 RSI: 000055c1c5642320 RDI: 0000000000000001
[ 3966.375537] RBP: 000055c1c5642320 R08: 000000000000000a R09: 0000000000000001
[ 3966.375539] R10: 000000000000000a R11: 0000000000000246 R12: 00007feca7820760
[ 3966.375542] R13: 0000000000000002 R14: 00007feca781c2a0 R15: 00007feca781b760
[ 3966.375547] Sending NMI from CPU 5 to CPUs 0-4,6-15:
[ 3966.375569] NMI backtrace for cpu 13 skipped: idling at acpi_idle_do_entry+0x19/0x40
[ 3966.375574] NMI backtrace for cpu 12 skipped: idling at acpi_idle_do_entry+0x19/0x40
[...]

The above example is from an idle system, but if the system was busier it would display more activity from other CPUs, system calls and what driver/module is involved.

If the same module, driver or hardware device keeps showing up in the backtraces you should check them as possible source of the high CPU utilisation.

[Updated instructions for Ubuntu 20.04 here]

I have had this USB wireless adapter working fine on Ubuntu 18.04 LTS for a while. A system update stopped it from working.

Re-installing the OS provided drivers (Software & Updates / Additional Drivers) made no difference. I tested the adapter in other operating systems and it worked fine.

It seems that from kernel version 4.15 onwards the drivers provided with Ubuntu no longer work, but the GUI shows as if the driver is correctly installed, it can see wireless networks and it even tries to connect to them. It will invariably fail to connect to any of them.

Others have encountered and solved this issue before me:

https://www.learningpenguin.net/2018/01/30/install-realtek-rtl8812au-wifi-driver-linux/

https://github.com/gnab/rtl8812au

Find below the steps to troubleshoot similar issues and a summary of the steps to install the correct driver as per the above links.

Check the hardware

Unplug and re-plug the adapter and check the output of:

dmesg

The following commands will also help in showing if the adapter is correctly detected.

$ lsusb
Bus 004 Device 002: ID 1058:25e1 Western Digital Technologies, Inc. 
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 2357:0103  
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The Bus 003 Device 002: ID 2357:0103 entry is the one that is the USB wifi adapter on my system even if it isn’t showing an identifier. You can remove the adapter and issue the command again and compare results to help you identify it.

For non-USB adapters you can use:

$ lspci

More detailed information about the device can be obtained with the lshw command.

$ lshw -C network
WARNING: you should run this program as super-user.
  *-network                 
       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       [output truncated]
    *-network:2
       description: Wireless interface
       physical id: 4
       bus info: usb@3:1
       logical name: enx18d6c70fbacc
       serial: 18:d6:c7:a1:22:ab
       capabilities: ethernet physical wireless
       configuration: broadcast=yes driver=rtl8812au ip=192.168.x.2 multicast=yes wireless=IEEE 802.11AC
WARNING: output may be incomplete or inaccurate, you should run this program as super-user.

This last command is really useful because it will give really important information about what driver to use.

In this case the chipset and driver to use is identified in this string driver=rtl8812au.

Check the drivers

Now check that the driver is loaded, you need to look for a string that is similar to the driver string above.

$ lsmod | grep 8812
8812au                999424  0

If the module isn’t loaded you can use modprobe modulename to load it.

# modprobe 8812au

Installing updated drivers

But in my case all of the above was correct but the card would still not work. This was caused by an incompatibility of the the drivers provided with Ubuntu and the updated kernel.

I should have checked the system logs earlier as I believe there was an entry there indicating a problem.

Uninstall the system provided drivers from the GUI .

• Go to Software & Updates
• Select Additional Drivers
• Find the entry for the wifi adapter (rtl8812-au) and select Do not use the device

You can do the same from the CLI:

[find the one you have installed]

# apt list rtl8812au*

[and uninstall]

# apt purge rtl8812au-dkms

Get the updated drivers from github:

$ git clone https://github.com/gnab/rtl8812au.git

Install the drivers with one of these two commands. They will work as long as you are pointing to the directory generated by the previous git command.

At the time of writing the latest release of the drivers are 4.2.3. Your output might vary.

[this command]

# dkms add ./rtl8812au/

[or this command]

# dkms add -m 8812au -v 4.2.3

Build and install the drivers:

# dkms build -m 8812au -v 4.2.3
# dkms install -m 8812au -v 4.2.3

Check that they were installed correctly:

# dkms status

And finally add the module to autoload during boot.

# echo 8812au | tee /etc/modules

You should now be able to join your wireless network without problems. As the driver is installed via dkms if there is a kernel update it will automatically update and recompile the driver for the new release.

If you ever need to uninstall the driver you can do it with:

# dkms remove -m 8812au -v 4.2.3 --all

You will also need to edit out the entry in /etc/modules.

One additional thing that caught me off was that if the adapter is connected to a USB 3.1 port it won’t work. USB 3.0 ports are fine.

During boot of your system and just after the BIOS messages Ubuntu might display a black screen with an error: no video mode activated message. The system boots normally but it is annoying.

GRUB by default hides the boot menu and this message can show up if there is no video mode set. It seems to be a known bug when the hidden option is active. I think you can just dismiss is it with ESC or ignore it as it has no adverse effect.

If you find it annoying you can get rid of it with the following steps.

Activate the menu option in GRUB.

vim /etc/default/grub

Make the following changes. Adjust your timeout to the number of seconds you want the boot menu to be displayed. Values below 5 seconds are difficult to catch.

#GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10

Update the changes:

$ sudo update-grub

Reboot and check that the changes have been applied correctly.

In the Gigabyte BIOS you need to activate a series of settings on different sections in order for KVM to be able to use hardware acceleration.

• M.I.T. -> Advanced Frequency Settings -> Advanced CPU Core Settings -> SVM Mode set to Enable

• Chipset -> IOMMU set to Enabled

Save settings and reboot.

Run the KVM check to see if the system is capable or running hardware accelerated virtualisation.

kvm-ok
virt-host-validate

If you still fail the check review your BIOS/motherboard documentation to activate the correct setting.

Ubuntu Server and Ubuntu Desktop use different network managers. Ubuntu Server uses networkd which doesn’t have a GUI component. So after adding a desktop to Ubuntu Server you won’t be able to see or change the configuration via the GUI by default.

	Ubuntu Desktop	Ubuntu Server
Configuration tool	netplan	netplan
CLI manager	nmcli	networkd
GUI manager	NetworkManager	n/a

For you to be able to see the network settings on the GUI you need to switch from networkd to NetworkManager.

Install NetworkManager:

apt install network-manager network-manager-gnome network-manager-openvpn network-manager-openconnect network-manager-openvpn-gnome

Check which systemd network daemons are active:

systemctl list-unit-files | grep -i network

Disable/stop networkd services:

systemctl disable systemd-networkd.service
systemctl disable networkd-dispatcher.service
systemctl stop systemd-networkd
systemctl stop systemd-networkd.socket
systemctl stop systemd-networkd.service
systemctl stop network-dispatcher.service

Remember that nmcli can be used for CLI NetworkManager control also.

Network interfaces are listed in yaml files in /etc/netplan/

Edit /etc/netplan/50-cloud-init.yaml and edit the line or add a line after the version: 2 entry to be renderer: Networkmanager.

network:
  ethernets:
    eno1:
      dhcp4: true
  version: 2
  renderer: NetworkManager

Check the changes and apply them:

netplan generate
netplan try / netplan apply