Alles Rund um den MEDION LIFE P89626 NAS

[casati (Gast)]

@ElektromAn,

dann war ja meine Frage doch nicht so "dumm":

Wier repariert man also das XFS "im Fall der Fälle" - möglichst ohne 
Ausbau der Hard Disk?

Beste Grüße

[Lucian M. (lucian_m)]

Hi,

bezüglich der Fragestellung, ist es nun eine dual-core CPU bei der nur 
ein Kern aktiv ist, oder gar keine dual-core, hat uns Aldi da mit 
irreführender Werbung beschissen oder nicht, habe ich mir noch folgendes 
angeschaut, ich weiss nicht ob und wieviel es bedeutet:

~ # ls -al /sys/devices/system/cpu/
drwxr-xr-x    4 root     root             0 Dec  7 11:13 .
drwxr-xr-x    6 root     root             0 Dec  7 11:12 ..
drwxr-xr-x    3 root     root             0 Dec  7 11:13 cpu0
drwxr-xr-x    2 root     root             0 Dec  7 11:13 cpu1
-r--r--r--    1 root     root          4096 Dec  7 11:13 kernel_max
-r--r--r--    1 root     root          4096 Dec  7 11:13 offline
-r--r--r--    1 root     root          4096 Dec  7 11:13 online
-r--r--r--    1 root     root          4096 Dec  7 11:13 possible
-r--r--r--    1 root     root          4096 Dec  7 11:13 present

~ # cat /sys/devices/system/cpu/kernel_max
1
~ # cat /sys/devices/system/cpu/offline
1
~ # cat /sys/devices/system/cpu/online
0
~ # cat /sys/devices/system/cpu/possible
0-1
~ # cat /sys/devices/system/cpu/present
0-1

Was heißen die letzten beiden wohl?

~ # ls -al /sys/devices/system/cpu/cpu0/topology/
drwxr-xr-x    2 root     root             0 Dec  7 11:13 .
drwxr-xr-x    3 root     root             0 Dec  7 11:13 ..
-r--r--r--    1 root     root          4096 Dec  7 11:13 core_id
-r--r--r--    1 root     root          4096 Dec  7 11:13 core_siblings
-r--r--r--    1 root     root          4096 Dec  7 11:13 core_siblings_list
-r--r--r--    1 root     root          4096 Dec  7 11:13 physical_package_id
-r--r--r--    1 root     root          4096 Dec  7 11:13 thread_siblings
-r--r--r--    1 root     root          4096 Dec  7 11:13 thread_siblings_list

Dieses Verzeichnis ist allerdings leer:

/sys/devices/system/cpu/cpu1

[dimpflmoser (Gast)]

Jens D. schrieb:
> Also ein etwas ältere Version, denn auf der Box läuft ja: 
Linux-2.6.31.14_SMP_820
Das dürfte meiner gegrenzten Erfahrung nach kein Problem sein. Habe in 
der Arbeit Systeme, die mit Kernelversionen von 2.6.30 bis 2.6.38 
laufen.
So weit ich das bisher verstanden habe kommt es beim Root File System im 
wesentlichen drauf an welches Binary Format verwendet wird, z.B. elf, 
abi, eabi, und dann auch noch solche Details ob beim Arm der 16-Bit 
Befehlsatz (Thumb) oder 32-Bit (???) verwendet wird.
Anscheinend hat sich da aber irgendwie das Gnueabi-Format etabliert und 
wir müssen uns darum derzeit keinen Kopf machen.

> Kann ein Booten überhaupt von HDD klappen? Weil XFS Dateisystem?
Wenn ich das recht in Erinnerung habe werden keime XFS-Module geladen, 
d.h. XFS muss fest in den Kernel eincompiliert sein, demnach müsste der 
Kernel auch direkt von XFS booten können.

Ansonsten würde es doch auch nicht wirklich weh tun die Platte neu zu 
Partitionieren/Formatieren, oder?
Ich hoffe ich komme da heute Abend dazu, das zu testen.

Tschüss Dimpflmoser

[dimpflmoser (Gast)]

dimpflmoser schrieb:
> Ansonsten würde es doch auch nicht wirklich weh tun die Platte neu zu
> Partitionieren/Formatieren, oder?
> Ich hoffe ich komme da heute Abend dazu, das zu testen.
>
Bevor man da bestehende Daten sichern muss, wäre ein Boot via NFS-Root 
eventuell die sanftere Variante.

[Jens D. (jedie)]

Interesant ist /etc/init.d/rc.shutdown

Möchste man also den Zyxel Kram aus haben, sollte das so gehen:

/bin/killall -9 app_wd myhotplug
/bin/killall zyshd zyshclient zylogger

Bin gerade dabei ein debian Squeeze per debootstrap auf einen Stick zu 
packen. chroot geht schon mal ;)

[Lucian M. (lucian_m)]

dimpflmoser schrieb:
> Bevor man da bestehende Daten sichern muss, wäre ein Boot via NFS-Root
> eventuell die sanftere Variante.

Kann mann denn U-Boot mit einem Tastenschlag in der UART-Konsole 
anhalten um dann in ein Menu zu kommen? Ich kann mich erinnern, bei der 
Linkstation Pro ist das so. Allerdings hat die sowohl Kernel mit initrd, 
als auch system root auf Partitionen der Festplatte und nicht im NAND, 
also kann man dort wenich falsch machen mit Flashen, man kann immer die 
Festplatte in einen PC stecken und in den Originalzustand bringen, bei 
NAND ist das leider heikler...

[Jens D. (jedie)]

Lucian M. schrieb:
> Kann mann denn U-Boot mit einem Tastenschlag in der UART-Konsole
> anhalten um dann in ein Menu zu kommen?

Ja kann man ;)

Die Frage ist einmal: Kann man mit dem uBoot einen anderen Kernel von 
USB-Stick / TFTP oder NFS laden?
...oder kann man mit dem Kernel vom Flash ein anderes System von 
USB-Stick / TFTP oder NFS laden?

debootstrap --second-stage läuft bei mir noch ;)

[Lucian M. (lucian_m)]

Jens D. schrieb:
> Die Frage ist einmal: Kann man mit dem uBoot einen anderen Kernel von
> USB-Stick / TFTP oder NFS laden?

Das da, von mir aus gerne noch mit der Abwandlung "von 
Festplattenpartition" halt wie bei normalen PCs oder anderen NASen (wie 
die erwähnte LS-Pro von Buffalo) wäre mein Favorit.
Jedenfalls, eine Möglichkeit einen eigenen Kernel booten zu können (und 
das im uboot-NAND festklopfen, um nicht bei jedem Boot UART zu 
brauchen), das eröffnet viele Möglichkeiten, auch andere Module zu 
bauen, man denke nur an DVB-T oder DVB-S2 Sticks um einen VDR-Server 
daraus zu machen ;-)

[dimpflmoser (Gast)]

Lucian M. schrieb:
> auch andere Module zu
> bauen, man denke nur an DVB-T oder DVB-S2 Sticks um einen VDR-Server
> daraus zu machen ;-)

Genau das ist meine Anwendung, die ich im Auge habe. ;-)
Wobei ich mir jetzt einen DVB-Stick von Sundtek bestellt habe, die sind 
zwar relativ teuer und die Treiber sind closed source, allerdings lese 
ich bisher nur gutes über deren Support und deren Linux-Unterstützung. 
Der Treiber läuft im User-Space weshalb man den Kernel nicht 
modifizieren muss.

Demnach sehe ich bisher keine grundsätzlichen Hürden vor dem Einsatz als 
VDR-Server, außer dass meine Zeit halt irgendwie doch begrenzt ist.

Tschüss Dimpflmoser

[Jens D. (jedie)]

Lucian M. schrieb:
> Jedenfalls, eine Möglichkeit einen eigenen Kernel booten zu können (und
> das im uboot-NAND festklopfen, um nicht bei jedem Boot UART zu
> brauchen)

Das braucht man auch nicht jedes mal per UART zu machen. Schließlich 
kann man die "Kommandos" einfach modifizieren...


Ich überlege gerade welchen Kernel ich aus Debian nehmen sollte. 
Generell habe ich nun squeeze mit "--arch armel" drauf.

Zur Auswahl stehen:

linux-image-2.6-iop32x
linux-image-2.6-ixp4xx
linux-image-2.6-kirkwood
linux-image-2.6-orion5x
linux-image-2.6-versatile

[Jens D. (jedie)]

Also direkt von USB/Platte booten geht IMHO nicht... Den uBoot help 
spuckt nur folgende boot Einträge aus:

[code]
bootm   - boot application image from memory
bootp   - boot image via network using BootP/TFTP protocol
rarpboot- boot image via network using RARP/TFTP protocol
tftpboot- boot image via network using TFTP protocol
[/boot]

Ein bootusb gibt es nicht. Somit bleibt IMHO nur bootarg zu ändern um 
den Kernel aus dem Flash ein anderes Root unter zu schieben.

oder?

[Lucian M. (lucian_m)]

Jens D. schrieb:
> bootm   - boot application image from memory
> bootp   - boot image via network using BootP/TFTP protocol
> rarpboot- boot image via network using RARP/TFTP protocol
> tftpboot- boot image via network using TFTP protocol

Was soll genau bootm machen?

Naja, über TFTP zu booten wäre nicht so dramatisch, wenn man z.B. einen 
TFTP-server auf eine neuere Fritzbox laufen hätte, und das Kernel-Image 
in deren internen Flash oder USB gemountetem Medium...

Alternativ, kann man vielleicht später uboot selber auch ersetzten, mit 
einer "vernünftigen" Variante, aber vermutlich muß zuerst eine 
angepasste uboot-Variante erst gefunden oder entwickelt werden. Selbst 
mit einem neuen Kernel scheint es noch ein wenig zu dauern: 
http://archlinuxarm.org/forum/viewtopic.php?t=1865&p=10947
Oder kennt jemand einen anderen Ort wo die GPL-Sourcen zu diesem Kernel 
liegen, oder zu bekommen sein müssten?

[Jens D. (jedie)]

mehr Info's zu dem Hardware-Verwanten gibt es hier: 
http://archlinuxarm.org/platforms/armv6/pogoplug-provideov3

interessant dabei: http://archlinuxarm.org/os/oxnas/oxnas-install.sh

Vielleicht bekommt man von dort sourcen???


Dem bestehenden Kernel per boot Argumente ein anderes root unter zu 
schieben, funktioniert bei mir nicht. Die Angaben werden schliecht 
ignoriert. Wobei ich in den Ausgaben sehen kann, das sie vom uBoot 
übergeben werden.

Hab folgendes gemacht:

setenv bootargs console=ttyS0,115200 root=/dev/sdb1 rootfstype=ext3 rootdelay=15 elevator=cfq mac_adr=0x00,0x30,0xe0,0x00,0x00,0x01 mem=128M poweroutage=yes
run boot_nand

[Jens D. (jedie)]

Jens D. schrieb:
> Hab mir http://archlinuxarm.org/os/ArchLinuxARM-oxnas-latest.tar.gz von
> http://archlinuxarm.org/developers/downloads gezogen, aber die
> Angegebene MD5 c700bc0969fd1b71ff3eed29033e458e stimmt bei mir nicht. Es
> kommt immer 9e71b0c31ddba5d982f12b2d24f72ad8 raus!?

Ah! Anscheinend ist auf der Webseite schlicht eine falsche MD5 
hinterlegt... Denn in der Datei 
http://archlinuxarm.org/os/oxnas/oxnas-install.sh steckt nämlich 
9e71b0c31ddba5d982f12b2d24f72ad8 drin!

[Jens D. (jedie)]

Ich hab mal versucht über TFTP das uBoot aus 
http://archlinuxarm.org/os/ArchLinuxARM-oxnas-latest.tar.gz zu nutzten.

Anleitung von: 
http://www.mikrocontroller.net/articles/GoFlexHome#anderes_uBoot_Image_via_TFTP_testen

Normaler start:

U-Boot 1.1.2 (Jun 24 2011 - 09:41:57)

U-Boot code: 60D00000 -> 60D1A94C  BSS: -> 60D1F004
RAM Configuration:
        Bank #0: 60000000 128 MB
SRAM Configuration:
        64KB at 0x50000000
NAND:128 MiB
In:    serial
Out:   serial
Err:   serial
Setting Linux mem= boot arg value
Hit any key to stop autoboot:  0

Nun den das Image per tftp ziehen

$ setenv ipaddr 192.168.0.200
$ setenv serverip 192.168.0.100 
$ tftp 0x800000 uImage.pci

dann geht's los:

Wait GMAC to reset
Wait for PHY reset.
PHY is Realtek RTL8211E
Wait for link to come up..............Link up
Wait for auto-negotiation to complete
Link is 1000M
TFTP from server 192.168.0.100; our IP address is 192.168.0.200
Filename 'uImage.pci'.
Load address: 0x800000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ###########################
done
Bytes transferred = 2132324 (208964 hex)

Das laden ist schon mal Erfolgreich gewesen...
Dann starten:

$ go 0x800200 

## Starting application at 0x00800200 ...
prefetch abort
pc : [<00a00004>]    lr : [<60d03e8c>]
sp : 60cbf614  ip : ffffffff  fp : 00000000
r10: 00000000  r9 : 60ce1b00  r8 : 60cbffdc
r7 : 00000000  r6 : 00000002  r5 : 60ce1bb4  r4 : 00800200
r3 : 00000000  r2 : 00000001  r1 : 60ce1bb4  r0 : 00000001
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

Stage-1 Bootloader Tue Aug  9 16:44:00 CST 2011
...

Nun wird anscheinend wieder der alte uBoot geladen...
Evtl. ist die Addresse 0x800200 falsch?

[Lucian M. (lucian_m)]

Jens D. schrieb:
> Evtl. ist die Addresse 0x800200 falsch?

Die hast Du wohl aus dieser Anleitung für GoFlex, probier doch mal 
61000000

[dimpflmoser (Gast)]

Jens D. schrieb:
> Dem bestehenden Kernel per boot Argumente ein anderes root unter zu
> schieben, funktioniert bei mir nicht. Die Angaben werden schliecht
> ignoriert. Wobei ich in den Ausgaben sehen kann, das sie vom uBoot
> übergeben werden.
>
> Hab folgendes gemacht:
> setenv bootargs console=ttyS0,115200 root=/dev/sdb1 rootfstype=ext3 rootdelay=15 
elevator=cfq mac_adr=0x00,0x30,0xe0,0x00,0x00,0x01 mem=128M poweroutage=yes
> run boot_nand

hm, schade
mich wundert, dass Du als root 'sdb1' angegeben hast. AFAIR wird die 
interne Platte als sda eingebunden. Hast Du eine zweite Platte 
angehängt? (Wie?)

Ich sehe gerade in der Kernel-Config in der Arbeit, dass es eine Option 
gibt, die anscheinend die bootargs ignoriert. Diese Option heißt:

Always use the default kernel command string

Falls diese Option aktiviert ist müsste ja auch ein löschen der bootargs 
das System nicht richtig starten, oder?
Alternativ kann man ja mal eine andere Mac-Adresse konfigurieren und 
sehen ob die auch anders im Netzwerk erscheint.
Wofür stehen eigentlich die Optionen elevator=cfg und poweroutag=yes?

Bye Dimpflmoser

[Jens D. (jedie)]

Lucian M. schrieb:
> Die hast Du wohl aus dieser Anleitung für GoFlex, probier doch mal
> 61000000

Dann kommt statt "prefetch abort" ein "data abort"...

[dimpflmoser (Gast)]

Jens D. schrieb:
> Das laden ist schon mal Erfolgreich gewesen...
> Dann starten:
> $ go 0x800200

Hm, ich weiß noch nicht was in diesem Paket drin ist, interessant wäre 
doch aus diesem Paket den Kernel/das uImage zu extrahieren und diesen 
per TFTP zu laden.

Wie Lucian schon andeutet ist in der Original-Konfiguration die 
RAM-Adresse für das Image die 0x61000000. Außerdem würde ich dann diesen 
Kernel nicht über das Kommando go starten sondern über ein bootm.

D.h.

tftp 0x61000000 uImage
bootm 0x61000000

Ach wie gerne wäre ich jetzt daheim....

[Jens D. (jedie)]

Ja, da kommt was... Anscheinend ist es überhaupt nicht uBoot sondern der 
Kernel???

Ausgaben:

...
Filename 'uImage.pci'.
Load address: 0x61000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ###########################
done
Bytes transferred = 2132324 (208964 hex)
$ bootm 0x61000000
## Booting image at 61000000 ...
   Image Name:   Linux-2.6.31.6_SMP_820
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2132260 Bytes =  2 MB
   Load Address: 60008000
   Entry Point:  60008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux................................................................................................................................. done, booting the kernel.
[    0.000000] Linux version 2.6.31.6_SMP_820 (root@ProDev) (gcc version 4.6.0 20110429 (prerelease) (GCC) ) #99 SMP Sun May 29 03:04:43 EDT 2011
[    0.000000] CPU: ARMv6-compatible processor [410fb025] revision 5 (ARMv7), cr=00c5387f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: Oxsemi NAS
[    0.000000] 1 memory region
[    0.000000] Ignoring unrecognised tag 0x00000000
[    0.000000] Memory policy: ECC disabled, Data cache writealloc
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
[    0.000000] Kernel command line: console=ttyS0,115200 elevator=cfq mac_adr=0x00,0x30,0xe0,0x00,0x00,0x01 mem=128M poweroutage=yes
[    0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Memory: 128MB = 128MB total
[    0.000000] Memory: 125524KB available (3636K code, 296K data, 128K init, 0K highmem)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:96
[    0.000000] OX820_RPS_init_irq: interrupts 64 to 96
[    0.010000] Console: colour dummy device 80x30
[    0.010000] console [ttyS0] enabled
[    0.020000] Calibrating delay loop... 299.00 BogoMIPS (lpj=1495040)
[    0.240000] Security Framework initialized
[    0.240000] Mount-cache hash table entries: 512
[    0.250000] CPU: Testing write buffer coherency: ok
[    0.250000] Calibrating local timer... 374.49MHz.
[    0.320000] CPU1: Booted secondary processor
[    0.420000] Calibrating delay loop... 299.82 BogoMIPS (lpj=1499136)
[    0.630000] Brought up 2 CPUs
[    0.640000] SMP: Total of 2 processors activated (598.83 BogoMIPS).
[    0.650000] NET: Registered protocol family 16
[    0.650000] Number of DMA channels = 4, version = 4
[    0.660000] Reserving a DMA channel for DirectRAID
[    0.660000] Allocating 389 SRAM generic DMA descriptors

Danach kommen zwei Pipse, dann längere Zeit nichts mehr und dann noch 
einen Pieps...

Vielleicht passen nun die bootargs einfach nur nicht?

[Lucian M. (lucian_m)]

Jens D. schrieb:
> Ja, da kommt was... Anscheinend ist es überhaupt nicht uBoot sondern der
> Kernel???

Natürlich, ich war über Deine Aussage ein wenig verwundert, das uBoot 
hast Du ja im NAND Speicher, um ein anderes zu verwenden glaube ich 
musst Du es erstmal überflashen...

> [    0.320000] CPU1: Booted secondary processor
> [    0.420000] Calibrating delay loop... 299.82 BogoMIPS (lpj=1499136)
> [    0.630000] Brought up 2 CPUs
> [    0.640000] SMP: Total of 2 processors activated (598.83 BogoMIPS).

Na bitteschön, dual-core!!!!

> Danach kommen zwei Pipse, dann längere Zeit nichts mehr und dann noch
> einen Pieps...
>
> Vielleicht passen nun die bootargs einfach nur nicht?

Vielleicht braucht dieser Kernel einfach auch paar Module, die im 
Aldi-NAS unter /lib/modules fehlen (abgesehen von der unterschidlichen 
Kernel-Version), im Arch-Linux Image sind es jede Menge, unter anderem 
auch scheinbar einige Plattform-spezifische, die der "Aldi-Kernel" 
vielleicht monolytisch drinn hat...

Übrigens, wie genau waren denn die uBoot Komandos die nun dazu geführt 
haben?

Was Du noch probieren könntest: den anderen Kernel aus dem Arch-Linux 
Image, den mit "noPCI"...

Lucian

[Jens D. (jedie)]

"noPCI" habe ich auch schon Probiert. Auch einige bootargs Variationen. 
Aber er bleibt an der selben Stelle stehen...

Ich dachte es wäre uBoot, weil ich anscheinen 
http://archlinuxarm.org/os/oxnas/oxnas-install.sh falsch interpretiert 
habe ;)

Die Frage ist, ob man ein uBoot von diesem 
http://archlinuxarm.org/platforms/armv6/pogoplug-provideov3 bekommen 
kann... Hab aber noch nichts gefunden :(

Bin mir nicht sicher ob der Kernel zu dem Zeitpunkt überhaupt schon auf 
Platte zugreift...

[Jens D. (jedie)]

Nochmal zur anderen Idee:

/etc/init.d/rcS ruft ja /etc/profile auf.
rcS ist schreibgeschützt, aber profile kann man anpassen.

In profile könnte man also hingehen und den USB-Stick mit einem eigenen 
OS drauf mounten und einen chroot machen und damit dann z.B. 
/etc/inittab starten...

Man muß einzig /etc/profile ändern und ansonsten das Ogirinal System 
unangetastet lassen.

Was meint ihr?

[Jens D. (jedie)]

Jetzt muß ich mich aber wundern! Ich hab /etc/profile geändert und neu 
gestartet und danach ist es wieder der alte Inhalt!

Es hat aber definitiv mal geklappt, siehe: 
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"

[ElektromAn (Gast)]

@Jens D.

Es fehlt ein RootFS !!!.

Ob jetzt dies mit dem Kernel (als InitRamFS) oder als zusätzliches 
Datei geladen wird ist egal.

Für die zusätzliche Datei gibt es glaube ich noch eine uBoot Option.

Habe mir mal die Kernelsourcen von 
http://download.pogoplug.com/opensource/pro/pogopro-linux-2.6.31.6-r2.tar.bz2 
"gezogen".

Die Treiber für USB, SATA und Ethernet sind drin.

E-mAn

[David (Gast)]

Hallo Jens D.,

ich weiß nicht ob es euch hilft - alle Änderungen unter

/usr/local/zy-pkgs/etc/init.d

bleiben auch nach dem Neustart erhalten. Ich habs so geschafft dass der 
ssh-Zugang über dropbear gleich beim Hochfahren verfügbar ist und ich 
nicht jedesmal das Backdoor-Script für Telnet starten muss.

mfg DaViD

[Jens D. (jedie)]

@David: Kannst du das vorgehen im Wiki festhalten?

@ElektromAn: Ich hab eigentlich ein RootFS auf dem USB-Stick, welches 
/dev/sdb1 ist (Gesteckt im vorderen USB-Platz). Meinst du deswegen 
bricht der Bootvorgang ab? Sollte da nicht irgendein Fehler kommen?

[Jens D. (jedie)]

Ach, mein debootstrap Kram zum vorbereiten eines Sticks hab ich hier 
aufgeschrieben: 
http://www.mikrocontroller.net/articles/P89626/debootstrap

[dimpflmoser (Gast)]

Jens D. schrieb:
> @ElektromAn: Ich hab eigentlich ein RootFS auf dem USB-Stick, welches
> /dev/sdb1 ist (Gesteckt im vorderen USB-Platz). Meinst du deswegen
> bricht der Bootvorgang ab? Sollte da nicht irgendein Fehler kommen?

Hi,

also ich schätze, der Kernel kann bei der Suche nach dem RootFS noch 
nicht auf /dev/sdb1 zugreifen. Das wird ja erst später durch Udev 
angelegt.
Das RootFS muss direkt für den Kernel zugreifbar sein, d.h. entweder 
dass die enthaltenen Devicetreiber mit dem Device sprechen können, was 
bei /dev/sda[12] ja der Fall ist, oder man muss dem Kernel eine intird 
mitgeben, in die die notwendigen Komandos und Treiber zum einbinden des 
externen Laufwerks liegen.

Ich kann's ja aktuell leider nicht selbst testen, aber versuche doch mal 
bitte ob der Arch-Kernel auf /dev/sda1 zugreifen kann.
Wäre es für Dich ein großer Aufwand sda2 frei zuräumen und das Rootfs 
wie es von Arm-Arch kommt auf sda2 zu spielen? Dann müsste man halt etc 
fstab noch anpassen und als rootfs /dev/sda2 angeben.

Allerdings gehe ich davon aus, dass es erheblich einfacher ist das 
Arch-Rootfs auf einem NFS-Server zur Verfügung zu stellen, wobei wir 
nicht wissen ob der Kernen einen Support für ein NFS-Root hat.
Wobei, das könnte man leicht testen indem du als bootargs folgendes 
angibst:

setenv bootargs (...) root=/dev/nfs rw nfsroot=<serverip>:/srv/rootfs ip=<nas-ip>::<rooterip>:<netmask>:::off

Dann bootest Du den Kernel per bootm ....
Im Output solltest Du dann sehen, dass das Ethernetinterface 
konfiguriert wird und er versucht sich mit den NFS-Server zu verbinden, 
was dann fehl schlägt.
Falls es dazu kommt wissen wir dass der Kernel grundsätzlich nfsroot 
kann und wir können einen NFS-Server aufsetzen.

NFS hätte halt den Vorteil, dass man nichts überschreiben muss.

Noch ein Hinweis:
Bei deinen Beschreibungen Deiner Aktionen wäre es eventuell hilfreich 
wenn Du die Komandos, die Du absetzt auch hier im Forum wieder gibst, 
dann fällt es eventuell leichter zu verstehen was Du gemacht hast.

Tschüss Dimpflmoser

[Jens D. (jedie)]

dimpflmoser schrieb:
> setenv bootargs (...) root=/dev/nfs rw nfsroot=<serverip>:/srv/rootfs 
ip=<nas-ip>::<rooterip>:<netmask>:::off

ich hab das Versucht. Einmal mit dem Eingebauten Kernel: Der hat normal 
gebootet, wie immer. Spricht dafür das er bootargs ignoriert.
Einmal mit "uImage.pci": Bleibt wieder an der selben Stelle stehen. 
Ausgaben genau die selben wie bei 
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS" (bis 
auf "Kernel command line:")

