Nachtrag:
Ich gehe schon davon aus, dass wenn ich ein erstes Image nach dem Aufbau
produziere, wohl durchaus ein U-Boot 1.1.2 dort einbaue. Halt weil der
Code nunmal schon auf anderen Geräten läuft.
Das wäre dann genau das was den meisten bereits hilft.
@ElektromAn:
Die CPU des PogoPlugPro sowie des Medion NAS ist ein arm11 MPCore.
Einen 926EJS gibt es NICHT als Zweikern-CPU.
Die Datei include/configs/oxnas.h ist vom Vorgänger PogoPlug. Es ist
nicht die des PogoPlugPro.
so sieht sie beim PogoPlug Pro im U-Boot Source aus:
1
#if (NAS_VERSION == 820)
2
#include"configs/ox820.h"
3
#elif (NAS_VERSION == 810)
4
#include"configs/ox810.h"
5
#elif (NAS_VERSION == 800)
6
#include"configs/ox810.h"
7
#else
8
#warning
9
#endif
10
11
#endif
Zur OXNAS Familie gehören mehrere SoC:
OX800 ARM926EJ-S
OX810 ARM926EJ-S
OX820 ARM11 MPCore
Das Medion NAS wie auch PogoPlugPro ist ein OX820.
Folgende Zeile findet sich in configs/ox820.h:
1
#define CONFIG_ARM11 1
Lest den richtigen Source code ansonsten kann ich nur fröhliches Bricken
wünschen.
Hier mal was zur Info zur GPL (was eben gerade den Kernel und U-Boot
betrifft):
Jeder der einen unter der GPL-stehenden Source Code zum Bauen eines
Binaries verwendet und diese Binaries an andere gibt, muss auch diesen
den Zugang zum Source Code ermöglichen.
Hier mal als Zusammenhang wie:
Medion NAS => Medion muss den Source Code bereitstellen
HMNDCE => Iomega muss den Source Code bereitstellen
PogoPlugPro => Cloud Engines muss den Source Code bereitstellen
Ihr könnt euch mal auf www.gpl-violations.org umschauen.
PLXtech muss den Kernel nicht den Medion-Kunden als Source geben. Aber
Medion muss dieses tun, weil Medion Binaries an besagte Kunden
weitergibt.
Nur mal so zum Thema NDA und Linux-Kernel. Die GPL erlaubt keine
Einschränkungen von aussen. Und der Kernel wird ausschliesslich unter
der GPL verbreitet.
@Sven B.
ICH werde die BOX (Pogoplug) nicht bricken, da ich keine Lust habe
an uBoot herumzuschrauben.
Das einzige was ich machen werde/würde ich am Kernel zu arbeiten.
Es geht auch anderes das ein System auf der HDD genutzt wird und dafür
braucht es nur die Unterstüzung des Kernels. Wenn darin ein InitRamFS
ist kann es ggf. auch ein System auf der Platte starten.
Und was nützt ein #define wenn es nicht verwendet wird.
@ElektromAn:
Es ging mir lediglich darum nachzuweisen, dass du da den falschen Source
Code herangezogen hast. Deswegen der letzte Satz von mir in dem Post als
allgemeiner Satz, weil wenn dann Leute voreilig auf deinem Post
aufbauen, dann wird es zu einem Bricken kommen.
Deine Variante ist genau die die ich als Kernel-Tausch-Variante
beschrieben habe, d.h. Kerńel und Initrd im Flash tauschen. U-Boot und
stage1 bleiben unangetastet. Nur am U-Boot Environment eventuelle
Änderungen.
Nur habe ich auch in meinem vorherigen Post den Unterschied zwischen
PogoPlug und PogoPlugPro darstellen wollen. Ich hoffe es ist mir
gelungen und dir somit auch der Hardware-Unterschied klar geworden.
Sven B. schrieb:> Deine Variante ist genau die die ich als Kernel-Tausch-Variante> beschrieben habe, d.h. Kerńel und Initrd im Flash tauschen. U-Boot und> stage1 bleiben unangetastet. Nur am U-Boot Environment eventuelle> Änderungen.
Hätte aber den Nachteil, das man bei jedem Kernel Update neu Flashen muß
:(
Sven B. schrieb:> Nur mal so zum Thema NDA und Linux-Kernel. Die GPL erlaubt keine> Einschränkungen von aussen. Und der Kernel wird ausschliesslich unter> der GPL verbreitet.
Wie sieht es mit stage1 aus?
Jens D. schrieb:> Hätte aber den Nachteil, das man bei jedem Kernel Update neu Flashen muß> :(
das stimmt glaub ich nicht ganz. Theoretisch wäre auch eine art
Kexec-loader methode möglich. --> kernel + initrd sind nur dazu da einen
weiteren Kernel per kexec von der Festplatte zu starten. Den weg schlug
ich beim Bifferboard (
http://www.mikrocontroller.net/articles/Bifferboard ) auch ein, so war
es auch möglich Kernels zu laden die größer waren als 1Mb :D Man braucht
nur die init in der initrd so umzuschreiben, dass sie:
1. eine festplatte nach /mnt mountet
2. den kernel von der festplatte lädt
3. die festplatte unmountet
4. den geladenen kernel per kexec ausführt
Max H. schrieb:> Theoretisch wäre auch eine art> Kexec-loader methode möglich. --> kernel + initrd sind nur dazu da einen> weiteren Kernel per kexec von der Festplatte zu starten.
Naja gut, aber wenn das uBoot direkt machen kann, wäre das doch
einfacher, oder nicht?
mit dem Nachteil, dass wenn mals uboot zerflasht ist kann mer des ganze
auch gleich als Briefbeschwerer benutzen ^^ außerdem hätten wir dann
nicht die Probleme wie Dateisystem support in uboot, usb support in
uboot etc...
Ein mit xfs und usb funktionierender Kernel existiert bereits und es
wäre theoretisch auch möglich das raid in der init richtig einzurichten,
sodass man auch von dem normalen Festplattenlayout aus Kernel booten
kann.
solo schrieb:> Wie versprochen hänge ich die ersten 32MB meiner iomega HMNHDCE an.> Frisch gezogen mit:>> dd if=/dev/sda of=iomega_HMNHDCE_first_32mb.img bs=512 count=65536>> Jemand mit serieller Konsole sollte das auf eine leere HDD schreiben und> ins Medion NAS stecken. Das Image enthält GPT-Partitonstabelle, stage1,> mehrere uboot-kopien mit env's und das Kernel-image.>> Falls in der Konsole die SoC-Initialisierung mit 600Mhz auftaucht, habt> ihr einen guten Startpunkt, was gescheites zu basteln.
Es geht!!!
Hm. War ein wenig voreilig beim testen. Nun hab ich ja keine system mehr
auf Platte und kann nun nicht wirklich irgendwas booten.
Nun muß ich mal sehen, wie die das original system aus dem NAND booten
kann ;)
Jens D. schrieb:> Wie sieht es mit stage1 aus?
Der stage1 ist kein Kernel Bestandteil. Daher sieht es hier eben auch
anders aus.
Max H. schrieb:> das stimmt glaub ich nicht ganz. Theoretisch wäre auch eine art> Kexec-loader methode möglich.
Einmal müssten wir dann definitiv flashen und insbesondere, dass was im
Flash ist komplett verändern, da ja ein komplett anderes initrd für
diese Methode benötigt wird.
Das Hauptproblem bei allen diesen Änderungen ist, dass wir aktuell noch
keine Recovery-Methode haben. Sollte hier beim Flashen der falsche MTD
beschrieben werden, dann haben wir ebenfalls einen Brick.
Max H. schrieb:> Theoretisch wäre auch eine art> Kexec-loader methode möglich. --> kernel + initrd sind nur dazu da einen> weiteren Kernel per kexec von der Festplatte zu starten.Jens D. schrieb:> Naja gut, aber wenn das uBoot direkt machen kann, wäre das doch> einfacher, oder nicht?
Wir könnten auch einfach einen SATA-tauglichen U-Boot in den MTD-Block
schreiben, wo der Kernel liegt. Warum also einen Kernel nehmen, wenn der
U-Boot genauso gut wäre.
Oder noch simpler einen SATA-stage1 ins MTD, für dessen 8kB ist
garantiert noch irgendwo Platz ohne was anderes kaputt zu machen.
Und diesen dann von geflashten U-Boot laden und starten.
Der Rest ist dann auf Platte + neuem U-Boot Environment.
Max H. schrieb:> Ein mit xfs und usb funktionierender Kernel existiert bereits und es> wäre theoretisch auch möglich das raid in der init richtig einzurichten,> sodass man auch von dem normalen Festplattenlayout aus Kernel booten> kann.
Beim XFS habe ich doch schon mal einiges zitiert, dass gerade für die
heimische Betriebsumgebung ohne USV dieses nicht für alle Umstände
geeignet ist.
Das verzögerte Schreiben des XFS verträgt eben keine Stromausfälle im
falschen Moment. Der häufigste Stromausfall wird eben mal das Ziehen vom
Stecker oder solche Geschichten sein.
Zu dem ist eine kexec-Umgebung ebenfalls nicht so simpel aufzusetzen, da
wäre ein SATA-stage1 irgendwo anders noch zusätzlich im Flash
untergebracht noch eine Runde einfacher und das Recovery von einer
defekten Firmware auf Festplatte gespeichert mit RAW-Sektorzugriff nun
mal auch leicht zu reparieren.
Die Geschichten mit dem zerschossenen RAID bzw. XFS kann man ja hier
hinlänglich lesen.
Der Name RAID ist "Redundant Array of Inexpensive Disks". Das Wort
"redundant" ist bei dem Setup des Medion NAS nicht gegeben. Also kein
RAID. Den Begriff JBOD ("just a bunch of disks") würde ich da schon
akzeptieren.
Kann mir jemand ein printenv vom original system geben? (Hätte ich mal
vorher sichern sollen ;)
Brauche die uBoot Befehle, um das Original System aus den NAND laden zu
können...
Jens D. schrieb:> Es geht!!!
Perfekt, dann bleibt das Flash unangefasst.
Das ist die Optimum-Lösung.
Dann werde ich auch mit genau dem Setup bei meinem NAS testen.
Jens D. schrieb:> Brauche die uBoot Befehle, um das Original System aus den NAND laden zu> können...
bootcmd=run boot_nand
load_nand=nboot 61000000 0 440000
boot=bootm 61000000
boot_nand=run load_nand boot
Habs gerade aus meinem MTD3 Backup extrahiert.
Danke, habe ich gerade auch im Wiki bei P89626: uboot env gefunden.
Leider hab ich nun kein nboot :( Siehe help Ausgaben bei
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"
Jemand eine Idee, wie man vielleicht ein ganzes System per FTP booten
könnte? Wäre generell mal gut zu wissen.
Oder wie könnte ich das original uBoot wieder her bekommen?
Jens D. schrieb:> der wie könnte ich das original uBoot wieder her bekommen?
Die ersten 32MB plätten
dd if=/dev/zero of=/dev/<platte> bs=512 count=65536
So einfach kommt das NAND wieder hoch.
Max H. schrieb:> schon gut ich gebe mich geschlagen ;) mit der sata-stage1> Bootmöglichkeit die Jens getestet hat existiert jetzt ja auch eine> Recovery Möglichkeit =)
Ja, und das ist alles wirklich sehr erfreulich. Für ein recovery muß man
wohl dann wenn man keinen UART-Zugang hat die Platte wieder heraus holen
und dise ersten Sektoren wieder löschen? Willeicht nur den stage1-Teil?
Könnten wir diesen dump den solo freundlicherweise zur Verfügung
gestellt hat auf das nötigste reduzieren?
auch mein schreiben an Medion bzgl. Single Core Nutzung ist angekommen
^^
=========================================
Sehr geehrter Herr ...,
vielen Dank für Ihre Mitteilung.
Ihre Anfrage habe ich an die zuständige Fachabteilung weitergeleitet,
damit diese dort umgehend bearbeitet wird.
Ich bitte Sie noch um etwas Geduld.
Sobald mir eine Rückmeldung vorliegt, werde ich Sie sofort informieren.
Ich wünsche Ihnen einen guten Rutsch ins neue Jahr.
Freundliche Grüße aus Essen
Medion Technologie Center
Daniel Dildrop
=========================================
Sven B. schrieb:> Die ersten 32MB plätten>> dd if=/dev/zero of=/dev/<platte> bs=512 count=65536>> So einfach kommt das NAND wieder hoch.
Ja gut, dann muß ich aber mal eben die Platte wieder ausbauen und am PC
an stöpseln :(
Ideen was man ohne ausbau tun kann? (Geht nämlich jetzt nicht auf die
schnelle :)
Lucian M. schrieb:> Ja, und das ist alles wirklich sehr erfreulich. Für ein recovery muß man> wohl dann wenn man keinen UART-Zugang hat die Platte wieder heraus holen> und dise ersten Sektoren wieder löschen? Willeicht nur den stage1-Teil?> Könnten wir diesen dump den solo freundlicherweise zur Verfügung> gestellt hat auf das nötigste reduzieren?
Das ist auch meine Idee, wir nehmen das Image als Information und bauen
darauf dann das was wir brauchen auf.
Ja man kann es sicherlich mit einem Build-Kit kleiner gestalten.
Der stage1 und u-boot ist wichtig. Daher reicht es bis zum Sektorstart
des Kernels.
Sektoren 0-1289 und eine neue Partitionstabelle dürften reichen.
Für die Leute die 600MHz statt Lüfter wollen tut der stage1 von der
HMNDCE.
Der U-Boot hat ext2load drin. Also denkt an Partition ab Sektor 1290 mit
Ext2/Ext3 und 3,8GB für Arch RootFS.
Die gängige Lösung wäre somit praktisch fertig. Muss nur noch einer mal
umsetzen und die Schritte zusammenschreiben.
Endlich konnte ich mal wieder lesen was hier passiert ist. Und das sind
ja wunderbare Neuigkeiten.
Damit ich das richtig Verstehe, ist jetzt folgendes Möglich?
1) Jemand könnte jetzt ein Basis-System installieren (Debian oder ARM
Linux), anschliessend die ersten paar MB von der Platte dd'n und für
andere zur Verfügung stellen.
2) Diese können sich einfach per Telnet mit einer unangetasteten Box
verbinden und das Image der ersten paar MB über einen angeschlossenen
USB-Stick dann wiederum auf die interne Platte schreiben und haben nach
einem Reboot das gleiche Basis-System.
Jens D. schrieb:> Ideen was man ohne ausbau tun kann? (Geht nämlich jetzt nicht auf die> schnelle :)
mw
ide write
und dann U-Boot zum Überschreiben des Sektors 34 verwenden und den
Sektor 57088.
mw l 0x60000000 0 128
ide write 0x60000000 22 1
ide write 0x60000000 df00 1
Damit werden dann einfach mal Nullen auf die jeweils ersten Sektoren des
stage1 auf der Platte geschrieben.
Michael Kebe schrieb:> 1) Jemand könnte jetzt ein Basis-System installieren (Debian oder ARM> Linux), anschliessend die ersten paar MB von der Platte dd'n und für> andere zur Verfügung stellen.
Da wir nicht alle die gleichen Platten haben, könnte man das besser als
kleines Bash-Skript mit Daten-Image bauen, was dann die Partitionen
passend neu erstellt.
Michael Kebe schrieb:> 2) Diese können sich einfach per Telnet mit einer unangetasteten Box> verbinden und das Image der ersten paar MB über einen angeschlossenen> USB-Stick dann wiederum auf die interne Platte schreiben und haben nach> einem Reboot das gleiche Basis-System.
Genauso nur eben besser mit Bash-Skript.
Sven B. schrieb:> mw> ide write>> und dann U-Boot zum Überschreiben des Sektors 34 verwenden und den> Sektor 57088.
Verstehe, aber so auf die schnelle weiß ich nicht wie ich das machen
sollte.
Hab aber eine Lösung gefunden, ein uBoot mit nboot per TFTP laden und
booten:
1
tftp 0x61000000 u-boot2470376.bin.hdd;go 61000000
2
nboot 61000000 0 440000; bootm 61000000
uBoot von Beitrag #2470376 hat ja nboot ;)
Läuft wieder, mit usb_key_func ;) So kann ich die Platte neu machen ;)
Die Medion-Firmware ist allerdings inkompatibel mit dem SATA-Boot, weil
sie grosse Teile der Boot-Umgebung zerstören würde.
Aber wir haben zumindest einen Weg für ArchLinux, Debian usw.
Jens D. schrieb:> uBoot von Beitrag #2470376 hat ja nboot ;)
Genau der mit aktiven SATA bei NAND-Boot. ;)
Ich habe ein blankes HDD-Image erstellt. Wenns läuft, dann braucht es
nur noch einen Kernel.
Allerdings kann ich noch nicht sagen, ob ich den stage1 richtig auf
750MHz geschafft hab einzustellen.
Ein U-Boot mit SATA-Boot ist drin und default environment. Also bei
Einsatz erstmal das NAND-U-Boot-Environment wegen der MAC-Adresse
auslesen.
Jetzt auch das Archiv dazu
install.sh /dev/sda
aber nur auf dem NAS
Partitionen werden vom Skript gelöscht.
kernel-install.sh /dev/sda kernel-image
ebenfalls so nur auf dem NAS.
Zum fehlenden Kernel
den installiert man so auf dem NAS
./kernel-install.sh /dev/sda uImage
Den Kernel habe ich noch nicht in passender Form aber vielleicht kann
jemand mit laufendem Arch Linux Kernel mal die Datei /proc/config.gz
auslesen und posten wenn die Datei vorhanden ist.
Sven B. schrieb:> Jetzt auch das Archiv dazu
Ich werde es mal testen.
Btw. mach doch ein github Projekt draus, dann können mehrere Dran
arbeiten. Kannst gern auch https://github.com/jedie/NAS7820-Tools forken
und einfügen...
@Jens D.
passt schon unter gleichen Namen ft- hab ich mal einen github.com
Account angelegt.
Der U-Boot mit Sicherheit noch nicht die finale aber man kriegt damit
schon was hin.
Max H. schrieb:> Oder einfach die skripts von WarheadsSE verwenden ;)
Der Kernel muss für die Festplatten-LEDs ein paar Patches haben, die
noch sein müssen. Aber das ist auch eine Variante da hast Recht.
Allerdings dürfen wir das Medion NAS hardwaretechnisch unverändert nicht
so hoch getaktet laufen lassen.
Im Archiv von WarheadsSE findet sich alles von 700-850MHz in 50MHz
Schritten. Dann braucht es ja nur noch das eine Exemplar mit 600MHz fürs
Untertakten.
Der Kernel ist für die Ungeduldigen auch erstmal was, wenn die nopci
Variante verwendet wird.
Die Partitionstabelle die geschrieben wird, könnte passen allerdings
kann ich es nicht ohne weiteres sagen.
Somit haben wir also eine erste Basis mit ArchLinux die man ohne TFTP
Boot installieren kann.
@Jens D.
Du hast doch gerade eh eine geplättete Platte gehabt, dann hättest
gleich das erste voll lauffähige ArchLinux-System.
Sven B. schrieb:> Der Kernel muss für die Festplatten-LEDs ein paar Patches haben, die> noch sein müssen. Aber das ist auch eine Variante da hast Recht.
Was spricht denn momentan gegen den Medion-Kernel mit aktivierter
dualcore Unterstützung?
Nichts ausser der Konfig bezüglich der bootargs. Die kann man aber
anpassen.
Ich habe ja auch nicht gesagt, dass es abgeschlossen ist. Nur das eine
erste Methode für die Ungeduldigen gefunden ist.
Ich möchte vom Prinzip her auch den Kernel mit den
Festplatten-LED-Anpassungen nutzen können. Ist nun mal doch schöner wenn
man die Festplatten-Aktivität auch sieht.
Sven B. schrieb:> @Jens D.>> Du hast doch gerade eh eine geplättete Platte gehabt, dann hättest> gleich das erste voll lauffähige ArchLinux-System.
Das hab ich mir auch gedacht ;)
@Jens D.
Die Sektorengrösse ist bei dd unbedeutend. BS = Block Size
Probiere doch mal das Skript von WarheadsSE aus. Lediglich die symlinks
müsstest du ändern
ln -sf stage1/stage1.wrapped750 stage1.wrapped
ln -sf uImages/uImage.nopci uImage
im Skript dann noch disk=/dev/sdc anpassen.
und dann "./disk_create" aufrufen.
Der ROM-Code und stage1 denken in 512 Byte Sektoren also dem Legacy Mode
den Festplatten nach dem Reset einschalten.
Eventuell muss ich noch erst ein bisschen stage1 bauen üben. Daher mal
mit dem Skript.
Mir ist an dem Skript von WarheadsSE aufgefallen, dass er ein paar Bytes
des MBR schreibt. Ich habe den ersten Sektor mal mit eingepflegt.
Ich nehme mal an das Perl nicht so ohne weiteres auf dem NAS erreichbar
sein wird.
Das Skript nutzt die Binaries erstmal von WarheadsSE. Allerdings ohne
Perl damit nur coreutils verwendet werden. Ich habe das Perl-Segment von
WarheadsSE in ein mbr.bin-Binary umgewandelt.
Ich hab nochmal das gemacht:
> dd if=iomega_HMNHDCE_first_32mb.img of=/dev/sda bs=512 count=65536
Nun möchte ich mal normale MBR Partitionen mit fdisk erstellen und dann
mal sehen, ob man ArchLinux booten kann. Danach kann man ja mal
probieren erstmal nur die Kopie von uBoot zu überschreiben, siehe:
http://iomega.nas-central.org/wiki/Stock_Configuration_%28Home_Media_CE%29#.27Unused_space.27_.28first_32_MiB.29
Demnach gibt es jeweils von stage1, uBoot und uImage eine zweite Kopie,
bei Sektor 57088, 57208 und 58344...
Die kann man ja als erstes versuchen zu überschreiben...
Nun zu fdisk. Ich habe nun also das gemacht:
o create a new empty DOS partition table
n add a new partition
Partition number (1-4, default 1): 1
First sector (2048-2930277167, default 2048): +32M
Last sector, +sectors or +size{K,M,G} (65536-2930277167, default
2930277167): +20G
Dann sieht das so aus:
Der Start ist erstmal in Ordnung.
Der stage1 kann vom Prinzip her ja zum Testen auch erstmal drin bleiben
und nur U-Boot tauschen. Der muss nämlich wegen der RAM-Grössen-Angabe
geändert werden oder es klappt per Bootargs.
Ich nehme an den Abschnitt aus dem MBR ist das was ich nicht hatte.
Jens D. schrieb:> Dann sieht das so aus: Device Boot Start End Blocks Id
System
> /dev/sda1 65536 42008575 20971520 83 Linux>> Dürfte doch ok sein, oder?
Hm. Doch wie macht man weiter?
Erstellt man eine neue Parition schlägt fdisk als startsektor 2048 vor,
was natürlich nicht geht.
Ob es vielleicht Sinn macht eine erste ungenutzte fake Parition zu
erstellen?
/dev/sda1 2048 65535 31744 ?? ?????
/dev/sda2 65536 42008575 20971520 83 Linux
Doch welchen Typ nehmen? "0" == Empty oder "da" == Non-FS data ?
Nein 2048 darfst nicht nehmen. Einfach 42008576 eingeben als First
Sector.
Also ab der zweiten Partition einfach den Vorschlag übergehen und den
Ende-Sektor der letzten Partition + 1 eingeben.
Jens D. schrieb:> Doch wenn man immer bei "Start" +1 vom letzten "End" nimmt, hat man dann> sicher immer "gerade" Sektoren (von wegen 4096K pro Sektor) ???
Teile einfach durch 8 dann weist du es.
Die Sektoren sind zwar nur 4kB = 4096 Byte aber das ist auf der
Festplatte. Das Thema des Alignments kommt daher, dass Dateisysteme auch
in Blöcken denken, die grösser als ein Sektor sind. Und wenn man diese
auf die 4kB Sektoren der Platte abstimmt, dann gibt es maximale
Leistungsfähigkeit.
Anmerkung: Ich habe mal versucht, ein Partitionierskript zu bauen mit
Hilfe von parted. Die erste Partition definitiv in Reichweite des
U-Boot.
parted ist aber beim Original system und auch nicht beim ArchLinux out
of the box dabei... Kann man bei archlinux natürlich nach installieren
;)
Tja, schade... Nach dem ich fdisk gemacht habe, startet uBoot nicht mehr
von Platte :(
Wie kann man prüfen, ob die richtigen Daten an der richtigen Stelle noch
liegen? Bzw. Wie kann man das dd von iomega_HMNHDCE_first_32mb.img so
abändern, das die Partitionstabelle nicht wieder überschreiben werden?
Würde ein seek=1 reichen?
Gut, ich kann eine Sicherung anlegen, mit:
> dd if=/dev/sda of=mbr_sicherung bs=512 count=1
Dann:
> dd if=iomega_HMNHDCE_first_32mb.img of=/dev/sda bs=512 count=65536
und zurück spielen, mit:
> dd if=mbr_sicherung of=/dev/sda bs=512 count=1
Jens D. schrieb:> Es geht!!!
Jippie! Und gleich bis zum U-Boot-Prompt, wie ich vermutet hatte. Ihr
könnt das ..._first_32MB-Image verkleinern, indem ihr die kernel images
am ende abschneidet.
Ein Tipp noch: Ich hab ewig Zeit damit verplempert, nach dem
Partitionieren immer wieder eine unbootbare Platte zu haben. Der
Perl-Abschnitt in WHSE'S Skript ist wichtig. Irgendwas um den MBR herum
ist auch wichtig - ich hab das aber nicht genau eingrenzen können, bevor
mir die Energie ausging. Nehmt zum Partitionieren parted oder sgdisk und
macht eine GPT drauf - dann interessiert der MBR nicht.
Ich hab mich hier wegen akutem schlechten Gewissen eingeklinkt, weil ich
nicht mehr genug Antrieb hatte, den Iomega-HMNHDCE-Prozess zu
dokumentieren. Das ist aber notwendig, um die User-Basis für ArchLinux
auf diesem SoC groß genug zu bekommen, damit genug Motivation für die
Anpassung neuer Kernels entsteht. PLX wird uns da im Stich lassen.
Ciao,
solo
Sven B. schrieb:> Mir ist an dem Skript von WarheadsSE aufgefallen, dass er ein paar Bytes> des MBR schreibt. Ich habe den ersten Sektor mal mit eingepflegt.
Das könnte der Grund sein, warum das bei mir nun nicht mehr klappt!
Kenne mich leider nicht mit perl aus. Weiß also nicht was da genau
passiert. Auf der anderen Seite, könnte man das irgendwo machen, wo perl
installiert ist und dann per dd in einer Datei schreiben und gut...
Eigentlich haben wir die Daten ja in iomega_HMNHDCE_first_32mb.img
Wenn die Beispiele bei
http://wiki.ubuntuusers.de/shell/dd#MBR-Boot-Loader-und-Partitionstabelle-sichern
stimmen, ist der MBR 446 Bytes groß, danach kommt die
Partitionstabelle...
Ich teste das mal so:
eigene MBR + Partitionstabelle sichern:
> dd if=/dev/sda of=ersten_512_bytes bs=512 count=1
Dann:
> dd if=iomega_HMNHDCE_first_32mb.img of=/dev/sda bs=512 count=65536
Original sichern:
> dd if=/dev/sda of=nur_mbr bs=446 count=1
eigene MBR + Partitionstabelle zurück:
> dd if=mbr_sicherung of=/dev/sda bs=512 count=1
nur MBR aus iomega_HMNHDCE zurück:
> dd if=nur_mbr of=/dev/sda bs=446 count=1
solo schrieb:> Das ist aber notwendig, um die User-Basis für ArchLinux> auf diesem SoC groß genug zu bekommen, damit genug Motivation für die> Anpassung neuer Kernels entsteht. PLX wird uns da im Stich lassen.
Darum bin ich ja froh, dass wir zumindest von dem Geräteherstellern die
an die Kunden verkaufen den Source vom Kernel geben müssen.
Wir haben ja mittlerweile von Cloud Engines, Iomega und Medion
Kernel-Sourcen bekommen, da haben wir auf jeden Fall genügend Quellen.
Allerdings beim Kernel-Config durchschauen beim Medion-Kernel. Da hab
ich gerade gedacht mich tritt ein Pferd als ich die einkompilierten
Joystick-Treiber gesehen habe. Joystick am NAS mal ehrlich.
Jens D. schrieb:> Kenne mich leider nicht mit perl aus. Weiß also nicht was da genau> passiert. Auf der anderen Seite, könnte man das irgendwo machen, wo perl> installiert ist und dann per dd in einer Datei schreiben und gut...
Nimm das mbr.bin aus dem Repo von mir.
https://github.com/ft-/NAS7820-Tools/sataboot.
Das sind 512 Byte aber kannst ja auch "dd if=mbr.bin of=/dev/sda
count=446 bs=1" schreiben. Hatte ja gesagt, dass ich das Perl-Skript in
ein Binary umgewandelt habe.
Jens D. schrieb:> Ich teste das mal so:
Das ist es! Nun kommt wieder der iomega uBoot zum Vorscheinen.
Allerdings bringt ext2ls hier auch nichts :(
Außerdem kann ich den Kernel per TFTP nicht ganz booten:
http://pastie.org/3092786 (Der normalerweise aber klappt)
Mit dem Kernel aus iomega_HMNHDCE_first_32mb.img will es auch nicht:
1
...
2
[ 2.300000] mice: PS/2 mouse device common for all mice
3
[ 2.300000] md: linear personality registered for level -1
4
[ 2.300000] md: raid0 personality registered for level 0
5
[ 2.300000] md: raid1 personality registered for level 1
Problem ist der Iomega U-Boot setzt eine zu hohe RAM-Grösse. Somit
schlägt ein Booten zwangsläufig fehl, weil der Kernel die RAM-Grösse
nicht selbst bestimmt.
ext2ls funktioniert bei deiner 20GB Partition nicht, weil der U-Boot im
ext2 Lese-Code nur bis 4GB adressieren kann.
Ich habe zum makepartitions.sh jetzt mal auch ein parted gelegt. Benutzt
nur libs die auch im USB-Spezialboot verfügbar sind.
Schreib mal in die bootargs "mem=128M" dazu.
Sven B. schrieb:> Problem ist der Iomega U-Boot setzt eine zu hohe RAM-Grösse. Somit> schlägt ein Booten zwangsläufig fehl, weil der Kernel die RAM-Grösse> nicht selbst bestimmt.
Stimmt. Dann sind wir wieder an der gleichen Stelle, das wir ein
funktionierenden uBoot brauchen :(
Sven B. schrieb:> ext2ls funktioniert bei deiner 20GB Partition nicht, weil der U-Boot im> ext2 Lese-Code nur bis 4GB adressieren kann.
Ah, ok. Das wäre bei mir auch der Fall.
Wenn wir also bei einem Kernel Update nicht per dd nach /dev/sda
schreiben wollen, dann sollten wir eine erste Partition erstellen, die
nur für den Kernel ist. Vielleicht eine kleine ext3 Partition, die wir
nach /boot mounten?
Ich für meinen Teil, verschiebe weitere Tests auf nächstes Jahr ;)
Jens D. schrieb:> Wenn wir also bei einem Kernel Update nicht per dd nach /dev/sda> schreiben wollen, dann sollten wir eine erste Partition erstellen, die> nur für den Kernel ist. Vielleicht eine kleine ext3 Partition, die wir> nach /boot mounten?
Davon rede ich doch die ganze Zeit, irgendwas kleineres. Entweder eine
4GB Partition oder nur eine für den Kernel und ein paar bedeutsame
Dateien wie initrd.
@all
Ich versuche gerade mal, ob der Medion-Kernel nicht zu verhackt ist.
Ansonsten werde ich mir mal den Iomega-Source (gleiche Kernel-Version)
vornehmen und schauen was fehlt.
@Jens D.
Für die meisten wird das, was jetzt zur Verfügung steht, ausreichen. Ich
bin nur neugierig, was da noch so umtriebiges geschehen ist. Man weiss
ja nie wann man die Firmware wieder mal zu Gesicht bekommt.
Danach werd ich auch schauen, was ich wirklich auf Dauer haben will.
Ein U-Boot könnte man auch erstmal von WarheadsSE auf die Platte
schreiben, dann haben wir einen passenden U-Boot auf der Platte.
Schau ins Repo bei mir da liegt ein u-boot von WarheadsSE, dass zum
Medion NAS passen wird, ist von WarheadsSE's PogoPlugPro
ArchLinux-Anpassungen.
(PogoPlugPro 128MB, Medion NAS 128MB)
Alles weitere ist nur Gimmick und muss nun mal nicht von allen gemacht
werden. (neuerer U-Boot usw.)
Ich hab gleich nochmal ein update-uboot.sh Skript gebaut.
Medion Kernel lässt sich noch gut entschlacken. Medion-Image ca. 5MB mit
initrd drin. Angepasstes Image ca. 1,8MB. Für ein initrd Boot ideal.
Vielleicht baue ich ja ein pivot_root System mit ext2 o. ext3 Partition
als Start-Partition, dass wär mal einfacher zu warten als jedes initrd.
Ich habe mir glaube heute das NAS zerschossen. Gibt es eine Möglichkeit
die alte (neue) Firmware per USB draufzuspielen? Also ich habe es mit
der NSA210 Firmware probiert (und natürlich das check file geändert) und
da bleibt er zumindest bei einem blinken der blauen LED stehen. Wenn ich
gar nicht den stick reinmache, also normal boote, kommt er bis nach der
Initialisierung vom USB und dann wird die blaue LED rot. In diesen
Zustand bleibt er dann...
Den iomega-Kernel hab ich jetzt seit Wochen mit Arch laufen. Ich hänge
noch die lib/modules zum reinkopieren ins rootfs an. Das nur, falls er
mit dem auf 128MB korrigierten Startparametern bei euch bootet und ihr
Verwendung dafür habt. Die LED funktionieren nicht.
Das ist vorerst alles, was ich für euch tun kann. Das wichtigste ist
imho jetzt, einen aktuellen 3.1er Kernel zum Laufen zu bringen. Dann
dürfen wir uns noch lange über aktuelle Software auf unseren Kisten
freuen. Wenn da jemand WHSE und redsquare unterstützen kann... imho
wichtiger als die u-boot- und stage1-Spielereien.
@Sven B., den Unermüdlichen
Vielen Dank für deine Skripterei. Das ist das, was ich nicht gut kann.
Ich werde das auf dem iomega testen und vielleicht kriegen wir eine
Anleitung vom Stecken eines präparierten USB-Sticks am Neugerät bis zum
laufenden ArchLinux hin.
Ciao,
solo
Tim Friedrich schrieb:> Ich habe mir glaube heute das NAS zerschossen. Gibt es eine Möglichkeit> die alte (neue) Firmware per USB draufzuspielen? Also ich habe es mit> der NSA210 Firmware probiert (und natürlich das check file geändert) und> da bleibt er zumindest bei einem blinken der blauen LED stehen. Wenn ich> gar nicht den stick reinmache, also normal boote, kommt er bis nach der> Initialisierung vom USB und dann wird die blaue LED rot. In diesen> Zustand bleibt er dann...Wenn es wirklich die Firmware aufgespielt hat
NSA210 Firmware ist die falsche Firmare. Da hat man Glück wenns
überhaupt noch irgendwie bootet.
Die einzige Recovery die wir jetzt noch im Petto haben, ist die
Festplatte ausbauen und an Rechner hängen und dann mit Kernel usw.
initialisieren.
Ein Recovery-Boot für die Medion Firmware hat noch keiner geschrieben.
Wäre aber möglich.
ACHTUNG an alle (Fehlinformierten)! Medion NAS != NSA210, da
unterschiedliche Hardware.
Das Medion NAS besitzt keine Firmware Update Möglichkeit per USB, die
wurde glücklicherweise auskommentiert.
Wenn es das nicht getan hat
Vielleicht kommst ja noch per telnet dran, denn wenn es nur die
Festplatte ist, dann heisst es einfach Partitionen löschen. Das wurde
schon mehrfach geübt.
solo schrieb:> Vielen Dank für deine Skripterei. Das ist das, was ich nicht gut kann.> Ich werde das auf dem iomega testen und vielleicht kriegen wir eine> Anleitung vom Stecken eines präparierten USB-Sticks am Neugerät bis zum> laufenden ArchLinux hin.
Genauso denke ich auch, weil das schon absolut sicher ist, dass zwar die
Daten weg sein werden aber wenigstens kein Brick entsteht.
solo schrieb:> Den iomega-Kernel hab ich jetzt seit Wochen mit Arch laufen. Ich hänge> noch die lib/modules zum reinkopieren ins rootfs an. Das nur, falls er> mit dem auf 128MB korrigierten Startparametern bei euch bootet und ihr> Verwendung dafür habt. Die LED funktionieren nicht.
Da ich gerade mit dem Medion-Kernel rumgespielt habe und jedes Mal in
irgendwelche wilden Hacks geraten bin, werde ich mir wohl entweder den
2.6.31.14 vom HMNDCE oder den 3.1 heranziehen und da den LED-Kram für
rausziehen und in ordentlicher Form integrieren.
@solo: Ist zumindest der 3.1 Kernel für PLX7820 gemäss GPL-Bedingungen
im Source Code verfügbar. Der Kernel für PLX7820 im ArchLinux ARM sollte
es nämlich nach GPL eigentlich auch sein. NDAs werden von der GPL nicht
zugelassen.
Tim Friedrich:
Du kannst zum Festplatten Löschen folgendes auf den Stick packen. Dann
kannst das NAS nach Anleitung neu einrichten, wenn nur die Daten auf der
Platte vom Problem betroffen sind.
https://github.com/ft-/NAS7820-Tools und dort killpartusbstick
Wichtiger HinweisACHTUNG Nicht bei einem funktionsfähigen Medion NAS verwenden. Es wird
die Festplatte sang und klang los von allen Daten befreien (d.h.
löschen).
Stick mit besagtem Inhalt nicht am NAS stecken lassen, ansonsten wird
beim nächsten Neustart wieder gelöscht. Am besten den Stick nach
erfolgreicher Benutzung gut wegschliessen oder leeren. Es ist ein Medion
NAS HDD Clear.
das mit dem Löschen werde ich mal versuchen..aber ich glaube ich habe am
chip rumgespielt..also per telnet...und ich dabei das sysdisk.img
gelöscht...daher muss ich glaube ne neue firmware draufspielen. ich
könnte also nicht mit startscript die neue firmware draufspielen?
Das bräuchte ein Recovery-Image mit Flasher auf Platte. Das müsste
erstmal gebaut werden.
Das erinnert mich gerade irgendwie an die Leute, die bei Windows NT und
neuer NTLDR löschen, weil sie die Platte aufräumen wollen. Und dann
verzweifelt bei jemanden anrufen, warum der Rechner am nächsten Morgen
nicht mehr startet.
Ich glaube das wird nur jetzt gerade nix, weil alle im Bett sind, die in
der Nähe ihres Medion NAS sind.
Es muss schon dass zur Firmware passende sein, irgendwas anderes geht da
nicht.
Oder hast etwa gemeint die NSA210 Firmware muss da drauf geschrieben
werden.
Wieso hast das sysdisk.img gespeichert? Und was hast nach dem Speichern
davon gemacht? gelöscht oder mit was anderem überschrieben.
Das Problem wird nicht der Pfad sein, sondern dass einiges nicht
eingebunden ist.
naja nicht ich habe gemacht sondern jmd anderes...aber egal.
Also wir wollten das sysdisk.img überschreiben..also mit einer
angepassten Version. Ging nicht. Da wurde es gelöscht aber vorher ein
backup auf meinen PC gezogen. Nach den löschen stellten wir aber fest
das ein link auf sysdisk.img lag. Das heißt speicherplatz konnte nicht
freigemacht werden. Dieser war aber nur begrenzt an der stelle (glaube
80mb oder so). Naja dann haben wir noch ewig rumprobiert und
letztendlich neugestartet. Tja und diese Datei wird jetzt vom System
natürlich gesucht..vergebens..
Hast Glück
Ich habe gerade ein Skript nach dem Source Archiv zusammengebaut.
reinstallsysdiskstick wird ein sysdisk.img wieder ins Dateisystem legen.
sysdisk.img muss explizit mit drauf.
Wichtiger HinweisACHTUNG nur verwenden, wenn das NAS nicht korrekt startet. Nicht mit
einem sysdisk.img aus undefinierter Quelle verwenden (nur Medion NAS)
genau
ich konnte es leider nicht selber testen, aber wenns klappt dann wird
dein NAS durchstarten. Aber 10-15min so lange wirds wohl dauern bis es
installiert ist. Oder warte bis ich noch eine kleine Änderung am Skript
gemacht habe.
schaltet gleich auf rot...klappt das so mit "cp /sysdisk.img /sysdisk "
weil es bei den anderen usb_key_func.sh meist so da steht:
/mnt/parnerkey/nsa220_fw/ras.bin ...also das ist jetzt von der
firmware..das hatte ich mir nur mal angeschaut...
_______________________
nicht probieren;-) für alle anderen
ich glaube da hilft nur noch Recovery von SATA Platte aus, weil das mit
der Firmware von den Zyxel Geräten alles nur noch verschlimmert hat.
Aber das baue ich jetzt nicht mehr zusammen.
Ich hoffe doch, dass es bei dir auch um ein Medion NAS geht.
Das usb_key_func.sh ist genau für diesen Zweck erstellt, das kann gar
nichts anderes als ein sysdisk.img wieder auf das Dateisystem zu
schieben.
Ich hoffe die Zeile davor ist dir auch aufgefallen.
jap es geht um das Medion NAS...alles klar..naja es schiebt halt nix,
sondern landet gleich bei der der roten LED (klar wird es kurz
initialisiert...aber da wird nix verschoben)
Danke trotzdem für deine Mühen..vll schauste ja nochmal später drüber;-)
würde mich freuen
Zu usb_key_func.sh: Ich hatte noch die Idee, das man es ein wenig
generischer macht. d.h. das man nicht immer die Checksumme anpassen muß.
Könnte man ganz einfach machen, in dem man in der usb_key_func.sh nicht
weiter macht als externe Skripte zu starten. Vielleicht in einer
Reihenfolge wie die Dateinamen sortiert sind oder so.
Dann kann man recht leicht eine Kopie davon machen, eigenen Skript dazu
packen und fertig.
Zum Thema Recovery: Es wäre nicht schlecht, wenn man ein Image, ähnlich
dem iomega_HMNHDCE_first_32mb.img macht, welches ein abgespecktes
Recovery Linux beinhaltet. Vielleicht mit separaten vorgefertigten
Partitionstabellen oder nicht.
Hat man sein System zerschossen, kann man das Image per dd auf die
Platte packen und dann sollte man alle Möglichkeiten haben, das System
neu auf zu setzten...
Sven B. schrieb:> Schau ins Repo bei mir da liegt ein u-boot von WarheadsSE, dass zum> Medion NAS passen wird, ist von WarheadsSE's PogoPlugPro> ArchLinux-Anpassungen.> (PogoPlugPro 128MB, Medion NAS 128MB)>> Alles weitere ist nur Gimmick und muss nun mal nicht von allen gemacht> werden. (neuerer U-Boot usw.)
Heißt das der ist schon jetzt nutzbar? Den hatte ich IMHO noch nicht
probiert. Aber wenn dieses uBoot das macht, dann ist ja alles ok!
Jens D. schrieb:> Heißt das der ist schon jetzt nutzbar? Den hatte ich IMHO noch nicht> probiert. Aber wenn dieses uBoot das macht, dann ist ja alles ok!
Das Skript müsste nutzbar sein, ich hatte ja nur den MBR Teil nicht
gehabt.
Jens D. schrieb:> Zum Thema Recovery: Es wäre nicht schlecht, wenn man ein Image, ähnlich> dem iomega_HMNHDCE_first_32mb.img macht, welches ein abgespecktes> Recovery Linux beinhaltet. Vielleicht mit separaten vorgefertigten> Partitionstabellen oder nicht.
Braucht doch nur einen U-Boot mit speziellen Environment ;)
Der kann soweit ich weiss auch selbst flashen. Muss man nur ins
Environment skripten.
Und Partitionen per Raw Write aus U-Boot löschen.
Den Rest kann ja dann die Original-Firmware machen.
Ich tippe so kommt die Firmware auch initial drauf. Die Spuren sieht man
nur nicht mehr weil die Daten geplättet werden auf der Platte.
Für ArchLinux wäre es etwas anders, da wäre es eher ein
Installations-Image.
Man könnte die Recovery-Funktion gleich mit einbauen als eine kleine
Partition, wenn das Hauptsystem nicht startet, dann rein ins Recovery.
;)
Jens D. schrieb:> Zu usb_key_func.sh: Ich hatte noch die Idee, das man es ein wenig> generischer macht. d.h. das man nicht immer die Checksumme anpassen muß.> Könnte man ganz einfach machen, in dem man in der usb_key_func.sh nicht> weiter macht als externe Skripte zu starten. Vielleicht in einer> Reihenfolge wie die Dateinamen sortiert sind oder so.> Dann kann man recht leicht eine Kopie davon machen, eigenen Skript dazu> packen und fertig.
zum Beispiel so:
usb_key_func.sh
1
#!/bin/sh
2
3
exec /mnt/parnerkey/do.sh
Dann wird das usb_key_func.sh ausführungstechnisch ersetzt und man
kodiert im do.sh so wie man es im usb_key_func.sh machen würde.
Habs mal genauso bei mir unter usb_key_func_do_sh/ angelegt.
Sven B. schrieb:> @solo: Ist zumindest der 3.1 Kernel für PLX7820 gemäss GPL-Bedingungen> im Source Code verfügbar. Der Kernel für PLX7820 im ArchLinux ARM sollte> es nämlich nach GPL eigentlich auch sein. NDAs werden von der GPL nicht> zugelassen.
Bin mir nicht sicher, ob du das als Frage gemeint hast, ich interpretier
es mal so. Vom NDA betroffen ist nur der stage1-Quelltext, der dann wohl
keine GPL-Bestandteile hat. Wie gesagt glaube ich, dass Medion
geschlampert hat und denen der stage1-Code in ihr Quelltext-Paket
durchgerutscht ist. Gut für uns, schlecht für Medion, die könnten
deswegen Ärger kriegen.
Einen 3.1-Kernel gibt es von PLX nicht. Seit dem 2.6.31 haben die selber
nichts mehr gemacht. Das ist die typische Hit-and-Run-Taktik
zweitklassiger ARM-Buden, die Torvalds schon oft kritisiert hat. Die
konstruieren ein SoC, hacken in eine x-beliebige Kernel-Version die
Unterstützung dafür rein, verkaufen das Ding ein paar Jahre und
vergessen dann alles darüber. Das wird mit dem 7820 genauso werden.
Iomega, Medion etc. können doch noch ein paar Jahre NAS'en mit dem alten
Kernel ausliefern. Die Kette reißt erst dann, wenn sie wegen dem alten
Kernel kein aktuelles Debian mehr nehmen können, deswegen die aktuellen
Mediensachen (Twonky etc.) nicht mehr laufen, deswegen die aktuellen
Fernseher nicht mehr korrekt bestreamt werden etc. Dann - und erst dann
- wird der Murks für den Kunden sichtbar und verkaufsschädigend.
Dann gibts von PLX den 7920 mit SDK auf 3.1er-Kernel-Basis und das Spiel
geht von vorne los. Die notwendige Qualität, dass das Ganze mainline
geht und dort gepflegt werden kann, wird nie erreicht. Die
Kirkwood-Plattform zeigt wie's gehen kann. Aber Marvell ist auch eine
andere Hausnummer als PLX.
Deshalb ist die Community höchstwahrscheinlich auf sich gestellt, was
neue Kernel betrifft. In dem iomega-Quellcode-Paket sind die Patches
separat drin. Ich glaube nicht, dass das im SDK direkt von PLX groß
anders aussieht. Sind etwa 3MB, von denen aber nicht alles für den 7820
relevant ist, soweit ich das überflogen habe. Die müsste man durchgehen
und in einen 3.1er reinpatchen, was mal mehr, mal weniger Anpassungen
benötigt. Die Arch-Leute haben wohl den größten Teil für u.a. USB, SATA
und Netzwerk schon geschafft. Ich selber kann mangels Kenntnissen nicht
helfen. Das wäre für mich ein Puzzlespiel nur mit der Form der Steine,
nicht ihrer Beschriftung.
Ciao,
solo
solo schrieb:> Einen 3.1-Kernel gibt es von PLX nicht. Seit dem 2.6.31 haben die selber> nichts mehr gemacht.
Nein, meine Frage zielte auf ArchLinux ARM ab, da ja von dort die
Binaries kommen.
Kenne ich allerdings auch von Geräteherstellern die Mentalität. Gerade
bei DSL-Routern auch gern anzutreffen, da wird dann eine ewig alte
Kernel-Version immer weiter verwendet. Hab da auch noch ein Gerät was
ich noch vor mir hab, dass Zeug mal auseinanderzunehmen.
solo schrieb:> Vom NDA betroffen ist nur der stage1-Quelltext, der dann wohl> keine GPL-Bestandteile hat. Wie gesagt glaube ich, dass Medion> geschlampert hat und denen der stage1-Code in ihr Quelltext-Paket> durchgerutscht ist. Gut für uns, schlecht für Medion, die könnten> deswegen Ärger kriegen.
Wegen der Kommentare auch ziemlich eindeutig. Alles weisst auf OXNAS
hin. Ist aber nicht der erste Source der jemals rausgerutscht ist.
Aber ein wirkliches Kunstwerk ist es nicht, ca. 80% könnte man mittels
GPL-Sourcen herstellen.
Ich habe mir gerade die Mühe gemacht mal aus einem NAND-Backup ein
HDD-Recovery-Image-Builder zu bauen, Die MAC-Adresse muss halt
eingetragen werden.
Vielleicht mag das mal ausprobieren, am besten auf kaputtgeschriebenen
NAND.
ACHTUNG
Am laufenden NAS nicht ausprobieren, es sei denn man ist zum Recovery
selbst in der Lage.
Jens D. schrieb:> Es geht!!!
Tolle Sache! 8)
Da ich mein NAS allerdings nicht verlieren will, warte ich lieber auf
die Sicherheitsfreigabe von euch :D Wenn es dann daran geht, die
Firmware anzupassen, bin ich wieder dabei ;)
solo schrieb:> Deshalb ist die Community höchstwahrscheinlich auf sich gestellt, was> neue Kernel betrifft. In dem iomega-Quellcode-Paket sind die Patches> separat drin. Ich glaube nicht, dass das im SDK direkt von PLX groß> anders aussieht. Sind etwa 3MB, von denen aber nicht alles für den 7820> relevant ist, soweit ich das überflogen habe. Die müsste man durchgehen> und in einen 3.1er reinpatchen, was mal mehr, mal weniger Anpassungen> benötigt. Die Arch-Leute haben wohl den größten Teil für u.a. USB, SATA> und Netzwerk schon geschafft. Ich selber kann mangels Kenntnissen nicht> helfen. Das wäre für mich ein Puzzlespiel nur mit der Form der Steine,> nicht ihrer Beschriftung.
Das nehme ich auch an. Deswegen ist es ja schon gut, dass wir
vollständige Kernel-Sourcen haben.
Beim U-Boot habe ich auch mal eine neuere Version schon
zusammengestellt, die will ich aber auch erst testen. Und ist ja für
eine grundsätzliche Inbetriebnahme ja auch erstmal nicht bedeutend.
Allerdings für später interessant.
Der USB-Code war ziemlich einfach zu übernehmen, war ja nur ein bisschen
Init-Code. Beim SATA und Ethernet ist es schon etwas komplexer. Habe den
Ethernet-Code vom U-Boot 1.1.2 halt vollständig auf die neue
Infrastruktur umgebaut (CONFIG_NET_MULTI für die U-Boot-Bewanderten).
Ähnliches habe ich beim SATA gemacht.
Gerade der SATA-Code ist beim U-Boot 1.1.2 auch ein ziemliches
Hackstück.
Johann B. schrieb:> Da ich mein NAS allerdings nicht verlieren will, warte ich lieber auf> die Sicherheitsfreigabe von euch :D Wenn es dann daran geht, die> Firmware anzupassen, bin ich wieder dabei ;)
Wir haben ja einen der sich, dass Flash kaputtgeschrieben hat.
solo schrieb:> Die> Kirkwood-Plattform zeigt wie's gehen kann. Aber Marvell ist auch eine> andere Hausnummer als PLX.
Sollte man also bei zukünftigen Anschaffungen darauf achten? Macht wohl
Sinn, was?
Jens D. schrieb:> Sollte man also bei zukünftigen Anschaffungen darauf achten? Macht wohl> Sinn, was?
Zumindest sollte man darauf achten, dass man die relevanten Sourcen in
die Finger bekommt.
@solo:
Das Recovery HDD-Image liesse sich auch für PogoPlugPro adaptieren. Aber
da habe ich kein Flash-Backup für.
@all:
Das MedionNAS Recovery soll nur die Original-Firmware wiederherstellen.
solo schrieb:> Bin mir nicht sicher, ob du das als Frage gemeint hast, ich interpretier> es mal so. Vom NDA betroffen ist nur der stage1-Quelltext, der dann wohl> keine GPL-Bestandteile hat. Wie gesagt glaube ich, dass Medion> geschlampert hat und denen der stage1-Code in ihr Quelltext-Paket> durchgerutscht ist. Gut für uns, schlecht für Medion, die könnten> deswegen Ärger kriegen.>> Einen 3.1-Kernel gibt es von PLX nicht. Seit dem 2.6.31 haben die selber> nichts mehr gemacht. Das ist die typische Hit-and-Run-Taktik> zweitklassiger ARM-Buden, die Torvalds schon oft kritisiert hat. Die> konstruieren ein SoC, hacken in eine x-beliebige Kernel-Version die> Unterstützung dafür rein, verkaufen das Ding ein paar Jahre und> vergessen dann alles darüber. Das wird mit dem 7820 genauso werden.> Iomega, Medion etc. können doch noch ein paar Jahre NAS'en mit dem alten> Kernel ausliefern. Die Kette reißt erst dann, wenn sie wegen dem alten> Kernel kein aktuelles Debian mehr nehmen können, deswegen die aktuellen> Mediensachen (Twonky etc.) nicht mehr laufen, deswegen die aktuellen> Fernseher nicht mehr korrekt bestreamt werden etc. Dann - und erst dann> - wird der Murks für den Kunden sichtbar und verkaufsschädigend.>> Dann gibts von PLX den 7920 mit SDK auf 3.1er-Kernel-Basis und das Spiel> geht von vorne los. Die notwendige Qualität, dass das Ganze mainline> geht und dort gepflegt werden kann, wird nie erreicht. Die> Kirkwood-Plattform zeigt wie's gehen kann. Aber Marvell ist auch eine> andere Hausnummer als PLX.>> Deshalb ist die Community höchstwahrscheinlich auf sich gestellt, was> neue Kernel betrifft. In dem iomega-Quellcode-Paket sind die Patches> separat drin. Ich glaube nicht, dass das im SDK direkt von PLX groß> anders aussieht. Sind etwa 3MB, von denen aber nicht alles für den 7820> relevant ist, soweit ich das überflogen habe. Die müsste man durchgehen> und in einen 3.1er reinpatchen, was mal mehr, mal weniger Anpassungen> benötigt. Die Arch-Leute haben wohl den größten Teil für u.a. USB, SATA> und Netzwerk schon geschafft. Ich selber kann mangels Kenntnissen nicht> helfen. Das wäre für mich ein Puzzlespiel nur mit der Form der Steine,> nicht ihrer Beschriftung.>> Ciao,>> solo
Da hat der Entwickler vom BSP geschlampt und einfach den kompletten
Source vom SVN ausgecheckt.
Was ja eigentlich ja schon für die Kernel Sourcen seltsam ist, bwz. wer
benutzt noch SVN als Repo ?
Das zweite Problem das die Sourcen betriff, das so wie es aussieht
niemals dran gedacht wurde diese Mainline zu bringen. Das sieht man an
Core USB, VFS und SATA Änderungen, auch ist die Abschaltung des zweiten
Kerns nicht in dem Platformteil gemacht wurden.
Und nicht nur Marvell, sondern auch Samsung ist ein gutes Beispiel
siehe
http://events.linuxfoundation.org/events/embedded-linux-conference-europe/dae
ElektromAn schrieb:> Da hat der Entwickler vom BSP geschlampt und einfach den kompletten> Source vom SVN ausgecheckt.
soll uns nur recht sein, sonst wäre es ja nicht so schön komplett. Auch
wenn der Source noch überarbeitungswürdig ist.
Ich hatte den SATA-Code jetzt mal doch durchgängiger analysiert und ich
glaube der Code im Medion-Kernel ist der aktuellere von den
SATA-Treibern, die wir haben.
ElektromAn schrieb:> Was ja eigentlich ja schon für die Kernel Sourcen seltsam ist, bwz. wer> benutzt noch SVN als Repo ?
Alle die für ein verteiltes Repository keine Notwendigkeit haben.
Deswegen ist es gar nicht so unüblich.
ElektromAn schrieb:> Das zweite Problem das die Sourcen betriff, das so wie es aussieht> niemals dran gedacht wurde diese Mainline zu bringen. Das sieht man an> Core USB, VFS und SATA Änderungen, auch ist die Abschaltung des zweiten> Kerns nicht in dem Platformteil gemacht wurden.
Dem kann ich nach Durchsicht nur zustimmen. Änderungen am VFS will ich
schon mal gar nicht haben. Ich möchte persönlich einen SATA-Treiber
haben, der wie die anderen auch aufgebaut ist.
Da ist aktuell im SATA-Treibercode eine Menge Mist drin, der da einfach
nichts dauerhaft zu suchen hat. (z.B. Error Injection)
Den SMP-Code will ich auch in Originalform sehen. Nicht dieses
herumgemurkste Zeug. Auch der USB-Code ist mir noch ein wenig zu sehr
Bastelwerk.
Ich hatte versucht, den Medion-Kernel zu modularisieren. Das kann man
aber praktisch durch die Bastelei darin nicht umsetzen.
Ich habe WarheadsSE kontaktiert wie der Stand vom 3.1 Kernel ist und
leider ist der SATA-Code aktuell unbrauchbar. Ich hab kein Problem damit
diesen komplett zu überarbeiten. Erstmal schaue ich aber, dass ich die
Zusammenhänge des SATA-Kerns verstehe. Und dann weiter.
Aktuell ist der Source Code von diesen Teilen im 2.6.31.x keine Freude,
da er praktisch von keinem ausserhalb PLX so richtig verstanden wird und
wie ja belegt scheint, hat PLX wohl auch keine wesentliche weitere
Pflege mehr daran betrieben (neuere Kernel). Also muss zur sinnvollen
Pflege erstmal der Source richtig aufgeräumt werden. Alles anderes -
denke ich - ist nur Leben auf Raten.
Mal davon abgesehen, dass der Code sich nicht an Richtlinien des
Mainline-Kernels orientiert hat.
Es gibt einige Hersteller, die es definitiv besser gemacht haben. In
einigen anderen Fällen hat die Community nachgeholfen und einen
aufgeräumten Source Code präsentiert (dank der GPL).
Einiges an PC-Hardware fällt mir dazu ein, aber die Liste bringt hier
jetzt nichts dem Thema.
Sven B. schrieb:> Den SMP-Code will ich auch in Originalform sehen. Nicht dieses> herumgemurkste Zeug. Auch der USB-Code ist mir noch ein wenig zu sehr> Bastelwerk.>> Ich hatte versucht, den Medion-Kernel zu modularisieren. Das kann man> aber praktisch durch die Bastelei darin nicht umsetzen.>> Ich habe WarheadsSE kontaktiert wie der Stand vom 3.1 Kernel ist und> leider ist der SATA-Code aktuell unbrauchbar. Ich hab kein Problem damit> diesen komplett zu überarbeiten. Erstmal schaue ich aber, dass ich die> Zusammenhänge des SATA-Kerns verstehe. Und dann weiter.
Ich glaube ich habe den USB Source gesäubert, muss dieses aber noch
testen.
Mit SATA und/oder Netzwerk kann ich noch nicht genaues sagen, da ich den
bl*den* LEON Chip und/oder die seltsamen DMAs nicht verstanden haben.
Auch ist beim SATA das mit dem "aktiven" RAID 0/1 im SATA device
seltsam. Es gab/gibt auch einen Modus ohne das bl*den* RAiD.
Ausserdem sind viele symbole noch von dem alten Design übernommen worden
ohne vorher zu prüfen ob diese jemals benutzt werden.
Hey Ihr Kernelprofis, das sieht ja ganz schön und langfristig viel
versprechend aus, was Ihr da vor habt, Respekt, da freue ich mich drauf!
Ich würde noch zu den nice to have Sachen hinzu fügen, RTC, HW
Monitoring (Temperatur und Fans) welche diese Platform noch unterstützen
sollen (ich denke über i2c). Hierfür gibt's auch schon Module, man kann
sie sogar bauen und laden, bloß brauchbar sind sie (noch) nicht. Ob das
gar nicht in der konkreten Medion Hardware aktiv oder ausgebaut ist,
oder einfach nur die derzeitigen Sourcen auch vermurkst sind, weiß ich
nicht.
Hier mal eine Aufzählung wo überall im Medion-Kernel was gebastelt
wurde.
* GIC (Generic Interrupt Controller) Code
** Interrupt Code
* SMP-Code
** CPU Init
* MMU-Handling
** Page Table Handling
** TLB Handling
* VFS-Code
* Netzwerk-Stack
Wobei ich dieses SATA-Direct-Read/Write-Zeugs für äussert kritisch
ansehe, da es eine Komplexität in den Code einfügt. Das hat den
Charakter von zwei Treibern an einen Controller, dass braucht
kompliziertes Handshake zwischen beidem und sorgt für Fehlerkategorien,
die es nur unübersichtlich machen.
Da sowieso alles über User Space und dann über zwei Context-Switches weg
muss, bringt diese Optimierung faktisch gar nichts. Insbesondere, da man
im User-Space dann Informationen über Dateien benötigt, die auch hier
wieder komplizierte Patches nötig machen. Das macht man meiner Meinung
nach anders. Ich frage mich nur, warum im Vanilla-Kernel soviel Arbeit
in einen NoCopy-Stack gesteckt wird. Und dass irgendwelche Leute sich
trotzdem irgendwas wildes eigenes ausdenken.
Das Stabilitätsproblem, warum nur ein Kern aktiv ist, überrascht mich da
immer weniger.
Der Code kann so gar nicht Mainline werden.
Meine "Lieblings-Datei": atomic_torture.c
"Atomare Folter" mal grob übersetzt.
Sven B. schrieb:> Ich hatte versucht, den Medion-Kernel zu modularisieren. Das kann man> aber praktisch durch die Bastelei darin nicht umsetzen.>> Ich habe WarheadsSE kontaktiert wie der Stand vom 3.1 Kernel ist und> leider ist der SATA-Code aktuell unbrauchbar. Ich hab kein Problem damit> diesen komplett zu überarbeiten. Erstmal schaue ich aber, dass ich die> Zusammenhänge des SATA-Kerns verstehe. Und dann weiter.>> Aktuell ist der Source Code von diesen Teilen im 2.6.31.x keine Freude,> da er praktisch von keinem ausserhalb PLX so richtig verstanden wird und> wie ja belegt scheint, hat PLX wohl auch keine wesentliche weitere> Pflege mehr daran betrieben (neuere Kernel). Also muss zur sinnvollen> Pflege erstmal der Source richtig aufgeräumt werden. Alles anderes -> denke ich - ist nur Leben auf Raten.
Was ich dabei nicht verstehe: Der alte 2.6er ArchLinuxARM Kernel läuft
doch. Läuft der nur, weil WarheadsSE die nötige Unterstützung
implementiert hat? Ist es nicht vernünftiger darauf aufzubauen, als auf
den Medion Kram?
Wäre noch zu prüfen, wie die Kernel von Iomega oder dem Level One
GNS-1001 aufgebaut sind. Vielleicht wurde da sauberer Gearbeitet?
Jens D. schrieb:> Was ich dabei nicht verstehe: Der alte 2.6er ArchLinuxARM Kernel läuft> doch. Läuft der nur, weil WarheadsSE die nötige Unterstützung> implementiert hat? Ist es nicht vernünftiger darauf aufzubauen, als auf> den Medion Kram?
der 2.6er Kernel läuft weil er auf diesen PLX-Sourcen/Patches aufbaut.
Und die sind in allen Varianten so verschroben implementiert. Deswegen
ist ja im ArchLinuxARM-Kernel die XFS-Unterstützung kaputtgepatcht von
PLX. Weil das noch die ältere Fassung ist.
Nur muss man dann auf alle Zeiten mit den Problemen leben, die die
besagte Version hat. Inklusive Sicherheitslöchern.
Ich benutze den Medion-Kernel lediglich um den SATA-Core zu verstehen
und dann zu wissen, was wirklich nötig ist.
Jens D. schrieb:> Wäre noch zu prüfen, wie die Kernel von Iomega oder dem Level One> GNS-1001 aufgebaut sind. Vielleicht wurde da sauberer Gearbeitet?
Die Kernel enthalten alle diesen abgedrehten Direct SATA-Kram. Wenn da
mal was schief geht, dann richtig.
Deswegen bekommen wir im Übrigen meiner Meinung nach auch diese Blockade
beim Gerät, weil Twonky Media dann keinen Zugriff bekommt und dann
eifrig Busy Waiting geschieht.
Mit dem Code wird das Blockade-Problem beim Draufladen grosser
Datenbestände nie gelöst werden.
Sven B. schrieb:> Jens D. schrieb:>> Was ich dabei nicht verstehe: Der alte 2.6er ArchLinuxARM Kernel läuft>> doch. Läuft der nur, weil WarheadsSE die nötige Unterstützung>> implementiert hat? Ist es nicht vernünftiger darauf aufzubauen, als auf>> den Medion Kram?>> der 2.6er Kernel läuft weil er auf diesen PLX-Sourcen/Patches aufbaut.> Und die sind in allen Varianten so verschroben implementiert. Deswegen> ist ja im ArchLinuxARM-Kernel die XFS-Unterstützung kaputtgepatcht von> PLX. Weil das noch die ältere Fassung ist.
Noch ein Problem: mit einem "alten" Kernel wirst Du nach und nach nicht
mehr aktuellere Firmware nutzen können, ganz konkretes aktuelles
Beispiel, mit der Version des Medion-Kernels kann man kein udev neuer
wie 164 nutzen, und die Liste kann jeden Monat länger werden, ein wildes
herumgematsche basierend auf den allrdings "lauffähigen" Sourcen führt
eher früher als später in die Sackgasse. Deswegen ist das einzig
Vernünftige das Vorhaben das ganze mainline-tauglich zu kriegen. So habe
ich das auch damals mit der orion5x Platform von Marvell erlebt als ich
die Linkstation Pro kaufte, da hatten die ersten Kernel-Hacker an den
releasten Sourcen auch nicht viel Gutes zu verlieren. Zum Glück hatte
danach Marvell selbst Leute dafür eingestellt, das ganze "richtig" zu
machen...
Lucian M. schrieb:> Hey Ihr Kernelprofis, das sieht ja ganz schön und langfristig viel> versprechend aus, was Ihr da vor habt, Respekt, da freue ich mich drauf!>> Ich würde noch zu den nice to have Sachen hinzu fügen, RTC, HW> Monitoring (Temperatur und Fans) welche diese Platform noch unterstützen> sollen (ich denke über i2c). Hierfür gibt's auch schon Module, man kann> sie sogar bauen und laden, bloß brauchbar sind sie (noch) nicht. Ob das> gar nicht in der konkreten Medion Hardware aktiv oder ausgebaut ist,> oder einfach nur die derzeitigen Sourcen auch vermurkst sind, weiß ich> nicht.
RTC ist bei der Medion BOX nicht vorhanden ...
Es fehlt einfach der Chip, das I2C (für RTC) über BitBang/GPIO (eine Art
Software I2C Schnittstelle) ist nebensächlich.
Das geht zum Teil auch bei anderen SoC so, z.B. für OutOfBand Signaling
für RGMII (Netzwerkport)
@Sven .B
Das SATA Direct Zeugs ist für die Optimierung von sendfile/readfile. Die
haben sogar ein Teil den VFS in den Treiber gepackt, um nicht die Daten
mehrmals im Speicher zu kopieren. Was nach meiner Meinung Blödsinn ist
wg. MMAP und auch wegen der Firewall, die schmeissen einfach die Pakete
auf den Port.
Das meiste frisst nach meiner Meinung der Copo (LEON) für TOE weg, da
dieser mit im internen Bus liegt. Bei Gemini (IB4220) liegt das auf
der MAC Schicht.
Hmm.
atomic_torture.c nett. Wurde wohl zum Testen des SoC benutzt.
Ich werde mir mal die SATA Sourcen von uBoot ansehen hoffentlich ist da
keine FW drin für den "internen" RAID Controller ...
Alles was innerhalb /arch/arm/ox820 ist sieht relativ "normal" aus,
jedenfalls wenn man die kruden Sachen weg lässt.
Die Patches im USB EHCI-HCD.c von seiten PLX sind auch völlig unnötig.
Nur der Init Code ist überhaupt nötig.
SATA im U-Boot hab ich mir schon angeschaut, wird ohne
Microcode-Firmware betrieben. Ist trotzdem ein ziemlicher Wust.
ElektromAn schrieb:> Das SATA Direct Zeugs ist für die Optimierung von sendfile/readfile. Die> haben sogar ein Teil den VFS in den Treiber gepackt, um nicht die Daten> mehrmals im Speicher zu kopieren. Was nach meiner Meinung Blödsinn ist> wg. MMAP und auch wegen der Firewall, die schmeissen einfach die Pakete> auf den Port.
MMAP wurde sogar abgeschaltet. Hab die Stelle schon gesehen.
Wegen den VFS-Patches wurden einige Dateisysteme kaputtgepatcht.
Ich versuche mich gerade daran, den ox820 sata code erstmal
umzuschreiben und ohne HWRAID zusammenzubauen.
Das Locking im Ursprungs-Code ist eine mittlere Katastrophe. Busy
Waiting überall wo man hinschaut. Das funktioniert dann vor allem so
"schön" auf Multi-Core Systemen. Da warten dann beide Kerne andauernd
aufeinander. Kein Wunder, dass die Kiste so warm wird bei Datentransfer.
Die CPU müsste eigentlich die meiste Zeit schlafen, was aber mit Busy
Waiting nicht geht.
ElektromAn schrieb:> RTC ist bei der Medion BOX nicht vorhanden ...> Es fehlt einfach der Chip, das I2C (für RTC) über BitBang/GPIO (eine Art> Software I2C Schnittstelle) ist nebensächlich.> Das geht zum Teil auch bei anderen SoC so, z.B. für OutOfBand Signaling> für RGMII (Netzwerkport)
Ich vermute mal, dass auf dem freigelassenen IC-Platz ein paar GPIOs
ankommen. Da könnt man schon was mit anfangen. RTC-Chips sind nicht
teuer.
Lucian M. schrieb:> So habe> ich das auch damals mit der orion5x Platform von Marvell erlebt als ich> die Linkstation Pro kaufte, da hatten die ersten Kernel-Hacker an den> releasten Sourcen auch nicht viel Gutes zu verlieren. Zum Glück hatte> danach Marvell selbst Leute dafür eingestellt, das ganze "richtig" zu> machen..
Marvell hat wenigstens ein paar Leute mit Stolz, die etwas richtig
machen wollen.
Lucian M. schrieb:> Noch ein Problem: mit einem "alten" Kernel wirst Du nach und nach nicht> mehr aktuellere Firmware nutzen können, ganz konkretes aktuelles> Beispiel, mit der Version des Medion-Kernels kann man kein udev neuer> wie 164 nutzen, und die Liste kann jeden Monat länger werden, ein wildes> herumgematsche basierend auf den allrdings "lauffähigen" Sourcen führt> eher früher als später in die Sackgasse.
Das denke ich auch.
Bei den Versionen mit den Basteleien bin ich auch vorsichtig,
wahrscheinlich werde ich den gesamten Datenbestand der Platte noch per
MD5 checken. Nachdem was ich im VFS-Code alles gesehen habe.
Sven B. schrieb:> Das SATA Direct Zeugs ist für die Optimierung von sendfile/readfile.
Bringt eigentlich nur richtig was bei Apache und FTP. Aber bei NFS
dürfte das ziemlich unsinnig sein, da solche Protokolle nicht wirklich
grosse Blöcke übertragen, da steckt dann soviel Overhead dazwischen,
dass es kaum was bringt. Selbst SMB hat noch einen Protokoll-Overhead
welches die Block-Übertragung auf maximal 64kB beschränkt.
Und dann kommt noch die gesamte TCP-State Machine dazu.
ElektromAn schrieb:> Arrggghhh ....>> PLX ist nicht der Hersteller vom SoC bzw. er hat diesen nur Designt ...>> SATA, DMA, USB (inkl. OTG) und Ethernet kommt von Synopsis.
Ist mir auch schon aufgefallen.
PLX hat im Grunde viele Bauteile nur zusammengestellt.
ARM 11MPCore
AMBA-Bus
SATA ist Synopsis
DMA ebenfalls
USB scheint auch von extern zu sein
Ethernet ähnlich
Alle diese Teile kommen über den Weg von Oxford Semiconductors Ltd. in
den Bestand von PLX. Oxford Semiconductors Ltd. scheint ein
Firmen-Einkauf seitens PLX zu sein.
Aber das ist eigentlich nicht so ungewöhnlich. Gibt sogenannte
IP-Core-Lizenzen.
Im Übrigen viele Firmen designen zwar ASICs aber lassen diese bei einem
der Chip-Fabriken fertigen. Ist gängige Praxis.
Nur ganz wenige Chip-designende Firmen haben eine eigene Chip-Fabrik
(z.B. Intel, NEC, Samsung, AMD usw.)
Wenn ich mich recht entsinne, designt Synopsis auch nur Komponenten.
@Lucian M.
habe gerade das geforkte Repo bei dir entdeckt. Ich habe bereits einiges
an Source zusammengestellt im U-Boot 2011.09. Insbesondere habe ich auch
dabei festgestellt, dass vielfach Code nicht einfach nur zu portieren
ist. Ich habe ja schon oben weiter mal die zusammengefassten Fakten zu
diesem neu zusammengestellten Code aufgelistet. Das Portieren von 1.1.2
auf 2011.09 ist recht umfangreich: Wegfall von config.mk. Neu ist die
Steuerung komplett über ein config.h.
Ich habe sowohl am NAND-Code Dinge angepasst als auch am SATA-Code.
Wobei der SATA-Code erstmal ein direkter Port ist (von ide -> sata
Kommando). Wohingegen der Ethernet-Code ein vollständiger Port auf
CONFIG_NET_MULTI ist. Ebenfalls habe ich den USB-Init-Code aus dem
Kernel in den U-Boot eingebaut. Im Moment würde ich es allerdings nur
denen besser zum Testen geben, die auch in der Lage sind mit eventuellen
Fehlern klarzukommen.
Ein frohes neues Jahr zusammen!
Sven B. schrieb:> habe gerade das geforkte Repo bei dir entdeckt. Ich habe bereits einiges> an Source zusammengestellt im U-Boot 2011.09.
Ja, da wollte ich auch mal 'reingucken, war noch bevor Du hier sagtest
daß Du mit der aktuellen Version was machst. Da war mir schon längst
klar, und Michael Kebe auch, daß es für uns gar nicht so einfach sein
würde... Also werde ich zumindest mit jenem Fork nichts weiter machen...
@Lucian M.
Den SATA-Code will ich noch aufräumen, aber erstmal muss er auch
funktionieren.
Das war auch schon ein ziemlicher Umbau von config.mk auf config.h. Ich
hatte auch ein Disk Environment-Modul gleich dabei kodiert.
Ich hatte auch die Einschätzung von Michael Kebe gelesen, dass es zu
viele Unbekannte für ihn gibt.
@Sven B.
Bist du auch schon auf die Problematik mit dem Linker gestoßen, die ich
beschrieben habe? Sind dir alle Adressen für das Board klar?
Interessiert mich wie weit da der Stand ist. Kompiliert U-Boot 2011.09
schon für das Board?
@All
Frohes Neues!
@Michael
Ja, er kompiliert und linkt. Es kommt also ein Binary dabei raus.
Lediglich laufen lassen konnte ich den Code noch nicht. Ich hatte zwar
auch den ein oder anderen Linker-Fehler aber die waren alle lösbar.
Insbesondere der SATA-Code benötigte für eine sinnvolle Anbindung einige
Änderungen. So halt auch der Ethernet-Code. Ebenfalls habe ich auch die
UART-Adressen verknüpft und den richtigen Treiber ausgewählt.
Der NAND-Code ist besonders stark von Änderungen betroffen, da hier
bestimmte Funktionen im neueren U-Boot keine Entsprechungen mehr haben.
Die notwendigen Adressen bezüglich Ladeadressen waren für mich leicht
auszumachen. Zum Beispiel CONFIG_SYS_TEXT_BASE bekam den Wert
0x60d00000. War auch im alten config.mk als TEXT_BASE zu finden.
Ist aber mit ARM-Hintergrundwissen alles machbar.
Ich hatte mir auch die "hilfreichen" Antworten, die du bekommen hast,
mal durchgelesen.
@All
Von mir auch ein frohes neues
@all
bezüglich Kernel 3.1 Support: Den von mir überarbeiteten SATA-Treiber
kann man wohl in Kürze als Beta betrachten. Also gibt es bald einen
sauberen Kernel ohne wilde Hacks. Er scheint erst mal zu laufen, wie mir
WarheadsSE bestätigt hat.
Jetzt habe ich mal eine Frage:
Die hier im Wiki beschriebene Variante, ALARM per chroot zu nutzen,
klappt bei mir nicht :(
Der Fehler liegt imho an fehlenden Rechten des "admin"-Kontos:
>~ $ chroot . /bin/bash> chroot: can't change root directory to .: Operation not permitted> ~ $ whoami> admin> ~ $ su> su: must be suid to work properly
Habe ich was falsch gemacht, oder stimmt das wirklich? Ich habe übrigens
die Aldi-Nord-Variante, die etwas teurer war und wohl eine größere
Platte hat als das Gerät, das ihr scheinbar alle besitzt ;)
Aah, danke^^
Ich bin es halt nicht gewohnt, dass man sich als Superuser per PW
anmelden kann ;)
So klappt es wunderbar :)
Allerdings, was ist mit "ACHTUNG: Der Zugriff auf /dev/sda2 beschädigt
das RAID" gemeint? In dem System mounte ich ja ohnehin nichts, oder?
Jens D. schrieb:> solo schrieb:>> Die>> Kirkwood-Plattform zeigt wie's gehen kann. Aber Marvell ist auch eine>> andere Hausnummer als PLX.>> Sollte man also bei zukünftigen Anschaffungen darauf achten? Macht wohl> Sinn, was?
Ja, man sollte das recherchieren und bedenken. Vor allem, wenn man auf
den Komfort von Debian & Co. angewiesen ist. Der ist dauerhaft nur
gegeben wenn die Hardware wirklich gut unterstützt ist, also mainline
und große Community.
Mir hat es zunächst gereicht, zu wissen, dass ich ein abgespecktes
System überhaupt drauf kriege. Notfalls hätte ich später mit buildroot
was ganz minimales auf altem Kernel stricken können, um noch ein paar
Jahre hinzukommen. Dass die Hardware nochmal per Aldi unters Volk
gebracht wird, konnte ich nicht ahnen - kommt mir natürlich jetzt
gelegen.
@Sven
Große Klasse! Vielen Dank für deine Arbeit.
Ciao,
solo
Johann B. schrieb:> Allerdings, was ist mit "ACHTUNG: Der Zugriff auf /dev/sda2 beschädigt> das RAID" gemeint? In dem System mounte ich ja ohnehin nichts, oder?
Das Problem ist aber das es ein chroot-System ist, wenn von dort
irgendwas an gemounteten Dateisystemen geschieht, so wirkt es sich
insgesamt aus.
Johann B. schrieb:> Habe ich was falsch gemacht, oder stimmt das wirklich? Ich habe übrigens> die Aldi-Nord-Variante, die etwas teurer war und wohl eine größere> Platte hat als das Gerät, das ihr scheinbar alle besitzt ;)
Es handelt sich im Grunde um die gleiche Hardware.
Einziger Unterschied 2TB statt 1,5TB. Alle die ihre 1,5TB Festplatte
gegen eine 2TB Festplatte ersetzen, haben dann genau das was du auch
hast.
@solo
Danke fürs Lob.
sorry, dass ich hier noch mal so rein platze... ;o) leider sind durch
meine copy-aktionen diverse berechtigungen in den ordnern abhanden
gekommen, sodass ich einen teil erstmal wieder auf standard rücksetzen
müsste. die berechtigungen über die web-oberfläche zu entfernen und neu
anzulegen funktioniert leider nicht. ebenso kann ich via windows nix an
deren einstellungen ändern. ich gehe mal stark davon aus, dass es nur
via telnet mit dem root-account funktionieren wird. könntet ihr mir
bitte noch verraten, wie ich allen ordnern inkl. unterordnern+dateien
die standard-berechtigungen der shares zuweisen kann!? sprich: direkt in
den shares (vorhanden oder neu angelegt) kann ich lesen+schreiben. in
die darin kopierten ordner hab ich leider keine schreibrechte mehr und
auch diverse user (root/504 z.b.), mag ich gern entfernen, um erstmal
wieder ein frisches aufsetzen der accounts vornehmen zu können.
vielleicht besteht die möglichkeit die ordner der sda2 in knoppix zu
mounten und dann grafisch die user zu bearbeiten? aktuell bekomme ich
leider beim mounten in telnet, dass das system busy ist!?
~ # mount -t xfs /dev/sda2 /temp
mount: mounting /dev/sda2 on /temp failed: Device or resource busy
danke und ein gesundes neues noch! :o)
Johann B. schrieb:> Allerdings, was ist mit "ACHTUNG: Der Zugriff auf /dev/sda2 beschädigt> das RAID" gemeint? In dem System mounte ich ja ohnehin nichts, oder?
Das gilt nicht für chroot, sondern, wenn man ArchLinuxARM bootet und die
Platte benutzt. Kann man wahrscheinlich auch abstellen, wenn man das
RAID auch als solches einbindet.
Johann B. schrieb:> Ich habe übrigens> die Aldi-Nord-Variante, die etwas teurer war und wohl eine größere> Platte hat als das Gerät, das ihr scheinbar alle besitzt ;)
Kannst du mal nachsehen ob die Angaben bei P89626 auch für deines
gelten. Insbesondere die Angaben bei P89626: Software. Der
Vollständigkeitshalber könntest du die Info's deiner Platte im Wiki
einfügen.
@Sven B.: Ich verfolge den Thread im Nachbarforum (
http://archlinuxarm.org/forum/viewtopic.php?f=29&t=1865 ) gute Arbeit.
Du bist ja recht Fleißig ;)
vielleicht noch mal ne ganz einfache frage!? ;o) ich habs jetzt
geschafft meine platte mal wieder im telnet zu mounten (mount -t xfs
/dev/md4 /temp), allerdings bekomm ich das mount nicht im dateimanager
(pcmanagerfm) angezeigt, damit ich da endlich wieder grafisch ordnung in
die rechteverwaltung reinbekommen kann. funktioniert mein vorhaben
überhaupt?
die standard-shares haben ja root:root, während die erstellten via
web-gui admin:root haben. nun hab ich durch die ganze kopiererei auch
1000:1000 und 504:everyone drin, was natürlich total nervt und dazu
führt, dass ich in besagte ordner nicht mehr schreiben kann. gibt es
denn einen entspannten kniff, um den standard-shares wieder komplett
(also auch darin enthaltenen ordnern+dateien) root:root zu erteilen,
sowie selbiges für die manuell erstellten shares mit admin:root zu
erreichen und gleichzeitig die ungeliebten 1000 und 504 zu entfernen?
wie schauen denn die shares auf einem nicht durch ausbau der platte und
kopier-marathon verhunzten nas aus?
an chmod mag ich mich ehrlich gesagt nicht unbedingt austoben...
Alex S. schrieb:> sprich: direkt in> den shares (vorhanden oder neu angelegt) kann ich lesen+schreiben. in> die darin kopierten ordner hab ich leider keine schreibrechte mehr und> auch diverse user (root/504 z.b.), mag ich gern entfernen, um erstmal> wieder ein frisches aufsetzen der accounts vornehmen zu können.
root löscht man nicht. Es sei denn man möchte gleich ein Zurücksetzen
der Einstellungen machen. Wenn du alles neu aufsetzen möchtest, dann
benutze doch lieber die Funktion "Zurücksetzen auf Werkseinstellungen"
Alex S. schrieb:> kann ich lesen+schreiben. in> die darin kopierten ordner hab ich leider keine schreibrechte mehr
chmod a+w -R <ordner-name>
Das Problem wird sein, dass du auch die Eigentümer-Information verändert
hast. Aber mit obiger Zeile kann jeder schreiben.
Jens D. schrieb:> @Sven B.: Ich verfolge den Thread im Nachbarforum (> http://archlinuxarm.org/forum/viewtopic.php?f=29&t=1865 ) gute Arbeit.> Du bist ja recht Fleißig ;)
Ich möchte nun mal diese zurechtgeschusterte Geschichte loswerden.
Dies Frickelwerk, was PLX und Medion produziert haben, möchte ich ungern
als Dauerbetriebslösung haben. Insbesondere wenn irgendwas schiefgeht,
dann ist man mit solchen Lösungen auf sich allein gestellt. Erst recht
dann wenn der Hersteller-Support ausläuft. (weil abgekündigt oder
ähnliches). Mit einem sauberen System geschieht das jedenfalls nicht.
Ich werde auch nochmal den Ethernet-Treiber durchgehen und überprüfen.
Für ArchLinuxARM sollten die OX820-Kernel-Module (PLX782x) vorzugsweise
Modulparameter verwenden, alles andere lässt sich mit Binaries faktisch
nicht behandeln.
Ich werde auch noch schauen, ob die GPIO-Anbindung LED-Definitionen
besitzt und wenn nein dann würde ich mir dazu auch die Mühe machen. Im
SATA-Treiber ist der LED Trigger Support schon drin.
>root löscht man nicht. Es sei denn man möchte gleich ein Zurücksetzen>der Einstellungen machen. Wenn du alles neu aufsetzen möchtest, dann>benutze doch lieber die Funktion "Zurücksetzen auf Werkseinstellungen"
das war natürlich ungeschickt vom mir ausgedrückt... der user 504 ist
wohl mitglied der gruppe root, daher auch "/" und nicht "," ;o)
ich führe den werksreset gerade noch einmal durch, kann mir aber nicht
vorstellen, dass er die rechte der ordner/dateien auf der
daten-partition zurücksetzt, von daher bin ich noch nicht selbst auf
diese idee gekommen. wäre natürlich klasse, falls er es doch tun würde!?
Alex S. schrieb:> ich führe den werksreset gerade noch einmal durch, kann mir aber nicht> vorstellen, dass er die rechte der ordner/dateien auf der> daten-partition zurücksetzt, von daher bin ich noch nicht selbst auf> diese idee gekommen. wäre natürlich klasse, falls er es doch tun würde!?
Wahrscheinlich nicht, aber dafür gibt es ja chmod.
Sven B. schrieb:> Wahrscheinlich nicht, aber dafür gibt es ja chmod.
aber wie bekomm ich damit auch wirklich wieder die "ausgangslage" aller
berechtigungen her? help plz :-) jedenfalls resetted er nach wie vor
kräftig, womit ich fast davon ausgehe, dass er doch alle dateien anfasst
und möglicherweise auf root zurücksetzt!?
Johann B. schrieb:> Da ohnehin keine anderen Benutzer auf dem NAS agieren, kannst du doch> ohnehin>> chmod 777 ./*> machen oder nicht?
Das muss eher so heissen
chmod -R 0777 ./*
Ohne 0 ist es zudem falsch wegen Oktalschreibweise.
sonst sind es nur die Dateien im aktuellen Ordner und nicht die
Unterordner.
allerdings sollte bei Alex auch folgendes genügen
chmod -R a+w ./*
a+w => Dadurch werden die write bits für alle gesetzt.
so werden die Änderungen passieren:
0444 => 0666
0555 => 0777
aktuell werkelt sie noch vor sich hin und lässt sich nicht mehr pingen.
weder auf ihrer static 192.168.0.105, noch auf der ausgangs-ip 10.1.1.7
... das kommt mir irgendwie bekannt vor und wird diesmal nicht von mir
unterbrochen werden! ;o) sie scheint mit dem werksreset über die web-gui
also auch am filesystem zu werkeln, sonst würde es ja nicht soooo lange
für benötigen!? ich werde jedenfalls bis zum spindown der platte warten
(das hat bisher ohne probs bei mir funktioniert) und dann berichten bzw
ggf oben genannte tips in die tat umsetzen. bis dato
hoffentlich gibts keinen stromausfall... :oD
Kernel 3.1 Update: Ich habe jetzt ein Stück Code implementiert, welches
die GPIOs des OX820 am Standard-GPIO-Interface des Kernels anbindet.
Somit existiert auch eine Brücke zum GPIO LED Support. Über diesen kann
dann der LED Trigger des SATA-Treibers auf seinen Stamm-GPIO geschaltet
werden.
Alle weiteren LEDs lassen sich natürlich damit auch bedienen.
Anmerkung: zur Zeit ist es noch ungetestet aber ich werde das noch tun.
Danach habe ich vor den GPIO Event Support einzubauen und dann kann man
mit den Tastern sich auch bei ArchLinuxARM allerhand Sachen einfallen
lassen.
@Sven B.
Hey man du bist echt der Hammer, freue mich echt schon darauf wenn du
sagst "Aufgehts jetzt kann sich jeder den Kernel installieren"
Coole Sache ich freue mich echt das wir hier für das System so fähige
Leute am start haben.
Macht nur weiter so.
Wenn ihr soweit seit kann man dann das system flashen und auch ohne TFTP
boot den kernel starten oder ??
MfG der Niko
Kann mich nur anschließen.
nikolay schrieb:> Wenn ihr soweit seit kann man dann das system flashen und auch ohne TFTP> boot den kernel starten oder ??
Das geht auch jetzt schon, wenn du die Platte ausbauen und an einen
Linux-PC (sysresccd genügt) stecken kannst, Zugriff auf die serielle
Konsole hast, dir die Infos's aus dem Thread hier zusammensuchst und
viel googelst. Im wesentlichen musst du folgendes tun: Du kopierst das
Image des Medion Kernels und die /lib/modules aus dem Medion System
raus. Du spielst das Iomega-32MB-Image auf bzw. gehst nach
http://archlinuxarm.org/forum/viewtopic.php?f=29&t=2146 vor. Du
korrigierst die Partitionierung. Das iomega-kernel-image überschreibst
du mit dem rauskopierten Medion-kernel. Du entpackst das
archlinux-oxnas-rootfs auf die erste Partition. Du kopierst die
lib/modules aus dem Medion System an die richtige Stelle im neuen
root-fs. Du bootest und unterbrichst über die serielle Konsole am u-boot
Prompt. Du korrigierst die Kernel-Start-Parameter (RAM, rootfs) und
schreibst sie auf die HDD. Danach solltest du Arch booten können,
möglicherweise ohne Netzwerk, es können noch ein paar Feinarbeiten per
Serieller Konsole notwendig sein. So solltest du zu einem per ssh
erreichbaren, permanent von hdd bootenden Archlinux kommen. Auf den
3.1er Kernel kannst du später umsteigen.
@ft
Dir ist klar, dass dir grade sicherlich ein paar dutzend Leute auf die
Finger schauen? ;) Ich kann mein NAS leider nicht zur Dev-Box machen und
deinem git-repo folgen, da ich auch wichtige Daten drauf habe. Deshalb
muss ich für Kernel-Tests wenigstens die Platte wechseln. Bitte gib ein
Zeichen, wenn du einen Stand hast, mit dem du halbwegs zufrieden bist!
Ciao,
solo
ich meld mich auch mal wieder mit einer erkenntnis zu wort, die dem
einen oder anderen vielleicht helfen mag. nachdem die nas nun 24h auf
"wiederherstellung" gemacht hat, hab ich vorhin einfach mal den
netzwerk!!!-stecker gezogen und siehe da, sie rödelte extremst vor sich
hin und gipfelte im spindown der festplatte... jetzt werd ich sie wieder
online nehmen, mal schauen wie es im bezug auf zugriff und
rechte-verteilung ausschaut. bis später!
@solo
Das ist mir klar, dass etliche Leute jetzt darauf warten, den Kernel
ohne diese wilden PLX-Hacks zu bekommen.
Ich werde auf meiner Box ohnehin ein Setup fahren, wo ich dann die Teile
auch mal testen kann.
Deswegen verstehe ich auch, dass nicht alle gleich den Kernel
installieren.
Den Umstieg auf 3.1 sehe ich auch als zukünftigen Schritt, da ja das
Wegkommen von der Medion-Firmware auch mit dem 2.6er Kernel aus dem
ArchLinuxARM bereits klappt. Interessierten Leuten, die den Kernel 3.1
bereits ausprobieren wollen, können dies tun. Ist halt immer eine
persönliche Abschätzung.
Der SATA-Treiber selbst ist aber soweit nutzbar. (WarheadsSE spielt
damit schon eifrig in seinen Setups soweit ich das weiss).
Der GPIO-Teil kann dann mit kompiliert werden, muss aber nicht. Ist eine
Kernel-Config-Option.
Das Thema wichtige Daten wird bei mir auch passieren. Allerdings habe
ich ja sowohl das 1,5TB NAS als auch die 2TB USB Platte. Da kannst dir
schon denken, was jetzt in Kürze passiert. 2TB rein und 1,5TB als USB.
Ich muss ohnehin mal schauen, wie die LED class Funktionalität bedient
wird. Aber das kann ich mir auch beim OpenWRT anschauen, da wird das
schon gemacht.
Hallo,
nur mal zur Info. Habe nach Weihnachten eine Mail an den Medion Support
bezüglich der NAS Problem (die euch ja bekannt sind) gesendet.
Heute bekam ich Antwort:
"Für die NAS Laufwerke steht ein Firmwareupdate zum Download bereit.
Über Administrator - Wartung - FW Update können Sie die aktualisierte
Version 1.00 (UZD.2) herunterladen und installieren.
Wir hoffen, Ihnen mit diesen Informationen weitergeholfen zu haben"
Jetzt frage ich mich gerade, ob die mich veräppeln wollen. Erst mal sagt
der NAS, das es keine Firmware gibt und zweitens ist das doch die
Auslieferungsfw.
Gruß
Eddie
EddieTheEagle schrieb:> Version 1.00 (UZD.2)
Ja das ist keine neuere. Veräppelung ;)
In einem andern Forum hieß es, es soll Anfang 2012 eine neue Version
geben.
Selbst wenn, ich glaube kaum das die einem Rundrum glücklich machen wird
;)
@solo
Danke für die Infos.
Ist es auch denkbar das bei der sache z.B.
ein update Image machbar ist welches ich wie bei einer Fritzbox
einspiele
und danach hab ich halt arch linux am laufen und nicht dieses
Zyxel/Medion ding. Oder sind da noch unbekannte im system der NAND Flash
oder die stag0 zum Beispiel.
Mit deiner Anleitung könnte ich und sicherlich auch andere das ding
umbasteln nur um eine größeren bereich an leuten ansprechen zu können
ist es halt zu kompliziert.
Hat sich einer den aufbau des Firmware images von medion angesehen
welche schritte der durchläuft um das system auf einen neuen stand zu
flashen.
dies sollte sich für ein arch linux image doch auch benutzen lassen.
Oder sehe ich da was nicht.
Danke und mfg der Niko
@nikolay:
Da die Originalfirmware diesen USB-Rettungsstick-Support hat, könnte man
darüber einen ArchLinux-Installer laufen lassen, welcher dann die
Festplatte modifiziert.
Der Inhalt im NAND ist danach ohne Bedeutung.
Ich habe mir zwar das Firmware-Update-Format mal zum Teil angeschaut.
Ist aber aufgrund des zuvor genannten völlig irrelevant.
Deswegen braucht es dort keine Firmware-Update-Datei.
Anders als die FritzBox, welche nur mit Flashes umgehen kann, kann das
Medion NAS direkt von Platte booten.
Ein Firmware Update kann über
https://github.com/jedie/NAS7820-Tools/tree/master/usb_key_func
realisiert werden.
Ich finde es jedoch besser, ein Alternatives Linux interaktiv zu
installieren. Also usb_key_func nutzten um telnet zu starten und dann
soll der User sich einloggen und per Hand ein/zwei install Skripte
starten.
So ein richtiges Dummuser Update bringt doch nichts wenn eh nur ein
"Nackes" Linux installiert wird.
Ich habe es noch nicht getestet, aber unter
https://github.com/ft-/NAS7820-Tools
habe ich mal einen archlinuxinstaller-medion Image für einen
FAT-formatierten USB-Stick zusammengestellt.
ACHTUNG
Der Festplatten-Inhalt wird gelöscht.
@Jens D.
Weil es einfacher und auch Fehler toleranter ist wenn man ein
automatisches Install image hat. Damit ist auch all den jenen geholfen
die z.B. für nen Freund (mal schnell) nen arch linux drauf installieren
um dem z.B. für nen mac dort nen TimeMashine fähiges nas zu erzeugen
usw.
Es geht hier gar nicht darum meiner Oma am Telefon zu sagen "He du hau
dir arch linux drauf damit du schön software per pacman nach ziehen
kannst"
Aber für alle anderen ist die Hürde ihr system erstmal aufschrauben
usb2serial Adapter anklemmen usw. höher als wenn sie ein image
einspielen und danach sich um die Applikation kümmern können als die
zeit zu verwenden das ding umzuinstallieren.
Und des weitern lässt sich so auch ne art arch_linux__p89262
Distribution mit den einsprechenden Modifikationen zusammen packen ohne
stunden zu verbringen wer in welchen der vielen Foren jetzt nun wie was
gemacht hat. Falls wir modifikation für das medion nas benötigen falls
nicht reicht ja eine Standard ArchLinuxARM-oxnas.
@Sven B.
Cool sven das du da schon nen script gebaut hast, wenn ich das alles
richtig verstehe geht das aber nur wenn ich per serieller console das
usb_key_func.sh angebe, oder führt das system die datei aus wenn es
einen usb stick erkennt.
Ja ich würde halt
https://github.com/ft-/NAS7820-Tools/blob/master/archlinuxinstaller-medion/do.sh
aufteilen. Halt telnet starten und dann muß man den installer an werfen.
Dann sieht man auch die Ausgaben und ob evtl. was schief läuft.
Ansonsten ist das ja ohne JTAG ein Blindflug ;)
Außerdem wäre es dumm, wenn man versehentlich den Stick angeschlossen
läßt ;)
Gebe dir recht das es Blindflug ist, nur ist es ja auch bei einer
Installation von einem Medion original Image genauso ein Blindflug.
Und nicht jeder hat ein JTAG Interface rumm liegen.
Ok ihr schon ;-)
Wie läuft es denn mit dem original Image, in dem befindet sich doch
bestimmt ein zyxel tar und nen installer script oder liege ich da
falsch?
Und mein Gedanke ist nun so ein image nachzubauen welches halt mit
deinem install script plus dem arch linux zusammen gepackt ist. Und sich
evtl. noch sogar als zucker inital per medion web gui installieren
lässt. (das danach keine webgui mehr da ist, ist klar)
Wäre doch wirklich schön um das system auch bei anderen Leuten
installieren zu können.
Oder was meint ihr bin ich da aufm Holzweg ???
Wollen wir es nur denen gönnen die sich trauen die Hardware auseinander
zu nehmen und dann per console rum zubasteln.
MfG der Niko
Nikolas R. schrieb:> Cool sven das du da schon nen script gebaut hast, wenn ich das alles> richtig verstehe geht das aber nur wenn ich per serieller console das> usb_key_func.sh angebe, oder führt das system die datei aus wenn es> einen usb stick erkennt.
Sollte eigentlich automatisch gehen. Aber womöglich stimmt die Checksum
noch nicht.
Jens D. schrieb:> Außerdem wäre es dumm, wenn man versehentlich den Stick angeschlossen> läßt ;)
Sobald ArchLinux läuft passiert nix mehr. Weil ArchLinux sich für diesen
Stick nicht interessiert. Nur die Medion-Firmware interessiert sich
dafür aber SATA hat Priorität und somit ist sobald das richtig
eingerichtet ist, der Stick-Inhalt ohne Funktion.
Deswegen funktioniert der auch nur genau einmal.
Nikolas R. schrieb:> Und mein Gedanke ist nun so ein image nachzubauen welches halt mit> deinem install script plus dem arch linux zusammen gepackt ist. Und sich> evtl. noch sogar als zucker inital per medion web gui installieren> lässt. (das danach keine webgui mehr da ist, ist klar)
Ist kein tar und hat auch kein install script. Sind nur die Binaries
und deren MD5 drin und der Updater liegt auf der Seite der bereits
laufenden Original-Firmware. Darum wird der Weg nicht funktionieren. Wie
gesagt ich habe mir dass Zeug angeschaut und es ist definitiv nicht
möglich von dort auf die Festplatte zu kommen.
Die FritzBox hat ein anderes Firmware-Format. Nicht jeder Hersteller
baut die Firmware auf dieselbe Weise zusammen.
Nikolas R. schrieb:> Wollen wir es nur denen gönnen die sich trauen die Hardware auseinander> zu nehmen und dann per console rum zubasteln.
Deswegen der USB-Stick, wenn der einmal richtig gemacht ist, dann
funktioniert das auch ohne console. Nur diesen kann dann praktisch jeder
mit einem beliebigen Betriebssystem bauen.
Anleitung z.B. wie folgt für den Anfang:
1. Leg das Zeug aus folgenden Zip auf einen FAT-formatierten Stick.
2. Stecke den Stick an das NAS
3. Starte das NAS neu
4. Warte bis es nochmal neustartet.
Man könnte auch noch die verbliebenen Schritte aus der
ArchLinux-Installationsanleitung automatisieren. Diese benötigen aber
nur telnet-Zugang.
Jens D. schrieb:> Ja ich würde halt> https://github.com/ft-/NAS7820-Tools/blob/master/a...> aufteilen. Halt telnet starten und dann muß man den installer an werfen.> Dann sieht man auch die Ausgaben und ob evtl. was schief läuft.> Ansonsten ist das ja ohne JTAG ein Blindflug ;)
dann packst einfach das do.sh auf einen Stick mit der Erstfassung und
telnet-Start. Dann hast doch genau das was dir beliebt.
Es ist im Moment der Erstentwurf aber ich würde definitiv den Weg der
vollautomatisierten Variante gehen, weil das am sichersten ist und
keinerlei login-Fragen nach sich zieht.
Muss halt nur noch vollständig sein und dann kann das jeder benutzen, um
eine ArchLinux-Installation in wenigen Minuten drauf zu installieren,
die im Übrigen gleich vom DHCP eine IP-Adresse holt.
Sven B. schrieb:> dann packst einfach das do.sh auf einen Stick mit der Erstfassung und> telnet-Start. Dann hast doch genau das was dir beliebt.>> Es ist im Moment der Erstentwurf aber ich würde definitiv den Weg der> vollautomatisierten Variante gehen, weil das am sichersten ist und> keinerlei login-Fragen nach sich zieht.
Wenn ich Zeit hab, werde ich das mal umändern. Ich wollte eigentlich
auch schon längst die anderen Flash Skripte ein wenig aufbohren...
Wie wäre die Variante:
Man muß eine Datei umbenennen, dann ist es voll automatisch. Im Original
Zustand muß man allerdings die Installation per telnet machen.
Ich meine es sollte eh nur von Leuten gemacht werden, die eine Telnet
Verbindung aufbauen können ;)
Servus Leute,
@Jens hast schon recht so das minimal Verständnis um sich einzuloggen
und meinetwegen auch nur per Anleitung etwas durchzuführen sollte schon
da sein.
Die Idee vom Sven gefällt mir schon sehr gut.
Ist es es möglich das in so einer frühen Fase auch schon Meldungen per
syslog verschickt werden, so könnte man wenn netzwerk vorhanden ist zum
mindestens ab diesem punkt etwas erhalten un währe nicht ganz so blind.
Da ihr da ja mehr Ahnung habt wie sieht es mit dem 3.1 kernel eure
Meinung nach aus, werden in diesem kernel auch alle teile die in diesem
SOC sind angesprochen ??
MfG der Niko
Nikolas R. schrieb:> Da ihr da ja mehr Ahnung habt wie sieht es mit dem 3.1 kernel eure> Meinung nach aus, werden in diesem kernel auch alle teile die in diesem> SOC sind angesprochen ??
Apropos, Sven, habe mal Dein git repo geclont, macht es denn Sinn,
drivers/mtd/nand/ox820_nand.c mit der entsprechenden Medion-typischen
Partitionierung zu übernehmen? Wenn ja, kann ich Dir mal den
entsprechenden Patch auf github schicken, falls Du an so
Klein-Zuarbeiten interessiert bist mach' ich einen Fork.
Ich wollte eigentlich schon mal angucken über UART, wie sich der 3.1er
Kernel aktuell so tut ;-). Ist denn ox820_pogoplug_defconfig ein guter
Ausgangspunkt für die Konfiguration?
Geht derzeit die NIC? Wie sieht das mit der Firmware für den
LEON-Coprocessor aus, kann man die in den sourcen ohne weiteres
aufnehmen, oder eher nicht?
Hallo Leute,
ich verfolge nun schon seit Weihnachten hier eure Beiträge und finde das
einfach nur genial was ihr hier auf die Beine stellt.
Jetzt habe ich aber ein paar fragen mal an euch.
Soweit ich das jetzt verstanden hab kann man mittels eines Usb Stick
ArchLinux auf der Festplatte installieren.
Kriegt man denn die Platte dann noch in den schlafmodus oder rattert die
dann immer durch?
Sollte mir das alles nicht gefallen kann man so wie ich das jetzt
verstanden habe das Medion System problemlos wieder draufmachen oder?
Das Medion System hat so eine schöne weboberfläche mit Diaschau und
Filmwiedergabe ist das dann mit arch auch möglich?
Zum Verwalten habe ich gelesen kann man Webmin draufspielen richtig?
Die ganzen möglichkeiten denke finde ich dann im ArchlLinux Wiki und wie
man alles installiert oder?
Ich habe 2 gute gründe warum ich schon wechseln will.
1. Nach längerer nicht benutzung des Nas hat man kein zugriff mehr und
nur ein reboot hilf.
2. Kein DualCore (echt ne frechheit)
Zum schluss ein GROßES DANKE an euch für die tolle arbeit und die zeit
die ihr investiert habt
Nikolas R. schrieb:> Oder was meint ihr bin ich da aufm Holzweg ???
Nein, definitiv nicht. Ich habe deine Frage als Gelegenheit genutzt,
auch für andere mal die wesentlichen Schritte zusammen zu schreiben. Das
wird noch einfacher und defintiv auch ohne serielle Konsole möglich
sein.
Der Vergleich mit der Fritzbox hinkt allerdings ziemlich: Bei der FB ist
es kaum möglich, die Kernfunktionalitäten auf einer Standard-Distri
nachzubauen und man kann/möchte das Gerät eh nur um wenige Funktionen
ergänzen. Da ist der Weg über Zusatzpakete zur Firmware wesentlich
attraktiver. Beim Medion NAS liegen diese Dinge anders, und es ist
besser, eine Standard-Distri drauf zu bringen, die man dann mit deren
Werkzeugen und Support(!) erweitern kann.
Das bringt uns zum nächsten Punkt: Die Community um ein einzelnes
spezielles NAS-Gerät ist winzig - selbst wenn es von Aldi verkauft
wird. Die Community um das SoC des Medion ist schon größer. Da kommen
noch (interessierte) Iomega-, Zyxel- und Pogoplug-Besitzer dazu. Ohne
wirklich gute Gründe sollte man keine Gerätespezialisierung betreiben
und diese Gruppe spalten. Stell dir vor, du hast ein drei Jahre altes
Medion-One-Klick-Installationsimage, das nicht mehr gepflegt wird und du
bekommst es wegen irgendeiner Macke nicht mehr bis zu einem aktuellen
ArchLinux upgedatet. Bei Arch liegen aktuellere Root-FS-Images und
Kernel - aber du weißt nicht, wie du die zu einem Installer
zusammenbäckst.
Ein 10-Punkte-Howto zu einem Gerät hat keinen Wartungsaufwand und
funktioniert (sehr wahrscheinlich) auch in drei Jahren noch mit
aktuellerer Software. Was ist so schlimm dran, paar Befehle zu tippen -
musst du hinterher eh, um auch nur einen Bruchteil der NAS-Funktionen
wieder drauf zu kriegen. Ein "pacman -S samba" reicht übrigens nicht, um
die Box am Windows Rechner zu sehen.
Ciao,
solo
@Jens R.
Glaub mir am Telnet fällt denen eigentlich viel zu viel Mist ein.
Man könnte zwar telnet statt einer Shell einfach das Skript bei Login
starten lassen. Aber prinzipiell gehe ich davon aus, dass die
Umbenenn-Variante ruckzuck eine Default-Auto-Variante findet.
Das Problem an den Flash-Skripten ist, dass diese nicht in der
Firmware-Datei sind. Somit würde es erst irgendwelche Modifikationen am
DSL-Router und an der Firmware erfordern. Darum fällt die
Firmware-Update-Methode im Grunde flach. Und es gibt genügend
DSL-Router, wo die Leute keinen Zugriff auf die Administration haben
(TR069 sei "dank").
Ich halte eine Installation nur für sinnvoll, die mit dem eigentlichen
Gerät arbeitet und einen USB-Stick zu präparieren ist nunmal in der
gleichen Liga wie ein Firmware-Mod bei Linux-Routern einspielen.
Deswegen muss das Skript sicherlich noch ein paar Ergänzungen bekommen.
@Nikolas R.
soweit ich das sehe ist alles was für SATA-Boot nötig ist auch
enthalten.
Für folgende Komponenten liegt eine Unterstützung vor.
GPIO (von mir neugebaut, ungetestet, nötig für LED-Trigger in
SATA-Treiber)
SATA (von mir umgebaut, von WarheadsSE Lauffähigkeit bestätigt)
Ethernet (ist erstmal nur Port seitens ArchLinuxARM-Leuten)
Plattform-Support (Dual-Core, Port seitens ArchLinuxARM-Leuten)
@Lucian M.
Ich habe bei allen Modulen an denen ich gearbeitet habe nicht die
Medion-Sourcen direkt übernommen sondern auch dabei entsprechend dem
aktuellen Kernel aufgeräumt.
ox820_pogoplug_defconfig schaltet PCIe Support ein, den muss man noch
ausschalten. Eine sinnvolle Medion-Kernel Config habe ich noch nicht als
Default gemacht. Aber da würde ich auch eher sagen, dass dieser Build im
Rahmen von ArchLinuxARM entsteht.
drivers/mtd/nand/ox820_nand.c ist für SATA-Boot ohne Bedeutung, da
nichts vom Flash verwendet wird. Selbst das U-Boot Environment lässt
sich dann auf Platte platzieren.
Dann kann man das Flash unangetastet lassen und hat im Grunde ein Gerät
welches ausschliesslich durch Modifikationen auf der Festplatte mit
ArchLinuxARM betrieben wird. Keine Flash-Modifikationen. Und wenn man
die Platte wechselt kann man wieder den Stick benutzen.
Das ist selbst für die garantiefürchtigen Leute tragfähiger, denn die
Festplatte ist ohnehin zugänglich durch die USB-Stick-Backdoor.
Das was ich zusammengestellt habe, soll erstmal ein HMNDCE-artiges Setup
auf das Medion-NAS aufspielen. Damit gibt es dann eine Swap-Partition
und eine grosse Partition für den Rest.
Merz schrieb:> Sollte mir das alles nicht gefallen kann man so wie ich das jetzt> verstanden habe das Medion System problemlos wieder draufmachen oder?
Bei der Methode, die ich für den Stick mir denke, reicht es die ersten
paar Sektoren zu plätten und ein Neustart durchzuführen.
Dann kommt die Medion-Firmware wieder hoch als sei nix gewesen und will
jungfräulich im WebGUI die Formatieraufforderung bekommen.
solo schrieb:> Ein 10-Punkte-Howto zu einem Gerät hat keinen Wartungsaufwand und> funktioniert (sehr wahrscheinlich) auch in drei Jahren noch mit> aktuellerer Software. Was ist so schlimm dran, paar Befehle zu tippen -> musst du hinterher eh, um auch nur einen Bruchteil der NAS-Funktionen> wieder drauf zu kriegen. Ein "pacman -S samba" reicht übrigens nicht, um> die Box am Windows Rechner zu sehen.
Deswegen mach ich das Skript so offensichtlich mit den Dateien, da kann
dann jeder später den Kernel recht elegant einsetzen oder das Skript
bedient sich gar gleich direkt am ArchLinuxARM Server und holt sich auch
den Kernel dazu. Da haben wir nunmal mit diesen usb_key_func.sh Zeug
eine Lösung, die wirklich die Installation einfach macht.
Für denjenigen der das eintippen mag, kann ja trotzdem jemand eine
Anleitung zaubern. Nur haben wir auch einige interessierte
Linux-Neulinge hier und da sind diese Befehle eben schnell mal falsch
getippt und wenn der MBR bereits drauf ist, dann gute Nacht (heisst dann
Platte ausbauen).
Dann passt die ganze Geschichte auch dann noch.
Die dd-Befehle roh zu tippen ist fehleranfällig und ich denke da sind
einfach zu viele Fehler möglich. Selbst bei WarheadsSE Skripten für den
PogoPlugPro finden sich Leute, die sich schwer damit tun.
Ich meine wir müssen da eher vergleichbar den OpenWRT-basierten Geräten
mit solchen Skripten sein. Der Rest ganz simpel ArchLinuxARM mit
gängigen Kernel-APIs und Userspace-API für Kernel-Funktionen. Nix für
irgendein Board spezialisiertes.
Oder simpler gesagt, wenn MedionNAS spezifisches notwendig ist, dann ist
es nur ein Paket mit userspace-Programmen wie jedes andere auch.
> Soweit ich das jetzt verstanden hab kann man mittels eines Usb Stick> ArchLinux auf der Festplatte installieren.> Kriegt man denn die Platte dann noch in den schlafmodus oder rattert die> dann immer durch?
Jein. Mit unverändertem Arch läuft sie durch oder viel zu oft wieder an,
als gesund für die Hardware ist. Mit etwas Handarbeit kriegt man es hin.
Man muss die Sachen finden, die in die Ramdisk gehören. Das hängt aber
von den installierten Diensten ab.
> Sollte mir das alles nicht gefallen kann man so wie ich das jetzt> verstanden habe das Medion System problemlos wieder draufmachen oder?
Nicht nötig, das bleibt im Flash unangetastet drauf. Du kannst im
laufenden ArchLinux das stage1 von der Platte löschen und neu booten.
Die Daten sind natürlich dann weg.
> Das Medion System hat so eine schöne weboberfläche mit Diaschau und> Filmwiedergabe ist das dann mit arch auch möglich?
Theoretisch ja, ist aber aufwändig: Webserver installieren, passende
(php-)Skripte finden, konfigurieren.
> Zum Verwalten habe ich gelesen kann man Webmin draufspielen richtig?> Die ganzen möglichkeiten denke finde ich dann im ArchlLinux Wiki und wie> man alles installiert oder?
So ist es.
Ciao,
solo
solo schrieb:> Jein. Mit unverändertem Arch läuft sie durch oder viel zu oft wieder an,> als gesund für die Hardware ist. Mit etwas Handarbeit kriegt man es hin.> Man muss die Sachen finden, die in die Ramdisk gehören. Das hängt aber> von den installierten Diensten ab.
Hier kann man ja spezialisierte Post-Install-Skripte bauen, die ein
fstab erzeugen bei dem /var zum Beispiel im RAM landet usw.
Sven B. schrieb:> Ich meine wir müssen da eher vergleichbar den OpenWRT-basierten Geräten> mit solchen Skripten sein. Der Rest ganz simpel ArchLinuxARM mit> gängigen Kernel-APIs und Userspace-API für Kernel-Funktionen. Nix für> irgendein Board spezialisiertes.> Oder simpler gesagt, wenn MedionNAS spezifisches notwendig ist, dann ist> es nur ein Paket mit userspace-Programmen wie jedes andere auch.
Okay, stimme ich zu. Für euch nicht so wichtig, aber ich sehe die
Skriptlösung für die HMNHDCE noch nicht so ganz. Man müsste ja dem
laufenden System das Root-FS unter den Füßen weg ziehen und gegen eines
vom stick tauschen, um die Platte bearbeiten zu können. Mit pivot_root
habe ich noch nicht rumgespielt.
Ciao,
solo
Sven B. schrieb:> Hier kann man ja spezialisierte Post-Install-Skripte bauen, die ein> fstab erzeugen bei dem /var zum Beispiel im RAM landet usw.
var ist zu groß. Da liegt der Paketcache drunter. Ich habe ein Skript
angepasst, das ausgewählte Unterverzeichnisse von var in die ramdisk
verschiebt und beim runterfahren wieder zurück schreibt. Bei
Filesharing-Kram wirds aber verrückt...
Ciao,
solo
solo schrieb:> Okay, stimme ich zu. Für euch nicht so wichtig, aber ich sehe die> Skriptlösung für die HMNHDCE noch nicht so ganz. Man müsste ja dem> laufenden System das Root-FS unter den Füßen weg ziehen und gegen eines> vom stick tauschen, um die Platte bearbeiten zu können. Mit pivot_root> habe ich noch nicht rumgespielt.
Bei der Medion NAS USB-Stick-Lösung ist noch nichts von der Festplatte
gemountet, somit kann der Stick mit der Platte anstellen was er will.
solo schrieb:> var ist zu groß. Da liegt der Paketcache drunter. Ich habe ein Skript> angepasst, das ausgewählte Unterverzeichnisse von var in die ramdisk> verschiebt und beim runterfahren wieder zurück schreibt. Bei> Filesharing-Kram wirds aber verrückt...
z.B. würde auch gehen:
ln -s /disk/cache /var/cache
Funktioniert auch die USB-Stick-Lösung nur zur Zeit installiert der noch
kein lauffähiges System, danach heisst es ohne es genauer untersucht zu
haben. Serielle Konsole haben. Aber wenn das korrigiert ist, dann sollte
es durchstarten.
Mein erster Versuch, Sven's Kernel, konfiguriert (siehe Anhang)
ausgehend von der Pogoplug-Konfig erweitert mit nfsroot-Möglichkeiten
führte auch zu einem erfolgreichem (wenn auch nicht fehlerfreiem) Booten
von Gentoo auf der Medion-NAS:
1
medion-nas-gentoo ~ # dmesg
2
[ 0.000000] Initializing cgroup subsys cpuset
3
[ 0.000000] Initializing cgroup subsys cpu
4
[ 0.000000] Linux version 3.1.0ft+ (root@htpc2) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.0, pie-0.4.6) ) #3 SMP Thu Jan 5 01:45:30 CET 2012
Also ich sehe das so: Solange nach dem ArchLinux Installation keine
Web-GUI existiert, ist die ganze Sache eh nicht für Otto-Normalo
benutzbar.
Was nutzt eine "Ein-Klick" installer, wenn danach nur ein nacktes
ArchLinuxARM läuft?
Mir reicht ein nacktes System, bei dem ich meine benötigten Dienste
(NFS/Samba) Einrichte und gut.
>> Kenne mich leider nicht mit perl aus. Weiß also nicht was da genau> passiert. Auf der anderen Seite, könnte man das irgendwo machen, wo perl> installiert ist und dann per dd in einer Datei schreiben und gut...
So ich hab mir das ganze nochmal angesehen. Es wird ein String mit einer
länge von 444Bytes zusammen gebaut. Hab das Skript mal geändert und die
Ausgabe von Perl in einer Datei rein geschrieben:
1
#!/bin/bash
2
perl <<EOF | dd of=test.dat bs=512
3
print "\x00" x 0x1a4;
4
print "\x00\x5f\x01\x00";
5
print "\x00\xdf\x00\x00";
6
print "\x00\x80\x00\x00";
7
print "\x00" x (0x1b0 -0x1a4 -12 );
8
print "\x22\x80\x00\x00";
9
print "\x22\x00\x00\x00";
10
print "\x00\x80\x00\x00";
11
EOF
0x1a4 ist die Zahl 420, also:
1
print "\x00" x 0x1a4;
sind 420 mal einen NULL String
Lustig ist, das diese Zeile vollkommen überflüssig ist:
1
print "\x00" x (0x1b0 -0x1a4 -12 );
Denn 0x1b0 ist 432 und 0x1a4 ist 420 also: 432 - 420 - 12 sind 0 ! print
macht also nichts ;)
In Python kann man den String auch so zusammen bauen (die überflüssige
Zeile weg gelassen):
1
sequnce = "\x00" * 420 + (
2
"\x00\x5f\x01\x00"
3
"\x00\xdf\x00\x00"
4
"\x00\x80\x00\x00"
5
"\x22\x80\x00\x00"
6
"\x22\x00\x00\x00"
7
"\x00\x80\x00\x00"
8
)
Ich frage mich, ob die ersten 420 NULL Bytes überhaupt nötig sind, oder
einfach nur zum auffüllen da sind. Also ob stage1 wirklich die ganzen
444Bytes auswertet, oder einfach nur die letzten 24Bytes.
Servus Leute,
@jedie Kritischere bereiche werden so automatisiert und es gibt weniger
Fehler und gebrickte boxen auf für leien und das man wenn man alles
manuel machen möchte eine serielle console benötigt.
Klar wäre as noch fein wenn anschließend noch ein script laufen würde
welches Samba/NFS und so weiter einrichtet aber das muss erstmal nicht
sein. Es reicht schon die Gewissheit das sich das system ohne Probleme
umstellen läst.
Übrigens @Sven da fällt mir ein in deinem script könnte man ja noch
diverse configs vom alt system ins arch rüber kopieren (smb.conf,nfs
exports hosts usw.) bzw. alt dafür auch die passenden Verzeichnisse
anlegen. Ich weis das geht jetzt evtl. schon etwas zu weit da die Daten
durchs umformatieren eh weg sind aber zu-mindestens hätte man nach dem
um installieren ein laufenden nas server mit den alten freigaben.
@Solo
du hast ja recht :-) das beispiel sollte nur da zu dienen ein
vereinfachtes Instalations verfahren zu verdeutlichen.
@Lucia Wie gentoo wie lange braucht das teil um sich da durch zu
compilieren oder warst du ungeduldig und hast fertige binaries
installiert. Wie ist den so der support für arm unter gentoo ???
Sven B. schrieb:> Bei der Medion NAS USB-Stick-Lösung ist noch nichts von der Festplatte> gemountet, somit kann der Stick mit der Platte anstellen was er will.
Davon red ich ja. Für das iomega HMNHDCE muss dafür noch eine Lösung
gefunden werden, was bei euren Boxen nicht der Fall ist.
@Jens D.
> sucht stage1 Bootloader im Flash zuerst auf der SATA Platte nach einem
alternativen stage1
Du hast da immer noch einen Denkfehler drin. Es gibt keinen Flash auf
dem iomega HMNHDCE. Da ist gar kein Chip auf dem Board. Wenn keine
vorbereitete Platte dran hängt, gibt das Ding keinen Mucks von sich,
kein Lämpchen geht an, keine einzige Zeile auf der Seriellen Konsole -
nix, nada.
Beim Booten wird deshalb auch nicht von einem stage1 zum alternativen
gesprungen. Der 7820 lädt seinen stage1 grundsätzlich immer zuerst von
SATA, auch auf euren Medions. Wenn dort keiner ist, wird er beim Medion
aus dem Flash geladen, während das HMNHDCE einfach stehen bleibt. Nur
die Bedeutung der Binärsequenz im ersten Sektor ist noch unklar.
Ich finde es ziemlich genial, einen Rechner fast ab den ersten Bits, die
überhaupt in der CPU wackeln, von einer austauschbaren Festplatte zu
starten. Das macht ihn nämlich so gut wie unkaputtbar.
Ciao,
solo
solo schrieb:> Du hast da immer noch einen Denkfehler drin. Es gibt keinen Flash auf> dem iomega HMNHDCE.
Stimmt, aber ich dachte dabei auch ehr an die Medion Box ;) Ich hab
versucht im Wiki das klar zu stellen. Kannst aber natürlich mit arbeiten
und selbst abändern ;)
Nikolas R. schrieb:> Wie gentoo wie lange braucht das teil um sich da durch zu> compilieren oder warst du ungeduldig und hast fertige binaries> installiert. Wie ist den so der support für arm unter gentoo ???
Also ich war da nicht ungeduldig, sondern habe mir nach ein bisschen
Recherche einen zur CPU passenden toolchain generiert und damit aus
einem anderem Gentoo-System (amd64) die für das rootfs benötigten Pakete
cross-emerged, also kompiliert. Somit sind es ganz aktuelle, ich muß
nicht auf jemanden warten, mir die zu kompilieren, usw. Natürlich gibt
es auch Probleme, wie z.B. Pakete die sich nicht cross-kompilieren
lassen, die habe ich dann nativ auf der NAS erstmal in einem chroot,
dann später als ich sie über NFS-Root booten konnte, unter wirklich
nativ gebootetem Gentoo kompiliert. Cross-emergen geht natürlich viel
schneller als natives Kompilieren, wenn der PC auch aktueller ist.
Support hat für einen eher typischen Gentoo-User einen weiteren Sinn. Er
erwartet z.B. nicht fertig kompilierte Pakete von irgendwem, weil durch
die Natur der Sache die immer am Zielsystem bei der Installation,
konsistent mit den vorgefundenen Abhängigkeiten kompiliert werden. Das
heißt nicht dass es nicht auch die Möglichkeit gibt, fertige Binaries zu
installieren. Unter diesen Umständen lernt man dann auch, wie man sich
selber hilft wenn es ein gewisses Paket, oder eine Version davon nicht
gibt, man erstellt das Ebuild (ist ein spezielles Skript welches eine
Paketversion definiert, und zwar von wo die Sourcen heruntergeladen
werden und wie sie kompiliert und nacher installiert werden) dann
selber. Support holt man sich durchaus in der Community (Foren,
Bugtracker, IRC, auch mal ARM-spezifisch wenn ein Paket beim Kompilieren
oder zur Laufzeit unter ARM zickt.
Nachdem so ein Rootfs gut läuft, kann man es auch anderen mit einer
Installationsanleitung zur Verfügung stellen (hatte ich schon mal für
Linkstation Pro gemacht). Die fliessende Aktualisierung des Systems
macht dann aber jeder Einzelne selber, zumal er auch durch sogenannte
USE flags beieinflussen kann, welche Features welche Abhängigkeiten beim
Kompilieren einbinden, um sich nach Eigenen Vorstellungen das System
maßzuschneidern. Wegen der schwachbrüstigen NAS kann man immer ein
cross-toolchain dafür zur Hilfe nehemn, aber dafür braucht man auch ein
Gentoo-PC, danach emerged man die binaries auf die NAS, kompiliert dort
nativ nur jene Pakete die es unbedingt so wollen...
All dies ist natürlcih nicht jedermanns Sache...
@all
ArchLinux:
ist eine gute Basis zwischen Beeinflussbarkeit und Aktualisierbarkeit.
Auch Linux-erfahrene Leute haben irgendwann keine Lust mehr sich jedes
Paket zu kompilieren.
Debian:
sehr hoher Anspruch an Stabilität (APIs usw.) innerhalb einer
Distribution. Deshalb auch manche Pakete nur in älteren Versionen oder
Backports verfügbar.
Gentoo:
erfordert für Aktualisierungen immer Kompilationen. Ist also eher was
für den Linux-Bewanderten.
Anmerkung:
Ich habe schon mal LFS durchgezogen. Da ist dann die Updatebarkeit
komplett in eigener Hand. Allerdings bedeutet Updaten dann auch echt
viel Zeit.
Zum Zeitaufwand liegt Gentoo am nächsten.
Zur Aktualität sind sowohl Gentoo als auch ArchLinux dicht auf LFS
(sofern man die LFS-Anleitung als Blaupause versteht).
Ich denke eine Binärdistribution wird irgendwann gehäuft sein. Wie sagt
man so schön: Ausnahmen bestätigen die Regel.
Ich habe kein Problem damit wenn jemand sich lieber mit Gentoo usw. auf
dem NAS betätigen möchte.
solo schrieb:> Davon red ich ja. Für das iomega HMNHDCE muss dafür noch eine Lösung> gefunden werden, was bei euren Boxen nicht der Fall ist.
Stimmt bei direkt beim Start gemounteten Dateisystem wie bei der iomega
HMNDCE wird das tatsächlich schwieriger, pivot_root funktioniert aber
auch nur bei einer sehr frühen Phase im Bootprozess. Später ist soviel
eingebunden und gestartet, dass man da schon ein recht üppiges Skript
zum Alles-Beenden benötigt.
Dazu braucht man eine statische Busybox und dann das pivot_root daraus
und das erste ist im Grunde ein töte alles was nicht sein darf. Wird nur
beim /sbin/init schwierig, weil der Kernel diesen am Leben halten will.
Für pivot_root muss erstmal alles beendet werden. Daher ist der
Knackpunkt den laufenden /sbin/init loszuwerden.
Anonsten klappt das Unmounten nicht.
Ich habe den Installer nochmal auf Basis der PogoPlugPro Dateien gebaut.
Mit einer solchen Installation habe ich auch erstmal ein lauffähiges
System realisiert.
http://www.github.com/ft-/NAS7820-Tools
und dann
archlinuxinstaller-medion-pogoplugpro-based
@Sven:
Im 3.1-er Kernel ist derzeit arch/arm/plat-oxnas komplett weg. Das sind
doch die von Dir und ElektroMan angesprochenen schlecht implementierten
Tricksereien die Ihr jetzt the right way implementiert oder auch wegen
geringem Gewinn weglasst? Da war auch der LEON-Support drin, nun tut ja
die NIC auch ohne, aber kann es damit zu tun haben dass die in der
Kernel-Kommandozeile übergebene MAC-Adresse nicht angenommen wird?
Jens D. schrieb:> Stimmt, aber ich dachte dabei auch ehr an die Medion Box ;) Ich hab> versucht im Wiki das klar zu stellen. Kannst aber natürlich mit arbeiten> und selbst abändern ;)
Der Zaunspfahl traf. ;) Ich habe den Abschnitt umformuliert und ergänzt.
Wir müssten mal den ganzen Artikel entmüllen und die Umgangssprache
rausmachen.
Ist das Zeug in Sektor 1 eine Art Parameterspeicher für den ROM-Code im
SoC? Ein Äquivalent des Ergebnisses von "Einstellungen speichern" im
PC-BIOS? Zweimal x80 für 128 MiB RAM und 128 MiB Flash? x22 ist der
Startblock des stage1 in hex...
@ft
Hab dein Skript überflogen, sieht gut aus. Über die Partitionierung und
ext3 könnte man natürlich endlos diskutieren... ;)
> Stimmt bei direkt beim Start gemounteten Dateisystem wie bei der iomega> HMNDCE wird das tatsächlich schwieriger, pivot_root funktioniert aber> auch nur bei einer sehr frühen Phase im Bootprozess.
Ich müsste in der initrd nachschauen, ob man dort irgendwie unterbrechen
und ein eigenes rootfs unterschieben kann - ähnlich eurem
usb-parner-dings. Nachteil wäre, dass das mit neueren Firmwares wieder
geändert werden könnte. Kexec scheidet aus, ist nicht im Kernel drin.
Ciao,
solo
Lucian M. schrieb:> Im 3.1-er Kernel ist derzeit arch/arm/plat-oxnas komplett weg. Das sind> doch die von Dir und ElektroMan angesprochenen schlecht implementierten> Tricksereien die Ihr jetzt the right way implementiert oder auch wegen> geringem Gewinn weglasst? Da war auch der LEON-Support drin, nun tut ja> die NIC auch ohne, aber kann es damit zu tun haben dass die in der> Kernel-Kommandozeile übergebene MAC-Adresse nicht angenommen wird?
Ich habe gerade den 3.1er Kernel bei mir eingerichtet. Und die
Netzwerkverbindung tut soweit.
Das mit der MAC-Adresse kommt eher daher, dass bei ArchLinuxARM die
MAC-Adresse in so einer netten Datei namens /usr/local/mac_addr liegt.
Mein kleines Setup-Skript automatisiert das. Deswegen spürt man das dann
nicht mehr.
solo schrieb:> Ist das Zeug in Sektor 1 eine Art Parameterspeicher für den ROM-Code im> SoC? Ein Äquivalent des Ergebnisses von "Einstellungen speichern" im> PC-BIOS? Zweimal x80 für 128 MiB RAM und 128 MiB Flash? x22 ist der> Startblock des stage1 in hex...
Das kann durchaus sein. Ohne SoC-Manual wird man das aber nicht
rausbekommen.
solo schrieb:> @ft> Hab dein Skript überflogen, sieht gut aus. Über die Partitionierung und> ext3 könnte man natürlich endlos diskutieren... ;)
hab erst mal die PogoPlugPro-Formatierung übernommen + Swap
RAM-Menge ist ja bei PogoPlugPro und Medion NAS erstmal gleich.
solo schrieb:> Ich müsste in der initrd nachschauen, ob man dort irgendwie unterbrechen> und ein eigenes rootfs unterschieben kann - ähnlich eurem> usb-parner-dings. Nachteil wäre, dass das mit neueren Firmwares wieder> geändert werden könnte. Kexec scheidet aus, ist nicht im Kernel drin.
Vielleicht existiert ja sowas bei HMNDCE
Sven B. schrieb:> Das mit der MAC-Adresse kommt eher daher, dass bei ArchLinuxARM die> MAC-Adresse in so einer netten Datei namens /usr/local/mac_addr liegt.
Ok, da haben wohl die ArchLinux-guys ein workaround bevorzugt.
Naja, ich habe weiter probiert, und festgestellt dass es doch geht wenn
man den Parameter mit dem Modul-Namen präfixiert:
Lucian M. schrieb:> Ok, da haben wohl die ArchLinux-guys ein workaround bevorzugt.>> Naja, ich habe weiter probiert, und festgestellt dass es doch geht wenn> man den Parameter mit dem Modul-Namen
präfixiert:gmac.mac_adr=0x00,0x11,0x41,0x..,0x..,0x..
Die U-Boot-Parameter, dafür zu erzeugen müssen, war wahrscheinlich der
Grund warum die Datei als Alternative bevorzugt wurde.
Sven B. schrieb:> solo schrieb:>> Davon red ich ja. Für das iomega HMNHDCE muss dafür noch eine Lösung>> gefunden werden, was bei euren Boxen nicht der Fall ist.>> Stimmt bei direkt beim Start gemounteten Dateisystem wie bei der iomega> HMNDCE wird das tatsächlich schwieriger, pivot_root funktioniert aber> auch nur bei einer sehr frühen Phase im Bootprozess. Später ist soviel> eingebunden und gestartet, dass man da schon ein recht üppiges Skript> zum Alles-Beenden benötigt.
Kann man bei dem iomega HMNDCE nicht auch komplett vom USB Stick booten?
Was passiert, wenn man die magischen ersten 32MB auf einen USB Stick
anlegt?
Jens D. schrieb:> Kann man bei dem iomega HMNDCE nicht auch komplett vom USB Stick booten?
Komplett wahrscheinlich nicht, siehe unten. Das ist auch nicht unbedingt
nötig - images von der Platte in den RAM zu ziehen ist kein Problem.
Erst wenn ein Root-FS von Platte gemountet wird, entstehen die Fäden an
denen das laufende System dann hängt und von denen es schwer zu trennen
ist. Wenn man also in den Skripten der initrd eingreift, reicht das aus.
Dort könnten alle Mittel vorhanden sein, um ein FS von USB zu mounten.
Ich habe gestern versucht, die initrd zu entpacken - hat aber nicht
funktioniert. Vorher kann ich nicht reinschauen, ob dort was
implemetiert ist analog zu eurem parner-stick-zeugs. kexec wäre noch ein
guter Weg gewesen, ist aber im Stock-Kernel nicht drin. Falls in der
initrd nichts brauchbares ist, bleibt wirklich nur noch pivot_root in
einem so weit wie möglich runtergefahrenen System.
Die "Brick-Gefahr" ist damit hoch für so einen Prozess. Aber das lässt
sich nicht vermeiden bei einem NAS ganz ohne Flash. Als Notnagel bleibt
ja immer das Anschließen der Festplatte an einen PC. Und den hat jeder,
der ein NAS kauft - im Gegensatz zum USB-UART-Adapter. Eine solide
Vorgehensweise, die Platte am PC zu bespielen, ohne per serieller
Konsole eingreifen zu müssen, ist deshalb die Hauptsache. Das auch ohne
Ausbau der Platte hinzukriegen wäre nur ein nettes Add-on.
> Was passiert, wenn man die magischen ersten 32MB auf einen USB Stick> anlegt?
Ohne es probiert zu haben, aber mit einiger Sicherheit: Nichts. Dazu
müsste der SoC-ROM-Code in der Lage sein, das USB-Subsystem zu
initialisieren, einen Stick als Blockdevice zu erkennen und davon zu
laden. Davon ist in den Dokumenten zum 7820 keine Rede, während SATA,
SPI und NAND ja explizit aufgeführt sind. Daher glaube ich nicht, dass
das implementiert ist.
Ciao,
solo
solo schrieb:>> Was passiert, wenn man die magischen ersten 32MB auf einen USB Stick>> anlegt?> Ohne es probiert zu haben, aber mit einiger Sicherheit: Nichts. Dazu> müsste der SoC-ROM-Code in der Lage sein, das USB-Subsystem zu> initialisieren, einen Stick als Blockdevice zu erkennen und davon zu> laden. Davon ist in den Dokumenten zum 7820 keine Rede, während SATA,> SPI und NAND ja explizit aufgeführt sind. Daher glaube ich nicht, dass> das implementiert ist.
Ja, denke ich auch.
Wie ist ein "Recovery" von iomega aus geplant?
Wenn man ein uBoot mit USB unterstützung hat, sollte doch ein booten
komplett davon funktionieren.
Aber klar. Aus und Einbau im PC tut's auch. Wäre bei Medion ja auch eine
Option.
Jens D. schrieb:> Wie ist ein "Recovery" von iomega aus geplant?
Gar nicht. Durch Ausschalten im falschen Moment kann das System selber
nicht beschädigt werden, nur die Datenpartition. Damit kann man in der
Firmware umgehen. Der einzige denkbare echte Defekt bei
bestimmungsgemäßem Gebrauch ist ein Hardwarefehler. In der Garantiezeit
gibts dann ein neues Gerät. Iomega war auch in einigen Fällen kulant und
hat kaputtgebastelte Geräte ersetzt.
Die Frage ist eher, was Medion eigentlich will. Keine durch den Kunden
wechselbare Platte und trotzdem ein System auf Flash - das ist an sich
sinnlos. Ich hatte ja die Seagate Go-Flex-Home da. Das ist auch ein
1bay-NAS - aber eben mit Dock + Wechselplatte. Das geht nicht vernünftig
ohne Flash. Das Konzept des Medion-NAS ist dagegen fragwürdig und lässt
sich wohl am ehesten mit eigener Unsicherheit bei der Firmware erklären.
> Wenn man ein uBoot mit USB unterstützung hat, sollte doch ein booten> komplett davon funktionieren.
Bringt nichts, denn wenn beim austauschen von u-boot und u-boot-env was
schief geht, ist das gerät bereits gebrickt. Da kann man ebenso gut auch
nur die initrd austauschen. Hat dasselbe Risiko, kommt aber ohne
Neukompilieren von irgendwas gerätespezifischem aus.
Ciao,
solo
solo schrieb:> Die Frage ist eher, was Medion eigentlich will. Keine durch den Kunden> wechselbare Platte und trotzdem ein System auf Flash - das ist an sich> sinnlos. Ich hatte ja die Seagate Go-Flex-Home da. Das ist auch ein> 1bay-NAS - aber eben mit Dock + Wechselplatte. Das geht nicht vernünftig> ohne Flash. Das Konzept des Medion-NAS ist dagegen fragwürdig und lässt> sich wohl am ehesten mit eigener Unsicherheit bei der Firmware erklären.
Eine GoFlexHome hab ich auch ;) Dort läuft ArchLinuxARM ohne Probleme ;)
Ich denke im Falle von Medion ist es einfach so, das die ein paar
Komponenten zusammen gewürfelt haben und dabei war hat die Flash
Variante. Finde ich auch ok. So haben wir beide Möglichkeiten ;)
IMHO ist es so, das Medion auch nicht wirklich das Gerät entwickelt hat.
IMHO entwickeln die eh nichts. Es wird irgendwo fertig eingekauft und
den Namen drauf gepackt (Was auch der eigentliche Hersteller macht).
Medion ist IMHO nicht viel mehr als eine Importeur und kein Hersteller
und schon garnicht ein Entwickler. Aber das sind nur Vermutungen ;)
>> Wenn man ein uBoot mit USB unterstützung hat, sollte doch ein booten>> komplett davon funktionieren.> Bringt nichts, denn wenn beim austauschen von u-boot und u-boot-env was> schief geht, ist das gerät bereits gebrickt.
Wobei es ja noch die beiden Kopien gibt ;) Also die erste so lassen wie
sie sind und nur den zweiten per "Chain-Loading" nutzten.
Wobei wenn einmal ein uBoot drauf ist, was seinen Zweck erfüllt, dann
braucht man es ja nicht mehr an zufassen. Wichtiger ist, das man auf
einfacher weise den Kernel Aktuell halten kann...
Jens schrieb:> # smartctl --all /dev/sda | grep -i temp> 190 Airflow_Temperature_Cel 0x0022 043 042 045 Old_age Always> FAILING_NOW 57 (0 37 58 54)> 194 Temperature_Celsius 0x0022 057 058 000 Old_age Always> - 57 (0 20 0 0)>> Nachdem die Kiste mal auf Temperatur ist braucht sie hier extrem lange> um wieder abzukuehlen.
Hallo Jens,
bin erstaunt! Wie hast du smartctl auf die Schachtel bekommen? Bist du
firm und ausgestattet mit crosscompiling? Oder ist dir ein passendes
binary vor die Füße gefallen? Von Haus aus sehe ich es auf dem
nas-server nicht, "find" findet es auch nicht. Ein monitoring der
Temperatur finde ich sehr gut.
Weniger gut, wenn die Schachtel termische Probleme hat.
An smartctl bin ich interessiert, oder - weil ich nicht faul bin, an dem
Weg dahin, wie ich es selbst compilieren kann. Ist es denn möglich, perl
und mysql auf der Schachtel zum fliegen zu bringen? Spricht das magere
RAM dagegen? Gibt es schon Köpfe, die das für diese Platform zustande
gebracht haben?
Peter W. schrieb:> Wie hast du smartctl auf die Schachtel bekommen? Bist du> firm und ausgestattet mit crosscompiling? Oder ist dir ein passendes> binary vor die Füße gefallen? Von Haus aus sehe ich es auf dem> nas-server nicht, "find" findet es auch nicht. Ein monitoring der> Temperatur finde ich sehr gut.
Ich glaube mich zu erinnern, das kann man als "offizielles" Paket über
die WebGUI nachinstallieren, da gibt's 4 Pakete glaube ich, mehr nicht.
Jens D. schrieb:> Wobei es ja noch die beiden Kopien gibt ;) Also die erste so lassen wie> sie sind und nur den zweiten per "Chain-Loading" nutzten.
Ohne u-boot-prompt per UART-USB-Adapter? Ändern des u-boot-1-env gilt ja
nicht, da das Gerät im Fehlerfall genauso gebrickt wäre.
> Wobei wenn einmal ein uBoot drauf ist, was seinen Zweck erfüllt, dann> braucht man es ja nicht mehr an zufassen. Wichtiger ist, das man auf> einfacher weise den Kernel Aktuell halten kann...
Genau. Deswegen hab ich hier so penetrant auf den SATA-only-Boot-Prozess
mit Fertigbausteinen von iomega und pogoplug gedrängt. Eure
Hacker-Energie sollte in den Kernel anstatt U-Boot fließen, bevor sie
vielleicht abebbt. ;)
Ciao,
solo
solo schrieb:> Ohne u-boot-prompt per UART-USB-Adapter? Ändern des u-boot-1-env gilt ja> nicht, da das Gerät im Fehlerfall genauso gebrickt wäre.
Stimmt. So oder so heißt es Platte ausbauen und korrigieren...
solo schrieb:> ist. Wenn man also in den Skripten der initrd eingreift, reicht das aus.> Dort könnten alle Mittel vorhanden sein, um ein FS von USB zu mounten.> Ich habe gestern versucht, die initrd zu entpacken - hat aber nicht> funktioniert. Vorher kann ich nicht reinschauen, ob dort was
Versuch mal squashfs oder romfs. Nicht alle initrd sind cpio.
solo schrieb:> Das Konzept des Medion-NAS ist dagegen fragwürdig und lässt> sich wohl am ehesten mit eigener Unsicherheit bei der Firmware erklären.
Ich nehme an, die haben einfach die Zyxel-Basis so gelassen und haben
mit Linux mehr oder minder das erste Gerät gebaut.
Jens D. schrieb:> Ich denke im Falle von Medion ist es einfach so, das die ein paar> Komponenten zusammen gewürfelt haben und dabei war hat die Flash> Variante. Finde ich auch ok. So haben wir beide Möglichkeiten ;)> IMHO ist es so, das Medion auch nicht wirklich das Gerät entwickelt hat.> IMHO entwickeln die eh nichts. Es wird irgendwo fertig eingekauft und> den Namen drauf gepackt (Was auch der eigentliche Hersteller macht).> Medion ist IMHO nicht viel mehr als eine Importeur und kein Hersteller> und schon garnicht ein Entwickler. Aber das sind nur Vermutungen ;)
Im Grunde ist es Zyxel mit Hardware-Anpassungen.
Peter W. schrieb:> bin erstaunt! Wie hast du smartctl auf die Schachtel bekommen? Bist du> firm und ausgestattet mit crosscompiling? Oder ist dir ein passendes> binary vor die Füße gefallen? Von Haus aus sehe ich es auf dem> nas-server nicht, "find" findet es auch nicht. Ein monitoring der> Temperatur finde ich sehr gut.> Weniger gut, wenn die Schachtel termische Probleme hat.
Bei ArchLinuxARM => pacman -S smartmontools
Bei der zyxel-basierten Medion-Firmware gibt es auch ein SMART-Paket.
Peter W. schrieb:> An smartctl bin ich interessiert, oder - weil ich nicht faul bin, an dem> Weg dahin, wie ich es selbst compilieren kann. Ist es denn möglich, perl> und mysql auf der Schachtel zum fliegen zu bringen? Spricht das magere> RAM dagegen?
128MB RAM + 512MB Swap sollten definitiv für eine mysql-Installation
reichen. Läuft bei mir auch schon mit. Nur noch keine Datenbank dort
eingebaut.
solo schrieb:> Genau. Deswegen hab ich hier so penetrant auf den SATA-only-Boot-Prozess> mit Fertigbausteinen von iomega und pogoplug gedrängt. Eure> Hacker-Energie sollte in den Kernel anstatt U-Boot fließen, bevor sie> vielleicht abebbt. ;)
Neuerer U-Boot usw. ist auch erstmal Spielerei. Das werde ich zwar
nochmal machen. Aber nicht unmittelbar.
Das was ich zusammengestellt habe, basiert erstmal auf dem PogoPlugPro
oxnas_sata_boot.tgz von WarheadsSE, welches im Übrigen voll kompatibel
bezüglich RAM zum Medion-Gerät ist.
Einen Kernel 3.1 zu haben ist für mich auch erst mal Priorität. Meine
ersten Laufversuche mit Kernel 3.1 haben schon gezeigt, dass diese ganze
Direct SATA-Geschichte zur Umgehung des File Cache im Linux-Kernel
führt.
Soviel zur Bastelei im PLX-Kernel.
Damit kommt die Platte dann praktisch wenige Sekunden nach dem Standby
wieder hoch. Und das bei einem System auf dem nichtmal ein Syslog läuft.
Also keine Logs usw.
Das habe ich beim 3.1er nicht gehabt. Da blieb sie erstmal längere Zeit
im Standby bis der Syslog kam. Aber das lässt sich dann ja auch
anpassen.
Lucian M. schrieb:> Im 3.1-er Kernel ist derzeit arch/arm/plat-oxnas komplett weg. Das sind> doch die von Dir und ElektroMan angesprochenen schlecht implementierten> Tricksereien die Ihr jetzt the right way implementiert oder auch wegen> geringem Gewinn weglasst? Da war auch der LEON-Support drin, nun tut ja> die NIC auch ohne, aber kann es damit zu tun haben dass die in der> Kernel-Kommandozeile übergebene MAC-Adresse nicht angenommen wird?
heisst nur jetzt arch/arm/plat-ox820
das habe ich von redsquare und WarheadsSE so übernommen.
Die Tricksereien waren primär in den Dateisystemen und SATA-Treiber.
Lucian M. schrieb:> Ich glaube mich zu erinnern, das kann man als "offizielles" Paket über> die WebGUI nachinstallieren, da gibt's 4 Pakete glaube ich, mehr nicht.
Danke Lucian für den Hinweis. Hat mir geholfen - habe mir bei der
Gelegenheit neben den smarttools auch das NFS Paket geholt. Prima -
schreibe gerade einen 18 GB Molch auf das NAS. Abgesehen davon, dass man
dafür ein langes Leben braucht, bin ich nach nunmehr 2 Stunden bei 50%
also gerade mal 9 GB die auf dem NAS gelandet sind. S.M.A.R.T.
Information 50 Grad Celsius.
Es wird also 4 Stunden dauern ... Nur ein Test und nicht die übliche
Anforderung. Mit uptime sieht man ja auch immer die "load average" und
die ist nicht nennenswert 0.10, 0.16, 0.11 Es ändert sich wenig. D.h.
blödes kopieren stellt für das System keine Last dar. Die Platte wird
natürlich anderer Meinung sein.
Ich habe mir mal die Mühe gemacht, eine üppiger Default Config für das
Medion NAS im Repo abzulegen.
Ist für SATA-Boot definiert. (ox820_medion_defconfig)