pigr8

it's a big jump from 5.2 to 6.2, a setup of mine didn't go that well and had to a fresh install instead of a migration (data remains intact btw). you shouldn't have any major problem.

no, and no. first you don't have to be on the latest cutting edge version of the software when you talk about server stuff, and HP clearly stated that will not support older gen hardware from now on and drivers not made for your gen could very likely no work correctly if not supported.. as you said, gen9+ images have drivers for newer hardware and pregen9 has older support, you would you you unsupported drivers on your server? i asked you this because i've tested 6.7 gen9 images on my microserver gen8 and some vm weren't working correctly giving rw timeout, rolled back to 6.5.. if you major upgrade your hypervisor from 6.5u2 to 6.7 and use drivers that are not compiled for that kernel you are going to have bad time, and newer drivers as HP said will not support older hardware so could easily break your system, same what's going on with new loader images and new kernel in synology. newer doesnt meen that your performance and stability will be better, expecially if your hardware is unsupported. and to be clear, b120i it's not an hardware raid controller, it's a fake raid, and no, your statement about driver fails and data lost is wrong since your software raid in the OS of your choice will handle recovery. ahci means that the physical drivers attached to the sata ports have no HP fake raid layer to deal with, and all of them are shown directly to the OS.. in that OS you can choose if and how handle the raid and what filesystem you want to use.. of example i have my 5 disks setup in a raid5 (actually shr1) array with a brtfs filesystem, but you could use another raid setup (even those that are not supported from your fake raid controller since it's handled by the os - like mdma) or another filesystem like zfs. that's why most users that have raid controller flashed in IT mode, to handle the array OS side and not in BIOS.. for example some LSI card dont have RAID5/6, if you flash them IT mode you can pass the disks to the os using the controller as a simple HBA card and then handle the raid array in OS, like FreeNAS os DSM. if you think that using the b120i is protecting you from data lost you are wrong, and btw raid is not a backup solution anyway so it doesnt have to protect you in the first place. m2c.

why do you use 6.7? there is no pre gen9 image for 6.7. I use 6.5u2 and works perfectly, with b120i set to ahci and the whole controller in passthrough to dsm.

i've done it, upgrading an old HP N40L that was on 5.2 up to 6.2.. had to change C1E in bios as suggested, used the 1.03b worked but DSM had troubles reading some config (user and volume ok, packages ok, but network tab was completly blank and so the smb tab.. applying changes didnt work, so i had to migrate only data and reset everything else, and it worked. lost a couple hours but nothing major.

i have a e3-1265L that is a Sandy Bridge and has no issue with ds3615xs or ds3617xs loader (i use ds3615xs because bromolow and packages), only newer ds916+ or ds918+ need haswell or later cpu. try to reset the system and not migrate, it should work.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.7-15284 Update 2 - Loader version and model: JUN'S LOADER v1.03b - DS3615xs - Using custom extra.lzma: NO - Installation type: HP Gen8 - ESXi 6.5u2 (build 8935087), CougarPoint in passthrough - Additional comments: upgraded from 6.1.7-15284 Update 2 (loader 1.02b) to 6.2-23739 Update 2 (loader 1.03b) without a problem, everything went perfect.. loader is a vmdk sata disk, the controller where the disks are physically attached is in passthrough to the VM so that has native control, nothing was lost.

That worked perfectly, tested Thank you so much!!

i'm trying to do something similar using a vmdk loader and a vmdk virtual drive, loader is on sata controller 0 and drive on sata controller 1, booting and installing is fine but in dsm the first disk is on port 2 (/dev/sdb), the loader 50mb drive is not showing (as intended) but i wanted the first drive be /dev/sda. that's just for testing, since my production vm has a 6 port sata controller in passthrough and i always had this problem, resolved by moving the loader on a usb drive and boot from there, so that the physical disks are sda->f.. using the loader with the vmdk methon puts my drives in sdb->g. any advice?

thanks i'm gonna try that!

Is it possible to have the value for SasIdxMap= for -1 disk? Thanks Jun

- Outcome of the update: SUCCESSFUL - DSM version prior update: 6.1.7-15284 Update 1 - Loader version and model: Jun's Mod V1.02b - DS3617xs - Using custom extra.lzma: NO - Installation type: VM - ESXi 6.5.0-U2 (Build 8294253) on HP Microserver GEN8 (with CougarPoint in passthrough) - Additional comments: REBOOT REQUIRED

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.7-15284 - Loader version and model: Jun's loader v1.02b - DS3615xs - Using custom extra.lzma: NO - Installation type: VM - HP Gen 8 - ESXi 6.5.0 Update 2 (Build 8294253) VM with CougarPoint in passthrough - Additional comments: REBOOT REQUIRED

- Outcome of the update: SUCCESSFUL after reinstall - DSM version prior update: DSM 6.1.6-15266 Update 1 - Loader version and model: JUN'S LOADER v1.02b - DS3615xs - Using custom extra.lzma: NO - Installation type: VMWare ESXi 6.7.0 (Build 8169922) - Additional comments: REBOOT REQUIRED, after reboot "error 7 version error", had to reinstall without loosing any data.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.5-15254 Update 1 - Loader version and model: JUN'S LOADER v1.02b - DS3615xs - Using custom extra.lzma: NO - Installation type: ESXi 6.5.0 Update 1 Build 7967591 on HP Gen 8 - Additional comments: REBOOT REQUIRED

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.4 15217 Update 2 - Loader version and model: Jun's Loader v1.02b - DS3615xs - Installation type: ESXi on Microserver Gen8 VM - Additional comments: - reboot after update - /etc.defaults/synoinfo.conf reset to default