Übrigens sehe ich immer in "Kernel command line:" das zumindest meine 
geänderten bootargs übergeben werden.


Ich schätze uBoot muß halt auch auf USB bzw. NFS zugreifen können, damit 
das Funktioniert.
Ich hatte auch mal uBoot von 
http://jeff.doozan.com/debian/uboot/files/uboot/uboot.mtd0.goflexnet.jeff-2010-10-23.kwb 
und http://people.debian.org/~tbm/u-boot/2011.03-6/sheevaplug/u-boot.kwb 
probiert. Die liefen aber auch nicht...

[dimpflmoser (Gast)]

Jens D. schrieb:
> Übrigens sehe ich immer in "Kernel command line:" das zumindest meine
> geänderten bootargs übergeben werden.
Das ist ja zumindest mal ein gutes Zeichen.

> Ich schätze uBoot muß halt auch auf USB bzw. NFS zugreifen können, damit
> das Funktioniert.
Nee, sobald der Kernel geladen ist, d.h. sobald Du die Zeile

Linux version 2.6.31.14_SMP_820 (root@Neo) (gcc version 4.3.2 (crosstool-NG-1.8.0) ) #2 SMP Wed Oct 5 21:54:14 CST 2011

siehst hat U-Boot nichts mehr zu melden, dann hat der Kernel übernommen 
und der muss dann über seine Treiber die Geräte zur Verfügung stellen.

U-Boot benötigt man um den Kernel selbst zu laden, d.h. entweder so wie 
Du das jetzt machst per tftp oder halt vom USB-Stick o.ä.
Beim Laden des RootFS hat der der Bootloader keine Aktien mehr.

Ich finde es seltsam, dass beim Arch-Kernel nur so wenig Meldungen sind. 
Diese Meldungen hören in der Phase auf wenn die einzelnen Devices 
geladen werden. Wir sind da noch weit vom Mounten des RootFS entfernt.

Es scheint mir eher so, dass der Kernel versucht ein Device zu 
initialisieren, das auf unserer Kiste nicht drauf ist und dann 
abschmiert. Selbst dann müsste ja noch ein 'Kernel panic' kommen.

Mir kommt noch ein anderer Aspekt: Könnte es sein, dass da auf dem 
Board/Prozessor ein Watchdog initialisiert wurde, dieser während der 
U-Boot-Phase und dem Laden des Kernels nicht zurückgesetzt wurde und das 
Piepen vom Watchdog kommt?

Hast Du mal versucht, die Kiste für einige Zeit (1-2 Minuten) im U-Boot 
zu lassen ohne, dass Du eine Eingabe machst? Was geschieht da?

> Ich hatte auch mal uBoot von
> http://jeff.doozan.com/debian/uboot/files/uboot/ub...
> und http://people.debian.org/~tbm/u-boot/2011.03-6/she...
> probiert. Die liefen aber auch nicht...

Wie hast Du den U-Boot ausprobiert? Hast Du neu geflashed?

Was mich noch interessieren würde ob einer von beiden Kernel mit einer 
initrd arbeitet? Wo liegt die? Was steckt da drin? Kann man die 
Modifizieren?

Tschüss Dimpflmoser

[Jens D. (jedie)]

dimpflmoser schrieb:
> Wie hast Du den U-Boot ausprobiert? Hast Du neu geflashed?

Ne, um gottes willen ;) Ich glaube, wenn uBoot nicht mehr will, dann 
kann man per UART nichts mehr machen, dann muß man JTAG nehmen. Ich hab 
zwar ein JTAG<->USB Modul aus China hier, aber nie genutzt. Da wäre auch 
die Frage, wo die JTAG Schnittstelle sitzt...

uBoot probieren, geht ähnlich wie den Kernel per TFTP starten, 
beschreibung hier: 
http://www.mikrocontroller.net/articles/GoFlexHome#anderes_uBoot_Image_via_TFTP_testen 
basiert auf http://jeff.doozan.com/debian/uboot/build_uboot.htm

[Lucian M. (lucian_m)]

Jens D. schrieb:
> uBoot probieren, geht ähnlich wie den Kernel per TFTP starten,
> beschreibung hier:
> http://www.mikrocontroller.net/articles/GoFlexHome...
> basiert auf http://jeff.doozan.com/debian/uboot/build_uboot.htm

Das ist ja cool, dass man den bootloader chainload-en kann zur Probe, 
bevor man sich die Kiste zerflasht...

dimpflmoser schrieb:
> Was mich noch interessieren würde ob einer von beiden Kernel mit einer
> initrd arbeitet? Wo liegt die? Was steckt da drin? Kann man die
> Modifizieren?

Die Kernel-Kommandozeile sollte dann im uBoot Environment sowas wie

initrd=0x00800040

 (ist bei meiner Linkstation so) enthalten, oder?

[Jens D. (jedie)]

Dem ist IMHO nicht so, siehe: 
http://www.mikrocontroller.net/articles/P89626#uboot_env

[ElektromAn (Gast)]

@Jens D.

Die Position von RootFS kannst du per Kernelcmdline angeben.
z.B. root=/dev/sda1

Das nicht angezeigt wird kann dran liegen das ggf. die Puffer der 
seriellen Schnittstelle etwas groß sind. Normalerweise sollte aber eine 
Zeile erscheinen wie "Missing RootFS"

@dimpflmoser
Es gibt aber auch System die ohne udev auskommen. Dort sind die 
Device-Nodes in /dev hardcoded angelegt worden.

ggf. geht es auch mit busybox

mount -t procfs procfs /proc
mount -t sysfs sysfs /sys
busybox mdev -s

ggf. auch mal die Anzahl der CPUs begrenzen.

maxcpus=  [SMP] Maximum number of processors that  an SMP kernel
      should make use of.  maxcpus=n : n >= 0 limits the
      kernel to using 'n' processors.  n=0 is a special case,
      it is equivalent to "nosmp", which also disables
      the IO APIC.

E-mAn

[ElektromAn (Gast)]

@Lucian M.

mit

initrd=0x00800040

dann sollte an der Stelle auch ein initrd sein.

Achtung :
initrd != iniramfs

E-mAn

[Lucian M. (lucian_m)]

ElektromAn schrieb:
> dann sollte an der Stelle auch ein initrd sein.
>
> Achtung :
> initrd != iniramfs

Sorry, ich hatte unvollständig gepastet, danach konnte ich nicht mehr 
editieren weil ein neuer Posting schon da war. Ist eher so:

GenLSPro ~ # fw_printenv
bootargs=$(bootargs_base) $(bootargs_root)
baudrate=115200
loads_echo=0
rootpath=/nfs/arm
cpuName=926
CASset=min
MALLOC_len=4
ethprime=egiga0
bootargs_end=:::DB88FXX81:eth0:none
buffalo_ver=BOOTVER=1.01
build_time=10:35:38
initrd=initrd.buffalo
kernel=uImage.buffalo
bootargs_base=console=ttyS0,115200
bootargs_root=root=/dev/sda2 rw initrd=0x00800040,15M panic=5
def_tftp=tftp 0x00100000 $(kernel);tftp 0x00800000 $(initrd);setenv bootargs $(bootargs_base) $(bootargs_root) $(buffalo_ver);bootm 0x00100000 0x00800000
usb0Mode=host
usb1Mode=host
ethact=egiga0
ethaddr=00:16:01:41:2D:F5
ipaddr=192.168.178.103
stdin=serial
stdout=serial
stderr=serial
enaMonExt=no
enaFlashBuf=yes
enaCpuStream=no
bootdelay=3
disaMvPnp=no
overEthAddr=no
force_tftp=1
serverip=192.168.178.100
bootcmd=ide reset; ext2load ide 1:1 0x00100000 /$(kernel);ext2load ide 1:1 0x00800000 /$(initrd);setenv bootargs $(bootargs_base) $(bootargs_root) $(buffalo_ver);bootm 0x00100000 0x00800000
GenLSPro ~ #

[Christian (Gast)]

Christian schrieb:
> Befüllen des NAS stieg die Temperatur des Gerätes bedenklich an. Nach
> einer halben Stunde Betrieb zeigte S.M.A.R.T. 59°C an.
> Habt ihr hier ähnliche Werte oder habe ich hier ein "Montagsgerät"
> erwischt?
Habe mal spaßeshalber eine Supportanfrage bei Medion gestellt. Heute kam 
folgende Antwort:
"Aufgrund Ihrer Fehlerbeschreibung gehen wir von einem Defekt aus. Gerne 
bieten wir Ihnen an, das Gerät in unserer Fachwerkstatt zu überprüfen."
Da kann Medion dann aber wohl alle Geräte zurücknehmen ...

[ElektromAn (Gast)]

@Lucian M.

Deine Addresse von initrd, TFTP zu kernelcmdline, stimmt nicht.
müssen beide die gleichen Addressen sein.

Stimmt die Größenangabe deiner initrd mit 15MB (entpackte Größe) ?

E-mAn

[Lucian M. (lucian_m)]

ElektromAn schrieb:
> Deine Addresse von initrd, TFTP zu kernelcmdline, stimmt nicht.
> müssen beide die gleichen Addressen sein.
Ja, tun sie nicht, die eine ist für den Fall, wenn über tftp kernel und 
initrd bezogen werden, der andere, der Alltag bei den Buffalo LS-GL, 
sowohl kernel als auch initrd werden von /dev/sda1 geladen, so bootet 
meine Linkstation...

ElektromAn schrieb:
> Stimmt die Größenangabe deiner initrd mit 15MB (entpackte Größe) ?
Inetwa, ja, entpackt hat die initrd 12MB

[Rainer (Gast)]

David schrieb:
> ich weiß nicht ob es euch hilft - alle Änderungen unter
> /usr/local/zy-pkgs/etc/init.d
> bleiben auch nach dem Neustart erhalten

Ich habe es geschafft mit Dropbear und Winscp dank des Tipps mit dem 
Pfad /usr/local/zy-pkgs/etc/init.d/ dropbear dauerhaft zum Laufen zu 
bekommen und Winscp kann auch die Dateien anzeigen. Keys sind erzeugt 
und dropbear korrekt geladen
Was ich nicht hinbekommen habe, ist der Zugriff auf die Dateien, ich 
bekomme den Hinweis

SCP konnte für den Start der Übertragung nicht ausgeführt werden. 
Bitte stellen Sie sicher, dass SCP auf dem Server installiert ist 
und die $PFAD- Variable den Pfad zu SCP enthält. Anstatt SCP können Sie auch SFTP probieren.
Befehl gescheitert mit Beendigungscode 127.

Die Pfad-Variable habe ich mal gesetzt auf /var/ftp
Soweit ich gelesen habe sollte ich einen symlink auf die scp binaries 
setzen, aber die habe ich ja nicht..!?

Was muss ich noch machen? Danke im voraus für den Tipp

[SP()()KY (Gast)]

Christian schrieb:
> Christian schrieb:
>> Hat eigentlich schon mal jemand die Datenintegrität überprüft? Ich
>> stelle gerade mit Entsetzen fest, daß ein Großteil der übertragenen
>> Dateien defekt ist.
>
> Eine heiße Spur habe ich jetzt gefunden. Die Fehler waren gut
> reproduzierbar. Irgendwann ist mir aufgefallen, daß nur Dateien
> betroffen waren die potentielle Wirte für Viren sind. Nach Abschalten
> des Avast Antivir wurden die Dateien fehlerfrei aufs NAS geschrieben,
> ebenso wenn ich die Dateiendungen umbenannt habe. Interessanterweise
> tritt das Problem nicht, auf wenn ich die selben Dateien auf meine
> beiden selbst aufgesetzten Samba-Server schreibe (auch beide GBit-LAN
> und etwas schneller als das Medion NAS).
> Hat jemand eine Idee wie man nun dahinterkommt wer schuld ist; das NAS,
> der Virenscanner, Windows 7, mein PC bzw. die LAN-Treiber?
> Die Situation ist schon übel; es werden fehlerhafte Dateien geschrieben,
> man merkt es aber nur bei einem byteweisen Vergleich Original zu Kopie.
>
> Falls noch jemand das NAS zusammen mit Windows 7 64 Bit und Avast!
> Antivir im Einsatz hat wäre es super wenn er das auch mal testen könnte.
> Auffällig waren bei mir vor allem PDF, HTM(L), EXE, HLP.

Kann ich bestätigen, Win 7, 64 Bit Home Premium, Avast Antivir

Habe verschiedene Dokumente via Win Explorer auf die NAS kopiert, davon 
sind 90% schrott. (File Format waren PDF, DOC, RTF, EPUB, MOBI, JPG)

[Hermann K. (hermannk)]

SP()()KY schrieb:
> Christian schrieb:
>> Christian schrieb:
>>> Hat eigentlich schon mal jemand die Datenintegrität überprüft? Ich
>>> stelle gerade mit Entsetzen fest, daß ein Großteil der übertragenen
>>> Dateien defekt ist.
>>
>
> Kann ich bestätigen, Win 7, 64 Bit Home Premium, Avast Antivir
>
> Habe verschiedene Dokumente via Win Explorer auf die NAS kopiert, davon
> sind 90% schrott. (File Format waren PDF, DOC, RTF, EPUB, MOBI, JPG)

Das P89626 NAS ist mein drittes NAS Laufwerk und mein erstes, das 
brauchbar ist.

Da meine bisherigen Laufwerke mit CIFS (=SAMBA) und FTP langsam und 
unzuverlässig waren, habe ich hier direkt mit rsync über NFS angefangen. 
Die Hosts sind drei verschiedene Rechner unter Ubuntu. In diesen 
Umgebungen habe ich keine Kopierfehler gefunden. Die Fährte WINDOWS 
Explorer // SAMBA // Antivir scheint heiß zu sein.

[Lucian M. (lucian_m)]

Hermann K. schrieb:
> Da meine bisherigen Laufwerke mit CIFS (=SAMBA) und FTP langsam und
> unzuverlässig waren, habe ich hier direkt mit rsync über NFS angefangen.
> Die Hosts sind drei verschiedene Rechner unter Ubuntu. In diesen
> Umgebungen habe ich keine Kopierfehler gefunden.

Wie mountest Du denn genau (bitte poste mal die Parameter) die nfs 
shares der NAS unter Linux so das der Transfer schnell ist? Wie sind die 
MTU Einstellungen am NAS und an diesen Rechnern?

[Neox2222x (Gast)]

Hat es jetzt eigentlich schon jemand geschafft pyload auf der Kiste zum 
Laufen zu bringen?
Wenn ja, bitte ich um eine "Anleitung" die auch ein fast DAU versteht
Danke und viel Spaß weiterhin

[matz3e (Gast)]

Ja die Idee hat ich auch schon ... kommm aber nicht vor dem Wochenende 
dazu es zu testen.

[ElekromAn (Gast)]

@Rainer dropbear
Du musst einen Symlink von dbscp nach scp machen.
scp sollte im Verzeichnis /usr/bin sein.

z.B.

ln -s dbscp /usr/bin/scp

@all mit defekten Files
Das Problem ist erstmal herauszufinden wo der Fehler ist.
Daher diese Sache mit md5sum und Co.
Kann sein das da ein Filelocking fehlt.

Testaufbau:
Datei nach NAS übertragen.
Auf dem PC und auf dem NAS (telnet/ssh) die md5 oder sha1 Summe prüfen.
Die Prüfung auf dem NAS ist wichtig, da die Datei ja sonst wieder 
zurück auf dem PC übertragen wird.

Dies einmal mit und ohne Virenscanner machen.

[Christian (Gast)]

Hermann K. schrieb:
> Die Fährte WINDOWS
> Explorer // SAMBA // Antivir scheint heiß zu sein
Nur in Verbindung mit der konkreten SAMBA-Implementierung auf dem Medion 
NAS. Die gleichen Windows-Systeme hatten keine Probleme mit anderen 
Samba-Servern. Und der Fehler ist einem Posting zufolge auch schon in 
Verbindung mit Norton Internet Security 2012 aufgetreten. Sorry wenn ich 
diesen Thread hier mit lästigen Berichten über Bugs des Gerätes zumülle 
anstatt Beiträge zum eigentlichen Thema "how to hack this device" zu 
leisten.

[BillX (Gast)]

@christian
mach lieber einen neuen thread auf "Warum noten schei*** ist". Ich 
glaube nicht das das ein Fehler des NAS ist.

[Jens D. (jedie)]

SP()()KY schrieb:
> Kann ich bestätigen, Win 7, 64 Bit Home Premium, Avast Antivir
>
> Habe verschiedene Dokumente via Win Explorer auf die NAS kopiert, davon
> sind 90% schrott. (File Format waren PDF, DOC, RTF, EPUB, MOBI, JPG)

Hab nun auchmal tests gemacht. Verschiedene Dateien in Unterschiedlicher 
Größe: MD5/SHA1 hashes auf Win-Rechner erstellt, auf NAS Freigabe 
kopiert und wieder am Win-Rechner verglichen. Dabei ist kein einziger 
Fehler Aufgetreten.

Win7 64Bit pro, Antivir 10.2.0.704, GB-LAN

[Mackau (Gast)]

Ich wollte den Medion NAS als Backupserver für mein QNAP nutzen.
Beim Sync mit ftp von meinem QNAP NAS (ca. 20-30 GB) lag die Temp. über 
50°C.
Hinzu kommt noch, dass das Gerät nach längerer Betriebszeit und unter 
Last abstürzt. Kein Zugriff mehr auf die Ablagen oder das Webmenü. Da 
hilft nur ausmachen und wieder einschalten. Nix mit passiv Kühlung...

[Stefan N. (apophis81)]

Hallo zusammen,

ich hätte mal eine Frage. Wenn wir wissen, wo das NAS die Pakete 
herholt, könnte man dann nicht einen internen Proxy einschalten, der 
alle Anfragen auf einen eigenen Webserver umlenkt, aufdem dann die 
Updatepakete des Zyksel liegen? Vielleicht wäre das ein Ansatzpunkt.
Komme leider zur Zeit selber nicht dazu es mal auszulesen, welche 
Anfragen das NAS genau schickt über das Netzwerk.
Grüße
Apophis

[Jens D. (jedie)]

Zum Thema cross-compiler...

Man kann anscheinend auch einfach Pakete aus Debian aus dem armel Zweig 
nehmen und nutzten...

Ich hab das mal mit dropbear gemacht: 
http://packages.debian.org/squeeze/dropbear

Download kann man die .deb datei unter: 
http://packages.debian.org/squeeze/armel/dropbear/download

Eine Liste der Dateien hat man hier: 
http://packages.debian.org/squeeze/armel/dropbear/filelist

Das Binary findet man unter /usr/sbin/dropbear das mal auf die Box 
kopieren und starten, geht:

/i-data/6764ac2f/admin/bin # ./dropbear -h
Dropbear sshd v0.52
...

[Jens D. (jedie)]

Stefan N. schrieb:
> ich hätte mal eine Frage. Wenn wir wissen, wo das NAS die Pakete
> herholt,

Hab ich im Wiki Festgehalten: 
http://www.mikrocontroller.net/articles/P89626#Paketverwaltung

IMHO wäre es am einfachsten, wenn man das read-only Dateisystem 
überwinden könnte. Dann könnte man das ganze System umkrempeln.

Mit einem einfachen "mount -o remount,rw /bla" ist es allerdings nicht 
getan, siehe: Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"

[Jens D. (jedie)]

Rainer schrieb:
> Ich habe es geschafft mit Dropbear und Winscp dank des Tipps mit dem
> Pfad /usr/local/zy-pkgs/etc/init.d/ dropbear dauerhaft zum Laufen zu
> bekommen

Dazu habe ich noch eine Frage: Hast du dabei 
/usr/local/zy-pkgs/etc/init.d/ZYPKG_DEPS geändert?
Was hast du genau gemacht?


btw. das mit dem debian Quellen geht z.B. bei 
http://packages.debian.org/squeeze/armel/nano/download anscheinend 
nicht.

[Jens D. (jedie)]

Ach, laut Webseite http://matt.ucc.asn.au/dropbear/dropbear.html ist 
dropbear auch "Compatible with OpenSSH ~/.ssh/authorized_keys public key 
authentication"

Hab mal authorized_keys in /home/shares/.ssh/ hinterlegt, klappt aber 
nicht. Ein test mit /home/USERNAME/.ssh/authorized_keys tut's auch 
nicht...

Jemand eine Idee dazu?

[Jens D. (jedie)]

Zum Thema dropbear, ich hab nun folgendes gemacht:

/ # cat /usr/local/zy-pkgs/etc/init.d/ZYPKG_DEPS
# Dependency for zypkgs

# START-UP (DON'T REMOVE THIS LINE!)
/i-data/6764ac2f/admin/bin/start_dropbear.sh
/usr/local/zy-pkgs/etc/init.d/DyDNS
/usr/local/zy-pkgs/etc/init.d/SMART
/usr/local/zy-pkgs/etc/init.d/BackupPlanner
/usr/local/zy-pkgs/etc/init.d/NFS


# SHUTDOWN (DON'T REMOVE THIS LINE!)
/usr/local/zy-pkgs/etc/init.d/NFS
/usr/local/zy-pkgs/etc/init.d/BackupPlanner
/usr/local/zy-pkgs/etc/init.d/SMART
/usr/local/zy-pkgs/etc/init.d/DyDNS

Also einfach nur unter # START-UP die start_dropbear.sh Aufgerufen, die 
so aussieht:

/ # cat /i-data/6764ac2f/admin/bin/start_dropbear.sh
#!/bin/sh

set -x
cd $(dirname ${0})
killall dropbear

