Aktuelle Erfahrungen mit 7.1 und Updates: Qualität/Funktion

A

AB-stromer

Well-Known Member
Hi,

muss mal was loswerden:

derzeit mache ich desaströse Erfahrungen mit Updates via Ports, was ich bisher nicht so kannte. Updates scheinen mir derzeit stabil nur noch über Packages zu gehen.

Das aber ist erstens blöd, weil es Packages erst mit großer, KDE4.2, oder extrem großer, OpenOffice, Verzögerung gibt, und zweitens blöd, weil es das bei FreeBSD eigentlich so hervorragende Mittel nimmt, immer aktuell zu sein.

Will hier nicht jammern, aber doch mal wissen, ob ich da irgendwelche Fehler mache oder ob es anderen auch so geht.

Was ist also passiert?

Zielsetzung war eigentlich, auf KDE 4.2 zu kommen.

1) Ein laufendes System hatte ich zuletzt bei Freigabe von 7.1-RELEASE per Binär-Update von DVD auf eben 7.1-RELEASE gebracht, was bestens ging. Ein folgendes csup mit RELENG_7 führte dann bei einem portupgrade -a dazu, dass nur ein Bruchteil der zum Update empfohlenen Ports upgedatet wurden. Von den ganzen anderen, die ich dann manuell anstieß, brachen ungelogen 60-70% mit Fehlern schon beim Config oder einem allseits sehr beliebten "Unknown build error" beim Build ab! Das kannte ich bisher nicht...

2) Systemneuaufbau 7.1-RELEASE von DVD angegangen. Nach Basisinstallation gleich einen csup mit RELENG_7 gemacht. Via Ports Xorg auf 7.4 gebracht sowie hal und dbus aktualisiert. Kompilation von KDE 4.2 brach - natürlich um mich zu ärgern - nach stundenlangem Lauf mit - ja, genau - "Unknown build error" ab.
KDE 4.1 aus Packages installiert. Absonderliches Verhalten jetzt: viele Screenwechsel oder Eingaben gehen erst nach Bewegen der Maus!!
Nicht eine einzige Version der in den Ports befindlichen Versionen von OpenOffice ließ sich kompilieren, alle brachen - nach Stunden natürlich erst - mit unterschiedlichen Fehlern ab!
Ratlos.


Nein, die HW ist es nicht, Windoof und Linuxe laufen prächtig darauf.

Schweres persönliches Einzelschicksal oder gibt's ähnliche Erfahrungen?
 
Willkommen in der Xorg 7.4 Hölle. Abgesehen davon, habe ich hier auf 7-STABLE AMD64 Openoffice 3.0.1 erfolgreich aus den ports gebaut. Aber Xorg hat mich Tage gekostet.
 
AB-stromer schrieb:
KDE 4.1 aus Packages installiert. Absonderliches Verhalten jetzt: viele Screenwechsel oder Eingaben gehen erst nach Bewegen der Maus!!
Zum Vergrößern anklicken....

Genau das hatte ich gestern auch.
Die Lösung:
Code: 
        Option "AllowEmptyInput" "False"
        Option "AutoAddDevices" "False"
        Option "AutoEnableDevices" "False

In ServerLayout. Dazu hab ich noch den moused laufen und alles ist gut. :)
 
In letzter Zeit habe ich deutlich mehr Updates gemacht, als ich normalerweise so vornehme. Damit habe ich viele Funktionen von Xorg wieder bekommen, es hatt also auch ein Gutes.
Aber leider stimmt auch, daß sich mehr und mehr Port weigern zu bauen und Fehler liefern. Bislang meist unwichtige Updates, die ich vernachlässigen kann.
Allen voran fällt mir das mit OOo auf, denn ich habe erst letztens auf 301 umgebaut um festzustellen, daß die Rechschreibprüfung nicht will. Nun wollte ich verschieden Optionen probieren und bekomme nur noch Fehler.

Weil ich selbst einen dramatischen Fehler machte und ein neues BSD nicht nach dax sondern adx installierte, überschrieb ich mir die vorhandene Installation dummerweise und führte die Fehler darauf zurück. Es passt aber absolut zu dem Bild, das du hier schilderst und deshalb wollte ich mich vorsichtig mal melden.
 
pit234a schrieb:
Allen voran fällt mir das mit OOo auf, denn ich habe erst letztens auf 301 umgebaut um festzustellen, daß die Rechschreibprüfung nicht will. Nun wollte ich verschieden Optionen probieren und bekomme nur noch Fehler.
Zum Vergrößern anklicken....

ganz genau so sieht das aus!


pit234a schrieb:
Es passt aber absolut zu dem Bild, das du hier schilderst und deshalb wollte ich mich vorsichtig mal melden.
Zum Vergrößern anklicken....

Also nach dem ganzen Desaster habe ich komplett neu installiert. Von der 7.1-RELEASE DVD, also bewusst nur xorg 7.3, nur noch eben binär auf -p3, dann KDE4.1 packages, und wieder glücklich.
Source-Updates oder xorg 7.4 oder KDE4.2 kommen erst wieder in Frage, wenn ich aus Foren-Posts den Eindruck bekomme, dass die Lage wieder in Ordnung ist.
 
ich hatte meinen zu hause ausgekehrt und die ports neu installiert. eigentlich keine probleme auf diesem weg gehabt, bis auf das meine radeon, nach dem start von X, nun keine ttys mehr anzeigen kann, was sich aber mit der zeit sicherlich legen wird. allerdings hab ich die ports genommen und die kompilieren lassen, was auf der maschine nicht sehr lange gedauert hat.
 
AB-stromer schrieb:
Source-Updates oder xorg 7.4 oder KDE4.2 kommen erst wieder in Frage, wenn ich aus Foren-Posts den Eindruck bekomme, dass die Lage wieder in Ordnung ist.
Zum Vergrößern anklicken....

Bis auf den erforderlichen Eintrag:
Code: 
Option "AllowEmptyInput"	"off"
in der Section "ServerFlags" der xorg.conf, hatte bzw. habe ich mit xorg 7.4 keine Probleme.
 
makenoob schrieb:
ich hatte meinen zu hause ausgekehrt und die ports neu installiert. eigentlich keine probleme auf diesem weg gehabt, bis auf das meine radeon, nach dem start von X, nun keine ttys mehr anzeigen kann, was sich aber mit der zeit sicherlich legen wird. allerdings hab ich die ports genommen und die kompilieren lassen, was auf der maschine nicht sehr lange gedauert hat.
Zum Vergrößern anklicken....

Das Problem, keine ttys mit einer Radeon HD (HD4670 u. HD4830) zu haben, hatte ich sowohl unter FreeBSD 8.0 (HD4830) als auch FreeBSD 7.1-STABLE (HD4670) (beide Systeme AMD64. Unter FreeBSD 8.0, eine UP Maschine, habe ich in einer einwöchigen Compilerorgie zuerst alle Abhängigkeiten von xproto-*, dann all jene von libxcb neu compiliert, anschließend, nachdem das auch keine Abhilfe brachte, nochmals alles erneut und anschließend nochmals alles, was zum X11-Server gehört. Unter FreeBSD 8.0 kann ich jetzt wie gewohnt auf das tty wechseln (ich verwende kein HAL!).

Unter FreeBSD 7.1-STABLE, eine SMP Maschine mit einem Q6600, klappt der Wechsel zum tty bis heute nicht. Zwar wird irgendwas gewechselt (ich komme auch wieder auf den X-Screen zurück), aber die ttys bleiben dunkel. Die Situation ist schier unerträglich.
 
ja, schön ist das nicht, liegt allerdings am radeonhd-treiber (ich habe eine HD4850). mit dem vesa klappt das wunderbar. ich wechsel eigentlich nicht so häufig auf die ttys wieder zurück, aber fürs einrichten des Xservers ist das nix (für den rest nehm ich Terminal). der wechsel funktioniert, klar, aber eine röhre kommt damit nicht zurecht und kann dann mit der eingestellten refreshrate nix mehr anfangen. einem LCD scheint das wurscht zu sein, da es berichte gibt, dass sich dieses verhalten bei einem LCD nicht einstellt.
 
Hi,
ich habe diese Problem auch mit meiner PCIE 4850 und mit meiner 3200 Onboard.
Ich verwende auch den radeonhd Treiber, gibt es schon Lösungen oder gibt es eine Meldung an die Entwickler?
Ich kann nichmtl nachvollziehen was genau das Problem ist, Xorg log zeigt nicht auffälliges.
 
Also, der fehlerhafte Wechsel auf die Konsole liegt an radeonhd. Er schaltet irgendwelche Register falsch oder stellt irgendwas nicht so ein, wie er eigentlich soll. Das Verhalten ist auch unter Linux und OpenSolaris 1:1 reproduzierbar. Es tritt nicht auf, wenn man die EXA-Beschleunigung nutzt, leider hängt die dumme Karte sich dann nach 20 bis 30 Sekunden reproduzierbar auf (Betriebssystem läuft weiter, man sieht nur nichts mehr), was sich nur durch einen Reboot beheben lässt.
 
Ich hatte so etwas am Anfang. Ich habe aber unter FreeBSD frustiert alle Pakete mit Gewalt (-f) neu kompiliert und die Probleme sind verschwunden (HD 2600XT).

Wo treten die Probleme auf? radeonhd oder radeonhd-devel?
 
Bei mir unter radeonhd.
radeonhd-devel habe ich nicht probiert weil die ja älter ist als radeonhd.

Mein System ist ein frisches 7.1 Release und alles aktuell gebaut
 
Hallo! Ich wohl einer der wenigen bei dem es einfach geklappt hat. Habe neulich meinen alten Arbeitsrechner zum Entertainmentgeraet im Wohnzimmer umfunktioniert. Da ich die Platten getauscht habe, habe ich 7.1 RELEASE von der DVD installiert. Danach via portsnap den Portstree aktualisiert.

Dann habe ich wie immer via portinstall -P <name> kde42 installiert. Das hat zwar laenger gedauert =), aber es lief durch. Danach noch portinstall -P xorg bzw. nvidia. Ging auch. Danach hatte ich Probleme mit Tastatur und Maus. Nachdem ich rausgefunden hatte, das hald und dbus laufen muessen, ging auch das sofort problemlos. Via DVI -> HDMI Kabel an den Fernseher angeschlossen sah das schon ganz ordentlich aus. Dumm war nur dass die Schriften ewig gross erschienen. Da scheint die neue xorg version wohl zu versuchen besonders klug zu sein und hat die DPI geaendert. Ich habe es dann in xorg.conf auf Standard zurueckgesetzt und dann gings.

In diesem Sinne!
 
Hi. Mir steht nun auch das Update auf Xorg 7.4 bevor. Habe erstmal meinen gesamten Rechner gedumpt :D Nun kann es also losgehen. Bevor ich aber nicht mehr dazu komme hier im Internet zu fragen, gleich mal vorab die Frage:

Was muss ich an meiner xorg.conf ändern, damit alles wunderbar nach dem Update läuft?

Meine derzeitige Xorg-Konfiguration für mit Grafikkarte
agp0: <Intel 82945GM (945GM GMCH) SVGA controller> on vgapci0:

Code: 
Section "ServerLayout"
	Identifier	"xrandr"
	# Screen0 will correspond to the internal LCD
        Screen         0	"Screen0" 0 0
	# nothing new here :
	InputDevice    "Mouse0" "CorePointer"
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "ServerFlags"
Option "AIGLX" "True"
EndSection

Section "Files"
	RgbPath      "/usr/local/lib/X11/rgb"
	ModulePath   "/usr/local/lib/xorg/modules"
    FontPath 	"/usr/local/lib/X11/fonts/misc"
    FontPath 	"/usr/local/lib/X11/fonts/TTF"
    FontPath 	"/usr/local/lib/X11/fonts/Type1"
    FontPath 	"/usr/local/lib/X11/fonts/75dpi"
    FontPath 	"/usr/local/lib/X11/fonts/100dpi"
    FontPath 	"/usr/local/lib/X11/fonts/webfonts"
    FontPath 	"/usr/local/share/fonts"
EndSection

