Zteam_steven

I need help for DS3617xs /DS3615xs with EFI Loader

Recommended Posts

Platform: HP MicroServer Gen8 & VMware ESXi 6.7 U3
Loader:1.03b (DS3617xs / DS3615xs)
DSM: 6.2.0 or higher
Using custom modules/ramdisk  If yes which one :  None / extra.lzma (ver0.5)
Hardware details:Xeon E3-1220L V2,8G ECC,SATA AHCI mode,VMware LAN:Intel e1000 /e1000e / VMNET
USB passthrough Boot failed,Loader and drivers cannot run in EFI mode

 

Problem description:
Jun loader 1.03b or add Driver extension (extra3617_v0.5_test/extra3615_v0.5_test,from @IG-88),USB-HDD for passthrough from ESXi host to a virtual machine (Synology DSM 6.2.x)

The boot mode is BIOS, the USB device cannot be recognized and cannot be started. 
This seems to be a persistent problem with VMware ESXI, and the official documentation does not provide a solution.
Try “Plop Boot Manager” to boot USB drive with DSM6.2, loader error occurred, after the boot failure, the loader boot sector is damaged.

 

If the boot mode is changed to EFI, the USB device can start and boot normally
After experiment,it allows the startup of legacy BIOS + MBR
But,DS3617xs/DS3615xa Jun loader 1.03b or add Driver extension (extra3617_v0.5_test/extra3615_v0.5_test),After startup, IP cannot be found.
I guess the loader kernel or network driver is cannot be used in EFI mode.

 

I tested loader 1.02b for DSM6.1.x again and it worked perfectly.Because it supports EFI / BIOS.

 

I turn off the USB arbiter of esxi, use RDM to map USB devices, and set it to xpnology boot. It can start and operate normally with loader 1.03b for DSM6.2.x
I don't know what esxi went through,because it works on a virtual SATA HDD,not a USB HDD,But in doing so, other USB devices will be restricted.

I also tried to passthrough the USB controller, which also failed.

 

I really need to support EFI's bootloader and driver for DS3617xs / DS3615xs,Can you help me?  Or, who has a better solution to the USB passthrough problem.


In addition, I also tested the extended driver ver0.5 by IG-88. 
When SMB transferring files on vmxnet3, it will quickly slow down to 0Kb / s until the network crashes.


Sorry, my English is not good. 
 

I want help, thank you again!
 

Share this post


Link to post
Share on other sites

You cannot use EFI mode with 1.03b loader.  Legacy boot only.  This is well documented.

 

Are you trying to use a USB key to start your system under ESXi?  This is not required, just use the virtual HDD provided in the loader distribution.  This works fine for legacy boot.

 

Share this post


Link to post
Share on other sites

Thank you. I know loader 1.03b can't boot with EFI.

I don't want to boot with a virtual disk. Because I need DSM USB key for other purposes, I need to control the physical usb device for other boot programs share..
It is either a physical DSM system or a virtual DSM system, independent of the platform.But the boot information is consistent with the data.
the loader usb key is share,It will occur at power up, before booting the system.
In fact, I hope Jun to release a new version of DS3617xs / DS3615xs loader, just like loader 1.02b,Working perfectly in EFI mode.

 

I am trying to use BIOS mode to solve the USB problem, which is limited by VMware and it cannot be changed.

So waiting for EFI loader is the only way I can think of.

 

The proven reliability has led DSM 6.2 to a Long-Term Support (LTS) version maintained until 2023.

Advanced LUN of Snapshot Replication,
Storage pool now replaces RAID Group and Disk Group to unify storage for Storage Manager, LVM different
Synology High Availability and Live Station. the new changes are worth upgrading.

 

 

Share this post


Link to post
Share on other sites

I think you will be waiting a long time for EFI-compliant loader for DS3615/17xs and DSM 6.2.x

 

You have a few choices:

  1. Stay on 6.1.7
  2. Upgrade your CPU to a Haswell+ chip so that you can run DS918+ (and loader 1.04b which supports EFI boot)
  3. Solve whatever is going on with ESXi that precludes USB passthrough when using legacy boot (I have not heard of this problem before)

No details have been provided on the ESXi problem or your "other programs boot share" requirement.  If you were to explain these issues further, maybe there is a solution.

Share this post


Link to post
Share on other sites

My platform is HP microserver gen8

This is my bootmenu interface.

 

