Posted on by wusel

DockStar debianisieren per NFS-Root, ohne Consolenzugriff

Von Dirk Tostmann auf die Idee gebracht, versuche ich mich derzeit an einem Prototypen für das Umflashen eines DockStars zu einem »kleinen« SheevaPlug. Ich habe im Folgenden versucht, meine Schritte zu dokumentieren, die Idee dazu stammt, wie gesagt, von Dirk. Die nachfolgenden Schritte habe ich mittlerweile an einem zweiten DockStar ausprobiert — ohne die Console bemühen zu müssen.
Aber dennoch, auch um mich abzusichern: DON’T TRY THIS AT HOME (YET)! IT MOST CERTAINLY WILL BRICK YOUR DOCKSTAR DEVICE! Sollten einzelne Schritte fehlschlagen, z. B. das Booten der NFS-Root nicht funktionieren, ist es notwendig, die serielle Schnittstelle des DockStars zu aktivieren. You have been warned …
Ablauf:

  1. Umgebung vorbereiten: uImage von sheeva.with-linux.com holen, auf dem TFTP-Server ablegen (hier als »sheeva-2.6.34-uImage«, ggf. anpassen).
  2. NFS-Rootumgebung bereitstellen auf einem vom DockStar erreichbaren NFS-Server. Ich nehme dazu wieder das Debian-Lenny-Archiv; zum uImage passende Modules von sheeva.with-linux.com holen und in der NFS-Root ablegen; ebenfalls das uImage nach $NFSROOT/boot packen.
    Die Datei $NFSROOT/etc/fstab korrigieren (alles auskommentieren), $NFSROOT/etc/mtab zur Sicherheit löschen. In $NFSROOT/etc/network/interfaces die Zeilen mit eth0 auskommentieren; das Netzwerk ist bei NFS-Root schon konfiguriert, wenn die init-Skripte loslaufen (nette Falle BTW ;)). Evtl. auch $NFSROOT/etc/resolv.conf anpassen, wenn man einen lokalen Nameserver hat (Fritz!Box z. B.).
  3. UBIFS erzeugen und in NFS-Root ablegen; ich habe hierzu ebenfalls das Lenny-FS genommen (um ehrlich zu sein: die NFS-Root nochmal kopiert) und insbesondere dort etc/network/interfaces angepaßt, sodaß eth0 per DHCP versorgt wird. Auch etc/hostname und etc/hosts habe ich dort angepaßt, schon um Unterschiede zur NFS-Root zu sehen.
    Erzeugung des UBIFS (im Unterverzeichnis ubifs-root-fuer-DockStar); im Ubuntu 10.04-Paket sind alle erforderlichen Binaries drin, wer auf Debian Lenny arbeitet, braucht das mtd-utils-Paket aus Debian Testing): 

    cat <<eof >ubi.cfg
[ubifs]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=200MiB
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize
eof
mkfs.ubifs -r ubifs-root-fuer-DockStar -m 2048 -e 129024 -c 4096 -o ubifs.img -x zlib
ubinize -o ubi.img -m 2048 -p 128KiB -s 512 ubi.cfg

    Die Datei ubi.img dann ins / des NFS-Roots kopieren.

  4. DockStar normal booten, IP per DHCP geben lassen. Einloggen per SSH (root, stxadmin). Dann: 
    cd
mount -o rw,remount /
wget http://plugapps.com/os/pogoplug/uboot/blparam
chmod 755 ./blparam
export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/root
blparam orgbootcmd='nand read.e 0x800000 0x100000 0x300000; setenv bootargs $(console) $(bootargs_root); bootm 0x800000'
blparam netmask=255.255.255.0
blparam ipaddr=192.168.5.235
blparam serverip=192.168.5.2
blparam arcNumber=2097
blparam mainlineLinux=yes
blparam bootargs_end=:::DB88FXX81:eth0:none
blparam tftpboot='tftp 0x800000 sheeva-2.6.34-uImage ; setenv bootargs $(console) root=/dev/nfs rw rootdelay=5 nfsroot=192.168.5.245:/nfs/DockStar_tmp ip=$(ipaddr):$(serverip)$(bootargs_end) ; bootm 0x800000'
blparam bootcmd='run tftpboot'
blparam mtdparts='orion_nand:0x100000@0x0(u-boot),0x400000@0x100000(uImage),0x2000000@0x500000(rootfs),0xDB00000@0x2500000(data)'
blparam tftpboot='tftp 0x800000 sheeva-2.6.34-uImage ; setenv bootargs $(console) root=/dev/nfs rw rootdelay=5 nfsroot=192.168.5.245:/nfs/DockStar_tmp ip=$(ipaddr):$(serverip)$(bootargs_end) $(mtdparts) ; bootm 0x800000'

    Hier die Daten natürlich dem eigenen Umfeld entsprechend anpassen. Achtung, in dieser Konfiguration hat der NFS-Root-gebootete DockStar *kein* Default-Gateway!

  5. Dann beherzt einen Reboot des DockStars durchführen.
  6. Nach kurzer Zeit sollte er wieder erreichbar sein (ping aus dem gleichen Netz auf, hier, 192.168.5.235, sollte beantwortet werden), dann wieder einloggen (root, root). Der ssh-Client wird wegen falscher Keys meckern, dann entsprechend den alten löschen. (Alternativen wie eine .ssh/options überlasse ich dem geneigten Leser ;)).
    Auf dem nun per NFS-Root laufenden DockStar mal die Flashaufteilung ansehen: 

    debian:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "uImage"
mtd2: 0fb00000 00020000 "root"

    Sieht gut aus. Nun wird’s haarig ;) 

    route add default gw 192.168.5.2
wget http://http.us.debian.org/debian/pool/main/m/mtd-utils/mtd-utils_20090606-1_armel.deb
dpkg -i mtd-utils_20090606-1_armel.deb
flash_eraseall /dev/mtd2
ubiformat /dev/mtd2 -s 512 -f /ubi.img -y
flash_erase /dev/mtdblock1
flash_eraseall /dev/mtd1
cat /boot/uImage > /dev/mtdblock1
wget http://plugapps.com/os/pogoplug/uboot/blparam
chmod 755 ./blparam
./blparam
./blparam bootargs_ubi='ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs'
./blparam newbootcmd='nand read.e 0x800000 0x100000 0x300000 ; setenv bootargs $(console) $(mtdparts) $(bootargs_ubi) ; bootm 0x800000'
./blparam bootcmd='run newbootcmd'
  7. Nach dieser Prozedur sollte der nächste Reboot in ein Debian auf dem DockStar führen, welches als UBIFS im Flash läuft …
  8. Login war bei mir aufgrund des gewählten Filesystemarchivs root, root; man sollte dementsprechend auf dem neuen System – ggf. ist nochmal wieder ein Meckern von ssh wegen der ssh-Keys zu umschiffen – noch folgendes tun:
    • Passwort von root ändern (»passwd«-Befehl)
    • Keys für ssh neu machen, z. B. so: 
      rm /etc/ssh/ssh_host*
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""
    • /etc/hostname, /etc/hosts anpassen

No animal was harmed during these procedures … No liability assumed, your mileage may vary, standard disclaimers apply …

12 Replies to “DockStar debianisieren per NFS-Root, ohne Consolenzugriff”

  1. Hui, das musste ich doch gerade mal ausprobieren. Hat sogar funktioniert, ohne dass ich das Tierchen aufmachen musste…
    Die mtd-utils im nfs-root wünschen sich wohl noch liblzo2-2, sonst funktionierte aber alles klaglos.
    Ich hab dann mit localepurge noch ein paar unnötige Lokalisierungen gelöscht und die Pakete linux-image-2.6-kirkwood linux-image-2.6.32-5-kirkwood und linux-image-kirkwood gelöscht, weil ja der sheeva-for-linux Kernel benutzt wird, jetzt hab ich 104MB im Root-Filesystem frei, das reicht für ein paar Kleinigkeiten. Genauso groß war meine Festplatte damals am A500, und die hat für alles gereicht, sogar für’s Usenet… ;)
    Georg

  2. Ack, nach … 

    apt-get remove linux-image-2.6-kirkwood linux-image-2.6.32-5-kirkwood linux-image-kirkwood

    … sind schon mal wieder 35 MB frei. Zu liblzo2-2: 

    dockstar-4:~# apt-get install liblzo2-2
Reading package lists... Done
Building dependency tree
Reading state information... Done
liblzo2-2 is already the newest version.
liblzo2-2 set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.

    Das dürfte daran liegen. daß ich anfangs »apt-get install mtd-utils« gemacht hatte (und da liblzo2-2 nachgezogen wurde?), bevor ich dann feststellte, daß bei Debian Lenny, anders als auf dem Desktop mit Ubuntu Lucid, benötigte Tools (noch) fehlen und ich das Package aus Testing nachzog. Bitte daher dieses berücksichtigen.
    »localpurge« brachte dann noch mal 15MB, schanke dön für den Tipp; mit 52MB hat auch mein sheevaisierter DockStar nun mehr freien Flash als meine erste Festplatte vor ca. 25 Jahren ;)

  3. Kann das sein, dass das in der Konstellation nur funktioniert, wenn die Netmask 255.255.255.0 ist?
    Ich habe ‘ne Netmask von 255.255.252.0, das tftp des uImage klappt gemäß syslog, per NFS scheint aber danach nix mehr zu passieren, vermutlich weil der NFS-Server dummerweise in ‘nem anderen Class-C-Netz ist … Dockstar: 192.168.4.15, TFTP/NFS-Server: 192.168.6.6 …
    Nachdem ich mir die Parameter für den U-Boot dann mal genauer angeguckt habe, kommt mir das hier etwas spanisch vor:
    blparam bootargs_end=:::DB88FXX81:eth0:none
    und dann
    blparam tftpboot= … ip=$(ipaddr):$(serverip)$(bootargs_end) …
    Da fehlt irgendwie irgendwo die $(netmask), oder?
    Dann muss ich mir jetzt wohl mal ein passendes Kabel besorgen, um die Dock zu debricken. :-| Zum Glück hab ich mir ja gleich 3 gekauft … ;-)

  4. Yepp, das ist nur für ein /24 so gangbar; ich habe die Sachen ja auch »nur zusammengeklaubt«, für komplexere Netzwerke sind die anderen Felder auch auszufüllen: 

    ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>

    Da Dein Netz größer als /24 ist (und im ehemaligen Class-C-Berich liegt), wird wohl der Default von 255.255.255.0 genommen; ohne Gateway und ohne Netmask ist das dann wohl ein Fall für die Serielle, ja.

  5. Kabel ist schon bestellt. ;-) Dann noch ‘ne kleine Verständnisfrage … woher weiss das Image im UBIFS, dass das “sheeva-2.6.34-uImage” gebootet werden soll und nicht das “uImage”, was beim Lenny-Base-Archiv dabei war und auch noch in /boot liegt?

  6. In Schritt 6 bläst Du ein uImage (und das UBIFS-rootfs) ins Flash, diesen Kernel bootet der DockStar dann per uBoot, dieser Kernel lädt das das UBIFS-rootfs.

  7. Jau, jetzt seh ich das auch (so weit war ich ja bisher noch nicht *grin*) … vielleicht sollte man in Schritt 2 noch explizit hinzufügen, dass man sinnigerweise dann das ins $NFSROOT/boot kopierte uImage auch genauso nennt und nicht wie in Schritt 1 “sheeva-2.6.34-uImage” … denn wenn man das nicht tut, flasht man sich in Schritt 6 dann das alte uImage aus dem Debian-Lenny-Paket … oder man schreibt in Schritt 6 dann einfach
    cat /boot/sheeva-2.6.34-uImage > /dev/mtdblock1
    dann sind auch alle potentiellen Missverständnisse beseitigt.
    Wenn ich mir das Ding nicht vorher dank /22er Subnet schon ge-brick-t hätte, wär ich wahrscheinlich auch in die Falle mit dem “falschen” uImage gelaufen. ;-)

  8. Argh!

    IP-Config: Complete:
device=eth0, addr=192.168.2.6, mask=255.255.255.0, gw=192.168.2.1,
host=DockStar, domain=, nis-domain=(none),
bootserver=192.168.2.2, rootserver=192.168.2.2, rootpath=
Waiting 5sec before mounting root device...
eth0: link up, 1000 Mb/s, full duplex, flow control disabled
Looking up port of RPC 100003/2 on 192.168.2.1
Looking up port of RPC 100005/1 on 192.168.2.1
VFS: Mounted root (nfs filesystem) on device 0:12.
Freeing init memory: 140K

    Und ab da hängt der NFS-Boot mit dem sheeva.with-linux kernel dann (sowohl 2.6.34 als auch 2.6.34-1). Any ideas?

  9. Hmm. Hänger hatte ich mal, als ich im uBoot zwar “mainlineLinux” gesetzt hatte, aber nicht gespeichert (“saveenv”; “blparam” aus Linux macht das ja implizit ;)). Da Du ja Consolenzugriff hast, ggf. das mal checken?

  10. Hmm. Hänger hatte ich mal, als ich im uBoot zwar “mainlineLinux” gesetzt hatte, aber nicht gespeichert (“saveenv”; “blparam” aus Linux macht das ja implizit ;)). Da Du ja Consolenzugriff hast, ggf. das mal checken?

  11. Nope, mainlineLinux=yes. Ich habe gestern noch kurz tcpdump laufen lassen und gesehen, dass da munter irgendwelcher NFS-Traffic läuft, der mir nicht ganz normal aussieht. Vermute daher eher ein Problem mit meinem NFS-Server. War dann aber zu müde, um genauer nachzuforschen ;)
    Grüße nach Berlin

  12. Hallo,
    vielleicht ne dumme Frage, aber krieg hier das Debian an sich erst gar nicht zum rennen. (also bevor jetzt überhaupt per tftp, sollte ja eigentlich erstmal das System an sich laufen)
    Also zunächst mal mit plugbox draufgehauen gemäß http://www.plugapps.com/index.php5?title=PlugApps:Pogoplug_Setboot – funktionierte einwandfrei und
    Plugbox Linux bootet problemlos von USB Festplatte. Also booten von Festplatte prinzipiell kein Prob, das sheeva.with-linux…Kernel auch kein Prob, die blparam sollte ok sein..usw.
    Aber soll Debian drauf nur kriege ich Debian nicht zum rennen, Platte blinkt für einge Zeit , die LED geht aus, aber danach nix: System ist nicht erreichbar, pingbar etc. also irgendwo hängt es sich auf – hab leider kein serielles Kabel um zu sehen, was los ist.
    Hat vielleicht jemand trotzdem eine Idee?
    verwendet wie oben
    http://people.debian.org/~tbm/sheevaplug/lenny/base.tar.bz2 und dazu
    http://sheeva.with-linux.com/sheeva/2.6.33/sheeva-2.6.33-Modules.tar.gz
    http://sheeva.with-linux.com/sheeva/2.6.33/sheeva-2.6.33-uImage
    Danke Leutz!

Comments are closed.