1
2

[root@vhost:~] esxcli software profile update -p ESXi-7.0U3-18644231-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
Got no data from process: LANG=en_US.UTF-8 /usr/lib/vmware/esxcli-software profile.update -d "https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml" -p "ESXi-7.0U3-18644231-standard"

Daraufhin durchsuchte ich das Netz, wobei ich auf verschiedene Dinge stieß:

• ESXi Firewall freischalten:

  1 2 3 4 5 6 7 8

  # Cut and paste these commands into an ESXi shell to update your host with this Imageprofile # See the Help page for more instructions # esxcli network firewall ruleset set -e true -r httpClient esxcli software profile update -p ESXi-7.0U3-18644231-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml esxcli network firewall ruleset set -e false -r httpClient # # Reboot to complete the upgrade

Das half bei mir leider nichts

• Locker Space freigeben  - half bei mir auch nicht
• Manuell runterladen und installieren . Das funktionierte bei mir und war auch so wie ich es in der Vergangenheit gemacht hatte.

Für die Ausführung der letzten Problemlösung muss man auf die VMWare Seite für den Download  gehen und dort das “VMware vSphere Hypervisor (ESXi) Offline Bundle” herunterladen. Dieses ZIP-File dann ohne auspacken auf einen ESXi Datastore hochladen. Nun kann man via dem folgenden Kommando (Pfad zum Zip anpassen!) den ESXi updaten:

1

esxcli software profile update -d /vmfs/volumes/5f03704a-21ed9518-823f-7085c2f2f11f/VMware-ESXi-7.0U3-18644231-depot.zip -p "ESXi-7.0U3-18644231-standard"

Dann einmal rebooten und die Sache ist gegessen. Sehr seltsamer Fehler aber wenn es sich so einfach lösen lässt will ich mich mal nicht beschweren ;)

1
2

Warning: failed to get default registry endpoint from daemon (Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.37/info: dial unix /var/run/docker.sock: connect: permission denied). Using system default: https://index.docker.io/v1/
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.

Hintergrund ist eine Neuinstallation auf einem Raspbian. Nach der Installation von docker habe ich, um die tägliche Nutzung von Docker zu vereinfachen, den Nutzer “pi” zur Gruppe “docker” hinzugefügt (sudo usermod -aG docker pi). Das erlaubt dem Nutzer die Ausführung von “docker login” beispielsweise. Wenn man dann den Meldungen nach dem Hinzufügen des Nutzers folgen würde, so taucht dieser Fehler gar nicht erst auf.

Man muss sich daher lediglich (wie gemeldet) einmal neu am Nutzer anmelden und schon ist der Fehler weg ;)

Mein letztes Problem mit Gentoo war eine neue Netzwerkkarte, nachdem die alte ein paar Macken aufwies. Die alte Onboard-Netzwerkkarte wurde entfernt und stattdessen eine “Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 0c)” als PCI-Steckkarte installiert. Natürlich musste der Kernel neu gebaut werden, die Optionen “CONFIG_EEPRO100=y” und “CONFIG_E100=y” wurden so fest in den Kernel einkompiliert.

Nach einem Reboot meldete das Syslog jedoch folgende Fehlermeldung:

1
2
3

rc-scripts: network interface eth0 does not exist
rc-scripts: Please verify hardware or kernel module (driver)
rc-scripts: ERROR: cannot start sshd as net.eth0 could not start

was mich ein wenig erstaunte, denn dmesg meldete:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin  and others
ACPI: PCI Interrupt 0000:00:08.0[A] -> GSI 16 (level, low) -> IRQ 16
eth0: OEM i82557/i82558 10/100 Ethernet, 00:03:47:B0:ED:D3, IRQ 16.
Board assembly a29355-003, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x3258698e).
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation

Diese Meldungen kommen sowohl, wenn ich mir die IP über DHCP zuweisen lassen würde (in /etc/conf.d/net eingestellt) oder fest eintrage. Ich konnte jedoch ohne Probleme mit dieser Netzwerkkarte ein Rescue-System booten und darin arbeiten, was meine Erklärung dafür war, dass warum meines Erachtens die neue Karte nicht kaputt sein konnte

