How to run KDE Dolphin, Kate and KWrite as root user

When using KDE I occasionally wish to launch KWrite or Kate as root user in order to edit system files more easily than using a TUI editor in a terminal window (either launched as root user or by using the sudoedit command). Being able to browse using Dolphin as the root user occasionally is also useful. These all used to be possible by launching the application with the kdesu command, but in 2017 KDE developer Martin Gräßlin removed this option on security grounds (see his blog post ‘Editing files as root‘). Attempting to launch e.g. Kate using the sudo command results in the following message:

$ sudo kate
Executing Kate with sudo is not possible due to unfixable security vulnerabilities.

Attempting to launch e.g. Kate using the kdesu command results in a pop-up window prompting me to enter the root user’s password, but then does not launch Kate:

$ kdesu kate
$

I am willing to accept a small risk despite the ‘unfixable security vulnerabilities’ , and a 2018 Kubuntu Forums post by KDE user Rog131 provided me with a solution. It is possible to launch Dolphin, Kate and KWrite as root from your user account by using the pkexec command. For example, to launch Dolphin you can enter:

$ pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true dolphin

Dolphin first displays an orange-coloured box with the warning message ‘Running Dolphin as root can be dangerous. Please be careful.’ and you can then browse and open root-owned directories and files.

You can also launch Kate and KWrite as root from your user account in the same way:

$ pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true kate
$ pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true kwrite

To make it easy to launch them as root user from e.g. Konsole or Yakuake you could set aliases for the three commands in your ~/.bashrc file:

$ tail -n 3 ~/.bashrc
alias dolroot="pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true dolphin"
alias kateroot="pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true kate"
alias kwriteroot="pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true kwrite"

Then all you would need to type in a terminal window would be:

$ dolroot
$ kateroot
$ kwriteroot

which are no more difficult than having to type:

$ kdesu dolphin
$ kdesu kate
$ kdesu kwrite

If an alias is used, rooted-Dolphin/Kate/KWrite can be launched from the command line but cannot be launched via KDE’s Application Launcher menu or KRunner. On the other hand, if a wrapper script is used, rooted-Dolphin/Kate/KWrite can be launched from the user’s command line and via KDE’s Application Launcher menu (and therefore via KRunner too). For example, I created three tiny Bash scripts dolroot, kateroot and kwriteroot. The scripts simply contain the aforementioned pkexec command. For example, dolroot contains:

#!/bin/bash
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true dolphin

Don’t forget to make them executable:

$ chmod 700 dolroot
$ chmod 700 kateroot
$ chmod 700 kwriteroot
$ ls -la *root
-rwx------ 1 fitzcarraldo fitzcarraldo 115 Jul 30 15:33 dolroot
-rwx------ 1 fitzcarraldo fitzcarraldo 112 Jul 30 15:34 kateroot
-rwx------ 1 fitzcarraldo fitzcarraldo 114 Jul 30 15:34 kwriteroot	

After adding entries for dolroot, kateroot and kwriteroot to the KDE Application Launcher’s menu, you can press Alt+F2 as usual to display the KRunner launcher then enter ‘dolroot’, ‘kateroot’ or ‘kwriteroot’ (without the quotes, obviously) in the KRunner window to launch Dolphin/Kate/KWrite as root user. A window will pop-up for you to enter the root user’s password. Once you have entered the root user’s password, the application will be launched.

Thankfully KDE’s Nathaniel Graham is pragmatic:

D12795 – Re-allow running Dolphin as the root user (but still not using sudo)
D12732 – Show a warning when running as the root user

How to change the height of the Kickoff Application Launcher menu in KDE Plasma

The height of the KDE Plasma Kickoff Application Launcher menu is not user-configurable, which is odd in a Desktop Environment with a reputation for being highly user-configurable.

It turns out that the height and width of the pop-up menu are hard-coded in the ASCII file /usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/FullRepresentation.qml:

root # grep -E "Layout.minimumHeight.*units.gridUnit" /usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/FullRepresentation.qml
    Layout.minimumHeight: units.gridUnit * 34
root # grep -E "Layout.minimumWidth.*units.gridUnit" /usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/FullRepresentation.qml
    Layout.minimumWidth: units.gridUnit * 26

Now, I was a bit fed up having to scroll up and down the launcher menu to see all fourteen entries in my Favourites list, so I decided to increase the height of the menu, which I did by editing /usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/FullRepresentation.qml as root user:

root # nano /usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/FullRepresentation.qml
root # grep -E "Layout.minimumHeight.*units.gridUnit" /usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/FullRepresentation.qml
    Layout.minimumHeight: units.gridUnit * 44

The only downside to this is that the file will be overwritten when the package kde-plasma/plasma-desktop is upgraded.

The following command would allow me to make sure the file contains the height value of ’44’ that I want:

root # sed -i '/Layout.minimumHeight: units.gridUnit/ c\    Layout.minimumHeight: units.gridUnit * 44' /usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/FullRepresentation.qml

Therefore, to automate the editing of the file in my Gentoo installations that use OpenRC I created a shell script /etc/local.d/50-set_Kickoff_height.start with the following contents:

#!/bin/bash
if [ -e /usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/FullRepresentation.qml ]; then
    sed -i '/Layout.minimumHeight: units.gridUnit/ c\    Layout.minimumHeight: units.gridUnit * 44' /usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/FullRepresentation.qml
fi

The FullRepresentation.qml file will then be edited every time the machine boots, which is a tad inefficient but not a big overhead.

This is not a perfect solution because the menu will revert to its default height following an upgrade to the package kde-plasma/plasma-desktop until I reboot the machine, but it is good enough for me.

How to stop inactive user sessions triggering Suspend to RAM in a single-seat, multi-user installation of Lubuntu 18.04

In my previous post I mentioned a problem that I had still not been able to fix in a single-seat, multi-user installation of Lubuntu 18.04: Xfce Power Manager in each user’s account can cause the installation to suspend to RAM if a user has not logged out of his/her session and another user is using a different session. Each user account in Lubuntu 18.04 has its own XfcePower Manager settings, stored in the file ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-power-manager.xml. If the property /xfce4-power-manager/inactivity-on-ac has a value of 15 (minutes) or higher, that session can cause the machine to suspend to RAM even if the session is not active while someone else’s session is active. The example below illustrates the effect.

Consider five users mick, christine, john, stevie and lindsey with the following settings for the number of minutes of inactivity that will trigger suspension to RAM:

mick@aspirexc600:~$ xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/inactivity-on-ac
30
christine@aspirexc600:~$ xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/inactivity-on-ac
25
john@aspirexc600:~$ xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/inactivity-on-ac
45
stevie@aspirexc600:~$ xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/inactivity-on-ac
15
lindsey@aspirexc600:~$ xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/inactivity-on-ac
30

Now, suppose that john boots the machine, logs in to his account to check his e-mail, leaves the e-mail client open and goes off to grab lunch without logging out. Then stevie comes along and clicks on ‘Logout’ > ‘Switch User’ to display the LightDM greeter screen (or the greeter screen is already displayed because john‘s session has already been locked), logs in to her account and begins to use, say, LibreOffice Writer. Even though stevie is busy typing, the machine will suspend to RAM after 45 minutes of inactivity by john. This can be very annoying.

In addition to the individual users’ Xfce Power Manager configuration files in Lubuntu 18.04, I found the following Xfce Power Manager configuration files which appear to be system-wide:

/etc/xdg/xdg-Lubuntu/xfce4/xfconf/xfce-perchannel-xml/xfce4-power-manager.xml
/etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-power-manager.xml

First attempt at fixing the problem

I asked all the users to configure their accounts to never cause the machine to suspend, by using the Xfce Power Manager settings GUI in their session and selecting ‘Never’. I noticed this caused each user’s /xfce4-power-manager/inactivity-on-ac property to become ‘14‘:

user $ xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/inactivity-on-ac
14

Note that users must not edit their file ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-power-manager.xml; if they do, the settings shown in the Xfce Power Manager settings GUI will not be updated. Users must either use the Xfce Power Manager settings GUI or xfconf-query commands as explained on the askubuntu Web page ‘Change xfce4-power-manager option from terminal‘.

