Category: Painseeker

So, es reicht.

• iwl3945 kotzt ins Essen — Atheros- oder Prism54 via PC-Card rockt weiterhin das Haus (und ich bin nicht alleine …)
• kein Dateiempfang mehr via Bluetooth — another pain in the ass brought to you by the second LTS release
• synergy ausgebremst mit Ubuntu 8.04 LTS
• Daß suspend nicht immer funktioniert, ist leider nicht neu; außer, daß es zuletzt in 7.10 endlich stabil funktionierte, unter 8.04 will er mal nicht runterfahren und mal ist WLAN und/oder Ethernet hernach b0rked. Perfide ist das Problem beim Ethernet (sky2.ko): das Device ist da, ich glaube, sogar Link up/Link down wird erkannt. Nur: auch bei Link up kommen keine Pakete an. »rmmod sky2« und »modprobe sky2« umgehen zwar einen Reboot, aber partielle Nichtfunktion ist für mich nun einmal schlicht Nichtfunktion.
• Trotz – oder grade wegen? – laufendem ntpd weicht die Systemzeit schon mal im Tagesverlauf 15 Minuten und mehr von der Realzeit ab, dieser hinterherhinkend. Das kann natürlich durch den Netzwerkverlust beim Transport bedingt sein (da Suspend nicht tut, ist das, was »uptime« meldet, die wirkliche Uptime, wie bei einem Desktop mit USV; und da Network Manager keinen Failover von WLAN zu UMTS-via-BT kennt, ist die Kiste mehrere Stunden am Tag nicht wirklich am Netz, was aber durch den Einsatz von openvpn für die lokalen Anwendungen sich nur in Timeouts äußert).

Awesome!
Nun ja, stand ja groß drauf auf der Verpackung: »Finger weg! Bastelversion!« — »LTS« steht doch für »Leave This alone! It suxx!«, oder?
Richtig blöd ist nur eines: gehe ich jetzt zum unentropischen Debian-Projekt, werde ich garantiert in 6 bis 12 Monaten heulen, daß Debian Stable einfach zuuu alt für alles aktuell Interessante an HW ist. Und bei den komischen Hüten, Fedora 9 ist aktuell?, muß ich mir erst einmal die Finger brechen, damit MP3 und MPEG2-Video überhaupt was anzeigt außer »geht nicht« …
*sigh* Ja, ich kann schon verstehen, warum Windows XP so beliebt ist. Es ist zwar[sup]

[/sup] auch Kacke, aber auf einem viel höheren, abstrahierenden Niveau.
Jedenfalls scheint Ubuntu 8.04 LTS durchaus unterschiedliche Erfahrungen hervorzubringen …
____

*seufz* Mein dist-upgrade auf Ubuntu 8.04 war ja unter verschiedenen Gesichtspunkten ein Girff ins Klo; so richtig bekomme ich die Auswirkungen erst jetzt zu spüren, wo ich noch »mal eben« mittels Laptop und vdr-sxfe die Astra-28E-Schüssel nach all dem Wind der letzten Tage neu justieren wollte. Ubuntu-Bug #232241 beißt mich, und wer glaubt, mit Debian führe ich besser, der irrt wahrscheinlich. Der Käfer scheint irgendwo im Dunstkreis der xine-Library bzw. der darauf aufsetzenden vdr-Anbindung zu liegen.
Ein noch auf Ubuntu 7.10 laufender Laptop ist in der dependency hell gefangen, libxine1-xvdr depended da auf eine ältere libxine1 als die, die derzeit installiert würde — rohe Gewalt bringt es da nur zur Paketinstallation, nicht aber zu Funktion.
Wahrscheinlich muß ich dankbar sein, daß ich aus Zeitmangel mein Fedora-7-System noch nicht auf 9 hochgezogen habe — es ist derzeit die einzige Kiste, von der aus ich meine, teils headless laufenden, vdr korrekt ansprechen kann. Ganz, ja wirklich ganz toll ist das mal wieder :(

Auf Hinweis eines Kollegen hatte ich gestern abend mal die Skype-Version auf meinen Geilen Gutsy Gibbon-Rechnern aktualisiert und heute in einer Pause es dann mal ausprobiert: Skype 2.0.0.63 auf Ubuntu 7.10 mit Videounterstützung — Holy Shit, das funktionierte sogar, wenn auch mit Einschränkungen.
Erster Test war mit einer UVC-kompatiblen Kamera:

uvcvideo: Found UVC 1.00 device Hercules Dualpix Exchange (06f8:3005)

Die Cams gab’s vor Kurzem recht günstig in der Bucht, macht zwar auch nur 640×480, aber dafür ein recht stimmiges und scharfes Bild in Innenräumen. Für den Außeneinsatz hingegen ist sie scheinbar eher ungeeignet, da wird schon bei moderater Sonnenlichteinwirkung alles weiß. Kleiner Exkurs hinsichtlich des Treibers uvcvideo.ko: fswebcam als auch motion, zumindest in Version 3.2.9, können mit UVC-Kameras umgehen, im Falle der Quickcam Fusion (046d:08c1) klappt das sogar bis zu deren nativer Auflösung von 1280×960 Pixeln (alle Aussagen beziehen sich auf Ubuntu 7.10 i386-Systeme).

Skype 2 konnte mit der erwähnten Hercules Dualpix Exchange auch ein Videobild fangen und übertragen — allerdings brach die Bildübrtragung von mir zum Gegenüber nach ca. 10 Sekunden kommentarlos ab. Das syslog blieb leer, Skype meinte weiterhin, mit 15 FPS eine 160×120-Pixel-Briefmarke zu senden, allein es wurde weder mein Bild aktualisiert noch wurde irgendwas beim Gegenüber angezeigt.
Verbindungstrennung, Hinzufügen einer weiteren Cam per USB ohne Neustart der Skype-Applikation: Schade, hat Skype nicht mitbekommen. Also Skype beendet und neu gestartet, nun waren /dev/video0 (die UVC-Cam) und /dev/video1 (gspca-getrieben) auswählbar — und die Wahl von /dev/video1 aktivierte /dev/video0. Selbst wenn /dev/video1 das einzige Videodevice ist: eine Anwahl ergibt bei mir den Zugriff auf /dev/video0, ergo kein Bild.
Mit der gspca-getriebenen Cam als /dev/video0 dann funktioniere Skyke 2 für Linux endlich — auch mein Gegenüber konnte auf seinem Windows-PC mein hübsches Konterfei dauerhaft erblicken.
Qualitativ allerdings bewegen wir uns hier, trotz LAN-Verbindung, auf UMTS-Niveau, was die Videoübertragung angeht: 160×120 Pixel mit 5 Bildern pro Sekunde, da kommt kein Kinofeeling auf. Der Sound allerdings ist aller erste Sahne, Respekt — da muß ich wirklich meinen Hut ziehen, für Sprachkommunikation scheint Skype wie geschaffen zu sein. Schade aber, daß man weder beim Windows- noch beim Linux-Client offensichtlich an der Bandbreite für Video etwas drehen kann; im Lichte von relativ fetten DSL-Zugängen würde ich mir eine bessere Bildqualität wünschen.
Fazit: die Skype-Leute sind meiner Meinung nach auf dem richtigen Weg; endlich auch Videounterstützung unter Linux, das rockt. Wenn sie jetzt noch anfingen, auch mal mit mehreren angeschlossenen Audio- und Videogeräten zu testen (meine ersten Skype-Versuche scheiterten 2005 an der (nicht vorhandenen) Anwählbarkeit meines USB-Headsets in den Auswahldialogen …) und entsprechend korrekten Code zu fabrizieren, könnte ich zufrieden sein. Ah, halt: Anbindung an Asterisk, um ggf. Anrufe via Skype auch auf meiem DECT-Gerät zu Hause entgegen nehmen zu können, das wäre noch so ein Wunsch … Und ein Gateway zwischen der Skype-Welt und der von Jabber, insbesondere hinsichtlich GoogleTalk. Grade auf meinem N810 leuchtet mir nicht so ganz ein, warum ich die Chat-Applikation (die mindestens im Falle GTalk auch Videotelefonie unterstützt) und Skype parallel laufen lassen soll – kost’ doch alles Strom …

Da wunderte ich mich, wieso keine Screenshots mehr gemacht werden — jetzt ist mir klar, warum :(

~ $ sh -c 'stamp=`date +%Y-%m-%d-%H-%M`; i=1; path=/home/user/MyDocs/.images; if mount | grep -q /media/mmc1; then path=/media/mmc1; fi; while [ -f $path/shot-$stamp-`printf %02d $i`.png ]; do i=$((i+1)); done; sleep 5 ; screenshot-tool $path/shot-$stamp-`printf %02d $i`.png'
screenshot-tool: »/home/user/MyDocs/.images/shot-2008-01-26-21-28-01.png« konnte nicht zum Schreiben geöffnet werden: Read-only file system
~ $ mount
rootfs on / type rootfs (rw)
/dev/root on /mnt/initfs type jffs2 (ro)
none on /mnt/initfs/proc type proc (rw)
none on /mnt/initfs/sys type sysfs (rw)
none on /mnt/initfs/tmp type tmpfs (rw)
/dev/mtdblock4 on / type jffs2 (rw,rpsize=1024,rpuid=0,rpuid=30000)
none on /tmp type tmpfs (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
none on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
/dev/mmcblk0p1 on /media/mmc2 type vfat (ro,nosuid,nodev,noexec,uid=29999,fmask=0133,dmask=0000,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8)

Hmm. Meine geplante, kismet-unterstützte Wanderung vorhin tat auch nicht so richtig; der N810-gpsd scheint ein Limit von 2 parallelen Verbindungen zu haben, jedenfalls zeigte kismet als 3. gpsd-Nutzer keine Koordinaten an. Mag aber auch an kismet liegen, denn da, wo Python als auch Maemo Mapper wenigstens einen 2D-, wenn nicht 3D-Lock zeigten, meldete kismet unverdrossen in der GUI zwar Koordinaten, aber auch “NO LOCK” .Das nach ca. 60 Minuten kismet-Nutzung (IP-Verbindung in der Zeit via BT/UMTS) verwirrte WLAN konnte ich durch rmmod, insmod (siehe Screensh…, ah, nein, der fehlt auch schon :() reanimieren; da aber jener Screenshot schon fehlt, muß der zum ro-Remount geführt habende Vorfall schon unterwegs geschehen sein. Leider vollkommen still :(
Mal sehen, tut reboot gut?

~ $ sudo gainroot
Root shell enabled
BusyBox v1.6.1 (2007-09-27 18:08:59 EEST) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
/home/user # reboot

Yepp!

~ $ mount
rootfs on / type rootfs (rw)
[...]
/dev/mmcblk0p1 on /media/mmc2 type vfat (rw,nosuid,nodev,noexec,uid=29999,fmask=0133,dmask=0000,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8)

Also, verstehen tue ich nicht, was hier abgeht. Wann das /media/mmc2 read-only wurde, und warum, scheint nicht nachvollziehbar. Im dmesg stand soviel anderer Mist, daß zum ro-Remount nichts mehr zu finden war :(

62] EAC mode: play enabled, rec enabled
[ 6212.695312] EAC mode: play disabled, rec disabled
[ 6214.710937] EAC mode: play enabled, rec enabled
[ 6226.187500] EAC mode: play disabled, rec disabled
[ 6229.593750] EAC mode: play enabled, rec enabled
[ 6233.671875] EAC mode: play disabled, rec disabled
[ 6245.781250] EAC mode: play enabled, rec enabled
[ 6245.843750] dev_mc_discard: multicast leakage! dmi_users=1
[ 6245.890625] cx3110x: driver version 2.0.15 unloaded.
[...]

Irgendwie ganz schön doof …

I’m suffering from quite frequent (sometimes up to four a day — the N810 is nearly always on and for >90% of the time connected to the Internet (WLAN or UMTS-over-BT) reboots of my N810. Reading ReportingRebootIssues, I went to check the common files:

~ $ cat /proc/bootreason
32wd_to
~ $ ls -la /var/lib/dsme/stats/lifeguard_resets
ls: /var/lib/dsme/stats/lifeguard_resets: No such file or directory
~ $ ls -la /var/lib/dsme/stats/
drwxr-xr-x 2 root root 0 Jan 21 22:11 .
drwxr-xr-x 3 root root 0 Jan 1 1970 ..
-rw-r--r-- 1 root root 3 Jan 21 22:11 32wd_to
-rw-r--r-- 1 root root 61 Jan 17 04:32 lifeguard_restarts
-rw-r--r-- 1 root root 2 Jan 17 17:42 sw_rst
~ $ more /var/lib/dsme/stats/32wd_to
14
~ $ more /var/lib/dsme/stats/lifeguard_restarts
/usr/bin/hildon-input-method : 4
/usr/sbin/ke-recv : 4 *

Digging deeper down, I even checked dmesg (because of “If the device boots and reboots several times, then log in to a shell and check “dmesg” for whether this boot also ran out of memory (“OOM”) and the kernel happened to kill something that was not essential this time.”) — the only troublesome (for my liking) entry I found is:

[ 62.671875] JFFS2 notice: (403) check_node_data: wrong data CRC in data node at 0x01b87580: read 0xf56b695c, calculated 0xd4218b92.

Since I don’t use any MMC/SC yet, this must relate to the internal 2 GB of flash memory. I’m not that much into flash file-systems, does that mean I have a) broken internal flash memory, or b) there was data corruption (maybe due to the reboot(s)) or c) there is still a bug lurking around and I did trigger it? I’ve found a patch while googling around, which seems to be destined for 2.6.21 and tackle CRC issues:

commit 10731f83009e2556f98ffa5c7c2cbffe66dacfb3
Author: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Date: Wed Apr 4 13:59:11 2007 +0300
[JFFS2] fix buffer sise calculations in jffs2_get_inode_nodes()
In read inode we have an optimization which prevents one min. I/O unit (e.g. NAND page) to be read more then once.
Namely, at the beginning we do not know which node type we read, so we read so we assume we read the directory entry, because it has the smallest node header. When we read it, we read up to the next min. I/O unit, just because if later we’ll need to read more, we already have this data.
If it turns out to be that the node is not directory entry, and we need more data, and we did not read it because it sits in the next min. I/O unit, we read the whole next (or several next) min. I/O unit(s). And if it happens to be that we read a data node, and we’ve read part of its data, we calculate partial CRC. So if later we need to check data CRC, we’ll only read the rest of the data from further min. I/O units and continue CRC checking.
This code was a bit messy and buggy. The bug was that it assumed relatively large min. I/O unit, so that the largest node header could overlap only one min. I/O unit boundary.
This parch clean-ups the code a bit and fixes this bug.
The patch was not tested on flash with small min. I/O unit, like NOR-ECC, nut it was tested on NAND with 512 bytes NAND page, so it at least does not break NAND. It was also tested with mtdram so it should not break NOR.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

 
My N810 tells me it’s running “2.6.21-omap1 #2 Fri Dec 7 11:17:13 EET 2007 armv6l unknown” – so, am I safe?

Nachdem meine Lust, Nokia weiter Geld in den gierigen Rachen zu werfen, mehr und mehr gen Null tendiert, ich aber dringend ein mobil einsetzbares Gerät suche – das N95 ist aufgrund der formatbedingten Restriktionen nur für den absoluten Notfall als ssh-Console (mit einem BT-Keyboard) und zum Surfen faktisch nicht geeignet und das E90 kommt aus naheliegenden Gründen nicht mehr in Betracht –, schweifen meine Äugelein wieder mehr zum anderen derzeit hippen Gerät, dem Eee-PC.
Doch leider kommt auch Asus nicht in den Quark, dank des günstigeren Preises (bei tendentiell ähnlicher Grundausstattung) wäre mir ein (funktionierender) Promotioncode allerdings auch weit weniger wichtig als beim zumindest theoretisch coolen N810. Verglichen mit den N810 ist der Eee-PC allerdings auch deutlich größer — für mich, der seit 2000 mit einem 12″-Laptop Vaio Z600NE (1,7 kg mit Akku, IIRC) rumgelaufen ist, ist die Größe aber nicht ganz das ausschlaggebende Kriterium …
Viel gravierender – und, sorry, absolut unverständlich – ist aber das Fehlen von Bluetooth an Board des Eee; momentan kann ich mir beim besten Willen nicht erklären, was der Schwachsinn das soll.
BT ist für mich der Kurzstreckenfunk, über den vom GPS bis zum GSM-/UMTS-/HSDPA-Modem alles angebunden werden kann — und normalerweise wird. GPS-Empfänger auf dem Armaturenbrett, Laptop im Kofferraum (versorgt von Spannungswandler aus dem Bordnetz) — funktioniert hervorragend zum Aufzeichnen der Routen (und parallelen WLAN-Scanning, wenn’s eh schon alles läuft). Oder auch ein Verbindungsaufbau on demand zum Internet via Handy — kein Thema. Und keine störenden (USB-) Kabel … (Und bei UMTS bleibt man (sprach-) telefonisch weiterhin erreichbar.)
Da ich zwangsweise warten muß – da ich keinen Eee heute kaufen kann –, werde ich ich wohl die nächste Iterationsstufe, den Eee mit größeren Display, noch abwarten. Von BT steht bei dem zwar auch nix, aber ein Display mit 1024×600 statt 800×480, darauf zu warten lohnt sich allemal, imho.

There is no fun anymore. The Maemo people told me …

The discount codes of the N810 maemo contributors program are going to be valid from today onwards in the supported Nokia shops. Some of the shops might not have device in stock yet. If this is the case of your country please be a little bit (more) patient.
This is the list of shops supported:
[URLs for ordering in AT, BE, DK, FI, FR, GE, IR, IT, NL, ES, SE, NO, CH, UK]
Remember that your discount code is: 08154711. The code will be valid until the end of February. Please keep it in a safe place since this is the last time we will send it. If you have further questions please contact the customer care channel of your shop.
We had to make some changes in some codes. In case the code listed here is different than the one you received, this is the good one.
The maemo team wishes you a great time playing with the N810. Remember to share your plans and contributions at http://maemo.org .

 
Well, I don’t blame the Maemo people; I assume they, again, were working in good faith that the codes would really, really be working now in Nokia’s online shops. I further assume someone at Nokia actually told them that — a blatant lie, as it seems to me.
As requested, I tried to contact my Nokia online shop’s customer care channel — not an easy task, as they don’t show their hotline phone number at places where one would expect them to. (A colleague tried their Web interface once but it took the people responsible at Nokia Germany a whole week to come up with a first response, which was ”it’s being worked on“ — I bet they don’t do customer satisfaction surveys, do they?)
I finally found it, Nokia states:

Sollten Sie Fragen haben, können Sie sich direkt an unseren Kundenservice wenden. Unser Kontaktformular für Anfragen per E-Mail finden Sie hier. Von Montag bis Freitag zwischen 9 und 18 Uhr (ausgenommen bundesweite Feiertage) sind wir auch telefonisch unter der Nummer +49 (1805) 2582 66542 (0,14 €/Min.)* erreichbar.
[…]
*Die Angabe gilt für Anrufe aus dem Festnetz der Deutschen Telekom AG. Bitte erfragen Sie den gültigen Tarif bei Ihrem Netzbetreiber, wenn Sie den Nokia Online Shop-Service von Ihrem Mobiltelefon aus anrufen möchten.

 
Well, I choose to use my VoIP carrier to call that customer service line. It was a tremendous success — wouldn’t I have set my personal call duration limit to 30 minutes, I assume I’d be still sitting here holding the line by next week:

So, Nokia Germany was not willing to pick up it’s german online shop support line on a non public holiday Friday between 16:40 and 17:10 — they kept me on hold with this crappy endless loop for over thrity minutes until I nearly jumped out of the window! And I was calling well within the advertised call-in times …
Nokia Germany practically stole me 4,95 EUR today. And they fooled me and the Maemo people again, as even the new promotional codes are not working in their blasted online shop.
I’m not willing to let get Nokia away with this.
Not answering the announced customer care line during advertised call-in hours for half an hour means that Nokia Germany does not care a damn about it’s customers. They could as well have said on that endless loop

Go and fsck yourself, annoying pieace of shit. We are Nokia, world’s largest maker of mobile phones. Don’t bother us with questions, slimy little customer! Just buy our bug-infested phones and then shut up.

 
Actually, that’s what I understood for the last ten minutes holding the line and listening to the crappy jingle over and over again. Well, if that’s what Nokia wishes, I think this can be arranged. (Sort of; I won’t fsck myself, obviously, but some arrogant company.)
But there are some good news as well: All of the successful participants in this N810 promotion from Germany may at least get their N810 before Christmas, the Nokia Germany online shop promises! (Well, provided they finally get a clue and the promotional codes working until the end of February 2008 — at which time these codes will become worthless. Given Nokias proven past performance in this area, I personally won’t bet on it.)

… zum Fest gab’s dieses Jahr von meiner Seite aus nur vereinzelt; das hat mit dem moderat chaotischen Gesamtverlauf des Jahres zu tun, letztlich aber primär mit dem Doppel-RAID-Fehler, der die übliche Last-Minute-Greet-em-all-Session vereitelte. Wen’s also hierher verschlägt und sich über das Ausbleiben der obligatorischen »Frohe Weihnachten und ein recht neues 2008!«-Mails von mir wundern sollte — hier die Erklärung.
An meinem RAID-Problem hänge ich denn auch noch immer; habe erst einmal den MX auf 21 Tage Haltezeit hochgedreht — one never knows.
Mittlerweile weiß ich, daß ich tatsächlich zwei Platten mit Lesefehler verloren habe, fatalerweise natürlich beim Versuch, einen bestimmten Block zu lesen — auf Datenverlust kann ich mich also schon mal fest einstellen (2 von 4 aktiven Platten im RAID-5 können den Block nicht lesen), die Frage ist nur, wieviel der 680 GB ich abschreiben darf. Im Prinzip ist es /video01, sprich der Storage für meine heimischen VDRs (BTW: Danke, ARD, für 10+ Regionalsender mit identischem Basisprogramm; Wissen macht Ah!«-Folgen sind mittlerweile ein Lasttest des Systems geworden …), leider habe ich diesem vermeintlich sicheren Filesystem auch Teile des virtualisierten Systems mail.uu.org anvertraut — die nun nicht mehr errichbar oder gar vorhanden sind. (Und ja, meine Backupstrategie ist … nicht existent.)
Vier neue WD 250er sind im Zulauf, aber ein »Elektronische Sendungsdaten liegen vor« von gestern abend läßt mich nicht hoffen, diese heute noch in Händen zu halten. Narf.
So rückblickend betrachtet, also, von mir aus könnte man 2007 auch getrost aus der Geschichte streichen, außer Spesen (und einem tollen Urlaub, okay, …) nichts gewesen.

… kaum kurz außer Haus, schon sterben zwei von vier Platten im RAID-5. Nach dem Reboot kommt die Kiste nat. nicht wieder hoch (hängt wohl beim mount) – und da der File- auch der DHCP-Server ist, ist nun auch ein weiterer Server, der wg. “mount: /FS is busy” rebootet wurde, platt: ohne DHCP-Server keine IP :(
Jetzt fehlt noch ein Metoriteneinschlag in unser Haus, und dieses Chaosweihnachten 2007 ist komplett …

Ja, nee. Iss klar, Mustek …
Wenn man 40 Prozent Batteriekapazität einfach aufgrund des Anliegens von Netzspannung sich erhofft, dann verwundern die harten Aufschläge meiner Server mich zumindest nicht mehr.
Fragt sich nur, wer den Fehler jetzt behebt; eine USV, die beim Wegfall der Netzspannung sofort 40% weniger Kapazität anbietet als unter externer Versorgung darf, in meiner kleinen Welt, als broken beyond repair bezeichnet werden. Sowas als Neugerät erworben zu haben — ernsthaft, das böse Wort mit dem »Be« vorne und dem »trug« hinten drängt sich mir förmlich auf.
Aber immerhin funktioniert, wenn auch grade ungewollt ;), die Serverabschaltung via nut:
Broadcast message from nut (Sun Dec 23 01:09:35 2007):
UPS ups1@localhost on battery
Broadcast message from nut (Sun Dec 23 01:52:11 2007):
Executing automatic power-fail shutdown
Broadcast message from nut (Sun Dec 23 01:52:11 2007):
UPS ups1@localhost battery is low
Broadcast message from nut (Sun Dec 23 01:52:11 2007):
Auto logout and shutdown proceeding
Broadcast message from root (Sun Dec 23 01:52:16 2007):
The system is going down for system halt NOW!
Plöd nur, daß a) dieses System gar nicht mehr an dieser USV hängt und b) somit unter realen Geschehnissen dieser Fall nie eintreten wird. Aber vielleicht ist diese »Mustek PowerMust« ja auch nur ein Montagsmodell?