Nach pkg upgrade: KDE4, Firefox und Seamonkey starten nicht mehr

[cabriofahrer]

Nach einem pkg upgrade starten KDE4, Firefox und Seamonkey nicht mehr (und vielleicht noch andere Sachen, von denen ich noch keine Kenntnis habe).
Das System bootet zwar in KDM, doch dann erscheint ein kleines S/W-Fenster mit der Meldung, dass kde4init nicht gestarten werden kann. Wenn ich auf OK, drücke, kann ich wenigstens von KDM aus MATE starten.
Seamonkey und Firefox starten nicht mehr, Opera aber schon.
Für Firefox konnte ich lediglich folgende Meldung im Terminal sehen, die vielleicht Aufschluss gibt:

$ firefox
1512548630923 addons.xpi WARN Add-on timecop@mozilla.com is not compatible with application version.
1512548630924 addons.xpi WARN Add-on timecop@mozilla.com is not compatible with application version.
1512548630925 addons.xpi WARN Add-on timecop@mozilla.com is not compatible with application version.
1512548630926 addons.xpi WARN Add-on timecop@mozilla.com is not compatible with application version.
1512548630980 addons.xpi ERROR Failed to process extension changes at startup: [Exception... "Component returned failure code: 0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsIFile.isFile]" nsresult: "0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)" location: "JS frame :: resource://gre/modules/addons/XPIInstall.jsm :: this.loadManifestFromFile :: line 971" data: no] Stack trace: this.loadManifestFromFile()@resource://gre/modules/addons/XPIInstall.jsm:971 < syncLoadManifestFromFile()@resource://gre/modules/addons/XPIProvider.jsm:947 < updateCompatibility()@resource://gre/modules/addons/XPIProvider.jsm -> resource://gre/modules/addons/XPIProviderUtils.js:1410 < processFileChanges()@resource://gre/modules/addons/XPIProvider.jsm -> resource://gre/modules/addons/XPIProviderUtils.js:1547 < checkForChanges()@resource://gre/modules/addons/XPIProvider.jsm:3265 < startup()@resource://gre/modules/addons/XPIProvider.jsm:2182 < callProvider()@resource://gre/modules/AddonManager.jsm:263 < _startProvider()@resource://gre/modules/AddonManager.jsm:730 < startup()@resource://gre/modules/AddonManager.jsm:897 < startup()@resource://gre/modules/AddonManager.jsm:3081 < observe()@jar:file:///usr/local/lib/firefox/omni.ja!/components/addonManager.js:65
1512548630994 addons.xpi ERROR Attempted to load bootstrap scope from missing directory /usr/local/lib/firefox/browser/features/clicktoplay-rollout@mozilla.org.xpi
1512548630995 addons.xpi WARN Add-on clicktoplay-rollout@mozilla.org is missing bootstrap method startup
console.log: SBv4-gradual-rollout not needed on 57 or later, removing.
/usr/local/lib/libsqlite3.so.0: Undefined symbol "fdatasync"
$

 

[mr44er]

Das Problem liegt woanders. XPIs sind Plugins für den Firefox.

Ab FF56 aka Quantum gehen die 'alten' Plugins nicht mehr. Steht ja auch 4x in der Fehlermeldung so.

Schmeiß den FF mal runter und installier blank den neuen FF ohne Plugins erstmal.

 

[mordin]

/usr/local/lib/libsqlite3.so.0: Undefined symbol "fdatasync"

FreeBSD 11.0-RELEASE wird seit dem 30.11.2017 nicht mehr supported, d.h. dass u.a. die Pakete auf pkg.freebsd.org jetzt in 11.1 jails gebaut werden.
fdatasync() ist neu in 11.1.

Lösung: Mach ein Upgrade auf 11.1-RELEASE.

 

[holgerw]

Lösung: Mach ein Upgrade auf 11.1-RELEASE.

@cabriofahrer
Leicht OT: Vielleicht behebt das Upgrade auf 11.1 auch Deine Schwierigkeiten mit dsbmd/dsbmc

 

[cabriofahrer]

Danke Leute, habe jetzt mittlerweile das System auf 11.1 gebracht. War aber irgendwann nach Posten des Threads auch zu dem Schluss gekommen, denn ich wollte den Port sqlite3 einzeln neu kompilieren und bekam dann die Fehlermeldung, dass mein System nicht mehr unterstützt würde. Ab dann wurde es mir klar...

Möchte deshalb an dieser Stelle noch fragen: Welche (regelmäßige) Upgrade-Strategie fährt man denn am besten jeweils für Basissystem und Userland? Ich selbst bin eher ein Anhänger von Murphy's Law, "Never touch a running system", aber wie man sieht, ist diese Strategie wohl zeitlich begrenzt...

Leicht OT: Vielleicht behebt das Upgrade auf 11.1 auch Deine Schwierigkeiten mit dsbmd/dsbmc

Danke für den Hinweis, aber leider wohl nicht oder nur teilweise. Habe das Ergebis soeben im anderen Thread gepostet.

 

[zuglufttier]

"Never touch a running system" ist die schlechteste Strategie überhaupt und muss von Personen kommen, die keine Ahnung haben wie ihre Systeme funktionieren. Denn sonst installiert man halt Updates sobald sie zur Verfügung stehen. Gerade mit ZFS kannst du heute einfach einen Snapshot anlegen und dann das Update einspielen.

Ich mache das also, sobald ich Gelegenheit dazu habe.

 

[pit234a]

Ich mache das also, sobald ich Gelegenheit dazu habe.

"Immer wieder Sonntags..."
Das ist meist eine gute Gelegenheit bei mir und das nutze ich deshalb oft (allerdings gibt es auch schon mal Wochen dazwischen, wo ich keine Gelegenheit bekomme). Und dann mache ich immer erst einen neuen Znapshot (bzw mehrere), dann ein freebsd-update (was manchmal einen Neustart brauchen kann) und dann ein pkg upgrade. Den einen einsamen Port, den ich derzeit dann noch baue aktualisiere ich meist erst, wenn Probleme auftauchen.

Trotz pkg: das Lesen der UPDATING halte ich für wichtig genug, es hier ausdrücklich zu erwähnen (und gleichzeitig zuzugeben, dass ich es meist auch unterlasse, aber dies auch schon manchmal bereut habe).

 

[mr44er]

Trotz pkg: das Lesen der UPDATING halte ich für wichtig genug, es hier ausdrücklich zu erwähnen

Fullack, das behebt oft viel Haare raufen und Glatze kratzen.

 

[holgerw]

Mal ne Frage: Hast Du in der FreeBSD.conf ein quarterly oder latest?

Wenn Du Dir nämlich einzelne Sachen aus den Ports dazu kompilierst (da wird standardmäßig der head Branch verwendet), kann das zu Schwierigkeiten führen, quarterly für das Paketrepo zu nutzen.