SID in desolaten Zustand

[oldie]

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

[DonKult]

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...

[devil]

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

[agaida]

@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.

[holgerw]

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

[bluelupo]

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.

[ralfi]

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.

[holgerw]

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

[bluelupo]

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:

Code Select Expand


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.

[ralfi]

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.

[oduffo]

@ bluelupo
ich habe auch eine Synology-Box und binde die Partitionen mit

Code Select Expand

... ... 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

Code Select Expand

/var/run/network/mountnfs gelöscht werden muss. Nach sauberem mount existiert das nicht.

Gruß
oduffo

[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.

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):

Code Select Expand


/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.

[Geier0815]

@ bluelupo,

NFS kommt bei mir nicht mehr in die fstab sondern wird nur noch per autofs eingehängt. Seitdem wesentlich weniger Probleme.

[bluelupo]

@ bluelupo
ich habe auch eine Synology-Box und binde die Partitionen mit

Code Select Expand

... ... nfs defaults nolock ein. Problemlos.

Hi oduffo,
ich habe mal die Optionen "_netdev" und "defaults nolock" gestest.

Code Select Expand


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?

[oduffo]

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