mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik NFS mit grasshopper / AVR32


Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HILFE!!

ich bin LINUX-Neuling und versuche seit einigen Tagen vergeblich, ein 
unter NFS freigegegegebenes Verzeichnis (Fedora 8) zu mounten 
(grasshopper: Linux version 2.6.24-icnova_base1 (benjamin@marvin)).

Folgende Konfigurationen habe ich eingestellt bzw. vorgefunden:

PC(server): 192.168.12.1
grasshopper(client): PC: 192.168.12.2

/etc/hosts:
127.0.0.1  localhost.localdomain  localhost  localhost
::1  localhost6.localdomain6  localhost6

Die Dateien /etc/hosts.allow und /etc/hosts.deny sind (noch) logisch 
leer.

/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=localhost.localdomain

/etc/exports:
/home/Superandi/Avr32/rootfs 192.168.12.0/255.255.255.0(rw,async,no_root_squash,subtree_check,insecure)

da ich Informationen über DHCP beziehe:

/etc/dhcpd.conf:
#configuration dhcp-server

allow bootp;
ddns-update-style none;
ddns-updates off;

subnet 192.168.12.0 netmask 255.255.255.0 {
  default-lease-time 1209600;
  max-lease-time 31557600;
  option subnet-mask 255.255.255.0;
  server-identifier 192.168.12.1;

  group {
    #server-name "linux";
    #option routers 0.0.0.0;
    next-server 192.168.12.1;
    option root-path "/home/Superandi/AVR32/rootfs";
    option host-name "grashopper1";
    filename "uImage";

    host grasshopper1 {
       hardware ethernet 00:1F:E5:00:03:96;
      fixed-address 192.168.12.2;
    }
  }
}
#end of file

/etc/sysconfig/nfs:
#
# Define which protocol versions mountd 
# will advertise. The values are "no" or "yes"
# with yes being the default
#MOUNTD_NFS_V1="no"
#MOUNTD_NFS_V2="no"
#MOUNTD_NFS_V3="no"
#
# Path to remote quota server. See rquotad(8)
RQUOTAD="/usr/sbin/rpc.rquotad"
# Port rquotad should listen on.
RQUOTAD_PORT=875
# Optinal options passed to rquotad
#RPCRQUOTADOPTS=""
#
# TCP port rpc.lockd should listen on.
LOCKD_TCPPORT=32803
# UDP port rpc.lockd should listen on.
LOCKD_UDPPORT=32769
#
# Optional arguments passed to rpc.nfsd. See rpc.nfsd(8)
#RPCNFSDARGS
# Number of nfs server processes to be started.
# The default is 8. 
RPCNFSDCOUNT=8
#
# Optional arguments passed to rpc.mountd. See rpc.mountd(8)
#RPCMOUNTDOPTS=""
# Port rpc.mountd should listen on.
MOUNTD_PORT=892
#
# Optional arguments passed to rpc.statd. See rpc.statd(8)
STATDARG="--name localhost"
# Port rpc.statd should listen on.
STATD_PORT=662
# Outgoing port statd should used. The default is port
# is random
STATD_OUTGOING_PORT=2020
# Specify callout program 
#STATD_HA_CALLOUT="/usr/local/bin/foo"
#
# Optional arguments passed to rpc.idmapd. See rpc.idmapd(8)
#RPCIDMAPDARGS=""
#
# Set to turn on Secure NFS mounts. 
#SECURE_NFS="yes"
# Optional arguments passed to rpc.gssd. See rpc.gssd(8)
#RPCGSSDARGS=""
# Optional arguments passed to rpc.svcgssd. See rpc.svcgssd(8)
#RPCSVCGSSDARGS=""
#

/etc/sysconfig/rpcbind:
# Optional arguments passed to rpcbind. See rpcbind(8)
RPCBIND_ARGS="-l"

Firewalls sind abgeschossen bzw. deaktiviert. SeLinux habe ich ruhig 
gestellt in /etc/selinux/config:
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#  enforcing - SELinux security policy is enforced.
#  permissive - SELinux prints warnings instead of enforcing.
#  disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#  targeted - Targeted processes are protected,
#  mls - Multi Level Security protection.
SELINUXTYPE=targeted 
# SETLOCALDEFS= Check local definition changes
SETLOCALDEFS=0
Die Dienste rpcbind/nfs/dhcpd laufen und melden keinerlei Probleme.

Wenn ich nun als root auf dem grasshopper versuche, das freigegebene 
Verzeichnis zu mounten mit
mount 192.168.12.1:/home/Superandi/Avr32/rootfs /mnt
bekomme ich nach einiger Zeit die Meldungen:
rpcbind: server localhost not responding, timed out
RPC: failed to contact local rpcbind server (errno 5).
rpcbind: server localhost not responding, timed out
RPC: failed to contact local rpcbind server (errno 5).
lockd_up: makesock failed, error=-5
rpcbind: server localhost not responding, timed out
RPC: failed to contact local rpcbind server (errno 5).
mount: mounting 192.168.12.1:/home/Superandi/Avr32/rootfs on /mnt failed

Auf dem PC sehe ich in /var/log/messages:
Sep 15 13:14:20 localhost rpcbind: connect from 192.168.12.2 to dump()
Sep 15 13:14:20 localhost mountd[2059]: authenticated mount request from 192.168.12.2:973 for /home/Superandi/Avr32/rootfs (/home/Superandi/Avr32/rootfs)
Sep 15 13:14:20 localhost rpcbind: connect from 192.168.12.2 to getport/addr(nfs)

Ich interpretiere die Fehlermeldung so, dass das NFS des Servers seinen 
localhost nicht findet. Diese Vermutung wird bestärkt dadurch, dass ich 
am PC auf
rpcinfo -p localhost
folgende Rückmeldung bekomme:
rpcinfo: can't contact portmapper: RPC: Unknown host

Die gleiche Anfrage ohne Angabe 'localhost' ergibt das erwartete 
Ergebnis:
[root@localhost Superandi]# rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100000    4     0    111  portmapper
    100000    3     0    111  portmapper
    100000    2     0    111  portmapper
    100024    1   udp    662  status
    100024    1   tcp    662  status
    100011    1   udp    875  rquotad
    100011    2   udp    875  rquotad
    100011    1   tcp    875  rquotad
    100011    2   tcp    875  rquotad
    100021    1   udp  32769  nlockmgr
    100021    3   udp  32769  nlockmgr
    100021    4   udp  32769  nlockmgr
    100021    1   tcp  32803  nlockmgr
    100021    3   tcp  32803  nlockmgr
    100021    4   tcp  32803  nlockmgr
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100005    1   udp    892  mountd
    100005    1   tcp    892  mountd
    100005    2   udp    892  mountd
    100005    2   tcp    892  mountd
    100005    3   udp    892  mountd
    100005    3   tcp    892  mountd
Ich hatte schon die Vermutung, dass es daran liegt, dass an vielen 
Stellen nicht 'localhost' sondern 'localhost.localdomain' zu finden ist. 
Allerdings wird
rpcinfo -p localhost.localdomain
ebenfalls mit
rpcinfo: can't contact portmapper: RPC: Unknown host
quittiert.

So. Ich hoffe, es findet sich jemand, der sich erbarmt, mir zu sagen, wo 
ich geschlampt bzw. keine Ahnung habe. Als Motivation: Wenn mir jemand 
hilft, verspreche ich ein Kapitel in der grasshopper-wiki zu schreiben, 
in dem erklärt wird, wie wo was einzustellen ist, damit DHCP/BOOTP + 
TFTP + NFS-root funktioniert.

Autor: Claude Schwarz (claudeschwarz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube konkret Helfen kann ich Dir nicht. Aber ganz sicher das die 
Firewall(s) aus sind? Schon mal iptables -L aufgerufen? Kannst Du den 
localhost pingen ? Und was gibt ifconfig aus?

PS: Beeindruckend was Du als "Anfänger" schon alles überprüft hast , da 
kenne ich (Selbsternannte)"Profis" die viel früher das Handtuch werfen!

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sodann:

iptables -L
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             192.168.122.0/24    state RELATED,ESTABLISHED 
ACCEPT     all  --  192.168.122.0/24     anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable 
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable

Was macht icmp-port? Ist der für NFS relevant? Sollte da mehr bei 
rauskommen?

ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=4.72 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.351 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.245 ms
...

ifconfig
eth1      Link encap:Ethernet  HWaddr 00:0C:29:33:84:87  
          inet addr:192.168.136.130  Bcast:192.168.136.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe33:8487/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:791 errors:0 dropped:0 overruns:0 frame:0
          TX packets:752 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:497024 (485.3 KiB)  TX bytes:128356 (125.3 KiB)
          Interrupt:19 Base address:0x2080 

eth2      Link encap:Ethernet  HWaddr 00:0C:29:33:84:91  
          inet addr:169.254.17.44  Bcast:169.254.17.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe33:8491/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:99 errors:0 dropped:0 overruns:0 frame:0
          TX packets:65 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:17368 (16.9 KiB)  TX bytes:8864 (8.6 KiB)
          Interrupt:16 Base address:0x2000 

eth2:0    Link encap:Ethernet  HWaddr 00:0C:29:33:84:91  
          inet addr:192.168.12.1  Bcast:192.168.12.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:16 Base address:0x2000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2817 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2817 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:3702660 (3.5 MiB)  TX bytes:3702660 (3.5 MiB)

virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:6247 (6.1 KiB)

Zu dieser Konfiguration kommt es unter vmware (unter Win2000 ohne 
firewall). Zu den einzelenen 'Netzwerkkarten':

eth1: Mit vmware NAT -> WLAN

eth2: Drahtgebundenes (vmware bridge) Netzwerk mit switch & grasshopper 
(kein DHCP). Win2000 holt sich automatisch eine IP-Adresse (ZeroConf) 
und ich meine festgestellt zu haben, dass die Linux-VM im gleichen 
Submetz (Strang) sein muss um raus- und reinzukommen.

eth2:0 Die Spielwiese. Die habe ich eingerichtet, da ich auf Malooche 
eine andere IP-Adressen für eth2 habe. Dort ist übrigens ein 
DHCP-Server, der sich mit meinem 'duelliert'. Dummerweise muss ich beim 
Booten immer das Kabel vom Switch abziehen, sonst bekommt der 
grasshopper eine falsche Adresse. Wenn jemand Spass daran mir zu sagen, 
was ich an meinem DHCP Server einstellen muss um mit das zu ersparen, so 
will ich keinen abhalten...


Das k.. mich echt an. Erst lief es ganz geschmeidig: Fedora 8 auf vmware 
/ Toolchain von der CD kopiert & kompiliert / auf relativ kleinem Umweg 
DHCP(BootP)/TFTP mit U-Boot ans Laufen bekommen - und jetzt dass: Ich 
kann weder beim booten das rootfs mounten noch nach 'normalem' boot den 
freigegebenen Ordner mounten. Alle (insbesondere der Kollege nebenan mit 
seinem Fedora 4 und portmap) sagen NFS einzurichten sei eine Sache von 
wenigen Minuten...

Vielleicht hilft 'neu aufsetzen' aber das kanns nicht sein...

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich wollte ja schlafen gehen, aber dann habe ich angefangen mit 
/etc/host.allow und mit /etc/host.deny rumzuspielen, um herauszubekommen 
wann es hakt.

Die Minimalanforderung, die vom Dienst (oder Daemon gibt es da 
eigentlich Unterschiede?) 'nfs' zum Start benötigt wird

/etc/hosts.allow
rpcbind:127.0.0.1
/etc/hosts.deny
rpcbind:ALL
mountd:ALL
lockd:ALL
rquotad:ALL
statd:ALL

Der grasshopper soll sich nicht verbinden - tut er denn auch nicht:
# mount -t nfs 192.168.12.1:/home/Superandi/Avr32/rootfs /mnt
pmap_getmaps rpc problem: RPC: Authentication error; why = Client credential too weak
mount: RPC: Unable to receive; errno = Connection refused
Der PC sagt:
Sep 16 01:22:39 localhost rpcbind: connect from 192.168.12.2 to dump(): request from unauthorized host
Das sieht kontrolliert aus so so.

Versuchen wir es mit
/etc/hosts.deny
#rpcbind:ALL
mountd:ALL
lockd:ALL
rquotad:ALL
statd:ALL
Das Insekt meldet
mount: RPC: Authentication error; why = Failed (unspecified error)
Der PC
Sep 16 01:26:05 localhost mountd[4743]: connect from 192.168.12.2 to proc (1) in mountd: request from unauthorized host

Jetzt kommt:
/etc/hosts.deny
#rpcbind:ALL
#mountd:ALL
lockd:ALL
rquotad:ALL
statd:ALL

Es kommt zu ewig langem Warten beim Grasshopper und dann Fehlermedlungen 
wie oben
rpcbind: server localhost not responding, timed out
RPC: failed to contact local rpcbind server (errno 5).

und der PC tut, als ob nichts böses passiert sei:
Sep 16 01:28:03 localhost rpcbind: connect from 192.168.12.2 to dump()
Sep 16 01:28:04 localhost mountd[4911]: authenticated mount request from 192.168.12.2:984 for /home/Superandi/Avr32/rootfs (/home/Superandi/Avr32/rootfs)
Sep 16 01:28:04 localhost rpcbind: connect from 192.168.12.2 to getport/addr(nfs)

Für mich folgt hieraus, dass das mountd nicht seiner Arbeit nachkommt 
(weitere Dienste sind ja untersagt - würden die in Anspruch genommen 
werden, käme es zu einem definieretn und schnellen Fehler ohne Timeout).

Aber bringt mit das nicht nur neue Fragen? Was würde denn als nächstes 
passieren (welcher Dienst)? Was treibt mountd eigenlich mit rpcbind 
genau. Gibt es noch andere Log-Dateien, die informativer sind? Oder ein 
paar nette Bash Kapriolen, die mir sagen: Du musst in der Datei das 
ändern, dann klappt's auch mit NFS?

Ich geh schlafen..

Autor: SiO2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1000 und ein mal . Ich habe hier ein grundsätzliche Problem mit NFS: Ich 
denke wenn der grasshopper schon komplett unter Linux laufend mit dem 
mounten Probleme hat, wird er es beim booten auch nicht schaffen (nur 
muss ich beim booten immer RESET drücken, ein Netwerkkabel abziehen und 
an der U-Boot kommandozeile einige Befehle absondern)

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ich schon wieder (ich muss euch leider zutexten - wenn ich nicht 
bald eine Lösung finde kann ich für nichts garantieren...)

Ich habe mal mit tcpdump die Kommunikation mitgehört:
tcpdump -lT rpc host 192.168.12.1 and 192.168.12.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes
10:15:43.857789 IP 192.168.12.2.984 > 192.168.12.1.sunrpc: S 1344345850:1344345850(0) win 5840 <mss 1460,sackOK,timestamp 701032 0,nop,wscale 1>
10:15:43.857825 arp who-has 192.168.12.2 tell 192.168.12.1
10:15:43.858263 arp reply 192.168.12.2 is-at 00:1f:e5:00:03:96 (oui Unknown)
10:15:43.858271 IP 192.168.12.1.sunrpc > 192.168.12.2.984: S 3342150041:3342150041(0) ack 1344345851 win 5792 <mss 1460,sackOK,timestamp 4080096 701032,nop,wscale 6>
10:15:43.858762 IP 192.168.12.2.984 > 192.168.12.1.sunrpc: . ack 1 win 2920 <nop,nop,timestamp 701032 4080096>
10:15:43.859194 IP 192.168.12.2.984 > 192.168.12.1.sunrpc: P 1:45(44) ack 1 win 2920 <nop,nop,timestamp 701033 4080096>
10:15:43.859212 IP 192.168.12.1.sunrpc > 192.168.12.2.984: . ack 45 win 91 <nop,nop,timestamp 4080098 701033>
10:15:43.864128 IP 192.168.12.1.sunrpc > 192.168.12.2.984: P 1:693(692) ack 45 win 91 <nop,nop,timestamp 4080103 701033>
10:15:43.864722 IP 192.168.12.2.984 > 192.168.12.1.sunrpc: . ack 693 win 3612 <nop,nop,timestamp 701034 4080103>
10:15:43.865203 IP 192.168.12.2.984 > 192.168.12.1.sunrpc: F 45:45(0) ack 693 win 3612 <nop,nop,timestamp 701034 4080103>
10:15:43.865866 IP 192.168.12.1.sunrpc > 192.168.12.2.984: F 693:693(0) ack 46 win 91 <nop,nop,timestamp 4080105 701034>
10:15:43.866136 IP 192.168.12.2.0x605294b4 > 192.168.12.1.sunrpc: 108 set mountd.3
10:15:43.866493 IP 192.168.12.2.984 > 192.168.12.1.sunrpc: . ack 694 win 3612 <nop,nop,timestamp 701034 4080105>
10:15:46.867231 IP 192.168.12.2.0x605294b4 > 192.168.12.1.sunrpc: 108 set mountd.3
10:15:49.018016 IP 192.168.12.1.nfs > 192.168.12.2.1616024756: reply ok 84
10:15:49.018912 IP 192.168.12.2.0x27c1304c > 192.168.12.1.sunrpc: 56 getport portmapper.2
10:15:49.020073 IP 192.168.12.1.nfs > 192.168.12.2.666972236: reply ok 28
10:15:49.022615 IP 192.168.12.2.0x897241df > 192.168.12.1.sunrpc: 40 null
10:15:49.022909 IP 192.168.12.1.nfs > 192.168.12.2.2305966559: reply ok 24
10:15:49.029684 IP 192.168.12.1.nfs > 192.168.12.2.1616024756: reply ok 84

Der dazu gehörende Syslog aus dem PC:
Sep 16 10:15:28 localhost kernel: device eth2 entered promiscuous mode
Sep 16 10:15:34 localhost dhcpd: DHCPINFORM from 192.168.7.101 via eth2: unknown subnet for address 192.168.7.101
Sep 16 10:15:43 localhost rpcbind: connect from 192.168.12.2 to dump()
Sep 16 10:15:49 localhost mountd[3162]: authenticated mount request from 192.168.12.2:985 for /home/Superandi/Avr32/rootfs (/home/Superandi/Avr32/rootfs)
Sep 16 10:15:49 localhost mountd[3162]: authenticated mount request from 192.168.12.2:985 for /home/Superandi/Avr32/rootfs (/home/Superandi/Avr32/rootfs)
Sep 16 10:15:49 localhost rpcbind: connect from 192.168.12.2 to getport/addr(nfs)
Sep 16 10:17:59 localhost kernel: device eth2 left promiscuous mode

Ich habe das mount-Kommando am grasshopper um 10:15:43 losgeschickt. 
Kann hier jemand sehen, wo eine Antwort fehlerhaft ist bzw. ausbleibt?

Autor: Claude Schwarz (claudeschwarz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin ehrlich gesagt ratlos! Was mir aber noch auffällt ist das Du VmWare 
mit NAT benutzt. Damit habe ich auch nur Probleme gehabt , hatte dann 
damals auf Bridge umgestellt und alles lief bei mir. Inzwischen bin ich 
auf VirtualBox umgestiegen und dort "Bridge" ich auch alles. Eigentlich 
bin ich eingefleischter Debianer und SELinux Hasser, aber meine letzten 
NFS Versuche mit FC7 verliefen eigentlich Problemlos (Mit Klicki-Bunti 
Interface)

Autor: Claude Schwarz (claudeschwarz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arggh sollte alles lesen , das Kabel ETH ist ja über eine Bridge 
verbunden.

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läuft auf dem Client der portmapper?
Probier mal beim Client:

# /sbin/portmap
# mount -t nfs 192.168.12.1:/home/Superandi/Avr32/rootfs /mnt

Dann sollte das laufen.
(bin bei meiner diskless Arbeitsstation auch schon in
 die Falle getappt und hab versehenstlich den portmapper
 deinstalliert... aber es gibt ja chroot :-)

Weiter Oben ist mir noch aufgefallen das du mal
/home/Superandi/ Avr 32/rootfs
und mal
/home/Superandi/ AVR 32/rootfs
geschrieben hast, was 2 verschieden Verzeichnisse sind.

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DAS LEBEN IST SCHÖN!!!

@Tim Oh Du Retter. Ich war fest davon überzeugt, der PC ist der Böse. 
Das schärfste ist: Ich hatte mich fast über SiO2 geärgert (wie kann der 
mich für so blöd halten). In dem Artikel steht (ich muss allerdings zu 
meiner Entschuldigung sagen bei dem TFTP Abschnitt) erst portmap 
starten!!! Wie war das mit dem Wald und den Bäumen? Einen habe ich aber 
noch: Ich verstehe nicht was man mit chroot anfangen kann...

@Alle: Jetzt, da ich weiss, wie einfach NFS sein kann (viele der 
Konfigurationsfiles, die ich oben erwähnt habe, braucht es gar nicht - 
mit den defaults kommt NFS durch die Tür): Besteht hier jemand darauf, 
dass ich die Einrichtung DHCP/BootP  TFTP  NFS in dem Artikel [[AVR32 
Grasshopper]] beschreibe?

Autor: SiO2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@schnitzeltony, wenn du den Artikel erweitern kannst, dann mach es 
einfach. :D

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chroot ändert für das vom im gestartete Programm (sofern angegeben,
ansonsten /bin/sh) das root Verzeichnis.

Theoretisch würde
chroot /home/Superandi/AVR32/rootfs
bei dir eine shell innerhalb von /home/Superandi/AVR32/rootfs
starten. Für diese shell ist / dann /home/Superandi/AVR32/rootfs
und sie kann nur auf Dateien unterhalb von /home/Superandi/AVR32/rootfs
zugreifen.

Funktioniert bei dir aber nicht, da du in
/home/Superandi/AVR32/rootfs keine i386 Binarys liegen hast.

Ein Windows Vergleich wäre etwa so:
Du hast Windows 2x auf verschiedenen Partitonen auf deinem
PC installiert. Du färst windows Nr.1 hoch und startest dann
den explorer vom 2. Windows. Und der Würde sich so verhalten
als wenn du das 2. Windows hochgefahren hättest.

Dann noch ein Tipp:
Lese Fehlermeldungen von Linux sorgfältig. Anders als bei
Windows sagen die dir in der regel was/wo das Problem ist:
rpcbind: server localhost not responding, timed out
RPC: failed to contact local rpcbind server (errno 5).
"failed to contact local rpcbind server" war hier der
berühmte Wink mit dem Zaunpfahl.

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tim: Sieht noch nach einem langen Weg aus aber es ist ungeheuer 
spannend...

zu chroot:
Ich denke ich habe verstanden, was man damit machen kann. Das dumme ist 
nur, dass ich das von Dir genannte Szenario nicht verstehe: Du sagst, Du 
hattest eine Diskless-Station und hast portmap deinstalliert (wo? auf 
der Station oder deren Server). Hattest Du dort noch ein 'Ersatz' RootFS 
(bitte nicht zu laut lachen, wenn ich völlig daneben liege).

@Alle: zu meinem ursprunglichen Problem (der kleine Nimmersatt kann den 
Hals nicht voll bekommen):

Ich bin einen Schritt weiter (ich kenne den Verursacher des Problems) 
bin aber nicht am Ziel. Nochmal kurz was ich vorhabe:

1. Am U-Boot DHCP ausführen: U-Boot holt IP, Bootparameter und per TFTP 
den Kernel beim PC ab.
2. Kernel starten. Die Information, dass das RootFS per NFS zu beziehen 
ist, hinterlege ich im U-Boot durch
setenv bootargs root=/dev/nfs ip=dhcp nfsroot=${serverip}:${rootpath}
Bis auf das mounten klappt alles soweit. Ich fürchte, ich habe hier ein 
klassisches Ei/Huhn Problem: portmap ist notwendig für das mounten des 
RootFS befindet sich dummerweise in dem selben.

Kennt jemand die Antwort / Links zu diesem Problem?

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@Tim: Sieht noch nach einem langen Weg aus aber es ist ungeheuer
>spannend...

Ja. Aber die Lernkurve ist schon ziemlich steil. (und wird auch nicht 
wesentlich flacher) - aber ich wollte Dir jetzt nicht deine
Motivation nehmen :-)

>zu chroot:
>Ich denke ich habe verstanden, was man damit machen kann.

Gut.

>Du sagst, Du
>hattest eine Diskless-Station und hast portmap deinstalliert (wo? auf
>der Station oder deren Server).

Habe auf dem Client den dortigen Packetmanager angewiesen
portmap zu entfernen. (Fehler!)
Beim Booten am nächten Tag kam sowas wie rootfs nicht gefunden....
Also zum Server gelaufen, eingeloggt und
# chroot /srv/diskless
(in /srv/diskless ist das rootfs vom Client drin wie bei
 deinem /home/Superandi/AVR32/rootfs)
Dann habe ich den Packetmanager gebeten portmap wieder zu
installieren, was er auch braf getan hat (also im rootfs
des Clients unter /srv/diskless)
Danach dem Client Pc einen Reset verpasst und schon war
die Welt wieder bunt :-)

> Hattest Du dort noch ein 'Ersatz' RootFS

Ich hätte das Backup raushohlen können und damit
/srv/diskless wieder in den alten zustand versetzten können....
Macht aber arbeit, dauert ne weile und chroot war einfacher.

Zum Booten via Netztwerk / NFS root:
mit dem ip=dhcp währe ich vorsichtig, da das einen dhcp
client im Kernel vorraussetzt.
Häng doch mal an was die Kernel beim booten so alles von sich gibt.
Da müsste sich doch ein Hinweiss auf das Problem finden lassen....

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die Motivation ist gut..

da hätten wir:
Sending DHCP requests .<6>eth0: link up (100/Full)
., OK
IP-Config: Got DHCP answer from 192.168.12.1, my address is 192.168.12.2
IP-Config: Complete:
      device=eth0, addr=192.168.12.2, mask=255.255.255.0, gw=255.255.255.255,
     host=grashopper1, domain=localdomain, nis-domain=(none),
     bootserver=192.168.12.1, rootserver=192.168.12.1, rootpath=/home/Superandi/Avr32/rootfs
Looking up port of RPC 100003/2 on 192.168.12.1
Looking up port of RPC 100005/1 on 192.168.12.1
VFS: Mounted root (nfs filesystem).
Freeing init memory: 64K (90000000 - 90010000)
nfs: server 192.168.12.1 not responding, still trying
nfs: server 192.168.12.1 not responding, still trying

Also ich finde der DHCP Client sieht sehr gut aus - ich bin mächtig 
stolz, was alles angekommen ist :-))

