[Problem] FB7490: Freetz Update 6.30 -> 6.51 failed

krda79

Neuer User
Mitglied seit
28 Sep 2005
Beiträge
7
Punkte für Reaktionen
0
Punkte
1
Hallo,

ich nutze Freetz jetzt schon eine ganze Weile mit unterschiedlichen Fritzboxen und Fritz!OS-Versionen. Nun wollte ich endlich mal auf die aktuelle Version 6.51 updaten und boom: rien-ne-va-plus, recovery notwendig. Hab mir einen USB-Seriell-Adapter besorgt und nun eine serielle Konsole zur Fritzbox (bei der 7490 gibt es auf dem mittleren Kontakten, siehe http://www.wehavemorefun.de/fbwiki/images/a/a0/Serielle_Konsole-Bild1.jpg, Bootloader-Prompt, Kernelausgaben und Linux-Konsole).

Da kommen bei der Ausführung des post-install Skripts folgende Meldungen:

Code:
Erase mtd partitions 0 and 1 ...
info 0x0
{mtd_info} type 0x4
{mtd_info} size 0x400000
{mtd_info} erasesize 0x20000
{mtd_info} writesize 0x800
{mtd_info} oobsize 0x40
[main] exit error 0
info 0x0
{mtd_info} type 0x4
{mtd_info} size 0x3000000
{mtd_info} erasesize 0x20000
{mtd_info} writesize 0x800
{mtd_info} oobsize 0x40
[main] exit error 0
Copy kernel image...
info 0x0
{mtd_info} type 0x4
{mtd_info} size 0x400000
{mtd_info} erasesize 0x20000
{mtd_info} writesize 0x800
{mtd_info} oobsize 0x40
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] append 115192 Bytes
[main] written 0x20000 Bytes
[main] eof reached
[main] exit error 0
Copy filesystem image ...[ 9417.260000] SQUASHFS error: Major/Minor mismatch, trying to mount newer 0.0 filesystem
[ 9417.270000] SQUASHFS error: Please update your kernel

mount: mounting /dev/loop1 on /var/tmp/fs failed: Invalid argument
filesystem.image: cannot mount squashfs, trying ext2 ...
mount: mounting /dev/loop1 on /var/tmp/fs failed: Invalid argument
99528+0 records in
99528+0 records out
filesystem.image: ... mount ext2 done
Copy filesystem ...
... Copy filesystem done
Setting linux_fs_start mirror...
SHUTDOWN: unmounting
[ 9425.660000] SysRq : Emergency Sync
[ 9425.660000] SysRq : Emergency Remount R/O
SHUTDOWN: unmounting 'usbfs' on '/proc/bus/usb'
SHUTDOWN: unmounting 'yaffs2' on '/var/media/ftp'
umount: can't forcibly umount /var/media/ftp: Device or resource busy
SHUTDOWN: umount /var/dev/nand (on /var/media/ftp) failed, trying to remount readonly...
SHUTDOWN: unmounting 'yaffs2' on '/var/flash'
SHUTDOWN: unmounting 'devpts' on '/dev/pts'
SHUTDOWN: unmounting 'sysfs' on '/sys'
SHUTDOWN: unmounting 'yaffs' on '/wrapper'
umount: can't forcibly umount /wrapper: Device or resource busy
SHUTDOWN: umount rootfs (on /) failed, trying to remount readonly...
SHUTDOWN: still rw mounted: rootfs (on /)
SHUTDOWN: still ro mounted: /dev/root (on /wrapper)
SHUTDOWN: still ro mounted: /dev/loop0 (on /)
SHUTDOWN: still rw mounted: proc (on /proc)
SHUTDOWN: still rw mounted: tmpfs (on /var)
SHUTDOWN: still rw mounted: dev (on /dev)
SHUTDOWN: still ro mounted: /var/dev/nand (on /var/media/ftp)
SHUTDOWN: finished
The system is g[ 9428.820000] [avm_power]pm_ressourceinfo_thread: exit
[ 9428.830000] [avm_power] PowerManagmentRelease(0x8e98ff80)
oing down NOW!
Sent SIGTERM to all processes
[AHA] SIGTERM received: terminate AHA
pbd[1202]: received signal Terminated
Jun 25 18:16:27 pbd[1202]: terminating.
[ 9429.050000] __gmac_dev_event: ath0: 0x9 (NETDEV_GOING_DOWN), pid=1319 (hostapd)
[ 9429.100000] __gmac_dev_event: ath0: 0x2 (NETDEV_DOWN), pid=1319 (hostapd)

Beim darauffolgenden Boot sind die letzten Kernelausgaben folgende:

Code:
[    6.400000] [avmnet_create_netdevice] setup offload_cpu_link on device wasp
[    6.410000] avmnet: avm_pa: register pid wasp
[    6.440000] SQUASHFS error: Can't find a SQUASHFS superblock on mtdblock1
[    6.440000] yaffs: dev is 32505857 name is "mtdblock1" ro
[    6.450000] yaffs: passed flags ""
[    6.450000] [ifx_hsnand_command] read block is critical (column: 0x800 page: 0xc80)
[    6.470000] [ifx_hsnand_command] read block is critical (column: 0x800 page: 0x20c0)
[    6.480000] [ifx_hsnand_command] read block is critical (column: 0x800 page: 0x24c0)
[    6.480000] [ifx_hsnand_command] read block is critical (column: 0x800 page: 0x2940)
[    6.500000] VFS: Mounted root (yaffs filesystem) readonly on device 31:1.
[    6.510000] devtmpfs: mounted
[    6.510000] Freeing unused kernel memory: 300K (80835000 - 80880000)

Was läuft hier schief? Ist das Rootfs verkehrt gebaut?

Bei Bedarf kann ich gerne mehr Ausgaben und auch die Freetz-Config zur Verfügung stellen. Andere Threads in diesem Forum haben mir auch noch nicht weitergeholfen (oder ich habe den einen richtigen Hinweis bei den langen Threads übersehen).

Ich bin aktuell über folgendes EVA-Kommando wieder zurück im alten 6.30. Das Update auf 6.51 wurde also versucht in mtd0/1 zu installieren.
Code:
setenv linux_fs_start 1

Tschüss,
Daniel
 
Daß in mtdblock1 kein SquashFS-Superblock gefunden wird, ist normal ... das ist ein yaffs2-Dateisystem, in dem erst liegt das eigentliche root-Filesystem als SquashFS-Image.

Eigentlich sollte jetzt (nach dem Mounten des Root-FS in mtdblock1) der normale "init"-Prozess starten, der dann das SquashFS-Image "mounted" und mittels "pivot_root" dorthin umschaltet. Wenn das nicht zu sehen ist, würde ich auf ein Problem beim Starten der BusyBox in der wrapper-Partition tippen. Zum Eingrenzen könnte man in die /etc/inittab im wrapper noch irgendeine Protokollierung (z.B. "echo" nach /dev/console) einbauen, wobei da wohl schon nichts zu sehen sein wird, weil hier vermutlich schon das Mounten des SquashFS-Images fehlschlägt.

Solange das ein halbwegs aktuelles CS ist, sollten die BusyBox-Probleme im wrapper-FS eigentlich beseitigt sein (u.a. die manchmal fehlende libm.so für den Start der BusyBox) ... das ist schon etwas komisch. Der Kernel wurde hier aber offenbar nicht ausgetauscht, damit ist die Frage der falschen/unvollständigen Quellen hier auch nicht das Problem.

Ich wäre ja dafür, das Ersetzen der Busybox (und dann natürlich auch der Libs) im wrapper-FS optional zu machen in Freetz (ist ja jetzt schon eine gesonderte Einstellung, für die braucht es nur noch den "Ausknipser") ... es gibt nur sehr wenige Gründe, dort dieselbe BusyBox wie im "eigentlichen" System zu verwenden (manchmal ist es sogar von Vorteil, wenn da noch die AVM-Version liegt, weil man schnell mal etwas vergleichen kann).
 
Danke für die Antwort.

Was bedeutet eigentlich "CS"?

Ich hab nochmal bissl rumprobiert. Wenn ich ENTER drücke, kommt alle Sekunde die Ausgabe "can't open /dev/ttyS0: Read-only file system". Ich vermute das kommt von "/dev/ttyS0::askfirst:-/bin/sh" aus /etc/inittab. Das würde doch aber bedeuten, dass die Einträge davor in der inittab abgearbeitet wurden, oder? Ich werde da noch nicht so ganz schlau draus.
 
CS soll "Changeset" heißen und beschreibt den Patch-Stand des Freetz-Trunks.

Der aktuelle Stand wäre von gestern (CS 13806) und solange das eigene Image mit dem AVM-Kernel arbeitet, sollte es eigentlich funktionieren - einfach erst einmal mit einem minimalen Image beginnen. Das hieße dann auf alle "remove patches" zu verzichten und keine Pakete auszuwählen, die für Freetz nicht ohnehin "mandatory" sind.

Sollte es dabei Probleme geben, ist die serielle Konsole ja sehr nett und sehr hilfreich ... eine Datei mit der verwendeten Konfiguration hier anzuhängen, spart dann weitere Nachfragen nach dem Inhalt des Images - man kann schlicht dort nachschauen.

- - - Aktualisiert - - -

Zu dem Problem mit dem Device ... das klingt irgendwie so, als wäre da kein "devtmpfs" unter /dev gemountet, so daß dort weiterhin das read-only gemountete root-FS (yaffs2-Format, der Inhalt der "filesystem"-MTD-Partition) liegt - oder es gibt gar kein /dev/ttyS0 oder dieses hat die falschen Rechte oder oder oder ...

Das Mounten des root-Dateisystems (inkl. der Feststellung, welches das richtige ist) und des devtmpfs ist eigentlich Teil der Initialisierung des Systems - logischerweise, denn Inhalte des root-FS wie die "inittab" können eben erst dann gelesen werden, wenn das FS gemountet ist. Bei Kernel 3.10 wird auch das devtmpfs bereits von der Initialisierung gemountet (und der originale Inhalt von /dev dorthin gespiegelt) - bei früheren Versionen mußte das erst noch im Rahmen des "init"-Prozesses entsprechend eingerichtet werden (gleich am Beginn in /etc/init.d/rc.S).