Then I edited the file /etc/xdg/xdg-Lubuntu/xfce4/xfconf/xfce-perchannel-xml/xfce4-power-manager.xml to make its contents the same as the previous contents of the individual users’ settings when Suspend to RAM was enabled individually):

<?xml version="1.0" encoding="UTF-8"?>

<channel name="xfce4-power-manager" version="1.0">
  <property name="xfce4-power-manager" type="empty">
    <property name="power-button-action" type="uint" value="3"/>
    <property name="show-tray-icon" type="bool" value="true"/>
    <property name="brightness-switch-restore-on-exit" type="int" value="1"/>
    <property name="brightness-switch" type="int" value="0"/>
    <property name="presentation-mode" type="bool" value="false"/>
    <property name="inactivity-on-ac" type="uint" value="30"/>
    <property name="blank-on-ac" type="int" value="10"/>
    <property name="dpms-on-ac-sleep" type="uint" value="0"/>
    <property name="dpms-on-ac-off" type="uint" value="0"/>
    <property name="brightness-on-ac" type="uint" value="9"/>
    <property name="lock-screen-suspend-hibernate" type="bool" value="true"/>
    <property name="logind-handle-lid-switch" type="bool" value="false"/>
    <property name="dpms-enabled" type="bool" value="false"/>
    <property name="general-notification" type="bool" value="true"/>
    <property name="sleep-button-action" type="uint" value="0"/>
    <property name="hibernate-button-action" type="uint" value="0"/>
  </property>
</channel>

After rebooting, leaving one or more users logged in without any activity did not cause the installation to suspend to RAM after 30 minutes of no activity in any session.

So I then edited the file /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-power-manager.xml to make its contents the same as the above. After rebooting, leaving one or more users logged in without any activity did not cause the installation to suspend to RAM after 30 minutes of no activity in any session.

I therefore assume that the above two files are ignored by Xfce Power Manager during normal operation.

Second attempt at fixing the problem

I used the procedure given in the Xfce4-power-manager FAQs to check if Xfce Power Manager in Lubuntu 18.04 uses systemd-logind to suspend the installation, and indeed it does:

TRACE[xfpm-polkit.c:366] xfpm_polkit_check_auth_intern(): Action=org.freedesktop.login1.suspend is authorized=TRUE

Therefore I edited /etc/systemd/logind.conf to add IdleAction=suspend and IdleActionSec=30min, and rebooted. However, this had no discernable effect either. Leaving one or more users logged in without any activity did not cause the installation to suspend to RAM after 30 minutes of no activity in any session.

Third attempt (successful) at fixing the problem

So, what to do?! In my previous post I explained how I had fixed the problem of not being able to suspend to RAM automatically from the LightDM greeter screen. I decided to keep the scripts from that post and add a new script sessions_sleep.sh to the root crontab. The contents of all the files and the crontab are shown below.

user $ cd /etc/lightdm/lightdm.conf.d/
user $ cat 10_lubuntu.conf 
[Seat:*]
greeter-setup-script=/etc/lightdm/lightdm.conf.d/lightdm_sleep.sh
session-setup-script=/etc/lightdm/lightdm.conf.d/lightdm_kill_sleep.sh
session-cleanup-script=/etc/lightdm/lightdm.conf.d/unmount_FREECOM_HDD.sh
user $ ls
05_lubuntu.conf  lightdm_kill_sleep.sh       sessions_sleep.sh
10_lubuntu.conf  lightdm_sleep.sh            unmount_FREECOM_HDD.sh
user $ cat lightdm_sleep.sh 
#!/bin/bash
# This forms part of the scheme to provide automatic suspension while the greeter screen is displayed
file="/tmp/unique_identifier"
(while true; do sleep 30m; systemctl suspend; done) &
echo $! > $file
user $ cat lightdm_kill_sleep.sh
#!/bin/bash
# This forms part of the scheme to provide automatic suspension while the greeter screen is displayed
file="/tmp/unique_identifier"
if [ -f "$file" ]; then
    kill `cat $file`
    rm $file
fi
user $ tail -n 11 unmount_FREECOM_HDD.sh
#----------------------------------------------------------------------------------------------------
#
# This forms part of the scheme to provide automatic suspension while the greeter screen is displayed
file="/tmp/unique_identifier"
if [ -f "$file" ]; then
    kill `cat $file`
    rm $file
fi
#
#----------------------------------------------------------------------------------------------------
exit 0

If the machine did not already have a permanently-connected external USB HDD (LABEL=”FREECOM HDD”) then it would have sufficed to specify a script named, for example, lightdm_kill_sleep2.sh instead of unmount_FREECOM_HDD.sh:

user $ cat 10_lubuntu.conf 
[Seat:*]
greeter-setup-script=/etc/lightdm/lightdm.conf.d/lightdm_sleep.sh
session-setup-script=/etc/lightdm/lightdm.conf.d/lightdm_kill_sleep.sh
session-cleanup-script=/etc/lightdm/lightdm.conf.d/lightdm_kill_sleep2.sh
user $ cat lightdm_kill_sleep2.sh
#!/bin/bash
# This forms part of the scheme to provide automatic suspension while the greeter screen is displayed
file="/tmp/unique_identifier"
if [ -f "$file" ]; then
    kill `cat $file`
    rm $file
fi
user $ sudo nano sessions_sleep.sh
user $ sudo chmod +x sessions_sleep.sh
user $ cat sessions_sleep.sh 
#!/bin/bash
date +%s > /tmp/datetime_suspended # Initialise variable
while true
do
    # Only monitor idle time and suspend after specified inactivity if lightdm_sleep.sh is not taking care of those
    if [[ `ps -ef | grep bash | grep lightdm_sleep.sh | wc -l` -eq 0 ]]; then
        #-------------------------------STAGE 1: FIND OUT WHO IS THE ACTIVE USER--------------------------------------
        #
        while IFS=: read -r f1 f2 f3 f4 f5 f6 f7
        # $f1 is username
        # $f2 is password ('x')
        # $f3 is UID
        # $f4 is GID
        # $f5 is UID info
        # $f6 is home directory
        # $f7 is command/shell
        do
            if [[ $f6 == *"/home/"* ]] && [[ $f7 == "/bin/bash" ]]; then
                if `loginctl list-users | grep -ve '^$\|USER\|listed' | awk -F' ' '{print $2}' | grep -q $f1`; then
                    state=`loginctl show-user $f3 | grep State | awk -F'=' '{print $2}'`
                    if [[ $state != "active" ]]; then
                        inactive_user=$f1
                    elif [[ $state == "active" ]]; then
                        active_user=$f1
                    fi
                fi
            fi
        done < /etc/passwd
        #
        #-------------------------------STAGE 2: ASCERTAIN USER SESSIONS---------------------------------------------
        #
        # Find idle time for each X Windows session and suspend to RAM if the active user has been idle for >=30min.
        #
        who -u | grep -v "\." > /tmp/logged-in_users
        #
        while read a b c d e f g
        # $a is username
        # $b is the tty (tty1 to tty12)
        # $c is the date (yyyy-mm-dd)
        # $d is the time (hh:mm)
        # $e is the idle time (hh:mm) which does not reflect reality in this installation, for some reason
        # $f is the PID
        # $g is the display e.g. "(:1)"
        # Example: "john     tty7         2019-08-31 17:08 00:01        1624 (:0)"
        do
            if [[ $(echo $b | sed 's/[^0-9]*//g') -gt 6 ]]; then
                display=$(echo $g | sed 's/[^0-9]*//g')
                idle_millisecs=$(env DISPLAY=:$display sudo -u $a xprintidle)
                let idle_minutes=$idle_millisecs/60000
                if [[ $idle_minutes -ge 30 ]] && [[ $a == "$active_user" ]]; then
                    datetime_now=$(date +%s)
                    diffsecs=$(expr $datetime_now - $(cat /tmp/datetime_suspended))
                    # Prevent suspending immediately after resuming
                    if [ $diffsecs -gt 180 ]; then
                        date +%s > /tmp/datetime_suspended
                        systemctl suspend
                    fi
                fi
            fi
        done < /tmp/logged-in_users
        rm /tmp/logged-in_users
        #
        #------------------------------------------------------------------------------------------------------------
        sleep 10 # Frequency to repeat check
    fi
done

I installed the utility xprintidle via the Linux distribution’s package manager. As the name of the utility suggests, it returns the time (in milliseconds) that an X Windows session has been idle. Nice utility, by the way.

user $ sudo crontab -e
user $ sudo crontab -l | grep -v ^#
@reboot sudo /etc/lightdm/lightdm.conf.d/sessions_sleep.sh

Note that, despite its name, ‘@reboot‘ in the cron job will run the script after a cold boot as well as after a warm boot (reboot). Also note that the use of ‘sudo‘ in the root cron job is not an error; it makes the root cron job use the root user’s environment variables.

Remember that the property /xfce4-power-manager/inactivity-on-ac has to be configured to have a value of 14 (which corresponds to ‘Never’ in the Xfce Power Manager settings GUI) for every user. This should be done by each user using the Xfce Power Manager settings GUI in their own session.

Basically, the scheme works as follows: At boot, Lubuntu 18.04 launches the looping Bash script sessions_sleep.sh, which remains running but does nothing because no X Windows users are logged in. When LightDM runs the greeter-setup-script (lightdm_sleep.sh) and displays the greeter screen, sessions_sleep.sh still does nothing while lightdm_sleep.sh is running and taking care of managing suspension. When an X Windows user logs in and LightDM’s session-setup-script (lightdm_kill_sleep.sh) kills the running script lightdm_sleep.sh, the script sessions_sleep.sh then takes over monitoring users’ activity in X Windows and triggers suspension if the active user has not used his/her session for 30 minutes. If an X Windows user logs out, LightDM’s session-cleanup-script (unmount_FREECOM_HDD.sh) also kills lightdm_sleep.sh if it is running. When LightDM again runs its greeter-setup-script (lightdm_sleep.sh) and displays the greeter screen, that again inhibits sessions_sleep.sh from taking any action if no X Windows user is logged in. This all sounds convoluted, but it seems to work fine so far.

Because Xfce Power Manager is no longer used to monitor idle time and trigger suspension, ‘Presentation mode’ in Xfce Power Manager can no longer prevent the system from suspending after 30 minutes of inactivity while someone is watching a long video or playing music, for example. However this is not a problem; to temporarily inhibit suspension the user can use the method given in my earlier post ‘How to move a mouse pointer automatically in Linux to simulate user activity‘.

The Lubuntu 18.04 architecture

I suspect most Lubuntu 18.04 installations are on laptops or desktop machines with a single user, i.e. single-seat, single-user installations. In such a case, unless the user has created multiple user accounts that he/she logs into concurrently (by using ‘Switch User’, for example), the machine will never suspend unexpectedly while the user is logged in and using the session. I think the way LightDM, light-locker, systemd-logind and Xfce Power Manager have been bundled in Lubuntu 18.04 to manage suspending to RAM is a dog’s breakfast. The design apparently does not take into consideration that different people could be logged in concurrently in a single-seat installation. Try forcing people to log off so that only one person is ever logged in — it won’t happen! To be interrupted by Suspend to RAM triggered by Xfce Power Manager due to inactivity in a different session is illogical; the system should not suspend when someone is actively using the system. Therefore, in my opinion, management of suspension (and hibernation) ought to be configured and managed system-wide, not on a per-user basis, and a design should not require users to hack the installation to the extent I have described above. I was ‘scratching an itch’, but users should not have to jump through hoops to get an installation to function in a sensible manner. For all I know there may be a simpler way of achieving the functionality in Lubuntu 18.04 that I have described in this post and my previous post, but, if there is, it is not obvious. LightDM, light-locker, systemd and Xfce Power Manager are developed by different people, and functionality such as suspension and hibernation does not seem to have been considered using ‘helicopter vision’. Designing disparate applications developed separately to work together holistically is not a trivial task.

Anyway, hopefully I have fixed the problem and also ‘scratched my itch’. No more unexpected suspensions while I am using the family desktop machine!

How to make LightDM suspend to RAM automatically from the login screen and lock screen in Lubuntu 18.04

My family’s desktop machine has Lubuntu 18.04 installed, which generally works well. Each family member has their own account, therefore the installation is a single-seat, multi-user system. Lubuntu 18.04 uses LightDM for the display manager, light-locker (which uses LightDM) for the screen locker, and Xfce Power Manager for power management. Xfce Power Manager enables each user to specify for their session that the machine will suspend to RAM, and to configure the duration of inactivity in their session that will trigger suspension.

However, a couple of things about this arrangement are annoying. Firstly, if two or more users happen to be logged-in simultaneously because a family member does not bother to log out, Xfce Power Manager in an inactive session will eventually suspend the machine even when another user is actively using a different session. Secondly, if nobody is logged-in and the LightDM greeter screen is displayed, the machine will not suspend to RAM automatically after a period of inactivity. The only way to get the machine to suspend to RAM if nobody is logged-in is to click on the power indicator in the greeter’s system tray and select ‘Suspend’ from the drop-down menu.

I still have not figured out how to fix the first of the above-mentioned problems, but a Web search finally turned up a fix for the second problem: a post by Linux user boyi in Arch Linux Forums thread ‘need lightdm to suspend system‘. Below I explain how I implemented this in my family’s Lubuntu 18.04 installation. Basically, when the LightDM greeter screen is displayed LightDM runs a looping shell script (lightdm_sleep.sh) that will suspend the machine after a specified time has elapsed, and either logging in or unlocking the screen will run another shell script (lightdm_kill_sleep.sh) that kills the first script. Once a user has either logged in or unlocked the screen, Xfce Power Manager in that user’s session takes over monitoring activity.

1. Pre-existing situation
When I originally installed Lubuntu 18.04 I made sure each user used the Xfce Power Manager GUI to configure suspension to RAM. Each user’s own settings are shown below:

user $ cat ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-power-manager.xml
<?xml version="1.0" encoding="UTF-8"?>

<channel name="xfce4-power-manager" version="1.0">
  <property name="xfce4-power-manager" type="empty">
    <property name="power-button-action" type="uint" value="3"/>
    <property name="show-tray-icon" type="bool" value="true"/>
    <property name="brightness-switch-restore-on-exit" type="int" value="1"/>
    <property name="brightness-switch" type="int" value="0"/>
    <property name="presentation-mode" type="bool" value="false"/>
    <property name="inactivity-on-ac" type="uint" value="30"/>
    <property name="blank-on-ac" type="int" value="10"/>
    <property name="dpms-on-ac-sleep" type="uint" value="0"/>
    <property name="dpms-on-ac-off" type="uint" value="0"/>
    <property name="brightness-on-ac" type="uint" value="9"/>
    <property name="lock-screen-suspend-hibernate" type="bool" value="true"/>
    <property name="logind-handle-lid-switch" type="bool" value="false"/>
    <property name="dpms-enabled" type="bool" value="false"/>
    <property name="general-notification" type="bool" value="true"/>
    <property name="sleep-button-action" type="uint" value="3"/>
    <property name="hibernate-button-action" type="uint" value="3"/>
  </property>
</channel>

Note that each user must not edit their file ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-power-manager.xml directly, as the properties in the Xfce Power Manager settings GUI will not be updated if they do. Users must either use the Xfce Power Manager settings GUI or use xfconf-query commands on the command line as explained on the askubuntu Web page ‘Change xfce4-power-manager option from terminal‘.

The LightDM configuration files in /etc/lightdm/lightdm.conf.d/ were as follows:

user $ ls /etc/lightdm/lightdm.conf.d/
05_lubuntu.conf  10_lubuntu.conf  unmount_FREECOM_HDD.sh

The file 05_lubuntu.conf was installed when I installed Lubuntu 18.04. The two files 10_lubuntu.conf and unmount_FREECOM_HDD.sh were previously created by me in order to unmount a permanently-connected external USB HDD when a user logs out, to avoid an access problem when another user logs in (see an earlier blog post).