Bis
nfs: server 192.168.12.1 not responding, still trying
geht's flott aber dann verließen sie ihn. Der Hüpfer verendet nach etwa 
1-2 minuten in wilden Call-Stack-dumps...

Will irgendjemand die sehen?

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Siehe unter "Linux freezes at startup after aquiring address" auf

http://www.avrfreaks.net/wiki/index.php/Documentat...

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Werner: Ich bin nicht sicher, aber ich glaube mein Problem findet zu 
einem früheren Zeitpunkt statt.
@Tim ich glaube mit (Linux-)DHCP hat das nichts zu tun. Um dies zu 
überprüfen nehme ich
1. UBoot DHCP/TFTP:
ICNova>DHCP
macb0: Starting autonegotiation...
macb0: Autonegotiation complete
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
BOOTP broadcast 1
DHCP client bound to address 192.168.12.2
Using macb0 device
TFTP from server 192.168.12.1; our IP address is 192.168.12.2
Filename 'uImage'.
Load address: 0x10400000
Loading: #################################################################
         ##########################
done
Bytes transferred = 1330546 (144d72 hex)

2. UBoot Variablen so einstellen, wie in dem Artikel (ohne DHCP!) 
beschrieben (angepasst auf meine Umgebung) und überprüfen:
ICnova> setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}::${serverip}:::eth0:off console=ttyS0
ICnova> printenv
bootcmd=mtdparts default;chpart nor0,2;fsload /boot/uImage;bootm ${fileaddr}
bootdelay=3
baudrate=115200
ethact=macb0
ethaddr=00:1F:E5:00:03:96
stdin=serial
stdout=serial
stderr=serial
bootfile=uImage
filesize=144D72
fileaddr=10400000
netmask=255.255.255.0
hostname=grashopper1
rootpath=/home/Superandi/Avr32/rootfs
ipaddr=192.168.12.2
serverip=192.168.12.1
bootargs=root=/dev/nfs nfsroot=192.168.12.1:/home/Superandi/Avr32/rootfs ip=192.168.12.2::192.168.12.1:::eth0:off console=ttyS0

