• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

XServer nach 'pkg upgrade' nicht mehr lauffähig [SOLVED]

[KB]

Well-Known Member
Themenstarter #1
Hallo,

ich möchte mein frisch erworbenes Wissen mal wieder weitergeben...

Nach einem 'pkg upgrade' und einem anschließendem Neustart des Systems konnte der xorg-Server nicht mehr starten und ist mit einem Segmentation Fault ausgestiegen. Nach einigen Untersuchungen habe ich dann festgestellt, dass am 12.05.2017 bezüglich des Xorg-Servers mehrere Ports zusammengefasst wurden. Dies wurde jedoch bis jetzt noch nicht in der /usr/ports/UPDATING erwähnt und führt zu dem oben erwähnten Verhalten.

Meine (portmaster)-Lösung:
Code:
portmaster -o graphics/mesa-libs graphics/libEGL
portmaster -o graphics/mesa-libs graphics/libGL
portmaster -o graphics/mesa-libs graphics/libglesv2
portmaster -o graphics/mesa-libs graphics/gbm
portmaster -o graphics/mesa-libs graphics/libglapi
portmaster -o graphics/mesa-libs graphics/dri
portmaster -R -r mesa-libs
Dabei nicht wundern, dass die ersten 4 portmaster-Aufrufe mit einem Fehler enden. Dies ist normal und kann übergangen werden. Der letzte portmaster-Aufruf baut alle Abhängigkeiten neu.
Danach sollte der XServer wieder starten.

Bei Fehlern korrigiert mich bitte!
Wenn jemand diese Kette vereinfachen oder auch mit z.B. mit dem pkg-Kommando nachvollziehen kann, dann her damit ... :D

Viele Grüße,
[KB]
 

mr44er

Trödel-Troll
#2
Mir fiel das gestern auch auf. Die mesa-libs beißen sich mit dem nvidia-driver, die wollen ins gleiche Verzeichnis.

Ich tüftel ebenfalls.

Hatte kein segmentation fault, aber alles war schnarchlangsam und hing.
 

Fusselbär

Makefile Voyeur
#3
Ich hatte da mit pkg set -n und pkg set -o gearbeitet, um die Abhängigkeiten wieder gerade zu biegen. War aber schön gefummel. Besonders hartnäckig war webkit2-gtk3. Das ließ sich zu dem Zeitpunkt auf meiner Installation auch nicht neu bauen. Es gab aber auch erst mal keine Fertigpakete. Aber irgendwie haben es die Magier welche die Fertigpakete bauen, es wohl geschafft und dann gab es per:
Code:
portupgrade -PP webkit2-gtk3
ausnahmsweise ein Fertigpaket in die Installation, damit passten dann alle Abhängigkeiten wieder.

Ein Eintrag in UPDATING wäre schon schön gewesen.
 

pit234a

Well-Known Member
#5
auf meinem kleinen läuft soeben ein pkg upgrade und der hat präzise die Änderungen angesagt und will die betroffenen Pakete wegen geänderter libs reinstallieren.
Ich denke deshalb, das ist nur ein Problem bei Benutzung der Ports.
 

pit234a

Well-Known Member
#6
jo. Ist durch und gut auf dem Kleinen, der aber keine nvidia hat. Die mesa libs wurden aber entfernt und ersetzt, automatisch und problemlos.
 
#8
Ich hatte da mit pkg set -n und pkg set -o gearbeitet, um die Abhängigkeiten wieder gerade zu biegen. War aber schön gefummel. Besonders hartnäckig war webkit2-gtk3. Das ließ sich zu dem Zeitpunkt auf meiner Installation auch nicht neu bauen. Es gab aber auch erst mal keine Fertigpakete. Aber irgendwie haben es die Magier welche die Fertigpakete bauen, es wohl geschafft und dann gab es per:
Code:
portupgrade -PP webkit2-gtk3
ausnahmsweise ein Fertigpaket in die Installation, damit passten dann alle Abhängigkeiten wieder.

