Skip to content

Raspberry Pi - Raspbian Update auf Buster und Kioskmodus mit Chrome anpassen

Nicht nur ein neuer Raspberry Pi 4 hat vor kurzem das Licht der Welt erblickt, auch die bekannte Distribution Raspbian, welche auf den Minirechnern gerne läuft, wurde auf Debian Buster umgestellt.

Das neue Betriebssystem hat ein neues Theme erhalten und die üblichen Softwareaktualisierungen.
Nicht mehr dabei ist der Legacy Grafiktreiber Stack, dafür wurde auf Mesa V3 Treiber umgeschwenkt.
Ein Update auf die neue Version ist schnell gemacht, aber auch mir Vorsicht zu genießen, es wird eine Neuinstallation empfohlen.

raspberrypi


Update auf Raspbian (Buster)

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo sed -i 's/stretch/buster/g' /etc/apt/sources.list
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

Ich empfehle dringend ein Backup der wichtigen Daten zu ziehen.
Nach einem Testupdate konnte ich das System zwar noch booten, hatte außer einem Mauszeiger kein Bild. SSH funktionierte. Ich habe es allerdings nicht weiterverfolgt, da ich die Anzeigeneinstellungen händisch gesetzt hatte.

Da Debian Buster Tools mitbringt, welche nicht unterstützt werden, könnt ihr diese wieder deinstallieren.

sudo apt purge timidity lxmusic gnome-disk-utility deluge-gtk evince wicd wicd-gtk clipit usermode gucharmap gnome-system-tools pavucontrol


Kioskmodus unter Raspbian 

Was nach dem Update schnell klar war. Der Kiosk Modus mit Chromium ist defekt und muss repariert werden. Das geht allerdings schnell, denn es haben sich nur Pfade geändert.

Anders als noch bei den alten Raspbian Systemen ist das Verzeichnis /home/pi/.config/lxsession/LXDE-pi/autostart des Pi Nutzers nicht mehr vorhanden.
Alternativ kann einfach die globale Konfiguration unter /etc/xdg/lxsession/LXDE-pi/autostart angepasst werden, um den Vollbildmodus von Chromium 74 automatisch zu starten.

sudo nano /etc/xdg/lxsession/LXDE-pi/autostart

@lxpanel --profile LXDE-pi
@pcmanfm --desktop --profile LXDE-pi
# Bildschirmschoner deaktivieren
#@xscreensaver -no-splash
@point-rpi

@xset s off
@xset -dpms
@xset s noblank
#Autostart Chromium Vollbild-Kiosk
@chromium-browser --noerrordialogs --incognito --kiosk https://kiosk.itrig.de


 

Windows 10 bootet erst im 2. Versuch - Eine Lösung

Die Tage hatte ich ein interessantes Problem an einem Windows 10 Rechner.

Der Dell PC bootete und zeigte das Windows 10 Logo, danach passierte Nichts weiter. Der PC war mit dem Anzeigen des Windows Logos quasi eingefroren.

Nach einem harten Reset bootete der PC völlig normal und Windows zeigte nach dem Start ebenfalls keinerlei Fehler an. Dieses Spiel konnte endlich wiederholt werden.

 

Schlaflos - Der Schnellstartmodus

Die Lösung war recht schnell gefunden. Der sogenannte Schnellstartmodus hatte sich nicht mit der schon etwas älteren Hardware vertragen.

Windows 10 fährt den PC nicht mehr richtig herunter, sondern versetzt ihn nur noch in einen Ruhemodus, damit haben manche Geräte wohl ihre Probleme.

Der Schnellstartmodus lässt sich über die "Systemsteuerung --> Energieoptionen --> Auswählen, was beim Drücken von Netzschaltern geschehen soll" anpassen.

windows10-energieoptionennetzschalter-windows10schnellstart-win10