Environment size: 486/65532 bytes
Sowohl das booten des Flash- (boot) als auch des über TFTP geladenen 
(bootm) Kernels ergeben identische Fehlersituationen:
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
      device=eth0, addr=192.168.12.2, mask=255.255.255.0, gw=192.168.12.1,
     host=192.168.12.2, domain=, nis-domain=(none),
     bootserver=255.255.255.255, rootserver=192.168.12.1, rootpath=
Looking up port of RPC 100003/2 on 192.168.12.1
eth0: link up (100/Full)
Looking up port of RPC 100005/1 on 192.168.12.1
VFS: Mounted root (nfs filesystem).
Freeing init memory: 64K (90000000 - 90010000)

Das sieht der Fehlersituation mit DHCP sehr ähnlich (lediglich die 
Meldungen, dass der nfs-Server nicht reagiert, bleiben aus).
Witzigerweise sagt der grasshopper, er habe das RootFS gemounted! Ich 
denke, der Toolchain ist beizubringen, den portmapper (siehe oben) im 
Kernel verfügbar zu machen und zu starten. Was mich ebenfalls ein 
bischen verwirrt - gegenüber der Lösung mit DHCP - ist die Tatsache, 
dass RCP aufgerufen wird, bevor eth0 'habe fertig' meldet.

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon wieder ich..

Habe mir mal nach 'normal' gebooteten grasshopper die Prozesse 
angesehen:
# ps -w
  PID  Uid        VSZ Stat Command
    1 root       1264 S   init       
    2 root            SW< [kthreadd]
    3 root            SW< [ksoftirqd/0]
    4 root            SW< [watchdog/0]
    5 root            SW< [events/0]
    6 root            SW< [khelper]
   55 root            SW< [kblockd/0]
   83 root            SW  [pdflush]
   84 root            SW  [pdflush]
   85 root            SW< [kswapd0]
   86 root            SW< [aio/0]
  679 root            SW< [mtdblockd]
  680 root            SW< [ftld]
  698 root            SW< [rpciod/0]
  712 root            SWN [jffs2_gcd_mtd2]
  718 root       1260 S   /sbin/syslogd 
  720 root       1260 S   /sbin/klogd 
  738 root       1284 S   udhcpc -R -n -p /var/run/udhcpc.eth0.pid -i eth0 
  759 root       1272 S   /usr/sbin/httpd 
  765 root       1260 S   /usr/sbin/telnetd 
  773 root       1264 S   /sbin/getty 38400 tty1 
  775 root       1264 S   /sbin/getty 38400 tty2 
  778 root       1264 S   /sbin/getty 38400 tty3 
  781 root       1264 S   /sbin/getty 38400 tty4 
  783 root       1264 S   /sbin/getty 38400 tty5 
  785 root       1264 S   /sbin/getty 38400 tty6 
  789 root       1268 S   -sh 
  792 root       1264 S   /sbin/getty -L ttyS1 38400 vt100 
  796 root       1264 R   ps -w

Aufgrund seines Namens und der Tatsache, dass kein Verzeichnis angegeben 
ist, google ich nach rpciod und siehe da: Es gibt anscheinend zwei 
unterschiedlich Arten NFS zu betreiben:
1. Kernel Mode (über rpciod?)
2. User Mode (über portmap?)
Ich werde mich mal weiter nach rpciod umsehen...

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dhcp sieht sehr gut aus.
Looking up port of RPC 100003/2 on 192.168.12.1
Looking up port of RPC 100005/1 on 192.168.12.1

Kernel interner portmap geht auch.
VFS: Mounted root (nfs filesystem).
Freeing init memory: 64K (90000000 - 90010000)

Sehr gut. Root fs ist da.
nfs: server 192.168.12.1 not responding, still trying
nfs: server 192.168.12.1 not responding, still trying

Das wiederum sieht sehr schlecht aus. Ich fürchte das
es am Server liegt.....
Was steht in deiner aktuellen /etc/hosts.allow
/etc/hosts.deny und /etc/exports drin?

Das bei den avrfreaks beschriebene Problem ist es nicht.

Nebenbei:
Warum laufen da eigentlich 6 gettys?
  773 root       1264 S   /sbin/getty 38400 tty1 
  775 root       1264 S   /sbin/getty 38400 tty2 
  778 root       1264 S   /sbin/getty 38400 tty3 
  781 root       1264 S   /sbin/getty 38400 tty4 
  783 root       1264 S   /sbin/getty 38400 tty5 
  785 root       1264 S   /sbin/getty 38400 tty6 
Die sind alle vollkommen überflüssig (es sei den du hast
eine echte console, also Monitor und Tastatur, am Hopper
dran). Kann man in /etc/inittab abstellen. Das getty auf
ttyS1 muss aber bleiben, da sonst keine serielle console.

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tim: ich hoffe es kommt die Zeiten in denen ich mich für Deine 
Bemühungen revanchieren kann...

Zunächst die Antworten:

1. In /etc/hosts.allow bzw. /etc/hosts.deny ist alles mit '#' 
auskommentiert.

