(Q:) Box ueber NFS booten, (Yadd)BootFlag

hi,
sorry wenn's nervt...aber ich komme nicht weiter ohne Eure Hilfe und Tips:
Mit dem modifizierten u-boot von Homar und laufendem SFU-NFS Server sieht das log im Moment so aus:

Code: Alles auswählen

.
.
IP-Config: Complete:
      device=eth0, addr=192.168.0.4, mask=255.255.255.0, gw=255.255.255.255,
     host=192.168.0.4, domain=, nis-domain=(none),
     bootserver=192.168.0.1, rootserver=192.168.0.1, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.0.1
Looking up port of RPC 100005/1 on 192.168.0.1
VFS: Mounted root (nfs filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 72k init
Kernel panic: No init found.  Try passing init= option to kernel.
 <0>Rebooting in 180 seconds..

ist doch schon besser, oder? Wo, wie koennte ich denn den rootpath angeben...? Wo steckt denn 'init'...ist der Kernel vielleicht nicht in Ordnung? Wenn ich mir das bootlog von rolandm unter http://forum.tuxbox-cvs.sourceforge.net ... =init+yadd anschaue, scheint mir mein log bis zu 'Kernel panic:....' gut auszusehen....bei rolandm ist der rootpath auch nicht angegeben, aber es laeuft zumindest etwas weiter und es gibt keine Kernel panic.....?

cu,
peter

PS:@Entwickler
bootet Ihr alle eine Yadd mit dem Bootmanager (unter Windows) und hab't keinen andern NFS-Server laufen? Kann das ueberhaupt ohne Aenderungen an u-boot/ppcboot funktionieren? Den Wunsch, ein beliebiges auf die Platte entpacktes Image ueber Netz zu booten, habe ich mir ja schon abgeschminkt, aber eine Yadd mit anderem NFS-Server ueber den Bootmanger zu booten, sollte doch ohne viel Aufwand machbar sein, oder geht das schon, nur ich bin zu bloed dafuer?

Beitrag von **petgun** » Montag 13. September 2004, 21:10

hi,
ich gebe auf!

cu,
peter

Beitrag von **Npq** » Montag 13. September 2004, 22:57

Ich z.B. boote nie über Windows, sondern immer über Linux, ein Server-Rechner, auf dem alles läuft, dhcpd, tftpd und NFS.

Da dir offensichtlich die ausführlichen Informationen zu viel waren hier kurz und knapp:

Die Information, woher der u-boot den Server/Rootpath weiß, ist in den u-boot einkompiliert.

Das wird in diesen Config-Dateien hier festgelegt:
http://cvs.tuxbox-cvs.sourceforge.net/c ... oot-config

Bei der CDK-Config (das ist die, wie sie beim normalen CDK gebaut wird) bekommt der U-boot die Information vom dhcpd. Das heißt, dafür muß man den dhcpd konfigurieren, wie weit das beim Bootmanager möglich ist weiß ich leider nicht. Evtl. nimmt der automatisch den PC als NFS-Server, dann könntest du dir höchstens eine passende U-Boot-Config mit fest einkompilierter IP-Adresse erstellen.

Bei der Flash-Config ist diese Information hingegen fest in den u-boot eingebaut (die Flash-Partition ändert sich ja nicht).

hi,
Danke dass Du mich an die Hand genommen hast und eine vereinfachte Erklaerung dazu geschrieben hast: Jetzt habe ich es sogar verstanden

und weiss, dass es keinen Sinn macht, weiterhin so wie bisher zu probieren....

Die Information, woher der u-boot den Server/Rootpath weiß, ist in den u-boot einkompiliert.

Das wird in diesen Config-Dateien hier festgelegt:
http://cvs.tuxbox-cvs.sourceforge.net/c ... oot-config

...ich werde versuchen den Quellcode zu lesen....

Evtl. nimmt der automatisch den PC als NFS-Server, dann könntest du dir höchstens eine passende U-Boot-Config mit fest einkompilierter IP-Adresse erstellen.

das ist doch mal eine Idee wie es weitergehen koennte....als Server/Rootpath haette ich gerne...BootpServer-IP/root....jetzt muss ich nur noch einen Entwickler finden, der mir das mal zum testen kompiliert..obwohl in der Config steht schon:

.
"nfsroot=$(serverip):$(rootpath)/yaddroot/ "
.

...also einfach mal mit einem exportierten Verzeichnis 'yaddroot' testen, oder? Wobei mir auffaellt, dass ich immer mit mehreren exportierten NFS-Verzeichnissen (zB. die fuer Streaming) getestet habe und vielleicht in dem gepatchten u-boot von Homar '../yaddroot/' fehlt...

Kann mir einer von Euch mal auf die Spruenge helfen, mein Bootlog interpretieren 'Kernel Panic....no init found' und evtl noch einen Hinweis geben ? Muss ich jetzt exklusiv ein Verzeichnis 'yaddroot' exportieren oder muss nur das yaddverzeichnis /yaddroot/ zB auf C:\ existieren wenn ich komplett C:\ als root exportiere?

also nochmals Danke,
peter

PS:Sorry, wenn's nervt, aber ich komme nicht weiter

und drehe mich im Kreis....imo funktionieren die Yadd's einfach nicht...die letzte von Homar und einige von DietmarW liefern mit dem u-boot von Homar (mit dem man ein Image ohne Nullmodemkabel flashen kann) das oben gepostete Bootlog und bleiben alle mit 'Kernel Panic:no init found' haengen

Wenn ich wenigstens die Gewissheit haette, dass die heruntergeladenen Yadd's mit dem alten ppcboot und Bootmanger wie 'frueher' funktionieren muessten....

hallo,

beutze ein aktuelles YADD (Neutrino_Enigma_LCars_yadd_Day4.tar.bz2)
ich kann es auch booten, jedoch scheint es den angegebenen rootpath zu ignorieren

dhcp.conf nach den HowTo (http://www.dietmar-h.net/linux.html) erstellt
host dbox2 {
hardware ethernet 00:50:xx:xx:xx:xx;
fixed-address dboxxxxxx
if exists vendor-class-identifier {
filename "kernel-cdk";
option root-path "/home/dbox2/cdkroot";
} else {
filename "u-boot";
}
}

Es wird jedoch immer versucht /kernel-cdkcdkroot zu mounten. (Damit funktioniert es dann auch)
Kernel command line: root=/dev/nfs rw nfsroot=xx.xx.xx.xx:/kernel-cdkcdkroot/
ip=xx.xx.xx.xx:xx.xx.xx.xx:xx.xx.xx.xx:255.255.255.224:::off console=t
tyS0

Liegt das an dem u-boot?

Hatte vorher die "yadd Head 10.February 2004, 0017.tar" probiert,
da hat er versucht u-bootcdkroot zu mounten.
Ist vielleicht doch meine config falsch?

Hi,
wie startest Du die Yadd ? Mit dem Bootmanger und dem u-boot das bei der Yadd dabei war? Damit bin ich bisher nicht ueber erfolglose bootp-requests hinaus gekommen...mit dem u-boot von Homar komme ich soweit wie hier beschrieben.

cu,
peter

so wie es aussieht laufen die yadds zur zeit nur unter linux..

Beitrag von **Npq** » Mittwoch 15. September 2004, 14:37

Achso, ich dachte das wäre angekommen. *grummel*

Der Bootmanager arbeitet nicht mit der CDK-U-boot-Konfiguration zusammen. Wie ich bereits schrieb, kennt er das nötige Protokoll nicht.

Deswegen hat AlexW extra beim U-boot ein Bootmanager-spezifisches Define eingepatcht.

Vergeßt doch einfach den Bootmanager, gibt es denn keinen vernünftigen dhcpd für Windows?

Hallo,

ich benutz Linux, es läuft ja auch, nur dass er den falschen Ordner mounten will.
Gibt es trotzdem eine Möglichkeit ihm beizubringen, dass er den Pfad aus der dhcp.conf mountet?

hi,

Npq hat geschrieben:Achso, ich dachte das wäre angekommen. *grummel*

danke, dass Du es (noch einmal) klarstellst dass es nicht unter Windows funktioniert...habe ich nicht mitbekommen/so verstanden

Der Bootmanager arbeitet nicht mit der CDK-U-boot-Konfiguration zusammen. Wie ich bereits schrieb, kennt er das nötige Protokoll nicht.

Deswegen hat AlexW extra beim U-boot ein Bootmanager-spezifisches Define eingepatcht.

...nach meiner Meinung, laeuft es doch (fast) mit dem gepatcheten u-boot von Homar und 'cdkroot' wird auch gemountet....nur 'init' wird nicht gefunden....werfe doch bitte noch mal einen Blick auf das letzte Bootlog von mir...

Vergeßt doch einfach den Bootmanager, gibt es denn keinen vernünftigen dhcpd für Windows?

..doch...zB. http://www.hanewin.de/dhcp-d.htm und viele andere, aber ich glaube nicht so ganz das es damit weiter laeuft als bis 'Kenel Panic:no init found'...

cu,
peter

Beitrag von **Npq** » Mittwoch 15. September 2004, 16:00

@studti:
du benutzt aber jetzt nicht zufällig einen für den Bootmanager angepaßten u-boot?

Mit dem CDK-U-boot (also der CDK-config) geht das so wie du es möchtest. Mit der YADD-Config wird der Patch von AlexW aktiviert, weil nämlich der Bootmanager gerade diesen vendor-class-identifier nicht auswertet.

Wenn du so einen uboot nimmst weiß ich nicht genau was dann in Verbindung mit einem "echten" dhcp passiert.

@petgun:
das Problem ist, daß der Bootmanager entworfen wurde, um auch Einsteigern a) das Flashen zu ermöglichen und b) mal eben schnell den Blick auf eine YADD werfen lassen zu können.