My environment:
Usb-key1 is usb-cdrom, it is the first boot, it is used to start the odd HDD (HD5,esxi, default), and it is also a live CD (with boot PXE, ISO, IMG, Linux Live CD...)

Usb-key2 is DSM 6. X bootkey, located in the USB port, which is USB-HDD (HD0)

The CD-ROM has been transformed into a SATA HDD, which is located in the SATA port 5 (HD5) and running esxi 6.7 and VMFS datastore, including virtual machine, RDM, SCSI Lun, etc.

SATA standard 4-way disk:
Sata-hdd #1, running Windows client
Sata-hdd #2, running CentOS
Sata-hdd #3, running Windows Server
Sata-hdd #4, data sharing disk
...
Other tools menu, boot debugging command line, etc.

 

I will physically switch the multi operating system environment and co-exist with VMware virtualization. Multi hard disk is RDM mode.

My goal is that these drives can run completely independently and start on demand.

At the same time, it is also convenient for me to directly migrate the hard disk to other hardware compatible computer platforms.

However, most of the time, I don't use virtualization, I just start the synology DSM physical machine running mode.

I didn't add any hardware costs, and I also met my needs.

 

The problems are:

1. Esxi passthrough USB device, supports systems above windows and Linux v2.6.35
Other environments (MacOS) need to cooperate with vmware open-tools to drive.
But,initializes the USB controller and USB device after the operating system starts.

2. In legacy BIOS mode, USB and HID devices cannot be started as boot devices. This is what the VMware documentation says. In fact, it has been restricted since esxi5.0. but USB drives In EFI mode for boot is supported.

3. Jun loader 1.03b works in EFI mode, IP cannot be found, kernel and network driver do not match.
so the direct USB Key (USB-HDD 0) can't realize boot sharing.

Only Jun loader 1.02b is available in legacy BIOS and EFI mode.Corresponding to DSM 6.1.7, I am in use.

Now I would like to upgrade to DSM 6.2

 

Waiting for the new EFI version of Jun loader for ds3617xs / 3615xs

I guess there is no good way to solve the problem, or I can only give up the current use environment.

 

So I'm going to publish the questions and hope that other people can see them and give me better suggestions.

Or I hope @Jun can see my hope.Help me achieve it.

 

Thanks to all the friends have read , very patient.

 

 

Edited by Zteam_steven

Share this post


Link to post
Share on other sites
30 minutes ago, Zteam_steven said:

I will physically switch the multi operating system environment and co-exist with VMware virtualization. Multi hard disk is RDM mode.

My goal is that these drives can run completely independently and start on demand.

At the same time, it is also convenient for me to directly migrate the hard disk to other hardware compatible computer platforms.

However, most of the time, I don't use virtualization, I just start the synology DSM physical machine running mode.

 

It's not typical, but there is no reason here not to have two DSM bootloaders that access the same disks.

So use your USB DSM bootloader for baremetal and the image bootloader with Legacy boot from within ESXi.  As long as your boot menu USB can support working in Legacy boot mode.

 

On occasion of a DSM upgrade, you may want to do that on ESXi first and then use the img file to burn back to the USB key to be conservatively safe... you'll have to update the VID/PID and grub boot option but they are otherwise identical.  But even without that, I would guess that the second loader would realize the change and update quietly anyway.

Edited by flyride

Share this post


Link to post
Share on other sites

If USB passthrough mode of DSM updated, baremetal or the virtual machine,it's the USB-Key be updated synchronously, Just update once.

If clone the VMDK image back to USB-Key, Later the DSM system settings change in bare or virtual machines, and the boot data and configuration information are asymmetric, starting DSM will cause data corruption, and it will prompt data migration.
It can not update the configuration in real time, manual operation is too frequent, and it needs to be shut down for maintenance.I've tried this method before.

In addition, I do this in single machine state.
In the future, I will try PXE and SCSI networks or usb shareserver software to start DSM and separate USB-Key or boot image, which will realize the diskless system。

In DSM 6.1.7, all of the above have been successfully implemented. I am happy.Of course, it's still in the experimental stage.

I hope this boot menu can be applied to a variety of complex environments. Let it become universal。
passthrough USB-Key is one of the sub-functions. Because I realized the function of automatically discovering multiple DSMS ( Different versions, different models) and choice the boot.

 

My plan may be strange, because it's a requirement fulfilled in limited resources. ^-^

Of course, I'm just interested. This solution is not applicable to the production environment.

 

 

Edited by Zteam_steven

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.