Ein Eintrag in UPDATING wäre schon schön gewesen.
Beim Umzug einer Maschine von Intel$früher mit BIOS auf einen Skylake Xeon mit Intel HD Graphics und UEFI und gleichzeitigem Update 10.3 Stable -> 11Stable :zitter: blieb unter anderem dort (webkit2-gtk3) auch erstmal alles hängen.
Die Ursache ist eigentlich nicht webkit2-gtk sondern der geniale Port harfbuzz-icu, der libharfbzz.icu.so.0 etc nach /usr/local/lib/ installieren muss.
Das tut er (noch gestern) aber selbstgebaut einfach nicht, was zur Folge hat das (auf meinem System) webkit2-gtk3, chromium. libreoffice, tex-xetex. texlive-base nicht bauen wollten, eben mit der schönen Meckermeldung '... libharfbuzz-icu.so.0 not found'.
Den Port kann man bauen, bis er grün wird, der installiert so keine libs.
Das pkg aus dem FreeBSD repo, harfbuzz-icu-1.4.6_1.txz installiert aber genau diese libs korrekt und mit ein bisschen mehr gefrickel geht's dann wieder.
Warum das so sein soll, erschließt sich nicht zwingend, erklärt aber warum kein Eintrag in UPDATING da ist. :ugly:
Lösung:
ausnahmsweise ein Fertigpaket in die Installation
(gemeint ist harfbuzz-icu)
Quelle: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219008#c7
hth
 

Fusselbär

Makefile Voyeur
#9
Also bei mir sind die Ports harfbuzz und sein slave Port harfbuzz-icu brav und installieren ihre libs dorthin (gerade eben noch mal ausprobiert mit portupgrade -fu \*harfbuzz\*\:
Code:
ls -la /usr/local/lib/libharfbuzz*

lrwxr-xr-x  1 root  wheel      32 20 Mai 14:18 /usr/local/lib/libharfbuzz-gobject.so -> libharfbuzz-gobject.so.0.10400.6
lrwxr-xr-x  1 root  wheel      32 20 Mai 14:18 /usr/local/lib/libharfbuzz-gobject.so.0 -> libharfbuzz-gobject.so.0.10400.6
-rwxr-xr-x  1 root  wheel   52080 20 Mai 14:18 /usr/local/lib/libharfbuzz-gobject.so.0.10400.6
lrwxr-xr-x  1 root  wheel      28 20 Mai 14:18 /usr/local/lib/libharfbuzz-icu.so -> libharfbuzz-icu.so.0.10400.6
lrwxr-xr-x  1 root  wheel      28 20 Mai 14:18 /usr/local/lib/libharfbuzz-icu.so.0 -> libharfbuzz-icu.so.0.10400.6
-rwxr-xr-x  1 root  wheel    7640 20 Mai 14:18 /usr/local/lib/libharfbuzz-icu.so.0.10400.6
lrwxr-xr-x  1 root  wheel      24 20 Mai 14:18 /usr/local/lib/libharfbuzz.so -> libharfbuzz.so.0.10400.6
lrwxr-xr-x  1 root  wheel      24 20 Mai 14:18 /usr/local/lib/libharfbuzz.so.0 -> libharfbuzz.so.0.10400.6
-rwxr-xr-x  1 root  wheel  515648 20 Mai 14:18 /usr/local/lib/libharfbuzz.so.0.10400.6
webkit2-gtk3 aber wirft Linker Fehler bei der Suche nach ANGLE :eek:.
ANGLE ist doch was aus der Windows Welt?
https://github.com/Microsoft/angle
Wie hat sich das ANGLE bloß in den FreeBSD Port Bau verlaufen?
Jedenfalls sieht es beim webkit2-gtk3 Bau mit portupgrade dann bei mir so kurz vor dem Abbruch aus:
Code:
[153/5282] : && /usr/local/bin/clang++40  -O2 -pipe -march=native -DNDEBUG -fstack-protector -fno-strict-aliasing -fno-exceptions -fno-strict-aliasing -fno-rtti -std=c++1y -fcolor-diagnostics -Qunused-arguments -O2 -pipe -march=native -DNDEBUG -fstack-protector -fno-strict-aliasing  -L/usr/local/lib -fstack-protector @CMakeFiles/LLIntOffsetsExtractor.rsp  -o bin/LLIntOffsetsExtractor  && :
FAILED: bin/LLIntOffsetsExtractor
: && /usr/local/bin/clang++40  -O2 -pipe -march=native -DNDEBUG -fstack-protector -fno-strict-aliasing -fno-exceptions -fno-strict-aliasing -fno-rtti -std=c++1y -fcolor-diagnostics -Qunused-arguments -O2 -pipe -march=native -DNDEBUG -fstack-protector -fno-strict-aliasing  -L/usr/local/lib -fstack-protector @CMakeFiles/LLIntOffsetsExtractor.rsp  -o bin/LLIntOffsetsExtractor  && :
/usr/bin/ld:lib/libWTFGTK.a: file format not recognized; treating as linker script
/usr/bin/ld:lib/libWTFGTK.a:1: syntax error
clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation)
[154/5282] /usr/local/bin/clang++40    @Source/WebCore/CMakeFiles/ANGLESupport.dir/__/ThirdParty/ANGLE/src/compiler/translator/ASTMetadataHLSL.cpp.o.rsp -MD -MT Source/WebCore/CMakeFiles/ANGLESupport.dir/__/ThirdParty/ANGLE/src/compiler/translator/ASTMetadataHLSL.cpp.o -MF Source/WebCore/CMakeFiles/ANGLESupport.dir/__/ThirdParty/ANGLE/src/compiler/translator/ASTMetadataHLSL.cpp.o.d -o Source/WebCore/CMakeFiles/ANGLESupport.dir/__/ThirdParty/ANGLE/src/compiler/translator/ASTMetadataHLSL.cpp.o -c Source/ThirdParty/ANGLE/src/compiler/translator/ASTMetadataHLSL.cpp
[155/5282] /usr/local/bin/clang++40    @Source/WebCore/CMakeFiles/ANGLESupport.dir/__/ThirdParty/ANGLE/src/compiler/translator/blocklayout.cpp.o.rsp -MD -MT Source/WebCore/CMakeFiles/ANGLESupport.dir/__/ThirdParty/ANGLE/src/compiler/translator/blocklayout.cpp.o -MF Source/WebCore/CMakeFiles/ANGLESupport.dir/__/ThirdParty/ANGLE/src/compiler/translator/blocklayout.cpp.o.d -o Source/WebCore/CMakeFiles/ANGLESupport.dir/__/ThirdParty/ANGLE/src/compiler/translator/blocklayout.cpp.o -c Source/ThirdParty/ANGLE/src/compiler/translator/blocklayout.cpp
[156/5282] /usr/local/bin/clang++40    @Source/WebCore/CMakeFiles/ANGLESupport.dir/__/ThirdParty/ANGLE/src/compiler/translator/blocklayoutHLSL.cpp.o.rsp -MD -MT Source/WebCore/CMakeFiles/ANGLESupport.dir/__/ThirdParty/ANGLE/src/compiler/translator/blocklayoutHLSL.cpp.o -MF Source/WebCore/CMakeFiles/ANGLESupport.dir/__/ThirdParty/ANGLE/src/compiler/translator/blocklayoutHLSL.cpp.o.d -o Source/WebCore/CMakeFiles/ANGLESupport.dir/__/ThirdParty/ANGLE/src/compiler/translator/blocklayoutHLSL.cpp.o -c Source/ThirdParty/ANGLE/src/compiler/translator/blocklayoutHLSL.cpp
ninja: build stopped: subcommand failed.
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make: stopped in /usr/ports/www/webkit2-gtk3
** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20170520-48353-z00hoq env UPGRADE_TOOL=portupgrade UPGRADE_PORT=webkit2-gtk3-2.16.2 UPGRADE_PORT_VER=2.16.2 make
** Fix the problem and try again.
** Listing the failed packages (-:ignored / *:skipped / !:failed)
        ! www/webkit2-gtk3 (webkit2-gtk3-2.16.2)        (unknown build error)

