Problem mit USB / swap

[Frank_at_iphone]

Hi Ralf,

also unterhalb von build/modified/filesystem ist kein 'sys' oder 'sysfs' als File oder Link oder Directory

Im build/modified/filesystem/var.tar ist ./var/sysfs enthalten. Das ist ein symbolische Link auf ../sys


Beim auspacken von var.tar auf meiner Debian Box erscheint eine Fehlermeldung

/tmp$ tar xvf var.tar

./var/mod/etc/
./var/mod/etc/conf/
./var/mod/etc/init.d/
./var/mod/etc/reg/
./var/sysfs
tar: .: Cannot utime: Operation not permitted
tar: Exiting with failure status due to previous errors

Heute abend geht es weiter! Schoenen Tag!

 

[olistudent]

Moin.
Wie siehts denn im Verzeichnis freetz-.../root auf dem PC aus?

MfG Oliver

 

[ryazor]

Ich hatte das selbe Problem, allerdings benutzt du den Stick ja nicht für USB-Root, deshalb hilft dir meine Lösung wahrscheinlich nicht.

Da mein Stick das gesamte Filesystem beinhaltet + Swapfile, muss ich den Stick vorerst beschreibbar machen. Dafür habe ich in der rc.custom folgenden Eintrag:

# make usb-root writeable
mount -o remount -w /

Wie gesagt, hat mir nur was gebracht, da der Stick als USB-Root Medium genutzt wird, ich denke mal, dadurch dass du den Stick als "normales" Speichermedium bentuzt, wird er so oder so schon als "writeable" gemounted.

Gruß, r.

 

[Frank_at_iphone]

Hi,

@ryazor Die Files die Fehlen sind nicht auf dem Stick, sondern im 'Flash' der Fritzbox

@oliver
ein root Verzeichnis ist vorhanden:

$ find build -name root
build/modified/kernel/var.tar/var/mod/root

 ls -alrt build/modified/kernel/var.tar/var/mod/root
total 8
lrwxrwxrwx  1 frank frank   23 Jan 12 23:19 .profile -> /tmp/flash/mod/.profile

 

[olistudent]

Sorry, hab mich undeutlich ausgedrückt.

Ich hätte gerne das hier:

~/freetz/trunk_3170$ ls -al root/
total 36
drwxr-xr-x  9 oliver oliver 4096 2010-02-03 14:29 .
drwxr-xr-x 17 oliver oliver 4096 2010-02-03 21:46 ..
drwxr-xr-x  3 oliver oliver 4096 2009-10-24 14:17 bin
drwxr-xr-x  7 oliver oliver 4096 2010-01-08 15:10 etc
drwxr-xr-x  2 oliver oliver 4096 2010-02-03 14:31 lib
drwxr-xr-x  3 oliver oliver 4096 2009-10-24 14:17 sbin
drwxr-xr-x  6 oliver oliver 4096 2010-02-03 21:43 .svn
drwxr-xr-x  3 oliver oliver 4096 2009-10-24 14:17 sys
drwxr-xr-x  8 oliver oliver 4096 2009-10-24 14:17 usr

MfG Oliver

 

[Frank_at_iphone]

Hi,

bei mir fehlt da sys:

$ ls -al root
total 28
drwxr-xr-x  7 frank frank 4096 Jan 11 15:19 .
drwxrwxrwx 18 frank frank 4096 Feb  2 19:34 ..
drwxrwxrwx  2 frank frank 4096 Sep 12 22:23 bin
drwxrwxrwx  6 frank frank 4096 Jan 11 13:15 etc
drwxr-xr-x  2 frank frank 4096 Jan 11 15:19 lib
drwxrwxrwx  2 frank frank 4096 Sep 12 22:23 sbin
drwxrwxrwx  7 frank frank 4096 Aug  9 13:43 usr

 

[olistudent]

Wie hast du freetz denn da hinbekommen? Runtergeladen, aus dem svn ausgecheckt? Wie?

Am Besten fängst du nochmal von vorne an...

MfG Oliver

 

[Frank_at_iphone]

Hi,

es sollte revision 4187 aus subversion sein, allerdings sind bei mir alle leeren Directories entsorgt.

Ich habe als 'frontend' zu subversion git-svn benutzt, damit ich meine privaten Aenderungen wie z.B. '.config' einchecken kann.

Dabei wird anscheinend auch 'sauber' gemacht aehnlich wie bei "cvs up -P" Ich hatte mich schon häufig über die .empty Files in einigen Projekten gewundert.


Danke fuer eure Hilfe!



Ich habe jetzt gezählt und diese leeren Directories gefunden:

