pigr8

- 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

how is your setup exactly configured? i mean where have you esxi booting from? and where is your current datastore? what cpu are you using that allows you vt-d? my setup is the cleanest i can figure out: - the internal usb header with esxi installed in embedded (it always installs that way on a flash drive) - a pcie card supported by esxi (an asmedia 1061) with 2x sata 3 ports, 1 ssd and 1 hdd, ssd is the main datastore for the vms and the hdd is for snapshots and iso files. - the cougarpoint is passed through to the xpenology vm, 4 front bay populated and the 5 odd port is going to be asa i can find a wdred cheaply that way if i have to mess around with esxi i can swap out the usb drive and reflash it as needed without loosing the vms in the datastore if something goes wrong.. thats why i didnt install esxi on the ssd. the usb3 renasas controller is passed through another vm (router), i wanted to passthrough the usb2 also (to xpenology) but it went bad problems regarding the esxi boot. yes guides says that it has to be non-persistent but i run into troubles in every reboot of the vm where dsm wanted to repair and reinstall.. i figured it out after some testing that setting the synoboot to persistent fixed the problem, dont really know if there is a cleaner way to fix this.

i moved Plex out from XPenology and running it on a different VM in a different VLAN, i find it cleaner that way DSM is installed on the drivers that form the array, every disk has a partition and it's mirrored, the vmdk only contains the loader and it's loaded in ram at boot.. when you boot the first time in a clean system you indeed select where to install DSM, and ofc it has to be on the disk that you are passing through in the VM.. i didnt install anything because DSM was already installed on those disk, i transplanted the whole system from a running baremetal to a running vm with minimal downtime and no need to reconfig.so yes, DSM is installed on all the 4 disks and not only in 1 of them.. if you boot a real synology with only 1 disk it will install DSM on it, if you later add other 2-3-4 disks and DSM inizialise them it copies the system on every disk for redundancy.. that's why even if you loose the first original disk the system will boot anyway