Time spent in user mode   (CPU seconds) : 136.778s
Time spent in kernel mode (CPU seconds) : 14.185s
Total time                              : 1:07.25s
CPU utilisation (percentage)            : 224.4%
Times the process was swapped           : 0
Times of major page faults              : 2061
Times of minor page faults              : 1543167
ANGLE kann ja für die Windows-Welt für die Browser-Engine nötig sein, aber für FreeBSD ist es das nicht. Oder täusche ich mich da?

Edit:
Habe gerade diesen Faden im FreeBSD Bugzila entdeckt:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219161
Das probiere ich nachher mal aus, aber jetzt ist schon Libreoffice Bau und noch mehr gestartet, da hat die Kiste erst mal kräftig zu tun.
 
Zuletzt bearbeitet:

Fusselbär

Makefile Voyeur
#11
Nein, das ist bei mir 10.3-STABLE amd64 und die harfbuzzen sind heute nochmal extrafrischgebaut. Könnte es an einem Eintrag in der /etc/make.conf liegen?
Bei mir hier in der /etc/make.conf:
Code:
WITH_SYSTEM_ICU=YES
Der slave Port harfbuzz-icu zieht sich ja per automagie rein, es gibt keine wählbare Option im harfbuzz Port.

webkit2-gtk3 hat jetzt übrigens fertig, der Bau ist mit diesem Patch durchgelaufen:
https://bz-attachments.freebsd.org/attachment.cgi?id=182671&action=diff&format=raw&headers=1