Ok, dann halte ich in meiner Verwirrung lieber die Klappe bevor Unheil passiert
QNAP TS439 ProII+ QTS Clone
- OM22
- Unerledigt
-
-
Unheil! Gutes Stichwort
Also, ich scheine des Lesens nicht mehr mächtig oder finde die entsprechende Anleitung nicht.
Wie oben beschrieben habe ich mir
- TS-439_20120801-3.7.3.Flash.img geladen.
- dann mit unetbootin-windows-613 den Stick mit DSL vorbereitet
- und TS-439_20120801-3.7.3.Flash.img in dom.img umbenannt auf den Stick abgelegt.
Dann bin ich dem selben Weg gefolgt, wie in der mir vorliegenden Anweisung beschrieben:
Doch schon hier kommt der erste Unterschied im Ergebnis: - siehe Bild 1 (so soll es sein)
Bei mir sieht das dann so aus: Bild 2 (so ist es bei mir)
Ich würd ssooooooo gerne das Problem endlich mal verstehen
-
Also, ich scheine des Lesens nicht mehr mächtig
Scheint mir in der Tat so.
Du machst nach dieser Anleitung https://wiki.qnap.com/wiki/Fir…y_Guide_for_x86-based_NAS
Schritt für Schritt ein Recovery mit dem dort verlinkten Image http://eu1.qnap.com/Storage/ts…PROII+_20110609-1.1.4.img
bis du bei Punkt 14 anlangst.
In diesem Punkt klickst du auf den dortigen Link (im Bild rot markiert)
oder hier http://wiki.qnap.com/wiki/NAS_…_When_No_HDD(s)_Installed
In der sich nun öffnenden Anleitung lädst du dir das Image http://us1.qnap.com/Storage/ts…_20120801-3.7.3.Flash.img
und machst damit ein Update über Qfinder nach den dortigen Schritten unter "Update Procedures".
Anschliessend machst du ein Update auf die aktuelle FW.
-
Moin dr_mike, so weit war ich auch schon. Aber dann passierte folgendes: Der NAS fährt in der Testversion hoch, also die besagte 1.1.4. Ich sehe ihn auch im QFINDER, aber wenn ich die beschriebene Prozedur versuche, kommt eine Fehlermeldung.
QFINDER mit 1.1.4 TestImage.JPG
( so sieht das aus)
Und das kommt dabei heraus:
QFINDER mit 1.1.4 TestImage - via FirmWareUpdate- FEHLER.JPG
Als Image habe ich TS-439_20120801-3.7.3.Flash geladen. Alternativ gibt es auf der Seite nur noch das 439U-Image.
Gemacht habe ich folgendes:
1. F_TS-439PROII+_20110609-1.1.4 geflashed
2. QNAP Finder suche
3. Mit QFinder Versucht auf TS-439_20120801-3.7.3.Flash zu flashen.Soweit ich die Diskussion weiter oben verstanden habe, war die Installation von 1.1.4 in meinem Fall schon ein Fehler.
-
Versteht du jetzt, wieso ich die Welt nicht verstehe? Wo liegt der Fehler?
-
14.
When the firmware version is on 1.x.x, it is factory test firmware. No HDD can be detected with this firmware. Need to update the firmware to official firmware first.
For TS-239, TS-439 (kein U, kein Pro, kein II, kein +), TS-439U, TS-509, TS-639, TS-809, TS-809U, SS-439 and SS-839, please follow the procedures on the following link to update the firmware to 3.5.0.
http://wiki.qnap.com/wiki/NAS_…_When_No_HDD(s)_Installed
For other x-86 based NAS, please download the firmware 3.4.x from QNAP website and use QNAP Finder to update the firmware.
Es handelt sich doch um ein TS 439 Pro II+ oder nicht? Hier gibt es schon die ganze Zeit Verwirrung:
Mal taucht in den Posts eine 439U auf, im Titel ist von 439 pro+ die Rede und zwischendurch tauchen sowohl 439 als auch 439 Pro II+ auf...
Für eine 439 Pro II+ geht es nicht an der Stelle mit dem Link weiter sondern direkt mit der Installation der aktuellen FW.
Er sagt auch (zum wiederholten Male) dass die FW für eine TS439 (kein U, kein Pro, kein II, kein +) zum Flashen geladen wurde.
Vielleicht einfach mal auf das "New" im Finder klicken und damit die aktuelle Firmware flashen? Oder wenn es komplizierter sein soll die FW aus dem Download Center herunterladen, entpacken und dann flashen.
Soweit ich die Diskussion weiter oben verstanden habe, war die Installation von 1.1.4 in meinem Fall schon ein Fehler.
Nein scheinbar nicht, wenn Du die
1. F_TS-439PROII+_20110609-1.1.4 geflashed
genommen hast und auch eine 439Pro II+ hast. Das war mein Fehler in Folge der Verwirrung welches Gerät Du hast
Ich hoffe ich war jetzt etwas entwirrter, warte lieber auf Feedback bevor Du meinen Gedanken folgst
Edit:
Ich glaube so hattest Du das Anfangs auch gemacht, oder??? Eine Fehlermeldung scheint es nicht gegeben zu haben, ggf. solltest Du das Update nochmal via SSH probieren, da sieht man wenigstens was geht und was nicht geht...
-
genommen hast und auch eine 439Pro II+ hast.
tiermutter : Danke für deine Rückmeldung. Ich bin ja schon genauso wuschig. Deshalb habe ich ja auch den ScreenShot vom QFINDER eingehängt, auf dem zu erkennen ist, dass er einen TS-439 pro erkennt.
SSH hab ich bei 'nem QNAP noch nicht gemacht, hatte gehofft drumherum zu kommen.
-
Das Recovery war ja nichts anderes
Wenn es sich also um eine 439Pro II+ handelt, dann nehmen wir fortan auch nur noch Images und Updates bei denen auch genau das (nicht mehr, nicht weniger) dran steht. Da auch zu Beginn des Threads sehr verwirrend war, was nun wie mit dem Getausche etc. gelaufen ist würde ich in Erwägung ziehen das Recovery nochmals durchzuführen um dann sauber fortfahren zu können. Vielleicht klappt es dann schon mit dem finalen Update via QFinder.
Ansonsten wäre das der Ansatz für ein Update über SSH:
https://www.qnap.com/sv-se/how…owngrade-firmware-by-ssh/
Wobei ich mir gar nicht mehr sicher bin ob SSH/ ein SSH Update mit der initialen Firmware überhaupt möglich war.
Jedenfalls wird schonmal der Punkt mit "ins Public Folder kopieren" nicht möglich sein, da ja keine HDD vorhanden sein können. Hier müsste man die FW demnach auf nen Stick packen und den Update-Pfad entsprechend auf den Stick ändern... Ich denke nochmal sauber von vorn beginnen ist die bessere Wahl
Deshalb habe ich ja auch den ScreenShot vom QFINDER eingehängt, auf dem zu erkennen ist, dass er einen TS-439 pro erkennt.
Auf welchem Screenshot ist das denn so? 439 pro wäre ja noch eine weitere Variante die hier kursiert
-
Er sagt auch (zum wiederholten Male) dass die FW für eine TS439 (kein U, kein Pro, kein II, kein +) zum Flashen geladen wurde.
Nunja, hier ist aber auch eine Inkonsistenz bei der Bezeichnung der Modellreihen. Normalerweise haben alle Pro's und Co. außer U alle das gleiche FW-Image. Wenn es nur ein TS-439 Pro ohne "II" und ohne "+" wäre, dann hätte die Bezeichnung der FW kein "Pro" anhängen. Ein Modell TS-439 "ohne Pro" gibt es nicht.
pasted-from-clipboard.pngDas war es, was mich irre geführt hat.
Nun gibt es aber keine FW 3.x.x mehr und ich bin mir nicht sicher ob die 4.2.6 ohne Plattten installiert werden kann.
-
dr_mike
Hat den Titel des Themas von „QNAP TS439 pro+ QTS Clone“ zu „QNAP TS439 ProII+ QTS Clone“ geändert. -
Ja das macht es noch verwirrender... Genau daran hatte ich auch gedacht und mir die FW für die 439pro ii+ geladen, hier heißt die Datei aber auch entsprechend, was ich von meiner 219Pii auch nicht so kenne (hier gibt es aber wiederum eine 219 ohne Zusatz).
Aber warum sollte die 4.2.6 nicht auch ohne HDD geflasht werden können wie alle anderen auch? Die 3.x.x steht da doch sicherlich nur aufgrund des Alters der Anleitung...
Bin auf jeden Fall gespannt wie es weitergeht und was nun wirklich das Problem war
-
MIST!
Das geht so auch nicht:
Also hab ich es noch einmal von vorn versucht:
- mit unetbooting und dsl-4.4.10-initrd den Stick erstellt
- F_TS-439PROII+_20110609-1.1.4 auf den Stick ins oberste Verzeichnis gelegt und in dom.img umbenannt.
- Stick in den NAS, F11 bis BOOT-Auswahl um den USB Stick zu wälen
- und wenn dann das dom.img geladen werden soll
-
Jetzt ist es das erste Mal dass ich sagen würde: das muss aber!
Aber dr_mike hatte da ja Bedenken bei der 4.2.6.
Hast du denn das recovery vorher nochmal durchgeführt?
Evtl auf gut Glück mal eine Verbindung via SSH testen. Falls da was geht könnte man an der Stelle nochmal Versuche starten.
Theoretisch müsste das FW Update auch auf die Weise funktionieren, wie das recovery läuft. Da würde man wie gesagt mal was sehen wenn es schief geht.
-
/dev/sdb ist aber das device.
Müsste bei cp nicht eine Partition als Ziel angegeben werden (/dev/sdb1)?
Gruss
Und: wo liegt das Image?
-
cp muss nach sda erfolgen, das ist der DOM, nicht sdb.
Da das recovery Image ja auch Partitionsinfos enthält wird hier das device angegeben.
Allerdings scheint es ja schon beim mounten des sticks ein Problem zu geben...genauer gesagt wurde in dem Bild Partition 1 vom DOM (sda1) gemountet.
Es gilt erstmal herauszufinden welches device der Stick ist.
Vielleicht kommst Du hiermit weiter:
Firmware Recovery - Es geht nicht immer so, wie QNAP sagt
fdisk -l (kleines L) listet übrigens die Datenträger auf, da solltest du erkennen können, was dein Stick ist.
-
- und wenn dann das dom.img geladen werden soll
... hast du /dev/sda und /dev/sdb vertauscht.
Müsste bei cp nicht eine Partition als Ziel angegeben werden (/dev/sdb1)?
Nein, das Image ist ja ein Image von mehreren Partitionen.
-
So: Euch allen erst einmal 'Schöne Feiertage" und Danke für die bisherigen Tipps.
Sollte jemand von euch sein neue Jahr mit einer Guten Tat starten wolle, kann ich ihm das Teil gerne in die Kiste packen
Als Anhang zum Thema Fragezeichen mal noch ein kleiner ScreenShot. Da habe ich verscht nochmal von vorne anzufangen. Aber es wird ums Verrecken das dom.img nicht gefunden.
Fortsetzung folgt ...
-
kann ich ihm das Teil gerne in die Kiste packen
Das machen wir jetzt mal nebenbei wenn es passt
Ich bin diesen Heiligabend KZH und kann damit mal ruihige Weihnachten genießen
Jetzt ist es das erste Mal dass ich sagen würde: das muss aber!
Da lege ich dann doch mal Revision ein...
Bei Dir scheint (warum auch immer) sda der DOM zu sein (Grund: 512MB und die auf dem DOM befindlichen Partitionen).
Entsprechend scheint sdb Dein Stick mit 32GB zu sein. Das ist für mich ein sehr merkwürdiges Ding, normalerweise ist das andersrum! Ich kann auch nicht einschätzen was das für Auswirkungen auf den normalen Betrieb hat. Für das Recovery per se bedeutet das, dass Du bei den Kommandos in Deinem Screenshot und folgend sdb und sda stets tauschen musst.
Wie gesagt, keine Ahnung was das für den Betrieb für Auswirkungen hat... kann mir schon vorstellen, dass es Probleme gibt, wenn im Anschluss ein FW Update auf eigentlich sdb installiert werden soll und es sdb gar nicht gibt, weil der Stick nicht mehr steckt... Vielleicht hat hier aber auch nur DSL die Devices vertauscht, keine Ahnung! Notfalls machst Du es nochmal nach dieser Anleitung: Firmware Recovery - Es geht nicht immer so, wie QNAP sagt
Cheers!
-
Aber es wird ums Verrecken das dom.img nicht gefunden.
Weil du immernoch /dev/sda und /dev/sdb vertauschst.
-
Na das ist ja was ich meine... "vertauschen" ist bedingt richtig.
Wenn man nach Anleitung geht macht OM22 alles richtig!
Aber laut Anleitung ist sdb der DOM, so wie wir (oder ich) es kennen (wenn es nicht hda ist)
Bei OM22 ist aber sda der DOM! Das sollte lt. Anleitung aber der USB Stick sein.
USB und DOM sind also was die Anleitung betrifft vertauscht, schon verständlich dass hier "Murks" eingegeben wird wenn man sich an die Anleitung hält.
Oder bin ich diesem Verwirrungsthread schon wieder zum Opfer gefallen?
-
Keine Ahnung, wie er das hinbekommt, dass das Bootdevice /dev/sdb ist. Aber man kann daran schön sehen, dass die Devices dynamisch zugeordnet werden. Genauso dynamisch müsste die Anleitung sein. Da sie das nunmal nicht ist, muss der Anwender etwas mitdenken.
Das Device mit den 6 Partitionen und einer Größe von 515MB ist das DOM unabhängig davon welche Bezeichnung es hat
(in diesem Fall /dev/sda) und ist damit unser Ziel:
Das Device welches in der Regel wesentlich größer ist und meistenteils nur eine Partition hat (in diesem Fall /dev/sdb), ist der Stick und damit unsere Quelle:
Nun muß man Qelle und Ziel nur noch korrekt in die entsprechenden Befehle einsetzen.
mkdir usbdrive <- Mountpoint (leeres Verzeichnis) erstellen
mount /dev/sdb1 /home/dsl/usbdrive <- Partition1 der Quelle (/dev/sdb1) einbinden
cd ./usbdrive <- in das Verzeichnis der eingebundenen Quelle wechseln
Hier könnte man mit ls prüfen, ob man bisher alles richtig gemacht hat. Es müsste das dom.img aufgelistet werden.
Jetzt nur noch das Image ins Ziel (unser DOM /dev/sda) kopieren
cp dom.img /dev/sda und neu starten
reboot
Wenn man die Zuordnungen der Devices zu Quelle und Ziel beachtet, dann können die heißen wie sie wollen.
-
Genauso dynamisch müsste die Anleitung sein. Da sie das nunmal nicht ist, muss der Anwender etwas mitdenken.
Finde ich trotz "Zwinker" etwas daneben bzw. nicht zutreffend.
Es wurde nach offiziellen Anleitungen gehandelt. Das sdb oder hda der DOM ist, ist offiziell beschrieben, dass der DOM auch sda sein kann wurde niemals erwähnt, und nochmal ganz wirklich:
Kennt das jemand so?
Wenn ich mich nicht kürzlich erst intensiver mit der Materie beschäftigt hätte würde ich übrigens auch der offiziellen Anleitung folgen und bloß nichts anderes machen als da drin steht.
Und mal ehrlich: das sda und sdb systemseitig (DSL?) vertauscht sind hast Du dr_mike im Verlauf nicht gesehen und ich auch nicht und auch niemand der mitgelesen hat und es hätte wissen müssen, dass hier etwas komisch ist.
Ich glaube das hier ist nicht umsonst "der/ mein Verwirrungsthread".
Und was passiert anschließend außerhalb von DSL? Ist der DOM dann immernoch sda?
Ist das entgegen der offiziellen Anleitung bei einer 493Pii einfach so und das kleine Detail wurde vergessen?
Oder hat OM22 zu Beginn oder zwischendurch so einen Quatsch gemacht, dass nun das dabei rausgekommen ist?