IG-88

the downgrade script might work too, but you also have to assemble the raid1 partitions with mdadm you can also modify the /etc.defaults/VERSION manualy with a editor of your choice, there is not much the script does, its more important to choose the right numbers in my case i had a 6.1 15047 and the udpate to 6.1.1 15101 is not possible so i had to clean the system partition /dev/md0 to cleanly install 6.1.1 15101, for downgrade the changing of version numbers might be an option too in the end by formating with ext4 its 100% sure you will loose the configuration an plugins and start with clean defaults

hi, there is no "tandem" its just software raid on sata ports, if there is more then one controller providing the ports the order of the controller/ports might be important (depending on how you specify it in the syno config file, the default is 12 ports in a row, behind that the sata ports and then the usb ports) you might take thist into consideration if you want to move your drives directly to a new hardware viewtopic.php?f=2&t=16933 afaik the SataPortMap is about how the ports are spread over the controllers and the order of the ports in the case of your board (you have not specifiyd the brand) it might be SataPortMap=242 or SataPortMap=62 the 88SE9128 chip has only 2 ports so the 2 external ports you mention might have a diffrent (additional) controller you did not specify or there are "switchable" from 2 internal to 2 extrenal (sometimes seen this with controller cards, not so often on boards - provide more/exaxt information and the predictions get better) for 9 disks/ports you still missing ports so you will need a additional controller with at least 2 ports if you have all ports in a row, fill the "slots" (ports) without a gap and specify the ports (internal sata, external sata, usb ports, -> ) in the config correctly, then to set SataPortMap might be of no importance you should realy be carefull if you do this without a backup and tranfering the drives directly, if you do you should map the order of the drives from the "old" system and should do a test installtion on the new system with one drive (test-installing the dsm 6.x) and map the ports with a additional drive so you know exactly the order of the ports in you new system, after you are shure about the port mapping you could put in your 9 drives and install the new dsm to it (keeping the data raid) imho you should be prepared that the synology dsm riad fails and you have to use an live linux trom usb to manualy reasemble/recover your data raid and backup/offload it (after your first attempt of directly migarting fails spectecular) beside putting in all 9 drives in install the new dsm (without the option to modify the configuration first, the first boot will be with the 12 drive default of the 3615/3617) there is also the option to install one addtional (10th) drive first, modify the config according to the new hadware, put the 9 old drives in and see if the system comes up booting from the one drive and "spreading" the working system to the 9 "additional" drives (expanding the system partition raid1 from 1 drive to 10 drives) if that works you will have the system on all 10 drives an can remove the 10th drive it might be possible to test all this in a vm (virtualbox) before doing it with the baremetal but it will take some time its much safer and easyer to have a backup of all date

people her talking about a 6.1 15101 clean install and update to u1,u2 did this in vm and baremetal, no problems you updated from what version?

you can format the (raid) system partition, it's a raid1 over all disks with mdadm boot from a usb live linux, use mdadm to "assemble" the /dev/md0 and format it with ext4 (data on other raid aprtitions will be untouched and found after install, so harm done, you just loose the configuration und plugins) its a very clean solution (tryed it myself), no risk of cating any iffy stuff from prevois attempts after "cleaning" the system partition (raid1) you just plugin usb stick with jun 1.01 and install 6.0.2, you might even restore a backup of you previosly working configuration https://xpenology.com/forum/viewtopic.php?f=2&t=30805

synology has disabled that option in the newer 6.1 version but everything is still there, you just have to set 2 options in the config file and reboot to reenable it just search in the 6.0.2 thead viewtopic.php?f=2&t=20216&p=87110&hilit=shr+enable#p87110 btw. the default is just 12 drives you also have to tweak the config to 24 drives too there is a nice video if you dont like the "dry" stuff here as text

there was something aboute a Thecus lately, maybe its usefull for a start viewtopic.php?f=2&t=24630 when reading the following links there is the DOM, it has PCIe Slot, 2xMarvell 88SE6340 4-Port SAS-/SATA, Intel Celeron processor i'd expect that the 7700 is also more PC/Server like and the link above will help i would sugest to try jun loader 1.0.2a with 3615xs (fresh install with 6.1.1) http://www.tweaktown.com/reviews/2735/t ... ndex2.html http://www.tomshardware.de/N7700-Thecus ... 243-2.html