Section "Module"
        Load  "dri"
        Load  "glx"
        Load  "extmod"
        Load  "record"
        Load  "dbe"
        Load  "GLcore"
        Load  "xtrap"
        Load  "type1"
        Load  "freetype"
EndSection

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
        Option     "XkbModel" "pc105"
        Option      "XkbLayout" "de"
        Option      "XkbRules" "xorg"
EndSection

Section "InputDevice"
   Identifier      "Mouse0"
   Driver          "mouse"
   Option          "Protocol" "auto"
   Option          "Device" "/dev/sysmouse"
   Option          "Buttons" "5"
   Option          "ZAxisMapping" "4 5"
EndSection


#Monitor von Notebook
Section "Monitor"
        Identifier      "LVDS Monitor"
        ModeLine	"1280x800"     83.46   1280 1352 1480 1680    800  801  804  828
EndSection

#Externer Monitor
Section "Monitor"
        Identifier      "VGA Monitor"
        #Option          "RightOf" "LVDS Monitor"
        Option          "Below" "LVDS Monitor"
EndSection

Section "Device"
        Identifier	"Card0"
	Driver		"intel"
	VendorName	"Intel Corporation"
	BoardName	"Mobile Integrated Graphics Controller"
	BusID		"PCI:0:2:0"
        Option          "Monitor-LVDS" "LVDS Monitor"
        Option          "Monitor-VGA" "VGA Monitor"
Option "DRI" "True" # <=== Grafik Beschleunigung
Option "PageFlip" "True" # <=== Wird von Tripple Buffer benoetigt
Option "TripleBuffer" "True" # <=== Braucht PageFlip
Option "Accel" "True" # <=== Grafik Beschleunigung
Option "AccelMethod" "EXA" # <=== Grafik Beschleunigung, EXA anstatt XAA
Option "ExaNoComposite" "false" # <=== Hilft gegen Ruckeln beim srollen in KDE4
Option "MigrationHeuristic" "greedy" # <=== Hilft gegen Ruckeln beim srollen in KDE4
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor     "LVDS Monitor"
        Monitor     "VGA Monitor"
        DefaultDepth 24
        SubSection "Display"
		#Virtual		1280 800
                #Virtual         2560 1024
                Virtual         1280 1824
        EndSubSection
EndSection

Section "Extensions"
Option "Composite" "Enable"
Option "RENDER" "Enable"
Option "DAMAGE" "True"
Option "SECURITY" "True"
Option "MIT-SHM" "True"
EndSection

Section "DRI" # <=== Grafik Beschleunigung
Mode 0666
EndSection
 
Also ich hab mir vom neuen Xorg erstmal eine neue config generieren lassen und dann die restlichen sachen neu eingetragen. Ich glaube mich damit auch der sicheren Seite... :)
 
Hi

Nun ist mein portupgrade durchgelaufen.
Xorg 7.4 ist nun auch installiert.
pkg_libchk -qo hat nichts ausgeworfen.

Wenn ich dann aber startx als root aufrufe passiert folgendes:
Es erscheint ein hässlicher grau-schwarz gemusterter Bildschirm mit einem X als MausCursor, den ich auch durchaus mit meinem Touchpad bewegen kann.

Die linke und rechte Maustaste macht jedoch nichts. genauso kann ich nicht mit Strg+Alt+F* in irgendwelche anderen TTYs springen, was vor startx noch ging.

Bei CapsLock springt auch nicht mehr die CapsLock-Glühbirne an und Str+Alt+BackSpace resetet den X-Server nicht. Es tut sich einfach nichts.

Habe in meinen Server-Flags-Bereich auch alle Off-Optionen, die ich hier in den Foren gefundne habe eingebaut.

Hat jemand Ideen, was hier schief geht?

startxfce4 bringt die gleichen Effekte wie oben beschrieben...

Gruesse, Helko
 
Nach jedem xorg-update, mache ich immer noch Folgendes:

Code: 
# portupgrade -fu <Treiber-Grafikkarte>
# portupgrade -fu libtool
# pkgdb -L
# pkg_libchk -qo
 
Das ist meine Keyoard-Section:

Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "de"
Option "XkbRules" "xorg"
EndSection

Ist die so ok?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben