blackmac

Hatte mit Redpill und DSM 7.0.1. ein ähnliches Problem. Mein QNAP 509Pro besitzt 5 SATA–Anschlüsse (5 Bay), unter DSM 7.0.1 wurden partout nur 2 Platten richig erkannt. Nachdem ich SATA–PortMap vom automatischen auslesen von „2244“ auf „4444“ änderte, die Platten blank formatierte, werden sofort wie von mir gewünscht alle drei HDDs bereits von Anfang an erkannt.

4 TB Platten werden nicht erkannt / DSM 7.0.1 / QNAP509Pro / RedPill Bootloader Ich habe am Freitag erfolgreich meinen Bootloader von Juns 1.03b auf den RedPilla gewechselt und konnte DSM 7.0.1 / ds3615xs erfolgreich auf meinem QNAP 509 Pro installieren. Läuft top. Bisher hatte ich imme rnur 2TB Platten im Verbund betrieben, und wollte jetzt auf 4 TB Platten Seagate (für 3615 freigegeben) wechseln. Allerdings werden die nicht im Speichermanager erkannt und angeboten (. Nun ist es so das selbst original QNAP QTS die 4 TB SeagatePlatten nicht wirklich erkennen; in 2012 wurde einmal verlautbart das Hitachi 4 TB Platten getestet und freigegeben wurden. Gibt es irgendetwas an dem ich „rumschrauben“ kann, um 4 TB Platten in meine „Konstruktion“ einzubinden?

Ola, heute mal wieder hier. Das mit dem Win32Disk...wusste ich nicht; mir fiel aber mal bei den Raspi`s auf das die Backup-ISOs nur mit dem Win32Disk wirklich zuverlässig liefen; wenn man sie mal brauchte. Bin noch ganz zufrieden mit meiner QNAP / DSM Konstellation. Mir fiel auch auf das der V 1.03b Bootloader erheblich besser die beiden verbauten Netzwerkkarten anspricht; sprich die Geschwindigkeit im LAN ist erheblich besser und er bündelt jetzt auch beide- wenn man es will. Das einzige was nicht funktioniert ist das WOL und das Starten nach einer voreingestellten Zeit. Ich habe beide Mac Adressen richtig angegeben; per Windows (macOS will die Diskstation per SynologyAssistent erst gar nicht finden ^, aber egal) kann ich auch WOL konfigurieren; aber der QNAP 509 Pro möchte partout nicht. Aber wenn sonst nicht ist...will ich nicht meckern.

ERFOLGSERLEBNIS ^ Die Sache lies mir keine Ruhe, also setzte ich mich heute Nachmittag nochmal hin. Da ich partout keinen Fehler finden konnte und das MBR/GPT anscheinend keine Rolle spielte – kam ich auf die letztendlich problemlösende Idee den USB–Stick einmal mit Balena Etcher, und nicht wie vorher immer mit RUFUS, zu schreiben. Siehe da: im 1. Anlauf wurde die Konstellation „ Bootloader 1.03b, 3615xs“ im Netzwerk erkannt, 6.2.0 lies sich aufspielen und manuell konnte ich auch auf 6.2.3 + Update 3 aufstocken. Das 6.2.4 klemme ich mir dann sicherlich erstmal. #### Pro Forma werde ich mal die Tage an einer S20 nochmal ausprobieren, ob sich der ursprüngliche Fehler für mich reproduzieren lässt…

Ola, versuche ich die Tage gerne mal. In einem Schnellversuch konnte ich die 6.2.0. Install nicht mehr reproduzieren (. Dafür schaffte ich heute als "Nichtwissender" wenigstens dem QNAP für den Fall der Fälle seinen ursprünglichen Bootloader wieder unterzujubeln. Aber ich will schon das er gebetsmühlenartifg "Synaology" statt "QNAP" brabbelt. Eine dynamische Woche wünsc he ich schonmal und vielen Dank für Dein ausführliches Feedback; und Deinen Aufwand den Du hier im Forum betreibst. Ich sehe hier; Du bist in diesem Forum wohl der Held der Helden^^ . Respekt.

Booloadervorgang. Servus, ich besitze einen QNAP 509Pro und hatte vor kurzem auf diesem erfolgreich DSM 6.1.7 (DS3615xs, bootloader Jun‘s v1.02b) installiert bekommen. Lief auch gut. Jetzt befasste ich mich mit dem DSM 6.2.und versuche, die 6.2.0 mit v 1.03b zu installieren. Leider funktionierte das nur ein einziges mal, beim Update 6.2.2. wurde dann wohl der Bootloader auf dem USB Stick / HDDs zerhackstückt, und es war nicht mehr ansprechbar. Also musste ich einmal alles platt machen. Nicht so wild, kein Produktivsystem. Seitdem versuche ich erfolglos, zumindest das 6.2.0 raufzubekommen. Die NAS lässt sich einfach nicht per Finder/ bekannte IP ansprechen. Beim Bootloader v 1.02 fiel mir auf, dass dieser auf dem Bildschirm zum Schluss das entpacken des Linux Kernels meldete. Danach ist das NAS auch per Finder / IP ansprechbar. Beim Bootloader 1.03 meldet er nur bis zum Hinweis find.synology.com…. Jetzt überlege ich, ob ggf der Kernel zum Schluss nicht wirklich entpackt wird, und deshalb kein Ansprechen / Installieren möglich ist, die V / P ID Nummern der jeweiligen USB Sticks, SN Nummern des DS–Seriennummergenerator und Macadresse des QNAP in der Config passen. Anderseits erscheint meistens beim starten des QNAP mit dem „Bootloaderstick“, eben dieser QNAP in der FritzBox–Netzwerk doch mit aktiven Netzwerkkarten (QNAP Pro hat 2x LAN). Eine andere Überlegung ist, ob es an MBR/GPT bei der USB–Stick–Erstellung liegt. In Rufus gebe ich vor, das MBR zu nutzen ist. Der Stick selbst wird aber dann doch GPT (ausgelesen unter Win10 auf einer Lenovo S30, also einer UEFI Maschine). Das QNAP Board mit AMI Bios von 2009 – wird GPT eigentlich nicht lesen können. Noch aufgefallen ist mir wenn Rufus fertig ist (keine Ahnung wie oft ich den Boot–USB Stick mittlerweile gefertigt habe), dass manchmal beim „sicheren entfernen“ der USB Stick mal mit beiden Laufwerkbuchstaben angezeigt wird' und manchmal nur mit Punkte gekennzeichnet ist. In der Datenträgerverwaltung unter Win10 sind allerdings beide Partitionen zu erkennen. vllt hat jemand INPUT für mich, wo ich nochmal achauen kann. Falls es nicht funzt, gehe ich wieder auf 6.1.7. Vielen Dank im voraus.