Field hat sicherlich nicht vorgehabt damit die Server komplett zu ersetzen. Wer mehr will muß eben die entsprechende Infrastruktur aufbauen.

Bei deinem Log fehlt die wichtige "Kernel command line:[...]"-Zeile.
Das was IP-Config da sagt wird eben gerade von der Kommandozeile überschrieben.

Hi,

Npq hat geschrieben:..das Problem ist, daß der Bootmanager entworfen wurde, um auch Einsteigern a) das Flashen zu ermöglichen und b) mal eben schnell den Blick auf eine YADD werfen lassen zu können.

Field hat sicherlich nicht vorgehabt damit die Server komplett zu ersetzen. Wer mehr will muß eben die entsprechende Infrastruktur aufbauen.

..so wie Ihr Linux User sie habt oder wenn ich zB. w2k Server mit DHCP Server haette....wuerde der Hanewin DHCP Server (fuer Privat 19 Euronen) nach Deiner Meinung dazu reichen ?

.
Die Software implementiert einen DHCP/BOOTP Server nach RFC 2131.
Neben der einfachen Zuteilung dynamischer IP-Adressen aus einem Adresspool können Klienten mit bekannter Hardwareadresse oder Identifier feste IP-Adressen und abweichende Konfigurationsparameter zugeordnet werden. Der Server enthält einen TFTP Server für downloads.

