Also wie ich geschrieben hatte, klappte es bei mir:
* mit NUR einer Disk im 220+ und nach normalen Shutdown dann diese im PC ( das funktionierte bei Dir doch auch, oder?)
* mit gesyncten 2 Disks im 220+ und nach normalen Shutdown dann nur eine einzelne am PC (bay2) in einem 2-fach USB-Adapter (Innatec FD2002 ) am PC
Also wie ich geschrieben hatte, klappte es bei mir bisher mit Ubuntu 20.4.1 und aktuellem DSM 6.2.3:
* ERFOLGREICH mit NUR einer Disk im 220+ und nach normalen Shutdown dann diese im PC ( das funktionierte bei Dir doch auch, oder?)
* ERFOLGREICH mit gesyncten 2 Disks im 220+ und nach normalen Shutdown dann nur EINE (Bay2 !!) einzelne Platte am PC in einem 2-fach USB-Adapter (Innatec FD2002 ) am PC
Habe jetzt nochmal probiert und und auch mal die die einzelne Platte aus Bay 1 verwendet und da teilweise, auch kein Glück gehabt mit ähnlichem Fehler dass Syno220:2 mdadm Raid bereits vorhanden ist. Das war wohl immer dann der Fall, wenn ein md127 unter /dev auftauchte (einfach /dev nach Zeitänderung sortieren lassen, dann sieht man schnell was in /dev neu hinzukommt beim Anstecken des USB-Adapters.)
Es liegt bei mir scheinbar am Zeitpunkt wann ich den USB anschließe - ich habe das bisher immer erst nach Start des Systems gemacht, das beste Ergebnis bekomme ich wenn ich die Platte erst nach sudo -i anschliesse. also noch vor Aktualisieren des mdadm (zumindest bei ubuntu aktualisert er das - bei dir mit Mint sind ja beide Pakete schon aktuell).
Wenn unter /dev vor dem mdadm -Asf && vgchange -ay nur die verschiedenene sdc oder sdbs bei Anstecken erscheinen und kein md127 dann klappt es auch mit der Bay 1 Platte (einzeln).
Allerdings erscheint dann (manchmal) ein old PV header WARNING, aber sobald danach ein /dev/vg1000 erscheint, kann ich trotzdem normal
mount /dev/vg1000/lv /mnt -o ro durchführen und der Zugriff über /mnt ist möglich.
Also somit:
* ERFOLGREICH: mit gesyncten 2 Disks im 220+ und nach normalen Shutdown dann nur EINE (Bay1 !!) einzelne Platte am PC in einem 2-fach USB-Adapter (Innatec FD2002 ) am PC klappt, aber manchmal wenn md127 erscheint dann geht es nicht
Zudem habe ich es bisher nicht hinbekommen das md soweit zu deaktivieren und zu resetten um den USB im laufenden System erneut ab/anzustecken und erkenne zu lassen , sodass es nochmal funktioniert - somit ist bei jedem Fehlversuch ein kompletter PC Neustart nötig (dazu fehlen mir die lvm/mdadm/btrfs Kennnisse.
Als letztes habe ich in den 2 Bay USB-Adapter beide Platten nochmal gleichzeitig gehängt und auch das klappte mit (old PV header WARNING), solange nach USB anstecken nur sdb1... und sdc1... Platten im /dev erschienen.
* ERFOLGREICH: mit gesyncten 2 Disks im 220+ und nach normalen Shutdown dann BEIDE Platten am PC in einem 2-fach USB-Adapter (Innatec FD2002 ) am PC klappt
Also diesmal bei mir auch ein gemischtes Bild, am Besten klappte es mit nur der Bay2 Platte. Sobald md127 auftauchte half bei mir nur Reboot und erneuter Ansteckversuch. Insgesamt habe ich aber auf alle Platten zugreifen können.
Beide Platten booten wieder problemlos im NAS.
Werd mal sehen, dass ich aus dem Boot-Linux heraus noch Textfiles auf den USB schreiben kann um die Ausgaben einfacher zu dokumentieren.
Ein Versuch wäre, aufgrund der old PV header WARNING, tatsächlich mal (wie im Syno-Artikel geschrieben) ein Ubuntu 18.04 zu verwenden, ggf. sind die alten Tool-Versionen da besser auf die Synovariante "abgestimmt" -hab noch nicht per ssh nachgesehen welche Versionsnummer die einzelnen Komponenten auf der Syno haben.
Update:
auf dem 220+ wird btrfs-progs version 4.0 angegeben
und
https://packages.ubuntu.com/search?keywords=btrfs-progs zeigt bei 20.04 Version 5 also vielleicht ist bionic tatsächlich näher am Original wenn man nichts updaten/verändern will auf den Platten:
* mit NUR einer Disk im 220+ und nach normalen Shutdown dann diese im PC ( das funktionierte bei Dir doch auch, oder?)
* mit gesyncten 2 Disks im 220+ und nach normalen Shutdown dann nur eine einzelne am PC (bay2) in einem 2-fach USB-Adapter (Innatec FD2002 ) am PC
btrfs tools sind gleich, Repos sind bei Mint und Ubuntu gleich.
Ich habe es versucht vorher mit ubuntu 19 und auch ubuntu?? auf welchem das Desinfekt von Heisse aufgebaut ist.
Das Beste was ich erreichen konnte war der Fehler mit dem Filesystem.
Momentan scheint es mir dass eine Disk gar nicht richtig erkannt wird, wenn ich beide Anschliesse, dann gibt es Anzeichen dass etwas erkannt wird.
***Geht es bei dir nur mit einer Disk? Oder wie genau schliesst du die Disk an?***
Also wie ich geschrieben hatte, klappte es bei mir bisher mit Ubuntu 20.4.1 und aktuellem DSM 6.2.3:
* ERFOLGREICH mit NUR einer Disk im 220+ und nach normalen Shutdown dann diese im PC ( das funktionierte bei Dir doch auch, oder?)
* ERFOLGREICH mit gesyncten 2 Disks im 220+ und nach normalen Shutdown dann nur EINE (Bay2 !!) einzelne Platte am PC in einem 2-fach USB-Adapter (Innatec FD2002 ) am PC
Habe jetzt nochmal probiert und und auch mal die die einzelne Platte aus Bay 1 verwendet und da teilweise, auch kein Glück gehabt mit ähnlichem Fehler dass Syno220:2 mdadm Raid bereits vorhanden ist. Das war wohl immer dann der Fall, wenn ein md127 unter /dev auftauchte (einfach /dev nach Zeitänderung sortieren lassen, dann sieht man schnell was in /dev neu hinzukommt beim Anstecken des USB-Adapters.)
Es liegt bei mir scheinbar am Zeitpunkt wann ich den USB anschließe - ich habe das bisher immer erst nach Start des Systems gemacht, das beste Ergebnis bekomme ich wenn ich die Platte erst nach sudo -i anschliesse. also noch vor Aktualisieren des mdadm (zumindest bei ubuntu aktualisert er das - bei dir mit Mint sind ja beide Pakete schon aktuell).
Wenn unter /dev vor dem mdadm -Asf && vgchange -ay nur die verschiedenene sdc oder sdbs bei Anstecken erscheinen und kein md127 dann klappt es auch mit der Bay 1 Platte (einzeln).
Allerdings erscheint dann (manchmal) ein old PV header WARNING, aber sobald danach ein /dev/vg1000 erscheint, kann ich trotzdem normal
mount /dev/vg1000/lv /mnt -o ro durchführen und der Zugriff über /mnt ist möglich.
Also somit:
* ERFOLGREICH: mit gesyncten 2 Disks im 220+ und nach normalen Shutdown dann nur EINE (Bay1 !!) einzelne Platte am PC in einem 2-fach USB-Adapter (Innatec FD2002 ) am PC klappt, aber manchmal wenn md127 erscheint dann geht es nicht
Zudem habe ich es bisher nicht hinbekommen das md soweit zu deaktivieren und zu resetten um den USB im laufenden System erneut ab/anzustecken und erkenne zu lassen , sodass es nochmal funktioniert - somit ist bei jedem Fehlversuch ein kompletter PC Neustart nötig (dazu fehlen mir die lvm/mdadm/btrfs Kennnisse.
Als letztes habe ich in den 2 Bay USB-Adapter beide Platten nochmal gleichzeitig gehängt und auch das klappte mit (old PV header WARNING), solange nach USB anstecken nur sdb1... und sdc1... Platten im /dev erschienen.
* ERFOLGREICH: mit gesyncten 2 Disks im 220+ und nach normalen Shutdown dann BEIDE Platten am PC in einem 2-fach USB-Adapter (Innatec FD2002 ) am PC klappt
Also diesmal bei mir auch ein gemischtes Bild, am Besten klappte es mit nur der Bay2 Platte. Sobald md127 auftauchte half bei mir nur Reboot und erneuter Ansteckversuch. Insgesamt habe ich aber auf alle Platten zugreifen können.
Beide Platten booten wieder problemlos im NAS.
Werd mal sehen, dass ich aus dem Boot-Linux heraus noch Textfiles auf den USB schreiben kann um die Ausgaben einfacher zu dokumentieren.
Ein Versuch wäre, aufgrund der old PV header WARNING, tatsächlich mal (wie im Syno-Artikel geschrieben) ein Ubuntu 18.04 zu verwenden, ggf. sind die alten Tool-Versionen da besser auf die Synovariante "abgestimmt" -
Update:
auf dem 220+ wird btrfs-progs version 4.0 angegeben
und
https://packages.ubuntu.com/search?keywords=btrfs-progs zeigt bei 20.04 Version 5 also vielleicht ist bionic tatsächlich näher am Original wenn man nichts updaten/verändern will auf den Platten:
Paket btrfs-progs
bereitgestellt durch: btrfs-tools
- bionic (18.04LTS) (admin): Checksumming Copy on Write Filesystem utilities
4.15.1-1build1: amd64 arm64 armhf i386 ppc64el s390x - focal (20.04LTS) (admin): Checksumming Copy on Write Filesystem utilities
5.4.1-2: amd64 arm64 armhf i386 ppc64el s390x - groovy (20.10) (admin): Checksumming Copy on Write Filesystem utilities
5.7-1: amd64 arm64 armhf i386 ppc64el s390x - hirsute (admin): Checksumming Copy on Write Filesystem utilities
5.9-1build1: amd64 arm64 armhf i386 ppc64el s390x
Zuletzt bearbeitet: