Nachdem ich nun mehrere DockStars mein Eigen nenne und die an verschiedensten PCs hängenden USB-HDDs nun an diesen zusammenführen möchte, habe ich an einem »frischen« DockStar eine neue Methode zur »Befreiung« ausprobiert.
Vorweg: ich benutzte einen selbstgebackenen Linux-Kernel (2.6.32.2 von kernel.org), der um die DockStar-Patches von Alexander Holler, welchen ich auf einer x86-Kiste cross-compile und den ich per tftp mit dem orginalen DockStar-uBoot boote. Aufsetzen eines TFTP-Servers, Patching sowie Cross-compiling des Kernels sind an anderen Stellen im Netz dokumentiert, ich gehe darauf hier nicht ein — unter anderem auch, um nicht falsche Hoffnungen bei Linux-Anfängern zu wecken: der (Unter-) Titel, den Alexander Holler für seinen Artikel gewählt hat – »How to brick your DockStar and void the warranty« – ist kein Scherz; die Gefahr, seinen DockStar zumindest soweit unbrauchbar zu machen, daß man mit einer seriellen Schnittstelle mit TTL-Pegel den Innereien zuleibe rücken muß, ist nach wie vor hoch!
Dies vorausgeschickt, primär als Gedächtnisstütze für mich, mein aktuelles Kochrezept:
- An anderem Linux-PC auf einem USB-Stick oder einer USB-HDD das Filesystem erzeugen. Ich bin gemäß »Manually unpacking a tar ball of Debian on SheevaPlug« vorgegangen, also Debian Lenny (armel) auf Medium ausgepackt.
- Dann nicht vergessen, die etc/fstab dort zu editieren, ich habe auf einem 4 GB-USB-Stick 3 GB /dev/sda1 als ext3 und den Rest als /dev/sda2 für Swap:
/dev/sda1 / ext3 errors=remount-ro 0 1 /dev/sda2 none swap sw 0 0
- Die zum Kernel gehörenden lib/modules- und lib/firmware-Dateien aus dem Kernelbau in das neue Filesystem zu kopieren sollte man nicht vergessen ;)
- Medium vom (x86-) Linuxrechner abmontieren und ggf. beschriften; dann an den ausgeschalteten DockStar stecken und diesen zum ersten Mal booten. Einloggen per ssh und dann blparam holen:
-bash-3.2# mount -o rw,remount / -bash-3.2# cd -bash-3.2# wget http://plugapps.com/os/pogoplug/uboot/blparam -bash-3.2# chmod 755 ./blparam -bash-3.2# cp -p blparam /tmp/.cemnt/mnt_sda1/root/
Der letzte Befehl kopiert das Binary gleich in die neue Umgebung.
- Jetzt die Bootparameter anpassen — dabei auch diese Beispielsdaten natürlich an die lokalen Gegebenheiten ;)
-bash-3.2# ./blparam netmask=255.255.255.0 -bash-3.2# ./blparam ipaddr=192.168.5.236 -bash-3.2# ./blparam serverip=192.168.5.2 -bash-3.2# ./blparam arcNumber=2097 -bash-3.2# ./blparam bootcmd_tftp='tftp 0x800000 uImage ; setenv bootargs root=/dev/sda1 rw rootdelay=5 rootfstype=ext3 ; bootm 0x800000' -bash-3.2# ./blparam bootcmd2b='setenv bootcmd run bootcmd1 ; saveenv ; run bootcmd_original' -bash-3.2# ./blparam bootcmd_original='nand read.e 0x800000 0x100000 0x300000; setenv bootargs $(console) $(bootargs_root); bootm 0x800000' -bash-3.2# ./blparam bootcmd2='setenv bootcmd run bootcmd2b ; setenv mainlineLinux no ; saveenv ; reset' -bash-3.2# ./blparam bootcmd1b='setenv bootcmd run bootcmd2 ; saveenv ; run bootcmd_tftp' -bash-3.2# ./blparam bootcmd1='setenv bootcmd run bootcmd1b ; setenv mainlineLinux yes ; saveenv ; reset' -bash-3.2# ./blparam bootcmd='run bootcmd1'
- Nun noch /root/blparam bootcmd="run bootcmd1" >/dev/null 2>&1 nach /tmp/.cemnt/mnt_sda1/etc/rc.local hinzufügen und auch einmal ausführen.
- Nach einem Reboot sollte nun das neue Linux hochkommen, Zugriff bekommt man wie folgt:
When Debian has started, you can login as user root with the password root.
Disclaimer: Worked for me, your mileage may vary, no liability assumed. You may loose your warranty by doing this. You have been warned. Seriously, don’t try this at home!
Mein erster Versuch schlug fehl, nur jeder zweite Boot klappte, und dann in den »DockStar-Modus«; der Grund war schlicht, daß ich das FS auf dem USB-Stick weder bzgl. /etc/fstab angepaßt hatte noch die Module meines Kernels ‘rüberkopiert. Nachdem ich das nachgeholt hatte, bootete mein dockstar-3 sauber wiederholt ins Debian. Weitere Änderungen: ssh-Keys in /etc/ssh/ neugebaut – sonst hätte ja jeder DockStar identische Host-Keys – und natürlich /etc/hostname angepaßt.
Immerhin, dieser dritte angefaßte DockStar war der Erste, den ich bislang nicht für den Zugang per Console öffnen mußte ;)
Hope this helps; aber, wie gesagt, zur Nachahmung nur dem empfohlen, der sich mit Linux hinreichend auskennt und der auch kein Problem damit hat, den DockStar zu öffnen und an den vorhandenen Pins einen Adapter anzuschließen, um auf die Console zugreifen zu können.
Der Vorteil im obigen Vorgehen ist für mich einerseits, daß ich im sowieso vorhandenen Netz den Kernel per tftp bereitstellen kann und es kein Vertun gibt, von welchem Medium der Kernel nun geholt werden soll (die Reihenfolge der USB-Geräte-Erkennung erscheint mir noch immer teils zufallsgesteuert?), ferner erspare ich mir das Flashen eines zweiten U-Boot in den freien Flash-Bereich des DockStar; evtl. kann man den Bereich ja später für eine initrd nutzen oder ein minimales Root-FS …
[Edit: Unter Punkt 2 stand bis 2010-06-22 02:35 noch »ext2«, was natürlich Blödsinn ist für ein ext3-FS. Das ist mir natürlich nicht aufgefallen, da man ein ext3 ja als ext2 mounten kann, was mein »dockstar-2« auch tapfer gemacht hatte … Ich habe das auf »dockstar-2« (nein, nicht »frogstar-b« ;)) geändert, ihn rebootet … und er kam brav wieder hoch, jetzt mit einem / als ext3. Danke an Detlef, den aufmerksamen Leser!]


Hi again :-D
mein NSLU2 wird langsam unruhig, er sieht wohl schon kommen, dass er bald durch einen Dockstar ersetzt wird…
Ich war übrigens zu träge, mir einen eigenen Kernel zu compilieren, und hab einfach den Debian Kernel für den Sheevaplug (linux-image-2.6.32-5-kirkwood) genommen.
Ok, die mtd-Partitions sind in dem Kernel anders und beim Booten werden diesbezüglich Fehler angezeigt, aber wir benutzen die ja eh erstmal nicht. Und nur wegen der LED nen eigenen Kernel bauen… später vielleicht irgendwann…
Zusätzlich zum Kernel hab ich dann also auch die initrd auf den tftp-Server gelegt und die blparam-Zeile angepasst:
blparam bootcmd_tftp=’tftp 0x800000 uImage ; tftp 0x01100000 uInitrd; setenv bootargs console=ttyS0,115200 root=/dev/sda2 rw rootdelay=5 rootfstype=ext3 ; bootm 0x800000 0x01100000′
Bei mir ist root auf /dev/sda2, und die console geht so auch besser. Am liebsten würde ich ja direkt die UUID eintragen damit er nicht von der falschen Platte bootet, aber ich fürchte irgendwie, zu dem Zeitpunkt kann der kleine mit /dev/disk/by-uuid/….. noch nichts anfangen.
Ansonsten scheints so erstmal zu tun. Bis auf die Uhrzeit, die ich mit rdate und ntp setze, allerdings erst nach den Filesystem checks…
Georg
Cool; das mit ‘ner initrd steht bei mir auch noch auf der Liste; schön, daß mir jemand die Arbeit abnimmt rauszusuchen, wie das geht ;) Muß man dem Kernel noch was bestimmtes auf den Weg geben, damit er mit ‘ner initrd umgehen kann? (Ja, Asche auf mein Haupt, aber das sind jetzt so Dinge, die ich im täglichen Leben im x86-Umfeld nicht zu wissen brauche, die üblichen Distributionen kommen diesbezüglich ja fertig daher.)
Die mtds nutze ich schon — denke ich jedenfalls, blparam schreibt ja direkt das Flash um … Das mit dem eigenen Kernel, naja, den hatte ich eh’ gebacken für meine Sheevas, da ich das uvcvideo-Modul brauchte, der Mehraufwand für ‘nen DockStar-Kernel war somit sehr gering ;)
Die Filesystem-Checks sind bei mir jetzt weg, nachdem ich die Filesysteme mit »tune2fs -c0 -i 0« bearbeitet habe — ich kann es eh’ nicht ausstehen, daß nach 1,5 Jahren Laufzeit nach einem Reboot willkürlich fscks gefahren werden. Wenn sie was entdecken, dann ist’s eh’ aus, da ich die Meldung auf der Console ja nicht mitbekäme — und erfahrungsgemäß nicht die logische FS-Struktur im Eimer ist (ext3 ist da, anders als ext4, erstaunlich rebust), sondern die Hardware :(
Würde bzgl. der Meldungen »netconsole« eigentlich helfen? Soweit ich das verstehe ist das nur ein sendender Weg, kein empfangender, d. h. den »fsck -y« könnte ich darüber nicht starten?