Siduction Forum
Siduction Forum => Free Speech => Topic started by: bluelupo on 2011/06/03, 20:03:05
-
Hi zusammen,
heute habe ich nach ca. einwöchiger Pause wieder einen d-u durchführt und dabei sind mehrere schwerwiegende Fehler aufgetreten die mir ein völlig kaputtes System bescherten. Einen solchen Zustand von SID habe ich schon lange nicht mehr erlebt.
Fehler 1:
Der Bootvorgang hängt bei den NFS-Mounts für eine NAS-Box.
Fehler 2:
Das deutsche Tastaturlayout wird nicht geladen da eine Fehlermeldung beim Booten angezeigt wird. Als Folge kann ich mich nicht als root einloggen (wegen div. Sonderzeichen im Passwort)
Fehler 3: Im neuen KDE 4.6.3 werden Backgrounds und Aktivitäten durcheinander gewürfelt.
Fehler 4:
Der neue KDE 4.6.3 weigert sich transparente Plasmaoids anzuzeigen.
Fehler 5:
Seit Kernel 2.6.38-5 (slh) einfrieren meiner Systeme (3 von 4) beim Backup meiner Partitionen mit dd.
Fehler 6:
udev Fehlermeldungen seit einigen Wochen beim Booten.
Fehler 7:
Fehlermeldungen von rpcbind seit einigen Wochen beim Booten.
Ich habe mir allerdings gespart die Fehler zu suchen, weil mir ein lauffähiges System wichtiger ist als meine Zeit für ein kaputtes System zu verschwenden. Mein System habe ich kurzerhand komplett restored und somit auch wieder zum Laufen gebracht.
Mein Fazit aus diesem Vorfall ist mich nach einer Debian-Distribution umzusehen die konservativer ist. Ich habe mittlerweile für vier aptosid-Systeme einen exorbitanten Zeitaufwand um die Systeme aktuell und fehlerfrei zu halten. Diesen Zustand will ich nur noch übergangsweise aufrecht erhalten. Ich werde deshalb in nächster Zeit alle meine Systeme auf LinuxMint-Debian oder das pure Debian-Testing umstellen.
Es tut mir Leid zu sagen das aptosid und SID einfach nicht mehr meine favorisierten Linuxdistrobutionen sind. aptosid wegen des nicht mehr funktionierenden Kernels für meine HW und meiner Ansicht zu häufigen Kernelupgrades. Debian SID ist wegen zu häufiger schwerwiegender Fehlerzustände für mich nicht mehr in vernünftiger Zeit wartbar.
Im Prinzip hat der aktuelle Zustand von aptosid und Debian SID meine seit längerer Zeit gehegten Wechsel zu einer für mich brauchbarer Distri nur noch forciert.
It's time to say goodbye ;-)
-
Fehler 2:
Das deutsche Tastaturlayout wird nicht geladen da eine Fehlermeldung beim Booten angezeigt wird. Als Folge kann ich mich nicht als root einloggen (wegen div. Sonderzeichen im Passwort)
Das kann ich bestätigen, ist seit dem D-U vorhin genauso bei mir.
Läßt sich auch nicht mit dem vollen Programm dpkg-reconfigure console-data
dpkg-reconfigure console-common
dpkg-reconfigure console-setup
dpkg-reconfigure keyboard-configuration
reaktivieren.
Zurückspielen eines Backup brachte erst Hilfe.
Ich hab den Kernel in Verdacht.
...
-
Hi BlueLupo,
sowas ist mehr als ärgerlich. Von daher ist Deine Suche nach einer stabileren Distribution nur allzu verständlich.
Ich hoffe, Du berichtest trotzdem mal, wo Du gelandet bist und ob es dort wirklich besser (oder nur anders) läuft. :)
It's time to say goodbye ;-)
Ciao ....
-
Also ich kann nur sagen: Bei mir läuft es .. hab keine der genannten Probleme ...
-
Hmm,
größere Probleme kann ich auch nicht bestätigen. Zur Zeit ( gerade DU gemacht) mault die Kiste beim Hochfahren dass rpcbind eine Datei nicht findet und die nfs-mounts timen aus. Hat die Kiste jedoch endlich gebootet scheint alles (auch die nfs-mounts) da zu sein. Muss ich mir noch genauer anschauen.
Ich werde zumindest vorerst bei sid bleiben und solange es geht auch aptosid als Basis verwenden.
Ich verwende allerdings auch die "Fremdkernel" von Liquorix.
Grüße
Reiner
-
Da ich ebenfalls arge Probleme mit sid, gerade was den Bootprozess angeht, hatte, hatte ich in letzter Zeit hauptsächlich mit Arch gearbeitet. Mir fiel dabei vornehmlich auf, dass udev von 168 auf 171 aktualisiert wurde, ohne die Zwischenschritte die ich hier bei sid erleben musste. Als jemand der sich mit Arch nicht sonderlich gut auskennt kommt es mir oberflächlich so vor, als gäbe es dort eingehendere Prüfmechanismen, einschließlich entsprechender Umsetzungen, was neue, problematische Pakete angeht?
-
Debian testing hat zur Zeit so ziemlich dasselbe wie Debian sid, außer die problematischen Pakete.
-
Hi ralul,
Debian testing hat zur Zeit so ziemlich dasselbe wie Debian sid, außer die problematischen Pakete.
....die da wären?
-
Hey Bluelupo,
ich kann Deinen Frust gut nachvollziehen. In letzter Zeit ist die See auch für meinen Geschmack sehr stürmisch. Ein DU ist momentan doch eher eine 50:50 Glückspiel...
Dazu Ärgernisse, wie langes warten auf KDE 4.6, Iceweasel 4 usw.
VDR liegt dafür in einer undefinierten V 1.7 vor, welche so vermutlich nicht gewollt ist, da Klaus diese vderdevel 1.7 nennt. VDr ist bei 1.6. Für beide gibt es alle Plugins (z.B. bei e-tobi) aber eben nicht für vdr 1.7.
Naja, lange Rede, kurzer Sinn, ich denke SID wird sich wieder beruhigen - alles wird gut... bis zum nächsten udev update ;-)
Ich danke Dir auf jeden Fall für Rat und Tat in vielen Jahren!!!
Schau mal wieder vorbei - denn wir werden Dich vermissen!
-
@bluelupo, wenn ich eine preferenz für unstable von 1002 setze und apt-get dist-upgrade:
Die folgenden Pakete werden ENTFERNT:
console-terminus
Die folgenden NEUEN Pakete werden installiert:
console-setup-linux linux-headers-2.6.39-1-amd64 linux-headers-2.6.39-1-common linux-image-2.6.39-1-amd64
linux-kbuild-2.6.39 xulrunner-1.9.1
Die folgenden Pakete werden aktualisiert (Upgrade):
base-files console-setup cron debianutils dictionaries-common exiv2 gconf-defaults-service gconf2 gconf2-common initscripts
keyboard-configuration libbsd0 libcdaudio1 libdiscid0 libdjvulibre-text libdjvulibre21 libexiv2-9 libgconf2-4 libgd2-noxpm
libgl1-mesa-dri libgl1-mesa-glx libgssapi-krb5-2 libgudev-1.0-0 libidl0 libk5crypto3 libkrb5-3 libkrb5support0 liborbit2
libraptor2-0 libudev0 libvirtodbc0 libxml-parser-perl libxml2 libxml2-utils linux-headers-2.6-amd64 linux-image-2.6-amd64
linux-libc-dev module-init-tools python-libxml2 rsyslog sysv-rc sysvinit sysvinit-utils udev upower
virtuoso-opensource-6.1-bin virtuoso-opensource-6.1-common x11-common xauth xbase-clients xserver-xorg xterm
Die folgenden Pakete werden durch eine ÄLTERE VERSION ERSETZT (Downgrade):
btrfs-tools docbook-xsl docbook-xsl-doc-html dosfstools e2fslibs e2fsprogs iceweasel libglib2.0-data libvte-common libvte9
libxklavier16 libxtst6 p7zip p7zip-full
52 aktualisiert, 6 neu installiert, 14 durch eine ältere Version ersetzt, 1 zu entfernen und 0 nicht aktualisiert.
-
sehr hilfreich ;)
greetz
devil
-
Ok:
sysv-rc
sysvinit
sysvinit-utils
udev
upower
libgudev-1.0-0
base-files
console-setup
initscripts
keyboard-configuration
-
Es war ein Fehler soooo lange zu warten - heute habe ich auch mal ein Update auf meinem dritten Rechner versucht - Abbruch schon beim DU - ein Dienst war abgestürzt - welcher ? - Neustart - Login und danach nichts mehr schwarz - keine Mouse, keine Tastatur - Neustart - Mischung von kde und Konsole auf einem unbekannten Betriebssystem ohne Mouse und Tastatur.
Alle neuen User ohne Expertenwissen können so etwa sür die Umwelt tun - Strom sparen.
Aptosid ist schon lange ein Geist - aber wer nach 10 Tagen ein DU macht tötet auch den Geist - erstaunlich - Dracula war zäher.
-
Wir hatten mal nen Thread "Ist sidux für Anfänger geeignet" (frei zitiert). Es ergab sich ein leichter Überhang derjenigen, die feststellten, dass eine sid-basiertes Debian-Derivat durchaus nicht nur für Anfänger geeignet ist. Es ist erfrischend für Körper und Geist. ;-)
Regelmäßiges d-u gehört dazu, und der Einsatz von aptosid für den richtigen Zweck.
-
Nuja, ich kann das Alles irgendwie nicht nachvollziehen.
-
@towo: Sehe ich auch so. Nicht einer dieser Probleme hier hab ich auch nur ansatzweise bisher gehabt ... Zumindest zur udev-fehlermeldung wird im Forum mind. 2x gesagt, was dazu installiert werden muss ;)
-
ich auch nicht, und die aussagen von oldie, naja...
greetz
devil
-
@oldie: Ich habe am Freitag den Läppi meiner Eltern auf den aktuellen Stand gebracht, der hatte seit Februar kein DU mehr und ich habe in der Nacht davor meinen dritt PC auf den neusten Stand gebracht, der hatte 2010-03 drauf. Nie aktualisiert, also mindestens 5-6 Monate alte Pakete. Dort gab es einen Abbruch des DU, dann habe ich es neu gestartet und musste händisch ein Packet entfernen. Lief ansonsten alles glatt.
Insofern stimme ich towo zu. Wie man mit nur 10 Tagen Pause alles zerstört ist mir ein kleines Rätsel. meine Freuquenz liegt ca. auch immer so in dem Rahmen: Alle 1-2 Wochen ein DU.
-
Insofern stimme ich towo zu. Wie man mit nur 10 Tagen Pause alles zerstört ist mir ein kleines Rätsel. meine Freuquenz liegt ca. auch immer so in dem Rahmen: Alle 1-2 Wochen ein DU.
Das läßt sich ohne tiefere Einblicke ins System ohnehin nicht beantworten. Weiss der Geier, was die einzelnen User über preferences, Fremdquellen, etc. konfiguriert haben.
-
@bluelupo:
Fehler 2:
Das deutsche Tastaturlayout wird nicht geladen da eine Fehlermeldung beim Booten angezeigt wird. Als Folge kann ich mich nicht als root einloggen (wegen div. Sonderzeichen im Passwort)
kann ich nachvollziehen, siehe den Post von Ferdinand in den Warnungen - geht wieder - . Allerdings hatte ich das Problem, dass ich vom deutschen Layout nicht mehr wegkam.
Fehler 6:
udev Fehlermeldungen seit einigen Wochen beim Booten.
Kann ich nachvollziehen, ist nicht schön. Ich habe mich dazu entschlossen, das einfach zu ignorieren und einfach nichts zu tun. Allerdings bin ich grad am überlegen, mein Startsystem von debian sid auf stable oder arch umzustellen. Wobei mir arch am stabilsten vorkommt. :twisted: Von den restlichen Problemen blieb ich verschont. Momentan ist es halt ein wenig wild, wobei sich natürlich wieder einmal die Sinnfrage für den täglichen Einsatz stellt.
Um ganz deutlich zu werden: Findest Du etwas, was stabiler und aktuelle als sid ist, ganz laut rufen. Ein weiteres Kriterium: Ich will mir nicht in einem halben Jahr wieder mit pre-alpha-Software ins Knie schießen, die dann in diesem Zustand verbleibt. Damit fallen 2 Distributionen mit debian-Paketen aus. Bei Sid habe ich wenigstens Abwechslung und kann über sich ändernde Fehler kotzen. Bei den nicht namentlich erwähnten Distris sind die Probleme für mindestens 6 Monate statisch. Was ist jetzt besser?
In die Hölle RPM-basierter Distributionen möchte ich mich nicht begeben, das ist mir zu heftig, so verzweifelt bin ich nicht. Für den Desktop solltest Du Dir eventuell mal Arch anschauen, da ist der Wahnsinn Programm und hat Methode. Da die Jungs ihr Programm beängstigend konsequent durchziehen, kann ich von meiner Wenigkeit behaupten, das das die Distribution mit den wenigsten Problemen ist, die ich bisher probiert habe. Allerdings ist die Einarbeitung nicht ganz ohne und dauert seine Zeit, das Wort Problem ist auch ein wenig anders besetzt. Fakt ist aber: Läuft es einmal, ist es verdammt schwer, diesen Zustand in nicht laufend zu ändern.
-
Wir hatten mal nen Thread "Ist sidux für Anfänger geeignet" (frei zitiert). Es ergab sich ein leichter Überhang derjenigen, die feststellten, dass eine sid-basiertes Debian-Derivat durchaus nicht nur für Anfänger geeignet ist. Es ist erfrischend für Körper und Geist. ;-)
Regelmäßiges d-u gehört dazu, und der Einsatz von aptosid für den richtigen Zweck.
Hi RoEn,
eine Erfrischung ist ab und zu ganz gut und du hast Recht wenn du feststellst das Sidux bzw. aptosid keine Distri für Anfänger ist. Aber der Spass und die Erfrischung hört sich auf wenn ich gerade mal eine Woche Pause mache zwischen zwei d-u's und mir dieser dann ein absolut unbrauchbare Systeme beschert mit dem ich nicht mehr arbeiten kann. Ich habe seit Beginn des Jahres bereits fünfmal eine Situation in aptosid erlebt, bei der ich ein unbootbares oder nicht für meine Zwecke benutzbares System vorgefunden habe. Ich habe es meiner vorsichtigen Strategie zu verdanken das ich die betroffenen Notebooks innerhalb von 30 Minuten zurücksichern konnte.
Der Arbeitsaufwand den mir aptosid bzw. DebianSID momentan beschert halte ich für mich nicht mehr tragbar. Es gibt auch noch ein Leben ausserhalb von PC's ;-)
Aufgrund der aktuellen Fehlersituation habe mich entschlossen meine Systeme, wie schon weiter oben beschrieben, auf eine "pflegeleichtere" Linuxvariante umzustellen. Ich teste gerne Programme im Stile von SID, aber wenn es einen nur noch "kaputte" Systeme beschert dann stimmt etwas an der Qualität von einander abhängigen Systemkomponenten in SID nicht mehr.
-
@towo: Sehe ich auch so. Nicht einer dieser Probleme hier hab ich auch nur ansatzweise bisher gehabt ... Zumindest zur udev-fehlermeldung wird im Forum mind. 2x gesagt, was dazu installiert werden muss ;)
@reddark: die udev sind nur geringsten meiner Probleme. Was mich wirklich wurmt ist das ständige NFS/rpcbind Problem und meine Freezes bei einem ganz simplen Backup einer Partition mit dd der auf eine NAS-Box (mit NFS angebunden) schreibt. Das Problem ist reprozierbar auf drei meiner Kisten wenn sie einen Kernel nach 2.6.38-6.slh installiert haben. Für mich ist das ein unhaltbarer Zustand der dringend nach einer Lösung "schreit".
-
Was mich wirklich wurmt ist das ständige NFS/rpcbind Problem und meine Freezes bei einem ganz simplen Backup einer Partition mit dd der auf eine NAS-Box (mit NFS angebunden) schreibt.
Ok, das nutze ich nicht, weshalb ich dazu logischerweise nix sagen kann.
Aber wie gesagt, alles andere, was mir mein System bieten soll, läuft bei mir ohne Probleme ;)
-
Aber wie gesagt, alles andere, was mir mein System bieten soll, läuft bei mir ohne Probleme ;)
...da hast du Glück gehabt ;-)
Bei mir ist's halt die massive Häufung der Probleme die mir zu schaffen macht.
-
Was mich wirklich wurmt ist das ständige NFS/rpcbind Problem und meine Freezes bei einem ganz simplen Backup einer Partition mit dd der auf eine NAS-Box (mit NFS angebunden) schreibt.
Wir greifen per NFS mit zwei Desktops und zwei Laptops über WLAN auf eine NAS-box zu, auf der alle unsere Daten liegen. Das rpcbind-Problem besteht nur in ein paar Meldungen beim Boot, die ignoriert werden können. Der Übergang von portmap auf rpcbind erfolgte bei einem d-u ohne Probleme. Backup wird täglich gemacht per luckybackup und zwar (ungewöhnlich) vom NAS auf die Rechnerplatten. Insofern kann ich die geschilderten Probleme nicht nachvollziehen.
Aber wie schon oben erwähnt, man weiß nicht, was der jeweilige "Beschwerdeführer" alles auf seinem Rechner installiert oder geändert hat.
Ich bin seit Kanotix Xmas-edition dabei und habe nie ein Problem gehabt, das sich nicht mit Foren- und IRC-Hilfe innerhalb weniger Tage lösen ließ.
Für mich gibt es immer ein Indiz: Wenn andere das Problem nicht haben, muss es an meiner Konstellation liegen, also suche ich zuerst bei mir, bevor ich aptosid/sid/debian verteufele.
Die gilt hoffentlich auch noch für mein derzeitiges Problem mit dem plasma-desktop Auslastung --> http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=987
Gruß
oduffo
-
Auch nicht schlecht:
Ich wollte meinen überquellenden Downloadordner mal aufräumen, habe einige Dateien verschoben oder gelöscht. Nun sind alle Dateien in Dolphin 4KB groß, egal welche. Das ist Gottseidank nur in Dolphin so, die Dateien sind noch OK. :?
-
Hi oduffo,
Das rpcbind-Problem besteht nur in ein paar Meldungen beim Boot, die ignoriert werden können. Der Übergang von portmap auf rpcbind erfolgte bei einem d-u ohne Probleme.
....eine Fehlermeldung besagt immer das es ein Problem gibt. Meine Einstellung kommt nicht von irgendwo her sondern das ich einige Jahre im Second-Level-Support gearbeitet wo genau diese Fehlermeldungen Tagesgeschäft waren.
Backup wird täglich gemacht per luckybackup und zwar (ungewöhnlich) vom NAS auf die Rechnerplatten. Insofern kann ich die geschilderten Probleme nicht nachvollziehen.
Das ist absolut nicht vergeliechbar mit meiner Situation vergleichbar. Luckybackup benutzt rsync und hat wenig mit einem dd zu tun.
Aber wie schon oben erwähnt, man weiß nicht, was der jeweilige "Beschwerdeführer" alles auf seinem Rechner installiert oder geändert hat.
Es sind gewöhnliche Standard NB's (zB LENOVO T60) ohne irgendwelche "verdrehte" Konfigurationen
Für mich gibt es immer ein Indiz: Wenn andere das Problem nicht haben, muss es an meiner Konstellation liegen, also suche ich zuerst bei mir, bevor ich aptosid/sid/debian verteufele.
...das hilft mir jetzt aber nicht wirklich weiter ;-)
Aber wenn an 3 von meinen 4 Systemen z.B. die Probleme mit NFS und dem Freeze auftreten hat das erst mal nichts mit meiner Konfiguration zu tun. Das ist eindeutig ein aptosid-Kernel Problem, das seit Wochen nicht gefixt wurde.
-
Aufgrund der aktuellen Fehlersituation habe mich entschlossen meine Systeme, wie schon weiter oben beschrieben, auf eine "pflegeleichtere" Linuxvariante umzustellen.
Die Erfahrungen von agaida mit Arch decken sich komplett auch mit meinen. Arch ist bei mir im Linux-Bereich bisher das pflegeleichteste System gewesen.
Ich nutze beides, hatte selber allerdings keine grösseren Probleme mit aptosid dist-upgrades.
Sollte dein Entschluss auf etwas anderes umzusteigen aber unumstösslich und felsenfest getroffen sein, würde ich auch Arch einen Blick widmen.
-
bluelupo,
ich kann grade deinen report eines bugs im kernel auf aptosid.com nicht finden...
greetz
devil
-
Aufgrund der aktuellen Fehlersituation habe mich entschlossen meine Systeme, wie schon weiter oben beschrieben, auf eine "pflegeleichtere" Linuxvariante umzustellen.
Die Erfahrungen von agaida mit Arch decken sich komplett auch mit meinen. Arch ist bei mir im Linux-Bereich bisher das pflegeleichteste System gewesen.
Ich nutze beides, hatte selber allerdings keine grösseren Probleme mit aptosid dist-upgrades.
Sollte dein Entschluss auf etwas anderes umzusteigen aber unumstösslich und felsenfest getroffen sein, würde ich auch Arch einen Blick widmen.
Ich bin mir nicht sicher, woran es liegt, aber seitdem ich arch zum Laufen (dauerhaft und mit Feinheiten) überredet habe, hatte ich eigentlich mit keinerlei Distribution mehr größere Probleme. Vielleicht ist das einfach darauf zurückzuführen, dass man abstumpft und sich gleichzeitig die persönlichen Möglichkeiten erweitern.
Ich bin vor dem großen Rundumschlag immer dafür, direkte Rache am Subjekt des Ärgers zu nehmen. Wenn also wirklich der Kernel Stein des Anstoßes sein sollte - weg damit. Das ist grade mal ein apt-get entfernt. Sollte dann das Problem beseitig sein, weiss man sicher, dass es am Kernel lag. (Und hat das Problem nicht mehr). Danach kann man slh immer noch regelmäßig anschubsen - ob es was bringt oder nicht. Ist allerdings meine persönliche Meinung. Genau so wie die Meinung bin, dass ich nicht unbedingt jeder Entwicklung folgen muss, wenn ich partout nicht will. Und aptosid reduziert sich für mich nicht auf ein Bestandteil und sei es der Kernel. Linux gibt einem die Freiheit, alles zu tun und zu lassen, was man will und kann. Nutzen muss man diese Freiheit allerdings selbst und das kann schwer werden.
-
außer das mesa-dri meine ATI-karte nicht mehr unterstützt und ich gezwungen bin libgl1-mesa-swx11 zu benutzen, habe ich keinerlei probleme mit debian/sid Xfce.
gruß
brummer
-
bluelupo,
ich kann grade deinen report eines bugs im kernel auf aptosid.com nicht finden...
greetz
devil
Hi devil,
da hatten wir schon mal darüber diskutiert und meine Meinung hat sich dazu nicht geändert warum ich keine Bugreports mehr an aptosid berichten werde (und ausserdem nicht kann). Herr Stefan Lippers-Hollmann (slh) hat mich persönlich zu sidux Zeiten aus seinen Dunstkreis "verbannt". Ich werde einen Teufel tun noch mal irgendetwas zu tun was seine Aufmerksamkeit "erregen" könnte.
-
Die Erfahrungen von agaida mit Arch decken sich komplett auch mit meinen. Arch ist bei mir im Linux-Bereich bisher das pflegeleichteste System gewesen.
Mich würde schon auch Arch interessieren aber die Lernkurve schreckt mich momentan noch ab. Aber der Leidensdruck wird größer bei mir.
Ich bin vor dem großen Rundumschlag immer dafür, direkte Rache am Subjekt des Ärgers zu nehmen. Wenn also wirklich der Kernel Stein des Anstoßes sein sollte - weg damit. Das ist grade mal ein apt-get entfernt. Sollte dann das Problem beseitig sein, weiss man sicher, dass es am Kernel lag. (Und hat das Problem nicht mehr).
...ja da hast du Recht. Der Kernel towo-Kernel hat übrigens das gleiche Problem, aber es gibt noch Debian-Standard- oder Liquorix-Kernel. Ich werde es testen.
Genau so wie die Meinung bin, dass ich nicht unbedingt jeder Entwicklung folgen muss, wenn ich partout nicht will.
...das tue ich schon lange nicht mehr ;-)
Und aptosid reduziert sich für mich nicht auf ein Bestandteil und sei es der Kernel. Linux gibt einem die Freiheit, alles zu tun und zu lassen, was man will und kann.
...wenn ich aber aptosid-Kernel durch einen alternativen ersetze was bleibt dann noch von aptosid übrig. Das ist dann zu 99% Debian SID. Da würde ich dann gleich zum puren Debian umsteigen.
-
wenn ein kernel einen bug hat, so halte ich es für ziemlich unsinnig, auf persönliche befindlichkeiten rücksicht zu nehmen.
wenn debian das so machen würde, gäbe es nur halb so viele bugreports :)
greetz
devil
-
@devil: da bin ich anders gepolt wie du. Ich bin über dieses Alter hinaus das mich irgendwelchen Zwängen bedinungslos unterwerfen müsste. Zu einer fruchtbaren Zusammenarbeit zwischen Kernelentwickler und Anwender gehört auch eine Portion Kommunikationsfähigkeit und Anstand von beiden Seiten. An der hat es zu den Vorfällen in der Vergangenheit seitens des aptosid-Kernelentwicklers gemangelt.
Außerdem stehe ich zu meinen Befindlichkeiten ;-)
-
@bluelupo: Wozu willst Du auf SID umsteigen? Wie Du schon bemerkt hast, soviel anders ist das auch nicht. Abgesehen von Handbuch, ceni, einigen Settings, Hotfixes etc.
Da ist nur eine kleine Kleinigkeit: Hier versteht man Dich und stellt Dir nicht die Frage, warum Du überhaupt Sid benutzt. Das fand ich in reinen debian-Foren immer abstoßend - ich will mir halt das übliche Gelaber über stable, testing und Zielgruppen (und welcher man der Meinung anderer nach angehört) nicht geben. Und da ist halt aptosid zum Glück die Variante, einen debian-Desktop dauerhaft mit angemessenen DEs zu betreiben. Bei meinen Servern habe ich keinerlei Probleme damit, Sid zu fahren. Nur eine Produktionsmaschine läuft stable (in den Teilen, die von debian sind). Die größten Fehlerquellen sind entfernt: X, DEs, MySQl, Ruby. Und der Rest läuft bisher ohne Überraschungen durch.
-
@bluelupo: Wozu willst Du auf SID umsteigen?
....nein will ich nicht. Das war nur als Beispiel gemeint. Umsteigen werde ich auf Testing oder LMDE (also auch Testing).
Da ist nur eine kleine Kleinigkeit: Hier versteht man Dich und stellt Dir nicht die Frage, warum Du überhaupt Sid benutzt. Das fand ich in reinen debian-Foren immer abstoßend - ich will mir halt das übliche Gelaber über stable, testing und Zielgruppen (und welcher man der Meinung anderer nach angehört) nicht geben.
Ich habe diese Erfahrung Mint- bzw. Debianforen nicht gemacht. Es geht ja nicht um Probleme mit dem einem oder anderem Forum, sondern die Häufigkeit von Fehlerquellen die mich momentan in SID betrifft. Ich will einfach meinen Zeitaufwand wieder auf ein vernünftiges Maß reduzieren und dazu brauche ich eine (debianbasierte) Linuxvariante die weniger systemkritische Fehler hat.
Bei meinen Servern habe ich keinerlei Probleme damit, Sid zu fahren.
...das würde ich mir bei einen reinen Server nicht zumuten, aber das ist wie gesagt ansichtssache ;-)
-
kano hat doch gerade ne neue version "Hellfire" rausgbracht, da kenst de dich doch aus und bist quasi daheme. :wink:
http://www.kanotix.com/Article247.html
-
Mich würde schon auch Arch interessieren aber die Lernkurve schreckt mich momentan noch ab. Aber der Leidensdruck wird größer bei mir.
Ich finde, agaida übertreibt hier deutlich. Arch ist - verglichen mit Debian sid - nicht schwerer zu erlernen, eher leichter. Das Konzept der Abhängigkeiten ist etwas flexibler, aber jemand, der von aptosid kommt, dürfte sich innerhalb von ein bis zwei Stunden gut in Arch einarbeiten und hat dann für lange Zeit ein gut lauffähiges System.
Massive Vorteile von Arch liegen bei flexibleren Abhängigkeiten und deutlich höherer Geschwindigkeit.
-
Das mit dem Leidensdruck stammt nicht von mir, ich übertreibe auch nicht, wenn ich behaupte, dass arch gewöhnungsbedürftig ist. Es geht nicht darum, ein funktionsfähiges System zusammenzukloppen. Das ist in fast jedem Linux in kürzester Zeit getan. Es geht vielmehr um die Feinheiten und Ecken und Kanten. Da ich recht viel und gerne schraube, haben sich meine Installationen mit mir entwickelt. Von optimal und in Stein gemeisselt kann aber immer noch keine Rede sein. Den Zustand der Zufriedenheit habe ich erst an zwei bis drei eher unwichtigen Stellen erreicht.
So ein Überflieger, dass ich nach ein bis zwei Stunden ein neues System beherrsche, bin ich nicht. Bei mir dauert das meinst länger als ein bis zwei Monate, ein bis zwei Jahre wären noch realistischer. Meine persönlichen Preferenzen sind klar. Ich komme von arch, debian war und ist mir an einigen Stellen viel zu kompliziert und ohne arch hätte ich nie gelernt, ein debian in Ansätzen so aufzusetzen, wie ich es haben möchte. Das habe ich dann ja nach einem knappen Jahr fast geschafft. Das Arch nun schneller sein soll als ein vernünftig aufgesetztes anderes Linux kann ich ausdrücklich nicht bestätigen. ich kann mich da auch täuschen, weil ich momentan noch jeden Tag dazulerne. Vielleicht fehlt mir da auch nur der Vergleich, eigentlich ist auf meinen Maschinen jedes Linux schnell gewesen. Wenn dem mal nicht mehr so ist, ist halt wieder mal der homöopatische Einsatz neuer Hardware notwendig. Der ist auch zum Ende des Jahres geplant.
Die 1 oder 2 Platten, die dann Verwendung finden werden, hat devil schon vorgestellt (alternativ könnte man auch Revos nehmen), der Prozessor, das zukünftige Board und die Grafik sind noch nicht auf dem Markt. Es könnte aber auch sein, dass ich wieder mal ganz unrealistische Ansprüche an ein System und mich habe. Im Endeffekt wird das wohl alles mal bei Gentoo landen. Den Umstieg auf Gentoo werden ich wagen, wenn ich eine Maschine haben, die auf die einfache Geschwindigkeit 1 Kernel/min kommt. Das wären dann so ungefähr menschenwürdige Wartungszeiten für eine quellbasierte Distribution. Bis dahin ist noch ein wenig Zeit, die ich wohl mit Lernen und Frickeln verbringen werde.
-
Hallo,
also ich kann den bluelupo schon nachvollziehen. Ich habe bisher absolut keine der Erfahrungen, die er gemacht hat mit Aptosid. Ich habe auf dem Rechner nicht mal eine OS - Sicherung. Im Zweifel wird neu Installiert, die Daten sind noch am NAS gespiegelt.
Ich bleibe dabei: Rolling rules ! Daher lieber die Nachteile von (Apto-)SID als alle halbe Jahre ein DU und großes Zittern was alles anders ist.
Mein Vorschlag: lass einen oder 2 Rechner auf Aptosid und geh mit dem Rest auf Stable( das ist definitiv eine konservative Debian - Disto).
gruß.
-
ich kann towo nur zustimmen
meine kiste macht seit monaten keine zicken beim updaten
und den rechner meiner freundin hab ich nach 5 monaten ohne d-u ohne probleme aktualisiert.....
ich bastel aber auch nicht allzuviel selbst rum....;-)
mfg
-
Hallo,
bei diesen Diskussionen um andere Distributionen lese ich des öfteren von rpm Höllen oder ähnlichem.
Kann mir bitte mal ein Vertreter dieser rpm Höllen Theorie erklären, was es damit auf sich hat?
zypper löst exzellent Abhängigkeiten unter rpm Paketen auf, es ist ähnlich komfortabel wie apt-get.
Vor kurzem kam Mageia heraus, ich habe es seit gestern testweise auf meinem Desktop PC. Von rpm Höllen kann ich beim besten Willen nichts merken, urpmi und Konsorten an der Konsole funktionieren sehr gut.
Ich befürchte, bei der Abneigung gegen rpm basierte Distributionen werden Klischees aufrecht erhalten, die vielleicht mal ihre Berechtigung vor einigen Jahren hatten.
Viele Grüße,
Holger
-
Dependency Hell hast Du in jeder Distribution, davon ist debian, arch und natürlich auch suse nicht verschont. Den Mist haben wir doch grade mit Perl durch. Wenn sich das in Suse so gebessert hat, toll, ich hab da wahrscheinlich meine Antipathien in länger aufgebaut, als ich Linux aktiv benutze.
Ich kann mich nur lebhaft an die Panik vor Update-Orgien von RedHat erinnern - bei denen ich dank keiner Ahnung nicht mitspielen musste. Die Flüche waren in keinster Weise druckreif und unsere Jungens haben echt gekämpft. Aber nichts hält bekanntlich so lange wie ein Vorurteil.
Und irgendwie hält sich das bestimmt nicht unbegründete Gerücht, dass man bei RPM-basierten Distributionen halt mal öfter in die braune Masse greift, wenn man hart an der Grenze am werkeln ist oder zwingend bestimmte Versionen braucht.
-
Kann auch nicht nachvollziehen, warum Sid auf einmal "desolat" sein sollte.
Benutze Sidux/Aptosid seit 2007 und habe bis heute keine großen oder nicht in kürzester Zeit lösbare Probleme gehabt.
Wenn ich an die Zeiten des großen Wechsels von KDE denke (3 zu 4) sind die jetzigen Probleme doch eher Bagatellen.
Bin selbst nur ein erfahrener User ohne sehr tiefe Linuxkenntnisse, aber mit etwas Aufmerksamkeit und auch Geduld beim Dist-Upgraden gelingt es mir bisher ohne Probleme ein stabiles System zu halten.
Habe normalerweise einen 2-4-wöchigen Upgrade-Rhytmus, der sich nach Lektüre im Forum auch mal auf 6 oder 8 Wochen ausdehnen kann, je nach Situation.
Ich denke daß es mit etwas Sensibilität und vor allem Geduld kein Problem ist die zwangsläufigen Hürden eines Rolling-Releases zu umgehen.
Ist doch "Wurscht" ob das System 2 Tage oder 3 Wochen alt ist, wenn man nicht auf "Testen" scharf ist.
Bin jedenfalls "glücklich" mit meiner Distrie.
Gruß wkauz
-
Hallo - ich habe ein reines aptosid mit den Extras Opera, Firefox, Softmaker Office und gmic für Gimp - sonst nichts und auf unserem Laptop ist kein DU mehr möglich - letztes war vor dem Update von KDE. Mitten im DU startet der Rechner neu und bleib bei einer Mischung aus Konsole und KDE Startbildschrim hängen - ohne Tastatur und Mouse - das ist momentan die nackte Wahrheit - und das kann sich jeder in, um HH ansehen.
Die zwei Rechner die laufen vergessen bei jeden zweiten oder dritten Neustart die Bildschirmauflösung und teilen den Rest auch mal in drei Bildschirme auf - und heute wurde dann auch mal wieder die Einstellung für den USB Stick vergessen (automatisch einbinden).
Als Krönung hat ein Rechner als neue Herausforderung einen Abbruch beim Neustart - hängt beim Login in der Konsole - und das wars - 3 - 8 Neustarts bringen dann die Kiste wieder zum laufen.
Und nochmal - nichts gebastelt - ganz bewusst - rein und sauber 64 Bit und vor jedem DU ein Backup gemacht und oft gebraucht.
Gruß Oldie
-
zypper löst exzellent Abhängigkeiten unter rpm Paketen auf, es ist ähnlich komfortabel wie apt-get.
RPM ist leider nicht RPM. Es gibt das "alte" RPM in Version 4 + tausend (distro-spezifischen) Patches und RPM5 was inkompatibel ist zu machen verwendeten RPM4-Patches -- des Result ist, dass man sich das System noch ordentlicher zerlegt als man es bei debian-Paketen tut, wenn man die einer anderen Distro nimmt…
Jede RPM Distro hat also quasi sein eigenes "dpkg" wenn man so will: Das ist für Frontendentwickler natürlich nicht so positiv -- und für Paketbauer auch, den bei debian muss man meist "nur" das Sourcepaket in der "anderen" Distro bauen und nicht großartig Änderungen vollführen.
Pakete sind dann auch das Stichwort: Debian hat das große Glück viele Pakete zu haben. Bei vielen anderen ist die Auswahl durchaus geringer -- in den offiziellen Quellen. Häufig gibt es ihrgendwo anders doch wieder alles mögliche - das Problem: Qualität dieser Pakete und Maintaining. Nicht selten gibt es mehrere Archive die die selbe Version unterschiedlich paketieren - wenn man dann das Pech hat die Version aus dem falschen Archive installiert zu haben ist zwar die Abhängigkeit formal erfüllt, effektiv kann das Paket aber mit der Version gar nicht arbeiten -> Welcome to dependency hell!
Das Problem ist ubuntu mit seinen PPA's nicht gerade fremd und auch hier kennen wir ja alle ein gutes Beispiel: Die inoffiziellen Multimediapakete die inkompatible sind mit dem was aus den offiziellen Quellen kommt.
Insgesamt ist das Problem in Debian aber unbekannter, weil einfach von haus aus 30.000 Pakete mitkommen - damit ist schoneinmal sehr viel abgedeckt und da auch (theoretisch) alle Pakete gleich sind genießt man von der Warte her weniger Probleme - daher wird sich da auch eher nicht dran ändern, auch wenn gerade wieder ein Thread zum Thema "core" vs. "main" Pakete auf debian-devel rumeiert…
-
oldie,
sorry, ich glaub das so alles nicht.
ich habe 3 rechner derzeit mit aptosid, von denen ich 2 täglich produktiv nutze und täglich dist-upgrade.
da gibt es _nichts_ was mich am produktiven arbeiten hindert.
greetz
devil
-
@DonKult:
Das ist das Schöne hier, wieder was dazugelernt, auch wenn ich es nicht bis zum Ende begriffen habe. Das muss erst mal sacken.
Zum Thema desolat zurück: SLH und andere definieren den Kernel wirklich als bleeding. Das ist mir manchmal zu grenzwertig. Das kuschelt nicht wirklich immer. Zum testen hab ich eigentlich Arch. Wenn SLH schneller ist als die Buben von Arch, brauche ich mir wenigstens keine Sorgen mehr um das nächste Arch-Upgrade machen. Geplant war das andersrum ;) Fakt ist aber auch, daß wenn man der Zeit ein wenig vorraus ist, nicht immer auf das größte Wohlwollen des Auditoriums hoffen darf. Für diesen Fall gab oder gibt es aber ganz eindeutig Alternativen, die sehr gut auch ohne Distributionswechsel laufen.
Da ich auf ein funktionsfähiges Entwicklungssystem angewiesen bin, habe ich eigentlich immer einen aktuellen Clone in der Hinterhand. Den hab ich eigentlich noch nicht wirklich gebraucht - ausser bei den wenigen Malen, wo ich einfach keinen Bock hatte, mich um Kleinigkeiten zu kümmern, die sofort zu beheben wahrscheinlich nur unwesentlich länger gedauert hätte, als in den Clone zu booten und da weiterzuarbeiten. Von daher kann ich das mit dem desolat nur sehr partiell (eigentlich gar nicht) sehen.
@oldie: Falls Du bei Deinem Problemrechner das Startproblem eventuell durch morsen auf dem Powerknopf lösen kannst - mit diesem Problem bin ich bei eigentlich jedem Kernel seit November 2010 gesegnet. Wohlgemerkt bisher nur auf 2 Boards - nolapic_timer ist eine geile Sache für die Kernelzeile und funktionierte bisher zu über 90% auf Rechnern, die Freezes während des Bootens hatten. Da ich die Nase voll davon hatte, in solchen Fällen bei Ubuntu zu begründen, warum das hilft, habe ich das in das Wiki aufgenommen und einfach nur noch auf die entsprechende Seite verwiesen.
-
Hallo David,
danke für Deinen ausführlichen Beitrag.
RPM ist leider nicht RPM. Es gibt das "alte" RPM in Version 4 + tausend (distro-spezifischen) Patches und RPM5 was inkompatibel ist zu machen verwendeten RPM4-Patches -- des Result ist, dass man sich das System noch ordentlicher zerlegt als man es bei debian-Paketen tut, wenn man die einer anderen Distro nimmt…
Das ist sicherlich so, über rpm stand erst neulich etwas auf pro-linux.de. Ich komme aber auch nicht auf die Idee, ein Opensuse Paket auf PCLinuxOS oder Mageia zu installieren. Das ist doch gar nicht notwendig.
Pakete sind dann auch das Stichwort: Debian hat das große Glück viele Pakete zu haben. Bei vielen anderen ist die Auswahl durchaus geringer -- in den offiziellen Quellen.
Debian hat vermutlich das größte Paketrepo und das macht es nicht gerade einfach, alles aufeinander abzustimmen, und das braucht auch Zeit. Du musst aber zugeben, dass die große Anzahl an Paketen in Debian teilweise daher kommt, dass ein Paketsplitting stattfindet.
Häufig gibt es ihrgendwo anders doch wieder alles mögliche - das Problem: Qualität dieser Pakete und Maintaining.
Nun muss man bei extra Repos sorgfältig vorgehen, das ist richtig. Unter Opensuse gibt es jedoch gut gepflegte Community Repos, die für nvidia, für KDE Extra, Packman und Videolan. Mehr brauche ich nicht, und dann trifft das folgende auch nicht zu:
Nicht selten gibt es mehrere Archive die die selbe Version unterschiedlich paketieren - wenn man dann das Pech hat die Version aus dem falschen Archive installiert zu haben ist zwar die Abhängigkeit formal erfüllt, effektiv kann das Paket aber mit der Version gar nicht arbeiten -> Welcome to dependency hell!
Turboprint etwa baut seine Pakete für Debian/Ubuntu und rpm basierte Distries. Mit einem Turboprint rpm hatte ich bisher weder Schwierigkeiten bei PCLinuxOS, Opensuse und nun auch Mageia.
Installierte Pakete auch aus Zusatzrepos laufen bei mir, bis auf Experimente mit digikam2 Betapaketen hatte ich bisher unter Opensuse keine Schwierigkeiten.
Viele Grüße,
Holger
-
Fehler 1:
Der Bootvorgang hängt bei den NFS-Mounts für eine NAS-Box.
Fehler 2:
Das deutsche Tastaturlayout wird nicht geladen da eine Fehlermeldung beim Booten angezeigt wird. Als Folge kann ich mich nicht als root einloggen (wegen div. Sonderzeichen im Passwort)
Fehler 3:
Im neuen KDE 4.6.3 werden Backgrounds und Aktivitäten durcheinander gewürfelt.
Fehler 4:
Der neue KDE 4.6.3 weigert sich transparente Plasmaoids anzuzeigen.
Fehler 5:
Seit Kernel 2.6.38-5 (slh) einfrieren meiner Systeme (3 von 4) beim Backup meiner Partitionen mit dd.
Fehler 6:
udev Fehlermeldungen seit einigen Wochen beim Booten.
Fehler 7:
Fehlermeldungen von rpcbind seit einigen Wochen beim Booten.
Hi zusammen,
noch ein Versuch mit d-u die oben angeführten Fehler evtl. beheben zu können.
Fehler 1: nfs-common und nfs-kernel-server komplett neu installiert - keine Besserung der Situation. Sobald NFS-Mounts in der fstab eingetragen sind steht das System beim Booten.
Fehler 2: ist durch neue Version behoben
Fehler 3/4: durch Workaround mit einem neuen KDE Profil eines Testusers behoben (Verzeichnis .kde kopiert) - Lösung ist das aber keine
Fehler 5: aptosid-Kernel weiterhin buggy. Aktuellen Liquorix-Kernel getetstet - funktioniert.
Fehler 6: weiterhin vorhanden bei einer Kiste obwohl fehlendes Programm mtp-probe nachinstalliert wurde
Fehler 7: ist nach wie vor zu beobachten
Fazit, es ist weiterhin übel meine SID-Systeme zu aktualisieren und immer mit viel Arbeit verbunden.
-
Hallo bluelupo,
kannst du den Zugriff auf die NAS Box mal tracen, z.B. mit wireshark ?
Ich benutze div. SID-Installs mit Standard oder auch Towo-Kerneln sowie ständigen Updates und da funktionieren die NFS-Mounts (bis auf die Kleinigkeiten der bekannten Fehlermeldungen) zu NFS Debian Testing / SID Servern ohne Probleme. Ich vermute da eher ein Problem in der Firmware bzw. Protokoll-Implementation der NAS Box.
Ich hatte sowas schon mal, da war der Client einfach zu neu. Allerdings hat sich die Kiste nie aufgehangen, das ist schon merkwürdig.
-
Hallo @Bluelupo,
mit welchen Optionen bindest Du Deine NFS Partitionen ein?
Seite OpenSUSE 11.4 musste ich den Zusatz "_netdev" verwenden, weil sonst das System versucht, NFS Partitionen einzubinden, bevor das Netzwerk gestartet ist.
Viele Grüße,
Holger
-
Hallo @Bluelupo,
mit welchen Optionen bindest Du Deine NFS Partitionen ein?
Hi Holger,
ich binde die NAS-Box (SYNOLOGY DS211) so in der fstab ein:
192.168.178.77:/volume2/Misc /mnt/diskstation/misc nfs rw,noauto 0 0
192.168.178.77:/volume2/Photo /mnt/diskstation/photo nfs rw,noauto 0 0
192.168.178.77:/volume1/VM /mnt/diskstation/vm nfs rw,auto,users 0 0
192.168.178.77:/volume1/Backup_Diskimages /mnt/diskstation/diskdump nfs rw,auto,users 0 0
192.168.178.77:/volume2/Backup_Filesnapshots /mnt/diskstation/rsnapshot nfs rw,auto,users 0 0
Die Option _netdev muss ich erst mal testen. Ich frage mich außerdem wieso die Initscripte von nfs-common und nfs-kernel-server vor dem Netzwerk gestartet werden?
Ich hatte sowas schon mal, da war der Client einfach zu neu. Allerdings hat sich die Kiste nie aufgehangen, das ist schon merkwürdig
@ralfi: Ich denke NFS wartet wohl auf einen Timeout (jeweils pro NFS-Mount). Die Kiste wird nicht komplett stehen geblieben sein.
-
Hi bluelupo,
haste das dd mal mit einer älteren Live-CD versucht ?
Alternativ / zusätzlich probiers doch einfach mal mit händischen Mounten inkl. gleichzeitigen wireshark Trace aus.
-
@ bluelupo
ich habe auch eine Synology-Box und binde die Partitionen mit
... ... nfs defaults nolock ein. Problemlos.
Option _netdev kenne ich nicht und benötige sie offensichtlich auch nicht.
Und nur der Vollständigkeit halber noch der Hinweis auf das alte Problem, dass nach vergeblichen mount-Versuchen /var/run/network/mountnfs gelöscht werden muss. Nach sauberem mount existiert das nicht.
Gruß
oduffo
-
haste das dd mal mit einer älteren Live-CD versucht ?
Alternativ / zusätzlich probiers doch einfach mal mit händischen Mounten inkl. gleichzeitigen wireshark Trace aus.
Hi ralfi,
das händische mounten der NFS-Shares klappt problemlos. Das mit dem dd ist ein seltsames Fehlerbild das drei von mein vier Kisten betrifft seit ungefähr Kernelversion 2.6.38-5.slh. Der dd wird innerhalb eines Shellscriptes aufgerufen der den vorher erzeugten LVM-Snapshot eines Logical Volumes auf das NAS schreibt.
Hier mal das Codeschnipsel aus dem Script ($OF_DIR ist das Verzeichnis auf dem NAS):
/sbin/lvcreate -l$LECOUNTER -s -n SNAPSHOT_$LVNAME_SHORT $LVNAME_LONG 1>> $LOGFILE 2>> $OF_DIR/$ERRFILE
echo " --> Create from the snapshot SNAPSHOT_$LVNAME_SHORT, a 1:1 copy with dd" >> $LOGFILE 2>&1
dd if=$VGPATH/SNAPSHOT_$LVNAME_SHORT of=$OF_DIR/$LVNAME_SHORT-$TIMESTAMP.dd >> $LOGFILE 2>&1
/sbin/lvremove -f $VGPATH/SNAPSHOT_$LVNAME_SHORT 1>> $LOGFILE 2>> $OF_DIR/$ERRFILE
Aktuell auf einer meiner Kisten (LENOVO T60) den Liquorixkernel 2.6.38-7.dmz.2-liquorix-686 installiert bei dem der dd innerhalb des Scriptes korrekt durchläuft. Wenn ich hingegen einen aktuellen slh-Kernel installiere schreibt der dd zwei von den Snapshots korrekt weg und beim dritten ist dann Ende. Dabei ist mir aufgefallen das dieser dann eigentlich schon komplett fertig geschrieben ist (kann ich anhand der Größe feststellen des dd-Image) und nur weitermachen müsste im Scriptablauf. Desweiteren stellte ich fest das (im Script-Logfile) die Schreibrate auf das NAS von ca. 35-40 MB/sec fast gegen Null geht und die CPU-Last auf 100% steigt (laut htop).
Meiner Ansicht nach muss der Fehler beim Zusammenspiel zwischen Kernel (slh) und dem NFS liegen.
-
@ bluelupo,
NFS kommt bei mir nicht mehr in die fstab sondern wird nur noch per autofs eingehängt. Seitdem wesentlich weniger Probleme.
-
@ bluelupo
ich habe auch eine Synology-Box und binde die Partitionen mit
... ... nfs defaults nolock ein. Problemlos.
Hi oduffo,
ich habe mal die Optionen "_netdev" und "defaults nolock" gestest.
192.168.178.77:/volume1/VM /mnt/diskstation/vm nfs rw,auto,users,_netdev 0 0
192.168.178.77:/volume1/VM /mnt/diskstation/vm nfs rw,defaults,nolock,users 0 0
...beide Male läuft der NFS-Mount auf einen Timeout beim Booten (mehrere Minuten). Die Kiste kommt nur ohne Verzögerung bei der Option "noauto" hoch, d.h. dann muss ich alle meine NFS-Shares per Hand mounten. Hast im SYNOLOGY-Configtool bei Freigabe von NFS-Shares die Option "asyncron" aktiviert oder nicht?
-
Hast im SYNOLOGY-Configtool bei Freigabe von NFS-Shares die Option "asyncron" aktiviert oder nicht?
Diese Option finde ich nicht.
Ich habe eine DS 109 mit Disk Station Manager 2.2
oduffo
-
Hallo @Bluelupo,
bei meinem Nas heißt die Option async. In den /etc/exports habe ich für meine Nuterdaten folgendes stehen:
/mnt/disk1/daten/nutzer/holger 192.168.1.102(rw,async,subtree_check)
Gemountet wird diese Freigabe dann durch den Eintrag
192.168.1.116:/mnt/disk1/daten/nutzer/holger /home/holger/daten/nas nfs defaults,_netdev 0 0
Das klappt bei Opensuse 11.4, Kubuntu und Mageia.
Viele Grüße,
Holger
-
Hi zusammen,
hier mal ein paar mitgeloggte Daten. Hier die Situation wenn die Kiste praktisch nix mehr tut bei einem Lauf des dd (siehe Prozessausgabe).
root@tweety:~# sar -n NFS 5
Linux 2.6.39-1.dmz.1-liquorix-686 (tweety) 09.06.2011 _i686_ (2 CPU)
09:59:19 call/s retrans/s read/s write/s access/s getatt/s
09:59:24 0,00 0,00 0,00 0,00 0,00 0,00
09:59:29 0,00 0,00 0,00 0,00 0,00 0,00
09:59:34 0,00 0,00 0,00 0,00 0,00 0,00
09:59:39 0,00 0,00 0,00 0,00 0,00 0,00
09:59:44 0,00 0,00 0,00 0,00 0,00 0,00
09:59:49 0,00 0,00 0,00 0,00 0,00 0,00
^C
root@tweety:~# ps -ef|grep dd
root 3908 3307 87 09:44 pts/1 00:13:53 dd if=/dev/VGsystem/SNAPSHOT_LVhome of=/mnt/diskstation/diskdump/tweety/2011-06-09-0939/LVhome-20110609_0939.dd
Hier noch ein top:
top - 10:04:20 up 29 min, 2 users, load average: 7.08, 6.75, 4.59
Tasks: 131 total, 2 running, 129 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2%us, 49.9%sy, 0.0%ni, 40.9%id, 9.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 3112760k total, 2972644k used, 140116k free, 664684k buffers
Swap: 2097148k total, 0k used, 2097148k free, 2173528k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3908 root 7 0 5428 548 464 R 100 0.0 18:12.12 dd
3973 root 7 0 2592 1112 832 R 1 0.0 0:00.02 top
2452 root 1 0 8896 2772 2248 S 0 0.1 0:00.11 sshd
1 root 1 0 2176 680 584 S 0 0.0 0:00.96 init
2 root 1 0 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root 1 0 0 0 0 S 0 0.0 0:00.00 ksoftirqd/0
EDIT: So ich habe jetzt nochmal auf der NAS-Box in der /etc/exports nachgesehen wie dort die NFS Optionen gesetzt sind.
/volume1/Backup_Diskimages 192.168.178.1/24(rw,sync,no_wdelay,no_root_squash,insecure_locks,anonuid=0,anongid=0)
Kann mir jemand sagen ob das soweit passt oder eine der Optionen evtl. die Schwierigkeiten verursacht mit dem "hängenden" dd-Kommando?
EDIT2:
Nochmal mit dem NFS Optionen (in der /etc/exports) auf der NAS-Box getestet. Statt obige Zeile jetzt folgende probiert:
/volume1/Backup_Diskimages 192.168.178.1/24(rw,no_root_squash,anonuid=0,anongid=0)
...hat leider keinen Erfolg gebracht - Kiste bleibt beim Schreiben des Partitionsimages mit dd hängen. Das alles beim Liquorix-Kernel 2.6.39-1.dmz.1-liquorix-686. Dann wieder zum Kernel 2.6.38-7.dmz.2-liquorix-686 gewechselt - keine Probleme. Dasselbe passiert bei den slh-Kerneln, dort allerdings schon bei Kernel größer 2.6.38-5.
Ich habe gerade ein wenig recherchiert via Google - und es wurde am NFS-Client im Kernel 2.6.39 doch "ordentlich herum geschraubt" :-(
...ich hab' jetzt langsam die Faxen dicke :-(
-
Was sagt denn der Debian-Kernel? So mal richtig in "konservativ"? (Natürlich der aus Sid)
-
@agaida: das ist jetzt mein nächster Versuch. Inzwischen habe ich auch noch die Firmware der NAS-Box aktualisiert. Test folgt!
EDIT: Welchen der Debian Kernelpakete muss ich da installieren bei einer 32Bit-Kiste?
# apt-cache search linux|egrep '(linux-headers|linux-image)-2.6.39'
linux-headers-2.6.39-1.slh.3-aptosid-686 - Header files for Linux 2.6.39-1.slh.3-aptosid-686
linux-image-2.6.39-1.slh.3-aptosid-686 - Linux 2.6.39 for modern PCs
linux-headers-2.6.39-1-486 - Header files for Linux 2.6.39-1-486
linux-headers-2.6.39-1-686-pae - Header files for Linux 2.6.39-1-686-pae
linux-headers-2.6.39-1-all - All header files for Linux 2.6.39 (meta-package)
linux-headers-2.6.39-1-all-i386 - All header files for Linux 2.6.39 (meta-package)
linux-headers-2.6.39-1-amd64 - Header files for Linux 2.6.39-1-amd64
linux-headers-2.6.39-1-common - Common header files for Linux 2.6.39-1
linux-headers-2.6.39-2-486 - Header files for Linux 2.6.39-2-486
linux-headers-2.6.39-2-686-pae - Header files for Linux 2.6.39-2-686-pae
linux-headers-2.6.39-2-all - All header files for Linux 2.6.39 (meta-package)
linux-headers-2.6.39-2-all-i386 - All header files for Linux 2.6.39 (meta-package)
linux-headers-2.6.39-2-amd64 - Header files for Linux 2.6.39-2-amd64
linux-headers-2.6.39-2-common - Common header files for Linux 2.6.39-2
linux-image-2.6.39-1-486 - Linux 2.6.39 for older PCs
linux-image-2.6.39-1-686-pae - Linux 2.6.39 for modern PCs
linux-image-2.6.39-1-686-pae-dbg - Debugging infos for Linux 2.6.39-1-686-pae
linux-image-2.6.39-1-amd64 - Linux 2.6.39 for 64-bit PCs
linux-image-2.6.39-2-486 - Linux 2.6.39 for older PCs
linux-image-2.6.39-2-686-pae - Linux 2.6.39 for modern PCs
linux-image-2.6.39-2-686-pae-dbg - Debugging infos for Linux 2.6.39-2-686-pae
linux-image-2.6.39-2-amd64 - Linux 2.6.39 for 64-bit PCs
-
Ist nur so eine saudumme Idee, Ich weiss nicht, inwiefern der Liquorix-Kernel auch von den Auswüchsen der Entfernung des BKL betroffen ist. Bei dem was ich gelesen habe, standen aber noch einige Punkte grade mit BKL und nfs-client und -server offen, Schwierigkeit hoch. Die waren aber bei Thats-all-folks immer noch nicht gelöst.
-
EDIT: Welchen der Debian Kernelpakete muss ich da installieren bei einer 32Bit-Kiste?
# apt-cache search linux|egrep '(linux-headers|linux-image)-2.6.39'
Wen dein rechner nicht wirklich alt ist (wobei dann aptosid vermutlich gar nicht laufen würde):
linux-image-2.6.39-2-686-pae - Linux 2.6.39 for modern PCs
Aber effektiv könntest du jeden dieser Kernel installieren und vermutlich jeden laufen lassen. Auch den amd64 wenn dein CPU 'lm' unterstützt (cpuflag).