Svens Netzblog

Frisch gekaufte flüssige Seife ist einfacher wiederzufinden, wenn man sie im Badezimmer und nicht im Kühlschrank lagert.

Weiter mit Musik.

Das alle Jahre bei einem Auto ein Ölwechsel fällig ist, dürfte der überwiegenden Mehrheit ja bekannt sein.

Aber das auch bei PCs ab und zu ein Erneuern der Wärmeleitpaste zwischen CPU und Kühlkörper sinnvoll ist, dürfte neu sein.

Aber genau das habe ich heute gemacht, denn nachdem die CPU (AMD64 3200+) bei knapp 68°C im Leerlauf und bis zu 82°C unter Vollast vor sich hin brutzelte und mein BIOS mir akustisch zu verstehen gab, dass es das so nicht gutheissen kann, musste ich aktiv werden.

Da der Kühler (ein leiser von Arctic Cooling, aber keiner der meiner-ist-größer-als-deiner Varianten) früher die CPU nie wärmer als ca. 55°C unter Last hat werden lassen, musste sich etwas verändert haben.

Den Staub hatte ich immer mal wieder entfernt und so warm wurde der Kühler auch gar nicht. Daraus schloss ich, das irgendwie die Abwärme der CPU nicht korrekt bzw. vollständig auf den Kühlkörper übergeht.

Also habe ich ihn abmontiert und die alte und mittlerwiele ausgehärtete Wärmeleitpaste entfernt (geht sehr gut mit einer alten Konto-Karte) und neue dünn aufgetragen (ebenfalls mit der altem Konto-Karte).

Und siehe da: nach dem Wiederaufsetzen war wieder der alte Zustand erreicht, knapp 38°C im Leerlauf, 55°C unter Last.

Also Leute, es muss nicht immer gleich ein 80€-600g-Kühler aus gefrästem Kupferblock sein, ein einfacher Alu-Kühler für 15€ mit geregeltem großem Lüfter reicht auch, um die 90W der CPU abzuführen.

Was bisher geschah: VIA-SATA ist Schrott, mit Promise hat's funktioniert.

Wie es weiter ging: Das RAID1 ist mittlerweile aufgebaut, die Daten ge'rsynct, mittels GRML wurde dann auch der Rest übertragen, GRUB installiert und alles bereit gemacht.

Nun die alten Platten abhängen, das BIOS auf "Booten von PCI-Gerät" einstellen, einschalten und ... ein langes Gesicht machen.

Das mdadm aus Debian Sid erzeugt mittlerweile einen Superblock im Format 1.0 (wenn /etc/mdadm/mdadm.conf entsprechend eingestellt ist, was derzeit default ist), der Kernel erkennt aber nur solche mit Format 0.90 korrekt und automatisch.

Natürlich könnte ich jetzt eine initrd anlegen, aber ich traue diesem ganzen Early-Userspace-Kram nicht so recht über den Weg.

Mir blieb also nichts anderes übrig, als mein fertig synchronisiertes RAID1 wieder aufzubrechen, eine Platte davon mit korrektem Superblock im degraded mode als neues RAID1 anzuwerfen und die Daten noch einmal durch die Gegend zu schaufeln.

Wenigstens habe ich so einmal etwas Belastung auf den Platten erzeugt und jeder Block wurde mindestens einmal angefasst, so dass ich Hoffnung haben kann, dass die Platten nicht gleich Dead-on-Arrival sind.

Was bisher geschah: Platten gekauft, angeschlossen, geht nicht.

Jetzt der zweite Teil: Da ja der On-Board-VIA-SATA-Kontroller einfach nur grottig ist (ja, ich habe die Platten auch Testweise auf 1,5GBps gejumpert gehabt), habe ich mir heute dann einen Promise TX4 gekauft, um Ruhe zu haben.

Also flugs eingebaut, Platten angeschlossen, mein normales System (Debian Sid) gestartet und schon einmal das neue RAID zusammengestellt.

LVM drauf, Dateisysteme drauf, zusammenmounten und rsync von alt nach neu anstossen, das komplette restliche Synchronisieren erfolgt dann später via GRML.

Da das ja eine Zeit dauert, bleibt noch Muße für einen netten Spieleabend mit Komilitonen und Freunden.

Nachdem, wie schon beschrieben, mal wieder die Windows-Platte in meinem Rechner den Geist aufgegeben hatte, wollte ich endlich den schon früher vorgenommenen Umbau von vier PATA-Platten auf zwei SATA-Platten (je RAID1) vornehmen, um dann eine der freiwerdenden Platten für Windows nutzen zu können.

Gesagt, getan, zwei 500GB SATA-Platten ausgesucht, sicherheitshalber noch zwei SATA-Kabel dazu gekauft und mit dem Umbau begonnen.

Erster Fallstrick: Die On-Board-SATA-Anschlüsse liegen exakt unter dem Kühler meiner Grafikkarte, so dass ich nur mit millimeter-genauer Bastelei beide Anschlüsse nutzen kann, ohne das dabei Spannungen und Verbiegungen auftreten.

Zweiter Fallstrick: Der On-Board-VIA-SATA-Controller ist einfach scheisse. Die Platten werden nicht sicher erkannt und wenn sie mal erkannt werden, dann reicht allein schon ein simples mke2fs, dass der Chip nach kurzer Zeit meint, dass die Platten defekt wären und aussteigt.

Super.

Also doch einen externen SATA-Kontroller kaufen.

Morgen.

Mal wieder:

hdb: status error: status=0x7f { DriveReady DeviceFault SeekComplete DataRequest CorrectedError Index Error }
hdb: status error: error=0x7f { DriveStatusError UncorrectableError SectorIdNotFound TrackZeroNotFound AddrMarkNotFound }, LBAsect=260013951, sector=0
ide: failed opcode was: 0xec

drive not ready for command

Danach wurde die Platte von keinem sich in meinem Besitz befindlichen IDE-Kontroller mehr erkannt.

Es war zwar (wieder) nur die Windows-Platte, daher kein zu großer Verlust, aber die Reinstallation des ganzen Geraffels inkl. aller mittlerweile von Microsoft herausgegebenen Patches und Hotfixes wird wieder den besseren Teil meines Tages aufbrauchen.

Mist^TM!

Immerhin habe ich noch Garantie, die Platte war ja gerade mal 9 Monate alt.

Gegeben sei ein Rechner mit Yukon2-Netzadapter (mit sky2 v1.5 unter Linux 2.6.18.2) und die Notwendigkeit, hier VLANs hinzuzufügen und auch wieder zu entfernen.

Das Hinzufügen einen VLANs (entweder via /etc/network/interfaces) oder auch manuell mittels vconfig funktioniert ohne Probleme, das zusätzliche Interface ist verfügbar und benutzbar.

Interessant wird es, wenn man ein VLAN wieder entfernen will, dann funktionieren andere VLANs auf dem gleichen Master-Interface nicht mehr.

Beispiel:

eth0 (Master, keine IP)
eth0.4 (192.168.100.4)
eth0.1023 (192.168.120.1)
eth0.1965 (192.168.140.20)

Jetzt füge ich mittels "vconfig add eth0 42" ein weiteres VLAN hinzu:

eth0 (Master, keine IP)
eth0.4 (192.168.100.4)
eth0.1023 (192.168.120.1)
eth0.1965 (192.168.140.20)
eth0.42

Soweit keine Probleme. Wenn ich jetzt aber mittels "vconfig rem eth0.42" dieses Interfaces entferne, so sind alle anderen VLAN-Interfaces an eth0 auch tot, nur das ungetaggte eth0 funktioniert noch.

Wobei sich "tot" nur darin äußert, dass keine Pakete mehr rein oder raus laufen, die Interfaces bleiben UP und sind vorhanden.

Auch der aktuelle 2.6.19-rc5 mit sky2 v1.10 zeigt das gleiche Verhalten, andere Treiber, z.B der skge oder auch e100/e1000 etc. sind nicht betroffen.

Der für mich interessante Teil besteht jetzt darin, den Leuten auf der netdev-Liste dieses Phänomen zu erklären, damit das Problem jemand finden und fixen kann.

Heute bin ich endlich dazu gekommen, ein sehr merkwürdiges Problem mit mysql-server-5.0 von backports.org auf einem Debian Sarge AMD64-System zu untersuchen.

So startete der mysqld ab und zu beim Booten nicht, sondern das Init-Scripte gab nur aus, in /var/lib/mysql wäre zu wenig Platz, was aber kompletter Unsinn ist, denn diese Ausgabe erfolgt nur, wenn weniger als 4MB frei sind, während auf dem fraglichen System über 300GB verfügbar waren.

Der Fehlschlag beim Start trat aber nicht immer auf, in nicht vorhersehbaren Intervallen war der Start möglich oder er schlug fehl.

Nach näherer Betrachtung stellte sich dann das folgende Verhalten von df heraus:

root@xen-16:~# while sleep 1; do BLOCK_SIZE= df --portability /; done
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.8MiB 175KiB 1.5MiB 11% /
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda1 1829159K 178307K 1553259K 11% /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.8 178 1.6 11% /
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda1 1829159M 178307M 1553259M 11% /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.8M 178k 1.5M 11% /
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda1 1829159 178307 1553259 11% /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.9MB 179kB 1.6MB 11% /

Man beachte hierbei die sich verändernde Darstellung bei aber immer gleichem Aufruf von df.

Dieses Verhalten, das nur auf AMD64 und auch nur dann auftritt, wenn BLOCK_SIZE= gesetzt (eigentlich gelöscht) wird, hat größeres Stirnrunzeln verursacht.

Die Versionen der coreutils in Debian Etch und Sid zeigen diese Verhalten nicht (mehr).