Reconfiguring the time zone, locales and keymaps in Sabayon Linux

This is an example of how to reconfigure the time zone, locales and keymaps in a Sabayon Linux installation from the command line. Sabayon Linux uses systemd, therefore much of this example should also be applicable in other Linux distributions that use systemd, and will certainly be applicable in Gentoo Linux installations that use systemd rather than OpenRC.

You can check the currently selected keymaps (console and X Windows) and locale using the ‘localectl status‘ command. For example:

user $ localectl status
   System Locale: LANG=en_GB.UTF-8
       VC Keymap: uk
      X11 Layout: gb
       X11 Model: pc105

Let’s say I had previously configured my installation to use only the en_GB and en_US locales but I now want to add Swiss Italian. The steps would be as shown below. I will assume the system being configured is in Switzerland and therefore I will also reconfigure the time zone accordingly, but that is not essential.

Check if the desired time zone exists:

root # timedatectl list-timezones | grep Zurich
Europe/Zurich

Set the desired time zone:

root # timedatectl set-timezone Europe/Zurich

Check if the Swiss Italian locale (it_CH) has already been added:

root # localectl list-locales
C.utf8
en_GB
en_GB.iso88591
en_GB.utf8
en_US
en_US.iso88591
en_US.utf8

If the desired locale is not present, add it:

root # nano /etc/locale.gen
root # grep -v "^#\|^$" /etc/locale.gen
C.UTF-8 UTF-8
en_GB.UTF-8 UTF-8
en_GB ISO-8859-1
en_US.UTF-8 UTF-8
en_US ISO-8859-1
it_CH.UTF-8 UTF-8
it_CH ISO-8859-1

Generate the locales:

root # locale-gen
 * Generating 7 locales (this might take a while) with 1 jobs
 *  (1/7) Generating C.UTF-8 ...                                          [ ok ]
 *  (2/7) Generating en_GB.ISO-8859-1 ...                                 [ ok ]
 *  (3/7) Generating en_GB.UTF-8 ...                                      [ ok ]
 *  (4/7) Generating en_US.ISO-8859-1 ...                                 [ ok ]
 *  (5/7) Generating en_US.UTF-8 ...                                      [ ok ]
 *  (6/7) Generating it_CH.ISO-8859-1 ...                                 [ ok ]
 *  (7/7) Generating it_CH.UTF-8 ...                                      [ ok ]
 * Generation complete
 * Adding locales to archive ...                                          [ ok ]

Check the locales have been added:

root # localectl list-locales
C.utf8
en_GB
en_GB.iso88591
en_GB.utf8
en_US
en_US.iso88591
en_US.utf8
it_CH
it_CH.iso88591
it_CH.utf8

Set the desired locale:

root # localectl set-locale LANG=it_CH.UTF-8

Check which Italian console keymaps are available:

root # localectl list-keymaps | grep it
it
it-ibm
it2
mac-it

But let’s say I want to use a Swiss German keymap (sg) for the console instead of an Italian keymap. Check if a console keymap for Swiss German exists:

root # localectl list-keymaps | grep sg
sg
sg-latin1
sg-latin1-lk450

By the way, Debian, Ubuntu and its derivatives store console keymaps differently to some distributions, and the command ‘localectl list-keymaps‘ in Debian, Ubuntu and its derivatives will return an error message (the command ‘localectl set-keymap’ will still work though):

user $ localectl list-keymaps
Failed to read list of keymaps: No such file or directory

Set the console keymap to Swiss German:

root # localectl set-keymap sg

Let’s say I want to use a Swiss keymap in X Windows. Check if it exists:

root # localectl list-x11-keymap-layouts | grep sg
root # localectl list-x11-keymap-layouts | grep ch
ch

Set the X Windows keymap to Swiss:

root # localectl set-x11-keymap ch

Update the environment variables and profile:

root # env-update && source /etc/profile
>>> Regenerating /etc/ld.so.cache...

Edit /etc/default/grub and change (or add, if none exists) the console keymap entry in GRUB_CMDLINE_LINUX_DEFAULT to be vconsole.keymap=sg, and also rd.vconsole.keymap=sg (‘rd‘ stands for ‘RAM disk’) because Sabayon Linux uses an initramfs:

root # nano /etc/default/grub

Regenerate grub.cfg:

root # grub-mkconfig -o /boot/grub/grub.cfg
Generazione file di configurazione GRUB...
Trovato sfondo: /boot/grub/default-splash.png
Trovata immagine linux: /boot/kernel-genkernel-x86_64-5.4.0-sabayon
Trovata immagine initrd: /boot/initramfs-genkernel-x86_64-5.4.0-sabayon
fatto

Reboot to check if everything is working:

root # systemctl reboot

Check that the list of locales is as expected:

root # eselect locale list
Available targets for the LANG variable:
  [1]   C
  [2]   C.utf8
  [3]   en_GB
  [4]   en_GB.iso88591
  [5]   en_GB.utf8
  [6]   en_US
  [7]   en_US.iso88591
  [8]   en_US.utf8
  [9]   it_CH
  [10]  it_CH.iso88591
  [11]  it_CH.utf8
  [12]  POSIX
  [13]  it_CH.UTF-8 *
  [ ]   (free form)

Check if the current configuration is as expected:

root # localectl status
   System Locale: LANG=it_CH.UTF-8
       VC Keymap: sg
      X11 Layout: ch

If the Desktop Environment is KDE, check the file ~/.config/locale-plasmarc to see if the LANG variable is set to the locale just configured.

root # cat /home/fitzcarraldo/.config/plasma-localerc
[Formats]
LANG=en_GB.UTF-8

If it is not, delete the file:

root # rm /home/fitzcarraldo/.config/plasma-localerc

then logout, login again and re-check the file:

root # cat /home/fitzcarraldo/.config/plasma-localerc
[Formats]
LANG=it_CH.UTF-8

The system should now be ready for use with the new time zone, locale and keymaps.

user $ date
gio 2 lug 2020, 15:55:21, CEST
user $ localectl status
   System Locale: LANG=it_CH.UTF-8
       VC Keymap: sg
      X11 Layout: ch

Using a mixture of locale variables

It is not mandatory for all the locale variables to be for the same locale. For example, suppose I want to use the currency and number formats of one of the other locales I added. That is not so outlandish: I could be a Swiss national whose mother tongue is Swiss Italian, working in the Swiss branch of a British company and I want the currency format and number format on my work computer to be British, but everything else to be Swiss. To achieve this I can additionally do the following:

root # localectl set-locale LC_MONETARY=en_GB.UTF-8
root # localectl set-locale LC_NUMERIC=en_GB.UTF-8
root # env-update && source /etc/profile

Check that the main locale and keymaps remain as they were but that the two locale variables have been changed to the British locale:

root # localectl status
   System Locale: LANG=it_CH.UTF-8
                  LC_NUMERIC=en_GB.UTF-8
                  LC_MONETARY=en_GB.UTF-8
       VC Keymap: sg
      X11 Layout: ch
root # locale
LANG=it_CH.UTF-8
LC_CTYPE="it_CH.UTF-8"
LC_NUMERIC=en_GB.UTF-8
LC_TIME="it_CH.UTF-8"
LC_COLLATE="it_CH.UTF-8"
LC_MONETARY=en_GB.UTF-8
LC_MESSAGES="it_CH.UTF-8"
LC_PAPER="it_CH.UTF-8"
LC_NAME="it_CH.UTF-8"
LC_ADDRESS="it_CH.UTF-8"
LC_TELEPHONE="it_CH.UTF-8"
LC_MEASUREMENT="it_CH.UTF-8"
LC_IDENTIFICATION="it_CH.UTF-8"
LC_ALL=

You can see above that only $LC_NUMERIC and $LC_MONETARY have changed, as I wanted. As I did not change the time zone, the command I used earlier to set the time zone to Europe/Zurich is still in force:

root # date
gio 2 lug 2020, 16:12:18, CEST

By the way, if you try to change one of the variables from en_GB.UTF-8 back to it_CH.UTF-8, the change does not show in the output of the locale command. For example, let’s say you want to change LC_NUMERIC back to it_CH.UTF-8:

root # localectl status
   System Locale: LANG=it_CH.UTF-8
                  LC_NUMERIC=en_GB.UTF-8
                  LC_MONETARY=en_GB.UTF-8
       VC Keymap: sg
      X11 Layout: ch
root # localectl set-locale LC_NUMERIC=it_CH.UTF-8
root # cat /etc/locale.conf   
LANG=it_CH.UTF-8
LC_MONETARY=en_GB.UTF-8
root # cat /etc/env.d/02locale
LANG=it_CH.UTF-8
LC_MONETARY=en_GB.UTF-8
root # localectl status
   System Locale: LANG=it_CH.UTF-8
                  LC_MONETARY=en_GB.UTF-8
       VC Keymap: sg
      X11 Layout: ch
root # locale
LANG=it_CH.UTF-8
LC_CTYPE="it_CH.UTF-8"
LC_NUMERIC=en_GB.UTF-8  <-- Notice it didn't change
LC_TIME="it_CH.UTF-8"
LC_COLLATE="it_CH.UTF-8"
LC_MONETARY=en_GB.UTF-8
LC_MESSAGES="it_CH.UTF-8"
LC_PAPER="it_CH.UTF-8"
LC_NAME="it_CH.UTF-8"
LC_ADDRESS="it_CH.UTF-8"
LC_TELEPHONE="it_CH.UTF-8"
LC_MEASUREMENT="it_CH.UTF-8"
LC_IDENTIFICATION="it_CH.UTF-8"
LC_ALL=
root # env-update && source /etc/profile
>>> Regenerating /etc/ld.so.cache...
root # locale
LANG=it_CH.UTF-8
LC_CTYPE="it_CH.UTF-8"
LC_NUMERIC=en_GB.UTF-8 <-- Notice it still didn't change
LC_TIME="en_GB.UTF-8"
LC_COLLATE="it_CH.UTF-8"
LC_MONETARY=en_GB.UTF-8
LC_MESSAGES="it_CH.UTF-8"
LC_PAPER="it_CH.UTF-8"
LC_NAME="it_CH.UTF-8"
LC_ADDRESS="it_CH.UTF-8"
LC_TELEPHONE="it_CH.UTF-8"
LC_MEASUREMENT="it_CH.UTF-8"
LC_IDENTIFICATION="it_CH.UTF-8"
LC_ALL=

This is one of the reasons I’m not keen on the layer of abstraction added by systemd. The way to get LC_NUMERIC back to it_CH.UTF-8 is to change all the locale variables to en_GB.UTF-8 then back to it_CH.UTF-8:

root # localectl set-locale LANG=en_GB.UTF-8
root # env-update && source /etc/profile
root # localectl set-locale LANG=it_CH.UTF-8
root # env-update && source /etc/profile
root # reboot

After rebooting, the change will have been applied:

root # locale
LANG=it_CH.UTF-8
LC_CTYPE="it_CH.UTF-8"
LC_NUMERIC="it_CH.UTF-8"
LC_TIME="it_CH.UTF-8"
LC_COLLATE="it_CH.UTF-8"
LC_MONETARY="it_CH.UTF-8"
LC_MESSAGES="it_CH.UTF-8"
LC_PAPER="it_CH.UTF-8"
LC_NAME="it_CH.UTF-8"
LC_ADDRESS="it_CH.UTF-8"
LC_TELEPHONE="it_CH.UTF-8"
LC_MEASUREMENT="it_CH.UTF-8"
LC_IDENTIFICATION="it_CH.UTF-8"
LC_ALL=
root # localectl status
   System Locale: LANG=it_CH.UTF-8
       VC Keymap: sh
      X11 Layout: ch