Ich habe die Karte natürlich über “rc-update add net.eth0 default” zum Starten angewiesen, der Link ist auch korrekt erstellt (und hat mit der alten Karte funktioniert).

Letztendlich wusste ich nicht mehr weiter und meldete mein Problem im offiziellen Gentoo-Forum, wo mir innerhalb von wenigen Minuten geholfen werden konnte. Das Problem hätte mir auffallen müssen, als folgende Einträge im Log aufgetaucht sind:

1
2

udevd-event[5100]: run_program: exec of program '/sbin/udev_run_hotplugd' failed
udevd-event[5101]: run_program: exec of program '/sbin/udev_run_devd' failed

Das Problem war relativ einfach in den Griff zu bekommen ( Quelle ):

In der Datei /etc/udev/rules.d/70-persistent-net.rules stand bei mir folgendes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x1106:0x3065 (via-rhine)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0c:6e:92:02:aa", NAME="eth0"

# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:03:47:b0:ed:d3", NAME="eth1"

Man beachte hierbei: VIA Rhine war meine vorherige Netzwerkkarte, die e100 meine neue. Die neue Karte wurde von udev einfach als eth1 eingetragen und war daher auch nicht unter eth0 erkannt worden. Ich habe nun schlicht und einfach die alte rausgeworfen, bei e100 auch eth0 eingetragen und schon war das Problem behoben.

1
2

# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:03:47:b0:ed:d3", NAME="eth0"

Vielen Dank ans Gentoo-Forum  für den schnellen Support, vielleicht hilft dieser Post dem einen oder anderen verzweifelten Gentoo-Besitzer

Da aber beides meines Erachtens nicht zutreffen sollte, machte ich mich also auf die Suche und traf in den error-Logs des Apache2-Webservers auf folgenden Fehler:

1

[Mon May 22 10:52:42 2006] [crit] [client 123.123.123.123] (13)Permission denied: /var/www/XXX/html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable

Einige Elemente dieser Fehlermeldung sind von mir gelöscht worden

Wie sich erkennen lässt, “mault” der Apache wegen einer .htaccess, die seines Erachtens nicht lesbar ist. Nun habe ich also eine solche überhaupt nicht in diesem Verzeichnis, was seltsam war. Ich habe dann eine .htaccess angelegt, die einfach mal testweise auf “chmod 777” gesetzt, der Fehler ist jedoch trotzdem nicht verschwunden.

Nach einer intensiven Befragung von Google bin ich schlussendlich darauf gekommen, dass es ein rechte Problem zu sein scheint. Apache hat nur schlicht und einfach keinen Zugriff auf das GANZE verzeichnis gehabt. Nach einem Vergleich mit dem Verzeichnis einer anderen Domain und der anschließenden neuen Rechtevergabe funktionierte wieder alles so, wie es sollte. Es waren wohl aus Versehen falsche Benutzerrechte gesetzt worden.

Ob der Apache auf ein Verzeichnis zugreifen kann, lässt sich sehr schnell und unkompliziert feststellen:

1

su - www-data -s /bin/bash -c "cd /var/www/XXX/html; ls -la"

Wenn der Befehl ein “Permission denied” ausgibt, dann hat der Webserver definitiv keinen Zugriff auf das Verzeichnis. “www-data” ist hierbei der Nutzer des Webservers, und “/var/www/XXX/html” das verzeichnis.

Vielleicht hilfts ja jemandem bei der Fehlersuche :)

1 Blinken: Keine Displayanzeige, Keine Sprachausgabe

• Öffne das Batteriefach
• Entferne die Batterie und stelle sicher, dass sich im Batteriefach keine Fremdkörper (Staub, Krümel, usw) befinden, die den Kontakt stören könnten
• Lege die Batterie wieder ein und schließe das Fach. Stelle sicher, dass alle Schrauben wieder angezogen werden.
• Wenn Schrauben fehlen sollten, fordere diese bei iRobot an
• Wenn eine der Schrauben sich nicht mehr anziehen lassen sollte, so kann ein Austausch des Roomba notwendig sein
• Ersetze die Batterie falls das Problem weiter besteht

