Kategorien
Allgemein

Windows 7 Druckerverbindung nicht möglich Fehler 0x00000bc4

Ein PC der über Jahre ohne Probleme mit einem Drucker verbunden ist kann plötzlich nicht mehr drucken, das Löschen und Wiederherstellen der Verbindung über den UNC Pfad \\prod1\pdf schlägt fehl. Eine Verbindung via IP Adresse \\192.168.1.1\PDF ist allerdings noch möglich!

Im Eventlog von Windows findet sich mal wieder überhaupt nichts, auch sonst kein wirklicher Hinweis woher das Problem stammen könnte.

Nachdem ich alle Verweise auf den Drucker in der Registry gelöscht und den PC neu gestartet habe bekomme ich folgenden Fehler zu sehen: 0x00000bc4

Unglaublich aussagekräftig, hier lobe ich mir die Linux Welt – gewöhnlich vernünftige Fehlermeldungen in den Logs und falls das nicht reicht dreht man das Debugging einfach hoch und lässt sich mit Meldungen überfluten. Mit ein wenig Hirnschmalz kommt man dann meist schnell an’s Ziel.

Nicht so bei meinem „Lieblingsbetriebssystem“ – hier muss man sich via trial and error stundenlang quälen und wertvolle Lebenszeit vergeuden.

So geschehen am gestrigen Tag und heute Morgen, immerhin habe ich eine Lösung für das Problem gefunden und möchte es hier für künftige Einsätze und andere Gequälte festhalten:

Diesen Registry Key löschen:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers

Und anschließend einmal neu starten, anschließen lässt sich die Druckerverbindung wieder herstellen.

Eine andere vorgeschlagene Lösung hat bei mir nicht funktioniert:

ipconfig /flushdns

Für den Fall der Fälle schadet es aber nicht den mal auszuführen. Die Namensauflösung lief bei mir aber immer sauber durch, ein Ping auf prod1 war immer problemlos möglich und wurde zur korrekten IP aufgelöst.

Kategorien
Linux

X11 Autologin startet nach Upgrade von Ubuntu 14.04 auf 16.04 nicht mehr

Nach einem Upgrade von Ubuntu 14.04 auf 16.04 bekomme ich auf einem Kiosk System mit automatischem Login und Start des X11 Servers als nicht root-User in der Xorg.0.log Datei eine Fehlermeldung dass auf /dev/tty1 nicht zugegriffen werden kann.

Keine Rechte – OK, erst mal in der /etc/group Datei den User zu den Gruppen tty und vga hinzugefügt und neu gestartet…

Neue Fehlermeldung, selbes Ergebnis – X11 startet nicht.

Die neue Fehlermeldung lautet:

[ 16.675] (EE) Fatal server error:
[ 16.675] (EE) xf86OpenConsole: Cannot open virtual console 2 (Permission denied)

Nach längerer Recherche im Netz habe ich dann die Lösung gefunden – es muss ein zusätzliches Paket installiert werden.

sudo apt-get install xserver-xorg-legacy

Hat das Problem bei mir beseitigt, das Kiosk System funktioniert wieder.

Kategorien
Allgemein

Owncloud zu Nextcloud Migrationsproblem mit Mysql DB Verbindung

Nachdem sich Nextcloud von Owncloud abgesplittet hat und die Entwicklung dort Fahrt aufgenommen hat, wollte ich heute eine Owncloud 9 Version nach Nextcloud 11 migrieren.

Der Direkte Pfad wird nicht empfohlen – hier die Empfehlung von Nextcloud:

  • ownCloud 8.0.x -> ownCloud 8.1.x -> ownCloud 8.2.x -> Nextcloud 9.0.x -> Nextcloud 10.0.x
  • ownCloud 8.2.x -> Nextcloud 9.0.x -> Nextcloud 10.0.x
  • ownCloud 9.0.x -> Nextcloud 9.0.x -> Nextcloud 10.0.x
  • ownCloud 9.1.x -> Nextcloud 10.0.x -> Nextcloud 11.0.x