Oh i didnt knew that you could split the Cougar controller in half, i didnt dig that deep into it since i wanted to use 5 disks in DSM anyway so i had to passthrough the whole controller bad performance? o i didnt notice any issue, actually i had DSM installed on that array (shr1/btrfs) when i had it running baremetal, when i switched to a VM the system was intact as before, it just booted and migrated a couple of seconds, on second reboot everything was running and performace wise (i use smb and nfs for different clients) it's like baremetal.. share write at 115mb/s, and i have clients and diskstation in different vlans, no issues. yes, i use only 2core and 1gb in XPenology since it's more than enough for it, all that it has to do is run couple of packages (sickrage and couchpotato), the shares with the relative authentication, brtfs snapshots for the array and nothing else, memory never goes above 70% in use (es. atm it's 43% ), and since you need to have the memory preallocated for the passthrough to work give it more than 1gb is pointless imho.. if i go to add surveillance station i'm gonna see if it needs more memory, give it 2gb is overkill, RAM is precious even if i have 16gb in the Gen8. I use the last 6.5.0u1 (5969303) from HPE, you can find it here https://my.vmware.com/web/vmware/details?productId=614&downloadGroup=OEM-ESXI65U1-HPE running on the Gen8 with a e3-1265L cpu and 16gb ram, loader is 1.02b for the DS3515xs with the latest DSM 6.1.3-15152 Update 4 running perfectly. the synoboot is in a 50mb vmdk in the SSD datastore (thick, indipendent, persistent) it's only for booting the system the 4 front drives are untouched. the server is in production and so is the dsm vm, next time i reboot or poweroff i could make an export and share it but it's nothing fancy at all

ESXi 6.5.0u1 Synoboot 1.02b DSM 6.1.3-15152 Update 4 updated via webui, reboot is necessary, everything went perfect

i use it where are you booting ESXi from? you cant boot ESXi from a disk attached to the ODD port since the ODD port is part of the 6 port sata controller.. you are booting ESXi from the ODD port and then during the hypervisor boot you tell him to detach the controller and give it to the VM you gonna have abad time i boot ESXi embedded from a usb stick in the internal usb header, have a second cheap pcie sata3 controller with 2 ports where i have my datastores (ssd) and have the whole Cougar Point passed through to the XPenology VM, everything works fine ESXi totally ignores the controllers and the disks attached to it. ps: in the DSM gui disk1 is the virtual boot disk (synoboot.vmdk), it's there but cant be read or written from inside DSM, disk2345 are the 4 front hdd bay, disk6 is empty but will be populated with another wdred.

u3 ok here on esxi, 1.02b with 3615xs

updated both Baremetal ans ESXi to 6.1.3-15152 u1 without problems everything is OK

download this: https://www.dropbox.com/s/ytimsezu9cl61xx/synoboot_1.02b_ESXi_only.zip?dl=0 the only option available is ESXi, so you should not have problems regarding boot choice, it's for DS3615xs (i find has a better custom package support than DS3517xs). - extract and upload synoboot.vmdk and synoboot.img in your datastore - create a new VM (HW Version 11 or 13) dependent if you are on ESXi 6.0u2 or ESXi 6.5b - operating system should be Other -> FreeBSD 64bit - set bios to EFI - set nic to VMXNET3, set the mac manual to the same as the one in the grub.cfg - set scsi controller 0 to "LSI logic SAS" - add sata controller 0 if not there yet present - add existing hdd -> browse datastore -> add synoboot.vmdk - edit this hdd to "independent - persistent" and sata 0:0 on controller 0 - add how many new scsi disk you like, thin provisioning - dependent - save and poweron the VM - from your browser, go to find.synology.com, it should pop-up, connect and install it (manual or from internet is the same), reboot after finish the setup - create a new volume to your needs, if you want shr you have to modify synoinfo.conf - download this zip for open-vm-tools https://www.dropbox.com/s/k4hc343gwdepiuf/open-vm-tools_bromolow-6.0_10.0.7-1.spk.zip?dl=0 - extract the zip, install the spk in package manager - now ESXi should see that vm tools are installed and running Pretty much done.

Figured out myself yesterday, i had to change the bootloadet img from "indipendent - non persistent" to "indipendent - persistent"

Hi, i'm testing the latest DSM version on ESXi 6.5 with the 1.02b loader, i got the VM up and running, first boot everything is ok and system does all the stuff to boot and install itself. This is the log for the first boot, before install https://pastebin.com/s7yuweeA This is the log after the first reboot, and everything looks normal to me https://pastebin.com/mH0gtxu8 This is the log after the second reboot, and all the reboots after this https://pastebin.com/EWsWQBk8 If i shut down the VM and restart it, this happens: https://pastebin.com/pjZH6z8W ------------upgrade Begin upgrade procedure No upgrade file exists End upgrade procedure ============upgrade Exit on error [7] Version number not match... and system goes in recovery, wants to fix via webui, than reboots fine everytime until i poweroff the VM.. after poweroff "Version number not match", fixes, reboots fine. Anyone knows why it does this? Thank You

+1

i tried, i was interessed to 916 too but doesnt work for me

i wanted to try 1.02b on my baremetal (hp gen8 with i3 3220t cpu), 3615xs loader tested and working, 3617xs loader tested and working, 916+ loader not working, hangs on boot: [ 0.192870] invalid opcode: 0000 [#1] SMP [ 0.194242] Modules linked in: [ 0.195217] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.10.102 #15047 [ 0.197217] Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 07/16/2015 [ 0.199283] task: ffff880200d23510 ti: ffff880200d24000 task.ti: ffff880200d24000 [ 0.201473] RIP: 0010:[<ffffffff8148f33e>] [<ffffffff8148f33e>] sha_transform+0x2e/0x12e0 [ 0.203924] RSP: 0000:ffff880200d27d60 EFLAGS: 00010092 [ 0.205485] RAX: ffffffff819c2a80 RBX: 0000000010325476 RCX: 00000000e8a4602c [ 0.207646] RDX: ffff880200d27db0 RSI: ffffffff819c2a80 RDI: ffff880200d27d98 [ 0.209730] RBP: 00000000c3d2e1f0 R08: 00000000efcdab89 R09: 0000000010325476 [ 0.211814] R10: 0000000067452301 R11: 0000000098badcfe R12: 00000000f33d5697 [ 0.213886] R13: ffff880200d27e66 R14: 0000000000000286 R15: 0000000000000004 [ 0.215986] FS: 0000000000000000(0000) GS:ffff88020ba40000(0000) knlGS:0000000000000000 [ 0.218407] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.220116] CR2: 0000000000000000 CR3: 000000000180d000 CR4: 00000000001407e0 [ 0.222202] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 0.224281] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 0.226362] Stack: [ 0.227048] 0000000000000010 ffffffff81842cc0 ffffffff81842ce4 ffff880200d27e66 [ 0.229395] 0000000000000286 0000000000000004 ffffffff812fa652 efcdab8967452301 [ 0.231747] 1032547698badcfe 00000000c3d2e1f0 ffffffff81842e10 0000000000000246 [ 0.234128] Call Trace: [ 0.234853] [<ffffffff812fa652>] ? extract_buf+0x62/0x140 [ 0.236492] [<ffffffff810579a5>] ? __wake_up+0x35/0x50 [ 0.238091] [<ffffffff812fa464>] ? account+0x104/0x290 [ 0.239617] [<ffffffff812fab9c>] ? extract_entropy+0x5c/0x170 [ 0.241334] [<ffffffff8115f047>] ? proc_register+0x67/0x140 [ 0.242982] [<ffffffff813e89fb>] ? neigh_hash_alloc+0x7b/0xb0 [ 0.244657] [<ffffffff813e8ab6>] ? neigh_table_init+0x86/0x2b [ 0.325107] [<ffffffff818a13af>] ? arp_init+0xc/0x47 [ 0.348100] [<ffffffff818a16c0>] ? inet_init+0x18e/0x27a [ 0.349743] [<ffffffff818a1532>] ? ipv4_offload_init+0x63/0x63 [ 0.351496] [<ffffffff810003aa>] ? do_one_initcall+0xea/0x140 [ 0.353222] [<ffffffff81876dc8>] ? kernel_init_freeable+0x13a/0x1bb [ 0.355053] [<ffffffff814909f0>] ? rest_init+0x70/0x70 [ 0.356589] [<ffffffff814909f5>] ? kernel_init+0x5/0x180 [ 0.358232] [<ffffffff814a2548>] ? ret_from_fork+0x58/0x90 [ 0.359868] [<ffffffff814909f0>] ? rest_init+0x70/0x70 [ 0.361422] Code: 8b 5f 08 44 8b 17 41 56 44 8b 47 04 44 89 d1 41 55 c1 c1 05 41 54 45 8d 23 55 8b 6f 10 41 81 c4 99 79 82 5a 53 8b 5f 0c 41 89 d9 <0f> 38 f0 06 45 31 d9 89 02 45 21 c1 41 c1 c8 02 41 31 d9 41 01 [ 0.369569] RIP [<ffffffff8148f33e>] sha_transform+0x2e/0x12e0 [ 0.371349] RSP <ffff880200d27d60> [ 20.207634] Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu1

Just updated the bootloader to 1.02b (3615xs), up and running

actually i'm on 1.02a (1.02a2 is for ds3617xs), the update went fine but at reboot with the 6.1.2-15132 i had no network, so cp /lib/module/update to /lib/module over vsp (virtual serial port ssh) and rebooted again, everything went back normal

told ya fellas

basta che riflashi un'altra penna e cambi vid&pid, nessun problema a riguardo è una cosa prevista

that is because it's missing the lan driver, you should be able to fix it instead of remark as do_no_update. as the op said, login in via console (serial, virtual, local, whatever) and copy the modules in the right folder, tha reboot.. it's a very simple fix that require less than a minute, it's not an update problem but a loader bug.

working on Baremetal Gen8

not working anymore, you need to have a legit serial (new format) and mac.

updated here too on a gen8 baremetal to u2, reboot required and fully working without intervention.