2.
cat /etc/exports
/home/Superandi/Avr32/rootfs 192.168.12.0/255.255.255.0(rw,no_root_squash)
#/home/Superandi/Avr32/rootfs 192.168.12.0/255.255.255.0(rw,sync,no_root_squash,insecure)
Der grasshopper unter Linux kann mounten und ich kann mit ls auch alles 
sehen.

3. Die 6 gettys waren so eingestellt (ich habe an dem Flash bisher 
nichts geändert)

Es gibt allerdings neue Erkenntnisse (bilde ich mir jedenfalls ein). Ich 
hoffe ich bekomme das so erklärt, dass es verständlich ist:

Ich habe zwei Netzwerk-Umgebungen (siehe auch schon weiter oben): Zu 
Hause ohne weiteren DHCP-Server auf dem drahtgebundenen Netzwerk (nur 
mein Linux DHCP) / in der Firma mit Microsoft-DHCP (dort muss ich immer 
das Netzwerkkabel zum Rest-Netz vom Switch abziehen, sonst bekommt der 
grasshopper die DHCP-Informationen vom MS-Server, die zum booten wenig 
geeignet sind).

Dies halte ich insoweit für wichtig, weil der grasshopper sich in den 
Umgebungen unterschiedlich verhält:

In der Firma:
Dort bekomme ich keine Timeout Meldungen, allerdings nur, wenn ich nach 
dem DHCP des grasshoppers das Kabel zum Firmen-Netz wieder anbringe. 
Allerdings hängt der grasshopper anschließend. Im Vergleich zum 
'normal'-booten müsste eingentlich die Meldung der Busybox kommen. Mir 
scheint der grasshopper findet die skripte für den init-Prozess nicht.

Zu Hause (das waren die Logs, die ich hier gepostet hatte):
Ich hatte ja vorher gesagt, dass ich nach einiger Zeit wilde Stack-Dumps 
bekomme. Das war allerdings nicht die ganze Wahrheit:
1. Vor den Dumps steht beim grasshopper
INFO: task ifconfig:730 blocked for more than 120 seconds.
2. Im Syslog des PCs findet sich als letztes
Sep 20 16:07:52 localhost dhcpd: DHCPDISCOVER from 00:0b:2b:12:33:a1 via eth2: network 192.168.12/24: no free leases

Das führt mich zu folgenden Vermutungen:
1. Mein Linux DHCP-Server beantwortet die DHCPDISCOVER nicht.
2. In der Firma: Der Umstand, dass ich keine Timeout-Meldungen bekomme, 
wenn ich das Kabel wieder aufstecke -> Die DHCPDISCOVER werden nicht von 
meinem DHCP-Server beantwortet sondern vom Firmen-DHCP (der grasshopper 
und der Firmen DHCP kennen sich, da ich beim booten schon öfter 
vergessen habe, das Kabel abzuziehen). Die Antworten des Firmen-DHCP 
bringen den grasshopper völlig durcheinander.

Die Datei /etc/dhcpd.conf sieht mittlerweile folgendermaßen aus:
allow bootp;
ddns-update-style none;
ddns-updates off;
ignore client-updates;

subnet 192.168.12.0 netmask 255.255.255.0 {
  default-lease-time 3600;
  max-lease-time 7200;

  #pool {
  #  deny unknown clients;
  #  range 192.168.12.20 192.168.12.254;
  #}

  group {
    #option routers 0.0.0.0;
    host grasshopper1 {
       hardware ethernet 00:1F:E5:00:03:96;
      fixed-address 192.168.12.2;
      #server-name "linux";
      server-identifier 192.168.12.1;
      next-server 192.168.12.1;
      option root-path "/home/Superandi/Avr32/rootfs";
      option host-name "grashopper1";
      filename "uImage";
    }
  }

}

Zur Info: Den Eintrag
ignore client-updates;
habe ich zu Hause schon mal auskommentiert / dhcpd neu gestartet hat 
aber nichts verändert.

OH NOOOO:
Ich glaube meine ach so tolle Vermutungen kann ich in die Tonne 
schmeißen: '00:0b:2b:12:33:a1' ist der Windows host (nicht wie vermutet 
der grasshopper!!!), der sich nicht mit seiner ZeroConf Adresse 
zufrieden gibt und ab und an nochmal anklingelt, um eine 'richtige' 
DHCP-Adresse zu bekommen.

Bleibt immer noch die Frage, warum der grasshopper sich hier anders 
verhält als in der Firma...

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@Tim: ich hoffe es kommt die Zeiten in denen ich mich für Deine
>Bemühungen revanchieren kann...

abwarten ;-) Außerdem sehe ich das hier als Dienst für die Linux 
Gemeinschaft :-)


Ich verwende folgende export zeile:
/srv/diskless  192.168.1.1/32(rw,no_root_squash,no_auth_nlm,nohide,async,no_subtree_check)

>Der grasshopper unter Linux kann mounten und ich kann mit ls auch
>alles sehen.

Poste mal ein ls -l vom grasshopper im gemounteten Verzeichnis
und das selbe aus /home/Superandi/Avr32/rootfs von deinem Server.

Sep 20 16:07:52 localhost dhcpd: DHCPDISCOVER from 00:0b:2b:12:33:a1 via eth2: network 192.168.12/24: no free leases
Die beschwerde ist normal da du keinen ip-pool (range) definiert hast.
INFO: task ifconfig:730 blocked for more than 120 seconds.
Bedeutet das der task ifconfig (welcher die Netzwerk Karten 
konfiguriert) seit meht als 120 sec die Maschine blockiert. Die frage 
ist nur: warum?

Die dhcpd.conf sieht gut aus. Der Hopper sollte damit zumindest bis zum
mounten vom root fs kommen. (sofern ip=dhcp)

Was mir noch aufgefalles ist.. der ip= eintrag von
bootargs=root=/dev/nfs nfsroot=192.168.12.1:/home/Superandi/Avr32/rootfs ip=192.168.12.2::192.168.12.1:::eth0:off console=ttyS0
entspricht nicht
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
(siehe <kernel-dir>/Documentation/filesystems/nfsroot.txt)
korrekt währe:
ip=192.168.12.2:192.168.12.1::255.255.255.0::eth0:off

Zu den unterschiedlichen Verhaltensweisen Firma/Privat
fällt mir im moment nix ein. ggf müsste man da mal mit einem
Netzwerk sniffer dran. iptraf könnte schon reichen.

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß jetzt was die Unterschiede zwischen meinen Umgebungen waren:
Irgendwo habe ich gelesen (ich glaube es war in Atmel Dokumenten), dass 
beim Boot mit NFS-RootFS in der Datei /etc/network die Zeile
auto eth0
 aus zu kommentieren sei. Das hatte ich auf der Arbeit gemacht hier im 
Keller nicht. Ich hab's mehrfach hin- und her probiert es ist 
reproduzierbar: Bleibt die Zeile, kommt der Timeout / ohne diese Zeile 
einfach nur hängen im Schacht...
Das ist eine nicht unwesentliche Erkenntnis: Der grasshopper bedient 
sich beim PC!
Zu den Inhalten des rootfs:
Auf dem PC:
ls -l /home/Superandi/Avr32/rootfs/
total 64
drwxr-xr-x 2 Superandi Superandi 4096 2008-09-07 22:34 bin
drwxrwxr-x 2 Superandi Superandi 4096 2008-08-28 00:45 boot
drwxr-xr-x 2 Superandi Superandi 4096 2008-02-03 13:48 config
drwxr-xr-x 6 Superandi Superandi 4096 2008-09-21 02:38 dev
drwxr-xr-x 5 Superandi Superandi 4096 2008-09-20 23:28 etc
drwxr-xr-x 3 Superandi Superandi 4096 2008-09-09 22:24 home
drwxr-xr-x 3 Superandi Superandi 4096 2008-09-07 22:34 lib
lrwxrwxrwx 1 Superandi Superandi   11 2008-09-10 00:49 linuxrc -> bin/busybox
drwxr-xr-x 2 Superandi Superandi 4096 2008-08-27 22:18 mnt
drwxr-xr-x 2 Superandi Superandi 4096 2008-08-27 22:18 opt
drwxr-xr-x 2 Superandi Superandi 4096 2008-08-27 22:18 proc
drwxr-xr-x 2 Superandi Superandi 4096 2008-08-27 22:18 root
drwxr-xr-x 2 Superandi Superandi 4096 2008-09-07 22:34 sbin
drwxr-xr-x 2 Superandi Superandi 4096 2008-02-03 13:48 sys
drwxrwxrwt 2 Superandi Superandi 4096 2008-08-27 22:18 tmp
drwxr-xr-x 7 Superandi Superandi 4096 2008-08-28 00:14 usr
drwxr-xr-x 4 Superandi Superandi 4096 2008-08-27 22:18 var