In meinem Fall habe ich erst Owncloud auf die Version 9.1.4 hoch gezogen und dann migriert.

Die Migration hat allerdings nicht auf Anhieb geklappt – nach dem Einspielen der Dateien und dem Anpassen der Konfiguration bekam ich folgende Fehlermeldung:

Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occured in driver: SQLSTATE[HY000] [2006] MySQL server has gone away in /var/www/nextcloud/lib/private/DB/Connection.php:59
Stack trace:
#0 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(429): OC\DB\Connection->connect()
#1 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(389): Doctrine\DBAL\Connection->getDatabasePlatformVersion()
#2 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(328): Doctrine\DBAL\Connection->detectDatabasePlatform()
#3 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(621): Doctrine\DBAL\Connection->getDatabasePlatform()
#4 /var/www/nextcloud/lib/private/DB/Connection.php(142): Doctrine\DBAL\Connection->setTransactionIsolation(2)
#5 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php(172): OC\DB\Connection->__construct(Array, Object(Doctrine\DBAL\Driver\PDOMySql\Driver), Object(Doctrine\DBAL\Configuration), Object(Doctrine\Common\EventManager))
#6 /var/www/nextcloud/lib/private/DB/ConnectionFactory.php(121): Doctrine\DBAL\DriverManager::getConnection(Array, Object(Doctrine\DBAL\Configuration), Object(Doctrine\Common\EventManager))
#7 /var/www/nextcloud/lib/private/Server.php(415): OC\DB\ConnectionFactory->getConnection(‚mysql‘, Array)
#8 /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(113): OC\Server->OC\{closure}(Object(OC\Server))
#9 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(103): Pimple\Container->offsetGet(‚DatabaseConnect…‘)
#10 /var/www/nextcloud/lib/private/ServerContainer.php(89): OC\AppFramework\Utility\SimpleContainer->query(‚DatabaseConnect…‘)
#11 /var/www/nextcloud/lib/private/Server.php(1029): OC\ServerContainer->query(‚DatabaseConnect…‘)
#12 /var/www/nextcloud/lib/private/legacy/db.php(57): OC\Server->getDatabaseConnection()
#13 /var/www/nextcloud/lib/private/User/Database.php(232): OC_DB::prepare(‚SELECT `uid`, `…‘)
#14 /var/www/nextcloud/lib/private/User/Database.php(280): OC\User\Database->loadUser(“)
#15 /var/www/nextcloud/lib/private/User/Manager.php(140): OC\User\Database->userExists(“)
#16 /var/www/nextcloud/lib/private/User/Session.php(197): OC\User\Manager->get(“)
#17 /var/www/nextcloud/lib/private/Log.php(282): OC\User\Session->getUser()
#18 /var/www/nextcloud/lib/public/Util.php(159): OC\Log->log(3, ‚User backend OC…‘, Array)
#19 /var/www/nextcloud/lib/private/legacy/user.php(146): OCP\Util::writeLog(‚core‘, ‚User backend OC…‘, 3)
#20 /var/www/nextcloud/lib/base.php(742): OC_User::setupBackends()
#21 /var/www/nextcloud/lib/base.php(1074): OC::init()
#22 /var/www/nextcloud/console.php(56): require_once(‚/var/www/nextcl…‘)
#23 /var/www/nextcloud/occ(11): require_once(‚/var/www/nextcl…‘)
#24 {main}PHP Warning: call_user_func() expects parameter 1 to be a valid callback, class ‚OC\Log\File‘ not found in /var/www/nextcloud/lib/private/Log.php on line 299

Irgend ein Problem mit der Verbindung zur Datenbank – nachdem Owncloud zuvor mit der gleichen Config funktioniert hat und ich die Zugangsdaten mehrfach geprüft habe, kam ich zu dem Entschluß dass ich es mal mit einer frischen Datenbank versuchen könnte.

Also einfach die config/config.php verschmissen und neue Daten eingetragen. Wenige Sekunden später lief dann eine leere Instanz von Owncloud (keine User) mit den vorhandenen Files.

