Bad defaults

In my opinion, with good defaults options aren't needed. Options in software creates complexity, as all the code paths should be equally tested.

One always hope to encounter, if not good, at least reasonable defaults, especially in consumer hardware.

This post is about bad defaults.

Seagate has decided that their line of NAS hard disks¹ needs to have a power saving feature, with two profiles enabled on the firmware as default. The first one has a default timeout of 10 seconds and a null impact on the mechanical hardware itself, as it only stops the current feeding the disc's heads. The conscious reader would have guessed that it also has negligible effects on power savings².

The second enabled profile has a timeout of 240 seconds and it's more substantial than the first one as it parks the disc's heads on the drive ramp. For the reader unfamiliar with a drive internals, it's the heads' rest location, outside the disc platters.

So if the drive is idle for more than 4 minutes, the firmware unload the heads to the drive ramp. The number of times this operation is executed is recorded under the field labeled "load/unload cycle" in the disc's SMART data tally. Usually the discs mechanics are guaranteed for half a million load/unload cycles, after few months my disk reported nearly 40000 load/unload cycles.

Not good.

It has happened before, with other manufacturers it was even worst. If I recall correctly "Western Digital" had produced in the past disks with a similar behavior and didn't provided a modified firmware but instead they offered a DOS utility that periodically wrote a sector to avoid the disc to enter idle mode. If I'm not wrong, in that specific case the disc completely spin down: maximum power savings!

Fortunately Seagate offers an utility to modify the power saving's settings, it's a command line tool called sc-powerchoice or SeaChest_PowerChoice, available only as an IA32/AMD64 executable (no sources) inside a live Linux distribution that should be flashed on a USB memory stick. Unfortunately, again, it was only distributed as a Windows executable instead of a normal disk image³.

щ(ﾟдﾟщ)

Groan.

Anyway, after extracting and locally mounting the disc image I was able to copy the "64-bit" version of the utility on my NAS and finally I was allowed to disable the second profile with:

$ sudo sc-powerchoice -d /dev/sg1 --changePower --powerMode idle_b --disableMode

where the drive path is found using the --scan option and the command to show the current configuration is:

$ sudo sc-powerchoice -d /dev/sg1 -i --showEPCSettings

End of the rant.

Testing Stretch

There was a time when I boldly used the ever changing Debian's Sid flavor, but when the last stable version was released, Debian 8 code name "Jessie", I stuck with it. It seems has been ages but it's only a couple of years. Anyway when a few days ago I've learned that Debian 9 "Stretch" had a tentative release date set for June the 17, I decided it was time to give it a spin¹.

"Stretch, the rubber purple octopus"

I'm not going to do a review, I've used it non extensively only for a couple of days and under the hood Debian looks the same. On the outside, the shipped Gnome version was released more than a year ago so it's somewhat old news, but to me it feels fresh and I definitely like the small changes to the appearance and to the environment, at least most of all.

The Bad and the Ugly

For starters, one thing I'm less happy with, was the removal of the option to associate a menu to the physical power button. Now the choices when the button is pressed are: suspend, hibernate and doing nothing.

For the interested reader I'll report below the few lines that need to be patched in the gnome-settings-daemon

--- a/data/gsd-enums.h  2016-10-08 16:08:22.000000000 +0200
+++ b/data/gsd-enums.h  2017-05-31 07:56:53.069017123 +0200
@@ -113,6 +113,8 @@
 typedef enum
 {
   GSD_POWER_BUTTON_ACTION_NOTHING,
+  GSD_POWER_BUTTON_ACTION_INTERACTIVE,
   GSD_POWER_BUTTON_ACTION_SUSPEND,
   GSD_POWER_BUTTON_ACTION_HIBERNATE
 } GsdPowerButtonActionType;
--- a/plugins/media-keys/gsd-media-keys-manager.c   2017-05-31 08:26:10.000000000 +0200
+++ b/plugins/media-keys/gsd-media-keys-manager.c   2017-05-31 07:59:22.657383132 +0200
@@ -1990,6 +1990,12 @@

         action_type = g_settings_get_enum (manager->priv->power_settings, "power-button-action");
         switch (action_type) {
+        case GSD_POWER_BUTTON_ACTION_INTERACTIVE:
+                do_config_power_action (manager, GSD_POWER_ACTION_INTERACTIVE, in_lock_screen);
+                break;
         case GSD_POWER_BUTTON_ACTION_SUSPEND:
                 do_config_power_action (manager, GSD_POWER_ACTION_SUSPEND, in_lock_screen);
                 break;

and the gnome-control-center

--- a/panels/power/cc-power-panel.c 2017-03-10 19:15:25.000000000 +0100
+++ b/panels/power/cc-power-panel.c 2017-05-31 08:41:15.447701349 +0200
@@ -2066,6 +2066,7 @@
   } actions[] = {
     { N_("Suspend"), GSD_POWER_BUTTON_ACTION_SUSPEND },
     { N_("Hibernate"), GSD_POWER_BUTTON_ACTION_HIBERNATE },
+    { N_("Interactive"), GSD_POWER_BUTTON_ACTION_INTERACTIVE},
     { N_("Nothing"), GSD_POWER_BUTTON_ACTION_NOTHING }
   };
   guint i;