Vom grasshopper nach mount:
# mount 192.168.12.1:/home/Superandi/Avr32/rootfs /mnt
# ls -l /mnt
drwxr-xr-x    2 500      500          4096 Sep  7  2008 bin
drwxrwxr-x    2 500      500          4096 Aug 27  2008 boot
drwxr-xr-x    2 500      500          4096 Feb  3  2008 config
drwxr-xr-x    6 500      500          4096 Sep 20  2008 dev
drwxr-xr-x    5 500      500          4096 Sep 20  2008 etc
drwxr-xr-x    3 500      500          4096 Sep  9  2008 home
drwxr-xr-x    3 500      500          4096 Sep  7  2008 lib
lrwxrwxrwx    1 500      500            11 Sep  9  2008 linuxrc -> bin/busybox
drwxr-xr-x    2 500      500          4096 Aug 27  2008 mnt
drwxr-xr-x    2 500      500          4096 Aug 27  2008 opt
drwxr-xr-x    2 500      500          4096 Aug 27  2008 proc
drwxr-xr-x    2 500      500          4096 Aug 27  2008 root
drwxr-xr-x    2 500      500          4096 Sep  7  2008 sbin
drwxr-xr-x    2 500      500          4096 Feb  3  2008 sys
drwxrwxrwt    2 500      500          4096 Aug 27  2008 tmp
drwxr-xr-x    7 500      500          4096 Aug 27  2008 usr
drwxr-xr-x    4 500      500          4096 Aug 27  2008 var

Ach bevor ich's vergesse (darüber haben wir noch nicht gesprochen): Der 
Inhalt der Datei im RootFs /etc/fstab sieht folgendermaßen aus:
# <file system>         <mount pt>  <type>    <options>    <dump> <pass>
#/dev/root          /    jffs2    rw,noauto    0  1
/192.168.12.1:/home/Superandi/Avr32/rootfs  /    nfs    rw,noauto    0  1
proc            /proc    proc    defaults    0  0
devpts            /dev/pts  devpts    defaults,gid=5,mode=620  0  0
tmpfs            /tmp    tmpfs    defaults    0  0
none            /config    configfs  defaults    0  0
sysfs            /sys    sysfs    defaults    0  0

Ich habe lediglich die Zeile mit dem root Pfad überarbeitet.

Vielleicht sollte ich mich nach einer anderen Version von Buildroot 
umsehen? Meine war von der CD (als ich den grasshopper bestellt habe, 
habe ich nichts zum download gefunden - das hat sich jetzt geändert)

Und eine Frage hätte ich noch: Ich habe die Information zu den 
Bootargumenten
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
 nirgendwo direkt gefunden (immer nur ohne Erklärungen und schon 
ausgefüllt). Gibt es dazu Link(s)?

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Sache mit dem "auto eth0" verwirrt mich jetzt doch etwas...
Ich bin die ganze zeit davon ausgegangen das der Hopper unmittelbar
nach dem mounten des rootfs hängen bleibt (normalerweise sollte nach
dem mounten vom rootfs meldungen vom init bzw den initscripts kommen).
Scheint aber nicht so zu sein da er ja auf die veränderung der
Netzwerkeinstellungen reagiert.
Daher vermute ich (jetzt ;-) ein klassisches rechte Problem.
Die Dateien unter /home/Superandi/Avr32/rootfs/ gehören
Superandi:Superandi was der Hopper (mangels Eintrag in /etc/passwd und 
/etc/group) also 500:500 anzeigt. Normalerweise gehören die Dateien
im rootfs aber root:root (0:0). Könnte sein das sich das Ding
daran stört (ist nur eine Vermutung, habe mit der Busybox keine
so große Erfahrung).
Ich weiss nicht wo du das rootfs vom hopper her hast, aber du
solltest es mal, als root, vom original (ext2 image?) kopieren.
Z.b. nach /home/hopper oder so.

> Und eine Frage hätte ich noch: Ich habe die Information zu den
> Bootargumenten nirgendwo direkt gefunden (immer nur ohne Erklärungen
> und schon ausgefüllt). Gibt es dazu Link(s)?

nö. Aber in deinem Buildroot müssten ja auch die sourcen der Linux 
Kernel
sein (ansonsten kernel.org). Und da drin gibt es ein Verzeichnis
names Documentation. Als "index" für alle Parameter dient
kernel-parameters.txt.
GGf solltest du nach console=ttyS0 noch die Schnittstellenparameter
angeben, da der default "9600n8" ist und das getty mit 38400 fährt.

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
WE HAVE A LIFTOFF!!!

Habe das komplette RootFS vom grasshopper auf den PC kopiert (inklusive 
der Rechte/Besitzstände), /etc/fstabs überarbeitet, und - wie in [[AVR32 
Grasshopper]] beschrieben - die Datei /etc/rc.d/S10network.sh entfernt 
und siehe da: Ich kann booten. Durch Kopieren von Dateien konnte ich 
tatsächlich feststellen, dass ich per NFS unterwegs bin (ich hab dann 
auch direkt mal die ganzen nutzlosen tty-Prozesse entsorgt). Jetzt kann 
ich mal rumspielen und sehen, wie ich ein Skript erstelle, welches mir 
das RootFS in den freigegebenen Ordner kopiert und die Rechte so 
einstellt, wie sie später sein sollen (und alles immer noch läuft!).

Die nächsten Herausforderungen (da werde ich mich möglicherweise wieder 
melden :-O werden debugging (Applikationen) und das Einrichten von 
Eclipse (oder hat jemand einen besseren Vorschlag) aber erst mal 
rumspielen und freuen!!

@Tim: Noch eine letzte Frage (ich hab's wirklich versucht zu finden), 
die Dir sicherlich völlig den Rest geben wird: Wie macht man die grünen 
Zitate hier im Forum?

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> WE HAVE A LIFTOFF!!!

und wieder ein glücklicher Linuxianer ;-))

Dann man viel Spass beim Basteln!

> Wie macht man die grünen Zitate hier im Forum?

Genau so wie es angezeigt wird. Einfach
> am Anfang der Zeile.

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich fürchte beim 'rumspielen' sind mir einige Dinge aufgefallen, die ich 
bisher nicht klären konnte:

1. Das Verzeichnis /dev: Hier muss ich die Original-(Geräte-)Dateien aus 
dem grasshopper verwenden sonst bootet der Kleine nicht. Bei der Suche 
nach der Ursache ist mir folgendes aufgefallen: Schaue ich mir die 
Dateien mit nautilus (Klikibunti - mein neues Lieblingswort) an und 
betrachte den Typ der Datei fällt auf, dass in dem Buildroot RootFS die 
Typen der Dateien mit 'plain text document' oder 'unknown' angezeigt 
werden. Die Dateien, die ich vom grasshopper kopiert habe, haben alle 
den Typ 'x-special/device-char' oder 'x-special/device-block' so wie 
sich dass für anständige Gerätedateien wohl zu gehören scheint. Was ist 
zu tun, damit der grasshopper die von Buildroot angebotenen Dateien 
frisst? Bei meiner Suche bin ich bisher nur auf MAKEDEV gestoßen, was 
aber - wenn ich es richtig verstanden habe - die device Dateien neu 
anlegt.
2. Wenn ich mich als 'default' anmelde, und mit 'su' zum root wechseln 
möchte, kommt die Meldung 'su applet requires root privileges". Melde 
ich mich direkt als 'root' an, funktioniert dies ohne Fehlermeldung. Die 
Suche nach der Meldung führt zu folgender Sequenz in der Datei 
(...)/build_avr32/busybox-1.5.0/applets/applets.c:
  if (applet->need_suid == _BB_SUID_ALWAYS) {
    if (geteuid()) bb_error_msg_and_die("applet requires root privileges!");
  } else if (applet->need_suid == _BB_SUID_NEVER) {
    xsetgid(rgid);                          /* drop all privileges */
    xsetuid(ruid);
  }
Es sieht wieder so aus, als ob ich wieder ein Problem hätte mit den 
Rechten. Zur Info: Auf dem grasshopper ist der Benutzer 'default' mit 
den Benutzer/Gruppen IDs 1000:1000 vorinstalliert. Muss mein PC diesen 
Benutzer  kennen? Wenn ja: Wie richte ich das ein? Einfach auf dem PC 
die Dateien '/etc/passwd' und '/etc/group' überarbeiten und hoffen, dass 
alles noch läuft? Und noch eine Frage: In dem Quellcode sieht es so aus, 
als ob es noch eine EUID gibt. Ich habe den Begriff gegooglet: So 
richtig habe ich das nicht verstanden, was dort gelesen habe. Bisher 
kannte ich nur UID und GID.

Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist auch schon aufgefallen, daß nach einigem Spielen das 
dev-Verzeichnis "kaputtgegangen" ist. Die Dateien wurden als normale 
Dateien angelegt, nicht device nodes. Genauso werden diese dann auch in 
das Rootfs-Image abgelegt und so funktioniert es natürlich nicht.