./dropbear -I 480 -j -k -r dropbear_rsa_host_key -E

Ich Frage mich, was passiert, wenn man ein neues Paket installiert, bzw. 
eins deinstalliert..

btw, das sollte in's wiki ;)

[Jens D. (jedie)]

Hab nochmal Tests bzgl. der "profile" datei gemacht:

/etc # mv profile /usr/local/zy-pkgs/etc/profile
/etc # ln -s /usr/local/zy-pkgs/etc/profile /etc/profile
/etc # echo "# TEST" >> profile 
/etc # cat profile 
#!/bin/sh

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/zyxel/sbin:/usr/local/zy-pkgs/bin:/zyxel/htp
export PATH

LD_LIBRARY_PATH=/usr/local/zy-pkgs/lib
export LD_LIBRARY_PATH

# TEST
/etc # reboot

Nach dem Neustart, ist der Symlink wieder weg und die "default" profile 
wieder da:

/etc # ls -la profile 
-rw-r--r--    1 root     root           199 Oct  5 13:21 profile
/etc # cat profile 
#!/bin/sh

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/zyxel/sbin:/usr/local/zy-pkgs/bin:/zyxel/htp
export PATH

LD_LIBRARY_PATH=/usr/local/zy-pkgs/lib
export LD_LIBRARY_PATH

/etc #

Also nochmal direkt:

/etc # echo "# TEST" >> profile
/etc # reboot

Wie soll es sein, profile ist nach Neustat wieder resettet...

Mich würde das ja eigentlich nicht verwundern, wenn das Ändern über 
einen Neustart hinaus nicht früher geklappt hätte....

[Jens D. (jedie)]

Jens D. schrieb:
> btw, das sollte in's wiki ;)

Gemacht: http://www.mikrocontroller.net/articles/P89626/dropbear


Zum Thema Wiki Seite nicht mehr änderbar: 
Beitrag "Wiki Seite nicht mehr editierbar?"

[Jens D. (jedie)]

dimpflmoser schrieb:
> Wofür stehen eigentlich die Optionen elevator=cfg und poweroutag=yes?

"elevator=cfg" steht wohl für den I/O Scheduler "Completely Fair 
Queuing"
gefunden hier: 
https://www.redhat.com/magazine/008jun05/features/schedulers/


Anscheinend kann man doch die bootargs ändern!

Hab mal "initcall_debug printk.time=1" eingefügt (in uBoot gemacht):

setenv bootargs console=ttyS0,115200 initcall_debug printk.time=1 elevator=cfq mac_adr=0x00,0x30,0xe0,0x00,0x00,0x01 mem=128M poweroutage=yes
run boot_nand

und siehe da, ich bekomme ziemlich viele debug ausgaben, wie diese:

...
[   11.510000] initcall sddr09_init+0x0/0x18 returned 0 after 91012 usecs
[   11.510000] calling  sddr55_init+0x0/0x18 @ 1
[   11.630000] usbcore: registered new interface driver ums-sddr55
[   11.640000] initcall sddr55_init+0x0/0x18 returned 0 after 117542 usecs
[   11.640000] calling  usbat_init+0x0/0x18 @ 1
[   11.750000] usbcore: registered new interface driver ums-usbat
[   11.760000] initcall usbat_init+0x0/0x18 returned 0 after 108757 usecs
[   11.770000] calling  mousedev_init+0x0/0xa4 @ 1
...

Anscheinend gehen aber einfach nicht alle... Denn mit einem 
"init=/bla/bla" startet er dennoch normal durch. "/proc/cmdline" zeigt 
dennoch die Änderungen an...

"loglevel=7" macht auch nichts.

[BigMerlin (Gast)]

Weiß zufällig jemand ob man für die Fotoslideshow von extern einen 
seperaten Port brauch?

Wenn ich von extern drauf zugreife sehe ich die bilder einzeln...was 
aber nicht geht ist die slideshow...brauch ich da zusätzlich einen 
ofenen port?

Mfg

[ElektromAn (Gast)]

Hallo,

kann mit bitte einer mal die Ausgabe von

/lib/lib.so.6

posten

[Lucian M. (lucian_m)]

ElektromAn schrieb:
> kann mit bitte einer mal die Ausgabe von/lib/lib.so.6

Du meintest bestimmt

~ # /lib/libc.so.6
GNU C Library stable release version 2.9, by Roland McGrath et al.
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.3.2.
Compiled on a Linux >>2.6.32-21-generic-pae<< system on 2010-10-02.
Available extensions:
        crypt add-on version 2.1 by Michael Glad and others
        Native POSIX Threads Library by Ulrich Drepper et al
        Support for some architectures added on, not maintained in glibc core.
        BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

[David W. (heruur84)]

Hallo!

Ich konnte leider nichts in der Wiki ändern - deshalb hier mein Weg zum 
dauerhaften SSH-Zugang (auch nach einem Neustart):

SSH kann mann dauerhaft aktivieren (auch nach einem Neustart) indem man 
folgendes macht:

1. Die Binaries von https://sites.google.com/site/medionlifep89626/ 
herunterladen (Binaries von Andreas Ehrle, danke!)

2.) Die dropbearmulti auf der internen Festplatte ablegen
    (z. B.: (/i-data/6764ac2f)/public/bin/dropbear)

3.) die benötigten Symlinks erstellen und die Zugriffsrechte ändern
    ln dropbearmulti dropbear
    ln dropbearmulti dbclient
    ln dropbearmulti ssh
    ln dropbearmulti dropbearkey
    ln dropbearmulti dropbearconvert
    ln dropbearmulti scp
    chown root:root *
    chmod 700 *

4.) RSA-Schlüssel erzeugen:
    ./dropbearkey -t rsa -f dropbear_rsa_host_key

5.) Start-Scripte anpassen:
    im Ordner <pre>/usr/local/zy-pkgs/etc/init.d</pre> ein neues Script 
mit folgendem Inhalt erstellen (z. B. my_extensions):

    cp /i-data/6764ac2f/public/bin/dropbear/dbclient /bin/dbclient
    cp /i-data/6764ac2f/public/bin/dropbear/dropbear /bin/dropbear
    cp /i-data/6764ac2f/public/bin/dropbear/dropbearconvert 
/bin/dropbearconvert
    cp /i-data/6764ac2f/public/bin/dropbear/dropbearkey /bin/dropbearkey
    cp /i-data/6764ac2f/public/bin/dropbear/scp /bin/scp
    cp /i-data/6764ac2f/public/bin/dropbear/ssh /bin/ssh
    dropbear -r 
/i-data/6764ac2f/public/bin/dropbear/dropbear_rsa_host_key -E

    und die Zugriffsrechte ändern :
    chmod 755 my_extensions

Die DropBear-Symlinks müssen bei jedem Start neu in den ordner /bin 
kopiert werden weil nach dem Neustart sämtliche Änderungen verloren 
gehen.

6.) eigenes Start-Skript eintragen:
    in der Datei ZYPKG_DEPS im Start-Up-Block die eigene Datei 
eintragen. Müsste dann so aussehen:

    # Dependency for zypkgs

    # START-UP (DON'T REMOVE THIS LINE!)
    /usr/local/zy-pkgs/etc/init.d/DyDNS
    /usr/local/zy-pkgs/etc/init.d/SMART
    /usr/local/zy-pkgs/etc/init.d/BackupPlanner
    /usr/local/zy-pkgs/etc/init.d/NFS
    /usr/local/zy-pkgs/etc/inet.d/my_extensions

    # SHUTDOWN (DON'T REMOVE THIS LINE!)
    /usr/local/zy-pkgs/etc/init.d/NFS
    /usr/local/zy-pkgs/etc/init.d/BackupPlanner
    /usr/local/zy-pkgs/etc/init.d/SMART
    /usr/local/zy-pkgs/etc/init.d/DyDNS

Nach einem Neustart müsste SSH laufen.

[ElektromAn (Gast)]

Ja, da ist wohl ein 'c' abhanden gekommen ....

crossdev --libc 2.9_p20081201-r3 --gcc 4.4.5  armv6-hardfloat-linux-gnueabi

das macht z. Zt. meine gentoo "Kiste"

[David W. (heruur84)]

Rainer schrieb:
> David schrieb:
>> ich weiß nicht ob es euch hilft - alle Änderungen unter
>> /usr/local/zy-pkgs/etc/init.d
>> bleiben auch nach dem Neustart erhalten
>
> Ich habe es geschafft mit Dropbear und Winscp dank des Tipps mit dem
> Pfad /usr/local/zy-pkgs/etc/init.d/ dropbear dauerhaft zum Laufen zu
> bekommen und Winscp kann auch die Dateien anzeigen. Keys sind erzeugt
> und dropbear korrekt geladen
> Was ich nicht hinbekommen habe, ist der Zugriff auf die Dateien, ich
> bekomme den HinweisSCP konnte für den Start der Übertragung nicht ausgeführt 
werden.
> Bitte stellen Sie sicher, dass SCP auf dem Server installiert ist
> und die $PFAD- Variable den Pfad zu SCP enthält. Anstatt SCP können Sie auch 
SFTP probieren.
> Befehl gescheitert mit Beendigungscode 127.Die Pfad-Variable habe ich mal 
gesetzt auf /var/ftp
> Soweit ich gelesen habe sollte ich einen symlink auf die scp binaries
> setzen, aber die habe ich ja nicht..!?
>
> Was muss ich noch machen? Danke im voraus für den Tipp

Hallo Rainer,

ich gerade probeweise zum ersten mal per WinSCP auf das NAS zugegriffen 
und bekomm folgende Fehlermeldung

Command 'groups'
failed with return code 127 and error message
-sh: groups: not found.

allerdings funktionert sowohl der up- als auch der Donwload.
Mir war ein (dauerhafter) ssh-Zugang wichtiger.

[Lucian M. (lucian_m)]

ElektromAn schrieb:
> crossdev --libc 2.9_p20081201-r3 --gcc 4.4.5  armv6-hardfloat-linux-gnueabi

Jau, hatte ich auch schon gemacht, aber mich aus dem Australien-Forum 
dazu verleiten lassen µClibc zu nehmen, und softfloat 
(armv6k-softfloat-linux-uclibceabi). Hat denn nun diese CPU eine FPU 
oder nicht?

Willst Du binaries unter der Original-Firmware zum Laufen bringen, oder 
letztendlich Gentoo darauf booten? (weil Du etwa die entsprechende 
glibc-Version in Deinem toolchain angibst, sollte dann nicht auch die 
gcc-version übereinstimmen? Ansonsten glaube ich, würde ich die neuesten 
Versionen nehmen)

[David W. (heruur84)]

Jens D. schrieb:
> Rainer schrieb:
>> Ich habe es geschafft mit Dropbear und Winscp dank des Tipps mit dem
>> Pfad /usr/local/zy-pkgs/etc/init.d/ dropbear dauerhaft zum Laufen zu
>> bekommen
>
> Dazu habe ich noch eine Frage: Hast du dabei
> /usr/local/zy-pkgs/etc/init.d/ZYPKG_DEPS geändert?
> Was hast du genau gemacht?
>
>
> btw. das mit dem debian Quellen geht z.B. bei
> http://packages.debian.org/squeeze/armel/nano/download anscheinend
> nicht.

Hi!

Ich konnte die Wiki nicht bearbeiten und hab deshalb meine 
Vorgehensweise hier gepostet

[Jens D. (jedie)]

Noch ein paar Info's mit dem chroot debian (siehe 
http://www.mikrocontroller.net/articles/P89626/debootstrap ):

lscpu:

Architecture:          armv6l
CPU(s):                2
Thread(s) per core:    1
Core(s) per socket:    1
CPU socket(s):         2

Noch eine Frage zum chrooten: Warum schlägt das fehl:

+ mount -o bind /dev /e-data/3e5fea5f-e3aa-4766-9064-1fdefbe13b7c/dev
mount: mounting /dev on /e-data/3e5fea5f-e3aa-4766-9064-1fdefbe13b7c/dev failed: Invalid argument

+ mount /i-data /e-data/3e5fea5f-e3aa-4766-9064-1fdefbe13b7c/i-data
mount: mounting /i-data on /e-data/3e5fea5f-e3aa-4766-9064-1fdefbe13b7c/i-data failed: Invalid argument

Noch was interessantes gefunden: http://wiki.qnap.com/wiki/Autorun.sh
Dort macht man u.a. sowas:

# mount -t ext2 /dev/mtdblock4 /tmp/config

...um Dateien darin zu ändern.

Wir hätten da diese read-only Kandidaten:

/dev/mtdblock6 on /zyxel/mnt/info type yaffs2 (ro,relatime)
/dev/mtdblock7 on /zyxel/mnt/sysdisk type yaffs2 (ro,relatime)

[ElektromAn (Gast)]

@Lucian M.
Laut 
http://armin762.wordpress.com/2010/02/23/armv4larmv4tlarmv5telarmv6jarmv7a-gentoo-stages/
sollte die Kiste VFP haben (Hardware FPU)

habe auch schon eine Toolschain für uClibc gebaut.
Achtung :
Bei Gentoo ist leider nicht die aktuelle uClibc 0.9.32 drin. Dazu wird 
ein extra ebuild gebraucht. Diese libc kann auch NPTL.

Habe auch andere Toolchains armv5, es wird auch wieder eine für armv4 
gebaut.

gcc version kann größer sein, nur die Version der libc sollte wie auf 
dem Zielsystem sein. Sonst fehlen einig Symbole wenn du das Programm auf 
dem "Zielsystem" ausführst.


Ob jetzt die uClibc brauchtbar ist, kann ich noch nicht prüfen 
(Hardware), das zweite Problem könnte mit sehr großen 
Dateien/Partitionen sein. Ich hatte da mal ein Post bei mir im Forum 
gelesen.

@David Wesselich
Wrapper für fehlendes groups

#!/bin/sh
id -G -n "$1"

[Dimpflmoser (Gast)]

Leider konnte ich gestern Abend nichts mit dem U-Boot testen, da ich das 
USB-Serial-Kabel im Büro vergessen habe.
Ich hatte zwar versucht das NAS mit meinen beiden alten Psions zu 
verbinden, die noch eine serielle Schnittstelle haben, dort kamen aber 
nur wirre Zeichen an und das nur sporadisch. Ich schätze, dass da die 
Pegel auf dem NAS nicht zu den vom Psion erwarteten Pegeln passten.

Jens D. schrieb:
> IMHO wäre es am einfachsten, wenn man das read-only Dateisystem
> überwinden könnte. Dann könnte man das ganze System umkrempeln.
>
> Mit einem einfachen "mount -o remount,rw /bla" ist es allerdings nicht
> getan, siehe: Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"

Die MTDs werden ja mit dem Boot-Parameter auf RO gesetzt. Wenn man die 
auf rw setzt hat man ja eventuell eine Chance direkt drauf zu schreiben 
oder mit einem remount.

Allerdings hätte ich testen können (leider aber vergessen, bzw aus dem 
Fokus geraden) das Image zu modifizieren, das als /dev/loop0 gemounted 
wird.

Das Image selbst ist im RW-Memory (MTD7?), das kann man auf den PC 
ziehen, entpacken, modifizieren, neues Image bauen und das alte Image 
ersetzten.

Die Gefahr bleibt natürlich, dass man beim Ersetzten des Images aus dem 
System ausgesperrt wird. Vorsichtshalber sollte man demnach ein Dump 
dieses MTDs ziehen.

Bye Dimpflmoser

[Dimpflmoser (Gast)]

Jens D. schrieb:
> Ich hab das mal mit dropbear gemacht:
> http://packages.debian.org/squeeze/dropbear
>
Achso, ich hatte unstable/SID Pakete benutzt und dort hat's geknallt 
sobald eine Binary auf die glibc?? zugegriffen hat. Eventuell ist das 
mit squeeze ja besser und es werde kompatible Pakete/Libs verwendet.

Jens D. schrieb:
> btw. das mit dem debian Quellen geht z.B. bei
> http://packages.debian.org/squeeze/armel/nano/download anscheinend
> nicht.

Kannst Du sagen woran das lag?
Waren nur einige Paketabhängigkeiten nicht erfüllt oder waren das 
Kompatibiltätsprobleme bei diversen Libs?

Ich hatte mit einem anderen Paket ein Problem, das bestimmt auch mein 
Nano auftritt:
Nano verwendet ja ncurses5, das wiederum greift auf termio o.ä. zurück, 
das hatte ich auch alles installiert bzw aus anderen Debian-Paketen auf 
das NAS kopiert, allerdings war dann die Terminal-Info nicht 
konfiguriert, die von termio verwendet wird. Das hatte ich dann nicht 
direkt lösen können und bin irgendwie wieder abgelenkt worden.

[Jens D. (jedie)]

zu nano: Da kenne ich mich IMHO zu wenige mit Linux aus... Beim starten 
kamen nur wirre Zeichen, keine echte Fehlermeldung das irgendwas 
fehlt...

Wenn das mit dem 
http://www.mikrocontroller.net/articles/P89626/debootstrap#chroot_per_Skript 
besser klappt, also wenn man es schaft das Ursprüngliche Dateisystem in 
die chroot Umgebung einzubinden, dann kann man auch alles bequem aus den 
Repos ziehen und nutzten... Ein mc geht da ohne Probleme...

Ich meine das mount Problem von 
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"

Mein chroot Skript sieht z.Z. so aus:

#! /bin/sh

# Funktioniert nur wenn ein Stick gesteckt ist:
ROOT=/e-data/`ls /e-data`/

(
    set -x

    mount -o bind /dev ${ROOT}dev
    mount -o bind /sys ${ROOT}sys
    mount -t proc /proc ${ROOT}proc

    if [ ! -e ${ROOT}i-data ]; then
        mkdir ${ROOT}i-data
    fi
    mount /i-data ${ROOT}i-data

    cp /etc/resolv.conf ${ROOT}etc/resolv.conf

    chroot ${ROOT} /bin/bash
)

echo
echo "Bye..."
echo

(
    set -x
    umount ${ROOT}dev
    umount ${ROOT}sys
    umount ${ROOT}proc

    umount ${ROOT}i-data
)

[Dimpflmoser (Gast)]

Jens D. schrieb:
> Also nochmal direkt:/etc # echo "# TEST" >> profile
> /etc # reboot
>
> Wie soll es sein, profile ist nach Neustat wieder resettet...
>
> Mich würde das ja eigentlich nicht verwundern, wenn das Ändern über
> einen Neustart hinaus nicht früher geklappt hätte....
>

Da ich meine Box mal wieder nicht da habe, kann ich leider wieder nur 
aus meiner trüben Erinnerung heraus spekulieren.

AFAIR wird ein Teil des Dateisystems in einer Ram-Disk angelegt. 
Irgendwo auf der Platte/Flash habe ich ein Tar-Ball gesehen der die 
Dateien enthält, die später in der RAM-Disk benötigt werden.
D.h. beim Start wird die Ram-Disk neu angelegt und das Archiv dort 
reinkopiert. Ich würde nach diesem Archiv suchen und nachsehen ob ich 
darin was ändern kann.
Aber auch hier ist wieder die Gefahr, dass man sich aussperrt wenn man 
was falsch macht.

[Dimpflmoser (Gast)]

Jens D. schrieb:
> Hab mal authorized_keys in /home/shares/.ssh/ hinterlegt, klappt aber
> nicht. Ein test mit /home/USERNAME/.ssh/authorized_keys tut's auch
> nicht...
>
> Jemand eine Idee dazu?

Habe das Problem noch nicht ganz verstanden, aber mit dem Dropbear schon 
ein wenig Nahkampferfahrung sammeln können/müssen.

Was ist Dein Problem, kannst Du keine eingehende Verbindung, d.h. 
PC->NAS per RSA-Key herstellen oder geht's ned nach draußen (NAS->PC)?

Dropbear kann beides und ich habe das auch auf einem anderen ARM-System 
im Betrieb.

[Jens D. (jedie)]

ich kann mich einloggen, aber nur mit passwort und leider nicht per 
Public-Key...

Ach und die SSH Verbindung kann ich nicht in Nautilus (IMHO geht das 
über FUSE) einbinden...

[Dimpflmoser (Gast)]

Jens D. schrieb:
> ich kann mich einloggen, aber nur mit passwort und leider nicht per
> Public-Key...
>
Hat das Verzeichnis root.ssh die Rechte 700?
Hat die Datei root.ssh/authorized_keys die Rechte 600?

Ich gehe mal davon aus, dass der Public Key von deinem PC-Konto 
eingetragen ist, oder?
Verwendest Du openssh auf dem PC? Falls nicht, kann Dein SSH-Client mit 
Deinem lokalen Key umgehen?
Beim dropbear-ssh-client muss man mit dem Paramter -i angeben welchen 
Key man vewenden möchte.
Kann es sein, dass Du ein Passwort auf deinen private Key vergeben hast 
und dass einfach nur dieses Passwort verlangt wird?

> Ach und die SSH Verbindung kann ich nicht in Nautilus (IMHO geht das
> über FUSE) einbinden...
Kenne Nautilus nicht (bin KDE-User).
Dolphin (KDE) benutzt da keine Systemresourcen sondern macht das 
selbständig, d.h. wenn man das Verzeichnis in Dolphin/KDE mounted dann 
ist das für andere Programme nicht sichtbar.

Ich schätze, dass für diese Verbindung auch per sftp aufgebaut wird. Das 
tut bei meiner Installation auch nicht. Ich bekomme dort den Fehler:

sftp root@192.168.2.215
sh: /usr/libexec/sftp-server: not found
Connection closed

Unter dolphin gibt es noch die Alternative per fish:// aber auch das tut 
nicht.
scp tut problemlos

[Jens D. (jedie)]

Dimpflmoser schrieb:
> Hat das Verzeichnis root.ssh die Rechte 700?
> Hat die Datei root.ssh/authorized_keys die Rechte 600?

Das war der entscheidende Tipp. authorized_keys muß unter root.ssh/ 
gespeichert sein, dann klappt es auch!

Hab's im Wiki eingetragen: 
http://www.mikrocontroller.net/articles/P89626/dropbear#Authentifizierung_.C3.BCber_Public-Keys

[Dimpflmoser (Gast)]

Jens D. schrieb:
> Das war der entscheidende Tipp. authorized_keys muß unter root.ssh/
> gespeichert sein, dann klappt es auch!

Nur um sicher zu gehen, dass da jemand aufgrund eines 
Flüchtigkeitsfehlers nicht weiter kommt. Die Datei muss natürlich unter 
folgendem Pfad gespeichert werden:

/root/.ssh/authorized_keys

Die Rechte von root.ssh/ mussen 700 die von authorized keys 600 sein.

Tschüss Dimpflmoser

[Rainer (Gast)]

David Wesselich schrieb:
> Command 'groups'
> failed with return code 127 and error message
> -sh: groups: not found.

das gehört so, da hier ein Paket fehlt das nachinstalliert werden 
müsste. Die Groups-Funktionalität kann dropbear (oder wo auch immer das 
herkommt) nicht von Hause aus.

Bei Winscp einfach unter WINScp Anmeldung/Umgebung/SCP/Shell/Andere 
Einstellungen/Gruppen lesen Häkchen raus und die Fehlermeldung ist weg.

[In J. (patch24)]

Guten Abend,

ich habe das Gerät im "ruhenden - keiner greift zu" Betrieb mal 
ausgeschaltet (Testfall, wenn wir in Urlaub fahren).

Nach dem Anschalten wollte sich das System automatisch neu installieren
(via Medion Nas Starter Utility).
Alle Verzeichnisse und Zugriffe waren weg?!

Die Hotline von Medion hat mir bestätigt, dass das System nach dem 
Ausschalten wieder neu installiert. Das kann doch nicht war sein? Was 
ist denn bei einem Stromausfall?

Was könnt ihr mir dazu berichten. Wenn dem so ist, kann ich es nicht 
gebrauchen.

LG Patch24

[Rainer (Gast)]