Der Server unterstützt alle DHCP/BOOTP Optionen und besitzt keine Beschränkung in der Anzahl der Klienten.
Auf Multi-homed Servern können bis zu 32 Schnittstellen bedient werden. Es kann für jede Schnittstelle ein Adresspool mit dynamischen IP-Adressen eingerichtet werden.
.

Bei deinem Log fehlt die wichtige "Kernel command line:[...]"-Zeile..

und wieso fehlt die Zeile? Sorry, ich kann mir vorstellen das ich Dich/Euch mit meinen Fragen nerve....und warte dann jetzt einfach mal ab...vielleicht kuemmert sich ja doch irgendwann ein interessierter Ahnungstraeger darum...die Eingangsidee, beliebige entpackte Images, von der Platte booten zu koennen (ohne zu flashen) finde ich immer noch gut.

Danke fuer die Antworten,
peter

Beitrag von **Npq** » Mittwoch 15. September 2004, 17:26

Zu den Eigenschaften der Windows-DHCP kann ich dir nichts sagen, habe ich mich noch nie für interessiert. Aber wenn er alle Optionen unterstützt sollte das gehen. Was definitives zu sagen bei einer Software, die ich gar nicht kenne geht schlecht.

Die Zeile fehlt im Log weil du sie nicht mit reinkopiert hast. Sie kommt direkt am Anfang des Bootvorgangs, ist also in deinem Log bei dem "..." mit drin.

Npq hat geschrieben:@studti:
du benutzt aber jetzt nicht zufällig einen für den Bootmanager angepaßten u-boot?

Mit dem CDK-U-boot (also der CDK-config) geht das so wie du es möchtest. Mit der YADD-Config wird der Patch von AlexW aktiviert, weil nämlich der Bootmanager gerade diesen vendor-class-identifier nicht auswertet.

Ich hab das YADD von update.tuxbox-cvs.sourceforge.net -> DietmarW Downloads -> Head_YADD_Neutrino_Enigma_LCars

wo bekomme ich dieses cdk-uboot her?

Hi,
hier mal zum Abschluss das komplette Bootlog vom Versuch eine aktuelle Yadd zu booten (SFU-NFS Server laeuft mit exportierter 'cdkroot')

debug: DDF: Calibrating delay loop... debug: DDF: 66.76 BogoMIPS
debug: BMon V1.0 mID 02
debug: feID 00 enxID 03
debug: fpID 52 dsID xx-xx.xx.xx.xx.xx.xx-xx
debug: HWrev 01 FPrev 0.30
debug: B/Ex/Fl(MB) 32/00/08
dbox2:root> debug:
BOOTP/TFTP bootstrap loader (v0.3)
debug:
debug: Transmitting BOOTP request via broadcast
debug: Got BOOTP reply from Server IP 192.168.0.1, My IP 192.168.0.4
debug: Sending TFTP-request for file C/dbox/tftpboot/u-boot
will verify ELF image, start= 0x800000, size= 144652
verify sig: 263
boot net: boot file has no valid signature
Branching to 0x40000

U-Boot 0.4.0 (TuxBox) (Apr 29 2004 - 00:01:49)

CPU: PPC823ZTnnB2 at 65.900 MHz: 2 kB I-Cache 1 kB D-Cache
Board: DBOX2, Philips, BMon V1.0
Watchdog enabled
I2C: ready
DRAM: 32 MB
FLASH: 8 MB
Scanning JFFS2 FS: . .
find_inode failed for name=tuxbox
load: Failed to find inode
FB: ready
LCD: ready
In: serial
Out: serial
Err: serial
Net: SCC ETHERNET
find_inode failed for name=logo-lcd
load: Failed to find inode
ready - can't find logo in flash - try network
BOOTP broadcast 1
TFTP from server 192.168.0.1; our IP address is 192.168.0.4
Filename 'logo-lcd'.
Load address: 0x100000
Loading: ##

Bytes transferred = 7680 (1e00 hex)
find_inode failed for name=logo-fb
load: Failed to find inode
can't find logo in flash - try network
BOOTP broadcast 1
TFTP from server 192.168.0.1; our IP address is 192.168.0.4
Filename 'logo-fb'.
Load address: 0x100000
Loading: ##############

Bytes transferred = 70956 (1152c hex)

Options:
1: Bootmeldungen auf Seriell (ttyS0) - standard
2: Bootmeldungen auf TV (fb0)
3: Keine Bootmeldungen
4: Flashen via YADD
- Flashimage umbennenn in dboxflash.img
- in das Verzeichniss tftpboot kopieren
- beim Bootvorgang die Taste 4 drcken.
HAVE FUN...

...special u-boot for DboxII Boot-Manager
v 0.3 overclocked - patched by Homar 2003

Select option (1-4), other keys to stop autoboot: 0
TFTP from server 192.168.0.1; our IP address is 192.168.0.4
Filename 'kernel-cdk'.
Load address: 0x100000
Loading: #################################################################
#################################################################
###################