Ich habe dann noch eine zweite Buildroot-Umgebung heruntergeladen und 
diese einfach nach ...build_avr32/root/dev rüberkopiert, damit war das 
Problem behoben.

Vermutlich ist das ein Rechte-Problem und das Buildskript kann als 
normaler Benutzer keine device nodes anlegen oder so... keine Ahnung.

Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem mit su hatte ich übrigens auch schon. Nur, daß ich mich 
nicht als Root einloggen konnte. Ich habe dann direkt in eine Shell 
gebootet und ein neues Rootfs-Image aufgespielt, dann ging es wieder.

Das Insekt frisst meine Zeit auf!!!

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gerhard:
>Ich habe dann direkt in eine Shell
>gebootet und ein neues Rootfs-Image aufgespielt, dann ging es wieder.

Wie ich weiter oben schon gesagt habe: Ich bin Anfänger (und fresse im 
Moment jegliche Information in mich rein, die zu bekommen ist). Daher 
meine Frage: Was genau hast Du getan?

Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du den Grasshopper am USB-Port hast und ein Terminalprorgamm läuft, 
kannst du zur U-Boot-Befehlszeile, wenn du rechtzeitig die Leertaste 
drückst.

Dann mit printenv die Umgebungsvariablen aufrufen

Die Zeile mit bootargs anschauen, das sind die Parameter, die beim 
Booten an den Kernel übergeben werden. Zum Beispiel das Layout des 
Flash-Speichers und wo er das Root-Image findet. Da das Kopieren der 
bootargs nicht funktioniert, habe ich es folgendermaßen gemacht:

set bootargs '(dann den originalen Kram abgeschrieben) init=/bin/sh'

Dann "boot" tippen und das Insekt startet...

Mit init= teilt man dem Kernel mit, welches Programm er nach dem Starten 
ausführen soll. Normalerweise ist das /bin/init, welches dann anhand der 
Konfigurationsdateien /etc/inittab und der Skripte in /etc/rc.d das 
System konfiguriert, also alles das tut, was der Kernel noch nicht kann. 
Netzwerkeinstellungen, Gettys starten, Daemons starten usw.

Gibt man init=/bin/sh an, startet man direkt eine Shell, in der man dann 
natürlich root ist. So kann man das Rechte-Problem umgehen und Probleme 
fixen. Braucht man das Netzwerk, einfach mit /etc/rc.d/networking start 
das entsprechende Skript laufen lassen.

Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst ein neues Image folgendermaßen aufspielen, das ist aber 
gefährlich!

Erstmal muß das /tmp-Dateisystem (das liegt im RAM) gemountet werden. 
Dann mit

mount -o remount,ro /

das Root-System readonly mounten, damit nicht versucht wird, während des 
Updatens darauf zu schreiben, dann wäre das Insekt ziemlich kompliziert 
zu reparieren... Du müsstest dann aus u-Boot über's Netz sowohl Kernel 
als auch Dateisystem laden, was mir bisher noch nie gelungen ist.

Anschließend das neue Image auf den Grasshopper laden, ich mache das 
über http, weil auf meinem PC eh ein Apache läuft...

cd /tmp
wget http://192.168.1.100/rootfs.avr32.jffs2

Achtung: Das rootfs muß ein ungepacktes Image sein und im 
jffs2-Dateisystem. Vorher unbedingt das Image anschauen, ob es in 
Ordnung ist (device nodes in /dev?)!

Dann einfach mutig mit

dd if=/tmp/rootfs.avr32.jffs2 of=/dev/mtdblock2 bs=64k

das Flash schreiben. Nicht ausschalten, nichts sonstiges machen, bis der 
Prompt wieder erscheint. Dann einfach resetten und hoffen, daß alles 
funktioniert.

Wichtig ist auch, daß im Image ein funktionsfähiger Kernel vorhanden 
ist, denn den überschreibst du natürlich auch!

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gerhard:

1. Danke für die Info (bootargs: init=/bin/sh). Habe übrigens init bei 
mir nicht gesetzt und vermute daher, dass "/bin/init" default ist.
2.
>Du müsstest dann aus u-Boot über's Netz sowohl Kernel
>als auch Dateisystem laden, was mir bisher noch nie gelungen ist.
Das genau ist Thema dieses Threads (BootP/NFS auf directory und das 
funktioniert bis auf die letzen Einwände sehr gut), allerdings glaube 
ich hatte ich noch nicht den Inhalt der Datei /etc/xinetd.d/tftp 
angegeben:
service tftp
{
  disable      = no
  socket_type    = dgram
  protocol    = udp
  wait      = yes
  user      = root
  server      = /usr/sbin/in.tftpd
  server_args    = -s /home/Superandi/Avr32/ICNovaBaseCD/ICnova_base/build_avr32/root/boot
  per_source    = 11
  cps      = 100 2
  flags      = IPv4
}

Wichtig ist, dass xinetd läuft und /etc/dhcpd.conf die korrekten 
Einträge hat (siehe oben).

Vor einem Flash-Update möchte ich mich erst mal weit fernhalten...

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Thema /dev:
Nur root darf neue device files anlegen.
(Sonst könnte sich ja jeder User zugriff auf die Hardware verschaffen.)

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Nur root darf neue device files anlegen.
Das habe ich mir auch gedacht, habe Buildroot nochmal frisch vom root 
kompilieren lassen aber kein Unterschied: Die meisten der device files 
sind nach wie vor vom Typ 'unknown' bzw. 'plain text document'. Nebenbei 
wird in der Buildroot Dokumentation relativ am Anfang als eines der 
großen Highlights angegeben, dass root Rechte nicht von Nöten seien 
(apropos was ist eigentlich fakeroot?)
Bei meinen Recherchen bin ich über devfs gestolpert: Dies wird seit 
Kernel Version 2.6 nicht mehr unterstützt. Habe ich in Buildroot in den 
Tiefen von make menuconfig eine Einstellmöglichkeit, um zu beeinflussen 
wie die Gerätedateien angelegt werden?

Autor: Daniel B. (dbuergin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Mische mich jetzt auch noch ein. Vom Grasshoper verstehe ich (noch) 
nichts, bin ein bisschen am beobachten wie die Community damit zufrieden 
ist.

Aber von Unix verstehe ich ein klein bisschen ;-)

Desshalb mal was zu den Device Files im /dev Verzeichnis. Eines der 
Hauptmerkmale eines Unix Systems ist die Tatsache, dass (fast) alles ein 
File ist. Sowohl die Programme, die Daten als eben auch die Hardware 
werden in Form von Files repräsentiert. Und genau dies sind die dev... 
Files, nämlich die Möglichkeit, auf die Hardware zuzugreifen.
Ein Devicefile hat keinen Inhalt. Es hat auch keine Typ, desshalb weiss 
auch ein "Klickibunti" Tool nichts damit anzufangen.

Wichtig sind vier Sachen:
- Ob es ein Character (c) oder Blockdevice (b) ist
- Die "Major-Number"
- Die "Minor-Number"
- Die Rechte, welches das entsprechende File hat.

Ein Beispiel:

>ls -l /dev/sda*
brw-rw---- 1 root disk 8, 0 2008-09-24 20:52 /dev/sda
brw-rw---- 1 root disk 8, 1 2008-09-24 20:52 /dev/sda1

Der erste Buchstabe "b" sagt aus, dass es ein Blockdevice ist. Dannach 
kommen die Zugriffsrechte "rw-rw----". Nun folgen die Berechtigungen 
"root disk". Hier können auch Nummern stehen, wenn die dazugehörenden 
Namen im /etc/passwd (root) und /etc/group (disk) fehlen würden, was 
aber nicht gut wäre. Nun kommt die "8", welches die sog. Major-Number 
ist und dannach die "0" oder "1" als Minor-Number.
Grob gesagt definiert die Major-Number welchen Driver der Kernel für 
dieses Gerät verwenden soll und die Minor-Number gibt dem Kernel weitere 
Details zu dem verwendeten Gerät.

Erstellt werden Devicefiles mit dem Befehl "mknod".