Wer sich mit den neuen Windows Menüs noch nicht zurechtfindet, der kann den Weg über die alte Systemsteuerung gehen, diese muss allerdings via Cortana gesucht oder mit "Windows Taste+Pause" (startet im Untermenü "System") aufgerufen werden, zumindest wenn das Creators Update (1703) installiert ist.

Dell OMSA - Linux Fehler - Web Oberfläche zeigt Nichts an

Beim Einsatz von Dell Servern kommt zur Verwaltung oft Open Manage Server Administrator (OMSA) zum Einsatz. 
Das Tool erlaubt es Hardware von Windows oder Linux Server komfortabel zu verwalten oder zu warten.
Bei Linux Servern kann es vorkommen, wie in diesem Fall beschrieben, dass die dazugehörige Weboberfläche "https://127.0.0.1:1311/servlet/OMSAStart" weiß bleibt.
Das heißt eine Verwaltung des Servers ist unmöglich.

omsa

Fehleranalyse

Ein Neustart mittels /opt/dell/srvadmin/sbin/srvadmin-services.sh bringt leider keine Abhilfe.

Auch eine Aktualisierung der OMSA Installation (hier am Beispiel Ubuntu) kommt dem Fehler nicht bei:


sudo nano /etc/apt/sources.list.d/linux.dell.com.sources.list

    deb http://linux.dell.com/repo/community/ubuntu precise openmanage

sudo apt-get update
 sudo gpg --keyserver hkp://pool.sks-keyservers.net:80 --recv-key 1285491434D8786F
sudo apt-get install srvadmin-all

Ein Blick in das zuständige Logfile offenbart einen XML Fehler.

cat /opt/dell/srvadmin/var/log/openmanage/dsm_om_connsvcdIO.log

    [Fatal Error] :An invalid XML character (Unicode: 0x8) was found in the element content of the document.
    [Fatal Error] :An invalid XML character (Unicode: 0x8) was found in the element content of the document.
     WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting property 'debug' to '0' did not find a matching property

Dieser Fehler führt vermutlich zum "Blank Screen" beim Aufruf.

Eine Überprüfung des zuständigen Berichts zeigt ebenfalls einen Fehler beim Parsen der Datei.


sudo /opt/dell/srvadmin/bin/omreport about

Entity: line 1: parser error : PCDATA invalid Char value 8
g><ExpressServiceCode>386774405113</ExpressServiceCode><AssetTag editable="true">
                                                                               ^

Product name : Dell OpenManage Server Administrator
Version      : 7.4.0-1
Copyright    : Copyright (C) Dell Inc. 1995-2013 All rights reserved.
Company      : Dell Inc.

Lösung

Alles spricht dafür, dass der Info Tag von diesem Fehler betroffen ist und dadurch die Datei fehlerhaft ausgelesen wird.

Dieser Tag lässt sich mit einem Befehl zurücksetzen

/opt/dell/srvadmin/bin/omconfig chassis info tag="0"

Ein Kontrolle mit "/opt/dell/srvadmin/bin/omconfig" about führt danach zu einem richtigen Ergebnis, nun sollte auch der Webservice richtig starten.

Product name : Dell OpenManage Server Administrator
Version      : 7.4.0-1
Copyright    : Copyright (C) Dell Inc. 1995-2013 All rights reserved.
Company      : Dell Inc.

[Lösung] Outlook Fehler - Standard Email Ordner kann nicht geöffnet werden oder Microsoft Outlook kann nicht gestartet werden

Heute ein kleiner Ausflug in die gemeine Office Welt. Genauer gesagt zu Microsofts Mail Client Outlook.

Der Mailclient verweigert hin und wieder den Start mit folgender Meldung:

Microsoft Outlook kann nicht gestartet werden. Das Fenster kann nicht geöffnet werden. Der Informationsspeicher steht zurzeit nicht zur Verfügung

outlook-error

oder

Ihre Standard-E-Mail-Ordner können nicht geöffnet werden. Der Informationsspeicher steht zurzeit nicht zur Verfügung