Bytes transferred = 758817 (b9421 hex)
..............................................................
Un-Protected 62 sectors
## Booting image at 00100000 ...
Image Name: dbox2
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 758753 Bytes = 740.10 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.4.27-dbox2 (dietmarw@h5938) (gcc version 3.3.4) #1 Mi Sep 15 20:
16:42 CEST 2004
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nfs rw nfsroot=192.168.0.1:/C/dbox/cdkroot/ ip=19
2.168.0.4:192.168.0.1:::::off console=ttyS0
Decrementer Frequency = 247125000/60
m8xx_wdt: active wdt found (SWTC: 0xFFFF, SWP: 0x1)
m8xx_wdt: keep-alive trigger installed (PITC: 0x2580)
Console: colour dummy device 80x25
Calibrating delay loop... 65.53 BogoMIPS
Memory: 30572k available (1284k kernel code, 440k data, 72k init, 0k highmem)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
i2c-core.o: i2c core module version 2.6.1 (20010830)
i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
CPM UART driver version 0.04
ttyS0 at 0x0280 is on SMC1 using BRGttyS1 at 0x0380 is on SMC2 using BRG2
pty: 256 Unix98 ptys configured
eth0: CPM ENET Version 0.2.dbox2 on SCC2, xx:xx:xx:xx:xx:xx
D-Box 2 flash driver (size->0x800000 mem->0x10000000)
D-Box 2 flash memory: Found 2 x16 devices at 0x0 in 32-bit mode
Intel/Sharp Extended Query Table at 0x0035
cfi_cmdset_0001: Erase suspend on write enabled
Using word write method
Creating 6 MTD partitions on "D-Box 2 flash memory":
0x00000000-0x00020000 : "BR bootloader"
0x00020000-0x00040000 : "flfs (u-boot)"
0x00040000-0x00720000 : "root (cramfs)"
0x00720000-0x00800000 : "var (jffs2)"
0x00020000-0x00800000 : "flash without bootloader"
0x00000000-0x00800000 : "complete flash"
Linux video capture interface: v1.00
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
device=eth0, addr=192.168.0.4, mask=255.255.255.0, gw=255.255.255.255,
host=192.168.0.4, domain=, nis-domain=(none),
bootserver=192.168.0.1, rootserver=192.168.0.1, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.0.1
Looking up port of RPC 100005/1 on 192.168.0.1
VFS: Mounted root (nfs filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 72k init
Kernel panic: No init found. Try passing init= option to kernel.
<0>Rebooting in 180 seconds..

...und 'init' ist ein vorhandener Link in /sbin auf die Busybox in /bin der in meinem Beispiel nicht gefunden/aufgeloest wird..im Gegensatz zu dem von rolandm geposteten Bootlog http://forum.tuxbox-cvs.sourceforge.net ... =init+yadd wo es auch mit der Busybox weiterlaeuft im Gegensatz zu meinen erfolglosen Versuchen..

cu,
peter

Beitrag von **Npq** » Donnerstag 16. September 2004, 16:12

@studti:
Naja, ich kompiliere mir den immer selber, weiß nicht ob man den auch irgendwo im Netz fertig kompiliert findet.

@petgun
Hmm, seltsam, er mountet das Verzeichnis C:\dbox\cdkroot, das hört sich ja richtig an.

Da gab's zwar das Problem mit den Windows-Programmen, die die Symlinks nicht richtig auswerten aber ich denke mal, das wirst du ja schon berücksichtigt haben, schließlich sagst du ja selber, daß er auf die busybox zeigt.

Bei sowas guck ich mir meist direkt mit Ethereal an was da zwischen Server und Client hin- und her geht, ist oft effektiver als stundenlang zu rätseln.

Der Bootmanager-RARP geht mit dem WinPCap zwar nicht mehr, aber den braucht man für eine YADD ja sowieso nicht.

Npq hat geschrieben: Hmm, seltsam, er mountet das Verzeichnis C:\dbox\cdkroot, das hört sich ja richtig an.

Da gab's zwar das Problem mit den Windows-Programmen, die die Symlinks nicht richtig auswerten aber ich denke mal, das wirst du ja schon berücksichtigt haben, schließlich sagst du ja selber, daß er auf die busybox zeigt.

jau, mit tar entpackt...

Bei sowas guck ich mir meist direkt mit Ethereal an was da zwischen Server und Client hin- und her geht, ist oft effektiver als stundenlang zu rätseln.

Danke fuer den Tip...werde ich heute Abend mal probieren...hoffentlich geht meine Netzperformance nach der Installation von Etheral nicht dauerhaft in den Keller...Etheral mit WinPCap sind mit > 9MB ganz schoen fett ;-)

Der Bootmanager-RARP geht mit dem WinPCap zwar nicht mehr, aber den braucht man für eine YADD ja sowieso nicht.

...aber sonst gibt's keine Nachteile, oder?

cu,
peter

PS:die neue yadd (test5) von dietmarw geht jetzt ueber die vergeblichen BootP-Reqests hinaus, haengt aber bei mir noch genauso bei 'Kernel Panic..'...find ich aber super das sich was tut

Beitrag von **petgun** » Freitag 17. September 2004, 01:44

hi,
@Npq
danke fuer den heissen Tip mit Etheral

wirklich ein supergeiles Programm!

Wer von Euch kann das interpretieren:

Code: Alles auswählen

.
.
No.     Time        Source                Destination           Protocol Info
      6 0.087590    192.168.0.4           192.168.0.1           NFS      V2 LOOKUP Call (Reply In 7), DH:0x99abadf2/sbin