Noch was zu den Berechtigungen. Auf einem Unix hat ein User im 
Normalfall eine UserID und eine GroupID. Beides sind Nummern ! Erst die 
Einträge im /etc/passwd und im /etc/group machen aus den Nummern Namen. 
Dies ist einzig und allein damit wir Menschen es besser lesen können.

Ich habe nun nicht ganz verstanden, wo nun genau das /dev Verzeichnis 
des Grasshopers liegt. Auf dem PC unter Unix oder unter Windows ? Ich 
hoffe unter Unix ;-) . Wichtig ist hier, dass die Berechtigungen (root 
disk im obigen Beispiel) mit dem /etc/passwd und /etc/group auf dem 
Grasshoper übereinstimmen. Also KEINE Aenderungen auf dem PC in diesem 
Verzeichnis machen ! Auf dem Grasshoper sollte das /dev bei den meisten 
Files "root root" o.ä. zeigen. Wenn dort nur Nummern stehen, ist etwas 
falsch gegangen. Dann hilft ev. ein:
>chown -R root /dev
>chgrp -R root /dev

Im Normalfall sollte man das /dev Verzeichnis nur als TAR Archiv in der 
Gegend rum kopieren. Als auf dem Ausgangsrechner:
>cd /
>tar -cvf dev.tar dev

Nun das dev.tar File auf den Zielrechner kopieren und dort:

>cd xyz
>tar -xvf dev.tar

Nun hat man im aktuellen Verzeichnis das dev Verzeichnis.

Hoffe das hilft ein bisschen.

Gruss

Daniel

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe eine VM mit Linux Fedora 8 und möchte, Soft- und Hardware für 
den grasshopper entwickeln. Ich habe den grasshopper mit CD bestellt. 
Auf dieser befindet sich eine vorbereitete Buildroot-Umgebung, die - 
wenn ich das richtig verstehe - alles erstellt, was der kleine so 
braucht: Kernel und das Rootfs. Nun möchte ich für ein geschmeidiges 
Entwickeln, dass der Hüpfer sich beim booten und im Betrieb komplett 
beim PC bedient: Der Kernel wird per TFTP geladen (das macht keine 
Probleme) und das Rootfs mit NFS gemountet. Noch nicht erwähnt habe ich, 
dass ich nicht direkt in das root Verzeichnis von Buildroot mounte, 
sondern in ein Verzeichnis, welches root::root gehört und die Rechte 
'drwrwxrwx' hat. Grund dafür, dass ich eine Kopie erstelle ist, dass ich 
vermeiden möchte, dass die Dateien, die der kleine während seines 
Betriebs erstellt bzw. ändert, in Buildroot verbleiben. Das make von 
Buildroot möchte ich eigentlich nicht als root ausführen. Da dann die 
meisten Dateien, die Buildroot erzeugt Besizer/Gruppe 500:500 (der Zwerg 
kennt diese UID:GID nicht) erhalten, habe ich folgendes Skript erstellt:
#! /bin/sh
#1.
CMDLN_ARGS="$@" # Command line arguments for this script
export CMDLN_ARGS
# Run this script as root if not already.
chk_root () {
  if [ ! $( id -u ) -eq 0 ]; then
    echo "Please enter root's password."
    exec su -c "${0} ${CMDLN_ARGS}" # Call this prog as root
    exit ${?}  # sice we're 'execing' above, we wont reach this exit
               # unless something goes wrong.
  fi
}
# Call this function early on - now or before your script's main loop 
# starts.
chk_root

#2.
#setup folders
BUILDROOT_FS="/home/Superandi/Avr32/ICNovaBaseCD/ICnova_base/build_avr32/root"
ROOT_FS="/home/Superandi/Avr32/rootfs"
ROOT_FS_REF="/home/Superandi/Avr32/rootfs_reference"
#delete old contents
rm -rf $ROOT_FS/*
# copy all from buildroot
cp -a $BUILDROOT_FS/* $ROOT_FS

#3.
# change owner for all files
chown -R root:root $ROOT_FS/*
# change owner home default user
chown -R 1000:1000 $ROOT_FS/home/default

#4.
#remove device entries
rm -rf $ROOT_FS/dev
#copy reference devie files
cp -a $ROOT_FS_REF/dev/ $ROOT_FS

Zur Erklärung:
1. als root anmelden
2. Rootfs kopieren
3. UID:GID ändern
4. /dev überschreiben (mit den Nodes, die ich mir aus dem grasshopper 
kopiert habe)

Diese Vorgehensweise bringt den grasshopper zum humpeln ist aber 
sicherlich KEINE akzeptable Lösung weil:
1. Ich glaube nicht das die Erfinder von buildroot das so gedacht haben 
:-)
2. Die Besitzer/Gruppen werden hierdurch nur 'grob' eingerichtet. 
Sicherlich gibt es Dateien, die falsche Einstellungen bekommen. Es kann 
nicht der Weg sein jetzt alle Dateien zu überprüfen und das Skript 
aufzublähen. Die falschen Besitzer/Gruppen sind bestimmt auch die 
Ursache für mein Problem mit 'su' (siehe oben). Wenn ich das RootFS 
mounte, welches ich vom grasshopper kopiert habe, läuft der kleine 
fehlerfrei (zumindest habe ich noch keinen Fehler bemerkt).
3. Die von Buildroot erzeugten Gerätedateien (=Vorlagen?) werden 
komplett ignoriert.

Was mich ein bisschen wundert: Ist das so abwegig was ich vorhabe? Ich 
habe oft gesehen, dass Leute ext2 oder sonstige RootFS mounten, die in 
Dateien vergraben sind: Dadurch verliere ich einen wesentlichen Teil an 
Flexibilität: Ich möchte nicht nach jeder kleinen Änderung neu booten 
müssen. Verstehe ich hier was falsch?

Autor: Daniel B. (dbuergin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar, solche Sachen macht man immer wieder. Letzte Woche habe ich einen 
Solaris Server eingerichtet, welcher einem AIX Server seine gesamte 
Boot-Umgebung per NFS zur Verfügung stellt.

Das Vorgehen, so wie es im Artikel: 
http://www.mikrocontroller.net/articles/AVR32_Grasshopper steht, sollte 
eigentlich ok sein.

Im Buildroot Verzeichnis:

>make menuconfig

Dannach hast du im File rootfs.avr32.ext das besagte Root Filesystem. 
Dieses kannst du nun extrahieren und dem Hopper per NFS zur Verfügung 
stellen. Ich würde das folgendermassen machen:

>mount -o loop rootfs.avr32.ext /mnt
>cd /mnt
>tar cvf /tmp/rootfs.tar *
>cd /home/Superandi/Avr32/rootfs
>tar xvf /tmp/rootfs.tar

Ich hoffe, ich habe es richtig verstanden. Das Verzeichnis 
/home/Superandi/Avr32/rootfs ist das, welches du via NFS dem Grasshopper 
geben willst oder ? Sicherstellen, dass vor dem extrahieren via tar, das 
Verzeichnis leer ist.

Nichts an den Berechtigungen oder Ownerships ändern oder so. Dies sollte 
so eingestellt sein, dass der Grasshopper damit zurecht kommt. Sonst ist 
die Buildroot-Umgebung komisch aufgesetzt.

Wie gesagt, das Ganze ohne Gewähr, da ich selber keinen Grasshopper habe 
(ev. noch nicht) ;-)

Autor: SiO2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die dev files in der buildroot sind plaintextfiles. Im ext-Archiv sind 
es dann echte.

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh Mann ich bin einfach zu blöd (oder zu stur)...
Es gab mindestens zwei Dinge, die ich in dem Artikel [[AVR32 
Grasshopper]] nicht verstanden hatte:
1. Loop devices: mount -o loop rootfs.avr32.ext2 /mnt bringt mir den 
Zugriff in das Rootfs (also genau das was ich wollte). Das schöne daran 
ist, dass ich den verwendeten Speicherbereich vorgeben kann und dadurch 
einen Überblick habe, ob das was ich in Buildroot veranstalte noch ins 
Flash passen würde:
2. Da Buildroot nach der Installation jffs2 erzeugt, habe ich die Endung 
ext2 für einen Schreibfehler gehalten. Das hatte ich versiucht zu 
mounten hatte damit aber keinen Erfolg. Darauf, dass das mit make 
menuconfig einzustellen ist, bin ich nicht gekommen.

Man muss es positiv sehen: Ich habe die letzten Wochen viel gelernt 
unter anderem auch, dass es eine Menge geduldiger Leute da draussen 
gibt...

Danke an alle!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.