$ find . -empty -type d
./make/quagga/files/root/usr/sbin
./make/quagga/files/root/usr/bin
./make/pptp/files/root/usr/sbin
./make/lighttpd/patches
./make/vsftpd/files/root/usr/sbin
./make/haserl/patches
./make/apache/files/logs
./make/apache/files/root
./make/sg3_utils/patches
./make/rrdtool/patches
./make/netsnmp/files/root/usr/sbin
./make/netcat/patches
./make/rcapid/files/root/usr/sbin
./make/jamvm/files/root/usr/lib
./make/jamvm/files/root/usr/share/classpath
./make/jamvm/files/root/usr/bin
./make/collectd/files/root/usr/bin
./make/privoxy/files/root/usr/sbin
./make/dnsmasq/files/root/usr/sbin
./make/inadyn-mt/files/root/usr/sbin
./make/usbroot/files/root/oldroot
./make/usbroot/files/root/data
./make/ser2net/files/root/usr/sbin
./make/bip/patches
./make/tor/files/root/usr/sbin
./make/tinyproxy/files/root/usr/sbin
./make/mini_fo/files/root/sto
./make/bftpd/files/root/usr/sbin
./make/bird/files/root/usr/sbin
./make/matrixtunnel/patches
./make/stunnel/files/root/usr/sbin
./make/sablevm-sdk/files/root/usr/lib/sablevm-classpath
./make/sablevm-sdk/files/root/usr/share/sablevm-classpath
./make/pptpd/files/root/usr/sbin
./make/debootstrap/patches
./make/openntpd/files/root/usr/sbin
./make/vpnc/files/root/sbin
./make/openvpn/files/root/usr/sbin
./make/checkmaild/files/root/usr/sbin
./make/iptraf/files/var.tar/var/log/iptraf
./make/iptraf/files/var.tar/var/run/iptraf
./root/sys

Könnte man die nicht auch in einem der Makefiles anlegen?

-mkdir -p ${EMPTY_DIRS}

Ist aber auch nur so mittel schoen.

Frank

 

[hermann72pb]

@Frank: Wenn Tausende vor dir nie auf solche Ideen gekommen sind, dann deutet es für mich stark darauf, dass du daran selber schuld bist, irgendwelche Sachen zu verwenden, von deren Existenz bei dir wir überhaupt keine Ahnung haben und die in keiner der Anleitungen stehen. Warum sollen deine Sonderwünsche berücksichtigt werden, wenn sie bis jetzt keiner vermisst hat?

MfG

 

[Silent-Tears]

Ich bezweifle, dass wir wegen ein paar leeren Verzeichnissen, die bei deinem Sondernkonstrukt Probleme machen, irgendwelche Sachen so gravierend ändern werden. Ich zumindest sehe da keinerlei Notwendigkeit. Vllt. solltest du dein Konstrukt mal nach excludes oder ähnlichem Durchforsten...

 

[Frank_at_iphone]

Hi,


Hermann, Silent-Tears, mir ist klar das ich mir selbst in den Fuss geschossen habe und die Schmerzen sind noch da. Sorry!

Es ging mir darum doppelt-debuggen zu vermeiden. Der Fehler faellt spaet auf und ist zumindest mit meinen Kenntnissen nicht allein auffindbar. Derart erzeugte Images laufen bei mir seit laengerem stressfrei. USB habe ich halt von Hand gemountet.

Man koennte jetzt:
a) Nichts tun. Das Problem tritt selten auf und man findet es ab jetzt in der Forumsuche.
b) leere Verzeichnisse automatisch anlegen. Wie schon gesagt schoen ist das nicht.
c) Einen Fehler ausgeben, falls root/sys nicht da ist und damit das build-System robuster gegen User Fehler machen. if [ ! -e root/sys ] . ..
d) Es im wiki/FAQ eintragen: builds mit git-svn funktionieren nicht.

Mir ist auch klar, dass man nicht alles abfangen kann, dass derartige Tests/Workarounds das Build-System unuebersichtlicher machen usw... Es ist halt eine Frage der Balance. Mir ist auch klar das

Das entsorgen leerer Verzeichnisse ist bei git-svn ist System bedingt. git kann keine leeren Directories verwalten. Falls man weiss wonach man suchen soll springt es einem beim Suchen regelrecht entgegen. Aber das weiss man erst hinterher.


Danke nochmals!
Frank

 

[Silent-Tears]

Nun, ich beschreibe dir mal unser Vorgehen, denn es nutzt subversion oder einen Download (bz2 komprimiertes tar-Archiv). Ohne git. Und damit funktioniert eben dies

Alles andere ist von uns weder getestet, noch auf irgendeine Art und Weise freigegeben. Von daher belassen wir es dabei, es ist simpel: Wenn jem,and freetz zweckentfremdet, so muss er/sie selber dafür sorgen, dass es im nachhinein noch funktioniert, denn für Modifizierungen unser Arbeit und Vorgehensweise können wir keinerlei Garantie übernehmen.

 

[hermann72pb]

@Silent-Tears: Sein Problem war, dass er eine Erweiterung der SVN-Software verwendet hat. Ich glaube, sowas kann schon mal passieren. Die Lösung c) finde ich eigentlich nicht ganz verkehrt, wenn es denn alles noch mehr idiotensicher machen wird. Ohne, dass wir uns jetzt darüber streiten, würde ich vorschlagen, dass Frank_at_iphone seinen Vorschlag bei sich testet und es anschließend als patch zu fwmod hier oder/und als Ticket im trac publiziert. Wenn es denn geht und keine Probleme bereitet, wird es irgendwann mal von einem der Entwickler eingepflegt.

MfG

 

[Silent-Tears]

Nein, git-svn ist keine Erweiterung, sondern ein "Tool", was svn-repositories in git-repositories umwandelt und anders herum. Quasi ein Wrapper dazwischen.

Aber: Nur auf root/sys zu testen ist dabei zu wenig, und auf jedes leere Verzeichnis zu testen ist irgendwie ziemlich unnötig, da wir ja in unserem Repository und den Downloads diese Files haben. Deswegen plädiere ich simpel für d.

 

[olistudent]

Ich finde die Idee auf root/sys zu testen gut. Die anderen leeren Ordner sind nicht so relevant wie root/sys. Außerdem sollte bei allen leeren Ordnern das gleiche Verhalten zu beobachten sein.

MfG Oliver

 

[Frank_at_iphone]

Hi,

meinen Satz 'laufen stressfrei' muss ich auch relativieren:
Ich bin gerade nicht in der Lage einen Patch zu entwickeln und/oder zu testen: Meine Fritzbox ist anscheinend beleidigt und sagt jetzt immer "unbekannter Fehler" beim Firmware flashen.

Ich habe bislang folgendes getan:

In der Workarea, die ich mir mit git-svn verhunzt habe, habe ich die leeren Directories erzeugt, neu gebaut und per Webinterface die Firmware upgedated. Ergebnis: "Unbekannter Fehler"

# cat update_error.log                                                         
tar: invalid tar magic

Dann Windows Rechner gesucht und recover.exe gestarted. Alles geht glatt : Firmware-Version 54.04.80 ist wieder drauf. Die abgespeicherten Einstellungen wieder draufgespielt.

Neue Workarea aufgebaut, diesmal freetz-1.1.2 mit svn ausgecheckt.
make menuconfig; make; mit dem Webinterface die Firmware upgedated. Ergebnis: "Unbekannter Fehler".

Dann telnet mit Telefon an:

# cat update_error.log                                                         
tar: invalid tar magic

Einzige Veraenderung am 'nackten freetz-1.1.2' war ein Problem beim bauen von tcpdump. Hier im Forum einen Patch gefunden und angewandt:

...freetz-1.1.2$ svn diff make
Index: make/tcpdump/tcpdump.mk
===================================================================
--- make/tcpdump/tcpdump.mk     (revision 4287)
+++ make/tcpdump/tcpdump.mk     (working copy)
@@ -6,7 +6,7 @@

 $(PKG)_DEPENDS_ON := libpcap

-$(PKG)_CONFIGURE_PRE_CMDS += autoconf --force ;
+$(PKG)_CONFIGURE_PRE_CMDS += autoconf2.59 --force ;

 $(PKG)_CONFIGURE_ENV += BUILD_CC="$(TARGET_CC)"
 $(PKG)_CONFIGURE_ENV += HOSTCC="$(HOSTCC)"

Ist das jetzt ein neues Problem oder haengt das trotz recover mit dem kaputten Images ohne sysfs zusammen? Oder gibt es auch bekannte Paket Wechselwirkungen, dies das erzeugen können? Ich habe m.E. tor, tcpdump, dropbear ausgewählt.

danke
Frank

 

[Silent-Tears]

Nein, das hat nichts damit zu tun.
Aber du kannst mal bitte versuchen, das Image nit deinem tar zu entpacken, und mit "./tools/busybox tar" wieder zu packen. Alternativ den trunk nehmen um das mal zu verifizieren.

Wir hatten nämlich ein Problem mit manchen tar-Versionen, bzw. auch Originalimages, die irgendwie manches anders gemacht haben, als man für die Box braucht.

 

[olistudent]

http://trac.freetz.org/changeset/3638

Das hatten wir damals geändert...

MfG Oliver

 

[Frank_at_iphone]

Hi,

ich habe jetzt gepackt und entpackt:

  cd images
  mkdir z
  cd z
  tar xf ../7270_04.80freetz-1.1.2.de_20100208-200557.image
  ../../tools/busybox tar -cf ../fjh.image .

aber immer noch "invalid tar magic".

Das mir dem changeset(herunterladen, patch < changeset_r3638.diff) habe ich nicht geschafft. Oder gibt es einen svn Trick zum cherry-picken?
Ich sehe auch nichts von busybox im patch enthalten?

Ich baue gerade freetz-trunk: revision 4292
tor comipilierte nicht, habe ich diesmal abgewaehlt.

Ergebnis:

"invalid tar magic".

Frank

 

[hermann72pb]

@Frank_at_iphone: Ich glaube, Oliver wollte nur zeigen, was damals getan wurde, um tar von busybox zu nehmen. Es hieße nicht, dass du es anwenden sollst.

Und überhaupt. Warum machst du so krumme Sachen hier und willst von uns noch Support dafür haben? Es geht auch anders, eigene Pakete ins Image zu integrieren, oder von mir aus Binaries kompilieren und/oder ins Image mitnehmen, als sich mit tar rumzuquellen. Oliver und Co. haben es seiner Zeit für alle gemacht und optimiert. Man muss es nur nutzen und nicht das Rad neu erfinden.

MfG