user $ cat /etc/lightdm/lightdm.conf.d/10_lubuntu.conf
[Seat:*]
session-cleanup-script=/etc/lightdm/lightdm.conf.d/unmount_FREECOM_HDD.sh

2. Modifications to enable installation to suspend when no user is logged in

2.1 Specify the scripts

user $ cd /etc/lightdm/lightdm.conf.d/
user $ sudo nano 10_lubuntu.conf
user $ cat 10_lubuntu.conf 
[Seat:*]
greeter-setup-script =/etc/lightdm/lightdm.conf.d/lightdm_sleep.sh
session-setup-script=/etc/lightdm/lightdm.conf.d/lightdm_kill_sleep.sh
session-cleanup-script=/etc/lightdm/lightdm.conf.d/unmount_FREECOM_HDD.sh

2.2 Create the two scripts

user $ sudo nano lightdm_sleep.sh
user $ sudo chmod +x lightdm_sleep.sh
user $ cat lightdm_sleep.sh 
#!/bin/sh
file="/tmp/unique_identifier"
(while true; do sleep 30m; systemctl suspend; done) &
echo $! > $file
user $ sudo nano lightdm_kill_sleep.sh
user $ sudo chmod +x lightdm_kill_sleep.sh
user $ cat lightdm_kill_sleep.sh 
#!/bin/sh
file="/tmp/unique_identifier"
if [ -f "$file" ]
then
    kill `cat $file`
    rm $file
fi

2.3 Modify the existing session cleanup script to include the lightdm_kill_sleep.sh code

user $ tail -n 11 unmount_FREECOM_HDD.sh
################################################
# Code below copied from lightdm_kill_sleep.sh
file="/tmp/unique_identifier"
if [ -f "$file" ]
then
    kill `cat $file`
    rm $file
fi
# End of code copied from lightdm_kill_sleep.sh
################################################
exit 0

Of course, specifying lightdm_kill_sleep.sh would have sufficed if the installation did not already have a session cleanup script:

user $ cat 10_lubuntu.conf
[Seat:*]
greeter-setup-script =/etc/lightdm/lightdm.conf.d/lightdm_sleep.sh
session-setup-script=/etc/lightdm/lightdm.conf.d/lightdm_kill_sleep.sh
session-cleanup-script=/etc/lightdm/lightdm.conf.d/lightdm_kill_sleep.sh

3. Summary
Thus the file situation is now as follows:

user $ ls /etc/lightdm/lightdm.conf.d/
05_lubuntu.conf  10_lubuntu.conf  lightdm_kill_sleep.sh  lightdm_sleep.sh  unmount_FREECOM_HDD.sh
  • If nobody logs in after booting the machine, the machine will suspend to RAM after 30 minutes* due to greeter-setup-script.
  • If a user logs in, session-setup-script ensures only Xfce Power Manager controls suspension to RAM while the LightDM greeter screen is not displayed.
  • If a user logs out and no other user is logged in, the machine will suspend to RAM after 30 minutes* due to greeter-setup-script.
  • If a user locks the screen, the machine will suspend to RAM after 30 minutes* due to greeter-setup-script.

*Obviously the period of inactivity to trigger suspension to RAM can be configured by changing the time specified in the lightdm_sleep.sh script.

50th anniversary of Apollo 11

I recall watching on live TV in 1969 Neil Armstrong stepping onto the Moon for the first time. I still think the Apollo programme is mankind’s greatest technological achievement to date, especially taking into account the state of the art in the 1960s, albeit massive funding, around 400,000 professionals and some 5,000 companies working on the project helped immensely.

If you have a technical background and are interested in learning a bit about the technical aspects of the equipment and the mission, I can recommend W. David Woods’ book ‘How Apollo Flew to the Moon’. I found the sections on guidance particularly interesting. The book even addresses eating, ablution, urinating, defecating and waste disposal on the journey.

On the 40th anniversary of Apollo 11 I wrote a short post in the Sabayon Linux forums on using Audacity to analyse the recording of Neil Armstrong’s famous “One small step”, which I refreshed in this blog for the 42nd anniversary (see One small step for [a] man… revisited using Audacity).

To mark the 50th anniversary of the launch of Apollo 11, on 16 July this year I went to the cinema to watch the Todd Douglas Millar’s documentary ‘Apollo 11’ (see Apollo 11 [Official Trailer]), which has received good reviews due to its use of 65mm and 70mm footage. Actually, although I very much enjoyed it, quite a lot of the footage used is not 65mm or 70mm, and I found the soundtrack too loud, often making it difficult for me to make out what the controllers and astronauts said. Anyway, if you have not been to see it, I can still recommend it.

This week the UK TV channel BBC Four showed the US PBS (Public Broadcasting Service) excellent multi-part documentary ‘Chasing the Moon‘, which I found riveting. In fact, I much preferred it to Todd Douglas Millar’s ‘Apollo 11’, although the two documentaries are different animals and not really directly comparable. Anyway, if you are interested in the US-USSR space race, the internal politics behind the Apollo programme, and the Mercury, Gemini and Apollo programmes, I can thoroughly recommend ‘Chasing the Moon’, which is to be released shortly on DVD if you do not have the chance to catch it on TV or to stream it. I found the comments by Sergei Krushchev (the son of Nikita Khrushchev) particularly interesting, especially his mention about the hushed-up death of a Soviet cosmonaut in a fire during a test with a pure-oxygen environment prior to the Apollo 1 accident. If the Americans had known about this, it might have prevented the equally gruesome deaths of Grissom, White, and Chaffee in 1967.

YouTube is a gold mine if you are interested in old and newer films, documentaries and vlogs on the Apollo programme. There are hundreds of videos about it. If you are a computer buff, the videos on the AGC (Apollo Guidance Computer) are fascinating. The recent series of videos on the restoration to working condition of a privately-owned scrapped AGC are fascinating. Below are a few of the documentaries and videos I have watched this week to celebrate the 50th anniversary of Apollo 11. I have included links to a couple of the videos in the above-mentioned series on restoration of an AGC; you will be able to find the others in the series if you are interested.

  1. Chasing the Moon
  2. Spacecraft Films The Mighty Saturns Part I The Early Saturns
  3. Spacecraft Films The Mighty Saturns Part II The Saturn V
  4. Moon Machines: Command Module (2/6)
  5. Moon Machines: Navigation Computer (3/6)
  6. Moon Machines: Lunar Module (4/6)
  7. MIT Science Reporter – Computer for Apollo (1965)
  8. MIT Science Reporter – Landing on the Moon (1966)
  9. MIT Science Reporter – Returning from the Moon (1966)
  10. MIT Science Reporter – Food For Space Travelers (1966)
  11. The Real Story Behind the Apollo 11 Computer Error | WSJ
  12. The Journeys of Apollo
  13. The Apollo 4 Mission (1967)
  14. The Flight Of Apollo 7 (1968)
  15. Apollo 8 – Go For TLI (1969)
  16. Apollo 10 – To Sort Out The Unknowns (1969)
  17. Apollo 11 Saturn V Launch Camera E-8
  18. Restored Apollo 11 Moonwalk – Original NASA EVA Mission Video – Walking on the Moon
  19. Moon in Google Earth – Apollo 11 Landing
  20. Hear Buzz Aldrin tell the story of the first moon landing
  21. NASA: Moon Landing – Apollo 11 Descent Film and LRO [Lunar Reconnaissance Orbiter] Imagery
  22. Apollo 11: The Complete Descent
  23. Why were there missing rungs on the Lunar Lander’s Ladder?
  24. Apollo AGC Part 1: Restoring the computer that put man on the Moon
  25. Apollo AGC Part 23: Flying realistic Apollo 11 moon landings with the Apollo Guidance Computer
  26. An Audience with Neil Armstrong (2011 interview)
  27. Apollo 11 crew member [Buzz Aldrin]
  28. WATCH: Astronaut Michael Collins discusses the Apollo 11 launch 50 years later
  29. Apollo’s Most Important Discovery (Inside NASA’s Moon Rock Vault!)
  30. Where does NASA keep the Moon Rocks? – Smarter Every Day 220
  31. APOLLO MOON SUIT: demonstration of functioning, and manufacturing (1969)
  32. Moon Machines: Space Suit (5/6)
  33. The Space Suit Special