Als nächstes  habe ich einen Dump der alten Datenbank erstellt und diesen über die neue Datenbank gespielt. Eigentlich würde ich erwarten dass jetzt gleich wie vorher nicht mehr funktioniert. Falsch geraten – das Upgrade auf Nextcloud 10 ließ sich ohne Schwierigkeiten installieren.

Anschließend noch die Kür mit dem Upgrade auf Nextcloud 11 und beendet ist die kleine Upgrade-Orgie.

Warum das Ganze? Weil ich Kalender und Kontakte synchronisieren will… 🙂

PS: Im Zuge der Umstellung habe ich dann auch gleich von mysql zu mariadb gewechselt.

Kategorien
Linux

Ubuntu 16.04 – A start job is running for Unattended Upgrades Shutdown

Ubuntu richtet eine Dienst für unattended upgrades ein, genau dieser Dienst macht gelegentlich beim Herunterfahren des Systems Probleme.

Meine Geduld hat bisher nicht ausgereicht um so lange zu warten bis irgend etwas passiert, gefühlt dauert es eine Ewigkeit – die zwei Worte „no limit) am Ende der Meldung deuten auch wirklich darauf hin.

Gut möglich dass das Problem generell nur dann auftritt wenn das System frisch gestartet worden ist und man gleich oder nach kurzer Zeit einen Neustart einleitet.

Da ich alle Sicherheitsupdates zeitnahe selbst installiere und diese verantwortungsvolle und gelegentlich auch fehlerbehaftete Aufgabe nicht einem Dienst überlassen möchte, stört mich der Dienst mehr als er Nutzen bringt. Während der Installation des Systems habe ich übrigens die automatische Installation von Updates abgelehnt – da sind sie trotzdem auch wenn sie nichts automatisch installieren.

Um die Fehlermeldung zu eliminieren kann man den Dienst einfach nicht mehr starten:

update-rc.d -f unattended-upgrades remove

Wer vor dem reboot den Dienst beendet

systemctl stop unattended-upgrades

spart sich die Warterei und bekommt nach kurzer Wartezeit sein System ohne den Dienst gestartet – ein erneuter reboot läuft dann ohne lange Wartezeit!

Speziell bei der Fernwartung von Systemen die hunderte Kilometer entfernt stehen ist das eine echte Hilfe! 🙂

Kategorien
Allgemein

Thunderbird/Lightning Fehlermeldung – die binäre Komponente konnte nicht geladen werden

Eine der wohl schrägsten Fehlermeldungen die ich in letzter Zeit erhalten habe und die mich nicht so wirklich auf weiter gebracht hat ist die folgende:

Die für Lightning benötigte binäre Komponente konnte nicht geladen werden, da vermutlich nicht zueinander passende Versinoen verwendet werden. Aktuell haben sie Lightning 4.7.4 installiert, sollten aber eine Version aus der 4.7er-Serie verwenden.

Beim genauen Lesen dürfte auffallen dass die Version 4.7.4 durchaus der 4.7er Serie entspringt  – die Meldung also Schwachsinn ist.

Nach langem Suchen und verschiedenen Tests habe ich dann den Fehler gefunden, er dürfte sehr speziell sein und tritt nur in der bei uns eingesetzten Konstellation auf. Die Besonderheit ist dass unsere Thunderbird User Profil Ordner auf einem Netzlaufwerk (Samba Server) liegen. Alle von den Benutzern auf diesen Laufwerken erstellten Dateien bekommen per Default die Berechtigung 600 also RW zugewiesen – können also nur vom User selbst gelesen und beschrieben werden.

Und genau hier liegt das Problem – die eine DLL Datei die im extensinos/components Ordner von Lightning liegt braucht zusätzlich das execute-bit gesetzt!

Nach einem chmod +x auf der Datei „calbasecomps.dll“ verschwand die Fehlermeldung.

 

Kategorien
Linux

Ubuntu – bindgraph – Prototype mismatch: sub Parse::Syslog::str2time

Bereits mit Ubuntu 14.04 ist dieser Fehler schon aufgetaucht und bis heute haben sie es nicht geschafft diese Kleinigkeit zu fixen – eigentlich ein Trauerspiel weil’s wirklich nur einer Kleinigkeit bedarf.