In #1 ist ja auch auf der seriellen Schnittstelle noch zu sehen, wie das root-FS und auch devtmpfs gemountet werden, dann wird noch jetzt unbenutzter Hauptspeicher vom Kernel freigegeben und jetzt sollte eigentlich der "init"-Prozess vom Kernel gestartet werden. Dazu wird nach "/bin/init" gesucht ... und hier dürfte auch das Problem liegen - vermutlich wird /bin/init einfach nicht gefunden oder funktioniert eher nicht, weil das Fehlen eigentlich eine entsprechende Kernel-Message nach sich ziehen sollte. Da liegt es nahe zu vermuten, daß das BusyBox-Binary (welches hier ja das "init" bereitstellen soll) nicht geladen werden kann und das liegt in aller Regel an fehlenden DSOs.

Warum das so sein könnte, wird man aus der Ferne nur schwer herausfinden ... aber Du kannst vom zweiten System aus jederzeit nachsehen, indem Du das FS in "reserved-filesystem" einfach irgendwo mountest und dann den Inhalt untersuchst. Das sollte (mit ganz wenigen Änderungen) genau denselben Inhalt haben, wie das unter /wrapper im laufenden System gemountete (ehemalige) root-FS aus der "filesystem"-Partition. Wobei ich hier am ehesten darauf tippen würde (auch wenn ich mich wiedehole), daß die "libm.so" fehlt ... da Freetz die BusyBox in der wrapper-Partition ebenfalls austauscht (#2, Absatz 3 und 4), kann es da Probleme geben. Aber noch einmal ... das kannst nur Du selbst ermitteln - entweder anhand des Inhalts der Image-Datei aus Freetz oder anhand des Inhalts der yaffs2-Partition.

Da bringt auch
krda79 schrieb:
Ich hab nochmal bissl rumprobiert.
nur wenig ... entweder Du willst ernsthaft nach dem Problem suchen (immerhin hast Du ja offenbar sofort die Serielle bestückt, was schon mal viele eher nicht gemacht hätten - insofern unterstelle ich echtes Interesse und schreibe weiter) oder Du willst nur "rumprobieren". Systematisches "Rumprobieren" ist sicherlich auch nicht falsch, würde ich dann nur anders bezeichnen oder umschreiben - nämlich als "testen" und dazu darfst Du auch auf Hilfe hoffen; beim Spielen eher nicht, da sind heutzutage einfach spezialisierte Consolen wesentlich interessanter.
 
Danke für die ausführliche Antwort.

Mein weiteres "Rumprobieren" - äh Testen hat folgendes ergeben: Ich bin nochmal zurück zu einer einfachen Basiskonfiguration und hab von da aus meine Optionen wieder aktiviert. Alle diese Varianten funktionieren. Jetzt ist der einzige größere verbliebende Unterschied, dass die nichtfunktionierende Variante mit FREETZ_BUILD_TOOLCHAIN=y und nicht FREETZ_DOWNLOAD_TOOLCHAIN=y gebaut wurde. Die anderen, aber aus meiner Sicht unwichtigen, jetzt noch fehlenden Optionen sind nur: FREETZ_PACKAGE_DECRYPT_FRITZOS_CFG=y und FREETZ_FAVICON_ATOMPHIL=y.

Meine jetzige Config (compressed):
Code:
FREETZ_USER_LEVEL_EXPERT=y
FREETZ_TYPE_FIRMWARE_06_5X=y
FREETZ_PATCH_SIGNED=y
# FREETZ_RESTORE_DEBUG_CFG_SUPPORT is not set
FREETZ_PACKAGE_CALLMONITOR=y
FREETZ_PACKAGE_DROPBEAR=y
FREETZ_PACKAGE_SOCAT=y
FREETZ_BUSYBOX_FEATURE_VI_UNDO=y
FREETZ_BUSYBOX_FEATURE_VI_UNDO_QUEUE=y
FREETZ_BUSYBOX_FEATURE_FIND_EXEC_PLUS=y
FREETZ_SECURITY_LEVEL=0
FREETZ_JLEVEL=8
 
Wie alt ist denn die selbstgebaute Toolchain? Ist da vielleicht auch die uClibc für das Zielsystem enthalten (ich weiß nicht, was da alles bereitgestellt wird neben dem reinen buildroot) und sie wurde gleich zu Beginn der Verfügbarkeit der 06.5x in Freetz erstellt? Hinterher mußte die uClibc-Konfiguration noch angepaßt werden ... das war aber schon irgendwann Ende Dezembar/Anfang Januar. Seitdem hätten die meisten sicherlich die Toolchain auch schon neu gebaut ... andererseits kann man nie zu weit um die Ecke denken. Ich würde hier noch einmal einen frischen Trunk auschecken und mit eigener Toolchain (die .config kann man ja übernehmen) von Null an übersetzen ... wenn das dann immer noch Probleme bereitet, kann man weiter suchen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.