Hallo zusammen,
ich teile hier eine ausführliche Anleitung, wie ich die berüchtigten FW999-, FW012- und FW006-Fehler beim Update eines TVS-473e von QTS 5.2.5 auf 5.2.8 umgangen habe. Wenn ihr trotz reichlich Festplattenspeicher die Meldungen „Ungültige Update-Image-Größe“ oder „Systemaktualisierung fehlgeschlagen“ erhalten habt, ist das hier für euch.
Das Problem: Warum das offizielle Update fehlschlägt Nach einer gründlichen Analyse der Update-Logs und des Verhaltens von update.sh zeigen sich zwei große Schwächen in der aktuellen QNAP-Update-Logik:
-
RAMDisk-Erschöpfung (Fehler FW006): Das Update-Skript versucht, die Firmware nach /mnt/update zu entpacken, das oft auf einer winzigen RAMDisk (ca. 400MB) liegt. Wenn die Firmware und ihre entpackten Komponenten den freien Speicher überschreiten, bricht der Prozess mit „Kein Speicherplatz mehr auf dem Gerät“ ab.
-
Das „Schrödinger’s Mount“-Problem (Fehler FW999): Das Skript update_img.sh versucht, die DOM-Partition (/dev/sdd2) auf /root/FLASH_RFS1 zu mounten. In vielen Fällen gelingt das Mounten tatsächlich, aber das Skript interpretiert den Rückgabewert falsch oder scheitert an einem nachfolgenden Sanity-Check, startet eine „Cleanup“-Routine, die die entpackten Dateien löscht, und beschwert sich dann, dass das Gerät belegt ist—weil es selbst gerade gemountet wurde!
Die Lösung: Manuelles Update per „Chirurgischem Eingriff“
Wenn ihr euch mit der CLI (und mcedit/vi!) wohlfühlt, ist hier der Fahrplan zum Erfolg:
1. Arbeitsverzeichnis auf eurem eigentlichen Datenvolume anlegen Lasst QNAP nicht die RAMDisk benutzen. Erstellt einen Symlink auf euer großes HDD-Volume.
mkdir -p /share/Public/fw_update
rm -rf /mnt/update
ln -sf /share/Public/fw_update /mnt/update
2. Firmware manuell entschlüsseln und entpacken Nutzt das interne PC1-Tool, um das eigentliche fw.tar zu erhalten.
/sbin/PC1 d QNAPNASVERSION4 /share/Public/your_firmware.img /share/Public/fw_update/fw.tar
cd /share/Public/fw_update
tar xf fw.tar
3. Die „kaputte“ Skriptlogik reparieren Hier tricksen wir SoftLab aus. Öffnet update_img.sh (mit mcedit oder vi) und sucht die Zeile, die versucht, /dev/sdd2 auf /root/FLASH_RFS1 zu mounten. Kommentiert diese mount-Zeile aus (fügt ein # am Anfang hinzu). Warum? Weil ihr das Mounten manuell übernehmt und das Skript nicht in Panik geraten soll, wenn es versucht, eine bereits gemountete Partition erneut zu mounten. So sah es nach der Änderung aus:
mount_flash_rfs1()
{
[ -d "$FLASH_RFS1_MP" ] || /bin/mkdir "$FLASH_RFS1_MP"
# /bin/mount "$FLASH_RFS1" "$FLASH_RFS1_MP"
# /bin/grep "$FLASH_RFS1_MP " /proc/mounts > /dev/null 2>&1
# if [ $? -ne 0 ]; then
# echo "mount $FLASH_RFS1 to $FLASH_RFS1_MP failed"
# return 1
# fi
return 0
}
4. Umgebung vorbereiten und ausführen
# Sicherstellen, dass der Mountpoint existiert und die Partition gemountet ist
mkdir -p /root/FLASH_RFS1
mount /dev/sdd2 /root/FLASH_RFS1
# Die Versionsdatei für den Logger faken
echo “5.2.8” > ./newver
# Das eigentliche Image-Update-Skript ausführen (den Worker, nicht den Wrapper)
./update_img.sh /share/Public/fw_update
5. Aufräumen und Neustarten Wenn „Update Finished“ erscheint, habt ihr es geschafft.
umount /root/FLASH_RFS1
reboot
Abschließende Gedanken für QNAP-Entwickler Es ist faszinierend, wie das Update-Skript ausgefeilt genug ist, um Secure-Boot-Support zu prüfen, aber an einer Partition scheitert, die „zu erfolgreich“ gemountet wird. Vielleicht würde ein einfaches if ! mountpoint -q /root/FLASH_RFS1; then mount… den Nutzern viele Kopfschmerzen ersparen? Nur so ein Gedanke. 
Ich hoffe, das hilft jemandem, der im FW999-Loop feststeckt!