Egal, wen dieser Fehler hier plagt:

Starting DNS Statistics /usr/sbin/bindgraph.pl
Prototype mismatch: sub Parse::Syslog::str2time ($$$$$$$) vs ($$$$$$$$) at /us
Subroutine str2time redefined at /usr/share/perl5/Parse/Syslog.pm line 66.
Subroutine new redefined at /usr/share/perl5/Parse/Syslog.pm line 138.
Subroutine _next_line redefined at /usr/share/perl5/Parse/Syslog.pm line 206.
Subroutine next redefined at /usr/share/perl5/Parse/Syslog.pm line 388.
Not enough arguments for Parse::Syslog::str2time at /usr/sbin/bindgraph.pl lin
BEGIN not safe after errors–compilation aborted at /usr/sbin/bindgraph.pl lin
…fail!

Für den gibt es eine sehr einfache Abhilfe!

Einfach in der Datei /usr/sbin/bindgraph.pl folgende Einträge ändern -> Syslog zu BgSyslog.

Sehr einfach klappt das mit dem vi – vi starten und dann folgendes eingeben „:%s/Syslog/BgSyslog/g“, anschließend speichern und Dienst neu starten. Die Fehlermeldung sollte verschwunden sein und bindgraph seinen Dienst verrichten.

Kategorien
Linux

Ubuntu 14.04 – Paket irqbalance 1.0.6-2 Fehler beim Upgrade

irqbalance_1.0.6-2_update-error-fixedBeim Installieren der aktuellen Updates für irqbalance 1.0.6-2 bekommt man eine Fehlermeldung, dass das Post-Install-Script nicht korrekt abgelaufen ist und die Installation bricht ab.

Startet man die Installation manuell via „dpkg“ mit dem Parameter „-D65535“ bekommt man jede Menge Debug Informationen und ziemlich am Ende der langen Liste auch die Ursache präsentiert!

D000020: deferred_configure ‚/etc/init/irqbalance.conf‘ (= ‚/etc/init/irqbalance.conf‘) useredited=-1 distedited=-1 what=2
start: Job is already running: irqbalance
invoke-rc.d: initscript irqbalance, action „start“ failed.
dpkg: Fehler beim Bearbeiten des Paketes irqbalance (–install):
Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
D020000: post_script_tasks – ensure_diversions

Laut der Fehlermeldung konnte das Startscript nicht richtig ausgeführt werden weil bereits ein irqbalance Dienst läuft!

Für das Problem gibt es also eine ganz einfach Lösung – vor dem Start des Updates einfach den irqbalance Dienst stoppen.

service irqbalance stop

Und schon klappt es mit der Installation des Updates.

Kategorien
Linux

Fujitsu RX1330 – Ubuntu Kernel Upgrade auf Kernel 3.16.0-48 und Netzwerkprobleme

Nach dem letzten Ubuntu Kernel Update auf Version 3.16.0-48 habe ich probleme bei einem Fujitsu RX1330 mit den Netzwerkadaptern gehabt!

12.09.2015 Update: Es betrifft auch Primergy RX100 S7 Server – ich vermute fast dass das Problem eher mit dem e1000e Treiber oder der Intel Netzwerkkarte zusammenhängt (Intel Corporation 82579LM Gigabit Network Connection)!

Vernünftiges Arbeiten am Netzwerk war leider nicht mehr möglich – im /var/log/syslog Logfile fanden sich folgende Meldungen:

Sep 7 07:27:00 server kernel: [ 4715.488063] igb 0000:04:00.0: Detected Tx Unit Hang
Sep 7 07:27:00 server kernel: [ 4715.488063] Tx Queue <3>
Sep 7 07:27:00 server kernel: [ 4715.488063] TDH <80>
Sep 7 07:27:00 server kernel: [ 4715.488063] TDT <80>
Sep 7 07:27:00 server kernel: [ 4715.488063] next_to_use <82>
Sep 7 07:27:00 server kernel: [ 4715.488063] next_to_clean <80>
Sep 7 07:27:00 server kernel: [ 4715.488063] buffer_info[next_to_clean]
Sep 7 07:27:00 server kernel: [ 4715.488063] time_stamp <10010d661>
Sep 7 07:27:00 server kernel: [ 4715.488063] next_to_watch <ffff88003681f810>
Sep 7 07:27:00 server kernel: [ 4715.488063] jiffies <10010d944>
Sep 7 07:27:00 server kernel: [ 4715.488063] desc.status <33c200>

