Alles Rund um den MEDION LIFE P89626 NAS

GPIO-Treiber für OX820 funktioniert ebenfalls. Hier die 
GPIO-Zuordnungen:

SYSLED:Blue 37
SYSLED:Red 38
CopyLED:Green 40
Button:Copy 45
Button:Reset 43

Ein Kernel-Modul für die GPIO-Anbindung:

gpio-ox820

Ein Kernel-Modul für die LED-Class-Anbindung auf dem Medion NAS:

leds-gpio-ox820-stg212


Pfade im System:
/sys/class/leds/sysled.red
/sys/class/leds/sysled.blue
/sys/class/leds/copyled

Die SYSLED ist diejenige, die meist blau leuchtet.

Sie kann: aus, rot, blau, violett

Die COPYLED ist beim MedionNAS rot. Sie sollte wohl mal grün werden.

Mal ein paar ArchLinux-Zahlen mit Kernel 3.1:

16.3MB/s per SMB draufkopieren (Quellmaschine ist Linux-basiert)

Parallel spielt ein HD-Stream ab.

hier die /proc/loadavg:

1.50 1.37 0.71 2/65 1097

solo schrieb:
> Es scheint eine Möglichkeit zum Recovery und eine zum Booten
> von images auf USB zu geben. Ausgelöst wird das durch defekte Images auf
> der Platte oder durch den Reset-Taster auf der Rückseite des Geräts.

Also hat Iomega etwas ähnliches mit USB geschaffen.

solo schrieb:
> Vielleicht ist das ja eine Option für
> Medion-NAS-Besitzer, die den Komfort einer Weboberfläche und
> umfangreicher Vorkonfiguration brauchen.

Wenn man das U-Boot-Environment anpasst, würde die schon prinzipiell 
laufen. Allerdings vermute ich das die Taster und LEDs an anderen 
Leitungen angeklemmt worden sind. Es sei denn, es wurde ein 
Referenzdesign überall verwendet.

Sven B. schrieb:
> 16.3MB/s per SMB draufkopieren

Wow, ich hätte gar nicht gedacht, dass das so einen Unterschied macht oO

Ist denn Dualcore-Unterstützung bereits eingebaut? Wie sieht es mit der 
Wärmeentwicklung aus?

Johann B. schrieb:
> Sven B. schrieb:
>> 16.3MB/s per SMB draufkopieren
>
> Wow, ich hätte gar nicht gedacht, dass das so einen Unterschied macht oO
>
> Ist denn Dualcore-Unterstützung bereits eingebaut? Wie sieht es mit der
> Wärmeentwicklung aus?

Der Kernel läuft in Dual-Core und hält mit 12V Lüfter an 5V 40°C an der 
Festplatte beim Draufkopieren.

matz3e schrieb:
> VORSICHT geboten !!!

Ja. Die Pakete sind ja sicher nicht umsonst für ein anderes Gerät mit 
einer etwas anderen FW gebaut...

Zunächst einmal meinen ganz großen Respekt vor der Arbeit einiger Leute 
hier. Das was ihr hier veranstaltet, ist ganz großes Kino. Als Ausbilder 
von Fachinformatikern/Anwendungsentwicklung, weiß ich wovon ich rede.

Ich werde auf jeden Fall weiter verfolgen und evtl. eure Arbeit nutzen. 
Wichtig ist mir jedoch weiterhin Twonky, da mein NAS vorwiegend zwei PS3 
und mein Fernseher füttert welche DNLA erwarten. Natürlich sind auch 
einiger Ordner für Backups vom heimischen Rechner reserviert.

Hereingestolpert bin ich hier, während der Suche nach einer Lösung für 
die unsägliche OTC-Taste. Dass man mit ihr nur einen Ordner auf eine 
angeschlossene USB-Platte kopieren kann, ist schon mehr als Sinnbefreit.

Da ich kein Freund von Backup Software bin suche ich eine Lösung, wie 
ich auf dem NAS alle Ordner 1 zu 1 ohne Verschlüsselung oder 
Komprimierung auf eine angeschlossene WD Passport kopieren kann. Von 
daher möchte ich die mitgelieferte Backupsoftware nicht nutzen. Der 
Explorer scheidet mangels Geschwindigkeit aus. FireFTP und Filezilla 
erlauben keine Kopieraktionen auf dem NAS  direkt.  Bin ziemlich ratlos. 
Vielleicht hat ja jemand von euch einen Tipp.

Danke fürs lesen.

Gruß
Reinhold

Reinhold K. schrieb:
> Ich werde auf jeden Fall weiter verfolgen und evtl. eure Arbeit nutzen.
> Wichtig ist mir jedoch weiterhin Twonky, da mein NAS vorwiegend zwei PS3
> und mein Fernseher füttert welche DNLA erwarten. Natürlich sind auch
> einiger Ordner für Backups vom heimischen Rechner reserviert.

Twonky ist ja letztlich nicht der einzige DLNA-fähige Server. Aufgrund 
einiger Ungereimtheiten der Twonky-Version ist mein Ansinnen minidlna am 
Laufen zu haben.

Insbesondere mkv streamt Twonky nicht. Minidlna tut dieses und mein 
MedienPlayer nimmt auch dieses Format an.

Reinhold K. schrieb:
> Da ich kein Freund von Backup Software bin suche ich eine Lösung, wie
> ich auf dem NAS alle Ordner 1 zu 1 ohne Verschlüsselung oder
> Komprimierung auf eine angeschlossene WD Passport kopieren kann. Von
> daher möchte ich die mitgelieferte Backupsoftware nicht nutzen. Der
> Explorer scheidet mangels Geschwindigkeit aus. FireFTP und Filezilla
> erlauben keine Kopieraktionen auf dem NAS  direkt.  Bin ziemlich ratlos.
> Vielleicht hat ja jemand von euch einen Tipp.

Es gibt da diesen netten WebGUI Datei-Explorer, der auch Kopieraktionen 
durchführen kann.

@matz3e:

Ein weiteres Thema ist auch ArchLinuxARM mit einem Kernel 3.1 laufen zu 
haben.

Durch die Bootreihenfolge SATA und dann erst NAND lässt sich das Medion 
NAS nicht bricken. Man benötigt lediglich eine korrekte Initialisierung 
der Festplatte.

Um die Firmware im Flash ausser Betrieb zu setzen, muss man lediglich 
eine Datei löschen, dafür braucht man kein Paket von der Zyxel-Homepage.

Sven B. schrieb:
> Twonky ist ja letztlich nicht der einzige DLNA-fähige Server. Aufgrund
> einiger Ungereimtheiten der Twonky-Version ist mein Ansinnen minidlna am
> Laufen zu haben.

Ich finde die A/V-Implementierungen von UPNP praktischer, aber welchen 
Server man letztendlich verwendet ist ja Geschmackssache ;)

Sven B. schrieb:
> Twonky ist ja letztlich nicht der einzige DLNA-fähige Server. Aufgrund
> einiger Ungereimtheiten der Twonky-Version ist mein Ansinnen minidlna am
> Laufen zu haben.

Gut zu wissen. Danke.

Sven B. schrieb:
> Es gibt da diesen netten WebGUI Datei-Explorer, der auch Kopieraktionen
> durchführen kann.

Funktioniert nur auf Datei- jedoch nicht auf Ordnerebene. Und auch dies 
nur immer mit einer Auswahl. Mehrere Ordner markieren und dann kopieren 
geht damit auch nicht.

Reinhold K. schrieb:
> Funktioniert nur auf Datei- jedoch nicht auf Ordnerebene. Und auch dies
> nur immer mit einer Auswahl. Mehrere Ordner markieren und dann kopieren
> geht damit auch nicht.

"netten" hätte auch so wie jetzt geschrieben sein sollen.

solo schrieb:
> Jetzt unter Archlinux hab ich rsnapshot genommen. Die externe Festplatte
> ist per USB angeschlossen. Bei dem iomega-kernel ist mit ufsd ein sehr
> gutes NTFS-Modul dabei. Damit gehen mehr als 20MB/s über USB und die
> Backup-Platte ist nachher direkt am Windows-Rechner lesbar. Der
> Usermode-Treiber (NTFS-3G) war mit 2-3MB/s unbrauchbar.

solo schrieb:
> Jetzt unter Archlinux hab ich rsnapshot genommen. Die externe Festplatte
> ist per USB angeschlossen. Bei dem iomega-kernel ist mit ufsd ein sehr
> gutes NTFS-Modul dabei. Damit gehen mehr als 20MB/s über USB und die
> Backup-Platte ist nachher direkt am Windows-Rechner lesbar. Der
> Usermode-Treiber (NTFS-3G) war mit 2-3MB/s unbrauchbar.

Ich schau mir mal die NTFS For Linux Embedded Express Edition an.

Update: Ist prinzipiell machbar. Man bekommt so eine Konstellation wie 
bei Nvidia. Source-Front-End mit Binary-Blob.

