Globalscale, Abzocker vor dem Herrn?
Saturday, July 10, 2010, 23:24 - Geeks & Co., Technologien, PlugComputing, Abzocke
Einer meiner SheevaPlugs ist ja schon notoperiert seit knapp einem Monat, und ich glaube ja eigentlich nicht mehr, daß die Netzteile das Problem sind, sondern eher die generelle Hitzeentwicklung in den kleinen Heizkästchen. Aber statt eines kostenlosen neue Netzteils stellt sich NewIT jetzt auch mein Händler, NewIT aus UK, komisch an: We can of course supply these under your warranty, but first we need to have your failed PSU returned to us (this is a stipulation from Globalscale, we have had to buy the PSU’s and will get refunded for the failed PSU’s we return to them), before we can send out the replacement.
The charge for sending out the replacement PSU will be based on your location:
UK Customers - £2.50
EU Customers - £5.00
If you feel you are not confident to do this replacement you can of course send the unit to us for us to carry out the replacement, there will however be a charge for returning the unit to you, this will again be based on your location:
UK Customers - £ 7.00
EU Customers - £10.00
Also soll ich nun auf meine Kosten das defekte Netzteil nach UK schicken und für das Ersatznetzteil 2,5 UKP ablatzen? Da kommt ja ein DockStar nur wg. des Netzteils bald günstiger. Und, mal ehrlich, das sind keine Ausnahmen, das sind massenhafte Ausfälle von Netzteilen in SheevaPlugs, mithin liegt der Verdacht eines Serienfehlers nahe — aus meiner Sicht sollte die EU-Kommission ein Einfuhr- und Verkaufsverbot für GlobalScale-Produkte verhängen, nachdem diese unreife Hardware nun noch zu Folgekosten bei den Kunden führen soll.
Kommentar hinzufügen 
Tchibo InternetFlatrate L, Huawei E1550, Linux …
Wednesday, July 7, 2010, 00:51 - Berlin, GSM/GRPS/UMTS/..., PlugComputing, Linux, Mobile Blogging
(Blogged via flickr)
Nachdem mein o2 Genion Internet Pack M (200 MB) offensichtlich Montag daß Trafficlimit erreicht hat, habe ich Montag noch schnell mir eine neue Tchibo-SIM geholt, geplant war, da gleich 20,-- draufzuzahlen und die InternetFlatrate L zuzubuchen. 5 GB sollten hoffentlich reichen, bis ich hier in Berlin endlich DSL habe…
Die freundliche Verkäuferin allerdings meinte, die 'große' Flat gäbe es nicht mehr; ich habe dann für 19,95 mal wieder ein Bundle, Stick und SIM, gekauft, damit sollte zumindest bis 500 MB Ruhe sein. Aber, surprise: beim Aktivieren der SIM am Dienstag (Montag abend kam ich ja nicht mehr dazu, auch wenn auf dem Stick stand, daß der Freimonat nur bei Aktivierung bis 05.07.10 gelte) – übrigens über mein Milestone und D2 ;) –, gab es am Ende des Vorganges doch noch die Möglichkeit, die XL-Flat zu buchen. Jetzt muß ich nur nochmal 10,-- binnen 48h auf das SIM-Konto bekommen — und solange reicht hoffentlich die doch noch gewährte Flatrate L ;) Wobei letzteres nicht soo überraschend ist, denn bei den SIMs zu den Sticks scheint das generell vorgemerkt zu sein — steht nämlich auch in der Freischaltungsanleitung, daß es das Paket einen Monat gratis gäbe ;)
Der Stick ist übrigens ein Huawei E1550; sieht etwas anders aus als meine E160, kann genau wie jene oder auch der E220 eine MicroSD-Karte aufnehmen — und rennt auch unter Linux. Allerdings war bei mir apt-get install usb-modeswitch-data usb-modeswitch abzusetzen; nach dem cp und dem usb_modeswitch jedenfalls hat der NotworkManager sich bei Tchibo einwählen können (aber leider ist auch Lubricated Latex broken, eine geöffnete UID-0-Shell und der pppd terminiert weiter mit wirren Fehlermeldungen; schön, daß Ubuntu jetzt auch kaputtgespielte Subsysteme unter den LTS-Mantel packt und die Fehler kultiviert *fluch*).
Leider fehlt Debian Lenny das usb-switch-Paket, sodaß ich den E1550 – der übrigens Tchibo-SIM-locked sein soll – nicht an meinem UMTS-Router und OpenVPN-Terminator, dem DockStar, benutzen konnte. Muß ich mal auf einem meiner Sheevas zuhause durchkompilieren den Kram …
DockStar debianisieren per NFS-Root, ohne Consolenzugriff
Tuesday, June 29, 2010, 18:37 - Geeks & Co., Painseeker, Technologien, PlugComputing, Linux
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:
- Umgebung vorbereiten: uImage von sheeva.with-linux.com holen, auf dem TFTP-Server ablegen (hier als »sheeva-2.6.34-uImage«, ggf. anpassen).
- 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.). - 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
Die Datei ubi.img dann ins / des NFS-Roots kopieren.
[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 - DockStar normal booten, IP per DHCP geben lassen. Einloggen per SSH (root, stxadmin). Dann:
cd
Hier die Daten natürlich dem eigenen Umfeld entsprechend anpassen. Achtung, in dieser Konfiguration hat der NFS-Root-gebootete DockStar *kein* Default-Gateway!
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' - Dann beherzt einen Reboot des DockStars durchführen.
- 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
Sieht gut aus. Nun wird's haarig ;)
dev: size erasesize name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "uImage"
mtd2: 0fb00000 00020000 "root"route add default gw 192.168.5.2
wget http://http.us.debian.org/debian/pool/m ... _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' - Nach dieser Prozedur sollte der nächste Reboot in ein Debian auf dem DockStar führen, welches als UBIFS im Flash läuft …
- 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
DockStar als Linux-Box, nächste Version
Monday, June 21, 2010, 13:59 - Geeks & Co., Painseeker, Technologien, PlugComputing, Linux
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 /
Der letzte Befehl kopiert das Binary gleich in die neue Umgebung.
-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/ - 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.
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.
Zugriff auf den DockStar per RS-232-TTL-Pegelwandler.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!]
DockStar: boot per tftp?
Sunday, June 20, 2010, 01:18 - Geeks & Co., Painseeker, Technologien, PlugComputing, Linux
Hmm. Was habe ich hier jetzt nicht verstanden? U-Boot 1.1.4 (Jul 16 2009 - 21:02:16) Cloud Engines (3.4.16)WTF? Wieso schlägt das fehl?
U-Boot code: 00600000 -> 0067FFF0 BSS: -> 00690D60
Soc: 88F6281 A0 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz
DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000 size 128MB
DRAM Total size 128MB 16bit width
Flash: 0 kB
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:256 MB
CPU : Marvell Feroceon (Rev 1)
CLOUD ENGINES BOARD: REDSTONE:1.0
Streaming disabled
Write allocate disabled
USB 0: host mode
PEX 0: interface detected no Link.
Net: egiga0 [PRIME], egiga1
Hit any key to stop autoboot: 0
[…]
CE>> tftp 0x800000 uImage ; setenv bootargs ${bootargs_usb_root}; bootm 0x800000
Using egiga0 device
TFTP from server 192.168.5.2; our IP address is 192.168.5.5
Filename 'uImage'.
Load address: 0x800000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
########################
done
Bytes transferred = 2448208 (255b50 hex)
## Booting image at 00800000 …
Image Name: Linux-2.6.32.2
Created: 2010-06-17 0:35:49 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2448144 Bytes = 2.3 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum … OK
OK
Starting kernel …
Uncompressing Linux………………………………………………………………………………………………………………………………………….. done, booting the kernel.
Error: unrecognized/unsupported machine ID (r1 = 0x0000020f).
Available machine support:
ID (hex) NAME
00000690 Marvell DB-88F6281-BP Development Board
00000691 Marvell RD-88F6192-NAS Development Board
00000692 Marvell RD-88F6281 Reference Board
0000078c Marvell 88F6281 GTW GE Board
00000831 Seagate DockStar Board
0000085b QNAP TS-119/TS-219
00000915 Marvell OpenRD Base Board
Please check your kernel config and/or bootloader.
- Das Image wird per TFTP übertragen
- Es wird als unkomprimierter Linux Kernel erkannt, die Checksumme stimmt
- Beim Boot des Kernels – der so sonst vom ext3 des USB-Sticks der 1. Partition an Port 1 geladen wird – wird eine falsche Maschine erkannt‽
Weiter