2 Blinken: Display zeigt “Err 2” an und Sprachausgabe sagt “Charging Error 2”

• Ersetze den Roomba, die Stromversorgung oder die Ladeschale

3 Blinken: Display zeigt “Err 3” an und Sprachausgabe sagt “Charging Error 3”

• Ersetze den Roomba, die Stromversorgung oder die Ladeschale

5 Blinken: Display zeigt “Err 5” an und Sprachausgabe sagt “Charging Error 5”

• Ändere die Ladeumgebung zu einem kühleren Ort
• Ersetze das Netzteil

6 Blinken: Display zeigt “Err 6” an und Sprachausgabe sagt “Charging Error 6”*

• Ändere die Ladeumgebung zu einem kühleren Ort und stelle sicher, dass nichts auf dem Roomba liegt
• Ersetze das Netzteil
• Ersetze die Batterie
• Ersetze die Ladestation
• Ersetze den Roomba

7 Blinken: Display zeigt “Err 7” an und Sprachausgabe sagt “Charging Error 7”

• Ersetze die Batterie
• Ersetze den Roomba

( Quelle )

Dieser Modus ist hier  beschrieben.

Zunächst muss man den Roomba ausschalten, indem man “Clean” für ein paar Sekunden drückt. Nun gibt es entweder die Möglichkeit die Diagnose Automatisch oder Manuell ablaufen zu lassen.

Mobility Test: Für die automatische Diagnose drückt man neun-mal, für die manuelle zwölf-mal den “Spot” Button. Ich habe mich wie auch im Beitrag für die zwölf Mal entschieden. In diesem Modus kann man dann mittels “Dock” zum nächsten Test wechseln.

Built-In Test Für die automatische Diagnose drückt man drei-mal, für die manuelle sechs-mal den “Spot” Button. Ich habe mich wie auch im Beitrag für die sechs Mal entschieden. In diesem Modus kann man dann mittels “Dock” zum nächsten Test wechseln.

Die dann folgenden Tests lassen sich gut im Service Manual nachlesen, was es vor langer Zeit mal auf der iRobot-Seite zum Download gab (Über verschiedene Foren  und private Nachrichten bin ich nochmal dran gekommen und habe es bei mir hochgeladen). Bitte lese dort im Anhang A die einzelnen Tests und die Aktionen (aufgrund des jeweiligen Ergebnisses) nach dem Roomba_500_Series_SERVICE_Manual dokument.

Letztendlich habe ich so herausgefunden, dass die Elektronik an sich in Ordnung ist und dass ich mich der Mechanik des linken Rades zuwenden müsste. Na wenn es nur das ist ;) Denn die Elektronik im Bumper zu tauschen ist kein Spaß  ;)

Das geht eigentlich ganz einfach: Halte die Buttons “Spot” und “Dock” für rund 15 Sekunden. Das wird den Roomba komplett neu starten.

Hatte mein Problem nicht behoben, aber immerhin eine Möglichkeit ausgeschlossen ;)

• USB 3.0 wird nicht unterstützt
• WWAN Modul wird nicht gefunden
• 2. DVI/DisplayPort-Ausgang funktioniert nicht all dies sind Symptome für falsche Treiber, die sich das Gerät gezogen hat.

Das automatische Zuweisen von Treibern ist zwar praktisch, aber eben nicht sehr zuverlässig. Der Schlüssel zum Erfolg liegt meines Erachtens nach darin, auf das automatische Zuweisen von Treibern vollständig zu verzichten. Stattdessen empfehle ich, den Treiber gezielt in der Tasksequence zuzuweisen.

Wie das geht, ist recht einfach, wenn man einige kleine Kniffe beachtet. Der Reihe nach:

• Download des SCCM-Treiberpaketes von Lenovo  für die korrekte OS-Version (in meinem Beispiel w7 x64)
• Extrahieren des Treibers und Kopieren auf ein für den SCCM zugängliches Netzwerk-Share, z.B. das ProdShare. Ich empfehle, dort einen Order Namens “for-Import” zu erstellen, um die Übersicht zu wahren.
• Import Driver Wizard des SCCM starten, den UNC-Path zu den Treibern angeben. Hierbei folgende Optionen angeben:
  • Ein neues Treiber-Paket für das Model+OS-Version erstellen, also z.B. “Lenovo T450 w7x64”
  • Eine neue Kategorie für die Hardware erstellen, also z.B. “Lenovo T450”
  • WICHTIG: Treiber NICHT zum Boot-Image hinzufügen. Die Netzwerkkarte wird bereits vom Boot-Image unterstützt und braucht keine weiteren Treiber. Ein Hinzufügen zum Boot-Image bläht das Boot-Image nur unnötig auf und verursacht häufig Kompatibilitätsprobleme mit anderen Computern, die ja normalerweise auch das gleiche Boot-Image verwenden.
  • Distribution Points noch nicht updaten
  • Import starten
• Nach dem Import sollten die Treiber zunächst kontrolliert werden.

Ich habe persönlich schlechte Erfahrungen mit den Virtual Network Adaptern von Intel gemacht und kenne keinen Anwendungsfall für selbige. Aus diesem Grund lösche ich diesen:

Außerdem können bei Bedarf noch Treiber von nicht verwendeten Modellen gelöscht werden, in meinem Fall sind das die NVidia-Treiber, da ich keine Konfiguration mit Nvidia-Grafikkarte verwende.

Achtung: Das Deaktivieren von Treibern im SCCM hat keine Auswirkung, wenn das Treiber-Paket in der Tasksequence zugewiesen wird. (Deaktivieren wird nur bei Auto-Apply beachtet)

Daher nicht deaktivieren, sondern löschen!

Abschließend das Paket an die Distribution Points verteilen/updaten.

Nun kommt der Clou: Die vorhandene OS Deployment TS wird nun etwas modifziert.

• Zunächst wird der Step “Apply Drivers” entfernt.

• Nun erstellen wir einen neuen Step “Apply Driver Package”: Dieser Schritt sollte sich unter “Apply Operating System Image” befinden.

• Nun passen wir den Step auf das Computer-Modell an. Vergebe zunächst einen sinnvollen Namen, z.B. “Install Drivers Lenovo T450”. Wähle dann als Driver Package das zuvor erstelle Paket aus. Ich habe den Haken für unsignierte Treiber nicht gesetzt, da ich davon ausgehe, dass Lenovo nur signierte Treiber verwendet. Wer nach dem Deployment einen Treiber vermisst, sollte probieren, diesen Haken zu setzen.

• Nun kommt der wichtigste Schritt. Jetzt werden während des Deployments eine WMI-Abfrage starten und das Computer-Model abfragen. Nur wenn unsere Abfrage ergibt, dass ein T450 vorliegt, wird dieser Schritt ausgeführt. Das geht recht einfach: Im geöffneten Step unter “Options” Add Condition -> Query WMI wählen: Nun folgenden Query anlegen:

  1 2 3

  WMI Namespace: root\cimv2 WMI Query: SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "20BV%" AND Manufacturer = "LENOVO"

  Der WMI Query für das Lenovo T440s lautet:

  1	SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "20A%" AND Manufacturer = "LENOVO"

  Der WMI Query für das Lenovo T430 lautet (zumindest für die deutsche Version):

  1	SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "2349%" AND Manufacturer = "LENOVO"

  Wer mehr als einen Schritt für ein Computer Model ausführen will, kann auch gleich einen Ordner anlegen und diesen mit dem WMI-Filter belegen. Dies mache ich häufig für Treibersoftware, die abschließend installiert werden soll. In meinem Fall sieht die TS nun so aus:

• Fertig! Nun kann die TS verwendet werden.

Während des Deployments wird der wird praktischerweise der vergebene Name des Treiber-Step angezeigt, sodass man schon hier sehen kann, dass die Treiber zugewiesen werden.

Wichtig: Stelle vor dem Deployment unter “Content Status” sicher, dass die verwendeten Treiber-Pakete erfolgreich auf den DPs verteilt wurden.

Viel Spaß und Erfolg!