informationsspeicher-outlook

bzw.

Cannot open default e-mail folders. The information store could not be opened.

default-folder-outlook

Wobei dieser Fehler so gut wie alle Versionen betrifft. Egal ob 2007, 2010 oder 2013. Die neueste Version 2016 hab ich leider nicht prüfen können.

Die schnellste und einfachste Lösung ist es, die Outlook Verknüpfung mit dem Schalter "resetnavpane" zu starten und der Fehler  sollte behoben sein. Am Besten über Start/Ausführen aufrufen

outlook.exe /resetnavpane

[Lösung] vSphere/ESXi 6.0 U1 mit Veeam - Error: NFC storage connection is unavailable

Es ist mal wieder Zeit für einen Ausflug in virtuelle Gefilde, genauer gesagt soll es um das neueste Update aus dem Hause VMware gehen.

vSphere/Veeam - NFC storage connection is unavailable

VMware hat vor wenigen Tagen ein Update 60u1 für vCenter und ESXi Maschinen veröffentlicht (Changelog). 
Dieses bringt neben Neuerungen auch neue Probleme mit sich, so lässt sich nach einem Update auf die aktuellste Version keine virtuelle Maschine mit der Sicherungssoftware Veeam sichern, auch wenn dort die aktuellste Patch Version installiert ist. 

Die Sicherung bricht mit dem folgenden Fehler ab:

Getting VM info from vSphere
Error: NFC storage connection is unavailable. Storage: [stg:datastore-666,nfchost:host-666,conn:127.0.1.1]. Storage display name: [datastore]
Failed to create NFC download stream. NFC path: [nfc://conn:127.0.1.1,nfchost:host-667,stg:datastore-666@localhost.vmx]. 

Im Netz finden sich einige Vorschläge die dieses Problem angeblich lösen. Viele bringen den Fehler mit falschen DNS Einstellungen in Verbindung und schlagen vor alle Geräte richtig ins DNS einzutragen, bzw. die Host Datei anzupassen.
Leider beziehen sich die Lösungen oft auf ältere ESXi bzw. Veeam Versionen und führen somit nicht zum gewünschten Ziel.

veeam

Hier hilft ein Blick in die Logs der Sicherungssoftware oft weiter:

ERR |Failed to initiate NFC session. Target host: [127.0.0.1]. VI connection ID: [127.0.1.1]. Storage MOID: [datastore-666].
ERR |SSL error, code: [3368].error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
>>  |SSL_connect() function call has failed.

Der Meldung lässt sich entnehmen, dass die Verbindung an der SSL Aushandlung scheitert. Der Fehler hat somit Nichts mit DNS oder ähnlichem zu tun, es kommt schlicht keine sichere Verbindung zu Stande.


Ein weiterer Blick in den Changelog von ESXi 6.0 Update 1 zeigt folgenden Satz "Support for SSLv3: Support for SSLv3 has been disabled by default."
Das heißt, aktualisierte ESXi Hosts unterstützen dieses Protokoll in der neuesten Version nicht mehr. Das ist nicht weiter verwunderlich, denn es gilt als unsicher.

vSphere6

Leider benötigt Veeam SSLv3 weiterhin für seine Sicherungen, genauer betrifft es den Port 902. Die Funktion lässt sich über einen Eintrag in der Config wieder aktivieren. Dazu muss auf die jeweilige ESXi Maschine via SSH zugegriffen werden. Die unten erwähnte Konfigurationsdatei gilt es anzupassen.

cp /etc/vmware/config /etc/vmware/config.date
vi /etc/vmware/config
    vmauthd.ssl.noSSLv3 = false
    

Danach ist ein Neustart des Dienstes erforderlich

/etc/init.d/rhttpproxy restart 

Nach dieser Änderung sollten Sicherungen mit Veeam wieder funktionieren. Weitere Details dazu unter kb2063.