instead of the second link (outdated) there is a description how to di it manualy for dsm 6 http://xpenology.com/forum/viewtopic.ph ... wer#p99213 but no need to do that, the first link with spk for 6.1 works also with 6.1.1 (tested with u1 and u2, jun 1.0.2a 3515xs) btw. also usefull for VM usage, you can select acpi power button shutdown in the vm options to shut down the xpenology vm

versuchs mal hiermit, damit habe ich die 6er ans laufen gebraucht viewtopic.php?f=2&t=29582

ist normal, das hat synology über eigene spezielle hardware erledigt (genauso wie z.b. lüftersteuereung) , aber man kann sich ja mail als benachrichtigung konfigureiren, dann bekommt man eben eine mail und weis das es was zu tun gibt theoretisch kann man auch auf der konsole im linux graben wie die es erkennen und das script ein wenig anpassen, die kochen auch nur mit wasser (linux) und das software raid wird mit "standard" tools wie mdadm und lvm realisiert, genauso "begrenzt" sind dann eben auch die möglichkeiten wenn es darum geht einen fehler im raid zu erkennen (z.b. /proc/mdstat auswerten?) wenn man an den syno scripten rumspielt sollte man aber dran denken das das nach updates wieder zu überprüfen ist oder ob das angepasste nacj da ist oder überschrieben wurde - ist halt eine appliance, von hand dran rum basteln ist da nicht vorgesehen (zumindest aus sicht von synology) systemsteuerung / aktualis. und wiederherstellen / updateeinstellungen, dort nur wichtige updates und keinen zeitplan für automatische aktualisierung, dann wird er nur nach updates suchen wen man rein geht und fragen ob er runterladen soll, man kann dann entweder durchführen lassen oder es manuell runterladen und über den manuell button installieren. letzeres ist der weg man man am router der syno den internetzugriff komplett verbietet und dann updates einspielen will

hallo, mal so der vollständigkeit halber, wenn man die systempartition auf dem das linux liegt formatiert (ext4) dann wird danach beim installieren nur das system neu aufgespielt aber das raid mit den daten bleibt unangetastet da aber die systempartition ein raid1 über alle platten ist muss man ein recovery system von usb booten (live linnux oder spezielle recovery edition) und dann mir mdadm das raid1 "laden" (/dev/md0 mit allen platten, erste partition) und dann dieses device formatieren, wurd hier im forum im englischen bereich auch gut beschrieben, natürlich verleirt man seine einstellungen aber wenn man ein backup der syno konfigurarion hat (das beim einem backup eigentlich ummer mit angeboten wird) daann kann man nachher das alte system installiern (6.0.2) und dann das config backup mit der syno eigenen backup software zurückspeilen und hat wieder alles wie vorher, ansonsten ohne backup und neu einrichten aber man hat dann immerhin das ausgetestete 6.0.2 wieder

ich vermute du bist hier irgendiwe uaf dem falschen dampfer was LVM angeht ein synology software raid ist im grunde "nur" mdadm (fürs raid) und LVM für das volume (aber nur wenn man auf einem RAID aka Raidgroup mehrere Volumes haben will - so kann man den platz auf dem RAID beleibig zwischen den volumes darauf verteilen) man bekomme durch mdadm ein "großes" devive /dev/md2 das dann als solches von LVM benutzt wird, LVM weis im grunde garnichts von den raid darunter, für den ist das nur eine große disk auf der man was anlegen kann wenn man im diskmanager ein RAID5/6 anlegt beim anlegen des volumes auf der raidgroup angibt das man nur ein Volume haben will dann wird gar kein LVM benutzt dann hat man "reines" mdadm (/dev/md2) das dann mit fdisk partitioniert wird und dann formatiert wird (btrfs oder ext4) wenn also "disks" weg gewesen sind dann ist das nicht LVM sondern hat was mit mdadm zu tun und wenn das /dev/md2 deshlab nicht zur verfügung steht dann gibts auch nichts für lvm zu tun wie hast du bei 2 fehlerhaften platten und raid5 (1 platte redudanz) wieder ein laufendes raid5 bekommen, das kann erst mal so ohne weiteres nicht gehen wenn die zwei platten defekt/weg sind hier fehlt mir irgenwie etwas, ohne das wenigstens eine der "fehlende" platten wieder voll funktionsfähig auftaucht kann man das raid nicht wieder in betireb nehmen und nach den sachen weiter unten hast du 5 funktionierende lufwerke im raid, da kommen man nicht von 3 wieder auf 5 ohne das entweder die zwei platten wieder (unbeschädigt) da sind oder man das raid komplett neu anlegt (in letzterem fall kann es natürlich keine LVM mehr geben denn das /dev/md2 ist dann ein komlett neues/leeres device) das sieht soweit nach einen funktionsfähigen raid5 aus 5 platten aus, einzige auffäligkeit ist das es kein sda und sdb gibt außerdem ist die creation time 23.04.2017 aber zeimlich dicht am "jetzt" - also doch neu angelegt? und wenn ich mir die creation time des lvm aud der archive datei ansehe - 06.03.207 dann passt das auch nicht, das lvm kann nicht vor dem raid angelgt sein, erst erzeugt man das raid und oben drauf kommt lvm ansonten sieht man auch sehr schön am dem archive zeug das das lvm nicht aus "disks" bestand sondern aus /dev/md2 (nur ein physical device pv0) du hattest da drin 4 logigal volumes, eins das von synology zur reserve angelegt wurde, das normale "volume1" (das aber aus 2 segmenten besteht - mal irgendwas um-/aufgerüstet oder SHR mit sda/sdb?) und zwei iSCSI volumes zu je 15GB und 20GB - soviel kann man da zumindest rauslesen aber wenn in dem funktionierenden /dev/md2 keine LVM mehr zu finden ist und es wirklich noch das "alte" (richtige ist - was ich je bezweifle) dann würde nur richtiges datarecovery mit low level tools helfen, man müsste mit einem sektoreditor in /dev/md2 nach spuren der LVM Volumes suchen und sie mit den ihhalten der archive datei vergleichen evtl. kann man auch mit irgendwelchen kommendos die alte lvm archive datei dem /dev/md2 "aufzwingen" aber das würde die daten auf dem volume verändern und weites recovery erschweren/verhindern (da man daten verändert) - aber wenn man sonst das ganze wegwerfen würde kann man das zumindest als letztes mittel vor dem abfalleimer machen und sehen was passiert - allerdings habe ich da nichts parat, das habe ich noch nie gemacht, ist nur rein theoretisch was man machen könnte (bzw. was ich versuchen würde) man kann auch den ihalt von /dev/md2 "sichern" mit dd aber da bräuchte man eine 6TB platte, viel zeit um sich mit data recovery zu beschäftigen, ... das wird man nur machen wenn es kein backup gibt und die daten echt wichtig sind (bzw. kann man so eine mit dd erstellte kopie vermutlich auch datenrettungsprofis geben aber sowas ist in der regel für privat zu teuer) ich bin mir zwar nicht ganz sicher aber - mein beileid zum verlust der daten

hallo, zum einen können plugins durch ständige aktivität verhinder das die platten zur ruhe kommen (ich meine in dem zusammenhang plex gelsesen zu haben) - also mal zum testen im packetzentrum möglichst viele plugins deaktivieren um zu testen ob es dann geht zum anderen kommen da auch noch die dockerpackete ins spiel grundlegend muss man daran denken das die systempartition auf der auch die logs landen auf ALLEN platten als raid1 läuft (in der konsole mal "cat /proc/mdstat" eingeben, dann sieht man das auch ganz gut) und wenn er da hin schreiben will muss er eigentlich auf alle platten schreiben

yes, as i already had to use virtualbox for testing, it's easy to clone, backup, re-use or to rebuild from scrath the barematel system is for real life usage, not a playground i would expect thats the part where some tinkering is needed to get around the "protections" (or traps?) synology has build in, so atm i'm not touching this, i'm not planing to dive deeper then compiling extra drivers and providing modified extra.lzma whatever works is good, as long as it is easy to setup, the chroot plugin for DSM was a easy startpoint, a "normal distribution" with the usual tools und package repositorys might be more comfy in the end and will not so easy break as DSM/Xpenology (after one or the other update, -> 6.0.3 or 6.1.1)