Nur das wir die ARM-Variante statt der x86-32/x86-64 Varianten 
benötigen.

Beim Medion NAS wurde soweit ich das am Build Env sehe, kein ufsd.ko 
beigetan. Dort wird alles über ntfs-3g abgewickelt soweit ich das sehe.

J.R. schrieb:
> Leider hab ich nur einen USB/RS232 mit SUB-D und einfach nen Stick
> reinschieben und hoffen das danach Linux läuft war mir auch ein wenig zu
> riskant, drum hab ich die Platte an mein Linux Desktop angeschlossen und
> sie so vorbereitet wie in den do.sh Dateien im Github. Danach noch die
> fstab angepasst (ka ob das nötig ist), und die Platte wieder ins Gerät
> gebaut und siehe da, es bootet Problemlos mit einem kleine ArchLinux...

Das was das Skript macht, kann man auch am PC durchführen.
Oder eben per Telnet-Trigger usb_key_func.sh auf Stick und dann per 
Telnet dann sieht man auch die Ausgaben davon.

Ich hab das fstab bei mir angepasst, um logs sowie run ins RAM zu 
verfrachten. Aber es lief auch erstmal ohne Anpassung.

J.R. schrieb:
> er 3.1. Kernel der bei dir läuft der ist selbst kompiliert, wenn ich
> das richtig Verstehe.
>
> Welche Sourcen, mit welchen Patches, welcher config und welcher
> Toolchain?

Konfig liegt mittlerweile bei.

1

make ARCH=arm CROSS_COMPILE=/opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi- ox820_medion_defconfig

Da ist fast alles mit reinkompiliert, was anschliessbar ist.

Die Parameter ARCH und CROSS_COMPILE müssen immer dran stehen. Auch bei 
menuconfig usw.


Toolchain stammt aus dem Medion GPL-Archiv.

Beim Kompilieren aber besser -j<Anzahl der Kerne> an make als Parameter 
zusätzlich übergeben.

J.R. schrieb:
> Sven B. schrieb:
>> Konfig liegt mittlerweile bei.
>> make ARCH=arm
> CROSS_COMPILE=/opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none- 
linux-gnueabi-
> ox820_medion_defconfig
>> Da ist fast alles mit reinkompiliert, was anschliessbar ist.
>
> Erstmal vielen Dank, das ist schonmal sehr Hilfreich, ich muss aber
> leider nochmal dumm nachfragen: Wo finde ich die ox820_medion_defconfig?
> Hast du die Patches aus dem ArchLinuxArm Repo verwendet, oder ist das
> einfach Mainline?

Das sind keine Patches sondern ein Repo 
http://www.github.com/ft-/OX820-3.1-Linux
Und bei dem gibt es in den ARM-Configs eine defconfig, die mittels 
zuvorgenanntem make-Kommando als .config abgelegt wird.

Bauen komplett:

1

make ARCH=arm CROSS_COMPILE=/opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi- INSTALL_PATH=$HOME/kern-3.1/boot INSTALL_MOD_PATH=$HOME/kern-3.1 ox820_medion_defconfig

2

make ARCH=arm CROSS_COMPILE=/opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi- INSTALL_PATH=$HOME/kern-3.1/boot INSTALL_MOD_PATH=$HOME/kern-3.1 clean

3

make ARCH=arm CROSS_COMPILE=/opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi- INSTALL_PATH=$HOME/kern-3.1/boot INSTALL_MOD_PATH=$HOME/kern-3.1 uImage

4

cp arch/arm/boot/uImage $HOME/kern-3.1/boot/uImage-3.1.0+

5

make ARCH=arm CROSS_COMPILE=/opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi- INSTALL_PATH=$HOME/kern-3.1/boot INSTALL_MOD_PATH=$HOME/kern-3.1 install

6

make ARCH=arm CROSS_COMPILE=/opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi- INSTALL_PATH=$HOME/kern-3.1/boot INSTALL_MOD_PATH=$HOME/kern-3.1 modules

7

make ARCH=arm CROSS_COMPILE=/opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi- INSTALL_PATH=$HOME/kern-3.1/boot INSTALL_MOD_PATH=$HOME/kern-3.1 modules_install

8

cd $HOME/kern-3.1

9

rm boot/vmlinuz*

10

tar cfvz kern-3.1.0+-modules.tar.gz lib boot

Das File uImage-3.1.0+ kommt auf die erste Partition per

1

dd if=uImage-3.1.0+ of=/dev/<Disk>1 bs=512

<Disk> gegen das tatsächliche Laufwerk austauschen.

Das Archiv im Root entpacken:

1

cd /

2

tar xfvz <Pfad>/kern-3.1.0+-modules.tar.gz

Bezüglich ArchLinuxARM:

Die Leute dort wissen dass ich da auch was mache und schauen auch beim 
Repo vorbei.

Die Portierung vom SATA hatte ich soweit vervollständigt.
LED-Trigger-Support hatte ich ergänzt. Die LED bleibt 50ms nach dem 
letzten Festplatten-Zugriff an. Die anzusteuernde LED kannst aussuchen. 
Buzzer würde ich nicht empfehlen.

Neu ist das OX820-GPIO-Modul sowie ein für das Medion NAS passendes 
gpio-leds-ox820-stg212.ko.

Bei diesen sind die folgenden Ausgänge steuerbar.

SYSLED. Rot und Blau
COPYLED
Buzzer (1kHz)

Für die Buttons bin ich noch was am machen.

USB scheint zur Zeit an den Anschlüssen am Gerät keine neu 
angeschlossenen Geräte zu detektieren. Da muss man auch erst noch mal 
hinterkommen was im 3.1er anders ist.

Wohingegen bereits angeschlossene Geräte beim Initialisieren des 
USB-Controllers erkannt werden.

solo schrieb:
> Ist es eigentlich irgendwo genormt, wie LED's im System abgebildet
> werden sollten?

Eigentlich ist das die LED class. Diese werden unter /sys/class/leds/ 
abgebildet. Und diese funktionieren über den LED support vom Kernel. 
Daher funktionieren diese auch mit dem LED Trigger Support im 
SATA-Treiber.

hier mal die Hersteller-spezifischen Dinger, die ich zur Hand habe.