Da der Fehler unmittelbar nach dem Neustart mit dem neuen Kernel auftauchte, war natürlich der Rückschluss auf das Update naheliegend. Statt dem Weg zurück zum älteren Kernel habe ich die Flucht nach vorne gewagt! 🙂

apt-get install –install-recommends linux-generic-lts-vivid linux-headers-generic-lts-vivid linux-image-generic-lts-vivid

Nach einem erneuten Neustart läuft das System jetzt mit dem Kernel 3.19.0-26 wieder stabil!

Kategorien
Linux

Fehler beim Upgrade von Squidguard bei Ubuntu 14.04

Bin gerade in den Bug hier rein gerauscht:

https://bugs.launchpad.net/ubuntu/+source/squidguard/+bug/1313200

Wie in der Bugmeldung beschrieben liegt das Problem daran dass der squidguard in Version 1.5-2 versucht am Ende den Proxy Squid neu zu starten, was mangels /etc/init.d/squid3 Script aber scheitert.

Was liegt also näher als das Problem zu beheben indem man einfach dieses Script erstellt? – nichts! 🙂

#!/bin/bash

exit 0

Mehr muss da nicht drinnen stehen – Hauptsache das Script liefert ein „0“ als Fehlercode retour und somit ein OK. Mit „chmod 0700 /etc/init.d/squid3“ noch ausführbar gemacht und schon klappt das Update vom squidguard ohne Probleme!

Es gibt wie’s scheint schon ein Paket mit Bugfix 1.5-3 allerdings nicht in den Update Repositories vom 14.04, das kann sich natürlich jederzeit ändern…

Kategorien
Linux

RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller – nach Neustart nicht mehr aktiv

Nach einem Reboot war heute bei einem meiner PC’s die Netzwerkschnittstelle nicht mehr aktiv, eigentlich sollte der mit dem Kernel Modul r8169 laufen – was er bisher auch tat!

Auf den ersten Blick sah es so aus als wäre die Netzwerkkarte nicht mehr im System vorhanden, ein „ifconfig eth0“ lieferte keine Daten! Und auch „dmesg“ zeigte beim Starten kein eth0 Interface.

Mittels „lshw -C network“ konnte ich sie dann aber doch finden:

*-network UNCLAIMED
description: Ethernet controller
product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci@0000:02:00.0
version: 06
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress msix vpd bus_master cap_list
configuration: latency=0
resources: ioport:e000(size=256) memory:f7d00000-f7d00fff memory:f0000000-f0003fff

Ein Glück sie hat niemand ohne mein Wissen vom Mainboard gelötet! 🙂

Den Grund für das Verschwinden habe ich dann auch gefunden, im Zuge größerer Tests und Umbauarbeiten am System habe ich gestern zwei Pakete entfernt von denen ich dachte dass sie nicht benötigt werden – crda und wireless-regdb – im guten Glauben dass ich ohne WLAN diese auch nicht wirklich benötige. Nicht aufgefallen ist mir dass im Zuge dessen auch das Paket linux-image-extra-3.16.0-45-generic deinstalliert wurde und genau dieses Paket enthält den Treiber für den r8169 Chipsatz!

Nach dem Installieren der drei Pakete lies sich der Treiber wieder ohne Probleme laden und alles funktioniert wieder wie gewohnt.

Ein Glück dass ich in dem PC eine zweite Netzwerkkarte installiert hatte, darüber konnte ich per Fernwartung auf das System zugreifen und das Problem lösen. Ohne währe wohl eine kleine Autofahrt nötig gewesen… 😉