Alcuni giorni fa, mentre in Linux (SuSE 10.0 - sotto KDE) stavo
aggiornando i dati di un mio file di OpenOffice.org2.0-Calc, ad un certo
punto la tastiera ha cessato di scrivere. Il guaio è rimasto anche dopo
ripartenze a freddo del computer. Ho poi verificato che:
1) la mancanza di scrittura da tastiera è generalizzata in KDE e
comprende persino i comandi da tastiera nei giochi;
2) resta esclusa anche l'accettazione di testo da copia-incolla negli
editor, negli emulatori di terminale, nei programmi di scrittura e fogli
di calcolo e in vari altri programmi; non però in tutti (ad esempio,
yast ha accettato il testo della parola d'ordine di root da copia-incolla);
3) il difetto si limita all'utente interessato ed a quanto operato dalla
sua sessione di KDE anche operando come root o come altro utente per
tramite di "su" (non riguarda invece sessioni di root, né di un secondo
utente, che ho installato dopo che si è presentato il bug);
4) il guaio si limita all'ambiente grafico KDE; non riguarda gnome, né
l'operare fuori dall'ambiente grafico, anche per l'user che ha sofferto
il danno;
5) un tentativo di riparazione del sistema dal DVD di installazione non
ha dato alcun esito.
Potrei eliminare l'utente danneggiato; ma mi dispiace, per tutto quello
che ho nel suo sito home, ed ho anche paura che il guaio possa ripetersi
anche con nuovi utenti, e resta un po'intaccata la fiducia nella
stabilità di Linux; e poi sono assai interessato a capire che cosa sia
accaduto, e come si possa rimediare. Qualcuno mi potrebbe aiutare?
Ciao Riccardo,
Riccardo Zancan schrieb:
Alcuni giorni fa, mentre in Linux (SuSE 10.0 - sotto KDE) stavo
aggiornando i dati di un mio file di OpenOffice.org2.0-Calc, ad un certo
punto la tastiera ha cessato di scrivere. Il guaio è rimasto anche dopo
ripartenze a freddo del computer. Ho poi verificato che:
hai provato a fare un mv delle directory colle impostazioni personali di
KDE del tuo utente?
Io non uso KDE e perciò non ti so dire, se ho le directory sul mio
sistema. Attualmente trovo solo la directory .kde
patrick(a)vaio:~$ ls -ld .kde
drwx------ 3 patrick patrick 4096 2005-08-22 11:13 .kde
Prova a fare un mv tipo:
mv .kde .kde_OLD
E poi avviare l'interfaccia grafica. La dir dovrebbe essere recriata e
se era solo un problema nella tua configurazione, il problema dovrebbe
essere risolto.
[...] e resta un po'intaccata la fiducia nella
stabilità di Linux
Anche i programmi sotto GNU/Linux vengono scritti da essere umani e
perciò anche questi contengono errori. 
Un programma senza errori non esiste, perchè il programmatore sarebbe
perfetto e noi essere umani non siamo perfetti. Possiamo solo cercare di
aiutarci a vicenda riconoscendo e correggendo gli errori fatti
all'interno della comunità.
Happy hacking!
Patrick
Patrick Ohnewein ha scritto:
Riccardo Zancan schrieb:
Alcuni giorni fa, mentre in Linux (SuSE 10.0 - sotto KDE) stavo
aggiornando i dati di un mio file di OpenOffice.org2.0-Calc, ad un certo
punto la tastiera ha cessato di scrivere. Il guaio è rimasto anche dopo
ripartenze a freddo del computer. Ho poi verificato che:
.......
Prova a fare un mv tipo:
mv .kde .kde_OLD
E poi avviare l'interfaccia grafica. La dir dovrebbe essere recriata e
se era solo un problema nella tua configurazione, il problema dovrebbe
essere risolto.
Ciao Patrick. Ti ringrazio veramente molto del consiglio, che ho subito
applicato, con immediato effetto di perfetto ripristino di KDE.
Soluzione semplicissima, ma che viene in mente subito solo a chi ha,
come te, una grande esperienza.
[...] e resta un po'intaccata la fiducia nella
stabilità di Linux
Anche i programmi sotto GNU/Linux vengono scritti da essere umani e
perciò anche questi contengono errori.Un programma senza errori non esiste, perchè il programmatore sarebbe
perfetto e noi essere umani non siamo perfetti. Possiamo solo cercare di
aiutarci a vicenda riconoscendo e correggendo gli errori fatti
all'interno della comunità.Happy hacking!
Patrick
Accetto il rimprovero. So benissimo che non esiste un solo programma complesso esente da errori (a parte anche il dubbio se, in partenza, nel mio caso il bug fosse di Linux, o magari invece di OpenOffice). Al momento in cui ci si trova in difficoltà di questo tipo, è però facile avere un (breve e guaribile) momento di sfiducia.
Grazie ancora.
Riccardo
attachment.htm (2.19 KB)
Hallo,
ich kaempfe seit einiger Zeit mit einer Fedora(4)installation, die nicht
mehr will. Ich komme zum Terminal, X will aber nicht starten. Die
Grafikkarte ist eine nvidia fx 5200 - die Rechner der LBS Handwerk u.
Industrie BZ. Das system-config-display bringt nicht viel, auch nicht
mit VGA compatible Karte und Generic LCD Panel Bildschirm. Habe auch
versucht, das xorg.conf eines gleichen, laufenden Rechners
herzukopieren...nix! Was ihm nicht passt ist das GLX(modul?) von nvidia.
Ich frage mich und euch:
- warum sucht er das GLX-Zeug von nvidia auch wenn ich einen "generic"
einstelle?
- kann ich das abschaffen?
- hab auch probiert, den Nvidia-treiber-installer vom terminal zu
starten, ohne Erfolg.
- das yum geht von hier nicht, auch nicht mit dem laufenden ntlmaps zur
ntlm-authentifizierung.
Und last but not least: da gibt es unter GNOME eine Einstellung im Menu,
die heisst NETWORK PROXY. Wenn's mich nicht taeuscht, ist das nichts
anderes als eine GUI fuer die environment vars HTTP_PROXY und FTP_PROXY
(usw.). De facto werden sie aber nicht gesetzt. Ich muss sie dann
manuell exportieren - jedes Mal! Wie vermeide ich das? Und immer zum
selben Thema: gelten die environment vars immer nur fuer den aktuellen
Benutzer? Kann man sie nicht auch systemweit setzen?
thanks&bye,
Federico
ich kaempfe seit einiger Zeit mit einer Fedora(4)installation, die nicht
mehr will. Ich komme zum Terminal, X will aber nicht starten. Die
Grafikkarte ist eine nvidia fx 5200 - die Rechner der LBS Handwerk u.
Industrie BZ. Das system-config-display bringt nicht viel, auch nicht
mit VGA compatible Karte und Generic LCD Panel Bildschirm. Habe auch
versucht, das xorg.conf eines gleichen, laufenden Rechners
herzukopieren...nix! Was ihm nicht passt ist das GLX(modul?) von nvidia.
Ich frage mich und euch:
- warum sucht er das GLX-Zeug von nvidia auch wenn ich einen "generic"
einstelle?
- kann ich das abschaffen?
- hab auch probiert, den Nvidia-treiber-installer vom terminal zu
starten, ohne Erfolg.
Mmm..., was war den in Einsatz, bevor die Probleme aufgetreten sind:
der Nvidia Treiber oder der native von Xorg ("nv")?
Was steht den genau in der /var/log/Xorg.0.log nachdem
das Problem auftritt?
- das yum geht von hier nicht, auch nicht mit dem laufenden ntlmaps zur
ntlm-authentifizierung.
Yum geht definitiv nicht mit NTLM...
Und last but not least: da gibt es unter GNOME eine Einstellung im Menu,
die heisst NETWORK PROXY. Wenn's mich nicht taeuscht, ist das nichts
anderes als eine GUI fuer die environment vars HTTP_PROXY und FTP_PROXY
(usw.). De facto werden sie aber nicht gesetzt. Ich muss sie dann
manuell exportieren - jedes Mal! Wie vermeide ich das? Und immer zum
selben Thema: gelten die environment vars immer nur fuer den aktuellen
Benutzer? Kann man sie nicht auch systemweit setzen?
Jo,
muesstest die Variablen nur in /etc/profile setzen:
am Ende einfach:
export HTTP_PROXY=xxx
Bye, Chris.
Chris Mair ha scritto:
x-------------cut----------------x
- das yum geht von hier nicht, auch nicht mit dem laufenden ntlmaps zur
ntlm-authentifizierung.
Yum geht definitiv nicht mit NTLM...
da taeuschst du dich! Eben dieses magische "ntlmaps" schafft es. Sei es
yum als auch apt-get nutzen naemlich eventuell vorhandene
proxy-Einstellungen (HTTP_PROXY, FTP_PROXY & co.). Der Wert
http://127.0.0.1:5865 als proxy sorgt dann standardmaessig dafuer,
dass alles klappt. Nach langem Herumgehacke haben wir's jetzt (seit
einiger Zeit) heraus! Aber genau auf dem Rechner geht logisch (!) das
auch nicht.
Was genau im log steht bzw. die Fehlermeldung weiss ich nicht mehr, es
geht jedenfalls um GLX-Dateien (libraries?) die er nicht finden kann.
Anderen ist in der Zwischenzeit das selbe passiert. Und so etwas wie
dbus-daemon will auch nicht mehr -weiss nicht ob's da einen Zusammenhang
gibt.
bye,
Federico
> Yum geht definitiv nicht mit NTLM...
>
da taeuschst du dich! Eben dieses magische "ntlmaps" schafft es. Sei es
yum als auch apt-get nutzen naemlich eventuell vorhandene
proxy-Einstellungen (HTTP_PROXY, FTP_PROXY & co.). Der Wert
http://127.0.0.1:5865 als proxy sorgt dann standardmaessig dafuer,
dass alles klappt.
Dass yum diese Umgebungsvariablen beruecksichtigt, daran habe ich
auch nicht gezweifelt. yum kann aber nicht NTLM.
ntlmaps kannte ich nicht: http://ntlmaps.sourceforge.net
Eure Admins so weit zu kriegen, einen standard-konformen
HTTP Proxy fuer einige bekannte Linux Mirror freizuschalten
waere wohl einfacher:
- Linux Server mit fester IP habt ihr, Squid ist darauf wohl
eh schon installiert
- dann ginge es um ein paar Zeilen Squid Konfiguration und
eine Regel im Firewall, damit er den Squid raus laesst
Nach langem Herumgehacke haben wir's jetzt (seit
einiger Zeit) heraus! Aber genau auf dem Rechner geht logisch (!) das
auch nicht.
Was genau im log steht bzw. die Fehlermeldung weiss ich nicht mehr, es
geht jedenfalls um GLX-Dateien (libraries?) die er nicht finden kann.
Anderen ist in der Zwischenzeit das selbe passiert. Und so etwas wie
dbus-daemon will auch nicht mehr -weiss nicht ob's da einen Zusammenhang
gibt.
mmm...
glx ist ein (recht wichtiges) Modul von X11.
Kannst Du mir sagen, was auf den Maschinen, die nicht mehr gehen
installiert war: der driver von Xorg (aus der Fedora Installation), oder
der von nvidia (extra download)?
Kann es sein, dass X jeweils nach einem update nicht mehr ging?
Bye, Chris.