use open media vault (runs just from usb stick or extra disk) or just plain ubuntu? if power consumption is so important you can also just take 2 bigger drives as raid1 and expect it to run most of the time, calculate it and count the money the power costs per year i dont think modding something like dsm/xpenology to heavy defeats the whole purpose, it should be easy to set up, to use, to maintain - its much of a balance act as it is without tinkering on partitions and whatever

Hoooo ... thanks I work on my computer. But only for version 6.0. It is not possible for version 6.1 ???, with this system or another, in my system extra.lzma is necessary. Thank you. "This is only for v1.01 NOT v.1.02a." - it rwaly means that it is not for 1.02a aka dsm 6.1 dsm 6.1 is using a differnt kernel so kernel modules for 6.0 (loader 1.01) will not work on 6.1 i don't know what you mean or wanted to know by that

we already know that it works in general on baremetal, the interesing part is what hardware is working for you?

not usable as the hba will control the raid an dsm would not see much, there is a reason why it firmare is used for lsi's i wrote something about hp pxxx here viewtopic.php?f=2&t=32804

every disk conains a dsm sysem partion and as they run in raid1 they should contain the system log (when looking for reasons what faield) just mout one of the 3 disks on a linux (read only in the fist attempt) and have a look in /var/log if there is something useful

i downloaded it but as chege states its no good, my 3617xs vm did not like it too on updating (have'nt tryed fresh install) as synology pulled the plug on it i don't think its realy usefull to use it

why not using the img file you used to create the usb stick with? you might also serch the forum for using 5.2 with esx server there is a way to use the img file "as" vmdk in creating a *.vmdk test file containing information about the *,img file (you can have a exaple in jun's loader 1.02a) thats inside the synoboot.vmdk (synoboot.img file in the same directory) # Disk DescriptorFile version=1 CID=6ccf51e5 parentCID=ffffffff isNativeSnapshot="no" createType="vmfs" # Extent description RW 102400 VMFS "synoboot.img" 0 # The Disk Data Base #DDB ddb.adapterType = "lsilogic" ddb.deletable = "true" ddb.encoding = "UTF-8" ddb.longContentID = "7e24a756b77e33e24ac940cc6ccf51e5" ddb.thinProvisioned = "1" ddb.uuid = "60 00 C2 9a ee da ca 33-df 5e 04 3f 80 55 f9 62" ddb.virtualHWVersion = "10" "102400" is the count of 512 Byte Sectors in the synoboot.img used so if you create a image from your usb stick with Win32DiskImager you might be able to use that image when alterring the vmdk file accordingly

i dont think Pxxx controllers are possible, they usualy do not present disks through there drivers to the os, only configured raid arrays and afaik there is no firmware/driver that can change this there are Hxxx controllers with lsi controller chips on it that can be equipted with a "it firmware" (it = initiator target) to be used in a way dsm would need it the only thin that might work is to define a raid0 for each single disk, if a driver for those raid controllers is integrated you will see those as drive but thats no good, you dont get warnings about defective drives, no samrt data, even no serial number (not shure about that), not recommanded to do that (beside you might see bad performance)

if its just about trying it out, why not format the disk under windows as usual and with vmware just plainly create a virtual drive as file on that new drive letter, if its not about performace or keeping the date it does'nt matter if you crate thin disks you also might create a number of virtual disks in the vm and try out how to migrate from a basic disk to a raid1 or how to create a raid (1 or 5)

you have'nt mentioned what dsm version or bootloader i'm using virtualboy but i expect esx will be the same when installing, for boot, you use the same image with a vmdk definition file as you put on usb stick (synoboot.img) you could just the the same image as you copyed to your usb stick or even make a new image from the usb stick an use it in esx (there should be a how to for esx explainig what vrtual hardware und disk configuration to use the real problem will bei the disks, how did you plan to bring the disks into the vm? do you have vt-d and plan to give the controller to the vm or was rdm for every disk the plan? do you have your disk in a diskgroup or just a plain volume (without diskgroup the disk will have to be in the same order as befor or the raid might fail)

how is synology's diskgroups translated into "normal linux" in terms like mdadm or lvm?

cpio and lzma was working without installing explicitly (lzma -V was calling it XZ Utils), installed the package and now its "LZMA command line tool 9.22", does'nt hurt to have a newer one, added the package above