Sofern ein Linux-System systemd verwendet muß zum Abgleich der Systemzeit – sofern dieses nicht als Zeitserver für andere Systeme arbeiten sollen – kein ntp mehr insalliert werden.

Es reicht die Anpassung der Datei “/etc/systemd/timesyncd.conf”

$ sudo vi /etc/systemd/timesyncd.conf

in welcher dann in der Zeile “NTP=” der gewünschte Zeitserver eingetragen wird.

[Time]
NTP=zeitserver.local
FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
RootDistanceMaxSec=5
PollIntervalMinSec=32
PollIntervalMaxSec=2048

Nach Änderung der Datei wird der Dienst “systemd-timesyncd.service” neu gestartet - das war’s.

$ sudo systemctl restart systemd-timesyncd.service

Anschließend kann die Konfiguration des Diensts mittels

$ timedatectl status
               Local time: Mo 2020-04-27 21:19:40 CEST
           Universal time: Mo 2020-04-27 19:19:40 UTC
                 RTC time: Mo 2020-04-27 19:19:40
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

überprüft werden. Wird der Status des “NTP service” als “inactive” angezeigt, so ist ein

$ timedatectl set-ntp true

notwendig, um die Synchronisation zu aktivieren. Detaillierte Informationen erhält man entweder über

$ timedatectl timesync-status
       Server: 1.2.3.4 (zeitserver.local)
Poll interval: 1min 4s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 4
    Reference: AF0149C
    Precision: 1us (-21)
Root distance: 31.249ms (max: 5s)
       Offset: -1.759ms
        Delay: 1.972ms
       Jitter: 0
 Packet count: 1
    Frequency: +17,237ppm

oder mit Hilfe von

$ timedatectl show-timesync
SystemNTPServers=zeitserver.local
FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
ServerName=zeitserver.local
ServerAddress=1.2.3.4
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=2min 8s
NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=4, Precision=-21, RootDelay=17.333ms, RootDispersion=18.478ms, Reference=AF0149E, OriginateTimestamp=Mon 2020-04-27 21:05:29 CEST, ReceiveTimestamp=Mon 2020-04-27 21:05:29 CEST, TransmitTimestamp=Mon 2020-04-27 21:05:29 CEST, DestinationTimestamp=Mon 2020-04-27 21:05:29 CEST, Ignored=no PacketCount=2, Jitter=329us }
Frequency=1353001

Vor wenigen Tagen wurde LineageOS 17.1 veröffentlicht - Zeit auf die aktuelle Version zu wechseln und hierbei gleich neue Lineage Recovery auszuprobieren. Der in LineageOS eingebaute Updater erkennt zwar, daß eine neue Version vorliegt, kann das Update aber nicht manuell durchführen.

LineageOS

Die sehr kurz gehaltene Upgrade-Doku spart leider aus, daß man das Lineage Recovery nicht wie bisher für TWRP empfohlen mittels “fastboot boot …” direkt starten kann, denn dann erscheint lediglich eine Fehlermeldung:

$ sudo fastboot boot lineage-17.1-20200418-recovery-sailfish.img
...
FAILED (remote: dtb not found)

Ein Blick in die Installations-Doku zeigt, daß die Lineage Recovery installiert werden soll:

$ fastboot flash boot lineage-17.1-20200418-recovery-sailfish.img

Anschließend kann die Recovery gestartet werden (Power & Volume down) und über die Menüpunkte “apply update” / “apply from adb” empfangsbereit gemacht werden. Die eigentliche Installation des Updates ist unspektakulär:

$ adb sideload lineage-17.1-20200418-nightly-sailfish-signed.zip

GApps (optional)

Die Dokumentation weist darauf hin, daß es wichtig ist, den Zustand bzgl. eventuell verwendeter GApps beizubehalten, d.h. wenn welche installiert waren, müssen sie vor dem ersten Start des Betriebssystems aktualisiert werden.

Hierzu wird die Recovery erneut gestartet und bereit zum Datenempfang gemacht, dann kann das Paket installiert werden.

$ adb sideload open_gapps-arm64-10.0-pico-20200418.zip

Root

Das bisher für LineageOS 16 angebotene “addonsu” ist aus technischen Gründen leider nicht mehr erhältlich

… our usual provided AddonSU zip to enable root access for the user is no longer feasible

weshalb auf Alternativen wie Magisk ausgewichen werden muss.

… if you want root for apps, flash magisk zip in recovery. Just don’t flash it during initial lineage install, as it’s known to cause bootloop if you do.

Wichtig ist, Magisk nicht zusammen mit LineageOS zu installieren, ob hier ein erneuter Start der Recovery reicht oder ein Systemstart erfolgen sollte, ist nicht ganz klar. Die Installation erfolgt analog zu LineageOS bzw. den GApps am sinnvollsten nach einem Systemstart.

$ adb sideload Magisk-v20.4.zip

Nacharbeiten

Nach der Installation kam von Magisk keine Aufforderung von AFWall+ zum Erhalt von Root-Rechten. Nach einem weiteren Reboot kam dann aber die erwartete Aufforderung.

Der Captive-Portal-Check lief trotz übernommener AFWall+-Einstellungen immer auf einen Verbindungsfehler, die Liste der Freigaben musste noch um “[1073] Network Stack, com.android.server.NetworkPermissionConfig” erweitert werden, ansonsten wurde dauerhaft das “X” beim Verbindungsstatus angezeigt und einige Apps haben erst gar nicht versucht, sich mit dem Internet zu verbinden.

Ist es ein Bug oder ein Feature? Beim Verschieben von Dateien in Ordnerstrukturen wird mitten im Drag & Drop-Vorgang nach kurzer Zeit in den Zielordner gewechselt, was gerade bei größeren Aufräumaktionen zu vielen unnötigen Mausklicks führt.

Die zuständige Funktion in Nautilus nennt sich “open-folder-on-dnd-hover” und kann mittels dconf an- und ausgeschaltet werden:

In neueren Versionen des GNOME-Desktops (ab 3.34) kann die Funktion auch direkt im “Optimierungen”-Werkzeug konfiguriert werden.

Die Heidenheimer Zeitung widmet dem “ewigen Wüterich” zum 75. Geburtstag einen eigenen Artikel …

… und gratuliert mit einem irritierenden Bild: die Haare sind deutlich zu lang und zu hell, die Gitarre zu blau und das Shirt zu neumodisch. Abgebildet ist Ritchies Nachfolger (bei Deep Purple) Steve Morse, der allerdings 1954 geboren wurde und nicht 1945.