Notice that everything has changed back to it_CH.UTF-8, including $LC_MONETARY, so you’d have to repeat the command ‘localectl set-locale LC_MONETARY=en_GB.UTF-8‘ if you wanted that to still be the British format.

If you use KDE, also check the contents of the file ~/.config/plasma-localerc to make sure it contains the correct locale:

user $ cat ~/.config/plasma-localerc
[Formats]
LANG=it_CH.UTF-8

Optionally you could edit that file to add desired settings. For example:

[Formats]
LANG=it_CH.UTF-8
LC_CTYPE=it_CH.UTF-8
LC_NUMERIC=en_GB.UTF-8
LC_TIME=it_CH.UTF-8
LC_COLLATE=it_CH.UTF-8
LC_MONETARY=en_GB.UTF-8
LC_MESSAGES=it_CH.UTF-8
LC_PAPER=it_CH.UTF-8
LC_NAME=it_CH.UTF-8
LC_ADDRESS=it_CH.UTF-8
LC_TELEPHONE=it_CH.UTF-8
LC_MEASUREMENT=it_CH.UTF-8
LC_IDENTIFICATION=it_CH.UTF-8
useDetailed=true

Alternatively, delete that file then logout and login again to make KDE Plasma pick up the values of the variables from the existing configuration. KDE Plasma will recreate the file.

Sharing a folder between a Linux host and Sabayon Linux as the guest OS in a VirtualBox VM

You probably know that you need to install the VirtualBox Guest Additions in the guest OS in order share a folder between a host OS and a guest OS in a VirtualBox VM. However, of late I have found that shared folders do not work when the guest OS is any of the Sabayon Linux spins, even though I had installed the Entropy package app-emulation/virtualbox-guest-additions and ensured the user in the guest OS is a member of the vboxsf group. Fortunately, it is not difficult to fix this, and below is the procedure I use to get a Sabayon Linux guest to share folders with a Linux host.

Let us say that your username in the host OS is ‘brian‘ and you have created a directory named /home/brian/Shared-brian/ that you want to share with the guest OS (Sabayon Linux), and the username in the guest OS is ‘fitzcarraldo‘.

1. In the VM VirtualBox Manager window, select ‘Settings’ > ‘Shared Folders’ for the VM. Click on ‘Machine Folders’ in the Folders List and then on the ‘Add New Shared Folder’ icon. Specify the folder path /home/brian/Shared-brian, and tick ‘Auto-mount’ and ‘Make Permanent’.

2. Start the VM, login as user fitzcarraldo and open a terminal window. If /boot is on a separate partition, make sure it is mounted.

3. Use the usual Entropy package manager commands to bring the guest OS installation up to date and to install the latest Sabayon Linux kernel image (see one of my earlier posts), then reboot the VM. If /boot is on a separate partition, make sure it is mounted.

4. If the VirtualBox Guest Additions package from the Sabayon Linux Entropy repository is currently installed in the guest OS, uninstall it. If the package has not yet been installed, install it and then uninstall it.

fitzcarraldo@sabayon ~ $ sudo equo remove virtualbox-guest-additions

5. Check if you are in the ‘vboxsf’ and ‘vboxguest’ groups:

fitzcarraldo@sabayon ~ $ groups

If you are not, add the user to the two groups:

fitzcarraldo@sabayon ~ $ sudo usermod -a -G vboxsf,vboxguest fitzcarraldo

6. Check if the latest GNU compiler collection and kernel sources have been installed. If not, install them:

fitzcarraldo@sabayon ~ $ sudo equo install sabayon-sources gcc

7. Check if the Linux kernel headers have been installed. If not, install that package too:

fitzcarraldo@sabayon ~ $ sudo install linux-headers

8. In the menu bar of the VM’s window, select ‘Devices’ > ‘Insert Guest Additions CD Image…’. If you are asked if you want to download the disk image file from the Internet, click on ‘Download’.

9. Use the guest OS’s File Manager to check that the Guest Additions virtual CD is mounted. If it is not, use the File Manager to mount it.

10. Install the VirtualBox Guest Additions from the virtual CD:

fitzcarraldo@sabayon ~ $ sudo /run/media/fitzcarraldo/VBOXADDITIONS_5.1.34_121010/VBoxLinuxAdditions.run

Ignore any warning message about the remnants of an existing version of the Guest Addtions still being installed. Answer ‘yes‘ to the prompt ‘Do you wish to continue [yes or no]‘. There should be no error messages in the terminal output if the GCC, kernel sources and linux kernel headers have already been installed (see the earlier steps above).

11. Reboot the VM and login.

12. In the directory /media/sf_Shared-brian/ in the guest OS you should now see the files that are in the shared folder /home/brian/Shared-brian/ in the host OS. VirtualBox automatically adds the ‘sf_‘ suffix to the directory name in the guest OS, and it stands for ‘shared folder’.

13. In file managers such as GNOME’s Nautilus, MATE’s Caja, LXDE/LXQt’s PCManFM and Xfce’s Thunar you should see the folder /media/sf_Shared-brian listed in the left panel. In KDE’s Dolphin you can right-click in the left panel and add an entry for /media/sf_Shared-brian or, optionally, right-click in the main window and select ‘Create New’ > ‘Basic link to file or directory…’ and create a link in your home directory to /media/sf_Shared-brian/.

I have used the above procedure with recent spins of Sabayon Linux (KDE, GNOME, MATE, Xfce and LXQt), and it works consistently.

Dealing with the kernel image and kernel source code in Sabayon Linux

Some Sabayon Linux users do not know the particulars of the Linux kernel installation or how to upgrade the kernel image. A recent post by a new user in the Sabayon Linux Forums illustrates this (translated from the German):

I’m just setting up my first sabayon box.

In the manual you should see which kernel is selected with:

eselect kernel list

But this is empty for me:

(not found)

When installing one or other packages I also already have a corresponding error message. What am I doing wrong?

The command ‘eselect kernel list‘ lists the versions of kernel source code currently installed (directories such as /usr/src/linux-4.8.17-sabayon/, /usr/src/linux-4.9.38-sabayon/ or whatever) and indicates to which kernel source code directory the symlink /usr/src/linux/ is currently pointing (see Kernel/Configuration – Set symlink in the Gentoo Linux Wiki).

My guess is that this user wanted to rebuild the kernel image. Anyway, the situation in Sabayon Linux he described occurs as a result of either not having installed the kernel source code or not having installed the version of kernel source code corresponding to the version of the installed kernel image.

Before I go into detail on how to do the above, it is essential to understand the basics of the Entropy package management system and how to maintain a sane installation in Sabayon Linux. You should regularly: a) update the local database containing a list of available packages and their versions; b) upgrade installed packages to their latest available version; c) check and fix dependencies and libraries; d) remove any old versions of installed packages:

root # equo update
root # equo upgrade
root # equo conf update
root # equo deptest
root # equo libtest
root # equo upgrade --purge
root # equo cleanup

Do not blindly enter the above commands if you do not know what they do; first read the explanations in the list of equo functions in the Sabayon Linux Wiki.

I have found that sometimes the command ‘equo upgrade --purge‘ does not report all the packages that have to be removed manually. I therefore repeat the command a few times until no more packages are listed for removal.

Right, now let’s look at why the aforementioned Sabayon Linux user was in trouble…

If you happen to have the directory /boot on a separate partition to / (root) and you specified in the file /etc/fstab that /boot should not be mounted automatically when the machine boots, do not forget to mount the boot partition first.

I would see the same message as the aforementioned Sabayon Linux user if the kernel image and source code were not set up correctly in my Sabayon Linux installation:

sabayon fitzcarraldo # eselect kernel list
Available kernel symlink targets:
  (none found)
sabayon fitzcarraldo #

Obviously a kernel image must be present, so first let’s check which version of the kernel image package is installed:

sabayon fitzcarraldo # equo search --installed linux-sabayon
╠  @@ Searching...
╠      @@ Package: sys-kernel/linux-sabayon-4.8.17 branch: 5, [__system__]
╠          Installed:     version: 4.8.17 ~ tag: NoTag ~ revision: 0
╠          Slot:          4.8
╠          Homepage:      https://github.com/Sabayon/kernel
╠          Description:   Official Sabayon Linux Standard
╠                         kernel image
╠          License:       GPL-2 freedist
╠   Keywords:  linux-sabayon
╠   Found:     1 entry
sabayon fitzcarraldo #

As you can see above, Version 4.8.17 of the kernel image package was installed in my case.

Note that the kernel source code is not installed by default in Sabayon Linux, so my guess is that the aforementioned user didn’t have the kernel source code installed. Here’s how to find out which version of the kernel source code package is installed, if any:

sabayon fitzcarraldo # equo search --installed sabayon-sources
╠  @@ Searching...
╠      @@ Package: sys-kernel/sabayon-sources-4.11.10 branch: 5, [__system__]
╠          Installed:     version: 4.11.10 ~ tag: NoTag ~ revision: 0
╠          Slot:          4.11
╠          Homepage:      https://github.com/Sabayon/kernel
╠          Description:   Official Sabayon Linux Standard
╠                         kernel sources
╠          License:       GPL-2 freedist
╠   Keywords:  sabayon-sources
╠   Found:     1 entry
sabayon fitzcarraldo #

As you can see above, in my case I had previously installed Version 4.11.10 of the kernel source code, and it didn’t correspond to the kernel image in use.

If you want to rebuild the kernel, you also need to have the linux kernel headers installed, and those are not installed by default in Sabayon Linux, so let’s check if that package is already installed while we’re at it:

sabayon fitzcarraldo # equo search --installed linux-headers
╠  @@ Searching...
╠      @@ Package: sys-kernel/linux-headers-4.4 branch: 5, [__system__]
╠          Installed:     version: 4.4 ~ tag: NoTag ~ revision: 0
╠          Slot:          0
╠          Homepage:      https://www.kernel.org/
╠                         https://www.gentoo.org/
╠          Description:   Linux system headers
╠          License:       GPL-2
╠   Keywords:  linux-headers
╠   Found:     1 entry
sabayon fitzcarraldo #

As you can see above, in my case I had previously installed Version 4.4 of the linux kernel headers. However, if you don’t already have the package installed, install it:

sabayon fitzcarraldo # equo install linux-headers
╠  @@ Calculating dependencies...
╠  ## [R] [sabayon-weekly] sys-kernel/linux-headers-4.4|0   [4.4|0]
╠  @@ Packages needing to be installed/updated/downgraded: 1
╠  @@ Packages needing to be removed: 0
╠  @@ Download size: 937.6kB
╠  @@ Freed disk space: 0.0b
╠  @@ You need at least: 1.9MB of free space
╠  ::: >>>  (1/1) 1 package
╠    ## Downloading: 1 package
╠    ## ( mirror #1 ) [sys-kernel:linux-headers-4.4.150ec398796671a9b475328e5ae3f180b9b096c3~0.tbz2] @ http://na.mirror.garr.it
╠   ## Aggregated download: 1 item
╠    # [1] na.mirror.garr.it => sys-kernel:linux-headers-4.4.150ec398796671a9b475328e5ae3f180b9b096c3~0.tbz2
╠    ## Checking package checksum...
╠       : [sys-kernel:linux-headers-4.4.150ec398796671a9b475328e5ae3f180b9b096c3~0.tbz2] GPG validated
╠       : SHA1 disabled
╠       : [sys-kernel:linux-headers-4.4.150ec398796671a9b475328e5ae3f180b9b096c3~0.tbz2] SHA256 validated
╠       : SHA512 disabled
╠    ## ( mirror #1 ) [sys-kernel:linux-headers-4.4.150ec398796671a9b475328e5ae3f180b9b096c3~0.tbz2] success @ http://na.mirror.garr.it
╠    ##  Aggregated transfer rate: 1.3MB/second
╠  +++ >>>  (1/1) sys-kernel/linux-headers-4.4
╠    ## Unpacking: sys-kernel:linux-headers-4.4.150ec398796671a9b475328e5ae3f180b9b096c3~0.tbz2
╠    ## Package phase: setup
╠    ## Package phase: preinstall
╠    ## Installing package: sys-kernel/linux-headers-4.4
╠    ## [Linux system headers]
╠    ## Updating installed packages repository: sys-kernel/linux-headers-4.4
╠    ## Cleaning previously installed application data.
╠    ## Package phase: postremove
╠    ## Package phase: postinstall
╠    ## Cleaning: sys-kernel/linux-headers-4.4
╠  @@ Installation complete.
╠  @@ No configuration files to update.
sabayon fitzcarraldo #