David Wesselich schrieb:
> Ich konnte die Wiki nicht bearbeiten und hab deshalb meine
> Vorgehensweise hier gepostet

funktioniert einwandfrei! Klasse Arbeit, vielen Dank!

[Jens D. (jedie)]

In Ju schrieb:
> Nach dem Anschalten wollte sich das System automatisch neu installieren
> (via Medion Nas Starter Utility).
> Alle Verzeichnisse und Zugriffe waren weg?!
>
> Die Hotline von Medion hat mir bestätigt, dass das System nach dem
> Ausschalten wieder neu installiert. Das kann doch nicht war sein? Was
> ist denn bei einem Stromausfall?

Also ich hab das Ding schon mehrfach runtergefahren (Wobei es dabei ja 
nicht von alleine Aus geht. s.o.)

Ich habs auch mehrfach vom Stromnetz getrennt. Da ist nichts weg... Die 
Daten, die eingerichteten User/Freigaben, alles da. Was weg sind sind 
die internen Dinge, die uns hier beim Hacken stören ;)

Allerdings hab ich diese "Medion Nas Starter Utility" nie benutzt. Die 
CD nie angeschaut. Vielleicht macht die Software also von außen 
automatisch alles Platt? Wobei das nicht wirklich Sinn machen würde...

[In Ju (Gast)]

>
> Also ich hab das Ding schon mehrfach runtergefahren (Wobei es dabei ja
> nicht von alleine Aus geht. s.o.)

Wie funzt denn dieses runterfahren? Ausschalten kann ja jeder;-)

LG

[Hermann K. (hermannk)]

Lucian M. schrieb:

> Wie mountest Du denn genau (bitte poste mal die Parameter) die nfs
> shares der NAS unter Linux so das der Transfer schnell ist? Wie sind die
> MTU Einstellungen am NAS und an diesen Rechnern?

Die Mount-Parameter:

root@j4:/tmp# mount | grep j4
192.168.0.183:/i-data/6764ac2f/nfs/j4 on /j4 type nfs (rw,user=root,noexec,nosuid,nodev,addr=192.168.0.183)

Wie gesagt, die Dateien sind in Ordnung. Ich habe zwischenzeitlich den 
P89626 mehrfach ausgeschaltet, was zu keinen Fehlern geführt hat. 
/var/x.cpio ist die lokale Platte, /j4/var/x.cpio ist der P89626. Die 
Übertragungsrate ist:

root@j4:/tmp# md5sum /var/x.cpio /j4/var/x.cpio
3c490a5361bcb48d6345b35da1ee8d60  /var/x.cpio
3c490a5361bcb48d6345b35da1ee8d60  /j4/var/x.cpio
root@j4:/tmp# ls -l /var/x.cpio /j4/var/x.cpio
-rw-r--r-- 1 root root 2101320192 2011-05-06 21:15 /j4/var/x.cpio
-rw-r--r-- 1 root root 2101320192 2011-05-06 21:15 /var/x.cpio
root@j4:/tmp# sync ; echo 3 > /proc/sys/vm/drop_caches; time cp /j4/var/x.cpio  /dev/null

real  1m15.295s
user  0m0.010s
sys  0m1.960s
root@j4:/tmp# sync ; time cp /j4/var/x.cpio  /dev/null

real  0m0.552s
user  0m0.000s
sys  0m0.540s
root@j4:/tmp# sync ; echo 3 > /proc/sys/vm/drop_caches; time cp /var/x.cpio  /dev/null

real  0m13.427s
user  0m0.000s
sys  0m2.060s

Das bedeutet: 27.9 MBytes/s vom NAS, 156.5 MBytes/s von der lokalen 
Platte und 3.8 GBytes/s aus dem Cache. MTU ist auf j4 (eth0), auf dem 
P89626 (egiga0) und auf dem Switch 1500 Bytes. Da habe ich (noch) nichts 
optimiert.

nfsstat zeigt auf der Seite des P89626

~ $ nfsstat -s
Server rpc stats:
calls      badcalls   badauth    badclnt    xdrcall
995157     8          8          0          0       

Server nfs v3:
null         getattr      setattr      lookup       access       readlink     
5         0% 128077   12% 0         0% 490       0% 25301     2% 1         0% 
read         write        create       mkdir        symlink      mknod        
820878   82% 0         0% 0         0% 0         0% 0         0% 0         0% 
remove       rmdir        rename       link         readdir      readdirplus  
0         0% 0         0% 0         0% 0         0% 0         0% 20384     2% 
fsstat       fsinfo       pathconf     commit       
0         0% 15        0% 6         0% 0         0%

und auf der Seite von j4 keine Besonderheiten:

root@j4:/tmp# nfsstat -c
Client rpc stats:
calls      retrans    authrefrsh
5064759    0          5064776 

Client nfs v3:
null         getattr      setattr      lookup       access       readlink     
0         0% 424084    8% 6347      0% 24025     0% 111805    2% 15151     0% 
read         write        create       mkdir        symlink      mknod        
4190534  82% 199324    3% 1301      0% 27        0% 4         0% 0         0% 
remove       rmdir        rename       link         readdir      readdirplus  
17337     0% 3659      0% 1301      0% 0         0% 0         0% 68558     1% 
fsstat       fsinfo       pathconf     commit       
7         0% 12        0% 6         0% 1274      0%

Insbesondere ist retrans 0. Unterm Strich: Empfehlung für NFS.

[Lucian M. (lucian_m)]

ElektromAn schrieb:
> crossdev --libc 2.9_p20081201-r3 --gcc 4.4.5  armv6-hardfloat-linux-gnueabi
> das macht z. Zt. meine gentoo "Kiste"

Und läuft das bei Dir erfolgreich durch? bei mir bricht es ab:

htpc2 portage # crossdev --overlays /mnt/portage/overlays/local/my_overlay+patches/ --ov-output /mnt/portage/overlays/local/my_overlay+patches/ --libc 2.9_p20081201-r3 --gcc 4.4.5 --portage --update -t armv6-hardfloat-linux-gnueabi
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 * crossdev version:      20111018
 * Host Portage ARCH:     amd64
 * Target Portage ARCH:   arm
 * Target System:         armv6-hardfloat-linux-gnueabi
 * Stage:                 4 (C/C++ compiler)
 * ABIs:                  default

 * binutils:              binutils-[latest]
 * gcc:                   gcc-4.4.5
 * headers:               linux-headers-[latest]
 * libc:                  glibc-2.9_p20081201-r3

 * CROSSDEV_OVERLAY:      /mnt/portage/overlays/local/my_overlay+patches/
 * PORT_LOGDIR:           /var/log/portage
 * PORTAGE_CONFIGROOT:
  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _
 * leaving sys-devel/binutils in /mnt/portage/overlays/local/my_overlay+patches/
 * leaving sys-devel/gcc in /mnt/portage/overlays/local/my_overlay+patches/
 * leaving sys-kernel/linux-headers in /mnt/portage/overlays/local/my_overlay+patches/
 * leaving sys-libs/glibc in /mnt/portage/overlays/local/my_overlay+patches/
 * leaving sys-devel/gdb in /mnt/portage/overlays/local/my_overlay+patches/
 * leaving dev-util/insight in /mnt/portage/overlays/local/my_overlay+patches/
  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _
 * Log: /var/log/portage/cross-armv6-hardfloat-linux-gnueabi-binutils.log
 * Emerging cross-binutils ...                                                                                                                                                                           [ ok ]
 * Log: /var/log/portage/cross-armv6-hardfloat-linux-gnueabi-linux-headers-quick.log
 * Emerging cross-linux-headers-quick ...                                                                                                                                                                [ ok ]
 * Log: /var/log/portage/cross-armv6-hardfloat-linux-gnueabi-glibc-headers.log
 * Emerging cross-glibc-headers ...

 * glibc failed :(
 * If you file a bug, please attach the following logfiles:
 * /var/log/portage/cross-armv6-hardfloat-linux-gnueabi-info.log
 * /var/log/portage/cross-armv6-hardfloat-linux-gnueabi-glibc-headers.log

Die immer wieder kehrenden Fehler im zuletzt erwähnten Log:

ports/sysdeps/unix/sysv/linux/arm/eabi/sysdep.h:31:3: error: #error Kernel headers are too old
ports/sysdeps/arm/nptl/tls.h:48:3: error: #error "TLS support is required."

Has Du denn einen Tipp für mich, ElektromAn?

[Lucian M. (lucian_m)]

Hermann K. schrieb:
> Insbesondere ist retrans 0. Unterm Strich: Empfehlung für NFS.

Danke für Deinen auführlichen Bericht! Interessant wäre es auch zu hören 
was heraus kommt, wenn Du mal Zeit hast mit Jumbo-Frames zu testen...

[Dimpflmoser (Gast)]

Hallo,

versuche gerade per USB-serial-Adapter (PL2302) auf die Serielle 
Schnittstelle zuzugreifen aber bekomme da keine vernünftigen Ausgaben 
auf das Terminal.

Zu meinem Setup:

Linux Laptop mit PL2302-Adapter
dmesg sagt mir:

[ 3659.312060] usb 3-1: new full speed USB device number 3 using uhci_hcd
[ 3659.469220] pl2303 3-1:1.0: pl2303 converter detected
[ 3659.481266] usb 3-1: pl2303 converter now attached to ttyUSB0

Auf dem Laptop habe ich Minicom am Laufen mit den Parametern 115200 8n1

minicom -D /dev/ttyUSB0

Den Adapter habe ich so mit der Box verbunden:

D-SUB           J4              
(pl2302)      (NAS)
Pin 5            Pin 4 (Gnd)
Pin 3            Pin 2 (Rx)
Pin 2            Pin 3 (Tx)

Ich bekomme offensichtlich Daten vom NAS allerdings sind die nur Müll.
Wenn ich per Telnet Ausgaben auf ttyS0 umleite sehe ich synchron dazu 
entsprechend Ausgaben auf dem Terminal, allerding halt nur Müll.

Habt Ihr eine Ahnung was dabei schief laufen kann?

Bye Dimpflmoser

[Christian (Gast)]

ElekromAn schrieb:
> Testaufbau:
> Datei nach NAS übertragen.
> Auf dem PC und auf dem NAS (telnet/ssh) die md5 oder sha1 Summe prüfen.
> Die Prüfung auf dem NAS ist wichtig, da die Datei ja sonst wieder
> zurück auf dem PC übertragen wird.
>
> Dies einmal mit und ohne Virenscanner machen.

Auch wenn mir das Ergebnis schon klar war (aber manchmal wird man halt 
doch überrascht), hier die Überprüfung mit md5sum
Quelle:
vdr:/data# md5sum 1.pdf
82d151d2a3b5fad8936082ce390ecab9  1.pdf
Ziel:
/i-data/6764ac2f/Temp $ md5sum 1.pdf
031e207acd0d51979f99e14d508a3c46  1.pdf
Dateien nochmal gechrieben und Virenscanner konfiguriert Schreibzugriffe 
aufs NAS nicht zu überwachen
ziel:
/i-data/6764ac2f/Temp $ md5sum 1.pdf
82d151d2a3b5fad8936082ce390ecab9  1.pdf
So interessant es auch wäre wo das Problem liegt, gebe ich es auf. Danke 
für eure Rückmeldungen und Tipps.

[Rainer (Gast)]

Hat jemand eine Idee ob und wenn ja wie flexget auf dem NAS 
installierbar ist? python wäre vorhanden, auch wenn's ne andere Version 
ist...
http://flexget.com/

[Franz (Gast)]

Verzeiht, ich habe bereits alles durchsucht, aber gibt es bereits eine 
Lösung um dauerhaft(!) alle Optionen des Twonky Servers freizuschalten?

Im Thread zum P89626 auf nas-portal.org wird ja beschrieben, wie man die 
vollen Optionen für das Webinterface freischaltet - diese gehen aber bei 
einem Neustart des NAS verloren.

Gibt es dafür bereits eine Lösung?

Und Respekt an alle Tüftler und Bastler hier - ich verstehe zwar 
vielleicht nur jedes dritte Wort, aber ich verfolge das hier mit großer 
Spannung :D

[Michael (Gast)]

Ein HTTP GET müsste mit der besagten URL reichen. Diese URL mit wget 
aufrufen und in ein Script packen. Dann analog zum SSH Server dropbear 
in nicht geresetteten Startscripte packen und schon sollte auch nach 
einem Reboot alle Einstellungen verfügbar sein. Es sollte aber darauf 
geachtet werden, ob der Twonky-Server dann schon läuft, sonst läuft der 
wget Aufruf ins Leere.

#/bin/sh
wget http://localhost:9001/rpc/set_option?suppressmenu=mediafeeds,transcoding,AutoShare,Webaccess,Treetype,Logfile,Nicrestart,Friendlyname,Buttons,Language,MediaFusion,Contentdir,Scantime,Compilationsdir,Playlistnumentries

[Franz (Gast)]

Danke Michael :D

allerdings muss ich leider gestehen, dass ich jetzt spontan keine Ahnung 
habe, wie ich das Umsetze.
Was ist ein HTTP GET?
Und bzgl Dropbear, SSH etc muss ich mich auch erst einlesen, da weiß ich 
spontan ebenfalls nicht was die sind bzw. wie ich sie einsetze.

Aber grundsätzlich meinst du folgendes(?):
Durch irgendeine Form der command shell (also wahrscheinlich ist das 
SSH?) auf den NAS zugreifen und ein Script in die Startscripte packen.

Aber wie "erkläre" ich dem NAS, dass er dieses Script starten soll?
Und gehen bei dem Vorgang nicht trotzdem alle Einstellungen vom letzten 
mal verloren?
Speichert der NAS denn die Twonky Einstellungen denn? Bzw. er 
überschreibt sie doch, wenn der NAS neu startet.

Ich stell mir das so vor:
(ungemoddeter) NAS -> per URL unlock der Twonky Einstellungen -> 
Speichern der Einstellungen -> Netzschalter aus -> modden des NAS -> NAS 
bootet -> NAS überschreibt dabei die Einstellungen die man im "unlocked" 
Twonky vorgenommen hat -> das Script setzt ein -> ich muss zwar die 
Einstellungen nicht wieder manuell freischalten, sie aber sehr wohl 
jedes mal neu einstellen, oder?

Wie kann ich sicher gehen, dass der NAS die Einstellungen des 
"erweiterten/voll funktionsfähigen" Twonky speichert und auch wieder 
übernimmt, nach einem reboot des NAS?

Verzeiht, falls diese Fragen für euch stupide wirken, aber nachdem ich 
eher nur sehr grundsätzlich Wissen über NAS/Linux habe reime ich mir das 
hier so zusammen xD

Und Danke nochmals :)

[Michael (Gast)]

Du hast Recht, wahrscheinlich wird, dass was ich beschrieben habe, dafür 
reichen die Konfiguration von Twonky dauerhaft zu speichern. Ich habe 
lediglich beschrieben, wie die erweiterten Einstellung nach einem 
Neustart verfügbar gemacht werden.

Ich finde den Twonky irgendwie sowieso komisch. Ich habe ca. 30.000 MP3s 
hochgeladen und, die wurden nach einigen Stunden auch endlich alle von 
Twonky indiziert, aber die CPU reicht wohl nicht aus, vernüftig so große 
Sammlungen zu verwalten. Denn sobald ich mit einem DLNA Client zugreife 
geht die CPU Last auf 100%.

In dem Webinterface von Twonky konnte ich sehen, dass der 30.000 Files 
gefunden hat, aber nach einem Reboot stand da wieder 0.

[Michael (Gast)]

Michael schrieb:
> Du hast Recht, wahrscheinlich wird, dass was ich beschrieben habe, dafür
> reichen die Konfiguration von Twonky dauerhaft zu speichern.

Da fehlt ein NICHT!

Du hast Recht, wahrscheinlich wird, dass was ich beschrieben habe, dafür
NICHT reichen die Konfiguration von Twonky dauerhaft zu speichern.

[Jens D. (jedie)]

In Ju schrieb:
> Wie funzt denn dieses runterfahren? Ausschalten kann ja jeder;-)

Hatte ich weiter oben schon beschrieben (s. 
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS" ): Per 
SSH/Telnet ein "halt" absetzten... Dann warten bis Platte aus ist und 
dann kann man Strom abschalten. Warum die Kiste nicht von alleine aus 
geht, weiß ich nicht.

[Jens D. (jedie)]

Was haltet ihr von dieser Idee: Solange es kein uBoot/Kernel gibt, den 
man direkt starten kann, macht man folgendes:

Alle Dienste auf der Box beenden, chroot in Debian Systeme machen und 
Dienste, die man haben möchte wieder starten.

z.Z. gibt es mit /usr/local/zy-pkgs/etc/init.d/ZYPKG_DEPS den einzige 
Funktionierende Ort für einen Hook: Darin rufen wir ein Skript auf, 
welches die Prozedur dann macht, wenn ein passender USB-Stick [1] 
steckt...

Würde das ganze überhaupt gut funktionieren? Ich kenne mich dazu in 
Linux zu wenig aus...

[1] http://www.mikrocontroller.net/articles/P89626/debootstrap

[Franz (Gast)]

ich weiß nicht ob es schon gepostet wurde, aber auf medion.at ist der 
gpl_source zum download verfügbar:

http://www1.medion.de/downloads/download.pl?lang=de&filename=gpl_source_md86407.exe&id=10636&type=software

nützt der einem in irgendeiner Weise etwas?

[Lucian M. (lucian_m)]

Franz schrieb:
> ich weiß nicht ob es schon gepostet wurde, aber auf medion.at ist der
> gpl_source zum download verfügbar:
>
> http://www1.medion.de/downloads/download.pl?lang=d...
>
> nützt der einem in irgendeiner Weise etwas?

Könnte extrem nützlich sein... Interessant, Du erwähnst Du bist über 
medion.at darüber gestolpert, der Link zeigt letztendlich auf den .de 
Server...
Downloadgeschwindigkeit ist bescheiden, knapp 118kB/s, so wird das etwa 
1.5h dauern... Aber danke jedenfalls für den Hinweis!

[Jens D. (jedie)]

direkter download: 
http://download2.medion.com/downloads/software/gpl_source_md86407.exe

[Franz (Gast)]

oh...stimmt, naja ich bin über medion.at darauf gestoßen, aber ist ja 
nur logisch wenns über die "Mutter" läuft xD

Es wäre extrem cool über den Source Code an die Lösung zu kommen wie man 
eventuell den Twonky dauerhaft freischalten kann - allein schon, damit 
man ein Passwort einrichten kann für die Weboberfläche xD

Und was ich öfter gelesen habe ist, dass ja auch versucht wird Debian 
auf dem NAS zum laufen zu bringen - wie kann ein Laie sich das 
vorstellen?
Läuft die Konfiguration/Einstellung des Debian Linux dann nur über 
commando zeilen oder gibt es die Möglichkeit einer "Weboberfläche" oder 
eines Virtuellen Desktops?

Denn als ich das erste mal von Debian auf zb dem Medion NAS gelesen 
habe, habe ich es mir so vorgestellt, dass man eventuell auf dem NAS 
dann den jeweils aktuellsten Twonky installieren kann und das  ganze wie 
über einen virtuellen Desktop steuert - ist das denn möglich?

Oder sollte ich mir als Laie Debian komplett aus dem Kopf streichen?

[Lucian M. (lucian_m)]

Franz schrieb:
> Es wäre extrem cool über den Source Code an die Lösung zu kommen wie man
> eventuell den Twonky dauerhaft freischalten kann - allein schon, damit
> man ein Passwort einrichten kann für die Weboberfläche xD

Ich bezweifele dass die GPL-Sourcen hierfür dienlich sein würden, Twonky 
ist meines Wissens komerziell, closed-source...

> Und was ich öfter gelesen habe ist, dass ja auch versucht wird Debian
> auf dem NAS zum laufen zu bringen - wie kann ein Laie sich das
> vorstellen?
> Läuft die Konfiguration/Einstellung des Debian Linux dann nur über
> commando zeilen oder gibt es die Möglichkeit einer "Weboberfläche" oder
> eines Virtuellen Desktops?

Nich nur, man könnte z.B. Webmin aufsetzen, das erlaubt dann so manches 
über eine Weboberfläche, kannst mal da angucken: http://www.webmin.com/
>
> Denn als ich das erste mal von Debian auf zb dem Medion NAS gelesen
> habe, habe ich es mir so vorgestellt, dass man eventuell auf dem NAS
> dann den jeweils aktuellsten Twonky installieren kann und das  ganze wie
> über einen virtuellen Desktop steuert - ist das denn möglich?

Bloß wenn man eine kompilierte Version für die entsprechende Architektur 
bekommt, und das bekommen glaube ich nur diese NAS-Hersteller...

> Oder sollte ich mir als Laie Debian komplett aus dem Kopf streichen?

Wenn Du Bereitscheft und Zeit zum Lernen und Tüfteln aufbringen 
kannst/willst, dann nicht. Und ausser Debian gibt es ja auch noch Arch, 
Gentoo...

[Jens D. (jedie)]

Gerade entdecke ich diese Zeilen beim Booten:

ata1: SATA max UDMA/133 irq 50
ata2: SATA max UDMA/133 irq 50
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-8: ST1500DL003-9VT16L, CC4A, max UDMA/133
ata1.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/133
ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x9 t4
ata1.00: configured for UDMA/133
ata1: EH complete
ata2: SATA link down (SStatus 0 SControl 300)

d.h. es gibt einen zweiten SATA Anschluss?!?

[Franz (Gast)]

Achso, pardon, da hab ich mich falsch ausgedrückt - ja ich weiß, dass 
Twonky keine GPL ist, ich meinte viel mehr, dass es durch den Source 
Code vielleicht möglich ist das überschreiben der Twonky Einstellungen 
aus dem Flash(?) des NAS auszuhebeln - also ein Tweak am NAS-OS und 
nicht an Twonky.

Und Twonky gibt es doch auch für NAS oder?
Und unter Debian müsste Twonky Server sowieso laufen, oder braucht man 
da ein x86 System?

Ich persönlich bin ja mit dem NAS vollkommen zufrieden, wenn es später 
mal möglich ist die Erweiterten Einstellungen des Medienservers 
dauerhaft freizuschalten, ein Passwort einzurichten und das Auto-Scan zu 
konfigurieren xD

Denn ich nehm an, selbst wenn ich Twonky 6 oder 7 auf dem NAS zum laufen 
bekomme könnte ich dennoch keine mkv's auf der XBox abspielen oder? Der 
Twonky auf der NAS stellt die Datei ja nur zur Verfügung oder?

(Ich hoff es ist nicht allzu peinlich, dass ich mich nicht so gut 
auskenne ^^)

[Lucian M. (lucian_m)]

Jens D. schrieb:
> ata2: SATA link down (SStatus 0 SControl 300)
>
> d.h. es gibt einen zweiten SATA Anschluss?!?

Das sagt nicht, dass es einen physikalischen Anschluss gibt, wenigstens 
in Form von Leiterbahnen auf der Platine wo am Schluß nichts mehr 
angelötet wurde (so z.B. meine "alte" LS-Pro, da müsste man einen 
eSATA-Port nur zusammen mit 2-3 SMD-Kondensatoren anlöten und hinten am 
Gehäuse das entsprechendes Loch dremeln), sondern nur daß die Elektronik 
im SoC diesen zweiten Anschluß unterstützen würde.

[Michael (Gast)]

Hab mir mal ein bischen das GPL Paket angeguckt. Dort wird beschrieben, 
wie man ein Build-Environment aufsetzt um die Firmware für das "NSA 210" 
zu bauen. Von Medion ist da nicht die Rede. Die von Medion haben sich 
wahrscheinlich möglichst wenig Arbeit gemacht.

U.a. bin ich auf folgendes gestoßen:

build_NSA212.tar.gz\build_NSA212.tar\trunk\linux-2.6.31.14\STG212_Kernel.config

Vielleicht hilft das einen Kernel zu bauen, der funktioniert und der 
aber auch beide Core unterstützt.

Gruß
Michael

[Lucian M. (lucian_m)]

Franz schrieb:
> Achso, pardon, da hab ich mich falsch ausgedrückt - ja ich weiß, dass
> Twonky keine GPL ist, ich meinte viel mehr, dass es durch den Source
> Code vielleicht möglich ist das überschreiben der Twonky Einstellungen
> aus dem Flash(?) des NAS auszuhebeln - also ein Tweak am NAS-OS und
> nicht an Twonky.

Ok, in der Hinsicht könntest Du recht haben, möglicherweise finet man 
mehr heraus, wie das Ganze funktioniert um dann eventuell ein bisschen 
tricksen zu können...

> Und Twonky gibt es doch auch für NAS oder?

NAS ist nicht gleich NAS, sie sind mit unterschiedlichen 
CPU-Architekturen hergestellt, das heisßt dann auch daß die Firmwares 
die darasuf laufen, meistens Linux, entsprechend kompiliert sind, so 
auch jedes Programm was unter der entsprechenden Firmware ausgeführt 
werden soll, somit auch Twonky. Auf deren Seite gibt es aber nicht 
allzuviele unterschiedliche Downloads, sondern eher nur für PCs.

> Und unter Debian müsste Twonky Server sowieso laufen, oder braucht man
> da ein x86 System?

Debian alleine reicht nicht, siehe oben. Natürlich gibt es Twonky unter 
verschiedenen Linuxen (meinetwegen Debian), aber halt nicht frei für 
jedermann...

> Denn ich nehm an, selbst wenn ich Twonky 6 oder 7 auf dem NAS zum laufen
> bekomme könnte ich dennoch keine mkv's auf der XBox abspielen oder? Der
> Twonky auf der NAS stellt die Datei ja nur zur Verfügung oder?

Bei DLNA / uPNP ist es nicht ganz so einfach, sowohl Server als auch 
Client müssen meines Wissens miteienander harmonieren ,in der Art und 
Weise wie sie Informationen die vor dem eigentlichen Streamen notwendig 
sind, austauschen. Ich kenn mich mit DLNA zu wenig aus, aber vom Prinzip 
her denke ich schon daß die Art und Weise wie der Server dem Client die 
Streams bereitstellt, einen Rolle spielen...

> (Ich hoff es ist nicht allzu peinlich, dass ich mich nicht so gut
> auskenne ^^)

Nö, keine Sorge, all das sollte man eigentlich nicht wissen müssen, bloß 
die Industrie segnet uns immer wieder mit beta- und alpha-Produkten, 
oder mit beschnittenen, kastrierten, sodas dann einige von uns mit mehr 
oder weniger Erfolg anfangen zu stöbern, um deren Produkte auch wirklich 
brauchbar zu machen :-). Für viele ist es der Spaß am "hacken", aber 
auch das hat mal Grenzen, irgendwann mal will man das Dinge eingfach nur 
funktionieren, und zwar so das man nichts mehr auszusetzen hat ;-)