Iomega: /sys/class/nasled/*
Medion: /dev/nas_gpio

Es wäre auch machbar für die HMNDCE solch ein Modul wie für das 
Medion-Gerät zu bauen.

@Sven:

Wenn ich gpio-leds-ox820-stg212 in den Kernel einkompiliere, fängt der 
Buzzer schon während des Bootvorgangs an Krawall zu machen... Da ich 
hauptsächlich spät abends nachdem Kind und meistens auch Frau schon 
schlafen am Basteln am Gentoo für die Medion Nas komme, habe ich da 
sofort die Box ausgeschaltet und erst nachdem ich gpio-leds-ox820-stg212 
als Modul wieder gebaut habe, hochgefahren. Allerdings traute ich mich 
nicht das Modul zu laden, ist das so, soll der Buzzer einfach 
loslegen? Wenn ich heute Abend wieder dazu kommen werde wird es leider 
wieder spät sein...

Ach, noch etwas, Du hast auf mein pull request auf github bezüglich des 
NAND-Treibers gar nicht reagiert, der Patch ist nicht von mir einfach 
neu erfunden, sondern ich habe ich mit minimalen Änderungen aus der 
alten Kernelversion aus der Original-FW den Treiber übernommen...

Lucian M. schrieb:
> @Sven:
>
> Wenn ich gpio-leds-ox820-stg212 in den Kernel einkompiliere, fängt der
> Buzzer schon während des Bootvorgangs an Krawall zu machen... Da ich
> hauptsächlich spät abends nachdem Kind und meistens auch Frau schon
> schlafen am Basteln am Gentoo für die Medion Nas komme, habe ich da
> sofort die Box ausgeschaltet und erst nachdem ich gpio-leds-ox820-stg212
> als Modul wieder gebaut habe, hochgefahren. Allerdings traute ich mich
> nicht das Modul zu laden, ist das so, soll der Buzzer einfach
> loslegen? Wenn ich heute Abend wieder dazu kommen werde wird es leider
> wieder spät sein...

Eigentlich soll er das nicht. Passiert soweit bei mir auch normal nicht. 
Hatte ich bisher nur einmal gehabt, dass alles anging. Da hatte ich aber 
auch auf dem NAS ein fehlerhaftes Modul.
Bevor gpio-leds-ox820-stg212 geladen wird, muss gpio-ox820 geladen sein. 
Und gpio-ox820 darf erst nach gpio-leds-ox820-stg212 entladen werden.


Lucian M. schrieb:
>
> Ach, noch etwas, Du hast auf mein pull request auf github bezüglich des
> NAND-Treibers gar nicht reagiert, der Patch ist nicht von mir einfach
> neu erfunden, sondern ich habe ich mit minimalen Änderungen aus der
> alten Kernelversion aus der Original-FW den Treiber übernommen...

Hab erst heute wieder auf github.com direkt nachgeschaut und hatte ihn 
gesehen. Habs gerade reingeholt.

Sven B. schrieb:
> Bevor gpio-leds-ox820-stg212 geladen wird, muss gpio-ox820 geladen sein.
> Und gpio-ox820 darf erst nach gpio-leds-ox820-stg212 entladen werden.

Ok, werde das dann probieren. Ist es nicht so, dass solche Reihenfolgen 
und zugleich Abhängigkeiten automatisiert werden können, zumindest für 
modprobe, und bei rmmod auf die falsche Reihenfolge eine Fehlermeldung 
kommt? Vielleicht hilft auch, daß gpio-ox820 im Kernel und 
gpio-leds-ox820-stg212 als Modul gebaut wird.

Lucian M. schrieb:
> Allerdings traute ich mich
> nicht das Modul zu laden, ist das so, soll der Buzzer einfach
> loslegen? Wenn ich heute Abend wieder dazu kommen werde wird es leider
> wieder spät sein..

Hab aus dem Buzzer eine Kernel-Option gemacht. Jetzt kann der Kernel 
ohne Buzzer kompiliert werden.

solo schrieb:
> Auf dem iomega gibt es folgende Steuerungsmöglichkeiten für die LED:
> /sys/class/nasled/backup_blue_led
> /sys/class/nasled/hdd1_blue_led
> /sys/class/nasled/led_blinkrate
> /sys/class/nasled/led_brightness
> /sys/class/nasled/power_off
> /sys/class/nasled/pwr_white_led
> /sys/class/nasled/system_red_led
> /sys/class/nasled/system_white_led

Danke für die Info. Hab dadurch noch ein paar der GPIO-Register (PWM) 
gefunden.

noxx schrieb:
> kann mir einer sagen, wie im kompletten FTP Zugang (root) bekomme?

normalerweise sieht man nie das Root-Verzeichnis des Systems beim FTP.

Das sieht man normalerweise nur wenn man einen Shell-Zugang (telnet/ssh) 
benutzt.

solo schrieb:
> Sven B. schrieb:
>> Es wäre auch machbar für die HMNDCE solch ein Modul wie für das
>> Medion-Gerät zu bauen.
> Das wäre prima.

Habs gerade zusammengestellt, allerdings hab ich die Polaritäten nicht 
daraus verlässlich ermitteln können. Hab erst mal High-Active 
angenommen.

Wenns nicht stimmt, dann muss man da was ändern.

solo schrieb:
> Checking for pre-image script... found.
> Gruesse an die Medion-NAS-Truppe!!!

liesst sich irgendwie bekannt ;)

noxx schrieb:
> also kann ich die exports datei nur per telnet editieren (zwecks nfs
> freigabeordner einstellen)?

ja

@Sven, ist vielleicht für Dich hilfreich:

Lucian M. schrieb:
> Sven B. schrieb:
>> Bevor gpio-leds-ox820-stg212 geladen wird, muss gpio-ox820 geladen sein.
>> Und gpio-ox820 darf erst nach gpio-leds-ox820-stg212 entladen werden.
>
> Ok, werde das dann probieren.

Ich habe mittlerweile durch die Kernelkonfig-Option den Buzzer erstmals 
'raus, aber ich hatte noch vergessen zu erwähnen, auch die LEDs 
leuchteten alle auf einmal als sich das Modul komisch verhielt (mit 
Buzzer, sowohls im Kernel kompiliert, als auch als Modul, habe ich 
ausprobiert).
Danach habe ich udev-164 auf udev-171 geupgraded, und auch gpio-ox820 
was ich vorhin immer im Kernel kompiliert hatte, nun als Modul 
konfiguriert, sowie die Buzzer-Option 'raus. Jetzt leuchten die LEDs 
nicht mehr wild alle auf einmal.
Kann das Fehlverhalten auf udev-164 mit Kernel 3.1 zurückgeführt werden? 
Oder auf die Tatsache, dass ich gpio-ox820 vorher immer im Kernel fest 
einkompiliert hatte?
Ich werde dann mal morgen abend wieder die Buzzer-Option aktivieren und 
testen ob das Verhalten auch damit nun normal ist.

Lucian M. schrieb:
> Oder auf die Tatsache, dass ich gpio-ox820 vorher immer im Kernel fest
> einkompiliert hatte?

Ich vermute, dass irgendein Teil auf die GPIOs zugreift. Ich habe es 
nochmal überprüft und es passiert bei mir auch. Aber eben nur nach dem 
Einschalten der Spannungsversorgung. Nach Reboot nicht.

Deswegen habe ich beim LED-Modul die Möglichkeit eingebaut, die Ausgänge 
erst dann einzuschalten, wenn diese benötigt werden.

Neu ist auch variable Helligkeit auf den LEDs, dass hab ich mir vom 
HMNDCE abgeschaut.

Buzzer ist weiterhin nur an/aus.

gpio-ox820 verändert nichts an der Ausgangskonfiguration, dass macht 
erst leds-gpio-ox820-stg212.

Allerdings zeigt sich danach noch die Ethernet-Initialisierung. 
Eventuell wird dort von irgendwoher der GPIO geschaltet.

Jürgen J schrieb:
> hat schon jemand Probleme damit gehabt, dass die POP3-Postfachdateien
> z.B. "outlook.pst" durch die Speicherung auf dem Aldi NAS beschädigt
> werden?

Falls du das Problem reproduzieren kannst, versuche mal deinen 
Virenscanner zu deaktivieren, da einige Nutzer über Probleme bei 
bestimmten Kombinationen erwähnten (Am Besten liest du dir die 
entsprechenden Teile dieses Threads mal durch, falls du sie findest... 
Dies ist ein ziemlich langer Thread geworden...).

Andreas Ehrle schrieb:
> kann man eigentlich den twonkymediaserver dauerhaft in der webgui
> deaktivieren. ich finde da nix.
> oder hat schon jemand eine andere möglichkeit parat den twonky dienst
> abzuschalten?
>
> geiches gilt eigentlich auch für den webserver. das braucht mir alles zu
> viel ram.

Gibt es denn wirklich keine Möglichkeit, diesen dämlichen Twonky zu 
stoppen?
Wie hier schon erwähnt, hilft auch der kill -9 Prozessnummer nicht, da 
dieser Rotz immer wieder erneut gestartet wird. Unter /etc/init.d liegt 
die rcS, die dieses Resourcengeschmeiss startet. Leider führt jeder 
Eintrag (auskommentieren etc.) nach einem reboot wieder zu dem alten 
Zustand. Welcher Prozess übernimmt nach dem restart das Überbügeln?

Unglücklich gelöst, dass man solchen Mist nicht nur permanent laufen 
läßt, sondern auch noch überwacht.

Den httpd wird man natürlich nicht entbehren können, da damit das 
Webinterface abgefackelt wird. Und für diesen Quatsch muß er auch gleich 
3 mal laufen. Mit "top" sieht man recht gut, was Tinte auf den Füller 
bringt.

Ich vermute, dass die Zyxel Serie mehr auf der Pfanne hat. Dort wird 
bereits Squeezecenter zum download angeboten, basierend auf Perl 5.8.8 
und MySQL. Perl habe ich mit Mühe auf die ALDI-Pumpe gebracht. 
Trickreich, da @INC auf blödsinnige Pfade zeigt. Die slimserver.pl tut 
es aber nicht, bzw. pust nach 10 sec mit Out of Memory ab. Schade um die 
Zeit, und als Datenpumpe geht das Ding ja;-)

Peter W. schrieb:
> Unter /etc/init.d liegt
> die rcS, die dieses Resourcengeschmeiss startet. Leider führt jeder
> Eintrag (auskommentieren etc.) nach einem reboot wieder zu dem alten
> Zustand. Welcher Prozess übernimmt nach dem restart das Überbügeln?


Ja, das kommt ja aus dem Flash^^ Ich vermute mal "init" übernimmt das 
Neustarten.
> Und für diesen Quatsch muß er auch gleich
> 3 mal laufen. Mit "top" sieht man recht gut, was Tinte auf den Füller
> bringt.
Naja, 3 Threads sind ja für einen httpd noch sparsam ;)
> Perl habe ich mit Mühe auf die ALDI-Pumpe gebracht.
Wenn du ArchLinux per chroot einbindest, funktioniert es wahrscheinlich 
problemlos^^

Peter W. schrieb:
> Gibt es denn wirklich keine Möglichkeit, diesen dämlichen Twonky zu
> stoppen?
> Wie hier schon erwähnt, hilft auch der kill -9 Prozessnummer nicht, da
> dieser Rotz immer wieder erneut gestartet wird. Unter /etc/init.d liegt
> die rcS, die dieses Resourcengeschmeiss startet. Leider führt jeder
> Eintrag (auskommentieren etc.) nach einem reboot wieder zu dem alten
> Zustand. Welcher Prozess übernimmt nach dem restart das Überbügeln?
>
> Unglücklich gelöst, dass man solchen Mist nicht nur permanent laufen
> läßt, sondern auch noch überwacht.

/etc/init.d ist in einer RAM-Disk. Das wird bei Systemstart 
grundsätzlich neu aufgebaut, da flüchtig.

Merz schrieb:
> Hi
> jetzt wollte ich mal den arch testen aber glaubt ihr ich finde wie ich
> mein 4GB stick in vfat formatieren kann.
>
> ich habe ihn unter einer ubuntu vm zwar als vfat formatiert aber in win
> wird er als fat32 angezeigt und gemountet.
>
> sollte eigentlich ja nix passieren oder falls er falsch formatiert ist?

FAT32 ist bei Linux VFAT

Merz schrieb:
> Ach so mit dem Befehl habe ich formatiert: mkfs -t vfat /dev/sda1

Das ist schon so richtig.

*Info für alle ArchLinux-Anwender und Kernel 3.1*

Die Medion-GCC-Toolchain verursacht subtile Fehler, die sich im 
User-Space insbesondere bei su auswirken.

Besser ist es da eher die ArchLinuxARM armv5te Konfiguration für 
crosstool-ng zu verwenden.

Eine interessante eigenart ist mir bei der WarheadsSE uboot version von 
Festplatte aufgefallen: Booten per ext2 von einer kleinen partition am 
anfang der Festplatte funktioniert nicht. Booten von Fat jedoch schon.

Mein Festplattenlayout ist daher:

1

    Gerät  boot.     Anfang        Ende     Blöcke   Id  System

2

/dev/sda1            2048       43007       20480    b  W95 FAT32 // Boot 

3

/dev/sda2           43008    21014527    10485760   83  Linux  //Rootfs

4

/dev/sda3        21014528    21538815      262144   82  Linux Swap / Solaris

5

/dev/sda4        21538816  2930277167  1454369176   83  Linux  //Datafs

6

7

Uboot env: (Auszüge)

8

9

bootfile="uImage"

10

lightled=ledfail 1

11

extinguishled=ledfail 0

12

boot=bootm 60500000

13

ipaddr=192.168.178.5

14

serverip=192.168.178.4

15

netmask=255.255.255.0

16

boot_new=fatload ide 0:1 60500000 uimage.new; run boot

17

boot_old=fatload ide 0:1 60500000 uimage.old; run boot

18

boot_tftp=tftpboot 60500000; run boot

19

boot_nand=nboot 61000000 0 440000; bootm 61000000

20

bootcmd=run boot_new || run boot_old lightled || run boot_nand || run boot_tftp

21

stdin=serial

22

stdout=serial

23

stderr=serial

24

bootargs=root=/dev/sda2 console=ttyS0,115200 elevator=cfq rootwait mem=128M poweroutage=yes

Wie in der uBoot env ersichtlich lädt er wenn möglich zunächst den neuen 
Kernel, falls das nicht klappt den alten Kernel, dann den Medion kernel 
aus dem Nand und (was nicht vorkommen sollte) wenn alles schief geht 
lädt er den Kernel per tftp. Diese Konfiguration läuft auf meinem Nas 
einwandfrei...

Max H. schrieb:
> Eine interessante eigenart ist mir bei der WarheadsSE uboot version von
> Festplatte aufgefallen: Booten per ext2 von einer kleinen partition am
> anfang der Festplatte funktioniert nicht. Booten von Fat jedoch schon.

Ich habe den Kernel auf die erste Partition einfach mit dd draufgelegt, 
wie in der PogoPlugPro oxnas_sata_boot.tar.gz.

Also kein Dateisystem.

casati schrieb:
> Schaut man in /mnt/debootstrap/debootstrap.log, dann findet sich dort:
> Cannot specify both -k and -O if multiple URLs are given, or in combination
> with -p or -r. See the manual for details.
> man wget enthüllt das Geheimnis:
> --------------------------------
> This is not the complete manual for GNU Wget.  For more complete
> information, including more detailed explanations of
>        some of the options, and a number of commands available for use
> with .wgetrc files and the -e option, see the GNU Info
>        entry for wget.
> --------------------------------
>
> Deshal also NICHT "sudo ...", SONDERN "sudo su" UND DANN die
> Befehlszeile eingeben!!!

Dies hier hätte bereits gereicht.

1

su -l

sudo su ist einfach sudo zuviel.

Und für die Befehlszeile:

1

su -l root -c "<Befehlszeile>"

Das ergibt dann ein komplettes Environment gemäss root-Benutzer.

Und wenn man das aktuelle Verzeichnis nicht verlassen will, dann:

1

su root -c "<Befehlszeile>"

Sven B. schrieb:
> *Info für alle ArchLinux-Anwender und Kernel 3.1*
>
> Die Medion-GCC-Toolchain verursacht subtile Fehler, die sich im
> User-Space insbesondere bei su auswirken.
>
> Besser ist es da eher die ArchLinuxARM armv5te Konfiguration für
> crosstool-ng zu verwenden.

Ich hatte erst heute die Zeit, den Kernel 3.1 mit dem crosstool-ng 
basierten Compiler durchzuziehen und hatte dort jetzt auch das gleiche 
Spiel mit su-Binaries, die nicht mehr laufen. Muss ich mal schauen, was 
sich dazu finden lässt.

@Sven B.

Servus hab mal dein USB do.sh usb script ausprobiert.
Bei mir bleibt das script hängen in dem moment wo es versucht einen 
mount -t ext3 zu versuchen. Per ext2 geht es dann.

Das arch system was danach bootet ist soweit in Ordnung nur der erste 
pacman -Syu schlägt fehl. Hier zuvor erst einen "pacman -S filesystem 
--force" behebt diesen Fehler.

Nach dem das arch soweit läuft kommt man aber sehr schnell an die 
grenzen der 256MB RAM :-(

Nun bin ich auch soweit happy mein medion NAS ist eine schöne Time 
Machine für den MAC :-)

Und evtl. noch etwas mehr.
Übrigens für alle denen oscam etwas sagt das geht auch ich hab das 
"oscam-1.20-unstable_svn6024-armLE-synology-marvell_628X-linux" am 
laufen geht Einwand frei :-D

Nikolas R. schrieb:
> Nach dem das arch soweit läuft kommt man aber sehr schnell an die
> grenzen der 256MB RAM :-(

Deswegen hab ich auch eine 512MB swap eingebaut. (Medion NAS 128MB)

Folgendes in der /etc/fstab aktiviert diese dauerhaft.

1

/dev/sda3 swap swap auto 0 0

J.R. schrieb:
> Habe leider ein Problem mit dem 3.1 Kernel. Bekomme keine
> Netzwerkverbindung.

Bei 100Mbit klappt irgendwas nicht. 1GBit Verbindung klappt. Das Modul 
hatte ich erstmal so übernommen, wie es in dem Repo war, von wo ich 
geforkt habe.

Das ist wie USB Root Hub Connect auf einer glücklicherweise kurzen 
Liste.

solo schrieb:
> "The network chip needs a complete up-down-cycle before picking up links
> properly. The standard arch network init did never bring the connection
> up while booting. Yet it was enough to simply "rc.d restart network" on
> serial connection to make it work. I had this in my rc.local at first."
>
> Im Originalpost ist auch ein Zwei-Zeilen-Patch für das
> oxnas-mac-adressen-skript.

Das erklärt dann ja diese tollen egiga0-up und egiga0-down Skripte.

Ich habe gerade mal die Sourcen vom Medion-Kernel und PogoPlugPro 
(welcher die Portierungs-Basis war) verglichen. Es gibt etliche 
Korrekturen und Überarbeitungen.

Einer Gründe warum ich auch den SATA-Treiber aus neueren Kerneln zum 
Vergleich herangezogen hatte.

Das werde ich wohl beim Ethernet-Modul auch machen.

J.R. schrieb:
> Vielen Dank für die Mühe die du in den Kernel steckst, ich hoffe du hast
> wenigstens Spaß daran.

Hab gerade das USB Root Hub Connect Problem gelöst.

J.R. schrieb:
> Sven B. schrieb:
>> Hab gerade das USB Root Hub Connect Problem gelöst.
>
> Jupp, funktioniert gut.

Jetzt wo der USB Root Hub korrekt funktioniert, kann ich nämlich einen 
USB-Seriell-Adapter mit Autoskript benutzen und so mich um die 
Ethernet-Geschichte kümmern.

Denn das macht jetzt neuerdings Ärger bei mir.

Mir geht es da ganz ähnlich. Insbesondere nach den zuletzt vernommenen 
Geräuschen der Ursprungs-Platte des Medion-NAS. (solche die man schon 
mal gar nicht bei einer Festplatte hören will)

Die Wärmebilanz des NAS stimmt erst wenn mit einem Lüfter beide Kerne 
betrieben werden. Dann halten sich im Inneren stabile 40°C.

Ich gehe davon aus, dass wahrscheinlich alle NAS ohne Lüfter eine 
deutlich verkürzte Festplatten-Laufzeit haben werden.

Es wäre schön, wenn ein paar Leute mal ein Lebens- bzw. 
Nichtlebenszeichen für das NAS geben könnten.

Anmerkung zu meinen vorherigen Eintrag:

Es betrifft ausschliesslich das Medion NAS.

Also mein NAS läuft noch, ohne Lüfter und ähnlichen Schnickschnack ;)

Die Temperatur der Festplatten liegt im Standby bei 30°C, bei Benutzung 
des Geräts deutlich höher.

Es geht nunmal um das deutlich höher. Aber schön zu hören.

Meines läuft ja auch noch mit besagter Wärmebilanz. Nur eben der 2TB 
Platte aus dem USB-Rahmen. (Die im Übrigen noch keine Übertemperatur 
gesehen hat)

Ja, in dem Zusammenhang würde mich auch mal interessieren, was für einen 
Lüfter hast du / was für einer muss das sein, wie hast du den eingebaut?

Achja, und gibt es irgendwie eine Möglichkeit auf der Stock-FW die 
Tintenfüllstände des angeschlossenen Druckers abzufragen?

Auf nas:631 komme ich nicht drauf, obwohl das CUPS-Interface laut 
netstat dort wartet. In der config habe ich bereits auf Allow From All 
umgestellt.

Intern gibt es eine 3,5cm Lüfter-Montage Stelle. Allerdings habe ich 
derzeit einfach einen 8cm 12V Lüfter obendrauf gelegt und lasse den mit 
5V laufen. Dieser saugt die Luft oben einfach raus.


sollte eigentlich so gehen:

http://nas:631/

Dies wird für IPP-Protokoll und Admin-Interface verwendet.

Aber wo ein modifizierter rsync ist, würden mich weitere Modifikationen 
nicht wundern.

Die Tintenstände lassen sich über cups nicht abfragen. Dafür muss man 
prinzipiell das druckereigene Protokoll über USB ansprechen.

Hallo, ich besitze die 2TB-Variante und habe nicht nur mit der 
Temperatur zu kämpfen. Das Nas läuft noch auf der Originalfirmware von 
Medion.
Da sich die Festplatte auch bei Nichtnutzung nicht selbsttätig 
ausschaltet, zumindest nicht nur bei mir, steigt die Temperatur bis auf 
50 Grad an. Beim kopieren von Daten waren es auch schonmal 55 Grad mit 
Zwangsabschaltung der Festplatte.
Ich bin gerade am Basteln mit einem 5V-Lüfter den ich drunter bauen 
wollte und über USB mit Strom versorgen will.
Da ich in Sachen Linux absolut "doof" bin (ausser fritzen des Speedports 
über Ubuntu), hoffe ich immernoch auf eine Version, die auch ich als Dau 
auf das Nas spielen kann.
Bis dahin lese ich fleißig weiter, und zähle auf euer Wissen.

@Jan A.

ein oben drauf montierter zum Ansaugen der Luft von unten durch das NAS 
tut es auch.

Wenn es leiser sein soll, dann geht auch ein 12V 8cm Lüfter an 5V 
angeklemmt.

Ein Problem des Medion NAS ist wohl auch der schnelle Temperaturanstieg.

Die Seagate-Platten haben ein Limit von 20°C pro Stunde bezüglich der 
Temperaturveränderung. Das wird beim Medion NAS weit schneller erreicht.

Daher ist eine stabile Wärmebilanz wichtig.

Sven B. schrieb:
> Wenn es leiser sein soll, dann geht auch ein 12V 8cm Lüfter an 5V
> angeklemmt.

Danke für die schnelle Antwort. Hätte mich auch schon eher gemeldet, 
wollte nur euren Thread nicht zuspammen.

Einen 12V habe ich schon versucht, der läuft bei mir über USB garnicht
an. Ein versuchsweise 35 mm 5V läuft an, ist nur sehr laut. Ich würde es 
ja auch innen anstecken, ich habe aber bei der Demontage nichts 
gefunden.

Bislang schalte ich es einfach aus wenn ich es nicht brauche, den für 
mehr als Datenarchivierung ist es derzeit eh nicht zu gebrauchen.(mit 
originaler Firmware)

Jan A. schrieb:
> Einen 12V habe ich schon versucht, der läuft bei mir über USB garnicht
> an. Ein versuchsweise 35 mm 5V läuft an, ist nur sehr laut. Ich würde es
> ja auch innen anstecken, ich habe aber bei der Demontage nichts
> gefunden.

Die vier unbenutzten Löcher im Blech, das sind die aber dafür braucht 
man einen Radiallüfter. Und der muss zur Seite pusten.

Wahrscheinlich war da mal in einem Prototyp ein Loch im Gehäuse für.

Sven B. schrieb:
> Die vier unbenutzten Löcher im Blech, das sind die aber dafür braucht
> man einen Radiallüfter. Und der muss zur Seite pusten.

Ja habe ich völlig übersehen. Ich habe auch eben nochmal meinen 12V 
Lüfter angeschoben, er dreht doch aber zu langsam. Diese Woche sollte 
der neue 5V kommen wenn der nicht funzt schaue ich nochmal nach der 
internen Variante.
Danke

Wie sieht es eigentlich momentan aus mit ALARM auf dem NAS?

Wie läuft die Entwicklung?

läuft soweit, habe nur mal etwas Pause gemacht. offen sind noch Punkte 
im eth und vielleicht noch was bezüglich Performance des SATA.

Wunderbar :)

Erstellst du, sobald es wirklich öffentlichkeitstauglich ist einen 
Wiki-Artikel mit den grundlegenden Instruktionen?

noxx schrieb:
> Versuche mal die vordefinierten Ordner zu deaktivieren. Bei einigen
> bereiten die Probleme. Habs bei mir auch so gemacht und mir neue
> eingerichtet. Evtl geht dann der Standby.

Danke für den Tip, habe ich im anderen Forum auch gelesen, war bisher 
nur zu Faul meine ganzen Daten umzuschaufeln.
Wenn ich dem Thread hier folgen kann, wird die Platte ja sowieso neu 
partitioniert und die Daten müssen neu drauf. Ich werde es morgen 
trotzdem mal versuchen.

solo schrieb:
> Daher stammt auch das ominöse perl-skript, welches die Arch-Leute für
> die pogoplug verwenden. WarheadSE sagt ja, sie hätten das über die
> HMNHDCE rausgefunden. Der sinnlose *0 String ist dort schon drin.

Ich mag diesen Kommentar:

1

# TODO- configure U-Boot to use these if initial ones are bad

Die Checksum ist lustig, die kann man in einem Bash-Skript rechnen.

unter http://www.github.com/-ft/NAS7820-Tools
und dann generatembr.

Aber es wirft auch eine Frage auf, wie startet Iomega das HMNDCE wenn es 
noch blank ist.
Vom Verständnis her müssten, die doch preinitialisierte Platten 
verwenden. Anderenfalls müsste ein Boot-Zugang über die serielle 
Schnittstelle verwendet werden.

solo schrieb:
> Du bist der absolute Code-Wizard, was!? Wenn du jetzt noch ein Skript
> baust, um im uboot-image die kernel-start-zeile zu ändern, kann man nur

Im U-Boot-Image kann die leider nicht länger werden, aber ein U-Boot 
Environment Image, das geht.

Folgender Code ist aber nicht verifiziert, ob er was korrektes erzeugt.

1

# Generate UBootEnv

2

echo -en "bootargs= console=ttyS0,115200 elevator=cfq mac_addr=0x00,0x30,0xe0,0x00,0x00,0x01\0" >ubootenv.data

3

echo -en "bootcmd=run boot_nand\0" >>ubootenv.data

4

echo -en "bootdelay=2\0" >>ubootenv.data

5

echo -en "baudrate=115200\0" >>ubootenv.data

6

echo -en "ipaddr=192.168.50.100\0" >>ubootenv.data

7

echo -en "serverip=192.168.50.59\0" >>ubootenv.data

8

echo -en "autoload=n\0" >>ubootenv.data

9

echo -en "netmask=255.255.0.0\0" >>ubootenv.data

10

echo -en "bootfile=\"uImage\"\0" >>ubootenv.data

11

echo -en "load_nand=nboot 61000000 0 440000\0" >>ubootenv.data

12

echo -en "boot=bootm 61000000\0" >>ubootenv.data

13

echo -en "boot_nand=run load_nand boot\0" >>ubootenv.data

14

echo -en "MODEL_ID=AB03\0" >>ubootenv.data

15

echo -en "PRODUCT_NAME=STG-212\0" >>ubootenv.data

16

echo -en "VENDOR_NAME=MitraStar Technology Corp.\0" >>ubootenv.data

17

echo -en "ethaddr=${macaddr}\0" >>ubootenv.data

18

echo -en "\0" >>ubootenv.data

19

# Enlarge the image

20

dd if=/dev/zero of=ubootenv.data conv=notrunc seek=8167 bs=1 count=1 status=noxfer &>/dev/null || {

21

    echo "Failed to write"

22

    exit 1

23

}

24

cksum <ubootenv.data >cksum.data

25

read CRC32 REMAINDER <cksum.data 

26

# Byte 0

27

CRC32_OCTAL0L=$((CRC32 & 7))

28

CRC32_OCTAL0M=$(((CRC32 >> 3) & 7))

29

CRC32_OCTAL0H=$(((CRC32 >> 6) & 3))

30

# Byte 1

31

CRC32_OCTAL1L=$(((CRC32 >> 8) & 7))

32

CRC32_OCTAL1M=$(((CRC32 >> 11) & 7))

33

CRC32_OCTAL1H=$(((CRC32 >> 14) & 3))

34

# Byte 2

35

CRC32_OCTAL2L=$(((CRC32 >> 16) & 7))

36

CRC32_OCTAL2M=$(((CRC32 >> 19) & 7))

37

CRC32_OCTAL2H=$(((CRC32 >> 22) & 3))

38

# Byte 3

39

CRC32_OCTAL3L=$(((CRC32 >> 24) & 7))

40

CRC32_OCTAL3M=$(((CRC32 >> 27) & 7))

41

CRC32_OCTAL3H=$(((CRC32 >> 30) & 3))

42

43

CRC32_STRING="\0$CRC32_OCTAL0H$CRC32_OCTAL0M$CRC32_OCTAL0L"

44

CRC32_STRING="$CRC32_STRING\0$CRC32_OCTAL1H$CRC32_OCTAL1M$CRC32_OCTAL1L"

45

CRC32_STRING="$CRC32_STRING\0$CRC32_OCTAL2H$CRC32_OCTAL2M$CRC32_OCTAL2L"

46

CRC32_STRING="$CRC32_STRING\0$CRC32_OCTAL3H$CRC32_OCTAL3M$CRC32_OCTAL3L"

47

echo -en "$CRC32_STRING" >ubootenv.crc

48

cat ubootenv.crc ubootenv.data >ubootenv.bin

cksum macht nicht das was ich laut Beschreibung gedacht habe. Es 
berechnet eine andere 32-bittige CRC.

ich hab da mal in http://www.github.com/ft-/NAS7820-Tools unter ubootcrc 
einen Generator für ein 8kB grosses U-Boot-Environment gebaut, wie es 
auch im U-Boot seitens PLX verwendet wurde.

hier aber nochmal als Shell-Skript:

1

# Generate UBootEnv

2

echo -en "bootargs= console=ttyS0,115200 elevator=cfq mac_addr=0x00,0x30,0xe0,0x00,0x00,0x01\0" >ubootenv.data

3

echo -en "bootcmd=run boot_nand\0" >>ubootenv.data

4

echo -en "bootdelay=2\0" >>ubootenv.data

5

echo -en "baudrate=115200\0" >>ubootenv.data

6

echo -en "ipaddr=192.168.50.100\0" >>ubootenv.data

7

echo -en "serverip=192.168.50.59\0" >>ubootenv.data

8

echo -en "autoload=n\0" >>ubootenv.data

9

echo -en "netmask=255.255.0.0\0" >>ubootenv.data

10

echo -en "bootfile=\"uImage\"\0" >>ubootenv.data

11

echo -en "load_nand=nboot 61000000 0 440000\0" >>ubootenv.data

12

echo -en "boot=bootm 61000000\0" >>ubootenv.data

13

echo -en "boot_nand=run load_nand boot\0" >>ubootenv.data

14

echo -en "MODEL_ID=AB03\0" >>ubootenv.data

15

echo -en "PRODUCT_NAME=STG-212\0" >>ubootenv.data

16

echo -en "VENDOR_NAME=MitraStar Technology Corp.\0" >>ubootenv.data

17

echo -en "ethaddr=${macaddr}\0" >>ubootenv.data

18

echo -en "\0" >>ubootenv.data

19

# Enlarge the image

20

dd if=/dev/zero of=ubootenv.data conv=notrunc seek=8187 bs=1 count=1 status=noxfer &>/dev/null || {

21

    echo "Failed to write"

22

    exit 1

23

}

24

crc32 ubootenv.data >cksum.data

25

read CRC32 <cksum.data

26

CRC32=$((0x$CRC32))

27

# Byte 0

28

CRC32_OCTAL0L=$((CRC32 & 7))

29

CRC32_OCTAL0M=$(((CRC32 >> 3) & 7))

30

CRC32_OCTAL0H=$(((CRC32 >> 6) & 3))

31

# Byte 1

32

CRC32_OCTAL1L=$(((CRC32 >> 8) & 7))

33

CRC32_OCTAL1M=$(((CRC32 >> 11) & 7))

34

CRC32_OCTAL1H=$(((CRC32 >> 14) & 3))

35

# Byte 2

36

CRC32_OCTAL2L=$(((CRC32 >> 16) & 7))

37

CRC32_OCTAL2M=$(((CRC32 >> 19) & 7))

38

CRC32_OCTAL2H=$(((CRC32 >> 22) & 3))

39

# Byte 3

40

CRC32_OCTAL3L=$(((CRC32 >> 24) & 7))

41

CRC32_OCTAL3M=$(((CRC32 >> 27) & 7))

42

CRC32_OCTAL3H=$(((CRC32 >> 30) & 3))

43

44

CRC32_STRING="\0$CRC32_OCTAL0H$CRC32_OCTAL0M$CRC32_OCTAL0L"

45

CRC32_STRING="$CRC32_STRING\0$CRC32_OCTAL1H$CRC32_OCTAL1M$CRC32_OCTAL1L"

46

CRC32_STRING="$CRC32_STRING\0$CRC32_OCTAL2H$CRC32_OCTAL2M$CRC32_OCTAL2L"

47

CRC32_STRING="$CRC32_STRING\0$CRC32_OCTAL3H$CRC32_OCTAL3M$CRC32_OCTAL3L"

48

echo -en "$CRC32_STRING" >ubootenv.crc

49

cat ubootenv.crc ubootenv.data >ubootenv.bin

crc32 liegt bei ArchLinux unter /usr/bin/perlbin/vendor/crc32 wenn das 
Paket perl-archive-zip installiert ist.

Was mir gerade einfällt:

Ihr schreibt ja immer davon, die Platte zu plätten, muss das denn sein? 
Sicher, ein Backup kann nicht schaden, aber es werden doch nur die 
ersten 32MB überschrieben, oder?

Dann könnte man ja den GPT sichern und nach der Änderung 
wiederherstellen, oder?

solo schrieb:
> Wüsste jetzt nicht, wer das geschrieben hätte. Nein, das Neu-formatieren
> ist nicht unbedingt erforderlich. Du kannst den Anfang der Platte auch
> präparieren und die vorhandene GPT dabei intakt lassen.

Medion hat im Original-Kernel die GPT rausgelassen. Aber wenn man am PC 
die Partitionen erstellt gibt es nix dagegen einzuwenden.

Jedenfalls muss man ungefähr 32MB freimachen. Wenn man aber geradezu die 
ersten paar Sektoren überschreibt, dann ist auch die Partitionierung 
weg.

Aber man kann durchaus auch die Daten-Partition erhalten. Jedoch 
funktioniert der 2.6.31.8-Kernel im ArchLinuxARM nicht mit XFS.

Update 3.1:

Hatte gerade Informationen bezüglich Fehler in der Link Speed Selection 
des Ethernet-Treibers inklusive Korrektur bekommen und habe diese 
integriert.

Das wurde auch anbei der Informationen geschrieben, dass es dort noch 
Ungereimtheiten gibt. Ich habe mittlerweile ein Skript drin, welches 
nach einem USB-Seriell-Adapter sucht und ne Shell drauf startet, wenn 
vorhanden.

Das werd ich erst entfernen, wenn soweit alles läuft.

"Oder geht das nur mit einer komplett neunen Software ?"

Genau.

noxx schrieb:
> Ist es möglich, mit ein "paar Klicks" den 2ten Kern
> zu aktivieren?

nur mit einem nicht von Medion bereitgestellten Kernel.

Mit ein paar Klicks geht da gar nichts.

archlinuxinstaller-medion-pogoplugpro-based enthält die relevanten 
Schritte.
Man kann den Inhalt auf den Stick packen und neustarten und warten bis 
es das System abschliesst mit einem Neustart.
Oder alternativ hinterher noch den Inhalt von usb_key_func draufkopiert, 
dann kann man die Ausgaben im telnet Skript lesen (indem man do.sh 
ausführt).

wenn man da das folgende noch mit draufpackt, dann hat der Stick alles 
was nötig ist:

http://archlinuxarm.org/os/ArchLinuxARM-oxnas-latest.tar.gz


Ich verwende persönlich den Boot des NAS mittels SATA durch den Chip 
selbst.

Ich habe mir gerade mal den Spass gekönnt und ein USB-Wireless Headset 
am NAS angesteckt. ;)

Hallo,

ich habe auch eine Frage.
Wenn es schon möglich ist, Arch Linux mit dem 3er Kernel auf dem NAS 
laufen zu lassen. Wie schwierig ist es dann Debian mit dem Kernel darauf 
einzurichten?

Es gibt ja schon eine Beschreibung im Wiki, aber die ist ja leider nicht 
komplett funktionsfähig.

Viele Grüße

Hallo,

ich hab hier jetzt lange gelesen, aber leider etwas den Überblick 
verloren...
Also korregiert mich bitte:

1. Mit den Tools von Sven B. bekomme ich arch Linux auf mein P89626.
1.1 Und zwar mit einem 3er Kernel - nicht den von der original Firmware
2. Damit habe ich DualCore Support
2.1 Das sollte ich ohne Lüfter aber nicht nutzen
3. Da das NAS die Firmware noch im Rom hat, kann ich zurück zur original 
Firmware
3.1 Überschreib ich die im Wiki angebenen Sektoren der Platte einfach 
dafür?

Ist denn der Kernel von Sven B. jetzt komplett, oder fehlen da noch 
einzelene Treiber?

Auf jeden Fall vielen Dank für die Mühe

Daniel

Daniel V. schrieb:
> 1. Mit den Tools von Sven B. bekomme ich arch Linux auf mein P89626.
> 1.1 Und zwar mit einem 3er Kernel - nicht den von der original Firmware
> 2. Damit habe ich DualCore Support
> 2.1 Das sollte ich ohne Lüfter aber nicht nutzen
> 3. Da das NAS die Firmware noch im Rom hat, kann ich zurück zur original
> Firmware
> 3.1 Überschreib ich die im Wiki angebenen Sektoren der Platte einfach
> dafür?

1. ja
1.1 bisher nicht sondern den 2.6.31.8 kompiliert für OX820 von 
ArchLinuxARM
2. ja sowohl mit dem ArchLinuxARM-Kernel 2.6.31.8 als auch dem 3.1er
2.1 das gilt schon bei der Medion-Firmware
Mit Lüfter stimmt allerdings die Wärmebilanz
3. ja, die wird nicht verändert
3.1. ja, deswegen eben auch die Daten besser noch auf einem anderen 
System haben

Das Skript setzt das System so auf:
Partition 1 => Kernel-Image (uImage) roh auf Partition
Partition 2 => Root-Partition
Partition 3 => Swap 512MB (muss aber manuell von Hand in fstab 
eingetragen werden)

Zeile zur Swap-Einrichtung in fstab:

1

/dev/sda3 swap swap auto 0 0

Daniel V. schrieb:
> Ist denn der Kernel von Sven B. jetzt komplett, oder fehlen da noch
> einzelene Treiber?

Funktional ist soweit alles geklärt. Aber bisher ist er nicht integriert 
in der Install-Umgebung von mir.

Man kann am 3.1 zwar hier und da noch was verbessern aber funktional ist 
soweit alles in Ordnung.

Und mit zwei Kernen ist es doch um einiges reaktiver als nur mit einem 
Kern.

Beim SSH-Login mit Zertifikat ist es deutlich schneller als ein 1,2GHz 
x86.

Von ArchLinuxARM wird sicherlich auch mal ein fertiges Kompilat kommen. 
Die Leute dort sind letztlich auch schon sehr interessiert an einem 
Kernel, der sich am Mainline-Kernel orientiert.

solo schrieb:
> Wenn du genauer wissen willst, was vor sich geht, führt kein Weg dran
> vorbei, die Festplatte des NAS auszubauen und an den PC anzuschließen.
> Wenn du Windows drauf hast, kannst du sysresccd (danach googeln) booten
> und die von Sven genannten Scripte durchgehen.

Ein Kumpel von mir hat bei seiner Installation von ArchLinuxARM ein 
schönes Dokument gemacht, mal sehen wann und ob er es online stellt.

Moin Moin

Ich will nun ach mal eine Beitrag leisten und bringe mal eine DRAFT 
Version von einer ArchLinux ARM Installations-Dokumentation für das 
Medion NAS raus.

Ich habe das Wochenende genutzt um mein NAS auch auf den ArchLinuxARM 
Kernel 3.1.0 zu bringen. Ich wollte jedoch nicht Anfangen bevor ich eine 
angemessene Lösung für eine interne Belüftung fertiggestellt habe. Im 
DRAFT PDF ist das beschrieben. Meine Temperatur der HDD bleibt unter 45 
°C auch nach 500 GB schreiben. Im Idel Modus unter 40°C.

Das DOC ist z.Zt. nur eine DRAFT Version, da einige Punkte noch fehlen 
bzw. weiter ausgeführt werden müssen. Für Anregungen stehe ich zur 
Verfügung.

Ulf Z. schrieb:
> Ich will nun ach mal eine Beitrag leisten und bringe mal eine DRAFT
> Version von einer ArchLinux ARM Installations-Dokumentation für das
> Medion NAS raus.

Danke für die Beschreibung. Die liest sich schonmal echt gut.

solo schrieb:
> Arch ist eine nette schlanke Distri, die sehr gut zum NAS passt. Das
> Grundsystem braucht ein paar MB weniger RAM als Debian, was bei den
> knappen 128 MB des Medion nicht schlecht ist. Schau dir Arch mal an,
> wenn möglich.

Dann werde ich am WE, mit der Beschreibung zusammen, das ganze mal 
ausprobieren. ... Arch Linux mal in einer VM installier ...

Viele Grüße

Jens, Sven, Utz  et.al. - Großen Dank für Eure Investition von Zeit & 
"Denke" in das Projekt!

Bevor ich nun eines meiner NAS Systeme plätte (bei ALDI gilt immer: 
"Nimm Zwei!" ;-) ):

1. Der von Utz beschriebene 2.36 ARCH Install erzeugt ja ein OHNE USB 
Stick bootbares System.
Mit Jens Anleitung zu DEBIAN habe ich das nicht hinbekommen. Da brauche 
ich stets den USB Stick - und schlimmer noch: aptitude installiert auf 
den USB Stick.
Was mache ich falsch?

(Hinweis: Werde später die von Utz für ARCH beschriebemen Schritte noch 
einmal analog für DEBIAN durchspielen).

2. Wie reagiert das System auf 3 & 10 sec. Reset (1x bzw. 3x Beep)? 
Macht dann bei Letzterem die Firmware die Platte platt 
(Ursprungszustand)?

Beste Grüße

PS: Soll natürlich "Ulf" (und nicht "Utz") heissen ... X-(

Sehr gute Anleitung Ulf :)

Fändest du es allerdings nicht auch besser, wenn jeder an der Anleitung 
etwas ändern könnte, wenn er will? Mich hat es schon in den Fingern 
gejuckt, als ich den ein oder anderen kleinen Rechtschreibfehler gesehen 
habe ;)

Aber sicherlich könnten auch andere hier etwas von ihrer fachlichen 
Expertise loswerden. Im PDF-Format ist so etwas natürlich nur schwer 
möglich.

noxx schrieb:
> Hat dieses ArchLinux eine GUI?

Nein :P Man kann sich eine Desktopoberfläche installieren, aber auf dem 
NAS ist so etwas natürlich fehl am Platz^^

Peter A. Gebhardt schrieb:
> 2. Wie reagiert das System auf 3 & 10 sec. Reset (1x bzw. 3x Beep)?
> Macht dann bei Letzterem die Firmware die Platte platt
> (Ursprungszustand)?

Der Button ist dem System egal. Es sei denn man baut ein Kernel-Modul, 
dass sich für den GPIO des Reset-Buttons interessiert.

> Der Button ist dem System egal. Es sei denn man baut ein Kernel-Modul,
> dass sich für den GPIO des Reset-Buttons interessiert.

Danke! Da steht meinem SQL Server ja nichts mehr entgegen ;-)
Das Binary für mySQL on ARM habe ich Dank Ulfs Anleitung auch schon im 
Netz gefunden.

@all: Danke für die Resonanz

Johann B. schrieb:
> Fändest du es allerdings nicht auch besser, wenn jeder an der Anleitung
> etwas ändern könnte, wenn er will? Mich hat es schon in den Fingern
> gejuckt, als ich den ein oder anderen kleinen Rechtschreibfehler gesehen
> habe ;)

Ich hatte schon versucht das Dokument bei Google-Dokuments 
unterzubringen - hat mir glatt die Formatierung durch gedreht - suche 
nach eine Lösung mit Subautoren und "book captain". (evtl. auch etwas 
wie typo3 ...) Bis da hin könntet ihr technische Verbesserungen bzw, 
Anregungen an mich direkt senden. Evtl. müsste man da ein weiters Forum 
eröffnen, damit diese nicht untergehen und auch dieses technische Forum 
nicht belästigt wird.

Zudem ist das DOC mit LiberyOffice erstellt und schon sehr groß ( > 5MB 
) daher überlege ich den Hardware Teil aus zu lagern. Ein weiteres DOC 
für die Einrichtung des NAS von Medion ist auch angedacht. Damit sollte 
eine Ordentliche Dokumentationssammlung herauskommen.

@all: wenn ihr an dem NAS schraubt kann ich euch nur Empfehlen für Luft 
im NAS zu sorgen, da meine originale 1,5 TByte Platte schon eine Hitze 
Warnung in den S.M.A.R.T. Tabellen nach 2 Tagen aufwies (65°C) und sich 
nicht mehr im NAS befindet... Die SeaTools sagen jedoch: "Alles sei 
I.O." Grübelei

Teste gerade eine Laptop USB Docking Sation an dem NAS von Toshiba 
(Sound geht schon)

@merz:

Sieht so aus als wäre der USB Stick nicht gemounted worden. Macht die 
Medion Firmware eigentlich automatisch.

@Emerald Flint:

Die Platte wird nicht kaputt sein. Lösche mal den MBR und die 
Partitionstabelle und steck die Platte in das Medion NAS. Die Medion 
Firmware wird die blanke Platte erkennen. Dann kannst du über das 
Webinterface die Platte einrichten. Anschliessend kannst du nochmal das 
Script starten um ArchLinuxARM zu installieren.

Merz schrieb:
> bräuchte mal kurz eure hilfe.
> Ich habe gerade versucht nach Ulf Z. Anleitung arch zu installieren.
> Telnet habe ich aufbekommen nur wenn ich  mit
> "cd e-data  {XXX} /" in den Ordner wechseln möchte komme ich dann
> hierhin

@merz:

Das NAS muss mit dem USB-Stick angesteckt durchstarten. Wenn das 
eigentliche System läuft, dann gehts nicht.

und so führt man das aus:

1

cd /mnt/parnerkey

2

./do.sh

Emerald Flint schrieb:
> Alles soweit gemacht, die ganze Prozedur wiederholt aber unverändert.
> Das shellscript meldet keine Fehler, am Ende erbotet es dann. Danach
> nicht ansprechbar per SSH übers Terminal.
> Scheint wohl nicht richtig zu booten. Habe es mit dyn und stat DHCP
> versucht, kein Unterschied.
> Jemand ne Idee woran es liegen könnte?

Nach dem Start kommt es prinzipiell nur mit einer per DHCP zugewiesenen 
Adresse hoch. Einfach mal im Router nachschauen.

Alternativ: Platte an PC per USB o. SATA hängen. Und in der zweiten 
Partition die Datei etc/rc.conf editieren. (Linux-Distribution 
erforderlich)

1

interface=eth0

2

address=192.168.1.44 # IP-Adresse für das NAS

3

netmask=255.255.255.0 # Netzmaske

4

broadcast=192.168.1.255 # Broadcast-Adresse

5

gateway=192.168.1.1 # Router-Adresse

Man kann allerdings auch die reboot-Zeile auskommentieren und dann die 
Partition /dev/sda2 am NAS nochmal mounten und das Editieren dort mit vi 
durchführen.


dirk schrieb:
> Beim Booten laeuft er auf einen Fehler und startet daraufhin nicht
> vernuenftig ... evtl. muesste man da nochmal genauer nachschauen.

Das wäre sinnvoll. Denn ich hatte das Skript auf meinem NAS entwickelt 
und halt auch mit der telnet-Methode überprüft. Lediglich die 
parted-Geschichte war noch nicht astrein.

Man kann das System aber auch am PC fixen. Nur dazu muss erst mal klar 
sein, was passiert ist.

Die Medion-Firmware muss aber eigenständig den Stick unter 
/mnt/parnerkey gemountet haben. Alles andere kann nicht funktionieren.

Emerald Flint schrieb:
> Jemand ne Idee woran es liegen könnte?

Hast Du die Dateien aus archlinuxinstaller-medion-pogoplugpro-based von 
einem USB-Stick aus verwendet?

Da fehlt in do.sh in Zeile 28 ein

1

cd /mnt/parnerkey

 ansonsten werden die Image-Dateien nicht gefunden.

Daniel H. schrieb:
> Hast Du die Dateien aus archlinuxinstaller-medion-pogoplugpro-based von
> einem USB-Stick aus verwendet?
>
> Da fehlt in do.sh in Zeile 28 eincd /mnt/parnerkey ansonsten werden die 
Image-Dateien nicht gefunden.

Das do.sh soll aus /mnt/parnerkey ausgeführt werden, dann passt auch 
alles.

Aber ich habe es trotzdem mal eingebaut.

Neu ist jetzt auch die Möglichkeit eine rc.conf bei Installation mit ins 
System legen zu lassen.

Es liegt eine rc.conf.sample bei, die man zu rc.conf umbenennen kann. 
Dann wird das Skript diese auch in das neu eingerichtete System 
kopieren.

Sven B. schrieb:

> Das do.sh soll aus /mnt/parnerkey ausgeführt werden, dann passt auch
> alles.

Das Problem tritt ja nur auf, wenn man do.sh quasi blind von 
usb_key_func.sh ausführen läßt.

Ich habs jetzt ja auch mit eingebaut. Im Übrigen habe ich auch mal die 
Karteileichen entfernt. Ist also nur noch das da, was sinnvoll ist.

Emerald Flint schrieb:
> Danach tut sich wieder nichts, scheint nicht booten zu können (Die blaue
> LED blinkt nicht nach dem starten) Zur Sicherheit nochmal auf dem Router
> alles überprüft, nichts in der Log. Netzwerk mit Wireshark beobachtet.
> Auch nichts.

ArchLinux lässt die nicht blinken. Aber einen Durchstarten kann man an 
der grünen Netzwerk-LED erkennen. Die dürfte einmal für kurze Zeit 
ausgehen und wieder angehen.

Schonmal versucht anzupingen?


Im Übrigen das einzige was beim frisch installierten ArchLinux läuft ist 
ein SSH-Server.

Hallo,
kurze Frage zwischendurch. Welche Spannungspegel hat der UART. Ich habe 
noch FTDI Adapter für UART nach USB rumliegen, für 3.3V und 5V. 
Funktioniert da einer von am NAS?

Christian J. schrieb:
> Hallo,
> kurze Frage zwischendurch. Welche Spannungspegel hat der UART. Ich habe
> noch FTDI Adapter für UART nach USB rumliegen, für 3.3V und 5V.
> Funktioniert da einer von am NAS?

FTDI mit 3.3V sollte definitiv funktionieren.

Emerald Flint schrieb:
> Hab sowohl ping als auch ssh versucht, geht beides ins leere.

Womöglich hat das NAS aber eine andere IP vom Router bekommen, dann 
würde die bisherige ins leere führen.

Das habe ich doch schon mal von Johann B. gehört. Da werde ich doch mal 
einen 3.1er Kernel mit medion SATA only Config bauen und als Installer 
zusammenstellen.

Emerald Flint schrieb:
> Hab die Platte nochmal ausgebaut und unter Ubuntu nach geschaut.
> parted -l sagt mir das sich keine dort gültige partitionstabelle drauf
> befindet

Vorsicht mit Parted. Es müssen immer zuletzt noch die 444 Anfangs-Bytes 
in den MBR kopiert werden.
Anderenfalls startet das NAS nicht von der Platte.

Ich hoffe doch, dass die Zeile am PC parted -l /dev/sdb oder so hiess 
und nicht noch mit einer Nummer dahinter.

Wenn ich mir so die Skript-Ausgabe anschaue, dann ist aber definitiv 
eine Partition angelegt worden. Andernfalls würde allein schon mkfs.ext3 
nicht funktionieren.

Nicht zufällig noch einen USB-Stick am Rechner hängen, der hätte nämlich 
durchaus Super-Floppy-Format was eben auch bei Parted zu solch einer 
Ausgabe führen würde.

Nein, eigentlich nichts der gleichen. Ich führ das do script nun mal bis 
nach dem parted aus und schau mir dann an ob das auch gemacht wurde.

e: Hab mich mal registriert also nicht verwirrt sein über den 
Namenswechsel ;)

Soweit ich deinem Script entnehme, Schreibst du noch das u-boot und 
danach lässt du das Script beenden. Damit hast du auch keine Partitionen 
auf der HDD
du musst noch das Ausführen:

1

parted -s <<EOF

2

mklabel msdos

3

mkpart primary ext3 2048s 22527s

4

mkpart primary ext3 22528s -1048577s

5