Conspiracy theories and their debunking

  1. NASA: Moon Landing – Apollo 11 Descent Film and LRO [Lunar Reconnaissance Orbiter] Imagery
  2. Moon-Landing Hoax Still Lives On, 50 Years After Apollo 11. But Why?
  3. Apollo and the moon-landing hoax
  4. Moon landing conspiracy theories – Hoax claims and rebuttals
  5. A Brief History of Moon Hoaxes – Why do people still believe in them?
  6. Why Faking the Moon Landing Was Impossible
  7. Debunking the Myth that the Moon Landing Was a Hoax
  8. Nvidia Debunks Conspiracy Theories About Moon Landing
  9. Moon Hoax: Debunked!
  10. The Space Suit Special

The USSR

And, finally, these videos about the USSR’s failed attempt to put a man on the Moon are worth watching:

  1. Why Russia Did Not Put a Man on the Moon – The Secret Soviet Moon Rocket
  2. Soviet N1 Moon Rocket Documentary

Amazing that the NK-33 closed-cycle engines originally developed for the N1 were purchased by a US company, modified and finally used in a new launcher in 2013. The later and larger RD-180, also a Russian closed-cycle engine, is – if I understand correctly – still used to power US Atlas rockets until US-designed replacements are available.

Why I switched from WhatsApp to Signal

I had avoided WhatsApp until late 2017 when one of my family installed it on my phone with the promise I would find it useful to keep in touch during a two-month work trip. Actually, it turned out to be more useful for work, as WhatsApp is the preferred method of communication at the company I visited on that trip.

Now, I was aware that Facebook acquired WhatsApp in 2014 for US$19 billion. I do not have a Facebook account and have no intention of getting one, and the fact Facebook owns WhatsApp was one of the reasons I had been reluctant to install WhatsApp in the first place. However, it didn’t take me long to like WhatsApp. The UI is very well designed, the functionality excellent and WhatsApp Web is easy and convenient to use. WhatsApp is a polished product, no doubt about that. The end-to-end encryption of WhatsApp messages is comforting, although that was not my main reason for using it. Offhand I can only think of one function I find annoying in the WhatsApp UI: when you forward a message containing an image, there is no automatic way to include the text accompanying the original message.

Recently I have read several articles stating that Facebook intends to display advertising in WhatsApp from 2020 onwards. I am sick and tired of ‘surveillance capitalism‘ tracking me and bombarding me with advertising on the Web, and this news prompted me to search for a replacement for WhatsApp. A newspaper article mentioned Signal, which I learned happens to be the source of the encryption protocol used by WhatsApp. I also learned that WhatsApp co-founder Brian Acton, who left Facebook in 2017, is Executive Chairman of the Signal Foundation, which he co-founded with the creator of Signal in 2018. So I decided to give Signal a try, and was pleasantly surprised as the UI is very similar to WhatsApp. OK, it’s not quite as polished aesthetically, but it was easy to use from the get-go.

I initially found Signal’s security-related functionality confusing. I was not sure what the so-called ‘Safety Number‘ per contact does. It turns out that you can ensure your connection with a given contact is secure by ‘verifying the Safety Number’ with that contact. From then onwards ‘Verified‘ will appear next to the contact’s name and phone number at the top of the conversation window. Verifying the Safety Number is optional, which was not clear to me initially. Each contact’s Safety Number is actually a 3 x 4 table of 5-digit numbers. You should compare the Safety Number in your app with the Safety Number in your contact’s app in a way that prevents someone intercepting you both; you can either scan a QR Code or make a visual or audible comparison of the Safety Number in your app with the Safety Number in your contact’s app. If both Safety Number tables match, you can both click on ‘Mark as verified’ in your app. The app will then warn you if a safety number has been changed because someone is intercepting your conversation (a so-called ‘man-in-the-middle’ attack).

The other security-related function I found confusing initially is resetting a session (‘Settings’ > ‘Reset session’). It is normally not necessary for you to touch this, but, if for some reason the encryption keys between two contacts no longer match (the Signal app would notify you if that occurs), either party can reset their session and force Signal to negotiate a new session.

Unlike WhatsApp, Signal does not have a Web browser UI to use on desktop machines. It used to have such an interface (using Google’s Chrome browser) but now there is a Signal desktop app instead, with versions available for Windows, Mac OS and Linux. I have Gentoo Linux on my laptops and Lubuntu Linux on the family desktop, so I have installed the Linux desktop Signal app on those machines.

Unlike WhatsApp, the phone app and the desktop app do not sync earlier messages. By this I mean that, if you install the desktop app and launch it, you will not see any earlier messages that are visible in the phone app. Similarly, if you delete a message in the phone app it will not be deleted in the desktop app, and vice versa. This is a bit of a nuisance, but is OK once you get used to it. Perhaps this has been done with security as well as storage capacity in mind; Signal stores as little of your data as possible on its servers.

Below are a few aspects of Signal functionality that I prefer over WhatsApp:

  • In the phone app it is possible to set the colour of the background (‘wallpaper’) for contacts, not just the top-level page. Thus I have made the background black for contacts to help a little to conserve the phone’s battery charge.
  • When I forward a message that includes an image, Signal includes the original text as well as the image. Further more, it gives me the opportunity to edit the message text before actually forwarding the message.
  • When I forward a message containing an image, the whole image is displayed. For example, recently someone sent me a WhatsApp message containing a cartoon which I did not understand; I did not realise there was a caption until I tapped on the image to expand it. When I forwarded the message to a Signal contact (by selecting the message in WhatsApp and tapping the Share icon), the caption at the bottom of the cartoon was visible in the resulting Signal message without needing to tap on the image.
  • The Signal phone app lets you disable link previews (a.k.a. ‘URL previews’) easily in Settings, whereas you cannot disable link previews in WhatsApp (see Should WhatsApp let you disable URL previews?).
  • Signal allows you to specify a message lifetime (‘Disappearing messages’). You can specify that messages will never be deleted automatically, or will be deleted after a certain time has elapsed (user-selectable from 5 seconds up to 1 week).
  • Although WhatsApp uses Signal’s encryption technology, unlike Signal it does not encrypt backups.
  • Unlike WhatsApp, Signal does not store message metadata.
  • Signal is fully open-source (and free of charge, with a promise of no advertising). WhatsApp is closed-source.
  • The icons of contacts are obtained from your phone’s contact list, not specified within the app itself. Some of my WhatsApp contacts have not bothered to create an icon in WhatsApp, but I had set up an icon for them in my phone’s contact list, and that icon is used in Signal.

Below are a few aspects of WhatsApp functionality that I prefer over Signal:

  • Signal has the ability to show link previews for a few Web sites (currently for Imgur, Instagram, Reddit, and YouTube only), whereas WhatsApp shows them for all sites. (From a security perspective some people might regard this as a disadvantage of WhatsApp.)
  • I prefer the white/green ticks in WhatsApp to the unfilled/filled circles with ticks in Signal, but that is purely an aesthetic opinion.
  • WhatsApp syncs all messages between the phone app and the Web UI, not just new messages, whereas Signal just syncs the messages sent and received since you installed the desktop app. (From a Security perspective some people might regard this as an advantage of Signal over WhatsApp.)

Conclusion

In general I find Signal as good as WhatsApp, if not better. I had been worried I would not find an alternative to WhatsApp that is as easy to use and as intuitive. In fact Signal is very good, and, once you understand the security features I mentioned above, it is essentially the same as WhatsApp, which was a relief to me as I like the general concept of the WhatsApp UI.

At the moment I am having to use both WhatsApp and Signal because some of my contacts only use WhatsApp, but I have already persuaded some contacts to switch to Signal and I anticipate more will migrate to Signal once WhatsApp begins displaying adverts next year.

How to chroot in Sabayon Linux

Example 1: Sabayon Linux was installed in conventional partitions

Let’s say, for example, that the installation has three partitions: /dev/sda1 (EFI System Partition formatted with FAT32); /dev/sda2 (root partition formatted with ext4); /dev/sda3 (linuxswap). Modify the mount command below accordingly if the root directory is on a different partition. In this example, /boot is on the same partition as root (/) and therefore does not need to be mounted separately.