Frame 6 (154 bytes on wire, 154 bytes captured)
Ethernet II, Src: 00:50:9c:2d:xx:xx, Dst: 00:01:02:f4:xx:xx
Internet Protocol, Src Addr: 192.168.0.4 (192.168.0.4), Dst Addr: 192.168.0.1 (192.168.0.1)
User Datagram Protocol, Src Port: 800 (800), Dst Port: nfsd (2049)
Remote Procedure Call, Type:Call XID:0x0160b008
Network File System, LOOKUP Call DH:0x99abadf2/sbin

No.     Time        Source                Destination           Protocol Info
      7 0.088026    192.168.0.1           192.168.0.4           NFS      V2 LOOKUP Reply (Call In 6), FH:0x6fada3f2

Frame 7 (170 bytes on wire, 170 bytes captured)
Ethernet II, Src: 00:01:02:f4:xx:xx, Dst: 00:50:9c:2d:xx:xx
Internet Protocol, Src Addr: 192.168.0.1 (192.168.0.1), Dst Addr: 192.168.0.4 (192.168.0.4)
User Datagram Protocol, Src Port: nfsd (2049), Dst Port: 800 (800)
Remote Procedure Call, Type:Reply XID:0x0160b008
Network File System, LOOKUP Reply FH:0x6fada3f2

No.     Time        Source                Destination           Protocol Info
      8 0.089452    192.168.0.4           192.168.0.1           NFS      V2 LOOKUP Call (Reply In 9), DH:0x6fada3f2/init

Frame 8 (154 bytes on wire, 154 bytes captured)
Ethernet II, Src: 00:50:9c:2d:xx:xx, Dst: 00:01:02:f4:xx:xx
Internet Protocol, Src Addr: 192.168.0.4 (192.168.0.4), Dst Addr: 192.168.0.1 (192.168.0.1)
User Datagram Protocol, Src Port: 800 (800), Dst Port: nfsd (2049)
Remote Procedure Call, Type:Call XID:0x0160b009
Network File System, LOOKUP Call DH:0x6fada3f2/init

No.     Time        Source                Destination           Protocol Info
      9 0.089791    192.168.0.1           192.168.0.4           NFS      V2 LOOKUP Reply (Call In 8) Error:ERR_NOENT

Frame 9 (70 bytes on wire, 70 bytes captured)
Ethernet II, Src: 00:01:02:f4:xx:xx, Dst: 00:50:9c:2d:xx:xx
Internet Protocol, Src Addr: 192.168.0.1 (192.168.0.1), Dst Addr: 192.168.0.4 (192.168.0.4)
User Datagram Protocol, Src Port: nfsd (2049), Dst Port: 800 (800)
Remote Procedure Call, Type:Reply XID:0x0160b009
Network File System, LOOKUP Reply  Error:ERR_NOENT

No.     Time        Source                Destination           Protocol Info
     10 0.090943    192.168.0.4           192.168.0.1           NFS      V2 LOOKUP Call (Reply In 11), DH:0x99abadf2/etc

Frame 10 (154 bytes on wire, 154 bytes captured)
Ethernet II, Src: 00:50:9c:2d:xx:xx, Dst: 00:01:02:f4:xx:xx
Internet Protocol, Src Addr: 192.168.0.4 (192.168.0.4), Dst Addr: 192.168.0.1 (192.168.0.1)
User Datagram Protocol, Src Port: 800 (800), Dst Port: nfsd (2049)
Remote Procedure Call, Type:Call XID:0x0160b00a
Network File System, LOOKUP Call DH:0x99abadf2/etc

No.     Time        Source                Destination           Protocol Info
     11 0.091177    192.168.0.1           192.168.0.4           NFS      V2 LOOKUP Reply (Call In 10), FH:0x43a1a7f2

Frame 11 (170 bytes on wire, 170 bytes captured)
Ethernet II, Src: 00:01:02:f4:xx:xx, Dst: 00:50:9c:2d:xx:xx
Internet Protocol, Src Addr: 192.168.0.1 (192.168.0.1), Dst Addr: 192.168.0.4 (192.168.0.4)
User Datagram Protocol, Src Port: nfsd (2049), Dst Port: 800 (800)
Remote Procedure Call, Type:Reply XID:0x0160b00a
Network File System, LOOKUP Reply FH:0x43a1a7f2

No.     Time        Source                Destination           Protocol Info
     12 0.092450    192.168.0.4           192.168.0.1           NFS      V2 LOOKUP Call (Reply In 13), DH:0x43a1a7f2/init

Frame 12 (154 bytes on wire, 154 bytes captured)
Ethernet II, Src: 00:50:9c:2d:xx:xx, Dst: 00:01:02:f4:xx:xx
Internet Protocol, Src Addr: 192.168.0.4 (192.168.0.4), Dst Addr: 192.168.0.1 (192.168.0.1)
User Datagram Protocol, Src Port: 800 (800), Dst Port: nfsd (2049)
Remote Procedure Call, Type:Call XID:0x0160b00b
Network File System, LOOKUP Call DH:0x43a1a7f2/init

No.     Time        Source                Destination           Protocol Info
     13 0.093056    192.168.0.1           192.168.0.4           NFS      V2 LOOKUP Reply (Call In 12) Error:ERR_NOENT