To make sure you have the latest versions of the packages sys-kernel/linux-sabayon (the kernel image) and sys-kernel/sabayon-sources (the kernel source code), install the packages as follows:

sabayon fitzcarraldo # equo install linux-sabayon sabayon-sources
╠  @@ Calculating dependencies...
╠  ## [N] [sabayon-weekly] sys-kernel/linux-sabayon-4.11.10|0
╠  ## [R] [sabayon-weekly] sys-kernel/sabayon-sources-4.11.10|0   [4.11.10|0]
╠  @@ Packages needing to be installed/updated/downgraded: 2
╠  @@ Packages needing to be removed: 0
╠  @@ Download size: 198.9MB
╠  @@ Used disk space: 211.3MB
╠  @@ You need at least: 609.1MB of free space
╠  ::: >>>  (1/1) 2 packages
╠    ## Downloading: 2 packages
╠    ## ( mirror #1 ) [sys-kernel:linux-sabayon-4.11.10.1f22c24cc709872f47d62d3c9e44af879fe18888~0.tbz2] @ http://na.mirror.garr.it
╠    ## ( mirror #1 ) [sys-kernel:sabayon-sources-4.11.10.bd94789f59b1e0b33118e122a23a0164c7205b8a~0.tbz2] @ http://na.mirror.garr.it
╠   ## Aggregated download: 2 items
╠    # [1] na.mirror.garr.it => sys-kernel:linux-sabayon-4.11.10.1f22c24cc709872f47d62d3c9e44af879fe18888~0.tbz2
╠    # [2] na.mirror.garr.it => sys-kernel:sabayon-sources-4.11.10.bd94789f59b1e0b33118e122a23a0164c7205b8a~0.tbz2
╠    ## Checking package checksum...
╠       : [sys-kernel:linux-sabayon-4.11.10.1f22c24cc709872f47d62d3c9e44af879fe18888~0.tbz2] GPG validated
╠       : SHA1 disabled
╠       : [sys-kernel:linux-sabayon-4.11.10.1f22c24cc709872f47d62d3c9e44af879fe18888~0.tbz2] SHA256 validated
╠       : SHA512 disabled
╠    ## Checking package checksum...
╠       : [sys-kernel:sabayon-sources-4.11.10.bd94789f59b1e0b33118e122a23a0164c7205b8a~0.tbz2] GPG validated
╠       : SHA1 disabled
╠       : [sys-kernel:sabayon-sources-4.11.10.bd94789f59b1e0b33118e122a23a0164c7205b8a~0.tbz2] SHA256 validated
╠       : SHA512 disabled
╠    ## ( mirror #1 ) [sys-kernel:linux-sabayon-4.11.10.1f22c24cc709872f47d62d3c9e44af879fe18888~0.tbz2] success @ http://na.mirror.garr.it
╠    ## ( mirror #1 ) [sys-kernel:sabayon-sources-4.11.10.bd94789f59b1e0b33118e122a23a0164c7205b8a~0.tbz2] success @ http://na.mirror.garr.it
╠    ##  Aggregated transfer rate: 3.7MB/second
╠  +++ >>>  (1/2) sys-kernel/linux-sabayon-4.11.10
╠    ## Unpacking: sys-kernel:linux-sabayon-4.11.10.1f22c24cc709872f47d62d3c9e44af879fe18888~0.tbz2
╠    ## Package phase: setup
 * To avoid automounting and auto(un)installing with /boot,
 * just export the DONT_MOUNT_BOOT variable.

 * Your boot partition was detected as being mounted at /boot.
 * Files will be installed there for linux-sabayon to function correctly.
 * Preparing kernel and its modules
╠    ## Package phase: preinstall

 * Your boot partition was detected as being mounted at /boot.
 * Files will be installed there for linux-sabayon to function correctly.
╠    ## Installing package: sys-kernel/linux-sabayon-4.11.10
╠    ## [Official Sabayon Linux Standard kernel image]
╠    ## Updating installed packages repository: sys-kernel/linux-sabayon-4.11.10
╠    ## Package phase: postinstall
 * Removing extents option for ext4 drives from /etc/fstab
Generating grub configuration file ...
Found background: /boot/grub/default-splash.png
Found linux image: /boot/kernel-genkernel-x86_64-4.11.0-sabayon
Found initrd image: /boot/initramfs-genkernel-x86_64-4.11.0-sabayon
Found linux image: /boot/kernel-genkernel-x86_64-4.8.0-sabayon
Found initrd image: /boot/initramfs-genkernel-x86_64-4.8.0-sabayon
done

 * You are currently booting with kernel:
 * kernel-genkernel-x86_64-4.8.0-sabayon
 *
 * Use 'eselect bzimage' in order to switch between the available ones


 * If you are upgrading from a previous kernel, you may be interested
 * in the following document:
 *   - General upgrade guide: https://wiki.gentoo.org/wiki/Kernel/Upgrade

 * Updating module dependencies for 4.11.0-sabayon ...
depmod: WARNING: Ignored deprecated option -r                                                                                                                                                                                               [ ok ]
 * Please report kernel bugs at:
 * http://bugs.sabayon.org
 * The source code of this kernel is located at
 * =sys-kernel/sabayon-sources-4.11.10.
 * Sabayon Linux recommends that portage users install
 * sys-kernel/sabayon-sources-4.11.10 if you want
 * to build any packages that install kernel modules
 * (such as ati-drivers, nvidia-drivers, virtualbox, etc...).
╠    ## Cleaning: sys-kernel/linux-sabayon-4.11.10
╠  +++ >>>  (2/2) sys-kernel/sabayon-sources-4.11.10
╠    ## Unpacking: sys-kernel:sabayon-sources-4.11.10.bd94789f59b1e0b33118e122a23a0164c7205b8a~0.tbz2
╠    ## Package phase: setup
 * To avoid automounting and auto(un)installing with /boot,
 * just export the DONT_MOUNT_BOOT variable.

 * Your boot partition was detected as being mounted at /boot.
 * Files will be installed there for sabayon-sources to function correctly.
 * Preparing kernel and its modules
╠    ## Package phase: preinstall
╠    ## Installing package: sys-kernel/sabayon-sources-4.11.10
╠    ## [Official Sabayon Linux Standard kernel sources]
╠    ## Updating installed packages repository: sys-kernel/sabayon-sources-4.11.10
╠    ## Package phase: preremove
╠    ## Cleaning previously installed application data.
╠    ## Package phase: postremove
╠    ## Package phase: postinstall

 * If you are upgrading from a previous kernel, you may be interested
 * in the following document:
 *   - General upgrade guide: https://wiki.gentoo.org/wiki/Kernel/Upgrade

╠    ## Cleaning: sys-kernel/sabayon-sources-4.11.10
╠  @@ Installation complete.
╠  @@ No configuration files to update.
sabayon fitzcarraldo #

Now upgrade the OS installation to the latest kernel image and reboot the machine so that the new kernel image is loaded:

sabayon fitzcarraldo # kernel-switcher switch linux-sabayon-4.11.10
sabayon fitzcarraldo # reboot

Check that the new kernel version is running:

sabayon fitzcarraldo # uname -a
Linux sabayon.local 4.11.0-sabayon #1 SMP Sat Jul 15 09:33:23 UTC 2017 x86_64 Intel(R) Pentium(R) CPU G2030 @ 3.00GHz GenuineIntel GNU/Linux
sabayon fitzcarraldo #

The minor in the version number reported by the uname command does not necessarily correspond to the minor in the version number of the kernel image package. This is not an error: see Misunderstandings about the kernel in the Sabayon Wiki regarding this apparent discrepancy.

The symlink to the kernel source code will now exist:

sabayon fitzcarraldo # eselect kernel list
Available kernel symlink targets:
  [1]   linux-4.11.0-sabayon *
sabayon fitzcarraldo #

If everything works correctly, you can uninstall the earlier version(s) of the kernel image package:

sabayon fitzcarraldo # equo search --installed linux-sabayon
sabayon fitzcarraldo # equo remove linux-sabayon-4.8.17

In my case an earlier version of the kernel source code package was not installed, but if one had been then I would have uninstalled that package too:

sabayon fitzcarraldo # equo search --installed sabayon-sources
sabayon fitzcarraldo # equo remove sabayon-sources-4.8.17

You can also remove old kernel image files manually from the /boot directory if they were not removed automatically:

sabayon fitzcarraldo # ls /boot
sabayon fitzcarraldo # rm -i /boot/*genkernel-x86_64-4.8.0-sabayon

Regenerate the file grub.cfg so that the GRUB 2 menu at boot only lists the kernel images actually present in the /boot directory:

sabayon fitzcarraldo # grub-mkconfig -o /boot/grub/grub.cfg

If you’re running Sabayon Linux inside a VirtualBox virtual machine, you’ll also need to install in the guest installation the correct version of the VirtualBox Guest Additions for the new version of the kernel you just installed in the guest installation. Uninstall the old version if it has not already been uninstalled automatically, then search for the version that corresponds to the kernel you installed in the guest installation:

sabayon fitzcarraldo # equo remove virtualbox-guest-additions
sabayon fitzcarraldo # equo search virtualbox-guest-additions
sabayon fitzcarraldo # equo install virtualbox-guest-additions-5.1.22#4.11.0-sabayon

A method of ‘masking’ an OpenRC service (NetworkManager, in this case)

A Gentoo Linux user with an installation using OpenRC recently asked in the Gentoo Forums how to either a) disable NetworkManager so that it would not interfere with his netifrc configuration to give his installation a static IP address, or b) configure NetworkManager to use a static IP address (see the thread NetworkManager and static IP [SOLVED! THANKYOU]). In the end he solved the problem by uninstalling NetworkManager, the cleanest solution in his case given that his desktop machine is always in the same location and he does not need the features NetworkManager provides.

Now, although I use NetworkManager instead of netifrc, what intrigued me is that disabling the NetworkManager service using the standard command below does not stop the NetworkManager init script from running at boot-up:

root # rc-update delete NetworkManager default

Despite using the above command, following a reboot the NetworkManager service is still started and becomes active, and the NetworkManager daemon is running. Web browsers and other applications requiring network access still work. In order to stop the service running immediately so that his netifrc static IP address configuration could work, the aforementioned Gentoo user had to stop the NetworkManager service as follows:

root # /etc/init.d/NetworkManager stop

(The command ‘rc-service NetworkManager stop‘ does the same thing.)

The behaviour is the same on my laptop running Gentoo with OpenRC 0.22.4 and NetworkManager installed by networkmanager-1.4.0-r1 ebuild (with the upstream patch and necessary edit to the init script mentioned in Gentoo Bug Report No. 595806 – net-misc/networkmanager-1.4.0-r1[consolekit]: doesn’t automatically activate connections marked with "Automatically connect to this network when it’s available").

