TS-431 tot nach Firmwareupdate

  • Hi,
    mein TS-431 ist nach einem Firmwareupdate nicht mehr ansprechbar und auch im Finder nicht mehr zu sehen. Kein Ping möglich, keine Aktivität am Netzwerk. Es piept einmal direkt beim Einschalten, danach blinkt Status grün/rot.


    Was ich bisher versucht habe:
    - QNAP Finder - nichts
    - diverse Recovery-Prozeduren von https://wiki.qnap.com/wiki/Firmware_Recovery - für das TS-431 gibt es aber kein Recovery.
    - während der Recovery-Versuche habe ich den Traffic am LAN-Interface via tcpdump protokolliert - nichts
    - zerlegt und serielle console angeschlossen - da kommt was.


    Ich habe jetzt also Zugriff auf uboot (?) und nach dem Boot auf das Linux-System, aber da ist offenbar was defekt.


    uBoot:


    Login in das QNAP-System:

    Code
    [   .........] Weitere Kernel Meldungen
    [   79.411643] bonding: `' invalid for parameter `max_bonds'
    /sbin/daemon_mgr: error while loading shared libraries: libuLinux_config.so.0: cannot open shared object file: No such file or directory
    Welcome to use the QNAP's products.(none) login: adminPassword:login[1093]: root login  on `ttyS0'[~] # lsindex_default.html


    Offensichtlich ist also das System im NAND defekt. uBoot scheint zu funktionieren, so dass ich Hoffnung habe, darüber ein neues System einzuspielen.


    Nur:
    1. Wo könnte ich sowas finden?
    2. Wie könnte das gehen? :)


    Bevor ich hier durch wilde Versuche dem schönen Gerät den Rest gebe, hoffe ich auf Hilfe oder Erfahrungswerte aus dem Forum.


    Danke,
    Andreas


    Weitere Erkenntnisse:

    Code
    Barebox-C2K >/dev ls -l *root* *kernel*
    crw-------  225837056 nand0.boot1_rootfs2.bb
    crw-------  226492416 nand0.boot2_rootfs2.bb
    crw-------  226492416 nand0.boot2_rootfs2
    crw-------  226492416 nand0.boot1_rootfs2
    crw-------   33292288 nand0.boot1_kernel.bb
    crw-------   33554432 nand0.boot2_kernel.bb
    crw-------   33554432 nand0.boot2_kernel
    crw-------   33554432 nand0.boot1_kernel

    boot1_rootfs2.bb und boot1_kernel.bb sind kleiner als die anderen, und auch kleiner als die konfigurierten Werte (216MB und 32MB)


    Wenn ich den Kernel boote, fehlt das Verzeichnis "/usr/lib", damit ist auch ein manuelles Update nicht möglich.


    Also zwei Optionen:
    - irgendwie das boot2_rootfs gestartet bekommen
    - einfach boot2 auf boot1 kopieren...


    Woher weiss das Ding eigentlich, ob es ein TS-131 oder TS-431 ist? Kann ich da einfach ein TS-131 Board einbauen? Die Firmware ist ja identisch.


    Im QNAP Linux das /dev/mtd4 auf /dev/mtd2 kopieren ist offenbar keine gute Idee:


    Code
    Barebox-C2K >/ bootm /dev/nand0.boot1_kernel.bb
    skipping bad block at 0x00240000
    skipping bad block at 0x00760000
    skipping bad block at 0x00900000
    skipping bad block at 0x00b80000
    Verifying Checksum ... Bad Data CRC
  • angelluck: d.h. ein Mainboard der TS-131 würde in der TS-431 potentiell korrekt erkannt. Wäre ein Versuch

    Nachdem die Anschlüsse für gewöhnlich auf dem Mainboard sitzen wird das ts-131 Mainboard in einem ts-431 Gehäuse sicher immer noch als ts-131 erkannt.

  • Ok, TS-131 wird nicht funktionieren, die hat nur 1x LAN. Die HDD-Anschlüsse sind an einer Steckkarte, das wäre vielleicht noch gegangen. Das Mainboard hat eine Beschriftung "TS-x31".


    Meine nächste Idee: Die fehlenden Dateien (/usr/lib und /usr/local) einfach per USB in das System einspielen, das ich booten kann, und dann ein manuelles Upgrade versuchen.
    Hat jemand eine Idee, wie man eine QNAP Firmware-Datei xxx.img mounten kann und die Daten von dort extrahiert bekommt, oder kann mir jemand diese Verzeichnisse schicken?


    Die Version, die noch bootet, ist wohl 4.2.2, aus /etc/config/uLinux.conf:
    Version = 4.2.2
    Build Number = 20161102
    Number = 0306


    Der Bootloader "barebox" auf der Kiste scheint mir übrigens keine Netzwerkunterstützung zu haben. Das würde auch erklären, warum es kein Recovery-Image gibt.
    USB-Support habe ich auch nicht gesehen.
    Insgesamt etwas halbgar, weil der Bootloader zumindest einen kaputten Kernel erkennt und auf den alternativen Kernel umschaltet.

  • Weiter im Monolog :) Ich habe es jetzt geschafft, den von mir zerstörten Kernel in /dev/mnt2 zu reparieren, indem ich den Kernel auf /dev/mtd4 darüberkopiert habe:

    Code
    nanddump -f mtd4.dump /dev/mtd4
    flash_erase /dev/mtd2 0 0 
    nandwrite /dev/mtd2 mtd4.dump

    Das prinzipielle Handling der Files und den Boot-Vorgang habe ich soweit denke ich auch verstanden.


    Problem: Das UBI-Filesystem in /dev/mtd3 bzw. /dev/mtd5 ist offensichtlich nicht vollständig geschrieben worden, und lässt sich daher nicht einbinden. Dort liegen aber die libraries und module, um ein manuelles firmware-Update durchzuführen.

    Code
    [    6.501514] UBI error: compare_lebs: unsupported on-flash UBI format
    [    6.517404] UBI: attaching mtd5 to ubi0
    [    6.521256] UBI: physical eraseblock size:   131072 bytes (128 KiB)
    [    6.527564] UBI: logical eraseblock size:    126976 bytes
    [    6.532984] UBI: smallest flash I/O unit:    2048
    [    6.537700] UBI: VID header offset:          2048 (aligned 2048)
    [    6.543729] UBI: data offset:                4096
    [    7.087656] UBI error: process_eb: bad image sequence number 574346412 in PEB 628, expected 1284114743


    Der Weg zum Recovery ist jetzt einigermassen klar. Dazu bräuchte ich aber von jemandem mit funktionierendem TS-431 einen Dump von /dev/mtd[2345]. Ich vermute stark, dass die Daten zusammenpassen müssen.


    Könnte mir bitte jemand irgendwie folgende "mtdx.dump" Files zukommen lassen:

    Code
    nanddump -f mtd2.dump /dev/mtd2
    nanddump -f mtd3.dump /dev/mtd3
    nanddump -f mtd4.dump /dev/mtd4
    nanddump -f mtd5.dump /dev/mtd5


    Das wäre echt super!


    Danke,
    Andreas

  • Nachdem die Anschlüsse für gewöhnlich auf dem Mainboard sitzen

    Die SATA Anschlüsse sind auf der Backplane, welche auf dem PCI sitzt. Die TS-231 und TS-431 haben das selbe Mainboard, TS-131 ist schon wieder anders ;).

  • VaexX: Korrekt, auf der Backplane sitzen auch die SATA-Controller.


    Seit kurzem läuft das TS-431 wieder!


    Ich habe keine Ahnung, wie die Beschädigung zustande gekommen ist, weil an sich /dev/mtd3 und /dev/mtd5 beim Update nacheinander geschrieben werden, aber der Weg zur Wiederherstellung war dann relativ einfach.


    Ursache des Problems:
    /dev/mtd3 und /dev/mtd5 sind UBIFS-Filesysteme. Dort ist bei jedem Block auch hinterlegt, zu welcher Dateisystemversion der Block gehört, also ob die Blöcke zugleich formatiert wurden. Wenn hier Blöcke nicht zusammenpassen, lässt sich das Filesystem nicht mehr einbinden, damit schlägt der Start des QNAP fehl.


    Meine Lösung: - ACHTUNG: am Flash herumschreiben ist immer ein Risiko!
    cat /dev/mtd5 > mtd5.dump
    diesen Dump via USB auf ein Linux-System transportieren
    mit ubireader_extract_files aus dem ubi_reader Package die Dateien extrahieren. Dieses Tool ignoriert offenbar die Versions-Referenzen.
    diese Daten wieder auf USB und an das QNAP
    mtd5 neu formatieren:

    Code
    ubiformat /dev/mtd5
    ubiattach -p /dev/mtd5
    ubimkvol /dev/ubi0 -N rootfs2 -m
    mount -t ubifs ubi0:rootfs2 /mount/Point

    die extrahierten Daten dorthin kopieren, Volume unmounten, Neustart, fertig


    Bei der Einrichtung mittel QNAP-Finder werden dann alle Daten im Flash neu geschrieben und das Problem ist erledigt.


    Viel gelernt über Flash-Filesysteme...

  • :thumbup: find das echt super, dass du das hier alles dokumentiert hast und auch am Ende nochmal beschrieben hast, was nun das Problem war und wie du es gelöst hast. Wird leider viel zu selten gemacht, oftmals findet man dann nichts mehr und wenn nochmal jemand das Problem hat, ist derjenige dann aufgeschmissen. :thumbup:

  • Hallo,
    ich habe die TS-431+ im Einsatz und heute ein manuelles Update per SSH durchgeführt. Nach dem Reboot startet die Kiste nicht mehr. Die Status LED blinkt grün/rot und es gibt keine Verbindung mehr per SSH oder Webzugang ohne Festplatten. Ich wollte mich an die Konsole hängen, hast du @holzhammer dazu vielleicht noch eine kleine Anleitung, welche Strippen mit welcher Pinbelegung wohin?
    Das wäre super!

  • Vielen Dank Holzhammer.
    Ich habe mir jetzt bei Ebay einen PL2303 Adapter von RS232 auf USB gekauft und mit dem passenden Stecker eine Verbindung über Console (Putty bzw. minicom) hergestellt, wie in dem von dir verlinkten Artikel beschrieben.
    Ich bekomme jetzt eine ähnliche Ausgabe wie bei dir, bei mir startet der Kernel aber nicht:



    Hat da jemand von euch eine Idee?
    Ich kann im Terminal ein "Enter" senden, aber es passiert nichts. Da der Kernel nicht lädt, habe ich auch keine Shell...


    Edit1:
    Ich habe den Autoboot Mehanismus unterbrochen und gelange dadurch in eine Barebox-C2K.
    Das Kommando "nanddump" kennt er nicht, eine Online Dokumentation war eher nicht zu finden, ich habe folgende Kommandos zur Auswahl:


    Ich nutze ja eine TS-431+, die basiert wohl auf ARM. Kennt sich jemand von euch mit dieser Barebox aus?

  • you may try push USB copy button for 30sec while turn system power on
    and then turn off power
    than leave for some minutes device with no power connected

  • Hallo z_rg,
    ich habe das Gerät eingeschickt und es wurde repariert.


    Nach dem letzten Update funktioniert nun jedoch nicht mehr die Anmeldung über die Weboberfläche, die Anmeldung als Admin über SSH funktioniert jedoch ... Ich werde bald noch verrückt...

  • hast du schon versucht, die Firmware noch mal neu manuell drüberzuinstallieren? Oder hast du die alten Platten einfach wieder eingesetzt? Vorher aber an das Backup denken!