flyride

It doesn't work that way, each drive has a write serial number. The write serials are no longer in sync across the whole array. If the array wouldn't start because of not enough members, it would be up and healthy now, but it managed to start degraded and something in DSM wrote to it. It's probably innocuous and could be forced, but it's your data and I would never recommend that unless the data was otherwise irrecoverable.

If all the drives are present and it is not reporting healthy, then something wrote to the array while it was in degraded mode. In that case you ought to resync. If you want to continue with an upgrade plan, the controller/drive mapping needs to be understood. Nothing in your synoinfo.conf would cause the problem. Can you post the Disk Manager Overview now? You might feel like you've gone through a wringer, but your data was not at risk. And you have corrected two significant issues: vSCSI controller conversion to vSATA, and adding FixSynoBoot.sh, both of which are needed for a successful upgrade.

You may upload that file if you like (please upload an actual file or use a spoiler to keep the post short). I don't think it's a factor here, but never say never...

Well let's remove HD2, SATA controller1, floppy and CD, they are all not necessary. Please do that from the web client. Boot back up and see where we are.

You cannot have all those controllers in the system. Is this vCenter we are looking at? I find it hard to believe you cannot remove the base controllers from the image. Was the VM built from the "Other 3.x Linux 64-bit" template as the tutorials state? From my web access to my ESXi host, I see this on my production VM: Controller 0 with loader, controller 1 with virtual drives (RDM's in my case), and a PCI passthrough HBA.

What hypervisor environment is this?

Something else changed. Are there any other controllers (even with no drives attached to them) remaining in the VM? Let's try SataPortMap=444 and DiskIdxMap=00 This is a purely diagnostic/discovery test and the best case is that 4/5 drives on your HBA are visible, but it will tell us conclusively how these are getting mapped.

That's fine, just do them in order.

Do me a favor, in ESXi, modify the SATA Controller 0 then save. Then modify the SATA Controller 1, then save. Finally remove and add the passthrough HBA. See if that changes anything. As long as you don't write anything to your array you won't have to resync when we get this sorted out.

If you happen to be editing the hardware configuration of the VM, it may be reordering the PCI addresses of the devices from boot to boot. Let's regroup on this as I am losing track of the system state due to changes: Try: SataPortMap=1 DiskIdxMap=0C00 This is not technically correct but should work for most unknown configurations.

Ok, I think I understand now. Somehow your passthrough controller is being enumerated before the SATA controllers. This is not typical. SataPortMap=811 DiskIdxMap=000C08

<delete, incorrect assessment>

Also for what it's worth, the SCSI virtual controllers don't work in 6.2.x so that is one of the reasons your upgrade failed. Using SATA controllers for 6.2.x is clearly covered in all the tutorials.

Too many changes at once. Post your ESXi VM hardware page. Post your grub.cfg info

It is not best practice ever to use a RAID card with DSM. For best performance, features and data safety, always present raw disk to DSM.

Ok, the line we are interested in grub.cfg is this: set sata_args='sata_uid=1 sata_pcislot=5 synoboot_satadom=1 DiskIdxMap=0C SataPortMap=1 SasIdxMap=0' Specifically DiskIdxMap and SataPortMap. These really need to be set for DSM to survive a major version upgrade with a multi-controller environment such as yours. In your VM, you should have a SATA Controller #0 with the loader vmdk attached to it as dev 0:0 You should have a 50MB vmdk which should be attached to SATA Controller #1 as dev 1:0 - if this is not correct, please advise. The 50MB vmdk is not strictly necessary, but it's a good insurance because it has a copy of DSM on it in case something happens to your passthrough HBA. Then you have your passthrough HBA, for a total of three different controllers in the system. These controllers are in PCIe bus slot order (SATA 0, SATA 1, HBA). SataPortMap helps DSM know how many slots to attribute to controllers. Your SATA 0 has 1 drive attached, SATA 1 has 1 drive attached, and HBA supports up to 8 (correct?). Therefore, your SataPortMap=118. If you delete SATA Controller 1 and its vmdk, SataPortMap=18 DiskIdxMap helps DSM know how to map drives to drive letters. We don't need access to the loader (nor do we want it in the Disk Manager) so it is mapped beyond the allowable slots by default (0C = 12, which is > MaxDisks enumerated from 0). The SATA 1 vmdk needs to be accessible as /dev/sda, so it's value is 00, and the HBA needs to be accessible starting with /dev/sdb, so it's value is 01. That makes DiskIdxMap=0C0001. If you delete SATA Controller 1 and its vmdk, DiskIdxMap=0C00 You can edit grub.cfg with nano or vi using the mount synoboot command in the prior post in order to make these changes. The net effect you should see is in Disk Manager Overview, the gap between your virtual disk and HBA disks should disappear.

Sounds good. I'm not 100% clear on your configuration now. Did you get rid of disk 5 and Volume 1? Three preparatory steps: 1. Please print output of cat /proc/mdstat 2. Install FixSynoboot.sh per the instructions here: https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/ 3. Retrieve the current grub.cfg from your loader and upload it. You can do that by mounting your USB key using OSFMount or you can mount /dev/synoboot1 using the procedure below: $ sudo -i # mkdir /mnt/synoboot1 # cd /dev # mount synoboot1 /mnt/synoboot1 # cd /mnt/synoboot1/grub # cat grub.cfg

It should, but you really should review the upgrade thread and see if someone has successfully upgraded using your platform/NIC. https://xpenology.com/forum/topic/29401-dsm-623-25426/ And, rather than just "taking the plunge" why don't you temporarily pull your drives and USB key, then install 6.2.3 clean on a new key and blank drive, and then you'll know if it works ... Annnnnd, have a backup.

No shortage of discussions talking about upgrading. Most recent one today:

You'll want to select a "Migration Install." Some have reported that installing FixSynoboot.sh is necessary before starting the upgrade to avoid ERROR 21 and failure. The other pitfall with the 1.03b loader that is commonly encountered is the requirement to set BIOS/Legacy/CMS boot rather than EFI, which worked on 1.02b and the same DSM platform (3615xs/3617xs).

This is an old post and we have achieved better clarity and documentation since that was written. FMI: https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/ Recent discussion: https://xpenology.com/forum/topic/13030-dsm-5x6x-cpu-name-cores-infomation-change-tool/?do=findComment&comment=148590

Speaking to your second issue (fan):

Ok, wave a flag when you are done checking out your hardware. Obviously you want things stable before trying a migration. But I think we can resolve your upgrade problem with some simple loader settings when you are ready.

All I can say is try it and see, test the install for hardware transcoding like you did with everything else. To my recollection, few used the DS916+ image since by the time folks really got it working, 6.2.x, DS918+ and Jun's new loaders were available and so they went to those. IMHO transcoding is overrated, mostly people want to watch on their TV and a mobile device. Download or rip the version of the media that your streamer will handle directly, and then use your PC to encode the small screen version if you need it, and then always Direct Stream and it's no problem.

Short answer is - you are unlikely to be able to do hardware transcoding with that hardware. Hardware transcoding requires a processor support Intel Quicksync, and the software stack, from the OS (DSM) to the application, have to support the same. When you boot up with compatible hardware on a DSM with a software driver, /dev/dri will appear. The only DSM OS that supports the transcoding software driver on your CPU is 6.1.x on DS916+ and nobody has done any real development on that processor, plus there is no upgrade path. DS3615xs has no OS software driver for hardware transcoding. DS918+ has the support, but your CPU is too old to run it. This table will help with your decision, but personally I think you are already using the software and features with 6.2.3 and DS3615xs that you should be with that motherboard and processor, and not to try and use hardware transcoding.