1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

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

Dieses Thema im Forum "FreeBSD - Installation" wurde erstellt von [KB], 16 Mai 2017.

  1. [KB]

    [KB] Member

    Registriert seit:
    20 April 2010
    Beiträge:
    111
    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]
     
    goblin gefällt das.
  2. mr44er

    mr44er Trödel-Troll

    Registriert seit:
    22 September 2013
    Beiträge:
    168
    Ort:
    Reichelsheim
    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.
     
  3. Fusselbär

    Fusselbär Makefile Voyeur

    Registriert seit:
    6 August 2004
    Beiträge:
    2.172
    Ort:
    Köln
    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.
     
  4. cabriofahrer

    cabriofahrer Active Member

    Registriert seit:
    27 November 2004
    Beiträge:
    1.080
    Danke für diese Warnung. D.h. dann wie lange besser kein "pkg upgrade" machen, bis das Problem nicht mehr auftritt?
     
  5. pit234a

    pit234a Well-Known Member

    Registriert seit:
    8 Juli 2006
    Beiträge:
    2.840
    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.
     
  6. pit234a

    pit234a Well-Known Member

    Registriert seit:
    8 Juli 2006
    Beiträge:
    2.840
    jo. Ist durch und gut auf dem Kleinen, der aber keine nvidia hat. Die mesa libs wurden aber entfernt und ersetzt, automatisch und problemlos.
     
  7. cabriofahrer

    cabriofahrer Active Member

    Registriert seit:
    27 November 2004
    Beiträge:
    1.080
    Danke, dann scheint es für pkg-Benutzer ja doch kein Problem zu geben...
     
  8. metro

    metro i² = -1

    Registriert seit:
    12 November 2007
    Beiträge:
    381
    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:
    (gemeint ist harfbuzz-icu)
    Quelle: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219008#c7
    hth
     
  9. Fusselbär

    Fusselbär Makefile Voyeur

    Registriert seit:
    6 August 2004
    Beiträge:
    2.172
    Ort:
    Köln
    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: 20 Mai 2017 um 15:03 Uhr
  10. metro

    metro i² = -1

    Registriert seit:
    12 November 2007
    Beiträge:
    381
    das könne die alten libs von der vorherigen Version sein . Ist das 11-STABLE ?
    Wie auch immer.
     
  11. Fusselbär

    Fusselbär Makefile Voyeur

    Registriert seit:
    6 August 2004
    Beiträge:
    2.172
    Ort:
    Köln
    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