Frame 13 (70 bytes on wire, 70 bytes captured)
Ethernet II, Src: 00:01:02:f4:xx:xx, Dst: 00:50:9c:2d:xx:xx
Internet Protocol, Src Addr: 192.168.0.1 (192.168.0.1), Dst Addr: 192.168.0.4 (192.168.0.4)
User Datagram Protocol, Src Port: nfsd (2049), Dst Port: 800 (800)
Remote Procedure Call, Type:Reply XID:0x0160b00b
Network File System, LOOKUP Reply  Error:ERR_NOENT

No.     Time        Source                Destination           Protocol Info
     14 0.094213    192.168.0.4           192.168.0.1           NFS      V2 LOOKUP Call (Reply In 15), DH:0x99abadf2/bin

Frame 14 (154 bytes on wire, 154 bytes captured)
Ethernet II, Src: 00:50:9c:2d:xx:xx, Dst: 00:01:02:f4:xx:xx
Internet Protocol, Src Addr: 192.168.0.4 (192.168.0.4), Dst Addr: 192.168.0.1 (192.168.0.1)
User Datagram Protocol, Src Port: 800 (800), Dst Port: nfsd (2049)
Remote Procedure Call, Type:Call XID:0x0160b00c
Network File System, LOOKUP Call DH:0x99abadf2/bin

No.     Time        Source                Destination           Protocol Info
     15 0.094596    192.168.0.1           192.168.0.4           NFS      V2 LOOKUP Reply (Call In 14), FH:0xc5abd1f2

Frame 15 (170 bytes on wire, 170 bytes captured)
Ethernet II, Src: 00:01:02:f4:xx:xx, Dst: 00:50:9c:2d:xx:xx
Internet Protocol, Src Addr: 192.168.0.1 (192.168.0.1), Dst Addr: 192.168.0.4 (192.168.0.4)
User Datagram Protocol, Src Port: nfsd (2049), Dst Port: 800 (800)
Remote Procedure Call, Type:Reply XID:0x0160b00c
Network File System, LOOKUP Reply FH:0xc5abd1f2

No.     Time        Source                Destination           Protocol Info
     16 0.095858    192.168.0.4           192.168.0.1           NFS      V2 LOOKUP Call (Reply In 17), DH:0xc5abd1f2/init

Frame 16 (154 bytes on wire, 154 bytes captured)
Ethernet II, Src: 00:50:9c:2d:xx:xx, Dst: 00:01:02:f4:xx:xx
Internet Protocol, Src Addr: 192.168.0.4 (192.168.0.4), Dst Addr: 192.168.0.1 (192.168.0.1)
User Datagram Protocol, Src Port: 800 (800), Dst Port: nfsd (2049)
Remote Procedure Call, Type:Call XID:0x0160b00d
Network File System, LOOKUP Call DH:0xc5abd1f2/init

No.     Time        Source                Destination           Protocol Info
     17 0.096337    192.168.0.1           192.168.0.4           NFS      V2 LOOKUP Reply (Call In 16) Error:ERR_NOENT

Frame 17 (70 bytes on wire, 70 bytes captured)
Ethernet II, Src: 00:01:02:f4:xx:xx, Dst: 00:50:9c:2d:xx:xx
Internet Protocol, Src Addr: 192.168.0.1 (192.168.0.1), Dst Addr: 192.168.0.4 (192.168.0.4)
User Datagram Protocol, Src Port: nfsd (2049), Dst Port: 800 (800)
Remote Procedure Call, Type:Reply XID:0x0160b00d
Network File System, LOOKUP Reply  Error:ERR_NOENT

No.     Time        Source                Destination           Protocol Info
     18 0.097532    192.168.0.4           192.168.0.1           NFS      V2 LOOKUP Call (Reply In 19), DH:0xc5abd1f2/sh

Frame 18 (154 bytes on wire, 154 bytes captured)
Ethernet II, Src: 00:50:9c:2d:xx:xx, Dst: 00:01:02:f4:xx:xx
Internet Protocol, Src Addr: 192.168.0.4 (192.168.0.4), Dst Addr: 192.168.0.1 (192.168.0.1)
User Datagram Protocol, Src Port: 800 (800), Dst Port: nfsd (2049)
Remote Procedure Call, Type:Call XID:0x0160b00e
Network File System, LOOKUP Call DH:0xc5abd1f2/sh

No.     Time        Source                Destination           Protocol Info
     19 0.098010    192.168.0.1           192.168.0.4           NFS      V2 LOOKUP Reply (Call In 18) Error:ERR_NOENT

Frame 19 (70 bytes on wire, 70 bytes captured)
Ethernet II, Src: 00:01:02:f4:xx:xx, Dst: 00:50:9c:2d:xx:xx
Internet Protocol, Src Addr: 192.168.0.1 (192.168.0.1), Dst Addr: 192.168.0.4 (192.168.0.4)
User Datagram Protocol, Src Port: nfsd (2049), Dst Port: 800 (800)
Remote Procedure Call, Type:Reply XID:0x0160b00e
Network File System, LOOKUP Reply  Error:ERR_NOENT

No.     Time        Source                Destination           Protocol Info
     20 0.499902    192.168.0.1           192.168.0.4           ICMP     Echo (ping) request

Frame 20 (98 bytes on wire, 98 bytes captured)
Ethernet II, Src: 00:01:02:f4:xx:xx, Dst: 00:50:9c:2d:xx:xx
Internet Protocol, Src Addr: 192.168.0.1 (192.168.0.1), Dst Addr: 192.168.0.4 (192.168.0.4)
Internet Control Message Protocol
.

