• 08Nov

    Es gibt doch immer wieder Phänomene, die über den normalen Admin-Verstand hinausgehen. Man nehme z.B. diesen Fall:

    Das Acer Aspire 3000 eines Bekannten funktionierte auch nach mehrfacher Neueinrichtung von den Recovery-CDs nur mit USB-Maus und -Tastatur. Außerdem beschäftigte der System-Prozess die CPU dauerhaft mit ca. 50%, und die anderen Tasten (WLAN-Schalter, Power-Switch) funktionierten ebenfalls nicht.

    Also mal eine andere XP-CD genommen und frisch installiert. Alles lief wunderbar, also die Acer-CDs verflucht und das c’t Offline-Update angeschmissen. Rödel, rödel, rödel… Und nach einem der diversen Neustarts: das gleiche Phänomen! Kaum zu fassen!

    Nun gut – vor weiteren Versuchen mit Systemwiederherstellungspunkten (welches der zig Updates mag schuldig sein?) und neuen Chipsatztreibern nochmal einen Blick in die Suchmaschine werfen. Vielleicht finden die Jungs von Goggel ja in der Bibliothek was…

    Und siehe da: die erste Fundstelle zum Suchbegriff „aspire 3000 keyboard xp“ brachte diese Seite zum Vorschein. Zitat:

    I can see the processor working at 90% when the battery is connected. The solution is, of course, to detach the battery, or better to disable the Battery ACPI control. Bad Acer electronics!

    Nachfolgend gibt es Seitenweise Dankesbekundungen. Konnte es so einfach sein? Also Akku raus – und schwupps ging der Lüfter auf Normalbetrieb zurück und alles beruhigte sich! UNGLAUBLICH!

    Dann im Gerätemanager die „Microsoft ACPI-konforme Kontrollmethodenbatterie“ deaktiviert, Akku wieder rein, Verhalten bleibt normal.

    Nun weiß Windows zwar nichts mehr von dem Akku, aber was soll’s. Die Mühle läuft wieder und der Erfahrungsschatz ist um eine Anekdote reicher 🙂

    Permalink

    Tags: ,

  • 11Nov

    Natürlich nicht im direkten Sinne. Aber sie schicken immer mehr ältere Server in den verfrühten Ruhestand und helfen so beim Stromsparen. So geschehen am letzten Wochenende mit einem Webserver, der in immer kürzeren Abständen ausfiel. Dank fernschaltbarer Steckdose (mehr dazu demnächst) konnte er kurzfristig wieder zum Leben erweckt werden, aber als ich bei einem Ausfall gerade in der Nähe war und dann doch mal hingefahren bin, habe ich einen Blick ins Gehäuse geworfen. Es grüßten mich die üblichen Elkos mit „Hut hoch“…

    Defekte Elkos

    Defekte Elkos

    Zeitlich war das ganze etwas unpassend, aber was soll man machen. Eine gute Chance, die alte Mühle (Celeron 2,4 GHz, 512 MB RAM, aber immerhin 80er-Platten in HotSwap-Rahmen an einem 3ware PATA) zu virtualisieren. Der benachbarte XEN-Host hat noch genügend Luft 🙂

    Die Hoffnung, dass das Board das Kopieren der Daten übers Netzwerk noch durchhält, hat sich natürlich schnell zerschlagen. Also schnell die Platten in eine andere Maschine mit diesen Rahmen gesteckt (die leider somit zum Opfer wurde, sorry nochmal!) und wieder von CD gebootet. Folgendes Kommando hat dann gute Dienste geleistet:

    tar cf - . | ssh xenhost "(cd /mnt/temp && tar xvf - )"

    Natürlich war damit noch nicht alles getan. Als Linux kommt hier Ubuntu 8.04 Server zum Einsatz, es fehlte noch der passende XEN-Kernel. Beim Installieren (über einen anderen Server, schließlich lief dieser ja noch nicht!) wurde ich schon stutzig, als die Version 2.6.24-16-xen angezeigt wurde. Das wird doch nicht etwa immernoch…? DOCH! Noch immer gibt es keine Version des XEN-enabled Kernels in 8.04, die nicht mit dem Netzwerk-Bug daherkommt! Schlafen die eigentlich alle?

    Nur gut, dass ich diese Sache aus den Anfängen von 8.04 schon kannte. Schnell wieder den japanischen Patch gerausgesucht -> funktioniert. Danke!

    Permalink

    Tags: , , , ,