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:
da ich Informationen über DHCP beziehe:
/etc/dhcpd.conf:
1
#configuration dhcp-server
2
3
allow bootp;
4
ddns-update-style none;
5
ddns-updates off;
6
7
subnet 192.168.12.0 netmask 255.255.255.0 {
8
default-lease-time 1209600;
9
max-lease-time 31557600;
10
option subnet-mask 255.255.255.0;
11
server-identifier 192.168.12.1;
12
13
group {
14
#server-name "linux";
15
#option routers 0.0.0.0;
16
next-server 192.168.12.1;
17
option root-path "/home/Superandi/AVR32/rootfs";
18
option host-name "grashopper1";
19
filename "uImage";
20
21
host grasshopper1 {
22
hardware ethernet 00:1F:E5:00:03:96;
23
fixed-address 192.168.12.2;
24
}
25
}
26
}
27
#end of file
/etc/sysconfig/nfs:
1
#
2
# Define which protocol versions mountd
3
# will advertise. The values are "no" or "yes"
4
# with yes being the default
5
#MOUNTD_NFS_V1="no"
6
#MOUNTD_NFS_V2="no"
7
#MOUNTD_NFS_V3="no"
8
#
9
# Path to remote quota server. See rquotad(8)
10
RQUOTAD="/usr/sbin/rpc.rquotad"
11
# Port rquotad should listen on.
12
RQUOTAD_PORT=875
13
# Optinal options passed to rquotad
14
#RPCRQUOTADOPTS=""
15
#
16
# TCP port rpc.lockd should listen on.
17
LOCKD_TCPPORT=32803
18
# UDP port rpc.lockd should listen on.
19
LOCKD_UDPPORT=32769
20
#
21
# Optional arguments passed to rpc.nfsd. See rpc.nfsd(8)
22
#RPCNFSDARGS
23
# Number of nfs server processes to be started.
24
# The default is 8.
25
RPCNFSDCOUNT=8
26
#
27
# Optional arguments passed to rpc.mountd. See rpc.mountd(8)
28
#RPCMOUNTDOPTS=""
29
# Port rpc.mountd should listen on.
30
MOUNTD_PORT=892
31
#
32
# Optional arguments passed to rpc.statd. See rpc.statd(8)
33
STATDARG="--name localhost"
34
# Port rpc.statd should listen on.
35
STATD_PORT=662
36
# Outgoing port statd should used. The default is port
37
# is random
38
STATD_OUTGOING_PORT=2020
39
# Specify callout program
40
#STATD_HA_CALLOUT="/usr/local/bin/foo"
41
#
42
# Optional arguments passed to rpc.idmapd. See rpc.idmapd(8)
43
#RPCIDMAPDARGS=""
44
#
45
# Set to turn on Secure NFS mounts.
46
#SECURE_NFS="yes"
47
# Optional arguments passed to rpc.gssd. See rpc.gssd(8)
48
#RPCGSSDARGS=""
49
# Optional arguments passed to rpc.svcgssd. See rpc.svcgssd(8)
50
#RPCSVCGSSDARGS=""
51
#
/etc/sysconfig/rpcbind:
1
# Optional arguments passed to rpcbind. See rpcbind(8)
2
RPCBIND_ARGS="-l"
Firewalls sind abgeschossen bzw. deaktiviert. SeLinux habe ich ruhig
gestellt in /etc/selinux/config:
1
# This file controls the state of SELinux on the system.
2
# SELINUX= can take one of these three values:
3
# enforcing - SELinux security policy is enforced.
4
# permissive - SELinux prints warnings instead of enforcing.
5
# disabled - No SELinux policy is loaded.
6
SELINUX=disabled
7
# SELINUXTYPE= can take one of these two values:
8
# targeted - Targeted processes are protected,
9
# mls - Multi Level Security protection.
10
SELINUXTYPE=targeted
11
# SETLOCALDEFS= Check local definition changes
12
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
1
mount 192.168.12.1:/home/Superandi/Avr32/rootfs /mnt
bekomme ich nach einiger Zeit die Meldungen:
1
rpcbind: server localhost not responding, timed out
2
RPC: failed to contact local rpcbind server (errno 5).
3
rpcbind: server localhost not responding, timed out
4
RPC: failed to contact local rpcbind server (errno 5).
5
lockd_up: makesock failed, error=-5
6
rpcbind: server localhost not responding, timed out
7
RPC: failed to contact local rpcbind server (errno 5).
8
mount: mounting 192.168.12.1:/home/Superandi/Avr32/rootfs on /mnt failed
Auf dem PC sehe ich in /var/log/messages:
1
Sep 15 13:14:20 localhost rpcbind: connect from 192.168.12.2 to dump()
2
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)
3
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
Die gleiche Anfrage ohne Angabe 'localhost' ergibt das erwartete
Ergebnis:
1
[root@localhost Superandi]# rpcinfo -p
2
program vers proto port service
3
100000 4 tcp 111 portmapper
4
100000 3 tcp 111 portmapper
5
100000 2 tcp 111 portmapper
6
100000 4 udp 111 portmapper
7
100000 3 udp 111 portmapper
8
100000 2 udp 111 portmapper
9
100000 4 0 111 portmapper
10
100000 3 0 111 portmapper
11
100000 2 0 111 portmapper
12
100024 1 udp 662 status
13
100024 1 tcp 662 status
14
100011 1 udp 875 rquotad
15
100011 2 udp 875 rquotad
16
100011 1 tcp 875 rquotad
17
100011 2 tcp 875 rquotad
18
100021 1 udp 32769 nlockmgr
19
100021 3 udp 32769 nlockmgr
20
100021 4 udp 32769 nlockmgr
21
100021 1 tcp 32803 nlockmgr
22
100021 3 tcp 32803 nlockmgr
23
100021 4 tcp 32803 nlockmgr
24
100003 2 udp 2049 nfs
25
100003 3 udp 2049 nfs
26
100003 4 udp 2049 nfs
27
100003 2 tcp 2049 nfs
28
100003 3 tcp 2049 nfs
29
100003 4 tcp 2049 nfs
30
100005 1 udp 892 mountd
31
100005 1 tcp 892 mountd
32
100005 2 udp 892 mountd
33
100005 2 tcp 892 mountd
34
100005 3 udp 892 mountd
35
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
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.
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!
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...
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
1
rpcbind:127.0.0.1
/etc/hosts.deny
1
rpcbind:ALL
2
mountd:ALL
3
lockd:ALL
4
rquotad:ALL
5
statd:ALL
Der grasshopper soll sich nicht verbinden - tut er denn auch nicht:
1
# mount -t nfs 192.168.12.1:/home/Superandi/Avr32/rootfs /mnt
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
1
#rpcbind:ALL
2
#mountd:ALL
3
lockd:ALL
4
rquotad:ALL
5
statd:ALL
Es kommt zu ewig langem Warten beim Grasshopper und dann Fehlermedlungen
wie oben
1
rpcbind: server localhost not responding, timed out
2
RPC: failed to contact local rpcbind server (errno 5).
und der PC tut, als ob nichts böses passiert sei:
1
Sep 16 01:28:03 localhost rpcbind: connect from 192.168.12.2 to dump()
2
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)
3
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..
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)
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
1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
2
listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes
3
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>
Sep 16 10:15:34 localhost dhcpd: DHCPINFORM from 192.168.7.101 via eth2: unknown subnet for address 192.168.7.101
3
Sep 16 10:15:43 localhost rpcbind: connect from 192.168.12.2 to dump()
4
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)
5
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)
6
Sep 16 10:15:49 localhost rpcbind: connect from 192.168.12.2 to getport/addr(nfs)
7
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?
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)
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.
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?
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:
1
rpcbind: server localhost not responding, timed out
2
RPC: failed to contact local rpcbind server (errno 5).
"failed to contact local rpcbind server" war hier der
berühmte Wink mit dem Zaunpfahl.
@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
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?
>@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....
@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:
1
ICNova>DHCP
2
macb0: Starting autonegotiation...
3
macb0: Autonegotiation complete
4
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
5
BOOTP broadcast 1
6
DHCP client bound to address 192.168.12.2
7
Using macb0 device
8
TFTP from server 192.168.12.1; our IP address is 192.168.12.2
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.
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...
nfs: server 192.168.12.1 not responding, still trying
2
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?
1
773 root 1264 S /sbin/getty 38400 tty1
2
775 root 1264 S /sbin/getty 38400 tty2
3
778 root 1264 S /sbin/getty 38400 tty3
4
781 root 1264 S /sbin/getty 38400 tty4
5
783 root 1264 S /sbin/getty 38400 tty5
6
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.
@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.
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
1
INFO: task ifconfig:730 blocked for more than 120 seconds.
2. Im Syslog des PCs findet sich als letztes
1
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:
1
allow bootp;
2
ddns-update-style none;
3
ddns-updates off;
4
ignore client-updates;
5
6
subnet 192.168.12.0 netmask 255.255.255.0 {
7
default-lease-time 3600;
8
max-lease-time 7200;
9
10
#pool {
11
# deny unknown clients;
12
# range 192.168.12.20 192.168.12.254;
13
#}
14
15
group {
16
#option routers 0.0.0.0;
17
host grasshopper1 {
18
hardware ethernet 00:1F:E5:00:03:96;
19
fixed-address 192.168.12.2;
20
#server-name "linux";
21
server-identifier 192.168.12.1;
22
next-server 192.168.12.1;
23
option root-path "/home/Superandi/Avr32/rootfs";
24
option host-name "grashopper1";
25
filename "uImage";
26
}
27
}
28
29
}
Zur Info: Den Eintrag
1
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...
>@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:
>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.
1
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.
1
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
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.
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
1
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:
1
ls -l /home/Superandi/Avr32/rootfs/
2
total 64
3
drwxr-xr-x 2 Superandi Superandi 4096 2008-09-07 22:34 bin
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
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.
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?
> 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.
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:
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.
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.
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!!!
@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?
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.
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!
@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:
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...
>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?
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
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:
1
#! /bin/sh
2
#1.
3
CMDLN_ARGS="$@"# Command line arguments for this script
4
export CMDLN_ARGS
5
# Run this script as root if not already.
6
chk_root (){
7
if[!$(id-u)-eq 0 ];then
8
echo"Please enter root's password."
9
exec su -c"${0}${CMDLN_ARGS}"# Call this prog as root
10
exit${?}# sice we're 'execing' above, we wont reach this exit
11
# unless something goes wrong.
12
fi
13
}
14
# Call this function early on - now or before your script's main loop
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?
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) ;-)
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!
Thread beobachten
Seitenaufteilung abschalten