ich habe noch weitere Tests gemacht (zB. 'init' durch die busybox ersetzt..dann geht's fehlerlos weiter bis zum naechsten Link) und es sieht so aus dass 'nur' die Links nicht/falsch aufgeloest werden. Woran koennte das liegen?
Ich befuerchte das es am SFU-NFS Server liegt und muss, um das zu testen, dann wohl oder uebel meinen heissgeliebten SFU-NFS Server deinstallieren und durch ???? ersetzen oder mit dem NFS-Server des Bootmanagers mein Glueck versuchen....

Vielen Dank fuer des bisherige Interesse,
peter

Beitrag von **justav** » Freitag 17. September 2004, 07:23

moin,

ich hatte das selbe problem mit diesen YADDs.

studti hat geschrieben:hallo,

beutze ein aktuelles YADD (Neutrino_Enigma_LCars_yadd_Day4.tar.bz2)
ich kann es auch booten, jedoch scheint es den angegebenen rootpath zu ignorieren

....

Kernel command line: root=/dev/nfs rw nfsroot=xx.xx.xx.xx:/kernel-cdkcdkroot/
ip=xx.xx.xx.xx:xx.xx.xx.xx:xx.xx.xx.xx:255.255.255.224:::off console=t
tyS0

hatte exakt den fehler.
dann habe ich mich hingesetzt und mir mein yadd - unter linux -selbst kompiliert.
(anleitung https://www.remote-admin.info/TuxboxDev ... index.html )

jetzt faehrt die box einwandfrei hoch.

gruss
justav

@justav

und du bootest die yadd defenetiv mit dem bootmanager unter windows?
denn vom booten unter linux ist hier leider nicht die rede..

Beitrag von **justav** » Freitag 17. September 2004, 10:14

o.k. - ich boote von einem linux-server

Beitrag von **petgun** » Freitag 17. September 2004, 11:07

hi,

dietmarw hat geschrieben: ..denn vom booten unter linux ist hier leider nicht die rede..

stimmt, und ich hoffe es ensteht nicht der Eindruck das Deine Yadd's Fehler haben.

@all
ich versuche die Yadd's mit dem Botmanager unter Windows zu starten, aber einen anderen NFS-Server zu verwenden. In meinem Fall den SFU-NFS Server. Das erste Ziel ist es, den Bootmanger nach erfolgreichem booten beenden zu koennen, da sich zB. zwei NFS-Server nicht gut vertragen....es reicht zB. nicht, den Service temp. abzschiessen. Am Ende der Versuche hoffe ich, beliebige Images (min. jffs2 only Images) auch ohne den Bootmanager wie eine Yadd booten und benutzen zu koennen

cu,
peter

PS:...es klappt (fast)wie gewohnt bei deinstalliertem SFU-NFS Server mit dem Bootmanager...zumindestens ein mal. Beim naechsten Startversuch (nach Konfiguration, ucodes einspielen usw.) haengt es bei:

.
VFS: Mounted root (nfs filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 72k init
init started: BusyBox v1.00-pre10 (2004.09.16-14:43+0000) multi-modprobe: Can't
locate module tuxbox
/proc/bus/tuxbox/vendor: No such file or directory
/proc/bus/tuxbox/vendor: No such file or directory
/proc/bus/tuxbox/model: No such file or directory
/proc/bus/tuxbox/model: No such file or directory
/proc/bus/tuxbox/submodel: No such file or directory
/proc/bus/tuxbox/submodel: No such file or directory
Detected STB:
Vendor: Unknown
Model: Unknown Unknown
ln: /dev/dvb/adapter0/demux1: No such file or directory
ln: /dev/dvb/adapter0/dvr1: No such file or directory

Please press Enter to activate this console. LCD (/dev/dbox/lcd0): No such file
or directory
/dev/input/event0: No such file or directory

...erst mal nicht so wichtig und wahrscheinlich ein Fehler von mir.

Also kann der SFU-NFS Server zumindest die Links nicht aufloesen

...ist das jetzt ein Bug und ein Fall fuer MS$ oder ist der NFS-Server im Bootmanager eine speziell angepasste Version? Muss ich die Idee jetzt begraben, oder hat einer von Euch noch einen Tip fuer mich?

@petgun
wie gesagt, da fehlte noch ein sleep in der rcs, ist im test6 drin.
mit dem sfu-nfs... wie gesagt, einfach nochmal andere testen..

@all
die yadds ab morgen booten wieder mit dem bootmanager..

grade eine getestet (test6)

@npq
thanks for info

Beitrag von **petgun** » Freitag 17. September 2004, 21:56

hi,

dietmarw hat geschrieben:@petgun
wie gesagt, da fehlte noch ein sleep in der rcs, ist im test6 drin.
mit dem sfu-nfs... wie gesagt, einfach nochmal andere testen..

;-) jau, ich bin dabei.

Mit NFS-Axe (klingt wie ein Deo ;-)) klappt noch nicht mal das mounten des root Verzeichnis mit dem Bootmanger und u-boot:

Ethereal output:

Code: Alles auswählen

.
No.     Time        Source                Destination           Protocol Info
   3860 47.346251   192.168.0.4           192.168.0.1           MOUNT    V1 MNT Call (Reply In 3861)

Frame 3860 (102 bytes on wire, 102 bytes captured)
Ethernet II, Src: 00:50:9c:2d:xx:xx, Dst: 00:01:02:f4:xx:xx
Internet Protocol, Src Addr: 192.168.0.4 (192.168.0.4), Dst Addr: 192.168.0.1 (192.168.0.1)
User Datagram Protocol, Src Port: 800 (800), Dst Port: 1038 (1038)
    Source port: 800 (800)
    Destination port: 1038 (1038)
    Length: 68
    Checksum: 0x3faf (correct)
Remote Procedure Call, Type:Call XID:0x007dc002
    XID: 0x7dc002 (8241154)
    Message Type: Call (0)
    RPC Version: 2
    Program: MOUNT (100005)
    Program Version: 1
    Procedure: MNT (1)
    The reply to this request is in frame 3861
    Credentials
    Verifier
        Flavor: AUTH_NULL (0)
        Length: 0
Mount Service
    Program Version: 1
    V1 Procedure: MNT (1)
    Path: C/dbox/yaddroot/
        length: 16
        contents: C/dbox/yaddroot/

No.     Time        Source                Destination           Protocol Info
   3861 47.347270   192.168.0.1           192.168.0.4           MOUNT    V1 MNT Reply (Call In 3860)

Frame 3861 (70 bytes on wire, 70 bytes captured)
Ethernet II, Src: 00:01:02:f4:xx:xx, Dst: 00:50:9c:2d:xx:xx
Internet Protocol, Src Addr: 192.168.0.1 (192.168.0.1), Dst Addr: 192.168.0.4 (192.168.0.4)
User Datagram Protocol, Src Port: 1038 (1038), Dst Port: 800 (800)
    Source port: 1038 (1038)
    Destination port: 800 (800)
    Length: 36
    Checksum: 0xb69f (correct)
Remote Procedure Call, Type:Reply XID:0x007dc002
    XID: 0x7dc002 (8241154)
    Message Type: Reply (1)
    Program: MOUNT (100005)
    Program Version: 1
    Procedure: MNT (1)
    Reply State: accepted (0)
    This is a reply to a request in frame 3860
    Time from request: 0.001019000 seconds
    Verifier
        Flavor: AUTH_NULL (0)
        Length: 0
    Accept State: RPC executed successfully (0)
Mount Service
    Program Version: 1
    V1 Procedure: MNT (1)
    Status: ERR_NOENT (2)

Bootlog:

Code: Alles auswählen

.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
      device=eth0, addr=192.168.0.4, mask=255.255.255.0, gw=255.255.255.255,
     host=192.168.0.4, domain=, nis-domain=(none),
     bootserver=192.168.0.1, rootserver=192.168.0.1, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.0.1
Looking up port of RPC 100005/1 on 192.168.0.1
Root-NFS: Server returned error -13 while mounting C/dbox/yaddroot/
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or 02:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00
 <0>Rebooting in 180 seconds..

Das Vereichnis c:\dbox\yaddroot\ exsistiert natuerlich und wird von nfsaxe auch als C/dbox/yaddroot/ exportiert (mounten und lesen/schreiben von der Dbox funktioniert einwandfrei), trotzdem klappt's mit dem Bootmanger und der yadd nicht

Muss ich jetzt solange suchen bis ich einen geeigneten NFS-Server finde, oder hat einer von Euch noch eine Idee?

dietmarw hat geschrieben:die yadds ab morgen booten wieder mit dem bootmanager.. grade eine getestet (test6)

Danke!

cu,
peter

Beitrag von **petgun** » Samstag 18. September 2004, 01:06

hi,
jetzt klappt es endlich

Ich habe die Yadd.tar in ein gemountetes Verzeichnis gelegt und ueber Telnet von der Box aus unter Linux mit tar entpackt. Dann sind die Links in Ordnung und SFU-NFS kommt damit klar und ich kann den Bootmanager auch ohne Probleme nach dem booten beenden

Die tar-Version die unter Windows mit cygwin laeuft, schein die Links also anders zu entpacken...unter Windows werden die Links auch mit dem typischen Pfeil fuer eine Verknuepfung dargestellt im Gegensatz zu den Links die jetzt funktionieren...das sind einfach nur Binaerdateien ohne den Verkuepfungspfeil. Klar ist im Moment nur, dass der NFS-Server des Bootmanagers mit den Windows-cygwin-tar-Links keine Probleme hat...SUF-NFS und nfsAxe kommen damit nicht klar...ich werde aber nicht weiter suchen ob ich noch einen anderen NFS-Server finde, der die Windows-cygwin-tar-Links aufloesen kann ;-)

Jetzt freue ich mich erst mal, dass ich einen Schritt weiter bin

cu,
peter

PS:@dietmarw
btw laeuft Deine yadd _test5_, die sich herkoemmlich mit dem Bootmanagers nur einmal starten liess, jetzt mit dem SFU_NFS Server wie ein Uhrwerk und kann auch problemlos rebootet werden!!!
Die Aenderung (sleep) scheint also bei der Methode nicht noetig zu sein...kannst Du das erklaeren? Auf welchem CVS-Stand basiert die Yadd test5 ? Da sind zB. noch Plugins drin wie zB. 'Enigma Demo', start/stop Ngrabrecording.
Dass die TS-Aufnahme bei der Startmethode funktioniert, hatte ich zwar gehofft, aber nicht unbedingt erwartet. ...laeuft absolut perfekt!
Vielen Dank fuer Deinen Yadd/Image Service! Ich werde jetzt aber eher seltener flashen und mehr Deine Yadd's benutzen