In ein paar Tagen möchte ich meine Bachelorarbeit anmelden, doch die Angstrom Distribution auf dem Beagleboard macht Ärger. Mit ist es bisher nicht gelungen ein Image zu erstellen, mit dem ich wirklich arbeiten kann. Zumindest die Hürde mit den inkompatiblen Versionen des U-Boot Bootloaders habe ich inzwischen überwunden.

Jedes Image, das ich über den Online-Build-Service Narcissus erstellt habe, bricht leider beim Bootvorgang mit einem Kernel-Panic ab oder wirft mich ohne aussagekräftige Fehlermeldung auf eine Notfall-Shell.

Mit dem aktuellen Beagleboard-Demo-Image komme ich derzeit noch am weitesten:

Ethernet über USB, USB Stick, Tastatur und Maus funktionieren. SSH-Shell, SFTP – das ist ein Anfang. Selbst der X11-Server mit Enlightment startet und lässt sich etwas stockend bedienen. Damit sind zumindest theoretisch die meisten Voraussetzungen bereits gegeben.

Es fehlen nur noch ein Compiler, um die DSPLink Examples auf dem Board bauen zu können und die Utilities für die ALSA Schnittstelle, um dort die Aufnahme und Ausgabe testen zu können. Das alles sollte meiner Meinung nach über das OPKG Paketemanagement-System installierbar sein. Leider schlägt ein einfaches opkg upgrade wegen Speicherproblemen schon beim Download der Pakete fehl. Da ich das Beagleboard mit seinen 256MB Ram ohne SWAP-Space betreibe, treten die Probleme recht schnell auf und es werden zufällige Prozesse abgeschossen, bis es auch den opkg-Prozess erwischt.

Mein Enlightment hat es dabei schon  erwischt und will nicht starten.

Wäre nur das Wiederherstellen des ursprünglichen Zustands nicht so zeitaufwändig:
Zwei Gigabyte per dd über einen Cardreader auf die SDHC-Karte zu bekommen dauert einfach ewig (~2 MB/ Sekunde).

Der BurnOut ist aber noch fern, auch wenn ich so langsam gerne mit der “richtigen” Arbeit beginnen würde.

Die nächsten Optionen: SWAP auf USB-Stick (langsam) und externes manuelles Übertragen der richtigen Pakete auf die SD-Karte.

Vor zwei Wochen hatte ich mich hier über den wachsenden Speicherhunger meiner Spielepartition beschwert, die nicht mehr auf die 160GB Systemplatte passen wollte. Aus diesem Grund (und um meinen Server auf die kommende Bachelorarbeit vorzubereiten) lag gestern u.a. eine neue Festplatte im Briefkasten bzw. beim Nachbarn.

Das Klonen der gesamten Festplatte mit dd aus Ubuntu heraus wollte aber zunächst nicht klappen. Nach 21 GB gab es einen Input/Output-Error und das Tool brach ab. Trotzdem an dieser Stelle ein kleiner Tipp, um lange Datentransfers ohne Ausgabe durch Pipes zu überwachen: Der kleine Befehl pv schreibt die Datenrate und die übertragene Datenmenge auf die Standardausgabe und ist nicht sonderlich bekannt.

1

dd if=/dev/sdx of=/dev/sdy

wird zu

1

dd if=/dev/sdx | pv | dd of=/dev/sdy

Aber zurück zur Festplatte: (weiterlesen…)

Mich hat es vorgestern Abend beim Update auf Ubuntu 9.10 Karmic seit langem mal wieder so richtig erwischt. Nach dem Update (und vorheriger Sicherung) war Grub nicht mehr in der Lage seine Daten zu finden. Eventuell hatte sich das Problem aber schon vorher entwickelt, denn trotz separater Boot-Partition in der sich zumindest nach der Installation zwei recht aktuelle Kombinationen aus Kernel/Initrd befanden, war auch der unbenutzte Mountpoint auf der root-Platte voller Kernel deutlich älterer Bauart – wie ich mithilfe einer GRML-LiveCD heraus fand. Grub könnte sich also die gesamte Zeitspanne seit 9.04 aus diesem Verzeichnis bedient haben. Und zu meiner Schande muss ich gestehen, dass ich nie bewusst kontrolliert habe, ob der jeweils aktuelle Kernelversion auch korrekt im Bootmenü angezeigt wurde.

Kernel-Updates wurden korrekt auf die boot-Partition installiert, während der Bootmanager noch immer seine Auswahl aus dem /boot Verzeichnis bezog und den immer gleichen Kernel bootete. Sicherheitslücke hoch 2!

Genau zurückverfolgen, kann ich dies jetzt nicht mehr – dafür habe ich bei der Fehlersuche schon zu viel überschrieben – aber diese Version scheint in meinen Augen am plausibelsten zu sein.

Karmic als Ganzes hat ja schon einiges an negativer Presse über zerstörte Installationen bekommen, aber dies muss ich mir wohl doch selber zuschreiben. Abgesehen von diesem Problem, das mich einige Stunden gekostet hatte (ändern, booten, grml rein, wieder booten, grub konsole, …) läuft aber alles wieder sauber und stabil.

Die Hardware lag schon einige Zeit bei mir herum:

• Jumtec CoolMonster CMP/P166L
  Ein Industrie-Board mit PISA-Schnittstelle (ISA+PCI vereint), auf dem ein low-power Pentium 1 MMX mit 166 MHz arbeitet. Typische Leistungsaufnahme <10W dank embedded CPU.
• 128MB SDRAM
• PISA Backplane mit einigen PCI und ISA Steckplätzen
  Spannungsversorgung über die alten AT-Stecker oder über Schraubklemmen.
• PCI-Netzwerkkarte mit Realtek 8139 Chipsatz
• Dual-CompactFlash Adapter mit einer 8GB CF-Karte
• Netzteil mit 12V und 5V
  Inzwischen in einem alten ATX-Netzteil verbaut, damit es ausreichend belüftet und geschützt in ein normales Gehäuse passt. Zudem liegt der Eingang auf einer Kaltgeräte-Buchse und lässt sich mit einem Schalter unterbrechen.
• 19 Zoll Gehäuse mit 4 HE

Ausgabe von lspci:

00:00.0 Host bridge: ALi Corporation M1541 (rev 04)
00:01.0 PCI bridge: ALi Corporation M1541 PCI to AGP Controller (rev 04)
00:07.0 ISA bridge: ALi Corporation M1533/M1535/M1543 PCI to ISA Bridge [Aladdin IV/V/V+] (rev c3)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c1)
00:14.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
01:02.0 VGA compatible controller: Chips and Technologies F69000 HiQVideo (rev 64)

Die Installation des Basis-Systems nahm ich in einem zweiten Rechner vor, da ich ohne neue Kabel zu verlegen, neben dem Board nur noch den CF-Adapter versorgen konnte. Leider unterstützt das “Monster” weder das Booten von USB, noch von einer präparierten zweiten CF, die das Dateisystem einer Install-CD (syslinux) enthält. Also baute ich den Adapter zunächst in einen Rechner mit optischem Laufwerk ein.
(weiterlesen…)

Neuinstallationen stürzen mich in schöner Regelmäßigkeit in die Krise. In dieser Minute läuft auf meinem PC nur noch die Ubuntu Installation.

Bei der “Rückabwicklung” meiner Windows XP Installation hab ich es irgendwie geschafft, das BS so zu verbiegen, dass die explorer.exe nicht mehr startet. Dabei hab ich nur so viele unwichtige Programme wie möglich deinstalliert, um das zweiten Komplettbackup auf einen einzigen DVD-Rohling zu bekommen. Zum Glück schlummert auf einer anderen Festplatte ein kompletter Dump der Partition im lauffähigen Zustand. Allerdings bzip2 gepackt – bis ich das wieder aufgespielt habe, kann ich den Kram auch stundenlang zusammen frickeln.

Und eigentlich möchte ich ja Windows Vista installieren – da sind mir aber beim Brennen ein paar Datenfehler auf die Installationsmedien geraten. Argh. Das Neubrennen bereitete Schwierigkeiten, weil der NTFS Treiber den Datenträger nur noch gezwungenermaßen anfassen möchte. “NTFS logfile is unclean” – dem Vista Installer sei dank. Darum lade ich parallel zu meinen Installationsversuchen, das ISO neu vom MSDNAA Server der FH. Vielleicht ist mein Notebook ja in der Lage das ISO vollständig auf eine DVD-RW zu schreiben (andere Rohlinge hab ich gerade nicht zur Hand).

Schön das ich mit Ubuntu noch einen letzten Zufluchtsort habe, bis mir Vista den MBR überschreibt.

Nachtrag: Windows Vista bricht die Installation jetzt schon vor der ersten Eingabemaske ab: error message 0x00000e9 (IDE und AHCI Modus). Die Windows XP Installation stürzt sogar ab.

Nach dem Booten kommt: “Fehler beim Laden des Betriebssystems”. Jackpot!

Wenns ein grub-install unter grml nicht behebt, fang ich an zu heulen.

Nachtrag2: Läuft wieder. Aber bei der Partitionstabelle ist was im argen.