Boot a Sabayon Linux LiveDVD or LivePenDrive, open a terminal window and enter the following commands:

sabayonuser@sabayon ~ $ su
sabayon sabayonuser # fdisk -l # Ascertain the partitioning scheme.
sabayon sabayonuser # mkdir /mnt/mychroot
sabayon sabayonuser # mount /dev/sda2 /mnt/mychroot
sabayon sabayonuser # mount --rbind /dev /mnt/mychroot/dev
sabayon sabayonuser # mount --make-rslave /mnt/mychroot/dev
sabayon sabayonuser # mount -t proc /proc /mnt/mychroot/proc
sabayon sabayonuser # mount --rbind /sys /mnt/mychroot/sys
sabayon sabayonuser # mount --make-rslave /mnt/mychroot/sys
sabayon sabayonuser # mount --rbind /tmp /mnt/mychroot/tmp
sabayon sabayonuser # chroot /mnt/mychroot /bin/bash
sabayon / # source /etc/profile
sabayon / # env-update
>>> Regenerating /etc/ld.so.cache...
sabayon / # export PS1="(chroot) $PS1"
(chroot) sabayon / # 

Now you can enter whatever commands you want in the chrooted environment. When you have finished, exit the chroot as follows:

(chroot) sabayon / # exit
exit
sabayon sabayonuser # umount -R /mnt/mychroot/tmp /mnt/mychroot/sys /mnt/mychroot/proc /mnt/mychroot/dev /mnt/mychroot
sabayon sabayonuser # shutdown -h now

Example 2: Sabayon Linux was installed in a logical volume

Let’s say, for example, that the installation has three partitions: /dev/sda1 (EFI System Partition formatted with FAT32); /dev/sda2 (/boot partition formatted with ext4); /dev/sda3 as the LVM Physical Volume with Volume Group sabayon_sabayon containing Logical Volumes root (formatted as ext4) and swap (linuxswap). Modify the mount commands accordingly if the structure is different in your case. In this example, /boot is not on the same partition as root (/) and therefore needs to be mounted separately.

Boot a Sabayon Linux LiveDVD or LivePenDrive, open a terminal window and enter the following commands:

sabayonuser@sabayon ~ $ su
sabayon sabayonuser # fdisk -l # Ascertain the partitioning scheme.
sabayon sabayonuser # pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda3
  VG Name               sabayon_sabayon
  PV Size               39.31 GiB / not usable 2.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              10064
  Free PE               1
  Allocated PE          10063
  PV UUID               489QRE-rvgD-JUXz-ZYad-1DM7-XNwr-lDFVNw

sabayon sabayonuser # vgdisplay
  --- Volume group ---
  VG Name               sabayon_sabayon
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               39.31 GiB
  PE Size               4.00 MiB
  Total PE              10064
  Alloc PE / Size       10063 / 39.31 GiB
  Free  PE / Size       1 / 4.00 MiB
  VG UUID               oZ2s2c-fm35-VBCT-ef3i-n8OJ-79a2-IOJ5iW

sabayon sabayonuser # lvdisplay
  --- Logical volume ---
  LV Path                /dev/sabayon_sabayon/swap
  LV Name                swap
  VG Name                sabayon_sabayon
  LV UUID                dNoMjX-yv7i-3UVR-vG2s-jsJG-PHfX-BvCYs9
  LV Write Access        read/write
  LV Creation host, time sabayon, 2018-01-05 22:55:16 +0000
  LV Status              available
  # open                 0
  LV Size                2.00 GiB
  Current LE             512
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           251:0
   
  --- Logical volume ---
  LV Path                /dev/sabayon_sabayon/root
  LV Name                root
  VG Name                sabayon_sabayon
  LV UUID                Lf81Ni-LfMu-Pifu-UUzl-ypKK-xSUc-pPfawz
  LV Write Access        read/write
  LV Creation host, time sabayon, 2018-01-05 22:55:17 +0000
  LV Status              available
  # open                 0
  LV Size                37.31 GiB
  Current LE             9551
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           251:1

sabayon sabayonuser # pvscan
File descriptor 16 (socket:[30370]) leaked on pvscan invocation. Parent PID 2635: bash
  PV /dev/sda3   VG sabayon_sabayon   lvm2 [39.31 GiB / 4.00 MiB free]
  Total: 1 [39.31 GiB] / in use: 1 [39.31 GiB] / in no VG: 0 [0   ]
sabayon sabayonuser # vgscan
File descriptor 16 (socket:[30370]) leaked on vgscan invocation. Parent PID 2635: bash
  Reading volume groups from cache.
  Found volume group "sabayon_sabayon" using metadata type lvm2
sabayon sabayonuser # vgchange -ay
File descriptor 16 (socket:[30370]) leaked on vgchange invocation. Parent PID 2635: bash
  2 logical volume(s) in volume group "sabayon_sabayon" now active
sabayon sabayonuser # lvscan
File descriptor 16 (socket:[30370]) leaked on lvscan invocation. Parent PID 2635: bash
  ACTIVE            '/dev/sabayon_sabayon/swap' [2.00 GiB] inherit
  ACTIVE            '/dev/sabayon_sabayon/root' [37.31 GiB] inherit
sabayon sabayonuser # mkdir /mnt/mychroot
sabayon sabayonuser # mount /dev/sabayon_sabayon/root /mnt/mychroot
sabayon sabayonuser # mount /dev/sda2 /mnt/mychroot/boot
sabayon sabayonuser # mount --rbind /dev /mnt/mychroot/dev
sabayon sabayonuser # mount --make-rslave /mnt/mychroot/dev
sabayon sabayonuser # mount -t proc /proc /mnt/mychroot/proc
sabayon sabayonuser # mount --rbind /sys /mnt/mychroot/sys
sabayon sabayonuser # mount --make-rslave /mnt/mychroot/sys
sabayon sabayonuser # mount --rbind /tmp /mnt/mychroot/tmp
sabayon sabayonuser # chroot /mnt/mychroot /bin/bash
sabayon / # source /etc/profile
sabayon / # env-update
>>> Regenerating /etc/ld.so.cache...
sabayon / # export PS1="(chroot) $PS1"
(chroot) sabayon / # 

Now you can enter whatever commands you want in the chrooted environment. For example:

(chroot) sabayon / # equo version
319

When you have finished, exit the chroot as follows:

(chroot) sabayon / # exit
exit
sabayon sabayonuser # umount -R /mnt/mychroot/tmp /mnt/mychroot/sys /mnt/mychroot/proc /mnt/mychroot/dev /mnt/mychroot/boot /mnt/mychroot
sabayon sabayonuser # equo version
310
sabayon sabayonuser # shutdown -h now

In the example above I have used the ‘equo version‘ command in the chroot environment and in the LiveDVD environment, simply to illustrate that the two environments are not the same. As you can see, the LiveDVD I used has the package equo-310 installed, whereas the installation on the HDD has equo-319 installed.

By the way, if using the Sabayon Linux KDE LiveDVD/LivePenDrive, I discovered that the LVM command ‘vgchange -ay‘ can be omitted if I launch the KDE Partition Manager:

sabayon sabayonuser # partitionmanager

I just look at the partitions in the KDE Partition Manager’s GUI and quit the application (‘File’ > ‘Quit’).

How to change the keymap (keyboard layout) used by the GRUB shell in Gentoo Linux

The default keymap in the GRUB shell is US English. Because Linux has not yet been booted, the GRUB keymap is not governed by the keymap for the Linux console specified in /etc/conf.d/keymaps in the case of OpenRC, or in /etc/vconsole.conf in the case of systemd. This can be inconvenient if your keyboard has a different layout and you need to use the GRUB Rescue Shell. Below I explain how I configured my Gentoo Linux installation to be able to use a different keyboard layout in the GRUB shell.

There are, however, certain limitations to the keymap in the GRUB shell. The official GRUB documentation states the following:

17.4 Input terminal