to bring back the functionality.

Unfortunately, I suspect the Debian Gnome Packaging Team comprehensibly would not accept changes like the above this late in the release process.

*Shrug* I can live with a couple of custom packages.

Stale Processes

About other small problems I've found, the Gnome Online Accounts daemon, called goa-daemon, has a weird interaction with d-bus and the gnome-keyring. Basically, when a user log out, the goa-daemon is not killed² and if the same user log in again, the still running goa-daemon process couldn't contact the new instance of the gnome-keyring. This breaks the on-line calendar, the default mail client and the third party remote storage desktop integration, in other words, the cloud stops to work.

Looks like it isn't fixed upstream yet, so my workaround is to check at log-in time if the daemon is running and replace it with a new instance if true. A simple way was creating a desktop file in my ~/.config/autostart directory with the following content:

[Desktop Entry]
Name=Replace running goa-daemon
Exec=env sh -c 'pidof goa-daemon 1> /dev/null && /usr/lib/gnome-online-accounts/goa-daemon --replace'
NoDisplay=true
Terminal=false
Type=Application

My explanation above is very brief, the interested reader can check the bug #764029 filed on the Gnome bug tracking system for the gory details. The rabbit hole in this case is quite deep.

Authorizations

Another broken thing that I've found, although somewhat specific to my notebook model, was the iio-sensor-proxy happily spamming my log file with authorization errors³. I haven't exhaustively searched for a solution, but as it's related with all kinds of sensors interactions, like accelerometers, magnetometers, photodetectors and considering that I'm not interested in using the light sensor at the moment⁴, removing the iio-sensor-proxy package solved the issue.

That wasn't the only authorization error present in my logs, as I've found another one regarding lack of permissions accessing the display's ICC profile file. I don't have a solution for it yet but for my use case it's not critical and it happens only one time at the start of the session, so it can wait. Edit: relaxing the permissions of the path /var/lib/gdm3/.local/share/icc/ fixed the error.

Wayland

Even if not activated by default for the user session, Wayland/Weston is used by GDM, the Gnome log-in manager. I've tried a Wayland session once, and it seems to run without glitches on the notebook, but I'm too reliant on a couple of utilities that work only on X, xcape and libinput-gestures, so no Wayland for me yet.

With the transition to Wayland it was changed the way to enable the "tap to click" on the greeter's log-in screen, now there is a dconf Boolean key in the GDM user configuration to flip:

$ sudo su - Debian-gdm -s /bin/sh
$ export $(dbus-launch)
$ gsettings set org.gnome.desktop.peripherals.touchpad tap-to-click true

Speaking of the greeter, another thing I'm missing is the option to switch keyboard layout, and I was unable to find yet the configuration to regain the previous menu. I suspect I need to add the relevant dconf keys/values to the GDM user, if it's possible at all. Edit: in the notebook the greeter keyboard layout is set to Colemak so it's possible, if one day I'm really bored I'll try to figure out where is configured.

Anyway, having configured the keyboard with the Colemak layout and not having a simple way to switch to a different layout at log-in time, it will be a fun challenge/small deterrent for strangers.

As a side note, now on Debian the greeter starts from the first tty instead of the seventh. Color me surprised.

Boot Cosmetic

This should be filed under "yak shaving" as I was looking to force a complete blank screen during boot. I was mildly frustrated that, even if I explicitly passed the quiet option and reduced the log level, there was still a message present a boot time about the check of the system partition(s).

At first I suspected the systemd-fsckd.service, instead the culprit was the initramfs, or better the script inside the initramfs that execute the fsck command. With this knowledge, the quick fix was to appended a redirection to /dev/null after the command invocation in the /usr/share/initramfs-tools/scripts/functions file.

--- a/usr/share/initramfs-tools/scripts/functions   2017-06-02 19:01:42.459905047 +0200
+++ b/usr/share/initramfs-tools/scripts/functions   2017-06-02 19:00:58.093797696 +0200
@@ -386,7 +386,7 @@
        log_end_msg
    else
        log_begin_msg "Checking $NAME file system"
-       logsave -a -s $FSCK_LOGFILE fsck $spinner $force $fix -T -t $TYPE $DEV
+       logsave -a -s $FSCK_LOGFILE fsck $spinner $force $fix -T -t $TYPE $DEV > /dev/null
        FSCKCODE=$?
        log_end_msg
    fi

I've also removed the super annoying blinking cursor, passing the vt.global_cursor_default=0 kernel boot directive.

Hardware Obsolescence

You realize that your hardware is getting old the second time you go to boot one of your desktop computers and the BIOS's settings are reset again like the day before, and you figure out it happens because the computer motherboard's CMOS battery cell is depleted.

Looking at the bright side, this PC is so old that is not tainted by Intel's differently named backdoor tool¹, so I can blissfully ignore their latest security advisory².