So two questions arose: What launches the NetworkManager init script when it has not been added to a runlevel? What needs to be done to stop this from happening? My curiosity was piqued.

As it happens, a somewhat similar situation exists when using systemd rather than OpenRC, as explained in Arch Linux Forums thread [SOLVED] NetworkManager auto restart even though I stop it. and Red Hat Bugzilla Report No. 815243 – Even though NetworkManager was manually stopped, it gets restarted automatically via D-Bus, although those were primarily concerned with how to prevent NetworkManager being restarted during the same session, i.e. without having rebooted.

The following systemd commands are needed to stop immediately the NetworkManager service and keep it from being restarted subsequently during the current session and after rebooting:

root # systemctl mask NetworkManager
root # systemctl stop NetworkManager
root # systemctl disable NetworkManager

Unfortunately there is no equivalent mask command for an OpenRC service. The equivalent OpenRC commands for the second and third commands above are:

root # rc-service NetworkManager stop
root # rc-update delete NetworkManager default

However, as I pointed out earlier, for some reason the latter command does not stop OpenRC running the NetworkManager init script at boot.

I wondered how I could ‘mask’ the NetworkManager service in OpenRC. I asked myself what the systemd mask command actually does. Well, it simply creates a symlink from /etc/systemd/system/NetworkManager.service to /dev/null so that there is no longer a real unit file for systemd to use, and therefore systemd can no longer launch the service. So why not do something similar in OpenRC. I hit upon the idea of telling the NetworkManager init script it needs a non-existent service in order to start, thus preventing OpenRC from starting the NetworkManager service:

root # echo 'rc_need="non-existent_service"' >> /etc/conf.d/NetworkManager # (Or just edit the file manually.)

That is all there is to it. When booting, OpenRC now displays the messages shown below:

* ERROR: NetworkManager needs service(s) non-existent_service
* ERROR: cannot start netmount as NetworkManager would not start
* ERROR: cannot start samba as NetworkManager would not start

As shown below, now the service is not started, so the NetworkManager daemon is never launched:

root # rc-status
Runlevel: default
 dbus                                                  [  started  ]
 syslog-ng                                             [  started  ]
 consolekit                                            [  started  ]
 netmount                                              [  stopped  ]
 cupsd                                                 [  started  ]
 samba                                                 [  stopped  ]
 cronie                                                [  started  ]
 clamd                                                 [  started  ]
 bluetooth                                             [  started  ]
 xdm                                                   [  started  ]
 cups-browsed                                          [  started  ]
 sshd                                                  [  started  ]
 local                                                 [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed/wanted
 modules-load                                          [  started  ]
 xdm-setup                                             [  started  ]
 avahi-daemon                                          [  started  ]
Dynamic Runlevel: manual
root # ps -ef | grep -v grep | grep -i network
root #

As expected, given that the netmount service and samba service depend on the NetworkManager service starting, neither of those services were able to start either.

Furthermore, because I masked the service, if I attempt to start it manually:

root # rc-service NetworkManager restart
 * ERROR: NetworkManager needs service(s) non-existent_service

To unmask the service in OpenRC, all that is needed is:

root # sed -i '/rc_need="non-existent_service"/d' /etc/conf.d/NetworkManager # (Or just edit the file manually.)

Note that, instead of “non-existent_service” I could have written “fubar”, “null” or any other string that is not the name of an actual service. But “non-existent_service” is more meaningful and less likely to confuse me when viewing system messages and contents of the service configuration file.

In summary…

Why does OpenRC run the NetworkManager service init script when it is not in any runlevel?

I have no idea!

I wondered if the D-Bus service does it. The Arch Wiki article on NetworkManager claims this is the case (see the section titled Disable NetworkManager). However, my attempts at preventing D-Bus doing anything to NetworkManager did not stop the NetworkManager init script from being run at boot. I deleted /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf and /etc/dbus-1/system.d/nm-dispatcher.conf but that did not help. Neither did creating an appropriate /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf or /etc/dbus-1/system-local.conf. There is no /usr/share/dbus-1/system-services/org.freedesktop.NetworkManager.service file in my Gentoo installation using OpenRC, but creating one did not help either. So, if you know what runs the OpenRC NetworkManager init script when it is not in any runlevel, please post a comment.

Anyway, I now know how to prevent it happening, so I have satisfied my curiosity. Below I list the commands I actually used in a Gentoo Linux installation (amd64, OpenRC) and a Sabayon Linux installation (~amd64, systemd) to check the functionality.

OpenRC

The following two (optionally three) commands are needed to stop immediately the NetworkManager service and prevent it being restarted subsequently during this session and after rebooting:

root # rc-service NetworkManager stop
root # echo 'rc_need="non-existent_service"' >> /etc/conf.d/NetworkManager
root # rc-update del NetworkManager default # (Optional.)

The following two (optionally three) commands are needed to unmask the NetworkManager service and start it immediately, and make it start automatically after rebooting:

root # sed -i '/rc_need="non-existent_service"/d' /etc/conf.d/NetworkManager
root # rc-service NetworkManager restart
root # rc-update add NetworkManager default # Only needed if I earlier deleted the service from the default runlevel.

systemd

The following three commands are needed to stop immediately the NetworkManager service and prevent it being restarted subsequently during this session and after rebooting:

root # systemctl mask NetworkManager
root # systemctl stop NetworkManager
root # systemctl disable NetworkManager

The following three systemd commands are needed to unmask the NetworkManager service and start it immediately, and also make it start automatically after rebooting:

root # systemctl unmask NetworkManager
root # systemctl enable NetworkManager
root # systemctl start NetworkManager

Change the mp3 bitrate for ripping in K3b

I’ve been using K3b successfully (it’s currently at version 2.0.3-r1 in Gentoo Linux) to rip Audio CDs to mp3 files, but despite changing the bitrate to 192 kbps in the ‘K3b Lame Mp3 Encoder’ plugin settings, K3b was still ripping mp3 files at 128 kbps. I found out that I needed to make another change too.

The default bitrate for ripped mp3 tracks is 128 kbps in K3b. To use a different bitrate, I needed to do the following:

1. ‘Settings’ > ‘Configure K3b…’

2. Click on ‘Plugins’

3. Click on the spanner next to ‘K3b Lame Mp3 Encoder’, and change the bitrate on the Settings tab to 192 (or whatever you want). However, this alone does not have any effect, so also click on the spanner next to ‘K3b External Audio Encoder’, click on ‘Mp3 (Lame)’ in the list of ‘Configured Encoders’, click on ‘Edit’ and insert ‘-b 192‘ (or whatever bitrate you want) in the list of lame options, like so:

lame -r --bitwidth 16 --little-endian -b 192 -s 44.1 -h --tt %t --ta %a --tl %m --ty %y --tc %c --tn %n - %f

Here’s what happens before I added the ‘-b 192‘ to the settings for ‘Mp3 (Lame)’ in ‘K3b External Audio Encoder’:

$ file 01\ -\ Meu\ Bem\ Querer.mp3
01 - Meu Bem Querer.mp3: Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, JntStereo

And after adding the ‘-b 192‘ to the settings for ‘Mp3 (Lame)’ in ‘K3b External Audio Encoder’:

$ file 01\ -\ Meu\ Bem\ Querer.mp3
01 - Meu Bem Querer.mp3: Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer III, v1, 192 kbps, 44.1 kHz, JntStereo

Notice the bit rate of the file has changed.

NetworkManager creating a new connection ‘eth0’ that does not work, Part 4

Further to my previous post, this is to report the result of another experiment. By doing all the following I can stop NetworkManager creating an invalid second eth0 connection:

  • Enable IPv6 system-wide in /etc/modprobe.d/aliases.conf by commenting-out ‘alias net-pf-10 off‘.
  • Disable use of IPv6 by the Avahi daemon in /etc/avahi/avahi-daemon.conf (see the four additional lines given in my previous post).
  • Use plasma-nm to edit the connection profile for ‘eth0’ that I had already created. Click on the IPv6 tab and ensure ‘Method: Ignored‘ is selected. Click on the IPv4 tab and ensure ‘Method: Automatic‘ is selected and ‘IPv4 is required for this connection‘ is ticked. Ticking ‘IPv4 is required for this connection‘ adds the line ‘may-fail=false‘ in the [ipv4] section in the file /etc/NetworkManager/system-connections/eth0 (the default value for may-fail is ‘true‘ if the box has not been ticked and may-fail has not been assigned in the file).

The various experiments I have conducted are summarised in the following table:

Laptop WiFi switch off off off off off on
IPv6 enabled in aliases.conf yes no yes yes yes yes
IPv6 enabled in avahi-daemon.conf yes yes no no yes yes
[ipv6] method= ignore ignore ignore ignore ignore ignore
[ipv4] method= auto auto auto auto auto auto
[ipv4] may-fail= true true true false false false
Invalid second eth0 created usually no usually no yes yes

As disabling IPv6 system-wide makes it impossible for NetworkManager to use IPv6, the above table can actually be written as follows:

Laptop WiFi switch off off off off off on
IPv6 enabled in aliases.conf yes no yes yes yes yes
IPv6 enabled in avahi-daemon.conf yes yes||no no no yes yes
[ipv6] method= ignore ignore ignore ignore ignore ignore
[ipv4] method= auto auto auto auto auto auto
[ipv4] may-fail= true true||false true false false false
Invalid second eth0 created usually no usually no yes yes

I still think there is a bug in NetworkManager. I would not have expected NetworkManager to create a second eth0 connection and make it an IPv6 Link-Local connection when all the following are true:

  • /etc/NetworkManager.conf has ‘no-auto-default=eth0‘ in the [main] section.
  • IPv4 is required for this connection‘ is not ticked in plasma-nm (i.e. the [ipv4] section in /etc/NetworkManager/system-connections/eth0 contains either the line ‘may-fail=true‘ or the line ‘may-fail=‘).
  • Method: Automatic‘ is selected for IPv4 (‘method=auto‘ under [ipv4] in /etc/NetworkManager/system-connections/eth0).
  • Method: Ignored‘ is selected for IPv6 (‘method=ignore‘ under [ipv6] in /etc/NetworkManager/system-connections/eth0) and the other fields on the IPv6 tab have been rendered unselectable as a result.

Anyway, I will keep IPv6 disabled in /etc/avahi/avahi-daemon.conf and IPv6 enabled system-wide. This seems to be the first thing to try if you’re experiencing the creation of an invalid additional eth0 connection with an IPv6 Link-Local address and you’re sure that none of the net.* services are running.

NetworkManager creating a new connection ‘eth0′ that does not work, Part 3

I’m even more convinced the problem discussed in my previous post is due to a bug in NetworkManager. I believe the issue with the Avahi daemon generating an IPv6 Link-Local address is a consequence of NetworkManager not always activating an interface and therefore not obtaining an IPv4 address, i.e. the IPv6 Link-Local address produced by the Avahi daemon is a side effect, not the root cause.

After my previous post I discovered that adding ‘use-ipv6=no‘ in /etc/avahi/avahi-daemon.conf (my Experiment 2) had not prevented avahi-daemon using IPv6. However, adding the following lines in /etc/avahi/avahi-daemon.conf defintely does prevent avahi-daemon from using IPv6 in my installation:

use-ipv4=yes
use-ipv6=no
publish-a-on-ipv6=no
publish-aaaa-on-ipv4=no

You can see in the message log below that the Avahi daemon is no longer generating an IPv6 Link-Local address. However, even with IPv6 disabled in avahi-daemon, an invalid second eth0 connection with an IPv6 Link-Local address still occurs in my installation. This indicates the problem is not caused by the Avahi daemon.

Mar 18 22:17:31 localhost syslog-ng[8316]: syslog-ng starting up; version='3.6.2'
Mar 18 22:17:32 localhost NetworkManager[8346]: <info>  NetworkManager (version 1.0.0) is starting...
Mar 18 22:17:32 localhost NetworkManager[8346]: <info>  Read config: /etc/NetworkManager/NetworkManager.conf
Mar 18 22:17:32 localhost NetworkManager[8346]: <info>  WEXT support is enabled
Mar 18 22:17:34 localhost kernel: fglrx_pci 0000:01:00.0: irq 34 for MSI/MSI-X
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Firegl kernel thread PID: 8351
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Firegl kernel thread PID: 8352
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Firegl kernel thread PID: 8353
Mar 18 22:17:34 localhost kernel: <6>[fglrx] IRQ 34 Enabled
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Shared offset:0, size:1000000 
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Unshared offset:f7e2000, size:4000 
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Unshared offset:f7e6000, size:51a000 
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Unshared offset:3fff3000, size:d000 
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded plugin keyfile: (c) 2007 - 2013 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection /etc/NetworkManager/system-connections/Cisco00497
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection /etc/NetworkManager/system-connections/eth0
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection /etc/NetworkManager/system-connections/DIRECT-HeC460 Series
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  monitoring kernel firmware directory '/lib/firmware'.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  rfkill0: found WiFi radio killswitch (at /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/phy0/rfkill0) (driver iwlwifi)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WiFi hardware radio set enabled
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WWAN hardware radio set enabled
Mar 18 22:17:33 localhost /etc/init.d/NetworkManager[8326]: WARNING: NetworkManager has started, but is inactive
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-bluetooth.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-adsl.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-wwan.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-wifi.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WiFi disabled by radio killswitch; enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WWAN enabled by radio killswitch; enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WiMAX enabled by radio killswitch; enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Networking is enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): link connected
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): carrier is ON
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): new Generic device (driver: 'unknown' ifindex: 1)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): exported as /org/freedesktop/NetworkManager/Devices/0
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): link connected
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): carrier is ON
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): new Ethernet device (driver: 'atl1c' ifindex: 2)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): exported as /org/freedesktop/NetworkManager/Devices/1
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  startup complete
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: starting connection 'eth0'
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 1 of 5 (Device Prepare) scheduled...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): using nl80211 for WiFi device control
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): new 802.11 WiFi device (driver: 'iwlwifi' ifindex: 3)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): exported as /org/freedesktop/NetworkManager/Devices/2
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): preparing device
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 1 of 5 (Device Prepare) started...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) scheduled...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 1 of 5 (Device Prepare) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) starting...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: prepare -> config (reason 'none') [40 50 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) successful.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 3 of 5 (IP Configure Start) scheduled.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 3 of 5 (IP Configure Start) started...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: config -> ip-config (reason 'none') [50 70 0]
Mar 18 22:17:33 localhost dbus[7763]: [system] Activating service name='org.freedesktop.ModemManager1' (using servicehelper)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 5 of 5 (IPv6 Commit) scheduled...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 3 of 5 (IP Configure Start) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 5 of 5 (IPv6 Commit) started...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 5 of 5 (IPv6 Commit) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: secondaries -> activated (reason 'none') [90 100 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  NetworkManager state is now CONNECTED_LOCAL
Mar 18 22:17:33 localhost acpid[8386]: starting up with netlink and the input layer
Mar 18 22:17:33 localhost acpid[8386]: 6 rules loaded
Mar 18 22:17:33 localhost acpid[8386]: waiting for events: event logging is off
Mar 18 22:17:34 localhost ModemManager[8385]: <info>  ModemManager (version 1.4.2) starting in system bus...
Mar 18 22:17:34 localhost NetworkManager[8346]: <info>  (eth0): Activation: successful, device activated.
Mar 18 22:17:34 localhost dbus[7763]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Mar 18 22:17:34 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Mar 18 22:17:34 localhost nm-dispatcher[8435]: Dispatching action 'up' for eth0
Mar 18 22:17:34 localhost rpc.statd[8451]: Version 1.3.2 starting
Mar 18 22:17:34 localhost rpc.statd[8451]: Flags: TI-RPC 
Mar 18 22:17:34 localhost /etc/init.d/NetworkManager[8457]: status: inactive
Mar 18 22:17:34 localhost rpc.statd[8451]: Running as root.  chown /var/lib/nfs to choose different user
Mar 18 22:17:34 localhost /etc/init.d/NetworkManager[8469]: status: inactive
Mar 18 22:17:34 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.ModemManager1'
Mar 18 22:17:34 localhost NetworkManager[8346]: <info>  ModemManager disappeared from bus
Mar 18 22:17:34 localhost NetworkManager[8346]: <info>  ModemManager available in the bus
Mar 18 22:17:35 localhost sm-notify[8556]: Version 1.3.2 starting
Mar 18 22:17:35 localhost avahi-daemon[8585]: Found user 'avahi' (UID 108) and group 'avahi' (GID 444).
Mar 18 22:17:35 localhost avahi-daemon[8585]: Successfully dropped root privileges.
Mar 18 22:17:35 localhost avahi-daemon[8585]: avahi-daemon 0.6.31 starting up.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Successfully called chroot().
Mar 18 22:17:35 localhost avahi-daemon[8585]: Successfully dropped remaining capabilities.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Loading service file /services/sftp-ssh.service.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Loading service file /services/ssh.service.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Network interface enumeration completed.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Registering HINFO record with values 'X86_64'/'LINUX'.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Server startup complete. Host name is meshedgedx.local. Local service cookie is 3778762828.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Service "meshedgedx" (/services/ssh.service) successfully established.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Service "meshedgedx" (/services/sftp-ssh.service) successfully established.
Mar 18 22:17:35 localhost ntpd[8645]: ntpd 4.2.8@1.3265-o Wed  4 Mar 02:23:30 UTC 2015 (1): Starting
Mar 18 22:17:35 localhost ntpd[8645]: Command line: ntpd -g -q
Mar 18 22:17:35 localhost ntpd[8645]: proto: precision = 0.061 usec (-24)
Mar 18 22:17:35 localhost ntpd[8645]: Listen and drop on 0 v6wildcard [::]:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen normally on 2 lo 127.0.0.1:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen normally on 3 lo [::1]:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen normally on 4 eth0 [fe80::725a:b6ff:fe3e:c18a%2]:123
Mar 18 22:17:35 localhost ntpd[8645]: Listening on routing socket on fd #21 for interface updates
Mar 18 22:17:36 localhost kernel: fbcondecor: console 1 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 1
Mar 18 22:17:37 localhost kernel: fbcondecor: console 2 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 2
Mar 18 22:17:37 localhost kernel: fbcondecor: console 3 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 3
Mar 18 22:17:37 localhost kernel: fbcondecor: console 4 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 4
Mar 18 22:17:37 localhost kernel: fbcondecor: console 5 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 5
Mar 18 22:17:36 localhost bluetoothd[8787]: Bluetooth daemon 5.28
Mar 18 22:17:36 localhost bluetoothd[8787]: Starting SDP server
Mar 18 22:17:37 localhost kernel: Bluetooth: Core ver 2.19
Mar 18 22:17:37 localhost kernel: NET: Registered protocol family 31
Mar 18 22:17:37 localhost kernel: Bluetooth: HCI device and connection manager initialized
Mar 18 22:17:37 localhost kernel: Bluetooth: HCI socket layer initialized
Mar 18 22:17:37 localhost kernel: Bluetooth: L2CAP socket layer initialized
Mar 18 22:17:37 localhost kernel: Bluetooth: SCO socket layer initialized
Mar 18 22:17:38 localhost kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Mar 18 22:17:38 localhost kernel: Bluetooth: BNEP filters: protocol multicast
Mar 18 22:17:38 localhost kernel: Bluetooth: BNEP socket layer initialized
Mar 18 22:17:36 localhost bluetoothd[8787]: Bluetooth management interface 1.7 initialized
Mar 18 22:17:36 localhost NetworkManager[8346]: <info>  use BlueZ version 5
Mar 18 22:17:37 localhost ModemManager[8385]: <warn>  Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0': not supported by any plugin
Mar 18 22:17:37 localhost ModemManager[8385]: <warn>  Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0': not supported by any plugin
Mar 18 22:17:39 localhost dbus[7763]: [system] Activating service name='org.freedesktop.ColorManager' (using servicehelper)
Mar 18 22:17:39 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.ColorManager'
Mar 18 22:17:41 localhost kernel: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
Mar 18 22:17:43 localhost kernel: [UFW BLOCK] IN=eth0 OUT= MAC= SRC=fe80:0000:0000:0000:725a:b6ff:fe3e:c18a DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=8612 DPT=8612 LEN=24 
Mar 18 22:17:43 localhost kernel: [UFW BLOCK] IN=eth0 OUT= MAC= SRC=fe80:0000:0000:0000:725a:b6ff:fe3e:c18a DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=8612 DPT=8612 LEN=24 
Mar 18 22:17:43 localhost laptop-mode[8947]: Laptop mode 
Mar 18 22:17:43 localhost laptop-mode[8948]: enabled, not active
Mar 18 22:17:58 localhost kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Mar 18 22:17:58 localhost rpc.mountd[9741]: Version 1.3.2 starting
Mar 18 22:17:59 localhost kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
Mar 18 22:17:59 localhost kernel: NFSD: starting 90-second grace period (net ffffffff81c3d580)
Mar 18 22:17:58 localhost sm-notify[9760]: Version 1.3.2 starting
Mar 18 22:17:58 localhost sm-notify[9760]: Already notifying clients; Exiting!
Mar 18 22:18:00 localhost sshd[9816]: Server listening on 0.0.0.0 port 22.
Mar 18 22:18:00 localhost sshd[9816]: Server listening on :: port 22.
Mar 18 22:18:00 localhost cron[9870]: (CRON) STARTUP (V5.0)
Mar 18 22:18:00 localhost su[9899]: Successful su for fitzcarraldo by root
Mar 18 22:18:00 localhost su[9899]: + /dev/console root:fitzcarraldo
Mar 18 22:18:00 localhost su[9899]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:01 localhost dbus[7763]: [system] Activating service name='org.freedesktop.RealtimeKit1' (using servicehelper)
Mar 18 22:18:01 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.RealtimeKit1'
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Successfully called chroot.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Successfully dropped privileges.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Successfully limited resources.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Running.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Watchdog thread running.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Canary thread running.
Mar 18 22:18:01 localhost kdm[8833]: :0[8833]: pam_unix(kde:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:01 localhost kdm[8833]: :0[8833]: pam_ck_connector(kde:session): nox11 mode, ignoring PAM_TTY :0
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] sink.c: Default and alternate sample rates are the same.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] source.c: Default and alternate sample rates are the same.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] module-jackdbus-detect.c: Unable to contact D-Bus session bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] module.c: Failed to load module "module-jackdbus-detect" (argument: "channels=2"): initialization failed.
Mar 18 22:18:04 localhost pulseaudio[9904]: [pulseaudio] main.c: Module load failed.
Mar 18 22:18:04 localhost pulseaudio[9904]: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 18 22:18:04 localhost pulseaudio[9904]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 18 22:18:04 localhost su[9899]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:04 localhost su[9964]: Successful su for fitzcarraldo by root
Mar 18 22:18:04 localhost su[9964]: + /dev/console root:fitzcarraldo
Mar 18 22:18:04 localhost su[9964]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:04 localhost su[9964]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:04 localhost su[9966]: Successful su for fitzcarraldo by root
Mar 18 22:18:04 localhost su[9966]: + /dev/console root:fitzcarraldo
Mar 18 22:18:04 localhost su[9966]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:04 localhost su[9966]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:04 localhost su[9968]: Successful su for fitzcarraldo by root
Mar 18 22:18:04 localhost su[9968]: + /dev/console root:fitzcarraldo
Mar 18 22:18:04 localhost su[9968]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:04 localhost su[9968]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:15 localhost dbus[7763]: [system] Activating service name='org.freedesktop.UPower' (using servicehelper)
Mar 18 22:18:15 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.UPower'
Mar 18 22:18:17 localhost dbus[7763]: [system] Activating service name='org.freedesktop.UDisks2' (using servicehelper)
Mar 18 22:18:17 localhost udisksd[10120]: udisks daemon version 2.1.4 starting
Mar 18 22:18:17 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.UDisks2'
Mar 18 22:18:17 localhost udisksd[10120]: Acquired the name org.freedesktop.UDisks2 on the system message bus
Mar 18 22:18:19 localhost kernel: [UFW BLOCK] IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:16:fa:25:28:01:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=0 PROTO=2 
Mar 18 22:18:54 localhost hp-systray[10453]: hp-systray[10453]: error: option -s not recognized
Mar 18 22:18:55 localhost rtkit-daemon[9906]: Successfully made thread 10469 of process 10469 (/usr/bin/pulseaudio) owned by '1000' high priority at nice level -11.
Mar 18 22:18:55 localhost rtkit-daemon[9906]: Supervising 1 threads of 1 processes of 1 users.
Mar 18 22:18:55 localhost pulseaudio[10469]: [pulseaudio] pid.c: Daemon already running.
Mar 18 22:18:56 localhost rtkit-daemon[9906]: Successfully made thread 10485 of process 10485 (/usr/bin/pulseaudio) owned by '1000' high priority at nice level -11.
Mar 18 22:18:56 localhost rtkit-daemon[9906]: Supervising 1 threads of 1 processes of 1 users.
Mar 18 22:18:56 localhost pulseaudio[10485]: [pulseaudio] pid.c: Daemon already running.
Mar 18 22:19:04 localhost polkitd[7911]: Registered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.52 [/usr/lib64/kde4/libexec/polkit-kde-authentication-agent-1], object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8)
Mar 18 22:19:10 localhost su[10569]: Successful su for root by fitzcarraldo
Mar 18 22:19:10 localhost su[10569]: + /dev/pts/0 fitzcarraldo:root
Mar 18 22:19:10 localhost su[10569]: pam_unix(su:session): session opened for user root by fitzcarraldo(uid=1000)
Mar 18 22:19:26 localhost pulseaudio[9904]: [alsa-sink-ALC272 Analog] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write!
Mar 18 22:19:26 localhost pulseaudio[9904]: [alsa-sink-ALC272 Analog] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
Mar 18 22:19:26 localhost pulseaudio[9904]: [alsa-sink-ALC272 Analog] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
Mar 18 22:20:01 localhost cron[10670]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)

In the cases when NetworkManager activates a connection correctly and there is no invalid second eth0 connection, the log contains a message like the following:

Mar 16 22:23:47 localhost NetworkManager[6688]: <info>  Auto-activating connection 'eth0'.

Notice there is no such message in the message log above.

The only way I can be sure of preventing NetworkManager creating an invalid second eth0 connection is to disable IPv6 system-wide by uncommenting the line ‘alias net-pf-10 off‘ in the file /etc/modprobe.d/aliases.conf.

So, to me, this looks like a bug in NetworkManager 1.0.0 (I have been experiencing it since Version 0.9.10.0).

NetworkManager creates a new connection ‘eth0’ that does not work

Several months ago a new entry ‘eth0’ began appearing under ‘Available connections‘ in the KDE plasma-nm widget (the KDE GUI front-end to NetworkManager) in my Gentoo Linux installation. However, there was already an automatically-created entry ‘Wired connection 1’ for the wired interface. In the plasma-nm GUI I could see that both entries were for the same interface (eth0) and MAC address. My laptop could access the Internet via the connection ‘Wired connection 1’ as usual, but not via the new connection ‘eth0’. And if I deleted ‘eth0’ in the plasma-nm GUI, ‘Wired connection 1’ could not access the Internet until I recreated ‘eth0’ manually.

Apart from the fact that two entries for the same interface is unnecessary, it was annoying because sometimes ‘eth0’ automatically became the active connection instead of ‘Wired connection 1’, despite the fact that only ‘Wired connection 1’ had ‘Automatically connect to this network when it is available’ ticked in the plasma-nm GUI. When this happened, the network icon on the Panel showed an active connection but in fact the laptop could not connect to the Internet. However, the connection did work as expected on the occasions when ‘Wired connection 1’ automatically became the active connection or if I switched manually to ‘Wired connection 1’ via the plasma-nm GUI.

Even more strangely, if I happened to be using WiFi when no Ethernet cable was connected, very occasionally the network icon on the Panel would change from a wireless icon to a wired icon and connection to the Internet would be lost. I would then have to re-select the wireless network in order to reconnect to the Internet.

As my laptop has only one Ethernet port, and as there was previously no ‘eth0’ entry under ‘Available connections‘, initially I thought that the new entry occurred because I had recently installed a new version of udev. I have the parameter net.ifnames=0 in the kernel boot line to stop udev/eudev using the so-called Predictable Network Interface Names, and I have the following udev/eudev rules files relating to networking:

# ls -la /etc/udev/rules.d/*net*
lrwxrwxrwx 1 root root    9 Nov 30 15:25 80-net-setup-link.rules -> /dev/null
# ls -la /lib64/udev/rules.d/*net*
-rw-r--r-- 1 root root  452 Nov  7 09:57 /lib64/udev/rules.d/75-net-description.rules
-rw-r--r-- 1 root root 1734 Jan 28 18:29 /lib64/udev/rules.d/77-mm-huawei-net-port-types.rules
-rw-r--r-- 1 root root  491 Nov  7 09:57 /lib64/udev/rules.d/80-net-name-slot.rules
-rw-r--r-- 1 root root  280 Jan 24 00:41 /lib64/udev/rules.d/90-network.rules

Perhaps udev (well, eudev, as I switched to using eudev after the problem started) did have something to do with the new entry, but I began to suspect that NetworkManager was the culprit. I think the problem first occurred after installing NetworkManager 0.9.10.0 last October, but it remained after I installed NetworkManager 1.0.0, until today when I made the various changes described further on.

I had merged NetworkManager 1.0.0 and preceding versions since 0.9.8.8 with USE flags -dhclient and dhcpcd, i.e. NetworkManager in my installation uses the DHCP client dhcpcd instead of dhclient. (I used to merge NetworkManager to use dhclient but found it did not work with 0.9.8.8 and later versions of NetworkManager.)

The relevant network services running in my installation are as follows, and nothing looks incorrect to me:

# rc-update show | grep -i net
       NetworkManager |      default
                local |      default nonetwork
               net.lo | boot
             netmount |      default
# rc-status | grep -i net
NetworkManager                                                    [ started ]
netmount                                                          [ started ]
# rc-update show | grep dh
# rc-status | grep dh
# rc-update -v show | grep supplicant
wpa_supplicant |
# rc-status | grep supplicant
#

NetworkManager itself launches the DHCP client, so the installation should not be configured to launch a DHCP client. Indeed the output above shows that no DHCP client service is configured to run independently of NetworkManager, and I also double-checked that multiple instances of a DHCP client are not running (they’re not):

# ps -C NetworkManager
  PID TTY          TIME CMD
 6481 ?        00:00:22 NetworkManager
# ps -C dhcpcd
  PID TTY          TIME CMD
10378 ?        00:00:00 dhcpcd
# ps -C dhclient
  PID TTY          TIME CMD
#

As far as WiFi is concerned, NetworkManager itself launches wpa_supplicant, so the installation should not be configured to launch wpa_supplicant. Indeed the output from rc-update and rc-status above shows that no wpa_supplicant service is configured to run independently of NetworkManager, and I also double-checked that multiple instances of wpa_supplicant are not running (they’re not):

# ps -C wpa_supplicant
  PID TTY          TIME CMD
 6491 ?        00:00:00 wpa_supplicant
#

So, as far as I could tell, there was nothing wrong with the non-NetworkManager side of my installation.

I thought the problem might be due to the settings in the file /etc/NetworkManager/NetworkManager.conf, which contained the following:

[main]
plugins=keyfile
dhcp=dhcpcd

[ifnet]
managed=true
auto_refresh=false

[keyfile]
hostname=meshedgedx

I studied the manual pages for NetworkManager.conf:

# man NetworkManager.conf

If I understand correctly, the ifnet plug-in is Gentoo-specific (see References 3, 4 and 5 further on). The entries under [ifnet] in my NetworkManager.conf file were redundant in any case because the ifnet plug-in was not included in the plugins list under [main], so I deleted the entire [ifnet] section. There is no mention of the ifnet plug-in on the NetworkManager.conf manual page or in the Gentoo Linux Wiki article on NetworkManager, and a cursory look in the Gentoo ebuild for NetworkManager 1.0.0 clearly indicates the ifnet plug-in is broken. See, for example, the following comment in the ebuild:

# ifnet plugin always disabled until someone volunteers to actively
# maintain and fix it

and the following warning messages in the ebuild if the user has included ifnet in plugin=<plugin list> in NetworkManager.conf:

ewarn "Ifnet plugin is now disabled because of it being unattended"
ewarn "and unmaintained for a long time, leading to some unfixed bugs"
ewarn "and new problems appearing. We will now use upstream 'keyfile'"
ewarn "plugin."
ewarn "Because of this, you will likely need to reconfigure some of"
ewarn "your networks. To do this you can rely on Gnome control center,"
ewarn "nm-connection-editor or nmtui tools for example once updated"
ewarn "NetworkManager version is installed."
ewarn "You seem to use 'ifnet' plugin in ${EROOT}etc/NetworkManager/NetworkManager.conf"
ewarn "Since it won't be used, you will need to stop setting ifnet plugin there."

I modified NetworkManager.conf to contain the following:

[main]
plugins=keyfile
dhcp=dhcpcd
no-auto-default=eth0

[keyfile]
hostname=meshedgedx

Note that the ifnet plug-in was not specified in the plugins list in the [main] section of my previous NetworkManager.conf so it was not the cause of my problem, but I hoped that adding no-auto-default=eth0 to NetworkManager.conf would solve the problem. I deleted the ‘Wired connection 1’ entry from the plasma-nm GUI, ticked ‘Automatically connect to this network when it is available’ for the ‘eth0’ entry and made sure that option was not ticked for any of the other entries under ‘Available connections‘, then rebooted. There was no longer an entry ‘Wired connection 1’ in the plasma-nm widget GUI, just an entry for ‘eth0’, and the installation connected automatically to the wired network and I could access the Internet, but did not reconnect to the wired network if I removed and reinserted the Ethernet cable when also connected to a wireless network. So I was not home and dry yet.

I have read on various Web sites that NetworkManager prefers wired connections over wireless connections. I assume this is because NetworkManager sets a higher metric for the wired connection.

I am on a work trip at the moment and cannot use a dynamic wired connection, only a static wired connection, but I can see that NetworkManager 1.0.0 does set a higher-priority metric for wired connections:

# # Now with both dynamic wireless and static wired:
# ip route show
default via 10.90.21.1 dev eth0  proto static  metric 100
default via 10.96.0.1 dev wlan0  proto static  metric 600
10.90.21.0/24 dev eth0  proto kernel  scope link  src 10.90.21.112  metric 100
10.96.0.0/16 dev wlan0  proto kernel  scope link  src 10.96.87.86
10.96.0.0/16 dev wlan0  proto kernel  scope link  src 10.96.87.86  metric 303
127.0.0.0/8 dev lo  scope host
127.0.0.0/8 via 127.0.0.1 dev lo
192.0.2.1 via 10.96.0.1 dev wlan0  proto dhcp  metric 600
#

10.90.21.1 is the IP address of the gateway for the wired connection, and 10.90.21.112 is the IP address of my laptop’s wired interface. The smaller the metric value, the higher the routing priority. Notice that the metric for the eth0 interface is 100 whereas the metric for the wlan0 interface is 600, so it does appear that NetworkManager favours a wired connection over a wireless connection when both are active.

After doing all the above, I came across Debian bug report no. 755202: network-manager: keeps creating and using new connection “eth0” that does not work which appears to be exactly what I was experiencing. Various people posted solutions that worked in their particular circumstances, so I am none the wiser. Gentoo user Keivan Moradi posted message no. 79 on that bug report, about a warning message he found in the NetworkManager log file regarding a file /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0, and he then deleted the latter file. I found the same message in /var/log/messages:

# grep networkmanager /var/log/messages
Feb  9 04:10:05 localhost NetworkManager[10355]: <warn>      error in connection /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0: invalid connection: connection.type: property is missing
Feb 11 15:53:05 localhost NetworkManager[13143]: <warn>      error in connection /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0: invalid connection: connection.type: property is missing

The file /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0 also existed in my installation, so I also deleted it. It was a zero-length file and I do not know if it had anything to do with my problem:

# ls -la /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0
-rw------- 1 root root 0 Jan 20 00:09 /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0
# rm /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0
#

Anyway, the file /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0 has not reappeared since I deleted it.

Keivan Moradi had ‘id=Wired‘ under [connection] in the file /etc/NetworkManager/system-connections/eth0, and he decided to change the name of the file from ‘eth0‘ to ‘Wired‘. However, in my case the file name and the id in the file /etc/NetworkManager/system-connections/eth0 are both ‘eth0‘:

# cat /etc/NetworkManager/system-connections/eth0
[ethernet]
mac-address=70:5A:B6:3E:C1:8A
mac-address-blacklist=

[connection]
id=eth0
uuid=cb3d5786-f947-44b8-92f7-8471fc94c568
type=ethernet
permissions=
secondaries=

[ipv6]
method=ignore
dns-search=

[ipv4]
method=auto
dns-search=

I had already deleted and recreated the connection ‘eth0’ in the plasma-nm GUI by the time I checked the contents of the directory /etc/NetworkManager/system-connections/ so I do not know if the original file name and id were the same. I had also already deleted the connection ‘Wired connection 1’ in the plasma-nm GUI by the time I checked the contents of the directory; presumably files for connections ‘Wired connection 1’ and ‘eth0’ both existed in /etc/NetworkManager/system-connections/ before then. I do not know why the zero-length file .keep_net-misc_networkmanager-0 was created, but no further files have appeared in the directory since I deleted the connection ‘Wired connection 1’ and the file .keep_net-misc_networkmanager-0.

Keivan Moradi was also previously using a buggy r8169 kernel module (Realtek Ethernet hardware) and switched to using the r8168 module, but I am using a Qualcomm Atheros AR8131 Gigabit Ethernet card and an Intel Corporation Ultimate N WiFi Link 5300 card, so that part of his problem cannot be a factor in my case.

Anyway, as I wrote earlier, I no longer have two connection entries for the wired interface, and NetworkManager no longer creates automatically a second connection entry for the wired interface. And now if I am already connected to a wireless network, NetworkManager connects/reconnects automatically to a wired network with the ‘Automatically connect’ option ticked. So it looks like my problem is completely solved, although I reserve judgement until I have been able to use the laptop in my home network (which has the same router for both wired and wireless connections, whereas the wired network and wireless network are separate networks in the office in which I am now working).

Conclusion

If you had the patience to read all the above, I am impressed! If you also understood it, I am doubly impressed!

To cut a long story short, if you are experiencing a similar problem to mine, I recommend you do the following:

  1. Check that your network driver is reliable. You can search the Web to see if other users have experienced problems with the same driver you are using.

  2. Make sure the contents of NetworkManager.conf are correct. Read the NetworkManager.conf man page and the GNOME Wiki page on NetworkManager settings to find out what options are available.

  3. Delete all the files (i.e. including hidden files) in the directory /etc/NetworkManager/system-connections/ and recreate your connections via either the NetworkManager GUI (e.g. plasma-nm in KDE or nm-applet in GNOME) or NetworkManager TUI (nmtui).

References

  1. man NetworkManager.conf
  2. Gentoo Linux Wiki – NetworkManager
  3. GNOME Wiki – NetworkManager SystemSettings – Configuration Plugins
  4. Gentoo NetworkManager Plugin
  5. Another Gentoo Dev – Ifnet updates for NetworkManager 0.9

UPDATE (March 10, 2015): Well, I was right to reserve judgement until I was able to use my laptop with my home network. I am now back at home and an Ethernet cable is plugged into my laptop’s RJ45 socket. Even with the changes I made, when I boot the laptop NetworkManager sometimes (but not always) has two connections named ‘eth0’, one of them the ‘Active connection’ (but not able to connect to the Internet) and the other an ‘Available connection’. In this situation the wired network icon on the Panel has a yellow question mark superimposed. If I delete the ‘eth0’ active connection and use the other ‘eth0’, the latter works as expected and I have no trouble connecting to the Internet. In Debian bug report no. 755202 (see the link further up) user Frederik Himpe added a comment on March 4, 2015 that he is also still experiencing this problem and “It looks like there is a race somewhere, causing the network interface to be brought up before Network Manager is started, and this prevents correct configuration by NM”. So the problem is still unresolved. Hmm … I wonder if udev does have something to do with it after all.

UPDATE (March 12, 2015): The problem persists. I disabled use of IPv6 in /etc/avahi/avahi-daemon.conf to see if the Avahi daemon has something to do with the problem, but that made no difference. Later I also disabled use of IPv4 in /etc/avahi/avahi-daemon.conf, but that made no difference either. So it looks like the Avahi daemon is not the culprit. Checking via the plasma-nm GUI I notice that the ‘rogue’ eth0 Active connection has IPv4 disabled and IPv6 Link-Local enabled. So why is NetworkManager creating a second eth0 connection just for IPv6 Link-Local? And why on Earth is NetworkManager creating any additional connection at all when NetworkManager.conf contains no-auto-default=eth0? Surely this must be a bug in NetworkManager 1.0.0?

UPDATE (March 17, 2015): I have been investigating the problem further: see my latest blog post for details.

Fix for ALSA Speaker volume level resetting to zero at boot

Up until 2011 the problem of the volume level in ALSA resetting to zero at boot was a common occurrence in my Linux installations. Actually it was a common occurrence in Linux, full stop; search the Web using keywords such as “alsa reset volume” and you’ll find umpteen links. In 2012 the situation improved and I thought the problem had become a thing of the past, but it resurfaced in 2013 on my main laptop and has plagued me through every update since (well, apart from in one release of KDE). Every time I reboot, the ALSA Speaker channel’s volume is zero when I log-in to KDE. And, as KMix is a PulseAudio mixer by default these days, I have to launch ALSAMixer and raise the volume of the Speaker channel manually.

I don’t know if the source of the problem lies in KDE, PulseAudio or ALSA itself. It did disappear after one upgrade to KDE earlier this year (I don’t recall which release of KDE) but returned in the next KDE upgrade, so I suspect it is a KDE issue. In earlier days I could resolve the problem using the commands alsactrl store and alsactl restore and similar approaches. However, this time none of those fixes work for me. The problem never bothered me much, as I always connect external speakers to my laptop’s headphone socket when I’m at home, and I don’t want my laptop emitting sounds at the office. Nevertheless, the fact the problem exists niggled me, so I decided to try and fix it. Rather than expending any more effort trying to get the usual approaches to work (the Web is littered with suggested fixes over the years), I decided to reset the Speaker volume to the same level at each boot by using an automatically-launched shell script. The method I use is given below, and should work with either OpenRC or systemd in Gentoo Linux.

1. Create the file /etc/local.d/20set_alsa_volume.start containing the following:

#!/bin/bash
# Reset ALSA Speaker channel on the first sound card to 90% after booting.
su -c "amixer -c 0 -- sset Speaker playback 90%" -s /bin/sh fitzcarraldo

(Replace “fitzcarraldo” with your own user name, of course.)

2. Make the script executable:

# chmod +x 20set_alsa_volume.start

That’s all there is to it. The volume of the ALSA Speaker channel is always set to 90% after I reboot and login to the desktop environment. KMix remembers the PulseAudio volume setting from the previous session, so I can still avoid blasting the laptop’s speakers.

By the way, the manual pages for the amixer and alsamixer commands make useful reading:

$ man amixer
$ man alsamixer

For example, the first audio card (Card 0) in my main laptop has the following controls:

$ amixer -c 0 scontrols
Simple mixer control ‘Master’,0
Simple mixer control ‘Headphone’,0
Simple mixer control ‘Speaker’,0
Simple mixer control ‘PCM’,0
Simple mixer control ‘Mic’,0
Simple mixer control ‘Mic Boost’,0
Simple mixer control ‘Beep’,0
Simple mixer control ‘Capture’,0
Simple mixer control ‘Auto-Mute Mode’,0
Simple mixer control ‘Digital’,0
Simple mixer control ‘Internal Mic’,0
Simple mixer control ‘Internal Mic Boost’,0

Update (January 29, 2015): I found the cause of the problem: PulseAudio. I edited the file /usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf as per user agmg‘s January 2013 post Re: [SOLVED] Problems with PulseAudio 3.0 in the PCLinuxOS Forums:

Again, I had to edit the file: /usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf

and change this:

[Element Speaker]
switch = mute
volume = off

to this:

[Element Speaker]
switch = mute
volume = merge

I realized that editing the [Element Desktop Speaker] section of the above file, has no effect on the issue. Only the edit to [Element Speaker] is needed in my case.

In my case this change forces the ALSA Speaker channel volume to 100% after rebooting (irrespective of the volume levels I set via ALSAMixer and KMix before shutdown).

The contents of the file /usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf also include the following comment:

; See analog-output.conf.common for an explanation on the directives

The contents of the file analog-output.conf.common include the following comment:

; volume = ignore | merge | off | zero | <volume step> # What to do with this volume: ignore it, merge it into the device
;                                                      # volume slider, always set it to the lowest value possible, or always
;                                                      # set it to 0 dB (for whatever that means), or always set it to
;                                                      # <volume step> (this only makes sense in path configurations where
;                                                      # the exact hardware and driver are known beforehand).

So I could have tried volume = <volume step> instead of volume = merge, although I have no idea what value <volume step> would need to be. Anyway, the Bash script /etc/local.d/20set_alsa_volume.start that I created does the job in a different way without me having to tinker with the troublesome PulseAudio, so I reverted to volume = off in the file analog-output.conf and reverted to using /etc/local.d/20set_alsa_volume.start as explained earlier.

Laptop Mode Tools revisited due to a change in its functionality