Firmware console on BIOS, IEEE1275 and ARC doesn’t allow you to enter non-ASCII characters. EFI specification allows for such but author is unaware of any actual implementations. Serial input is currently limited for latin1 (unlikely to change). Own keyboard implementations (at_keyboard and usb_keyboard) supports any key but work on one-char-per-keystroke. So no dead keys or advanced input method. Also there is no keymap change hotkey. In practice it makes difficult to enter any text using non-Latin alphabet. Moreover all current input consumers are limited to ASCII.

Note that the GRUB documentation states ‘ASCII’, not ‘Extended ASCII’. ASCII is limited to codes 000 to 127 (see the character table in e.g. http://www.asciitable.com/).

Some Linux distributions have the utility grub-kbdcomp to generate a GRUB keyboard layout file. grub-kbdcomp is simply a shell script that is a wrapper for the Debian ckbcomp utility and grub-mklayout. There is a Gentoo Portage ebuild for ckbcomp:

root # eix ckbcomp
[I] sys-apps/ckbcomp
     Available versions:  (~)1.164
     Homepage:            https://anonscm.debian.org/cgit/d-i/console-setup.git
     Description:         Compile an XKB keymap for loadkeys

However, I noticed that the latest version currently available in Debian is 1.191 (https://salsa.debian.org/installer-team/console-setup.git), so I created an ebuild ckbcomp-1.191.ebuild in a local overlay on one of my laptops running Gentoo Linux Stable Branch, and I installed ckbcomp-1.191.

# Copyright 1999-2019 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

EAPI=6

DESCRIPTION="Compile an XKB keymap for loadkeys"
HOMEPAGE="https://salsa.debian.org/installer-team/console-setup.git"

if [[ ${PV} == 9999 ]]; then
        inherit git-r3
        EGIT_REPO_URI="https://salsa.debian.org/installer-team/console-setup.git"
else
        SRC_URI="https://salsa.debian.org/installer-team/console-setup/-/archive/${PV}/${P}.tar.gz -> ${P}.tar.gz"
        KEYWORDS="~amd64"
        S="${WORKDIR}"
fi

LICENSE="GPL-2"
SLOT="0"

DEPEND=""
RDEPEND="
        dev-lang/perl:*
        sys-apps/kbd
        x11-misc/xkeyboard-config"

src_compile() {
        :
}

src_install() {
        dobin console-setup-${PV}-*/Keyboard/ckbcomp
}

I have tried the above-mentioned ckbcomp command on my PC BIOS Core i7 laptop running Gentoo Stable with OpenRC and GRUB Version 2.02-r3:

root # eix -I grub
[I] sys-boot/grub
     Available versions:  (2) 2.02-r3(2/2.02-r3)^st **9999(2/9999)^st
       {debug device-mapper doc efiemu +fonts libzfs mount multislot nls sdl static test +themes truetype GRUB_PLATFORMS="coreboot efi-32 efi-64 emu ieee1275 loongson multiboot pc qemu qemu-mips uboot xen xen-32"}
     Installed versions:  2.02-r3(2/2.02-r3)^st(02:33:36 23/03/19)(fonts nls sdl themes truetype -debug -device-mapper -doc -efiemu -libzfs -mount -multislot -static -test GRUB_PLATFORMS="pc -coreboot -efi-32 -efi-64 -emu -ieee1275 -loongson -multiboot -qemu -qemu-mips -uboot -xen -xen-32")
     Homepage:            https://www.gnu.org/software/grub/
     Description:         GNU GRUB boot loader

I used the following steps:

1. Installed sys-apps/ckbcomp.

root # emerge ckbcomp
root # eix ckbcomp
[I] sys-apps/ckbcomp
     Available versions:  (~)1.164 (~)1.191[1]
     Installed versions:  1.191[1](22:09:15 20/04/19)
     Homepage:            https://salsa.debian.org/installer-team/console-setup.git
     Description:         Compile an XKB keymap for loadkeys

[1] "local_overlay" /usr/local/portage

2. Created a new sub-directory to store the GRUB keyboard layout files.

root # mkdir /boot/grub/layouts

3. Converted the X11 keymap to the GRUB keymap. The option for ckbcomp must exist in the directory /usr/share/X11/xkb/symbols/ for this to work.

root # ckbcomp gb extd | grub-mklayout -o /boot/grub/layouts/gb.gkb
Unknown keyboard scan identifier Meta_Tab
Unknown keyboard scan identifier Meta_Tab
Unknown keyboard scan code 0x54
Unknown keyboard scan code 0x65
Unknown keyboard scan code 0x7f

I used the following commands to generate a br.gkb (Brazilian Portuguese keymap) file and a us.gkb (US English keymap) as well, as it is possible to switch keyboard layouts from the GRUB command line using the keymap command, as I show further on:

root # ckbcomp br nodeadkeys | grub-mklayout -o /boot/grub/layouts/br.gkb
Unknown keyboard scan identifier Meta_Tab
Unknown keyboard scan identifier Meta_Tab
Unknown keyboard scan identifier KP_Comma
Unknown keyboard scan identifier KP_Comma
Unknown keyboard scan identifier KP_Comma
Unknown keyboard scan identifier KP_Comma
Unknown keyboard scan code 0x54
Unknown keyboard scan code 0x65
Unknown keyboard scan code 0x7f
root # ckbcomp us | grub-mklayout -o /boot/grub/layouts/us.gkb
Unknown keyboard scan identifier Meta_Tab
Unknown keyboard scan identifier Meta_Tab
Unknown keyboard scan code 0x54
Unknown keyboard scan code 0x65
Unknown keyboard scan code 0x7f

The resulting files can be seen in the directory /boot/grub/layouts/:

root # ls -la /boot/grub/layouts
total 11
drwxr-xr-x 2 root root 1024 Apr 21 21:20 .
drwxr-xr-x 7 root root 1024 Nov 26 00:01 ..
-rw-r--r-- 1 root root 2572 Apr 21 21:29 br.gkb
-rw-r--r-- 1 root root 2572 Apr 21 21:29 gb.gkb
-rw-r--r-- 1 root root 2572 Apr 21 21:30 us.gkb

4. Append ‘GRUB_TERMINAL_INPUT=at_keyboard‘ to /etc/default/grub.

root # grep GRUB_TERMINAL_INPUT /etc/default/grub
GRUB_TERMINAL_INPUT="at_keyboard"

5. Add ‘insmod‘ and ‘keymap‘ lines to /etc/grub.d/40_custom as shown below.

root # tail -n 2 /etc/grub.d/40_custom
insmod keylayouts
keymap $prefix/layouts/gb.gkb

6. Check what locales are available for the keymap.

root # locale --all-locales | grep -i gb
en_GB
en_GB.iso88591
en_GB.utf8

7. Add ‘locale=en_GB‘ to GRUB_CMDLINE_LINUX.

root # grep locale /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="locale=en_GB i915.modeset=1 rcutree.rcu_idle_gp_delay=1 acpi_enforce_resources=lax reboot=force raid=noautodetect resume=/dev/sda2"

8. Regenerate the grub.cfg file.

root # grub-mkconfig -o /boot/grub/grub.cfg
root # grep terminal_input /boot/grub/grub.cfg
terminal_input at_keyboard
root # grep gkb /boot/grub/grub.cfg
keymap $prefix/layouts/gb.gkb
root # grep layouts /boot/grub/grub.cfg
insmod keylayouts
keymap $prefix/layouts/gb.gkb

9. If the machine uses UEFI rather than PC BIOS, update the GRUB files in the EFI directory.

root # grub-install --efi-directory=/boot/efi

10. Reboot to check if the gb keymap has been loaded for the GRUB shell.

root # reboot

When I press ‘c‘ when the GRUB menu appears, I now see the following if I press each key on the second-to-last row of keys on the keyboard:

grub> \zxcvbnm,./

That corresponds to a British English keyboard layout. As I mentioned before, due to GRUB’s limitations only standard ASCII chars are possible, so it is not possible to type characters such as é and è, or symbols such as £ and etc. on the GRUB command line, whatever the keymap.

You can tell if the GRUB keylayouts module is loaded by entering the following command on the GRUB command line:

lsmod

Below is what I then see on the screen of a PC BIOS machine running up-to-date Gentoo Linux (Stable Branch) when I press ‘c‘ when the GRUB menu is displayed.


                                                GNU GRUB  version 2.02~beta3

   Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions. ESC at any time exits.


grub> lsmod
Name    Ref Count       Dependencies
minicmd 1
gfxterm_background      1              bitmap,video,extcmd,gfxterm,bitmap_scale,video_colors
bitmap_scale    2               bitmap
video_colors    2
png     1               bitmap,bufio
bitmap  7
search  1               search_label,extcmd,search_fs_file,search_fs_uuid
search_label    2
search_fs_file  2
search_fs_uuid  2
at_keyboard     1               boot,keylayouts
keylayouts      3
gfxterm 3               video,font
all_video       1               video_cirrus,video_bochs,vga,vbe
video_cirrus    2               video_fb,pci,video
video_bochs     2               video_fb,pci,video
pci     6
vga     2               video_fb,video
vbe     2               video_fb,video
video_fb        12
font    5               video,bufio
video   24
loadenv 1               extcmd,disk
disk    2
test    1
normal  1               gettext,boot,extcmd,bufio,crypto,terminal
gzio    0
gettext 3
boot    4
extcmd  8
bufio   10
crypto  2
terminal        2
biosdisk        1
part_msdos      2
ext2    4               fshelp
fshelp  5
grub>

Shown below is what I see when I perform the following steps on the GRUB command line:

  1. press each key on the second-to-last line of keys on the keyboard and press Enter;
  2. check which GRUB terminal input module is loaded;
  3. change from the British English keyboard layout to the Brazilian Portuguese keyboard layout;
  4. press each key on the second-to-last line of keys on the keyboard and press Enter;
  5. switch back to the British English keyboard layout;
  6. press each key on the second-to-last line of keys on the keyboard and press Enter;
  7. switch to the US English keyboard layout;
  8. press each key on the second-to-last line of keys on the keyboard and press Enter;
  9. switch back to the British English keyboard layout.

In each case the output on the screen is correct for the keyboard layout selected:

grub> \zxcvbnm,./
error: can't find command `zxcvbnm,./'.
grub> terminal_input
Active input terminals:
at_keyboard
Available input terminals:
console serial_* serial
grub> keymap br
grub> \zxcvbnm,.;
error: can't find command `zxcvbnm,.;'.
grub> keymap gb
grub> \zxcvbnm,./
error: can't find command `zxcvbnm,./'.
grub> keymap us
grub> <zxcvbnm,./
error: syntax error.
error: Incorrect command.
error: syntax error.
grub> keymap gb
grub> 

There is one more caveat…

When the GRUB menu first appears at boot, the following lines are still displayed at the bottom of the GRUB menu:

   Use the ↑ and ↓ keys to select which entry is highlighted.
   Press enter to boot the selected OS, `e' to edit the commands before booting or `c' for a command-line.
The highlighted entry will be executed automatically in 4s.

However, the highlighted entry on the GRUB menu is no longer executed automatically and I have to press ENTER in order to get GRUB to boot Linux. That is not a big deal in my case.

Automatically clearing the /usr/tmp/portage directory in Gentoo Linux

Gentoo Linux has been in use for nine years on one of my old laptops. A couple of days ago I performed the usual rolling update of the installation, but the latest version of a large package that normally takes several hours to compile failed to compile due to a lack of disk space. Sure enough, the command ‘df -h‘ showed me that the root partition was full. After a little digging I discovered that the directory /usr/tmp/portage/ contained a whopping 30GB of directories and files.

Portage uses the directory /usr/tmp/portage/ as a temporary store for the package source code when merging a package. The temporary files are not deleted if a merge fails, but the emerge command should delete them on the next merge of that package. On the other hand the ebuild command does not delete the temporary files, although normally you only use the ebuild command if you are creating a manifest.

Anyway, in the nine years that Gentoo Linux has been installed on the laptop I had never bothered to check that /usr/tmp/portage/ was actually empty, and its contents had slowly increased. The cure to my immediate problem was simply to empty the directory:

root # rm -rf /usr/tmp/portage/*

I doubt the laptop would still be working by the time /usr/tmp/portage would become that full again, but the situation got me thinking: What if I were to create a script to delete the temporary directories and files in /usr/tmp/portage/ at shutdown?

Gentoo Linux on this laptop uses OpenRC so I simply created a file /etc/local.d/99delete_tmp_files_from_failed_merges.stop containing the following code:

#!/bin/bash
# If root partition is more than 90% full, delete any temporary directories and
# files that were left in /var/tmp/portage/ instead of being deleted.
#
# The root partition is on /dev/sda6 and the emerge command must not be running.
#
if [ `pgrep -c emerge` -eq 0 ] && [ `df | awk '/sda6/ {print $5}' | awk -F% '{print $1}'` -gt 90 ]; then
    rm -rf /usr/tmp/portage/*
fi

I made the script executable:

root # chmod +x /etc/local.d/99delete_tmp_files_from_failed_merges.stop

Now, if the root partition is more than 90% full when I shut down the laptop, the script will automatically empty that directory. One less thing to think about.

KDE Device Notifier work-around

KDE Device Notifier can be annoying sometimes. The problem is that clicking on the Eject icon in Device Notifier (tooltip ‘Click to safely remove this device’) both unmounts and ejects the device (two separate commands). Of course, in the case of a USB device the device remains physically connected until you pull out the USB plug. You cannot re-mount the device in KDE Device Notifier until you unplug it and plug it in again. However, there is a hack that can help somewhat, as I explain below.

Firstly, note that it is possible to mount and unmount drives by using the ‘udisksctl’ command. For example, consider one of my USB HDDs which has the label ‘USBHDD01’ (I assign a label to all HDD partitions, be they on internal HDDs or on external HDDs/pendrives). It is possible to unmount the specific USB device and remount it by using the following commands:

fitzcarraldo@clevow230ss ~ $ udisksctl unmount -b /dev/disk/by-label/USBHDD01
Unmounted /dev/sdb1.
fitzcarraldo@clevow230ss ~ $ udisksctl mount -b /dev/disk/by-label/USBHDD01
Mounted /dev/sdb1 at /run/media/fitzcarraldo/USBHDD01.

In both the above cases the USB device remains visible in Device Notifier. I have created a couple of executable Desktop Configuration Files in the directory ~/Desktop/ which I can double-click to run each of the above commands. I have given each of them an appropriate icon:

The file ~/Desktop/Mount_USBHDD01.desktop contains the following:

[Desktop Entry]
Comment[en_GB]=Mount USB HDD with label USBHDD01
Comment=Mount USB HDD with label USBHDD01
Exec=udisksctl mount -b /dev/disk/by-label/USBHDD01
GenericName[en_GB]=Mount_USBHDD01
GenericName=Mount_USBHDD01
Icon=media-mount
MimeType=
Name[en_GB]=Mount_USBHDD01
Name=Mount_USBHDD01
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=none
X-KDE-SubstituteUID=false
X-KDE-Username=fitzcarraldo

The file ~/Desktop/Unmount_USBHDD01.desktop contains the following:

[Desktop Entry]
Comment[en_GB]=Unmount USB HDD with label USBHDD01
Comment=Unmount USB HDD with label USBHDD01
Exec=udisksctl unmount -b /dev/disk/by-label/USBHDD01
GenericName[en_GB]=Unmount_USBHDD01
GenericName=Unmount_USBHDD01
Icon=media-eject
MimeType=
Name[en_GB]=Unmount_USBHDD01
Name=Unmount_USBHDD01
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=none
X-KDE-SubstituteUID=false
X-KDE-Username=fitzcarraldo

(N.B. Since I could not find a media-unmount icon, I have used the media-eject icon to represent Unmount.)

This is not perfect in the sense that the device will still disappear from Device Notifier if you click on the Eject icon in Device Notifier. But at least I can avoid doing that until I really do want to unplug the device from my laptop. In other cases I simply double-click on the Mount_USBHDD01 icon and Unmount_USBHDD01 icon on my Desktop to mount and unmount the USB device as many times as I need to.