Mailinglist Archive: opensuse-de (1330 mails)
| < Previous | Next > |
Re: auto-update kann schaden
- From: Sebastian Siebert <freespacer@xxxxxx>
- Date: Fri, 05 Feb 2010 11:53:00 +0100
- Message-id: <4B6BF88C.4030501@xxxxxx>
Hallo,
Nun ja, mit selber Schuld kann man da nur teilweise zustimmen. Wenn man
den automatischen Update-Mechanismus von openSUSE verwendet, dann sollte
man evtl. den Kernel in die Blackliste eintragen (Sofern der User von
Linux, Konsolen, Kompilieren, etc. wenig bis gar keine Ahnung hat, der
den Rechner verwendet). Erst recht, wenn man selbst kompilierte
Kernel-Module verwendet wie NVIDIA oder AMD/ATI. Eine gewisse Portion an
Paranoia gegen über DAUs ist hier zu recht angebracht. Daher enden
Auto-Updates und selbstgebackene Kernel-Module immer tödlich. :-)
Ich hingegen update mein System regelmäßig (eigentlich fast täglich wg.
den Repos) manuell über die Konsole. :-)
# zypper -v up
Ich meine mich zu erinnern, dass erst mit openSUSE 11.2 die
X-Server-Konfiguration /etc/X11/xorg.conf weggefallen ist und nun auf
HAL zurückgreift. Fallback per /etc/X11/xorg.conf ist da noch erlaubt.
Die Frage ist nur, wie lange noch?!
In meinem Fall verwende ich AMD/ATI und habe mit der Auto-Konfiguration
von X11/HAL (ohne /etc/X11/xorg.conf) nur Probleme. Daher lasse ich mir
die Konfigurationsdatei /etc/X11/xorg.conf per
# sax2 -r
generieren und dann einmal vom ATI-Konfigurationstool per
# aticonfig --initial --input=/etc/X11/xorg.conf
drüberlaufen. Die Vorstellung, dass die Entwicklung von Sax2 komplett
eingestellt wurde, um eben auf diesen Automatismus von X11/HAL
zurückzugreifen, läuft mir heute noch kalt den Rücken herunter. Das
Zusammenspiel zwischen proprietären Treiber (egal ob NVIDIA oder
AMD/ATI) und der Auto-Konfiguration von X11/HAL steht leider nicht zum
besten.
Selbst ein
# X -configure
bringt mir eine total unbrauchbare Konfiguration und konnte damit rein
gar nichts anfangen. Daher greife ich viel lieber auf Sax2 zurück.
Jepp, vollkommen logisch.
Daher lieber den Kernel auf die Blacklist setzen und sobald der
Administrator vor Ort ist, das Update manuell einspielen. Dann hat man
wenigstens noch die volle Kontrolle und hast dann nicht so ein
inkonsistentes System wie jetzt.
Keine Frage, ich bin auch für ein Auto-Update, aber bei selbst
gebackenen Kernel-Modulen hört hier der Spaß auf. Leider.
Oder du arbeitest dich mit DKMS ein:
<http://linux.dell.com/dkms/>
Hier wird automatisch bei einem neuen Kernel-Update die Module neu
kompiliert. Voraussetzung ist natürlich, dass die Kernel-Quellen auch
alle mit der gleichen Version vorhanden sind.
Umgekehrt erinnert mich der betroffene Anwender an ein Windows-Nutzer,
der von der Technik hinter Linux keine Ahnung hat. Sorry, konnte ich mir
irgendwie nicht verkneifen. Aber gerade hier hätte ich Vorsorge
getroffen, damit sowas nicht passiert. Und gerade weil es der Kernel bei
einem DAU ist.
ACK. Ich baue mir lieber selbst aus den proprietären Linux-Treiber eine
RPM und installiere diese. Lässt sich hinterher restlos entfernen.
ACK.
Aber so wie ich es verstanden habe, hat nicht Wolfgang das Update
ausgelöst, sondern sein betroffener Anwender worüber ein Auto-Update lief.
*g* Zum Ausmisten brauche ich kein Update, sondern nehme gleich
rpmorphan. :-)
Dann installiere sie doch nicht, dann spart man sich den Aufwand. :-)
BTW, auf meinem Netbook verwende ich immer noch den 1. Kernel von
openSUSE 11.2 und habe immer noch den Kernel in der Blacklist, weil im
neuesten Kernel-Update der WLAN-Treiber für Ralink-Chipsätze leider
total vermurkst ist und nicht mit dem neusten Kernel läuft. Ergebnis
beim Connect über WLAN: Kernel panic!!! Warte heute noch auf ein Update
für ein Update. :-(
<https://bugzilla.novell.com/show_bug.cgi?id=568307>
<https://bugzilla.novell.com/show_bug.cgi?id=540589>
--
Gruß Sebastian - openSUSE Member (Freespacer)
<http://de.opensuse.org/Benutzer:Freespacer>
Wichtiger Hinweis zur openSUSE Mailing Liste:
<http://de.opensuse.org/OpenSUSE_mailing_list_netiquette>
--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+unsubscribe@xxxxxxxxxxxx
Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken
Sie eine Mail an: opensuse-de+help@xxxxxxxxxxxx
Vor ein paar Tagen hat dieser Rechner sich ein automatisches Kernel-Update
geholt; allerdings wurde weder nvidia noch kernel-source mit aktualisiert.
Selber Schuld. Updates kontrolliert man.
Nun ja, mit selber Schuld kann man da nur teilweise zustimmen. Wenn man
den automatischen Update-Mechanismus von openSUSE verwendet, dann sollte
man evtl. den Kernel in die Blackliste eintragen (Sofern der User von
Linux, Konsolen, Kompilieren, etc. wenig bis gar keine Ahnung hat, der
den Rechner verwendet). Erst recht, wenn man selbst kompilierte
Kernel-Module verwendet wie NVIDIA oder AMD/ATI. Eine gewisse Portion an
Paranoia gegen über DAUs ist hier zu recht angebracht. Daher enden
Auto-Updates und selbstgebackene Kernel-Module immer tödlich. :-)
Ich hingegen update mein System regelmäßig (eigentlich fast täglich wg.
den Repos) manuell über die Konsole. :-)
# zypper -v up
Das Ergebnis: nvidia war nicht mehr lauffähig, also fuhr das System im
Textmodus hoch.
Sax2 fand auch keinen Gefallen mehr am System sondern stürzte ab; deshalb
auch keine
realistische Chance, auf den fb Grafiktreiber auszuweichen.
Äh, was genau ist jetzt so schwer, in der /etc/X11/xorg.conf den
Driver "nvidia"
durch
Driver "nv"
zu ersetzen? Wen es überfordert "idia" in einer Textdatei zu
löschen...
Oder gibt's keine xorg.conf? Äh, ja, das verkompliziert die Sache
etwas.
X -configure
(oder so) könnte helfen. Oder:
sax2 -m 0=nv
Ich meine mich zu erinnern, dass erst mit openSUSE 11.2 die
X-Server-Konfiguration /etc/X11/xorg.conf weggefallen ist und nun auf
HAL zurückgreift. Fallback per /etc/X11/xorg.conf ist da noch erlaubt.
Die Frage ist nur, wie lange noch?!
Meinereiner hat jedenfalls, da Automatismen generell sehr abgeneigt,
eine vollständige xorg.conf in /etc/X11. Und sei es nur als Backup
unter nem anderen Namen.
In meinem Fall verwende ich AMD/ATI und habe mit der Auto-Konfiguration
von X11/HAL (ohne /etc/X11/xorg.conf) nur Probleme. Daher lasse ich mir
die Konfigurationsdatei /etc/X11/xorg.conf per
# sax2 -r
generieren und dann einmal vom ATI-Konfigurationstool per
# aticonfig --initial --input=/etc/X11/xorg.conf
drüberlaufen. Die Vorstellung, dass die Entwicklung von Sax2 komplett
eingestellt wurde, um eben auf diesen Automatismus von X11/HAL
zurückzugreifen, läuft mir heute noch kalt den Rücken herunter. Das
Zusammenspiel zwischen proprietären Treiber (egal ob NVIDIA oder
AMD/ATI) und der Auto-Konfiguration von X11/HAL steht leider nicht zum
besten.
Selbst ein
# X -configure
bringt mir eine total unbrauchbare Konfiguration und konnte damit rein
gar nichts anfangen. Daher greife ich viel lieber auf Sax2 zurück.
Irgendwo in den vielen Textzeilen stand wohl, man müsse ein neues
Kernelmodul bauen,
um nvidia wieder lauffähig zu machen .... und das ist aber am nicht
aktualisierten
kernel-source gescheitert.
Äh, ja, wie immer mit diesen Treibern. Egal ob nvidia, fglrx
(ATI/AMD), oder sonst einer (vmware z.B.). "Business as usual".
Jepp, vollkommen logisch.
Daher lieber den Kernel auf die Blacklist setzen und sobald der
Administrator vor Ort ist, das Update manuell einspielen. Dann hat man
wenigstens noch die volle Kontrolle und hast dann nicht so ein
inkonsistentes System wie jetzt.
Keine Frage, ich bin auch für ein Auto-Update, aber bei selbst
gebackenen Kernel-Modulen hört hier der Spaß auf. Leider.
Oder du arbeitest dich mit DKMS ein:
<http://linux.dell.com/dkms/>
Hier wird automatisch bei einem neuen Kernel-Update die Module neu
kompiliert. Voraussetzung ist natürlich, dass die Kernel-Quellen auch
alle mit der gleichen Version vorhanden sind.
Irgendwie läuft das falsch (und erinnert den betroffenen Anwender wohl an
Produkte
aus Redmond). Ich weiss nicht was das System wirklich tun sollte (die
Nachfrage, ob man
_genau dieses_ Update installieren will, würde das Chaos zumindest nicht
verhindern),
könnte mir aber vorstellen, dass eine automatische Installation des
aktualisierten
kernel-source hilfreich wäre
Umgekehrt erinnert mich der betroffene Anwender an ein Windows-Nutzer,
der von der Technik hinter Linux keine Ahnung hat. Sorry, konnte ich mir
irgendwie nicht verkneifen. Aber gerade hier hätte ich Vorsorge
getroffen, damit sowas nicht passiert. Und gerade weil es der Kernel bei
einem DAU ist.
Sinnvoller: verwende das Treiberpaket aus dem passende openSUSE
Repo. Läuft hier einwandfrei (11.2/x86_64), und auch schon auf der
10.2/i586 davor. Ab und an muß man eben ein wenig auf die
nvidia-Treiber warten oder für ein paar Tage auf "nv" als Treiber
umstellen (s.o.), oder der Treiber is Murks. Alles kein Problem IMO.
Bzw. gibt's bei der Konkurrenz genauso (nur meist nicht zur gleichen
Zeit).
ACK. Ich baue mir lieber selbst aus den proprietären Linux-Treiber eine
RPM und installiere diese. Lässt sich hinterher restlos entfernen.
Man sollte schon ein bisserl mitdenken und nicht _jedes_ Update
einspielen.
ACK.
Aber so wie ich es verstanden habe, hat nicht Wolfgang das Update
ausgelöst, sondern sein betroffener Anwender worüber ein Auto-Update lief.
Ich selber verwende Updates übrigens gerne als Anlaß ein bisserl
auszumisten und, statt ein Update zu installieren, fliegt das
jew. Paket gleich komplett vom Rechner.
*g* Zum Ausmisten brauche ich kein Update, sondern nehme gleich
rpmorphan. :-)
Leider gibt's einige Pakete auf meiner "Blacklist" die sich nur mit
großem Aufwand entfernen ließen ...
Dann installiere sie doch nicht, dann spart man sich den Aufwand. :-)
BTW, auf meinem Netbook verwende ich immer noch den 1. Kernel von
openSUSE 11.2 und habe immer noch den Kernel in der Blacklist, weil im
neuesten Kernel-Update der WLAN-Treiber für Ralink-Chipsätze leider
total vermurkst ist und nicht mit dem neusten Kernel läuft. Ergebnis
beim Connect über WLAN: Kernel panic!!! Warte heute noch auf ein Update
für ein Update. :-(
<https://bugzilla.novell.com/show_bug.cgi?id=568307>
<https://bugzilla.novell.com/show_bug.cgi?id=540589>
--
Gruß Sebastian - openSUSE Member (Freespacer)
<http://de.opensuse.org/Benutzer:Freespacer>
Wichtiger Hinweis zur openSUSE Mailing Liste:
<http://de.opensuse.org/OpenSUSE_mailing_list_netiquette>
--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+unsubscribe@xxxxxxxxxxxx
Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken
Sie eine Mail an: opensuse-de+help@xxxxxxxxxxxx
| < Previous | Next > |