flyride

Quoted is the last sentence in post #1. The script won't do anything if synoboot is properly configured, but it won't hurt anything either.

Serial port is the only option. They are cheap and USB-connectable and generally work even when other things aren't. That said, you are facing some standard problems and there may be more expedient/simpler ways to solve them. When asking for help, stating your CPU type, loader used and the DSM version and platform are required. Not knowing the details of what you were trying, here are some specific combinations for your hardware that are very likely to work: 1. Loader 1.02b, DSM 6.1.7 DS3615xs, any boot mode 2. Loader 1.03b, DSM 6.2.3 DS3615xs, CSM/Legacy boot mode If neither of these work, you probably have a VID/PID problem despite your efforts and should try another USB key.

Given the thread history, @StanG needs to now restore the original extra.lzma's to the boot loader or load the new ones for 6.2.3. The workarounds needed for 6.2.1/6.2.2 don't work on 6.2.3.

Unfortunately I still can't duplicate this behavior. The issue is probably a resource timing issue in the first place, so I suspect it's a difference between the boot up time of the systems. Your system is somewhat slower than the system I am using to test. You might want to try the modifications suggested in this post here. If you do and it works for you please report back. https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/?do=findComment&comment=150336 Again, even if you receive the pop-up messages, your synoboot should be working correctly and your system ought to be fully functional.

I wonder if this might be an option for you... never needed to try it myself, but it's an interesting idea. https://xpenology.com/forum/topic/12867-user-reported-compatibility-thread-for-dsm-62/?do=findComment&comment=157911

The UI pop-up message is a cosmetic problem not a functional one. But the current version of the script is intended to suppress the pop-up error message. Reading back through the thread, there was an individual that for some reason received UI notification, and to my knowledge never resolved it. I was unable to duplicate this reliably in test. Can you be very specific as to what you are doing when you do and don't receive the message? Are you using ESXi or baremetal? Do you mean restarting ESXi?

To run DS3615xs or DS3617xs you need to to turn on legacy boot in the BIOS. That board has very little for BIOS configuration. I seem to recall someone stumbled on a not-obvious boot option which caused it to disable UEFI. My best advice is to try everything. FMI: http://forum.asrock.com/forum_posts.asp?TID=8472&title=asrock-j5005itx-fails-missing-legacy-boot-mode

Is there something not working? There are a lot of "normal" errors in /var/log/messages, particularly on bootup.

Review this thread: https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/

Oh, you are using DS918+ with original MaxDisk=16. So DiskIdxMap should be 1000, that will make the 50MB disappear. You have SataPortMap=4 which probably should be "1"

It's a provided img file, you aren't creating it.

/dev/md0 is your root filesystem (DSM). Check for core files, orphaned log files, etc. Or reinstall DSM.

Two probable reasons - 1) failed to pick the VMWare option at the grub boot menu, or 2) your grub.cfg needs to include DiskIdxMap=0C00 which should also fix the slot placement of your live hard disks.

I'm not sure what Docker has to do with it

@seb0p how you are trying to allocate your storage isn't exactly how DSM intends for you to use it. DSM's purpose is to manage physical disks for redundancy and performance. Instead you are tasking ESXi with the storage management role and only using DSM for access. The preferable solution is to pass through your storage controller to the DSM VM, or RDM certain drives on the storage controller to DSM. Then everything works as expected. If your use case requires that you use scratch storage and virtual disks, you have a couple of choices. 1) create multiple identical vdisks as you want to grow and then RAID them in DSM. Again, this is suboptimal from a performance and data redundancy perspective. Or, 2) you can allocate a single vdisk and grow it. Unfortunately the disk management tools in DSM are not anticipating such a scenario (as it is not possible without running XPEnology in a virtual environment) so the procedure to grow the vdisk is manual. This thread will help, but I really recommend you consider giving DSM access to your physical disks.

Not on ARM CPU. If the hat includes an Intel CPU, possibly.

Do you know what VLAN # you chose? If you have a managed switch, you should be able to map the ports for your PC and NAS to join that VLAN and then you will be able to connect. If you have a passive switch, check the NIC configuration on your computer to see if you can add the VLAN tag there. Short of those options, I'm not sure how one would recover from this situation.

<deleted>

I think the Areca controller is more specifically the part that is not playing well with current DSM images. The rest of the system seems like it should work fine. So you have the choice to find another more compatible controller, or if Areca is supported by ESXi, install on that, then RDM the drives into DSM (a little bit labor intensive but equally functional)

Useful, thank you.

I would agree with that but we don't usually look at a serial output trace so I am not sure what to expect. The conf file patch failures at the beginning are piquing my interest.

Legacy boot set in BIOS? (i.e. CSM, non UEFI boot). It's an old motherboard but it may still need the setting.

I'm going to venture to say that most any points of feedback are going to be of personal preference, as you are thinking through this pretty deeply. So I'll share some opinions, and in no way are these critical of your approach: Snapshot and replication are where it's ultimately at in this scenario. This is protecting from ransomware and temporal data loss and should be the primary method for recovery. When you start replicating, you'll find that hourly snaps are probably too frequent for the overhead. Is your change rate that fast? Also snaps are dropped and the data is not cumulative (i.e. if you create a file and delete it, if that happens before the snap it is gone. If that spans a snap it will be retained, but then if that snap is dropped due to retention the file is gone), so consider that in your snap frequency and retention plan. Every time I've tried to use cloud storage when I have a snapshot target available, it makes no sense financially or from a performance standpoint. YMMV. I'm a big fan of VEEAM Free to backup Windows and Linux clients. You get baremetal and file restore in one, with incremental, self-managed file storage on the NAS. For me this is preferable over the "Drive" client functionality. My non-portable PC's have their Windows Documents folder rehomed to their user's home folder on the local NAS. You may not like this choice if you don't have 10Gbe. With this much dependency on XPEnology, consider a test environment part of your data security strategy. All this tech isn't helpful if it bricks on an update.

I've had DSM flag drives as problems before, I'd run the Quick Test a few times and see if you can get one to complete. Also I notice that the drive is (and has been since the beginning of this thread) "Not Initialized" which means it doesn't even have DSM on it - no partition structure. So nothing to be lost. If you cannot get it to clear, we may be able to purge the failed Quick Test record using the command line.