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.

Sollte nach der Installation von xrdp die Verbindung nur als root funktionieren und für alle anderen Benutzer verweigert werden, so hilft ein Eingriff in die Datei “/etc/X11/Xwrapper.config”: In der Zeile

allowed_users=console

den Wert von “console” auf “anybody” ändern.

Nach dem Update eines Microsoft Server 2008R2 (über den Umweg Server 2012) auf Server 2016 funktionierte der Zugriff auf eine WebDAV-Ressource nicht mehr und wurde mit einem Systemfehler 67 “Der Netzwerkname wurde nicht gefunden” beendet.

net use w: https://meintollerserver /user:benutzer kennwort
Systemfehler 67 aufgetreten.

Der Netzwerkname wurde nicht gefunden.

Nachdem vor dem Update alles funktionierte, musste der Fehler irgendwo beim Client liegen und wurde zunächst in den Netzwerkeinstellungen gesucht, aber sowohl “nslookup” als auch “ping” lieferten die zu erwarteten Ergebnisse und der Internet Explorer konnte sich auch probemlos verbinden.

Letztendlich führte die Suche nach einer Lösung zum Microsoft Knowledgebase-Artikel “Using the WebDAV Redirector” und dort im Abschnitt “Troubleshooting the WebDAV Redirector” zum entscheidenden Hinweis:

When attempting to map a drive to a WebDAV site, you receive the following error:

System error 67 has occurred.

The network name cannot be found.

This can be caused by one of the following conditions:

…
You have not installed the WebDAV Redirector on your client system.

…

Beim Update wurde offensichtlich die Installation der bisher zuständigen “Desktopdarstellung” nicht in die nun zuständigen Teilpakete aufgelöst.

Nach der Installation des Features “WebDAV Redirector” über den Servermanager und einen damit verbundenen Reboot funktionierte der Zugriff auf die Quelle wieder wie erwartet.

Ablageort

Um Dateien abzulegen, hat sich das freedesktop.org-Projekt ein System von Ordnern ausgedacht, welche direkt bei der Anmeldung im “home”-Verzeichnis jedes Benutzers erzeugt werden: “Bilder”, “Dokumente”, “Downloads”, “Musik”, “Öffentlich”, “Schreibtisch”, “Videos” sowie “Vorlagen”.

Einen (oder mehrere) davon loszuwerden ist gar nicht so einfach. Löscht man einen der Ordner, meldet sich ab und wieder an, ist der Ordner wieder da. Um dieses Verhalten zu ändern, ist ein Eingriff auf Systemebene notwendig, dieser wirkt sich allerdings auf alle Benutzer und nicht nur auf den aktuell angemeldeten Benutzer aus:

Sysadmins can configure things by editing /etc/xdg/user-dirs.conf. At the moment there are only two settings, you can disable the whole thing, and you can specify the charset encoding used for filenames.

Detailliertere Konfigurationsmöglichkeiten beschreibt der Beitrag “Standard-Ordner in GNOME loswerden”.

Kopieren oder verschieben?

Beide Methoden haben ihre Vor- bzw. Nachteile: Wer die Dateien kopiert, kann jederzeit nochmal zurück zum Start und im Falle eines Falles von vorne beginnen bzw. hat immer noch ein voll funktionsfähiges Altsystem, auf dem alle Dateien vorhanden sind. Dafür fällt es schwerer, den Überblick zu behalten, ob tatsächlich alles kopiert wurde und nicht noch irgendwo in einem Ordner ein paar eigentlich benötigte Dateien vergessen wurden.

Wer verschiebt, weiss ganz sicher: was im Altsystem weg ist, ist mit an Sicherheit grenzender Wahrscheinlichkeit im neuen System gelandet. Dafür ist ab dem ersten Schritt kein einfaches “Zurück” mehr möglich, auch weil bei einem Verschiebevorgang zurück u.U. die Zugriffsberechtigungen des Windows-Systems nicht mehr rekonstruiert werden können.

Wenn genügend Platz vorhanden ist, kann natürlich auch eine Kombination der beiden Methoden eingesetzt werden: Zuerst eine Kopie der gesamten Widows-Ordnerstruktur in einem Arbeitsverzeichnis erstellen und von dort dann verschieben.

Berechtigungen

Eine Klippe bezüglich der Dateiberechtigungen ist beim Kopieren bzw. Verschieben allerdings zu umschiffen: da Windows seine Dateien innerhalb des NTFS-Dateisystems speichert und dies keinerlei brauchbaren Informationen bezüglich der unter Linux zu verwendenden Dateiberechtigungen beinhaltet, müssen diese neu erzeugt werden.

Wer die Dateien gerne grafisch kopieren möchte, öffnet hierzu Gnome-Dateien (interner Name: Nautilus) und wechselt in der linken Leiste auf “Andere Orte”. Dort findet er die Laufwerke seines Windows-Systems, welche sich mit einem Klick einbinden lassen.

Beim Kopieren haben sich die Entwickler entschieden, den neu angelegten Dateien die maximal möglichen Berechtigungen zu erteilen.

 4 drwxrwxrwx 2 andreas andreas 4096 Aug 11 15:02 'a directory'
52 -rwxrwxrwx 1 andreas andreas 1234 Aug 11 14:52 file.txt

Dies ist auf einem Einbenutzer-System kein Problem, auf einem System mit mehreren Benutzern allerdings ein potentielles Sicherheitsrisiko.

Umgehen lässt sich dies durch das manuelle Kopieren der Dateien auf der Kommandozeile:

Zuerst wird das benötigte Windows-Laufwerk manuell eingebunden und anschließend die Dateien mittels “cp”-Befehl (oder “mv”) an den neuen Ort kopiert (oder verschoben). Der “cp”-Befehl berücksichtigt hierbei die sogegannte UMask, die Berechtigungen, unter denen neue Dateien eines Benutzers standardmäßig angelegt werden sollen. Mit ein paar zusätzlichen Parametern werden die zu übertragenen Dateien dann im neuen System angelegt:

$ cp -r --no-preserve=owner,mode --preserve=timestamp /media/VonWoAuchImmer ~/ZielOrdner/