sbv3000

if your system boots ok and is found on the LAN, then you choose the migrate option, retain settings. That will 'overwrite' the 6.1 install

I guess it depends on what you mean by 'borrowed time' Synology seem to be pretty good at maintaining the two latest DSM versions (6.1 and 6.2) and providing update packs and fixes, they have also supplied a fix for a recent flaw in DSM5.2, even though that O/S is out of support and not being developed. Your borrowed time might well be the failure of the hardware before DSM is unsupported:) Syno may release a 6.2.x update that changes significantly the DSM setup which might cause issues with the loader that cant be worked around, but in that case just stick with the previous version. ATM I'm running some 5.2 boxes which are 'fit for purpose' using old AMD embedded mobos, and on my 6.1.x environment I can't see any major reason to go to 6.2, for me not enough of a feature improvement to do.

You should be able to update directly to DSM5.2 using the 5967.1 image from the loader page. Ensure the pat file is the correct one from the Synology 5.2/5967 archive https://archive.synology.com/download/DSM/release/5.2/5967/ For DSM5.2 you don't need to make any changes to the USB boot device, just create your image. Once the machine is booted you can migrate, (keep settings or delete) then complete the update. Once that is completed you could look at updating to 6.1, and just follow the published tutorial 5.2>6.1. I would do a hardware test using a spare hdd and 6.1 loader to make sure you system is ok with 6.1 then connect you raid drives and migrate, but do a data backup either way before you start 'playing'

It might be. Because its a software raid system the underlying hardware should not matter, provided all the disks in the raid can be 'seen' by the hardware and software. I would do a test with a spare HDD, set to IDE, install a test DSM/volume then swap to ahci. If you can still see the volume it should be ok for your raid. I would do a backup of you critical data though.

you might need to switch the controllers to ahci mode