The site statistics for this blog can be quite revealing. For example, over the last two or three months I noticed that my post How to prevent a USB mouse auto-suspending in Linux when a laptop’s power supply is disconnected has consistently been one of the most viewed. Given the problems I experienced with Laptop Mode Tools 1.65 (see my Gentoo Linux Forums post Bug in laptop-mode-tools-1.65? and Gentoo Linux Bugzilla Bug Report No. 520124), I was not entirely surprised. Thanks to fellow Gentoo Linux and Laptop Mode Tools user Ted Tanberry I learned that Version 1.65 had stopped using Laptop Mode Tools module usb-autosuspend, and started using Laptop Mode Tools module runtime-pm instead. At least that was the developer’s intention, but he had not implemented it correctly. The aforementioned Gentoo Linux bug report explains in detail the problem with Version 1.65.

The situation in my Gentoo Linux installation with laptop-mode-tools-1.64 installed, providing the functionality I desired, was as follows:

a. The precise package installed:

# eix -I laptop-mode-tools
[U] app-laptop/laptop-mode-tools
Available versions: 1.64 (~)1.65 (~)1.65-r1 (~)1.66 {+acpi apm bluetooth scsi}
Installed versions: 1.64(10:04:43 21/10/14)(acpi bluetooth -apm -scsi)
Homepage: http://www.samwel.tk/laptop_mode/
Description: Linux kernel laptop_mode user-space utilities

b. The auto-suspend state when the laptop PSU was connected:

# for d in /sys/bus/usb/devices/[0-9]* ; do if [[ -e $d/product ]] ; then echo -e "`basename $d`\t`cat $d/power/control`\t`cat $d/speed`\t`cat $d/product`" ; fi ; done
1-1.2 on 1.5 USB Laser Mouse
2-1.2 on 12 Fingerprint Sensor
2-1.3 on 480 USB 2.0 Camera

c. The contents of the file /lib64/udev/rules.d/99-laptop-mode.rules:

ACTION=="change", SUBSYSTEM=="power_supply", RUN+="lmt-udev auto"
ACTION=="add|remove", SUBSYSTEM=="machinecheck", RUN+="lmt-udev auto"
ACTION=="add|remove", SUBSYSTEM=="usb", RUN+="lmt-udev force modules=usb-autosuspend devices=%k"

d. The contents of file /etc/laptop-mode/conf.d/usb-autosuspend.conf:

#
# Configuration file for Laptop Mode Tools module usb-autosuspend.
#
# For more information, consult the laptop-mode.conf(8) manual page.
#
 
 
###############################################################################
# USB autosuspend settings
# ------------------------
#
# If you enable this setting, laptop mode tools will automatically enable the
# USB autosuspend feature for all devices.
#
# NOTE: Some USB devices claim they support autosuspend, but implement it in a
# broken way. This can mean keyboards losing keypresses, or optical mice turning
# their LED completely off. If you have a device that misbehaves, add its USB ID
# to the blacklist below and complain to your hardware vendor.
################################################################################
 
# Enable debug mode for this module
# Set to 1 if you want to debug this module
DEBUG=0
 
# Enable USB autosuspend feature?
# Set to 0 to disable
CONTROL_USB_AUTOSUSPEND="auto"
 
# Set this to use opt-in/whitelist instead of opt-out/blacklist for deciding
# which USB devices should be autosuspended.
# AUTOSUSPEND_USE_WHITELIST=0 means AUTOSUSPEND_*_BLACKLIST will be used.
# AUTOSUSPEND_USE_WHITELIST=1 means AUTOSUSPEND_*_WHITELIST will be used.
AUTOSUSPEND_USE_WHITELIST=0
 
# The list of USB IDs that should not use autosuspend. Use lsusb to find out the
# IDs of your USB devices.
# Example: AUTOSUSPEND_USBID_BLACKLIST="046d:c025 0123:abcd"
AUTOSUSPEND_USBID_BLACKLIST="046d:c052"
 
# The list of USB driver types that should not use autosuspend.  The driver
# type is given by "DRIVER=..." in a USB device's uevent file.
# Example: AUTOSUSPEND_USBID_BLACKLIST="usbhid usb-storage"
AUTOSUSPEND_USBTYPE_BLACKLIST=""
 
# The list of USB IDs that should use autosuspend. Use lsusb to find out the
# IDs of your USB devices.
# Example: AUTOSUSPEND_USBID_WHITELIST="046d:c025 0123:abcd"
AUTOSUSPEND_USBID_WHITELIST=""
 
# The list of USB driver types that should use autosuspend.  The driver
# type is given by "DRIVER=..." in a USB device's uevent file.
# Example: AUTOSUSPEND_USBTYPE_WHITELIST="usbhid usb-storage"
AUTOSUSPEND_USBTYPE_WHITELIST=""
 
# Trigger auto-suspension of the USB deivce under conditional circumstances
BATT_SUSPEND_USB=1
LM_AC_SUSPEND_USB=0
NOLM_AC_SUSPEND_USB=0
 
# USB Auto-Suspend timeout in seconds
# Number of seconds after which the USB devices should suspend
AUTOSUSPEND_TIMEOUT=2

Having experienced the problems with the buggy Laptop Mode Tools 1.65, I re-installed 1.64 and had been using that successfully until a week ago. Then I noticed that 1.66 had been released, so I installed it:

# emerge laptop-mode-tools
.
.
.
>>> Installing (1 of 1) app-laptop/laptop-mode-tools-1.66::gentoo
* To enable automatic power state event handling,
* e.g. enabling laptop_mode after unplugging the battery,
* both laptop_mode and the acpid daemon must be
* added to default runlevel:
* # rc-update add laptop_mode default
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

* GNU info directory index is up-to-date.

I would not have expected that ewarn message about adding laptop_mode to the default runlevel, as the ebuild is only supposed to display the warning if laptop_mode is not assigned to the default runlevel. But, sure enough, something had removed it:

# rc-update show -v | grep laptop
laptop_mode |
# rc-update show -v | grep acpi
acpid |      default

I don’t know what removed laptop_mode from the default runlevel. It was certainly assigned previously, as proved by Laptop Mode Tools 1.64 working as expected when I connected and disconnected the laptop’s PSU from the mains (see my earlier post). Anyway, I re-added it:

# rc-update add laptop_mode default
* service laptop_mode added to runlevel default

If you use systemd instead of OpenRC, instead of adding laptop_mode to the default runlevel you would need to use the following command:

# systemctl enable laptop_mode.service

Notice that the incorrect contents of 99-laptop-mode.rules and /etc/laptop-mode/laptop-mode.conf that were present in Laptop Mode Tools 1.65 have been fixed in 1.66:

# cat /lib64/udev/rules.d/99-laptop-mode.rules
ACTION=="change", SUBSYSTEM=="power_supply", RUN+="lmt-udev auto"
ACTION=="add|remove", SUBSYSTEM=="machinecheck", RUN+="lmt-udev auto force"
ACTION=="add|remove", SUBSYSTEM=="usb", RUN+="lmt-udev force modules=runtime-pm devices=%k"

# cat /etc/laptop-mode/laptop-mode.conf | grep usb-autosuspend
#

The ebuild for Laptop Mode Tools 1.66 did not delete the now-redundant file /etc/laptop-mode/conf.d/usb-autosuspend.conf but it is presumably ignored by 1.66 anyway.

From now on I must configure the contents of /etc/laptop-mode/conf.d/runtime-pm.conf instead. After installing Laptop Mode Tools 1.66 it contained the following:

#
# Configuration file for Laptop Mode Tools module runtime-pm
#
# For more information, consult the laptop-mode.conf(8) manual page.
#


###############################################################################
# Runtime Power Management Settings
# ---------------------------------
#
#__COMMENT If you enable this setting, laptop mode tools will automatically enable
#__COMMENT the Runtime Power Management feature for all devices.
#__COMMENT
#__COMMENT NOTE: Some devices claim they support autosuspend, but implement it in a
#__COMMENT broken way. This can mean keyboards losing keypresses, or optical mice
#__COMMENT turning their LED completely off. If you have a device that misbehaves,
#__COMMENT add its DEVICE ID to the blacklist section below and complain to your
#__COMMENT hardware / device driver contact
#
################################################################################

# Enable debug mode for this module
# Set to 1 if you want to debug this module
DEBUG=0

# Enable Runtime autosuspend feature?
# Set to 0 to disable
CONTROL_RUNTIME_AUTOSUSPEND=1

# Set this to use opt-in/whitelist instead of opt-out/blacklist for deciding
# which devices should be autosuspended.
# AUTOSUSPEND_USE_WHITELIST=0 means AUTOSUSPEND_*_BLACKLIST will be used.
# AUTOSUSPEND_USE_WHITELIST=1 means AUTOSUSPEND_*_WHITELIST will be used.
AUTOSUSPEND_USE_WHITELIST=0

# The list of Device IDs that should not use autosuspend. Use system commands or
# look into sysfs to find out the IDs of your devices.
# Example: AUTOSUSPEND_DEVID_BLACKLIST="046d:c025 0123:abcd"
AUTOSUSPEND_RUNTIME_DEVID_BLACKLIST=""

# The list of device driver types that should not use autosuspend.  The driver
# type is given by "DRIVER=..." in a device's uevent file.
# Example: AUTOSUSPEND_DEVID_BLACKLIST="usbhid usb-storage"
AUTOSUSPEND_RUNTIME_DEVTYPE_BLACKLIST=""

# The list of Device IDs that should use autosuspend. Use system commands or
# look into sysfs to find out the IDs of your devices.
# Example: AUTOSUSPEND_DEVID_WHITELIST="046d:c025 0123:abcd"
AUTOSUSPEND_RUNTIME_DEVID_WHITELIST=""

# The list of device driver types that should use autosuspend.  The driver
# type is given by "DRIVER=..." in a device's uevent file.
# Example: AUTOSUSPEND_DEVTYPE_WHITELIST="usbhid usb-storage"
AUTOSUSPEND_RUNTIME_DEVTYPE_WHITELIST=""

# Trigger auto-suspension of the deivce under conditional circumstances
# Warning: DO NOT CHANGE THESE DEFAUTLS UNLESS YOU KNOW
BATT_SUSPEND_RUNTIME=1
LM_AC_SUSPEND_RUNTIME=1
NOLM_AC_SUSPEND_RUNTIME=1

# Auto-Suspend timeout in seconds
# Number of seconds after which the USB devices should suspend
AUTOSUSPEND_TIMEOUT=2

So, in order to stop my laptop’s USB mouse, USB external keyboard and some internal USB devices from going to sleep when my laptop is only on battery power, I made the following change to a line in /etc/laptop-mode/conf.d/runtime-pm.conf:

# External keyboard at one office, internal Webcam, internal fingerprint sensor, Logitek NX50 notebook mouse
AUTOSUSPEND_RUNTIME_DEVID_BLACKLIST="03f0:0024 064e:a115 147e:1001 046d:c052"

My earlier post about Laptop Mode Tools explained one method for finding the device ID for each USB device, but the lsusb command can also be used:

# lsusb
Bus 002 Device 005: ID 03f0:0024 Hewlett-Packard KU-0316 Keyboard <---- External keyboard at one office
Bus 002 Device 004: ID 064e:a115 Suyin Corp. <---- Built-in Webcam
Bus 002 Device 003: ID 147e:1001 Upek TCS5B Fingerprint sensor <---- Built-in fingerprint sensor
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 046d:c052 Logitech, Inc. <----Logitech NX50 notebook mouse
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Although the Laptop Mode Tools usb-autosuspend module is supposed to be unused in 1.66, I edited /etc/laptop-mode/conf.d/usb-autosuspend.conf (which was not deleted by the 1.66 ebuild) and changed CONTROL_USB_AUTOSUSPEND="auto" to CONTROL_USB_AUTOSUSPEND="0" just to be on the safe side.