[Lucian M. (lucian_m)]

Michael schrieb:
> U.a. bin ich auf folgendes gestoßen:
> build_NSA212.tar.gz\build_NSA212.tar\trunk\linux-2.6.31.14\STG212_Kernel .config
>
> Vielleicht hilft das einen Kernel zu bauen, der funktioniert und der
> aber auch beide Core unterstützt.

Na toi, toi, toi, auf sowas habe ich ehrlich gesagt am meissten 
gehofft!!!

[Dimpflmoser (Gast)]

Darf ich nochmal mein Problem hochbringen und um Hilfe bitten.

Ich komme nicht vernünftig auf die serielle Schnittstelle und demnach 
nicht ins U-Boot.
Könnt Ihr sehen was ich da falsch machen bzw Tipps geben was ich noch 
probieren kann?

Hier nochmal meine Mail von gestern Nacht:

Dimpflmoser schrieb:
> Hallo,
>
> versuche gerade per USB-serial-Adapter (PL2302) auf die Serielle
> Schnittstelle zuzugreifen aber bekomme da keine vernünftigen Ausgaben
> auf das Terminal.
>
> Zu meinem Setup:
>
> Linux Laptop mit PL2302-Adapter
> dmesg sagt mir:
> [ 3659.312060] usb 3-1: new full speed USB device number 3 using uhci_hcd
> [ 3659.469220] pl2303 3-1:1.0: pl2303 converter detected
> [ 3659.481266] usb 3-1: pl2303 converter now attached to ttyUSB0
>
> Auf dem Laptop habe ich Minicom am Laufen mit den Parametern 115200 8n1minicom 
-D /dev/ttyUSB0
>
> Den Adapter habe ich so mit der Box verbunden:
> D-SUB           J4
> (pl2302)      (NAS)
> Pin 5            Pin 1 Gnd)
> Pin 3            Pin 3 (Rx)
> Pin 2            Pin 2 (Tx)
>
> Ich bekomme offensichtlich Daten vom NAS allerdings sind die nur Müll.
> Wenn ich per Telnet Ausgaben auf ttyS0 umleite sehe ich synchron dazu
> entsprechend Ausgaben auf dem Terminal, allerding halt nur Müll.
>
> Habt Ihr eine Ahnung was dabei schief laufen kann?
>
> Bye Dimpflmoser

[Jens D. (jedie)]

Dimpflmoser schrieb:
> Auf dem Laptop habe ich Minicom am Laufen mit den Parametern 115200 8n1
> minicom -D /dev/ttyUSB0

Teste doch mal mit:

  screen /dev/ttyUSB0 115200

[Jens D. (jedie)]

Jens D. schrieb:
> Noch eine Frage zum chrooten: Warum schlägt das fehl:
> + mount -o bind /dev /e-data/3e5fea5f-e3aa-4766-9064-1fdefbe13b7c/dev
> mount: mounting /dev on /e-data/3e5fea5f-e3aa-4766-9064-1fdefbe13b7c/dev failed: 
Invalid argument
>
> + mount /i-data /e-data/3e5fea5f-e3aa-4766-9064-1fdefbe13b7c/i-data
> mount: mounting /i-data on /e-data/3e5fea5f-e3aa-4766-9064-1fdefbe13b7c/i-data 
failed: Invalid argument

Hat dazu jemand eine Idee?

Hab auch '''mount --rbind /dev ${ROOT}dev''' probiert, selbe Fehler...

[Christian (Gast)]

Michael schrieb:
> Vielleicht hilft das einen Kernel zu bauen, der funktioniert und der
> aber auch beide Core unterstützt.

Meines Wissens sollte der Kernel wenn halbwegs aktuell ohne weitere 
Anpassungen beide Cores unterstützen. Entscheidend ist, daß der U-Boot 
den zweiten Core auch aktiviert. Liegen die Sourcen vom U-Boot auch bei? 
Ohne Möglichkeit via JTAg neu zu flashen sind Anpaassungen am U-boot 
allerdings hochriskant ...

[Michael (Gast)]

Christian schrieb:
> Liegen die Sourcen vom U-Boot auch bei?

Ja unter trunk/sysapps/u-boot-1.1.2/ in der build_NSA212.tar.gz

[Jens D. (jedie)]

Christian schrieb:
> Ohne Möglichkeit via JTAg neu zu flashen sind Anpaassungen am U-boot
> allerdings hochriskant ..

Vor dem flashen kann man aber uBoot und Kernel ohne Problem über UART 
und TFTP testen!

Mal eine Vermutung: Medion hat es sich leicht gemacht und einfach fast 
unmodifiziert die Komponenten für den Zyxel NSA 210/212 genommen. Das 
Zyxel NSA 210 hat einen IMHO einen Single-Core: 
http://zyxel.nas-central.org/wiki/Dmesg_%28NSA-210%29 von daher haben 
wir auf dem Aldi Dual-Core in uBoot mit nur Single-Core Unterstützung?

...und der Zyxel NSA 212 hat IMHO auch nur single core: 
http://zyxel.nas-central.org/wiki/Bootlog_NSA-221

[Jens D. (jedie)]

Hab mir nochmal per UART angeschaut, was in diesem Abschnitt der rcS 
passiert:

  # Scan USB disk for HW test.
  any_usb=`ls /sys/block/ | grep sd`
  echo "${any_usb}"
  if [ -n "${any_usb}" ]; then
    /bin/mkdir /mnt/parnerkey
    for usb in ${any_usb}
    do
      echo "checking ${usb}"
      #Get the number of question marks
      qmark_num=`fdisk -l /dev/${usb} | grep "^"/dev/${usb} | grep -c "?"`
      partition_num=`fdisk -l /dev/${usb} | grep "^"/dev/${usb}`
      if [ "${qmark_num}" == "4" ] || [ "${partition_num}" == "" ]; then
        mnt_point=/dev/${usb}
        echo "Trying to mount ${mnt_point}"
        mount -o iocharset=utf8,shortname=mixed,ro ${mnt_point} /mnt/parnerkey
      else
        mnt_point=`fdisk -l /dev/${usb} | grep "^"/dev/${usb} | awk '{print $1}' | sed -n '1p'`
        echo "Trying to mount ${mnt_point}"
        mount -o iocharset=utf8,shortname=mixed,ro ${mnt_point} /mnt/parnerkey
      fi
...

Die Ausgaben zu diesem Teil (Ich hab ein ext3 Stick an der vorderen 
Buchse):

sda
sdb
checking sda
Trying to mount /dev/sda1
REISERFS warning (device sda1): super-6502 reiserfs_getopt: unknown mount option "iocharset=utf8"
FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
hfs: unable to parse mount options
udf: bad mount option "shortname=mixed" or missing value
XFS: unknown mount option [iocharset].
yaffs: dev is 8388609 name is "sda1" ro
yaffs: passed flags "iocharset=utf8,shortname=mixed"
yaffs: Bad mount option "iocharset=utf8"
yaffs: dev is 8388609 name is "sda1" ro
yaffs: passed flags "iocharset=utf8,shortname=mixed"
yaffs: Bad mount option "iocharset=utf8"
mount: mounting /dev/sda1 on /mnt/parnerkey failed: Invalid argument
Fail to mount /dev/sda1
checking sdb
Trying to mount /dev/sdb1
REISERFS warning (device sdb1): super-6502 reiserfs_getopt: unknown mount option "iocharset=utf8"
EXT3-fs: Unrecognized mount option "iocharset=utf8" or missing value
EXT4-fs (sdb1): Unrecognized mount option "iocharset=utf8" or missing value
FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
hfs: unable to parse mount options
udf: bad mount option "shortname=mixed" or missing value
XFS: unknown mount option [iocharset].
yaffs: dev is 8388625 name is "sdb1" ro
yaffs: passed flags "iocharset=utf8,shortname=mixed"
yaffs: Bad mount option "iocharset=utf8"
yaffs: dev is 8388625 name is "sdb1" ro
yaffs: passed flags "iocharset=utf8,shortname=mixed"
yaffs: Bad mount option "iocharset=utf8"
mount: mounting /dev/sdb1 on /mnt/parnerkey failed: Invalid argument
Fail to mount /dev/sdb1

Kann das sein, das es IMHO nie klappen wird, weil '''iocharset=utf8''' 
immer falsch ist?

[Michael (Gast)]

Siehe

http://zyxel.nas-central.org/wiki/Usb_key_func.sh#Comments

"In firmware version 3.24 (and in 4.01 for the NSA-320) the options 
iocharset=utf8,shortname=mixed are used for mounting the stick, 
effectively limiting the possible filesystems to vfat only :( . This 
makes it impossible to use symlinks and Posix file permissions."

[Jens D. (jedie)]

Ah! Danke für die Info. Ich wollte gerade alle möglichen Dateisysteme 
mal durchgehen!

Dann könnte man entweder mit zwei Sticks arbeiten, oder sich auf der 
Platte platz schaffen (Wobei ich nicht weiß wie man das machen könnte. 
Wegen RAID config und so...)

Oder ein Stick mit zwei Partitionen: sdb1 mit vfat und sbd2 mit ext3 und 
debian...

[Jens D. (jedie)]

Also fat16 geht schon mal nicht, denn bei '''mount -o 
iocharset=utf8,shortname=mixed,ro /dev/sda1 /mnt/parnerkey''' kommt:

mount: mounting /dev/sda1 on /mnt/parnerkey failed: Invalid argument

auf stderr per UART sehe ich:

REISERFS warning (device sda1): super-6502 reiserfs_getopt: unknown mount option "iocharset=utf8"
FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
hfs: unable to parse mount options
udf: bad mount option "shortname=mixed" or missing value
XFS: unknown mount option [iocharset].
yaffs: dev is 8388609 name is "sda1" ro
yaffs: passed flags "iocharset=utf8,shortname=mixed"
yaffs: Bad mount option "iocharset=utf8"
yaffs: dev is 8388609 name is "sda1" ro
yaffs: passed flags "iocharset=utf8,shortname=mixed"
yaffs: Bad mount option "iocharset=utf8"
NTFS-fs warning (device sda1): parse_options(): Option iocharset is deprecated. Please use option nls=<charsetname> in the future.
NTFS-fs error (device sda1): parse_options(): Unrecognized mount option shortname.

Hier wird vfat nicht aufgeführt.

[Jens D. (jedie)]

OK, ich glaub ich habe es:

/ # mkdosfs /dev/sda1 -v -n USB_vFAT -i 12345678
mkdosfs 2.11 (12 Mar 2005)
/dev/sda1 has 255 heads and 63 sectors per track,
logical sector size is 512,
using 0xf8 media descriptor, with 1028096 sectors;
file system has 2 16-bit FATs and 16 sectors per cluster.
FAT size is 251 sectors, and provides 64222 clusters.
Root directory contains 512 slots.
Volume ID is 12345678, volume label USB_vFAT   .
~ # mount -o iocharset=utf8,shortname=mixed,ro /dev/sda1 /mnt/parnerkey

Oiginal mount, wie beim booten, geht schonmal :)

Also dann mal weiter, erstmal mit einer leeren check_file um zu sehen, 
was beim booten passiert:

~ # umount /mnt/parnerkey/
~ # mount -o iocharset=utf8,shortname=mixed,rw /dev/sda1 /mnt/parnerkey
~ # touch /mnt/parnerkey/STG212_check_file
~ # reboot

[Markus (Gast)]

Hat schon jemand den Medion-Support angeschrieben weil das NAS im Moment 
nur einen Kern nutzt? Immerhin wurde das System mit "Dual-Core" 
beworben, da kann Otto-Normaluser eigentlich davon ausgehen, dass auch 
beide Cores genutzt werden...

[Jens D. (jedie)]

Es geht!

Also Dateisystem auf USB-Stick mit mkdosfs machen, s.o.

Dann folgende Dateien drauf packen:

usb_key_func.sh

#!/bin/sh
echo "Hello from usb_key_func.sh !!!"

STG212_check_file

/mnt/parnerkey/usb_key_func.sh
/mnt/parnerkey/usb_key_func.md5

md5 erzeugen mit:

cat /etc/Zy_Private usb_key_func.sh | md5sum > usb_key_func.md5

Hat dann einen Inhalt von:

f24d7a2705c8c5746be33b31c4e0171c  -

Beim Booten sieht man dann die Ausgabe: "Hello from usb_key_func.sh !!!" 
Danach geht es dann nicht mehr weiter!

d.H. die, die kein UART haben, sehen nix und die Box sieht tot aus, weil 
nicht weiter gebootet wird.
Wenn '''usb_key_func.sh''' mit '''exit 1''' endet, dann geht der 
Bootvorgang weiter! Das sollten also die Leute ohne Serielle-Ausgabe 
machen...



SO! Nun kann man sich also recht früh in den Bootvorgang einklinken und 
ganz unterbrechen. Somit könnte man doch dann mit einem anderen System 
weiter machen!!! Halt die chroot Geschichte mit Debian oder was 
anderes...

[Jens D. (jedie)]

Per UART sieht das dann mit dem Stick so aus:

checking sdb
Trying to mount /dev/sdb1
REISERFS warning (device sdb1): super-6502 reiserfs_getopt: unknown mount option "iocharset=utf8"
FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
cp: '/mnt/parnerkey/usb_key_func.sh' and '/mnt/parnerkey/usb_key_func.sh' are the same file
cmd = cat /etc/Zy_Private /mnt/parnerkey/usb_key_func.sh | md5sum -c /mnt/parnerkey/usb_key_func.md5 
md5 check ok
Hello from usb_key_func.sh !!!

Please press Enter to activate this console.

Dann ist das System noch "sauberere":

BusyBox v1.17.2 (2011-10-05 21:33:07 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/ # mount
rootfs on / type rootfs (rw)
/proc on /proc type proc (rw,relatime)
/sys on /sys type sysfs (rw,relatime)
none on /proc/bus/usb type usbfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,uid=0,gid=5,mode=620)
/dev/mtdblock6 on /zyxel/mnt/info type yaffs2 (ro,relatime)
/dev/mtdblock7 on /zyxel/mnt/sysdisk type yaffs2 (ro,relatime)
/dev/sdb1 on /mnt/parnerkey type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=utf8,shortname=mixed,errors=remount-ro)
/ # cat /proc/modules 
gmac 47336 0 - Live 0xbf004000
mii 6764 1 gmac, Live 0xbf000000
/ # top
Mem: 36280K used, 87784K free, 0K shrd, 24K buff, 6220K cached
CPU:  0.0% usr  0.0% sys  0.0% nic 99.4% idle  0.0% io  0.0% irq  0.5% sirq
Load average: 0.09 0.28 0.14 1/37 1326
  PID  PPID USER     STAT   VSZ %MEM CPU %CPU COMMAND
 1326  1321 root     R     2796  2.2   0  0.0 top
 1321  1236 root     S     2796  2.2   0  0.0 -/bin/sh
    1     0 root     S     2716  2.1   0  0.0 /bin/sh /init
 1236     1 root     S     2716  2.1   0  0.0 init
    5     2 root     SW<      0  0.0   0  0.0 [events/0]
  682     2 root     SW<      0  0.0   0  0.0 [scsi_eh_0]
    6     2 root     SW<      0  0.0   0  0.0 [khelper]
    2     0 root     SW<      0  0.0   0  0.0 [kthreadd]
  946     2 root     SW<      0  0.0   0  0.0 [usb-storage]
    3     2 root     SW<      0  0.0   0  0.0 [migration/0]
    4     2 root     SW<      0  0.0   0  0.0 [ksoftirqd/0]
    9     2 root     SW<      0  0.0   0  0.0 [async/mgr]
  105     2 root     SW<      0  0.0   0  0.0 [kblockd/0]
  110     2 root     SW<      0  0.0   0  0.0 [ata/0]
  111     2 root     SW<      0  0.0   0  0.0 [ata_aux]
  112     2 root     SW<      0  0.0   0  0.0 [harddrive_led]
  117     2 root     SW<      0  0.0   0  0.0 [khubd]
  138     2 root     SW<      0  0.0   0  0.0 [button controll]
  150     2 root     SW       0  0.0   0  0.0 [pdflush]
  151     2 root     SW       0  0.0   0  0.0 [pdflush]

[Michael (Gast)]

Jens D. wäre toll, wenn du mal probieren könntest U-Boot dazu zu bringen 
Verbindungen übers Netzwerk zu akzeptieren. So können auch Leute ohne 
Zugang zur serielle Schnittstelle auch rumprobieren :) Vielleicht mal 
was flashen oder so :) Oh oh gefährlich!

[Jens D. (jedie)]

Das ist nicht so einfach... Dazu braucht man ein uBoot mit netconsole... 
So wie für die Dockstar. Gibt es aber IMHO noch nicht. Wenn jemand was 
macht, kann ich es gern per TFTP testen...

Einen "usb_key_func.sh" Stick zu benutzten ist aber gefahrlos, nur sieht 
man erstmal nix. Man könnte vielleicht einen SSH Server laufen lassen...

Aber ich komme damit eh nicht weiter, denn ich dann /dev nicht 
durchreichen:

/ # export ROOT=/mnt/debian/
/ # mount --bind /sys ${ROOT}sys
/ # mount --bind /dev ${ROOT}dev
mount: mounting /dev on /mnt/debian/dev failed: Invalid argument
/ # mount --bind /proc ${ROOT}proc

sys und proc gehen, aber dev nicht und ohne dev kann man IMHO nicht 
wirklich was Sinnvolles machen :(

Siehe auch: http://debianforum.de/forum/viewtopic.php?f=12&t=133224

Das mit dev ist aber auch unabhängig vom Stick. Das kann man auch normal 
über Telnet Probieren...

Ich dachte mir sowas in der Art:

'''usb_key_func.sh''' auf sdb1 des Sticks:

#!/bin/sh
echo "...continue loading debian..."

mkdir /mnt/debian
mount /dev/sdb2 /mnt/debian

/mnt/debian/usb_key_func2.sh

'''usb_key_func2.sh''' auf sdb2 des Sticks:

#! /bin/sh

ROOT=/mnt/debian/

export TERM=xterm-color

mount --bind /dev ${ROOT}dev
mount --bind /sys ${ROOT}sys
mount --bind /proc ${ROOT}proc

cp /etc/Zy_Private ${ROOT}etc/Zy_Private

chroot ${ROOT}

#~ /etc/init.d/rcS
/etc/init.d/rc 2

Wie man nach dem chroot Sinnvoll weiter macht, weiß ich nicht.

[Franz (Gast)]

Markus schrieb:
> Hat schon jemand den Medion-Support angeschrieben weil das NAS im Moment
> nur einen Kern nutzt? Immerhin wurde das System mit "Dual-Core"
> beworben, da kann Otto-Normaluser eigentlich davon ausgehen, dass auch
> beide Cores genutzt werden...

Gibt es denn Beweise dass nur ein Kern benützt wird und der zweite Kern 
nicht bei Bedarf zugeschalten wird?

Ich ruf gern bei Medion an und urgiere das Thema, allerdings hab ich 
persönlich keinen Beweis in der Hand.
Wenn ihr den Beweis habt und euch der Zeit zu schade seid bei Medion 
anzurufen, dann übernehme ich das gern - wenn ich schon nix 
Software/Hardware technisch beitragen kann, dann soll das mein Beitrag 
sein ;)

[Jens D. (jedie)]

Man sollte auch die Temperatur erwähnen. Aber da können die schlecht was 
Sinnvolles per Software ändern... :(

[Michael (Gast)]

Franz schrieb:
> Gibt es denn Beweise dass nur ein Kern benützt wird und der zweite Kern
> nicht bei Bedarf zugeschalten wird?

Zuschalten eines zweiten Kerns macht Linux nicht.

Beweise:
1) Telnet backdoor auf einem unmodifizierten NAS aktivieren.
2) dmesg auf der Console eintippen. Dort steht in einer Zeile: "Brought 
up 1 CPUs".
3) "cat /proc/cpuinfo" zeigt auch nur einen Kern.

[Arthur D. (graznik)]

Franz schrieb:
> ich weiß nicht ob es schon gepostet wurde, aber auf medion.at ist der
> gpl_source zum download verfügbar:
>
> http://www1.medion.de/downloads/download.pl?lang=d...
>
> nützt der einem in irgendeiner Weise etwas?
>

Hallo Franz,

das nützt in der Hinsicht, dass nun endlich eine funktionierende 
Cross-Compiler-Toolchain zur Verfügung steht:

 
wget -c download2.medion.com/downloads/software/gpl_source_md86407.exe
wine gpl_source_md86407.exe
cd ~/.wine/drive_c/Medion/
tar -xvf x-tools.armv5v6.tar.gz
mv x-tools ~/
export CC=~/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc

Somit lässt sich nun endlich auch dropbear wie gewünscht compilieren:

  tar -xvf dropbear-2011.54.tar.gz
  cd dropbear-2011.54
  ./configure --host=arm
  make dropbear dbclient dropbearkey dropbearconvert scp

Danke für den Link, ich bin begeistert!

Viele Grüße

graznik

[Jens D. (jedie)]

Arthur Dent schrieb:
> das nützt in der Hinsicht, dass nun endlich eine funktionierende
> Cross-Compiler-Toolchain zur Verfügung steht

Hm!

Kann dann jemand reloaded-2.6.31.14_SMP_820.ko erstellen???

Siehe:
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"
http://zyxel.nas-central.org/wiki/Reloaded

Mehr Info + Sourcen v0.7.121:
http://www.inreto.de/dns323/reloaded/dns323-reloaded-0.7.121/

keine Info, aber Sourcen v0.7.167:
http://www.inreto.de/dns323/reloaded/dns323-reloaded-0.7.167/


Dann würde nämlich auch das mit dem "usb_key_func" richtig Sinn machen!
Hab dazu eine Wiki Seite gemacht: 
http://www.mikrocontroller.net/articles/P89626/usb_key_func Bestehende 
P89626 ließ sich wieder nicht ändern :(

[ElektromAn (Gast)]

Hallo,

ich mache mir mal die Sache einfach, da mir jetzt der Thread zu lang 
wird und unterteile meinen Post

@all, wegen FS Fehler, Virenscanner und Co.
ich habe gesehen das die FS (XFS) für die Paltte mit nobarrier 
gemountet werden.
Bitte mal die FS mit

mount -o remount,barrier

re-mounten.

@all wegen CPU
Die CPU muss im Bootvorgang erkannt werden, danach ist es nicht mehr 
möglich, die CPU "einzuschalten". Der Scheduler fordert beim Kernel Init 
den Speicher an. Und Hotswapable CPUs gibt es bei ARM nicht.

@all, wegen crossdev und glibc-2.8*
Das Problem habe ich auch. Ich habe jetzt die Holzhammermethode 
genommen und eben das ohne jede Option gemacht, mal sehen was daraus 
kommt.
ggf. ist es möglich den Kernel von 2.6.30 zu rebasen.
Die Quellen von der PogoplugPro scheinen OK zu sein.
Auch habe ich dort die GPIO Pins für das Abschalten der Platte gefunden.
Einfach

make menuconfig ARCH="arm"

Unter System dann das Oxford NAS auswählen. Da gibt es eine menge 
Optionen.

@all, wegen Zyxel kompatiblität
Die Zyxel BOX 210? hat einen alten 2.6.24.4.Kernel und soll schon die 
GPT lesen können.

[ElektromAn (Gast)]

@Franz, Arthur Dent
Eine exe Datei ???
gnaaaaahhhhhhhhh.
Da muss ich ja wirklich noch meine W*ndows BOX aus dem Keller hohlen.
Und nein ich habe kein Wine und Co. auf meinem Rechner.
Eine Toolchain habe ich schon und git ist sowieso auf meinem Rechner.

@Franz .D
was sollt denn
reloaded-2.6.31.14_SMP_820.ko
tun ?? kexec ??

E-mAn

[Michael K. (michaelkebe)]

Ich versuche mich gerade daran u-boot mit netconsole support zu bauen. 
So wie es scheint hat es auch funktioniert. Es werden folgende Dateien 
gebaut:

-rwxrwxr-x   1 michael michael 319898 2011-12-09 20:39 u-boot.srec
-rw-rw-r--   1 michael michael  88942 2011-12-09 20:39 u-boot.map
-rwxrwxr-x   1 michael michael 106596 2011-12-09 20:39 u-boot.bin
-rwxrwxr-x   1 michael michael 421383 2011-12-09 20:39 u-boot
-rw-rw-r--   1 michael michael  14354 2011-12-09 20:39 System.map

Kann damit jemand was anfangen? Kann man die schon nehmen und mit dem 
u-boot was von Haus aus drauf ist chainloaden?

Ich habe folgendes getan.

Ich habe erstmal geguckt ob die Version 1.1.2 von u-boot überhaupt 
netconsole kann. Es gab einen commit im August 2004:
http://git.denx.de/u-boot.git/?p=u-boot.git;a=commit;h=68ceb29e7133a0f972f53d3d61fd61207374baec

Ausserdem ist die 1.1.2 von Januar 2005 (falls das Datum der Datei 
stimmt):
http://ftp.denx.de/pub/u-boot/

Ich habe mir die Quelle drivers/netconsole.c angeschaut:
http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=drivers/netconsole.c;h=7e19161321ac32d4555fbb4f84f8e77800d2b2d6;hb=68ceb29e7133a0f972f53d3d61fd61207374baec

Netconsole support wird gebaut, wenn das define CONFIG_NETCONSOLE 
gesetzt ist. Ausserdem wird CONFIG_NET_MULTI benötigt.

Diese beiden Defines habe ich in der include/configs/ox820.h 
hinzugefügt:

...
#define CONFIG_NET_MULTI
#define CONFIG_NETCONSOLE
...

Ich bin auf die ox820.h gekommen, weil in der Readme steht:

...
2.You can manually build the u-boot-1.1.2 by command: ./zyxel-STG212.sh
...

und in dem script zyxel-STG212.sh steht:

...
make ox820_config CROSS_COMPILE=/opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi- MEM_SIZE=${MEM_SIZE} MODEL=${MODEL} INTERNAL_UART=${INTERNAL_UART}
...

Nach einem ./zyxel-STG212.sh hatte ich die o.g. Dateien.

[Lucian M. (lucian_m)]

ElektromAn schrieb:
> @Franz .D
> was sollt denn
> reloaded-2.6.31.14_SMP_820.ko
> tun ?? kexec ??

Scheint sowas in der Art.... Abgefahren, aber interessant....

Mit Holzhammermethode vorhin meintest Du mit crossdev das target ohne 
Versionsbeschränkung zu bauen?

[Michael K. (michaelkebe)]

Am Ende des Bauens kommt eine Meldung (letzten 3 Zeilen):

UNDEF_SYM=`/opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-objdump -x lib_generic/libgeneric.a board/oxnas/liboxnas.a cpu/arm11/libarm11.a lib_arm/libarm.a fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a fs/reiserfs/libreiserfs.a fs/ext2/libext2fs.a net/libnet.a disk/libdisk.a rtc/librtc.a dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a post/libpost.a post/cpu/libcpu.a common/libcommon.a drivers/mtd/nand/libnand.a drivers/mtd/spi/libspi_flash.a drivers/spi/libspi.a |sed  -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
    /opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld -Bstatic -T /home/michael/medion/build_NSA212/trunk/sysapps/u-boot-1.1.2/board/oxnas/u-boot.lds -Ttext 0x60d00000  $UNDEF_SYM cpu/arm11/start.o \
      --start-group lib_generic/libgeneric.a board/oxnas/liboxnas.a cpu/arm11/libarm11.a lib_arm/libarm.a fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a fs/reiserfs/libreiserfs.a fs/ext2/libext2fs.a net/libnet.a disk/libdisk.a rtc/librtc.a dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a post/libpost.a post/cpu/libcpu.a common/libcommon.a drivers/mtd/nand/libnand.a drivers/mtd/spi/libspi_flash.a drivers/spi/libspi.a --no-warn-mismatch -L /opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2 -lgcc --end-group \
      -Map u-boot.map -o u-boot
/opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O srec u-boot u-boot.srec
/opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin
-e Do not forget to append the header by tool 'packager' in branch/stage1/tools/

-e Usage: packager u-boot.bin u-boot.wrapped

Ich bin unter build/stage1/tools fündig geworden und habe da packager.c 
gefunden. Da habe ich folgendes gemacht:

michael@mrmuh:~/medion/build_NSA212/trunk/sysapps/u-boot-1.1.2$ cd ../../build/stage1/tools/
michael@mrmuh:~/medion/build_NSA212/trunk/build/stage1/tools$ make packager
gcc -c -g -I . -I ../include ../src/crc32.c -o crc32.o
gcc -c -g -I . -I ../include   -c -o packager.o packager.c
gcc crc32.o -lc packager.o -o packager
michael@mrmuh:~/medion/build_NSA212/trunk/build/stage1/tools$ cd -
michael@mrmuh:~/medion/build_NSA212/trunk/sysapps/u-boot-1.1.2$ ../../build/stage1/tools/packager u-boot.bin u-boot.wrapped
Input file - u-boot.bin
Output file - u-boot.wrapped
Input File Size - 106596

Aber was machen wir jetzt mit den Dateien?

[Lucian M. (lucian_m)]

Michael Kebe schrieb:
> Aber was machen wir jetzt mit den Dateien?

Irgendwo in den Sourcen findet man bestimmt auch heraus, wie man 
entweder diese .bin oder die .wrapped flashen kann, ist aber riskant. Am 
besten soll die jemand mit UART aus dem stock-bootloader mal versuchen 
zu chainloaden, um dann zu sehen ob man sich mit der netconsole 
verbinden kann.

Interesant wäre auch heraus zu finden, ob uBoot auch selber die 
SATA-Festplatte ansprechen kann, um z.B. das Kernelimage und eine 
Ramdisk anstatt aus dem NAND von einer Partition zu laden....

[Dimpflmoser (Gast)]

Jens D. schrieb:
> Dimpflmoser schrieb:
>> Auf dem Laptop habe ich Minicom am Laufen mit den Parametern 115200 8n1
>> minicom -D /dev/ttyUSB0
>
> Teste doch mal mit:
>
>   screen /dev/ttyUSB0 115200

In meiner Verzweiflung habe ich das natürlich auch getestet.
Mit dem Terminalprogramm hat man halt den Vorteil dass man auch noch 
einfach xon/xoff und HW-Handshake testen kann, wobei HW-Handshake bei 
3-adrigem Anschluss natürlich Müll ist.

Habe auch verschiedene Geschwindigkeiten von 9600-230000 getestet, aber 
das hilft alles nichts.
Ich hatte mir gefragt ob denn der PL2302 auf der RS232-Seite direkt mit 
dem NAS verbunden wird oder ob's eventuell auf der USB-Seite ist, wobei 
das natürlich eher Müll wäre, oder?

Habe leider keinen anderen PL2302 gefunden mit dem ich das testen 
könnte.
Macht es denn Sinn einen MAX323 dazwischen zu hängen?

Tschüss Dimpflmoser

[Lucian M. (lucian_m)]

Jens D. schrieb:
> Mehr Info + Sourcen v0.7.121:
> http://www.inreto.de/dns323/reloaded/dns323-reload...
>
> keine Info, aber Sourcen v0.7.167:
> http://www.inreto.de/dns323/reloaded/dns323-reload...
>
>
> Dann würde nämlich auch das mit dem "usb_key_func" richtig Sinn machen!
> Hab dazu eine Wiki Seite gemacht:

Naja, die Sourcen müsste man noch anpassen, aber vermutlich könnte man 
das sogar ohne irgendwelche usb_key_funk dinger dann auch über Telnet 
manuell laden, und als Parameter eine initrd und ein RootFS von der 
internen Platte, was man vorher dort ablegt, angeben, oder? 
Möglicherweise parallel mit den Shares, die würden sich vermutlich schon 
nicht beissen...

[Michael K. (michaelkebe)]

Hier ist die von mir gebaut u-boot version. Hoffentlich mit 
funktionierender netconsole.

http://dl.dropbox.com/u/4081494/p89626/u-boot/u-boot-p89626-netconsole.tar.gz

Da es eine alte Version (1.1.2) von u-boot ist, muss man die netconsole 
wohl so konfigurieren wie es hier steht:

http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=doc/README.NetConsole;h=8dc0d29197ec0cba86a86a55d64638e137f1d65e;hb=68ceb29e7133a0f972f53d3d61fd61207374baec

Jens probier die mal bitte aus :)

[Jens D. (jedie)]

Lucian M. schrieb:
> vermutlich könnte man
> das sogar ohne irgendwelche usb_key_funk dinger dann auch über Telnet
> manuell laden, und als Parameter eine initrd und ein RootFS von der
> internen Platte, was man vorher dort ablegt, angeben, oder?

Vermutlich. Wobei das dann auf jeden Fall länger beim Booten braucht.

Ich hab auch mal eine alternative usb_key_func.sh im Wiki rein gestellt, 
die dann Telnet startet, somit können das dann auch Leute ohne UART 
testen:

http://www.mikrocontroller.net/articles/P89626/usb_key_func#alternative_usb_key_func.sh


Zu uBoot: Man kann IMHO uBoot mit SATA und USB Unterstützung fertig 
backen.

[Lucian M. (lucian_m)]

Jens D. schrieb:
> Zu uBoot: Man kann IMHO uBoot mit SATA und USB Unterstützung fertig
> backen.

Ja klar, ich habe mich wohl eher nicht genau genug ausgedrückt, ob 
dieses uBoot das schon kann, oder relativ leicht aus den Sourcen (in 
denen ich SATA-Zeugs durchaus gesehen habe, sogar in der erwähnten 
ox820.h) mit entsprechender Unterstützung gebaut werden kann.

[Jens D. (jedie)]

Sieht ganz ok aus. Zumindest kann ich deine Version starten:

U-Boot 1.1.2 (Jun 24 2011 - 09:41:57)
...
$ tftp 0x61000000 u-boot.bin
...
Bytes transferred = 106596 (1a064 hex)
$ go 61000000
## Starting application at 0x61000000 ...


U-Boot 1.1.2 (Dec  9 2011 - 20:58:42)
...

[Jens D. (jedie)]

Anscheinend geht dann im neuen uBoot das Netzwerk nicht mehr:

$ setenv start_netconsole 'setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; version;'
$ setenv preboot 'run if_netconsole start_netconsole'
$ run preboot
Using unknown device

ARP Resend request

ARP Resend request

ARP Resend request

ARP Resend request

ARP Resend request
ping failed; host 192.168.7.2 is not alive

Vorher konnte ich mir ja über tftp die andere bin datei ziehen...

[Michael K. (michaelkebe)]

Ich bau nochmal eine ohne die Änderungen (also ohne netconsole) zum 
probieren.

[DiSa (Gast)]

Arthur Dent schrieb:
> Hallo Franz,
>
> das nützt in der Hinsicht, dass nun endlich eine funktionierende
> Cross-Compiler-Toolchain zur Verfügung steht:
>
> wget -c download2.medion.com/downloads/software/gpl_source_md86407.exe
> wine gpl_source_md86407.exe
> cd ~/.wine/drive_c/Medion/
> tar -xvf x-tools.armv5v6.tar.gz
> mv x-tools ~/
> export CC=~/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi- 
gcc
>
> Somit lässt sich nun endlich auch dropbear wie gewünscht compilieren:
>   tar -xvf dropbear-2011.54.tar.gz
>   cd dropbear-2011.54
>   ./configure --host=arm
>   make dropbear dbclient dropbearkey dropbearconvert scp
>
> Danke für den Link, ich bin begeistert!
>
> Viele Grüße
>
> graznik

Nicht nur dropbear lässt sich bauen, auch der Bau von rsync funktioniert 
mit der toolchain, man muss nur acl disablen.

In den Sourcen scheint auch noch die eine oder andere Information zu 
stecken ...

Vielen Dank für den Link!

[Michael K. (michaelkebe)]

Jens:

Hier nochmal eine die ohne Änderungen an den Quellen gemacht wurde.

http://dl.dropbox.com/u/4081494/p89626/u-boot/u-boot.bin.untouched

[Jens D. (jedie)]

Sorry, kann erst wieder MO weiter testen...

[Michael K. (michaelkebe)]

Kein Problem.

Schönes Wochenende ihr Hacker ;)

[Arthur D. (graznik)]

ElektromAn schrieb:
> @Franz, Arthur Dent
> Eine exe Datei ???
> gnaaaaahhhhhhhhh.
Ich kann deine Ablehnung verstehen.

> Da muss ich ja wirklich noch meine W*ndows BOX aus dem Keller hohlen.
> Und nein ich habe kein Wine und Co. auf meinem Rechner.
Dann solltest du Wine einfach installieren, tut auch gar nicht weh, 
versprochen. Die .exe startest du nur einmal zum Entpacken der Dateien, 
danach kannst du wine auch wieder deeinstallieren.

Gruß

graznik

[ElektromAn (Gast)]

@Arthur Dnet
ich hatte W*ndows noch auf einen anderen Rechner ...
Ich habe mich mittlerweile an Linux (Sabayon/Gentoo) gewöhnt.

Besonders gut ist die Sache mit dem SSH Tunnel.
Einige meiner Arbeitskollegen haben Probleme mit einen einfachen VPN 
Tunnel ala VNC. Da gibt es ein Programm das es relativ easy macht, man 
muss nur so eine PIN eingeben.
Ich habe ein etwas manchmal eine etwas seltsame Config
Doppeltes NAT im Source (UMTS und Router) und dazu noch doppeltes NAT 
zuhause.
Wenn die Leute dann von meinem Source auf ihr (Heim-)Netwerk wollen 
fliegen die auf die Fr*sse ...

Anyway
Archiv gezogen und einpackt.
Die Kernel Source sind Version 2.6.31.14 es sind nur sechs Security 
Patchesd gegenüber dennen Sourcen vom PogoplugPro dirn.

So für für U-Boot Leute ein git-repo für die oxnas

git remote show origin
* remote origin
  Fetch URL: git://github.com/lemenkov/u-boot-oxnas.git
  Push  URL: git://github.com/lemenkov/u-boot-oxnas.git
  HEAD branch: oxnas
  Remote branches:
    master                 tracked
    oxnas                  tracked
    oxnas-vendor_supplied  tracked
    thecus-vendor_supplied tracked
  Local branch configured for 'git pull':
    oxnas merges with remote oxnas
  Local ref configured for 'git push':
    oxnas pushes to oxnas (up to date)

Dann noch ein 3.1.* Kernel

git remote show origin
* remote origin
  Fetch URL: git://github.com/redsquare123/OX820-3.1-Linux.git
  Push  URL: git://github.com/redsquare123/OX820-3.1-Linux.git
  HEAD branch: master
  Remote branch:
    master tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

In den sourcen von Medion sind auch die Kernelconfigs in der Datei 
*STG212_Kernel.config*

Der 3.1.* Kernel ist schlecht gemanaged. Der wird es nie in Mainline 
schaffen ... Realname fehlt.

In menuconfig ist die Rede von Leon Support.
Das ist ein Coprozessor der TOE (für Ethernet) macht. Ich habe auch 
irgendwo gesehen das der Watchdog auch darüber läuft, bin mir da aber 
nicht sicher.
Der Copro (Leon) wird beim Kernelboot mit einer Firmware geladen. Im 
Verzeichnis /arch/arm/plat-oxnas liegt diese. Irgendwas mit S-Records.

Die Sourcen von U-Boot haben netconsole Support

@Jens D.
ja ich habe die default config für crossdev genommen. Ich muss 
vielleicht noch die Kernelversion angeben.

@all
An die Leute die es mit crossdev unter Sabayon/Gentoo versuchen wollen 
:
Bitte wenn layman installliert ist und die *ebuild's* von Sabayon 
holt, diese erstmal deaktivieren

layman -d OVERLAY

Es werden sonst die Sabayon ebuild's für crossdev benutzt und de sind 
nicht darauf getestet worden.

E-mAn
PS
Schöne Wochenende ...

[Markus (Gast)]

Hab Medion angeschrieben, mal sehen, ob sie antworten...:

"Hallo, das Medion NAS P89626, welches letzte Woche bei Aldi Süd 
erhältlich war wurde mit "Dual Core" beworben.
Nach Foreninformationen wird jedoch nur ein Core dieses Systems genutzt.
Wird es in absehbarer Zeit eine neue Firmware geben, mit der die 
beworbene "Dual Core"-Funktionialität hergestellt, d.h. auch der zweite 
Core genutzt wird? Mit freundlichen Grüßen"


Vielleicht sollten noch mehr Leute mit dem Hinweis auf "wie in der 
Werbung ist das aber nicht" an Medion schreiben.
Wobei ich die Befürchtung hege, dass sie den 2. Core eventuell aus 
Wärmegründen deaktiviert haben - aber dann baue ich lieber eine aktive 
Kühlung ein, mit nahezu doppelter CPU-Power sollten die Transferraten 
die 50MB/s locker knacken können.
Andererseits hat die Vermutung "vorhandene Firmware einer 
Singlecorelösung aus Bequemlichkeit nahezu 1:1 übernommen" auch etwas 
für sich  ;)

[Dirk S. (disa)]

Markus schrieb:
> Vielleicht sollten noch mehr Leute mit dem Hinweis auf "wie in der
> Werbung ist das aber nicht" an Medion schreiben.
> Wobei ich die Befürchtung hege, dass sie den 2. Core eventuell aus
> Wärmegründen deaktiviert haben - aber dann baue ich lieber eine aktive
> Kühlung ein, mit nahezu doppelter CPU-Power sollten die Transferraten
> die 50MB/s locker knacken können.

Ich habe heute morgen ein paar Geschwindigkeits-Tests gemacht, 
allerdings mit ernüchterndem Ergebnis. Ich habe das NAS über NFS an 
meinen Linux-Rechner gehängt und ein paar Dateien (insgesamt so ca. 
70GB) kopieren wollen. Am Anfang, direkt nach dem Einschalten hatte ich 
Transferraten, die lagen bei ca. 50-51MB/sec (1GBit LAN). Das Kopieren 
habe ich sporadisch mit df geprüft, dann urplötzlich wurde der freie 
Speicher auf dem NAS größer(!) anstatt kleiner, obwohl fleißig weiter 
kopiert wurde. Die Temperatur des NAS stieg auf über 56 Grad Celsius und 
smart lieferte deshalb FAILURES.
Ich habe dann den Test abgebrochen und nach einiger Zeit noch ein paar 
neue Tests gestartet. Hierbei waren die Transferraten nur bei ca 
11MB/sec. Ich vermute, dass die CPU-Temperatur einen sehr großen 
Einfluss auf die Transferraten hat und die CPU bei hohen Temperaturen 
automatisch heruntergetaktet wird.

[Tomi (Gast)]

Müßte der PLX 7825 sein ..

http://go.iomega.com/de/products/network-storage-desktop/home-network-hard-drives/home-media-cloud/?partner=4710#tech_specsItem_tab

source code 
>https://iomega-eu-de.custhelp.com/app/answers/detail/a_id/27383

kann man damit was anfangen..?

Greetz

[Michael K. (michaelkebe)]

Tomi schrieb:
> Müßte der PLX 7825 sein ..

Was meinst du damit? Laut den Sourcen von Medion ist das Ding ziemlich 
ähnlich zum Zyxel NSA 212. Werden teilweise die gleichen Sourcen 
genutzt. Ich lad die von dir genannten Sourcen mal runter und schau 
drüber.

[ElektromAn (Gast)]

@all die sich über die schlechte Netzwerkperformance beschweren

Das Problem glaube ich nicht die CPU !
Das meiste dürfte durch MMAP (für die Leute die es nicht kennen eine Art 
DMA) im Speicher hin- und hergeschoben werden. Dafür gibts im Kernel die 
Funkionen sendfile und Co.

CRC vom IP Frame dürfte der GMAC Teil des SoC machen. Dafür ist der 
Copro Leon zuständig. Die macht TOE, aber leider gehen diese Daten 
auch über dem "internen" SoC Bus und über deren Bandbreite habe ich noch 
nichts gelesen.

Kann denn die eingebaute Platte mehr als *50Mbyte/s* ?

Der Souce ist von einem Marvell Feroceon/Kirkwood Dual Core System.

E-mAn

[Tomi (Gast)]

Hier ist die Pdf (Home Media Gateway)..

..http://plxtech.com/pdf/apps/ExpApp82_NAS7825_Home_Media_Gateway.pdf

[Markus (Gast)]

Dirk S. schrieb:
> Ich habe dann den Test abgebrochen und nach einiger Zeit noch ein paar
> neue Tests gestartet. Hierbei waren die Transferraten nur bei ca
> 11MB/sec. Ich vermute, dass die CPU-Temperatur einen sehr großen
> Einfluss auf die Transferraten hat und die CPU bei hohen Temperaturen
> automatisch heruntergetaktet wird.

Ich habe einen 12V Gehäuselüfter, den ich mit 5V betreibe (schön leise) 
oben auf das NAS gelegt, so dass er die Luft aus dem Gehäuse saugt. Das 
mache ich immer dann, wenn ich größere Datenmengen transferiere 
(ansonsten nutze ich das Gerät hauptsächlich für das Streamen zum 
Fernseher). Keine Temperaturprobleme :)

[ElektromAn (Gast)]

@Tomi

Auf plxtech gibt es noch ein PDF mit dem NAS7820 SoC.
Dort kannst du auch den internen Aufbau des SoC sehen.

Bei deinem Datenblatt siehst du nur die externe Anbindung.
Der NAS7825 dürfte auch bei der PogopugPro drin sein, wegen dem WLAN.
Laut Kconfig irgendwas mit RT2XXX b/g/n WLAN.
Auch hat diese noch einen versteckten SATA Port ;-)

NAS7820 +  PCIe = NAS 7825

Und für die serielle Console ist ein Anschluss vorhanden ;-)

E-mAn

[Tomi (Gast)]

Joop, den kenn ich ja schon, es muß doch irgendwo Baugleiche Teile 
geben,

 mit'm besseren Os / FW.. (als son ineffizientes altes von zyxel).

[Dirk S. (disa)]

Apropos Performance, es scheint, als ob das Netzwerk der limitierende 
Faktor ist, wenn auch die Schreib-Performance der HD etwas zu wünschen 
übrig lässt (hat jemand Erfahrungen hinsichtlich XFS und Performance?):

Lesen über nfs:
129652+0 records in
129652+0 records out
2124218368 bytes (2.1 GB) copied, 77.6824 s, 27.3 MB/s

Schreiben (kopieren) über nfs:
129652+0 records in
129652+0 records out
2124218368 bytes (2.1 GB) copied, 257.8 s, 8.2 MB/s

Lesen local auf dem NAS:
129652+0 records in
129652+0 records out
2124218368 bytes (2.0GB) copied, 24.260484 seconds, 83.5MB/s

Schreiben local auf dem NAS (kopieren einer Datei):
129652+0 records in
129652+0 records out
2124218368 bytes (2.0GB) copied, 106.430207 seconds, 19.0MB/s

[Markus (Gast)]

Dirk S. schrieb:
> Apropos Performance, es scheint, als ob das Netzwerk der limitierende
> Faktor ist, wenn auch die Schreib-Performance der HD etwas zu wünschen
> übrig lässt (hat jemand Erfahrungen hinsichtlich XFS und Performance?):

Kann ich so nicht direkt bestätigen. Ich befülle das NAS seit ca. 1.5h 
mit TV-Mitschnitten (je ~1GB groß) und habe bereits 200GB kopiert. Das 
macht etwas über 2GB/Min oder 2000:60 = 33.3 MB/s (Win 7 zeigt mir 35.5 
MB/s an um genau zu sein). Die CPU-Last ist zwischen 80% und 100%, mein 
smbd pendelt zwischen 70% und 95%.
HDD-Temperatur laut SMART ist 33°, das NAS steht auf einem (Marmor-) 
Fenstersims mit sehr dezenter aktiver "von oben saugen"-Belüftung wie in 
meinem letzten Post beschrieben.
Die CPU läuft nicht komplett auf Anschlag (idelt noch so mit 5%-20% laut 
top), wäre interessant ob mit dem 2. Core noch mehr drin wäre. Nun ja, 
zumindest würden die "Nebenaufgaben" (Indizieren der Medien, 
DLNA-Server, Apache, etc) nicht bremsen...
Würde gernen den Unterschied der aktuellen Firmware ( 1.00(UZD.2) ) zu 
der in Australien initial mitgelieferten ( 1.00(UZD.0) ) erfahren, nicht 
dass der Multicoresupport wegen Wärmeproblemen weggepatched wurde. 
Zumindest berichten einige User von Performancewerten, die ich so mit 
meinem System nicht hinbekommen..?

[Michael K. (michaelkebe)]

Habt ihr euch mal die gezogenen Backup von /dev/mtd1 und /dev/mtd2 
angeschaut?

Irgendwie sehen die nicht gut aus. Irgendwie nur die beiden Hexwerte 55 
und AA. Irgendwann nur noch FF bis zum Ende. Was meint ihr?

[Michael K. (michaelkebe)]

Ich habe mir soeben den halben Flashspeicher mit dem Programm nandtest 
(aus dem Debian package mtd-utils) kaputtgeschrieben. Und zwar mit 
"nandtest /dev/mtd0".

NICHT MACHEN!!!!!!

nandtest testet wohl den NAND Flashspeicher indem es Daten schreibt und 
liest. Das ist mir erst aufgefallen als ich "Writing..." und 
"Reading..." im schnellen Wechsel nach dem Ausführen des Programmes las. 
Dies' hab ich natürlich direkt mit CTRL-C abgebrochen.

Zum Glück hatte ich noch die Dumps von Jens' Script. Und konnte so 
prüfen was alles kaputt war. Habe die md5-Summen verglichen mit einem 
erneuten dump. mtd1 bis mtd4 hatten Unterschiede.

Ruhig bleiben und hoffen, dass kein Stromausfall kommt :)

Ich habe mich erstmal an mtd3 versucht, da dort "nur" das uboot 
environment drin steht.

~ # /i-data/md0/admin/debianroot/usr/sbin/flashcp -v /i-data/md0/admin/mtd3.backup.oob /dev/mtd3 
/i-data/md0/admin/mtd3.backup.oob won't fit into /dev/mtd3!

Hmm mal die "mtd3.backup" nehmen, die ist etwas kleiner:

~ # /i-data/md0/admin/debianroot/usr/sbin/flashcp -v /i-data/md0/admin/mtd3.backup /dev/mtd3 
Erasing blocks: 4/4 (100%)
Writing data: 512k/0k (100%)
Verifying data: 512k/0k (100%)

Das sieht doch gut aus. Dump von /dev/mtd3 gemacht und md5sum mit alten 
dump verglichen. Übereinstimmung!

Okay mtd1:

~ # /i-data/md0/admin/debianroot/usr/sbin/flashcp -v /i-data/md0/admin/mtd1.backup /dev/mtd1
Erasing blocks: 2/2 (100%)
Writing data: 256k/0k (100%)
Verifying data: 256k/0k (100%)

md5sums überprüfen: Übereinstimmung!

Okay mtd2:

~ # /i-data/md0/admin/debianroot/usr/sbin/flashcp -v /i-data/md0/admin/mtd2.backup /dev/mtd2
Erasing blocks: 16/28 (57%)
While erasing blocks 0x001e0000-0x00200000 on /dev/mtd2: Input/output error

Mist, da stimmt was nicht.

Nagut erstmal mtd4:

~ # /i-data/md0/admin/debianroot/usr/sbin/flashcp -v /i-data/md0/admin/mtd4.back
up /dev/mtd4
Erasing blocks: 80/80 (100%)
Writing data: 10240k/0k (100%)
Verifying data: 10240k/0k (100%)

Übereinstimmung!

So jetzt zurück zu mtd3:
Ein bischen Google angeworfen und folgendes gefunden:

http://lists.infradead.org/pipermail/linux-mtd/2010-March/029312.html

Ok, flash_eraseall und nandwrite nutzen:

~ # flash_eraseall /dev/mtd2 
Erasing 128 Kibyte @ 1c0000 -- 50 % complete.
Skipping bad block at 0x001e0000
Erasing 128 Kibyte @ 360000 -- 96 % complete.

So so, ein bad block... Wie in der gefunden Mail gesagt... ok, 
nandwrite:

~ # /i-data/md0/admin/debianroot/usr/sbin/nandwrite /dev/mtd2 /i-data/md0/admin/mtd2.backup
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Writing data to block 4 at offset 0x80000
Writing data to block 5 at offset 0xa0000
Writing data to block 6 at offset 0xc0000
Writing data to block 7 at offset 0xe0000
Writing data to block 8 at offset 0x100000
Writing data to block 9 at offset 0x120000
Writing data to block 10 at offset 0x140000
Writing data to block 11 at offset 0x160000
Writing data to block 12 at offset 0x180000
Writing data to block 13 at offset 0x1a0000
Writing data to block 14 at offset 0x1c0000
Writing data to block 15 at offset 0x1e0000
Bad block at 1e0000, 1 block(s) from 1e0000 will be skipped
Writing data to block 16 at offset 0x200000
Writing data to block 17 at offset 0x220000
Writing data to block 18 at offset 0x240000
Writing data to block 19 at offset 0x260000
Writing data to block 20 at offset 0x280000
Writing data to block 21 at offset 0x2a0000
Writing data to block 22 at offset 0x2c0000
Writing data to block 23 at offset 0x2e0000
Writing data to block 24 at offset 0x300000
Writing data to block 25 at offset 0x320000
Writing data to block 26 at offset 0x340000
Writing data to block 27 at offset 0x360000
Data was only partially written due to error
: Success

Der bad block wurde übersprungen... Hoffentlich reichts.

Dump gemacht, verglichen, BINGO!

Scheint alles wieder in Ordnung zu seien.

Jetzt wo ich alles festgehalten habe. Kann ich die Box mal neustarten 
und hoffen, dass die wieder hochkommt.

Bis zu nächsten Beitrag... **daumendrück**

[Michael K. (michaelkebe)]

Yeah, die Box lebt noch! Also ich hoffe wir haben jetzt was daraus 
gelernt und mein Zittern war nicht umsonst. Ich hoffe wir können bald 
ein neues U-Boot oder nen neuen Kernel flashen!

Das flashen von mir war aber relativ einfach, da die größen identisch 
waren. Spielt die Größe überhaupt eine Rolle? Oder ist bei jeder mtd 
Partition noch genug Platz? Wer kennt sich da genauer aus?

[Dirk S. (disa)]

Habe mir hdparm mal die Konfiguration der Harddisk ausgelesen:
...
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:   16514064
        LBA    user addressable sectors:  268435455
        LBA48  user addressable sectors: 2930277168
        Logical  Sector size:                   512 bytes (*)
        Physical Sector size:                  4096 bytes (*)
        Logical Sector-0 offset:                  0 bytes
        device size with M = 1024*1024:     1430799 MBytes
        device size with M = 1000*1000:     1500301 MBytes (1500 GB)
        cache/buffer size  = unknown
        Nominal Media Rotation Rate: 5900
...

Könnte hier der Schlüssel zu den Performanceproblemen liegen?
Logical-Sectorsize 512 Byte, Pysical Sectorsize 4096 Byte, wenn hier die 
Verwaltungsstrukturen an den falschen Stellen liegen könnte ich mir 
schon vorstellen, dass es Probleme gibt. Deshalb kommt man selbst beim 
lokalen Schreiben wohl auch nicht über die 18-20MB/sec. Lesen mit 
>=85MB/sec ist ja eigentlich ganz in Ordnung.

[Dirk S. (disa)]

Michael Kebe schrieb:
> Das flashen von mir war aber relativ einfach, da die größen identisch
> waren. Spielt die Größe überhaupt eine Rolle? Oder ist bei jeder mtd
> Partition noch genug Platz? Wer kennt sich da genauer aus?

Die Größe der Partitionen bekommt man ja über /proc/mtd:
dev:    size   erasesize  name
mtd0: 08000000 00020000 "NAND 128MiB 3,3V 8-bit"
mtd1: 00040000 00020000 "stage1"
mtd2: 00380000 00020000 "uboot"
mtd3: 00080000 00020000 "uboot_env"
mtd4: 00a00000 00020000 "kernel"
mtd5: 00a00000 00020000 "etc"
mtd6: 00a00000 00020000 "info"
mtd7: 05dc0000 00020000 "sysdisk"

Wenn ich das richtig verstehe, ist
uboot, also mtd2 3,5 MB groß
uboot_env, also mtd3 512kb groß
und es wird in 128kb Einheiten geflashed.

[Paul (Gast)]

Harry schrieb:
> Hallo zusammen,
>
> ich habe ein anderes Problem mit dem Medion NAS. Wenn ich meine Daten
> mit robocopy [quelle] [ziel] /MIR /DCOPY:T auf den NAS kopiere werden
> die Dateien zunächst mit dem richtigen Datum angelegt. Kurze Zeit später
> wird das Datum von einzelnen Dateien bzw. Ordner auf das aktuelle Datum
> gesetzt.

Hallo,

habe exakt das gleiche Problem. Hat jemand bereits eine Lösung gefunden 
?

[Andy (Gast)]

Servus - verfolge den Thread mit steigender Begeisterung, auch wenn ich 
nur in Ansätzen folgen kann.
Meine Frage ist eine simple: kann man (inzwischen) den ftp-Zugang auf 
ein Verzeichnis oder eine Freigabe beschränken?
Wenn ja - wie?

vielen Dank!

[Franz (Gast)]

Oh Gott, ich habe gerade ein bisschen die Musik durchgesehen, die ich 
auf den NAS rüberkopiert habe...

bei einem ganzen Stück meiner MP3s scheint es auf den letzten 10s des 
Stücks ein Problem zu geben.

Zb ich spiel ein Stück ab, dass 3:13 dauert, bei ca 3:03 oder so skipped 
es schon zum nächsten lied (die Datei selber dürfte was haben, der 
Fehler tritt auf, egal ob per iTunes, VLC oder am Android Handy (Stock 
Player und Winamp) - die Datei am PC weißt das Problem nicht auf)

Woran kann das liegen?
Kann das ein Problem meines Switches sein? (D-Link DGS-1005D/E)
Oder hat der NAS etwas?
Ich muss noch meine ganze Sammlung durchsehen (gottseidank eh 
überschaubar) - aber das kann es doch nicht sein, oder?
Wie kann da was beim Übertragen beschädigt werden?

[Franz (Gast)]

Bitte verzeiht mir den Doppelpost (kann meinen vorherigen Post nicht 
editieren)

Bilder sind ebenfalls teilweise (eigentlich zu einem überwiegenden Teil) 
beschädigt.

Woran kann soetwas liegen?

[Christian (Gast)]

Franz schrieb:
> Bilder sind ebenfalls teilweise (eigentlich zu einem überwiegenden Teil)
> beschädigt.
>
> Woran kann soetwas liegen?

@Franz: Hast du zufällig Windows 7 und den Avast Antivir? Probier doch 
mal probehalber den Virenscanner abzuschalten und kopiere dann deine 
Dateien nochmals auf das NAS. Manche (auch ich) haben wohl ein Problem 
mit der oben genannten Kombination und dem Medion NAS.

ElektromAn schrieb:
> @all, wegen FS Fehler, Virenscanner und Co.
> ich habe gesehen das die FS (XFS) für die Paltte mit nobarrier
> gemountet werden.
> Bitte mal die FS mitmount -o remount,barrier
> re-mounten.
Einen Versuch war es wert, hat aber leider nichts gebracht.

[Franz (Gast)]

ich habe win7, ja, aber nicht avast

ich bin beim googlen darauf gestoßen, dass jemand bei einem anderen NAS 
ein ähnliches problem hatte und darauf auf Filezilla umgestiegen ist

ich habe bisher die datein per windos explorer verschoben/kopiert - 
könnte es daran liegen?

testweise habe ich jetzt vorhin mit filezilla einen ordner musik (wo 
vorher 2 korrumpierte files drin waren) und einen foto ordner (mit fast 
der hälfte korrumpierter files) auf den NAS kopiert - beide fehlerfrei

ich muss es jetzt noch mit großen datenmengen testen - ich will nichts 
verschreien, aber ich hoffe, dass die dann ebenfalls fehlerfrei 
übertragen werden

aber kann das sein, dass das an Windows liegt eventuell?
ist der windows explorer eher schlecht geeignet um sachen auf den NAS zu 
verschieben?

geht Medion davon aus, dass jeder weiß was ein FTP Client ist und dass 
jeder einen benützt?

langsam ärgere ich mich über Medion :(

und danke für eure Hilfe :)

@ Markus
ich werde die Tage ebenfalls eine mail an medion schicken - oder 
zumindest anrufen
ich hoffe es rufen noch mehr an und beschweren sich, vielleicht schiebt 
Medion dann eine gscheite Firmware nach - wünschenswert wäre es xD

[Ge A. (tonreg)]

Ich habe dieses Problem ebenfalls und zwar mit dem G-DATA Virenscanner, 
meines Wissens haben alle Virenscanner ähnliche engines, dass es also 
nicht vom Virenscanner Hersteller abhängig ist. Wie in einem Beitrag 
weiter oben bereits berichtet, Virenscanner für das Heimnetz abschalten. 
Bei mir hat das jedenfalls 100% funktioniert. Ich gehe davon aus, dass 
Medion noch erheblich Probleme bekommt, wenn sie dieses Problem nicht 
schnellstens lösen. Auch ich habe bereits gestern eine Mail an Medion 
geschickt.

[Rainer (Gast)]

Rainer schrieb:
> Hat jemand eine Idee ob und wenn ja wie flexget auf dem NAS
> installierbar ist? python wäre vorhanden, auch wenn's ne andere Version
> ist...
> http://flexget.com/

Ich möchte hier keinen nerven, aber muss nochmal das Thema mit Flexget 
hochbringen und es noch etwas schmackhafter machen, vielleicht erbarmt 
sich jemand das auf dem NAS zu compilieren. Dann könnte ich das Ding mal 
in den Keller stellen :-)

FlexGet is a multipurpose automation tool for content like torrents, nzbs, podcasts, 
comics, series, movies, etc. FlexGet is able to handle different kinds of sources like 
RSS-feeds, html pages and csv files. There are even some plugins for sites that do not 
provide any kind of useful feeds.

Vorhanden ist es bereits für

    OpenWrt
    Plugbox
    QNAP NAS
    ReadyNAS
    SynologyNAS
    Buffalo Linkstation

Die Sourcen sind hier: http://flexget.com/browser?order=name

[BillX (Gast)]

Wann versteht der ein oder andere endlich das es kein Fehler von medion 
sein wir sondern von euren drecks os oder virenscanner herstellern ? ich 
wette da werden irgendwelche puffer nicht richtig geleert oder so nen 
bullshit.... da kann das nas nix für wenns die daten garnicht erst 
bekommt.

[Christian (Gast)]

BillX schrieb:
> Wann versteht der ein oder andere endlich das es kein Fehler von medion
> sein wir sondern von euren drecks os oder virenscanner herstellern ?

Ist nicht gänzlich auszuschließen, aber hast du dafür einen Beweis der 
es rechtfertigen würde hier so ausfallend zu werden? Es hat bisher noch 
niemand mit einem anderen NAS oder auch selbst aufgesetzten 
Samba-Servern ein ähnliches Problem. Das ist zumindest ein kleines 
Indiz.

[SP()()KY (Gast)]

BillX schrieb:
> Wann versteht der ein oder andere endlich das es kein Fehler von medion
> sein wir sondern von euren drecks os oder virenscanner herstellern ? ich
> wette da werden irgendwelche puffer nicht richtig geleert oder so nen
> bullshit.... da kann das nas nix für wenns die daten garnicht erst
> bekommt.

da die NAS in einen Preissegment vertrieben wird welches überwiegend 
"Nutzer" anspricht, kann ich diese deine Wertung und Bewertung nicht 
nachvollziehen...

[SP()()KY (Gast)]

Ge Ai schrieb:
> Ich habe dieses Problem ebenfalls und zwar mit dem G-DATA Virenscanner,
> meines Wissens haben alle Virenscanner ähnliche engines, dass es also
> nicht vom Virenscanner Hersteller abhängig ist. Wie in einem Beitrag
> weiter oben bereits berichtet, Virenscanner für das Heimnetz abschalten.
> Bei mir hat das jedenfalls 100% funktioniert. Ich gehe davon aus, dass
> Medion noch erheblich Probleme bekommt, wenn sie dieses Problem nicht
> schnellstens lösen. Auch ich habe bereits gestern eine Mail an Medion
> geschickt.

das deaktivieren der Antivir Laufwerksüberwachung war in der tat die 
schnellste variante, ausserdem wurden die kopiervorgänge deutlich 
schneller abgearbeitet :) (Schreibgeschwindigkeit zw. 3 - 8 MB/s , bei 
einer Filegrösse von 3-8 MB)

[Franz (Gast)]

wie kann das AV programm da so negative auswirkungen haben?
da müssen doch viele so ein problem haben

wie kann man bei G-Data eigentlich ausstellen, dass es den Verkehr zum 
NAS nicht scanned? weil die funktion für alle (usb)laufwerke zu 
deaktivieren halte ich für gefährlich

und warum funktioniert es über filezilla, aber nicht über den windows 
explorer?

[Michael K. (michaelkebe)]

Jens D.:

Ich habe im Keller noch ein USB-to-Serial Adapter gefunden. Linux meldet 
mir beim einstecken:

[ 1103.720251] usb 2-1: new full speed USB device using ohci_hcd and address 2
[ 1104.475549] usbcore: registered new interface driver usbserial
[ 1104.475590] USB Serial support registered for generic
[ 1104.484851] usbcore: registered new interface driver usbserial_generic
[ 1104.484867] usbserial: USB Serial Driver core
[ 1104.520951] USB Serial support registered for pl2303
[ 1104.522737] pl2303 2-1:1.0: pl2303 converter detected
[ 1104.598466] usb 2-1: pl2303 converter now attached to ttyUSB0
[ 1104.600770] usbcore: registered new interface driver pl2303
[ 1104.600784] pl2303: Prolific PL2303 USB to serial adaptor driver

Jetzt muss ich doch nur noch dafür sorgen, dass ich GND, TX und RX 
richtig anschliesse und schon hab ich die Verbindung oder?

TX vom PC -> RX vom NAS
RX vom PC -> TX vom NAS

Beim 9-poligen Stecker die Pins
3(TX), 2(RX) und 5(GND)
und beim 25-poligen die Pins
2(TX), 3(RX), 7(GND).

Kann ich da was kaputt machen? Fehlt da noch so ein Levelconverter?

[Ge A. (tonreg)]

Hauptfenster von G-Data öffnen. Dann bei Virenprüfung "Optionen", 
"Wächter" , "Erweiert" und dann im nächsten Fenster den Haken aus 
"Netzwerkzugriffe" entfernen. Laut Beschreibung ist dies bei 
Heimnetzwerken nicht erforderlich.

[Jens D. (jedie)]

Michael Kebe schrieb:
> Kann ich da was kaputt machen? Fehlt da noch so ein Levelconverter?

Ne, ich hab auch rumprobiert um die Belegung heraus zu bekommen. Die 
Belegung des Kabels, hier: 
http://www.mikrocontroller.net/articles/UART_auf_USB (bzw. die Links zu 
pinouts.ru)

Die Belegung der Box und Info's hier: 
http://www.mikrocontroller.net/articles/P89626/UART

[Franz (Gast)]

cool danke

und kann ich da auch nur den NAS als ausnahme definieren? (bei 
"ausnahmen" die netzwerkadresse des nas angeben)
weil zb bin ich mit meinem netbook auch viel unterwegs - zuhause brauch 
ich ja die prüfung für den NAS nicht, unterwegs ist es aber durchaus 
praktisch einen automatischen scan laufen zu haben

und G-Data ist "sicher" der verursacher für die korruption der dateien?

[Jens D. (jedie)]

Michael Kebe schrieb:
> Hier nochmal eine die ohne Änderungen an den Quellen gemacht wurde.
>
> http://dl.dropbox.com/u/4081494/p89626/u-boot/u-boot.bin.untouched

Hab ich nun ausprobiert. Läuft schon mal:

$ go 0x61000000
## Starting application at 0x61000000 ...


U-Boot 1.1.2 (Dec  9 2011 - 22:13:39)
...

Übrigends geht es nicht mit bootm:

$ bootm 0x61000000
## Booting image at 61000000 ...
Bad Magic Number

Netconsole ist aber anscheinend nicht dabei:

$ ncip $serverip
Unknown command 'ncip' - try 'help'
$ ?
?       - alias for 'help'
base    - print or set address offset
bdinfo  - print Board Info structure
bootm   - boot application image from memory
bootp   - boot image via network using BootP/TFTP protocol
cmp     - memory compare
cp      - memory copy
crc32   - checksum calculation
echo    - echo args to console
exit    - exit script
go      - start application at address 'addr'
help    - print online help
iminfo  - print header information for application image
ledfail - Extinguish (0) or light (1) failure LED
loop    - infinite loop on address range
md      - memory display
mm      - memory modify (auto-incrementing)
mtest   - simple RAM test
mw      - memory write (fill)
nand    - NAND sub-system
nboot   - boot from NAND device
nm      - memory modify (constant address)
nwboot          - NAND Write boot information
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
version - print monitor version

Kann jemand, der einen crosscompiler am laufen hat, 
reloaded-2.6.31.14_SMP_820.ko erstellen??? Siehe: 
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"


btw. kann noch jemand die Wiki Seite zu P89626 nicht mehr editieren? 
Dann mal bei 
Beitrag "Re: Wiki Seite nicht mehr editierbar?" melden! 
Ich bin wieder beim speichern in einer "endlosschleife"...

[Michael K. (michaelkebe)]

Jens D. schrieb:
> Übrigends geht es nicht mit bootm:
>

$ bootm 0x61000000
> ## Booting image at 61000000 ...
> Bad Magic Number
>

bootm ist wohl nur zum Starten von Linux Kerneln. go für sogenannte 
"standalone applications".
Siehe http://www.denx.de/wiki/DULG/UBootCmdGroupExec

[Lucian M. (lucian_m)]

Jens D. schrieb:
> Kann jemand, der einen crosscompiler am laufen hat,
> reloaded-2.6.31.14_SMP_820.ko erstellen??? Siehe:
> Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"

Ich habe da so ein Modul erstellt, musste aber wenn ich das richtig 
verstehe, etwa 2 Sourcen passend zur Platform und CPU aus dem 
Medion-Kernel nehmen, ob es die richtigen sind weiß ich nichjt, 
kompilieren tut es, aber mit Warnings über undefinierten Symbolen:

htpc2 reloaded-oxnas # ./build --root /usr/armv6j-unknown-linux-gnueabi
make: Entering directory `/mnt/other/xtra-tmp/Medion-NAS/_build_kernel/linux-2.6.31.14'
  CC [M]  /mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/main.o
  AS [M]  /mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/reboot.o
  AS [M]  /mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/proc-v6.o
  CC [M]  /mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/arm-mmu.o
  LD [M]  /mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/reloaded.o
  Building modules, stage 2.
  MODPOST 1 modules
WARNING: "init_mm" [/mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/reloaded.ko] undefined!
WARNING: "local_v6_flush_kern_cache_all" [/mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/reloaded.ko] undefined!
WARNING: "v6wbi_tlb_fns" [/mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/reloaded.ko] undefined!
WARNING: "sys_open" [/mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/reloaded.ko] undefined!
WARNING: "v6_cache_fns" [/mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/reloaded.ko] undefined!
WARNING: "v6_user_fns" [/mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/reloaded.ko] undefined!
WARNING: "sys_read" [/mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/reloaded.ko] undefined!
WARNING: "v6_early_abort" [/mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/reloaded.ko] undefined!
WARNING: "pabort_noifar" [/mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/reloaded.ko] undefined!
  CC      /mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/reloaded.mod.o
  LD [M]  /mnt/other/xtra-tmp/Medion-NAS/reload/reloaded-oxnas/reloaded.ko
make: Leaving directory `/mnt/other/xtra-tmp/Medion-NAS/_build_kernel/linux-2.6.31.14'

Habe es nicht probiert, da ich derzeit keinen UART-Zugang habe. Auch den 
Kernel habe ich neu gebaut, mit leicht veränderter Konfiguration, also 
falls man den mal booten könnte, von mir aus über tftp, sollte er seine 
Konfiguration in /proc/config.gz exportieren, und ich habe CPU_HOTPLUG 
aktivierte, vielleicht ist deswegen der 2. Kern inaktiv?.

Jens, willst Du da mal was probieren, zum einen den Kernel ohn reloaded, 
und dann auch das reloaded-Modul? 
http://www.muresan.de/medion-nas/kernel+mods+reloaded.tar.bz2

[Jens D. (jedie)]

Lucian M. schrieb:
> Habe es nicht probiert, da ich derzeit keinen UART-Zugang habe.

Kannst du doch auch im laufenden System testen. Must allerdings dafür 
sorgen das Telnet wieder hochkommt. Ansonsten reboot.


Scheint aber nicht zu laufen:

insmod: error inserting '/reloaded/reloaded-2.6.31.14_SMP_820.ko': -1 Unknown symbol in module
reloading failed!

Auf stderr (per UART):

reloaded: Unknown symbol pabort_noifar
reloaded: Unknown symbol v6_early_abort
reloaded: Unknown symbol sys_read
reloaded: Unknown symbol v6_user_fns
reloaded: Unknown symbol v6_cache_fns
reloaded: Unknown symbol sys_open
reloaded: Unknown symbol v6wbi_tlb_fns
reloaded: Unknown symbol local_v6_flush_kern_cache_all
reloaded: Unknown symbol init_mm

[Lucian M. (lucian_m)]

Jens D. schrieb:
> Kannst du doch auch im laufenden System testen. Must allerdings dafür
> sorgen das Telnet wieder hochkommt. Ansonsten reboot.

Ja, klar, bloss ich war fast sicher dass es wegen diesen unknown symbols 
nicht klappen wird, ausserdem brauche ich physikalischen Zugang zur Box 
um sie aus gecrashtem Zustand neu booten zu können, an die WebGUI komme 
ich dann schon auch remote ran um den Telnet daemon zu starten...


Kannst Du mal bitte auch nur den Kernel probieren, direkt von uBoot aus? 
Falls er booten sollte, wäre mal interssant ob er den 2ten Core 
hochbringt...

[Jens D. (jedie)]

Sehr gute Idee!

kommt hoch:

Bytes transferred = 3324972 (32bc2c hex)
$ bootm 0x61000000
## Booting image at 61000000 ...
   Image Name:   Linux-2.6.31.14_SMP_820
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3324908 Bytes =  3.2 MB
   Load Address: 60008000
   Entry Point:  60008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux.................................................................................................................................................................................................. done, booting the kernel.
Linux version 2.6.31.14_SMP_820 (root@htpc2) (gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) ) #2 SMP Sat Dec 10 18:57:42 CET 2011
CPU: ARMv6-compatible processor [410fb025] revision 5 (ARMv7), cr=00c5387f
...

aber:

Brought up 1 CPUs
SMP: Total of 1 processors activated (299.00 BogoMIPS).

Hab an den boorargs nichts geändert, deswegen wohl dann das:

Please append a correct "root=" boot option; here are the available partitions:
0800      1465138584 sda driver: sd
  0801          514048 sda1
  0802      1464621952 sda2
1f00          131072 mtdblock0 (driver?)
1f01             256 mtdblock1 (driver?)
1f02            3584 mtdblock2 (driver?)
1f03             512 mtdblock3 (driver?)
1f04           10240 mtdblock4 (driver?)
1f05           10240 mtdblock5 (driver?)
1f06           10240 mtdblock6 (driver?)
1f07           96000 mtdblock7 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[<c0045d3c>] (unwind_backtrace+0x0/0xe0) from [<c0489fc0>] (panic+0x44/0x100)
[<c0489fc0>] (panic+0x44/0x100) from [<c0008f44>] (mount_block_root+0x1d8/0x29c)
[<c0008f44>] (mount_block_root+0x1d8/0x29c) from [<c00092d4>] (prepare_namespace+0x168/0x1c0)
[<c00092d4>] (prepare_namespace+0x168/0x1c0) from [<c0008c1c>] (kernel_init+0x1a4/0x1ec)
[<c0008c1c>] (kernel_init+0x1a4/0x1ec) from [<c0041c20>] (kernel_thread_exit+0x0/0x8)

Ich versuche mal mein Debian vom USB Stick als root anzugeben...

[David (Gast)]

Hallo!

ich schaffs irgendwie nicht lynx oder elinks zu kompilieren...hat 
vielleicht schon jemand erfolg damit gehabt?

[Jens D. (jedie)]

Hm. Komisch meinen Stick mag er aber nicht:

Waiting 15sec before mounting root device...
usb 1-2: new high speed USB device using oxnas-ehci and address 2
usb 1-2: configuration #1 chosen from 1 choice
scsi2 : SCSI emulation for USB Mass Storage devices
scsi 2:0:0:0: Direct-Access     USB      DISK             1100 PQ: 0 ANSI: 0 CCS
sd 2:0:0:0: Attached scsi generic sg1 type 0
sd 2:0:0:0: [sdb] 3917824 512-byte logical blocks: (2.00 GB/1.86 GiB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sd 2:0:0:0: [sdb] Assuming drive cache: write through
 sdb: sdb1 sdb2
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sd 2:0:0:0: [sdb] Attached SCSI removable disk
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
VFS: Cannot open root device "sdb2" or unknown-block(8,18)
Please append a correct "root=" boot option; here are the available partitions:
0800      1465138584 sda driver: sd
  0801          514048 sda1
  0802      1464621952 sda2
1f00          131072 mtdblock0 (driver?)
1f01             256 mtdblock1 (driver?)
1f02            3584 mtdblock2 (driver?)
1f03             512 mtdblock3 (driver?)
1f04           10240 mtdblock4 (driver?)
1f05           10240 mtdblock5 (driver?)
1f06           10240 mtdblock6 (driver?)
1f07           96000 mtdblock7 (driver?)
0810         1958912 sdb driver: sd
  0811           24066 sdb1
  0812         1927800 sdb2
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,18)
[<c0045d3c>] (unwind_backtrace+0x0/0xe0) from [<c0489fc0>] (panic+0x44/0x100)
[<c0489fc0>] (panic+0x44/0x100) from [<c0008f44>] (mount_block_root+0x1d8/0x29c)
[<c0008f44>] (mount_block_root+0x1d8/0x29c) from [<c00092d4>] (prepare_namespace+0x168/0x1c0)
[<c00092d4>] (prepare_namespace+0x168/0x1c0) from [<c0008c1c>] (kernel_init+0x1a4/0x1ec)
[<c0008c1c>] (kernel_init+0x1a4/0x1ec) from [<c0041c20>] (kernel_thread_exit+0x0/0x8)

btw. ein wenig Dumm: Mit dem reset Knopf bekommt man die Box nicht 
wieder! Ich sehe zwar Meldungen das der Reset Knopf gedrück wurde (per 
UART) aber er macht keinen reboot.

Wenn ich die Kiste normal hochfahren lasse, sieht das so aus:

/ # fdisk /dev/sdb -l

Disk /dev/sdb: 2005 MB, 2005925888 bytes
255 heads, 63 sectors/track, 243 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1           3       24066    6  FAT16
/dev/sdb2               4         243     1927800   83  Linux
/ # mount
...
/dev/sdb2 on /e-data/c64017f9-b19d-45ff-b6ea-9e13d18f1f81 type ext4 (rw,relatime,barrier=1,data=ordered)
...
/ # ls -ls /e-data/c64017f9-b19d-45ff-b6ea-9e13d18f1f81/
   4 drwxr-xr-x    2 root     root          4096 Dec  7 12:13 bin
   4 drwxr-xr-x    2 root     root          4096 Dec  7 12:16 boot
 220 -rwxrwxrwx    1 admin    everyone    225280 Dec  7 08:59 data.tar
   4 -rwxrwxrwx    1 admin    everyone       439 Dec  8 12:36 debian_bootstrap.sh
   4 -rwxrwxrwx    1 admin    everyone      1234 Dec  9 13:35 debian_bootstrap2.sh
   4 -rwxrwxrwx    1 admin    everyone       882 Dec 12 10:15 debian_chroot.sh
   4 drwxr-xr-x    2 root     root          4096 Jan  1  1970 dev
   4 drwxr-xr-x   57 root     root          4096 Dec 12 10:15 etc
   4 drwxr-xr-x    2 root     root          4096 Oct  3 02:53 home
  80 -rw-r--r--    1 root     root         80774 Dec  8 13:09 hwinfo.txt
   4 drwxr-xr-x    2 root     root          4096 Dec  8 11:44 i-data
   0 lrwxrwxrwx    1 root     root            33 Dec  9 16:52 initrd.img -> boot/initrd.img-2.6.32-5-kirkwood
   4 drwxr-xr-x   10 root     root          4096 Dec  8 13:07 lib
  16 drwx------    2 root     root         16384 Dec  9 12:38 lost+found
   4 drwxr-xr-x    2 root     root          4096 Dec  9 16:57 media
   4 drwxr-xr-x    2 root     root          4096 Oct  3 02:53 mnt
   4 drwxr-xr-x    2 root     root          4096 Dec  7 10:27 opt
   4 drwxr-xr-x    2 root     root          4096 Oct  3 02:53 proc
   4 -rwxrwxrwx    1 admin    everyone      1062 Dec 12 10:32 reload.sh
   4 drwxr-xr-x    3 root     root          4096 Dec 12 10:33 reloaded
   4 drwx------    5 root     root          4096 Dec  9 12:50 root
   4 drwxr-xr-x    2 root     root          4096 Dec  7 10:45 sbin
   4 drwxr-xr-x    2 root     root          4096 Jul 21  2010 selinux
   4 drwxr-xr-x    2 root     root          4096 Dec  7 10:27 srv
   4 drwxr-xr-x    2 root     root          4096 Jan  1  2011 sys
   4 drwxrwxrwt    3 root     root          4096 Dec  9 12:57 tmp
   4 drwxr-xr-x   10 root     root          4096 Dec  7 10:27 usr
   4 drwxr-xr-x   13 root     root          4096 Dec  7 10:27 var
   0 lrwxrwxrwx    1 root     root            30 Dec  9 16:48 vmlinuz -> boot/vmlinuz-2.6.32-5-kirkwood

Ich gebe mal "rootfstype=ext4" an.

[Jens D. (jedie)]

Jens D. schrieb:
> Ich gebe mal "rootfstype=ext4" an.

Ist das selbe :(

[Lucian M. (lucian_m)]

Jens D. schrieb:
> md: Waiting for all devices to be available before autodetect
> md: If you don't use raid, use raid=noautodetect

Hmm, probierst Du auch mal das mit raid=noautodetect? Und überhaupt, 
wenn Du ihm dann als root /dev/sda2 (also die Riesen XFS-Partitition der 
internen Festplatte) aber auch so mit deaktiviertem RAID angeben 
würdest, versucht er zumindest, dort nach einem root zu suchen? Wenn ja, 
könnte es vielleicht klappen wenn Du Dein rootfs vom Stick auf eben 
diese Partition parallel zu den originalen public|video|music|photo 
shares kopierst (kannst es ja hinterher immer noch löschen)

[Jens D. (jedie)]

Lucian M. schrieb:
> Hmm, probierst Du auch mal das mit raid=noautodetect?

Hab ich probiert. Ist das selbe.

Ich wollte auch mal selber ein Kernel/Ramdisk Image bauen und testen... 
Funktioniert aber nicht so richtig.

Erstellt hab ich es im chroot debian so:

root@NAS15TB:/# mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n "Debian Kernel" -d /boot/vmlinuz-2.6.32-5-kirkwood uImage-2.6.32-5-kirkwood
Image Name:   Debian Kernel
Created:      Mon Dec 12 11:22:46 2011
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    1435664 Bytes = 1402.02 kB = 1.37 MB
Load Address: 0x00008000
Entry Point:  0x00008000
root@NAS15TB:/# mkimage -A arm -O linux -T ramdisk -C gzip -a 0x0000000 -e 0x0000000 -n "Debian Ramdisk" -d /boot/initrd.img-2.6.32-5-kirkwood uInitrd-2.6.32-5-kirkwood
Image Name:   Debian Ramdisk
Created:      Mon Dec 12 11:22:55 2011
Image Type:   ARM Linux RAMDisk Image (gzip compressed)
Data Size:    5476879 Bytes = 5348.51 kB = 5.22 MB
Load Address: 0x00000000
Entry Point:  0x00000000

Das laden per TFTP will aber nicht:

Filename 'uImage-2.6.32-5-kirkwood'.
Load address: 0x61000000
Loading: T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T 
Retry count exceeded; starting again

[Lucian M. (lucian_m)]

Naja da passen schonmal load address nicht zusammen

[Jens D. (jedie)]

Lucian M. schrieb:
> Naja da passen schonmal load address nicht zusammen

Ja, ich verstehe sowieso nicht, was die alle zu bedeuten haben ;)

Welches sind denn die Richtigen?

Lucian M. schrieb:
> Und überhaupt,
> wenn Du ihm dann als root /dev/sda2 (also die Riesen XFS-Partitition der
> internen Festplatte) aber auch so mit deaktiviertem RAID angeben
> würdest, versucht er zumindest, dort nach einem root zu suchen? Wenn ja,
> könnte es vielleicht klappen wenn Du Dein rootfs vom Stick auf eben
> diese Partition parallel zu den originalen public|video|music|photo
> shares kopierst (kannst es ja hinterher immer noch löschen)

Hm. Wohin genau kopieren? Nach /i-data/6764ac2f/ ?

[Lucian M. (lucian_m)]

Jens D. schrieb:
>> Naja da passen schonmal load address nicht zusammen
> Ja, ich verstehe sowieso nicht, was die alle zu bedeuten haben ;)
> Welches sind denn die Richtigen?

Na Du lädst ja mit uBoot den Kernel an eine explizit angegebene oder im 
uBoot Environment festgelegte Addresse, und die ist nun mal 0x61000000 
wenn ich mich nicht irre, aber mit mkimage hast Du ja Deinen Debian 
Kernel so verpackt, daß es 0x00008000 will, das meinte ich damit (ist 
wohl von einer anderen Platform, der Marvell Kirkwood)...

> Lucian M. schrieb:
>> Und überhaupt,
>> wenn Du ihm dann als root /dev/sda2 (also die Riesen XFS-Partitition der
>> internen Festplatte) aber auch so mit deaktiviertem RAID angeben
>> würdest, versucht er zumindest, dort nach einem root zu suchen? Wenn ja,
>> könnte es vielleicht klappen wenn Du Dein rootfs vom Stick auf eben
>> diese Partition parallel zu den originalen public|video|music|photo
>> shares kopierst (kannst es ja hinterher immer noch löschen)
>
> Hm. Wohin genau kopieren? Nach /i-data/6764ac2f/ ?

Ja, ich bin der Meinung das ist letztendlich /dev/sda2, auch wenn die 
aktuelle Firmware das alles über raid und was weiß ich was noch 
verschleiert.

[Jens D. (jedie)]

Ist alles IMHO das selbe:

md: Skipping autodetection of RAID arrays. (raid=autodetect will force)
VFS: Cannot open root device "sda2" or unknown-block(8,2)
Please append a correct "root=" boot option; here are the available partitions:
0800      1465138584 sda driver: sd
  0801          514048 sda1
  0802      1464621952 sda2
1f00          131072 mtdblock0 (driver?)
1f01             256 mtdblock1 (driver?)
1f02            3584 mtdblock2 (driver?)
1f03             512 mtdblock3 (driver?)
1f04           10240 mtdblock4 (driver?)
1f05           10240 mtdblock5 (driver?)
1f06           10240 mtdblock6 (driver?)
1f07           96000 mtdblock7 (driver?)
0810         1958912 sdb driver: sd
  0811           24066 sdb1
  0812         1927800 sdb2
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,2)
[<c0045d3c>] (unwind_backtrace+0x0/0xe0) from [<c0489fc0>] (panic+0x44/0x100)
[<c0489fc0>] (panic+0x44/0x100) from [<c0008f44>] (mount_block_root+0x1d8/0x29c)
[<c0008f44>] (mount_block_root+0x1d8/0x29c) from [<c00092d4>] (prepare_namespace+0x168/0x1c0)
[<c00092d4>] (prepare_namespace+0x168/0x1c0) from [<c0008c1c>] (kernel_init+0x1a4/0x1ec)
[<c0008c1c>] (kernel_init+0x1a4/0x1ec) from [<c0041c20>] (kernel_thread_exit+0x0/0x8)

Eigentlich soll ja die Hardware die selbe sein wie beim Pogoplug Pro, 
oder?
Auf dem soll ArchLinux, Debian und Fedora laufen, siehe:
http://forum.doozan.com/read.php?3,6336
https://lists.fedoraproject.org/pipermail/arm/2011-July/001622.html
http://archlinuxarm.org/forum/viewtopic.php?f=29&t=1730&start=20

[Ge A. (tonreg)]

G-Data oder die anderen Virenscanner sind mit Sicherheit nicht die 
Auslöser; ich habe zwei D-Link NAS Server mit G-Data seit 5 Jahren ohne 
Probleme am Laufen, mit G-DATA! Es geht offensichtlich um das 
"Zusammenspiel" Medion NAS und Virenscanner.

[Jens D. (jedie)]

Lucian M. schrieb:
> Na Du lädst ja mit uBoot den Kernel an eine explizit angegebene oder im
> uBoot Environment festgelegte Addresse, und die ist nun mal 0x61000000
> wenn ich mich nicht irre, aber mit mkimage hast Du ja Deinen Debian
> Kernel so verpackt, daß es 0x00008000 will, das meinte ich damit (ist
> wohl von einer anderen Platform, der Marvell Kirkwood)...

OK, aber wie können diese beiden Zeilen dann aussehen:

mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n "Debian Kernel" -d /boot/vmlinuz-2.6.32-5-kirkwood uImage-2.6.32-5-kirkwood
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x0000000 -e 0x0000000 -n "Debian Ramdisk" -d /boot/initrd.img-2.6.32-5-kirkwood uInitrd-2.6.32-5-kirkwood

Wie wird das eigentlich gehandhabt, wenn Sicherheitsupdates für den 
Kernel raus kommen? Dann muss doch für Otto-Normal-Verbraucher von 
Medion ein Update bereitgestellt werden und das muss ja auf der Box 
geflasht werden.
Wenn wir nun ein eigenen Kernel bauen und flashen muß auch da jedes mal 
der Kernel neu gebaut und geflash werden...
Da geht es vielleicht auf Dauer mit einem Kernel aus den Debian Quellen, 
in Verbindung mit mkimage und tftp einfacher... oder?

[Lucian M. (lucian_m)]

Jens D. schrieb:
> OK, aber wie können diese beiden Zeilen dann aussehen:mkimage -A arm -O linux -T 
kernel -C none -a 0x00008000 -e 0x00008000 -n "Debian Kernel" -d 
/boot/vmlinuz-2.6.32-5-kirkwood uImage-2.6.32-5-kirkwood

Die Medion-Sourcen generieren diese Addressen hier: -a 0x60008000 -e 
0x60008000 für den Kernel.

> mkimage -A arm -O linux -T ramdisk -C gzip -a 0x0000000 -e 0x0000000 -n "Debian 
Ramdisk" -d /boot/initrd.img-2.6.32-5-kirkwood uInitrd-2.6.32-5-kirkwood
>
> Wie wird das eigentlich gehandhabt, wenn Sicherheitsupdates für den
> Kernel raus kommen? Dann muss doch für Otto-Normal-Verbraucher von
> Medion ein Update bereitgestellt werden und das muss ja auf der Box
> geflasht werden.

So eine Update-Politik seitens der NAS-Hersteller kann vergessen werden, 
glaube ich...

> Da geht es vielleicht auf Dauer mit einem Kernel aus den Debian Quellen,
> in Verbindung mit mkimage und tftp einfacher... oder?

Wenn Debian für alle erdenklichen Plattformen die Kernels mit den 
richtigen Startaddressen, machin IDs usw. verpackt bereitstellen 
würde...