just to check, you can install fully to the test HDD with no errors (pat corrupted etc) and its only after the first boot with dsm installed that the box can't be found? try booting with the test hdd disconnected so that you are only using the 'installed' boot usb. If that fails to find, it might be that some drivers/modules on the usb are being 'overwritten' by the versions on the pat file, or the driver version used/installed into the DSM partition is failing. compare to a clean boot usb that has not been possibly updated I'd also try a 'minimal hardware' boot, by disabling all devices (sata controllers, usb's, audio, parallel, firewire etc) except for the onboard sata needed for the test hdd. Connecting a serial port for full boot diagnostics might give you more info on failing modules.

Try disabling the onboard audio in case that has a conflict with the nic resources. Also try the 3615 loaders and also leaving the mac address blank. if you have a usb/serial adapter you could try a serial port connection and check the loading process for drivers/modules. could also try a live ubuntu or mint boot and check the pci devices and check that the nic is on the supported/enhanced module list.

check the serial numbers of the drives as shown in Storage Manager and then have a look at the labels on the drives in the box to match up. I usually label by sata leads with the DSM drive numbers for diagnosing problems like this

this might work if the drivers installed by DSM are then added to the usb

You will need to connect a monitor and keyboard to the mobo to setup the bios correctly for boot devices, serial connection, disabling other devices (sound/parallel etc) and to do your initial boot tests and debugging. Once you are working the monitor and kb can be disconnected

Why are you connecting the serial console? This is usually used for debugging boot loader issues. If your XPE box is running ok, you don't need serial connection. You can use telnet/ssh to access the system for most diagnostics. Anyway, check the FAQ for the correct serial settings and maybe also try another connection app like putty.

You should be able to update the S/N to a 'personal' one using any string of letters/numbers of the correct length. You don't need a generated S/N

Using 'real' serial syno serial numbers on xpe is unfair on synology, probably mis-use of their servers/ T&Cs and is something the forum discourages. Having said that, lots of people have edited their grub files to change the SN to a 'personal' one successfully, so it does work. Suggest you check the file carefully before you write it to your boot image, for example, check that you have write permissions on the partition in osfmount etc

Yes, setup XPE/DSM on your bare metal, create raid, transfer data then migrate the drives to the 415. Check the FAQs for how XPE works, basically it emulates the internal boot loader of a syno box, DSM is installed on all drives as the main o/s. You are right that there may be specific hardware drivers per device, but the DSM migration process takes care of that, when you migrate you will use the .pat file for the 415 and that will 'overwrite' if necessary the 3615/7 hardware drivers. The migrated DSM will also install the correct packages for the hardware. If you keep the XPE build minimal, just let DSM install the 'mandatory' apps (file station etc) that should be fine.

In theory your process should work. However if I were you I would put the drives directly into your XPE box and move the data, then swap them to the 415. Its less steps and less risky. I would also check the DSM version on the 415 and update it to match the XPE boot loader version, again less risk if your DSM versions are the same. I'm guessing you have tested your xpe hardware carefully to make sure the NICs, disk controllers are working? Worth noting as well that the controllers and other hardware in the xpe box may limit the transfer bandwidth regardless of NIC speed, so you might want to do a test first.

Before you transfer your hdds to the 918+ I would update the DSM boot loader firmware on it to the same base version as you have on your xpe box (use a spare hdd and install the dsm .pat file to install it). You should then be able to migrate and (imho) its less risky if the DSM base versions are the same. If your xpe box has updates patches added, these will be lost and you will have to reapply.

It depends what you want to check the status of I would not use SSH for that. That would mean opening SSH access and setting up a client, perhaps to run scripts - all complicated if you are a 'noob' Why not look at the monitoring that DSM already has built in (Control Panel > Notifications) and setup smtp email to send you an alert email depending on the event If you want more detailed monitoring then look at an SNMP software like paessler prtg.

Some interesting results across different platforms and setups. But I'm wondering that if we are trying to see where the performance issue may be, the tests should be on the same hardware with 1) the previous loader, 2) the latest and 3) a non-syno NAS, eg OMV. Still lots of variables that could make a difference, (Linux kernel, drivers). Maybe another test could be to check perf with clean installs, and then an upgrade.

Try the following Use the 6.1 loader for DS3615 'as is' and make no changes to SN/MAC, just edit grub.cfg to your correct USB vid/pid If that works and you can install DSM fully, then check if your Solarflare card is working (unlikely) but get the PCI and loaded drivers list for info. Create a new USB loader with the enhanced extra.lzma file, boot and see if the Solarflare works. If its based on a supported chipset included in the file then you are 'good to go', after you alter the SN/MAC to your settings. The 6.2 loader is (imho) still evolving, especially the add on drivers, but you can try it as well. Testing with 6.1 will be a good way to get familiar with the whole XPE/DSM setup process.

Avoid using Syno DDNS, its not fair use of their servers, see the faq If you look at the DDNS options in DSM Control Panel > External Access > DDNS, use one of them and or with a VPN. You don't specify your XPE hardware, but in theory a migration from a real syno box to XPE is just that. I would; 1) Test your XPE hardware with a spare HDD, make sure the disk controllers and NIC works and you can install DSM ie no vid/pid errors 2) Migrate to the same version of DSM as on your real syno box - If you have updated that to > 6.1 or 6.2 boot loader versions, you might be better adding your raid drives with the test hdd still attached (delete any volumes on the test HDD) and repair the system partitions. If thats the case then do a backup/restore of your syno box configuration to the XPE box to the test HDD before you migrate Whatever process you follow you should backup your critical data from the real syno box.

try setting the macs to the real addresses of the two nics rather than a random number string

have you set mac1 and mac2 addresses for both adapters?

personally I am sticking with 6.1 at the moment, imho 6.2 is still late beta, as this thread shows. I'm testing it myself, but wont be upgrading my live systems yet

I would not recommend running XPE/DSM in a 'Production' business environment, its not 'designed' for that. Check out FreeNAS, NAS4Free or (best option and closest to DSM) Open Media Vault. (OMV). If your CTO/CIO is happy for you to use 'pirate' software ( ) then your best option might be disable the onboard broadcom NICs, install a dual port Intel (you probably have loads in the spares box) and work with that

if you are a 'newbie' to NAS/RAID etc, enable SHR and stick with that. Its software raid, but flexible adding disks of different sizes, data recovery, volume management etc.