Weiterführender Tipp: Diese oben genannten WMI-Querys eigenen sich übrigens auch hervorragend für die Erstellung von automatisierten Computer Collections!

1

PHP Fatal error: [Zend Optimizer] Zend Debugger must be loaded after Zend Optimizer in Unknown on line 0

Seltsamerweise sah aber meine php.ini korrekt aus:

1
2
3
4
5
6
7

zend_extension_ts = "C:\Programme\xampp\php\zendOptimizer\lib\ZendExtensionManager.dll"
zend_extension_manager.optimizer_ts = "C:\Programme\xampp\php\zendOptimizer\lib\Optimizer"
zend_optimizer.enable_loader = 0
zend_optimizer.optimization_level=15
zend_extension_ts="C:\Programme\xampp\php\zendDebugger\ZendDebugger.dll"
zend_debugger.expose_remotely=allowed_hosts
zend_debugger.allow_hosts=127.0.0.1/32,192.168.0.0/255

Ich las also in wenig in verschiedensten Foren und kam dann auf die Lösung. Den Debugger sollte man als “debug server” nur mit dem Pfad, nicht der Dll in der php.ini einbinden:

1

zend_extension_manager.debug_server_ts=C:\Programme\xampp\php\zendDebugger

Wenn man das so eingetragen hat, muss die ZendDebugger.dll in ein passendes Unterverzeichnis “unter” zendDebugger je nach PHP-version geschoben werden. Ich fahre beispielsweise php-5.2.6, also heisst mein Verzeichnis php-5.2.x. Welches nun das passende ist, lässt sich sehr schnell herausfinden. Einfach die obenstehende Zeile in die php.ini eintragen. Jetzt wird ein Fehler im Apache-Log geworfen:

1

PHP Warning: Zend Debug Server for PHP 5.2.x cannot be found (expected at 'C:\\Programme\\xampp\\php\\zendDebugger\\php-5.2.x\\ZendDebugger.dll') - try reinstalling the Zend Debug Server in Unknown on line 0

Wie man sieht, wurde auch ausgegeben, wo der Webserver bzw. dessen PHP den ZendDebugger erwartet hätte. In diesen Fall in C:\Programme\xampp\php\zendDebugger\php-5.2.x\ZendDebugger.dll. Einfach dort die passende Dll ablegen und gut is ;)

1
2
3

[....] Testing nginx configuration:Configuration test failed!
nginx: [emerg] duplicate listen options for [::]:443 in /etc/nginx/sites-enabled/wolf-u.li:3
nginx: configuration file /etc/nginx/nginx.conf test failed

Was war passiert? Ich hatte zweimal (in verschiedenen vhosts) bei “listen” den port 443 mit den optionen, u.a. ssl und spdy, versehen:

Vhost 1:

1

listen [::]:443 default_server ssl ipv6only=off spdy;

Vhost 2:

1
2
3

server {
    listen [::]:443 ssl ipv6only=off;
}

Das war dem nginx nicht so recht ;) Abhilfe war also nur einmal die optionen festzulegen (also in vhost 1) und im zweiten nur noch:

1
2
3

server {
    listen [::]:443;
}

einzutragen. Schon liefs.

Abhilfe war ein Hinweis von Paul O’Brien  dass man dies per adb lösen kann:

1

adb shell am start -n com.google.android.setupwizard/.SetupWizardTestActivity

Das ruft den Setup-Wizard, den man zur ersten Einrichtung des Handy nutzt, nochmal auf. Ich musste lediglich meinen Namen nochmal eingeben womit der Wizard abgeschlossen war. Alle Settings blieben erhalten und plötzlich war alles gut - Die Benachrichtigungsleiste war wieder voll und mein Homebutton lief wie erwartet.

1

Internal error: Wrong R3trans version string: -> must be a 14 character string

Lösung: Das Filesystem /usr/sap/trans war zu 100% voll und die Transaktion konnte daher nicht fortgesetzt werden. Nach Erweiterung dieses Filesystems um ein paar GB lief der Upgrade wie gewohnt weiter.

PS: Ja das ist eine seltsame Meldung für diesen Fehler ;)