flyride

Sandy Bridge is older than Ivy Bridge, no matter it still won't run. CSM = Legacy Boot = "BIOS" in some motherboards. Sometimes it takes a particular combination of configuration settings to get it to work. If you can't get it to function any other way, there is an MBR build of the 1.03b loader out there that may work for you.

What types are the drives, specifically? Are they all the same make and model? Do all your drives properly display in the Storage Manager slots? Post some screenshots. Also, what happens when you remove your SSD cache drives from the system?

Ivy Bridge CPU cannot run DS918+ so that won't work (moving your existing USB). You are right to try 1.03b and DS3615xs (DS3617xs is better but no matter). Make sure you are installing DSM 6.2.3 and not an earlier version or drivers may be a problem. Did you remember to change to USB boot to CSM/Legacy mode?

Essentially using a M.2 drive like this is the equivalent of the IMG loader for ESXi (AFAIK you can just burn the IMG to a disk and then select ESXi for the grub options and it will work without all this trouble). Maybe get a used 16GB Optane drive so as not to be so wasteful. But also something like this will keep it clean and internal, I guess I am conflating this post and the other guy who wanted to use his internal NAND port. https://www.amazon.com/SinLoon-Female-Motherboard-Header-Adapter-Dual/dp/B0878S6BD5/ref=sr_1_5?dchild=1&keywords=usb+header+to+usb+port&qid=1613093640&sr=8-5 Usually doing a disk-based loader will end up with the device visible in the Storage Manager so then tweaking of DiskIdxMap and SataPortMap is required, but I suspect most don't bother and just ignore the spurious device. Not really sure why everyone wants to reinvent the wheel but hey, innovating and figuring stuff out is fun.

No, the stick can be cloned just fine. There is no checksum limitation on grub.cfg; it can be changed after the initial install.

If VID/PID does not match, the stick cannot be used to boot. It's not an install, it's permanent. The stick is updated on install and every major update of DSM.

Migration install should work. You should back up everything before doing any type of migration.

Replace the files in the USB stick with the updated versions. https://xpenology.com/forum/topic/28321-driver-extension-jun-103b104b-for-dsm623-for-918-3615xs-3617xs/

The motherboard NIC is brand new with B460 chipset; Intel releases refreshed silicon with new PCIe signatures for the i219 every chipset rev. You'll need to add extra.lzma for updated drivers from @IG-88 for the correct platform in order for it to be supported and it is possible it is too new even for that. Perhaps we should have started with this information at the beginning and avoided all the flailing. The failsafe is for you to order an Intel CT gigabit PCIe NIC for $20, disable the onboard NIC, and your problems will be resolved. I realize that you won't want to use your one slot for this because you want the 10Gbe card there, but you can get the system up and running and tested, then worry about drivers for your i219 NIC.

Putty on your PC connected to a serial port, which is then connected to DSM's serial port will do it. But it honestly should be unnecessary as we are just trying to set up basic functionality. Serial console is an advanced troubleshooting/debugging tool and not strictly required for initial install. It's possible that your mobo has onboard LAN silicon that isn't supported by the base loader. If that is true, you will need extra.lzma and/or buy an Intel CT PCIe card to get up and running. Regardless, we need to reduce the number of variables in this equation. So.... What motherboard, exactly, are you using? What CPU? What loader, platform and DSM version, specifically are you focusing on?

Console is output to serial only. You need to attach a device to the serial port and run a terminal-type session to see log messages without network. It seems like you are kind of throwing yourself at the problem without really understanding the relationship between the versions, settings and loaders. Since you are having little success, I'd review this first, simplify your system (set the 10Gbe card aside for now) and find a base configuration that works. Then build up from there. https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/

Right on the product page it says this: Support FIS switch or command switch based on port multiplier Also: SATA port multiplier is not supported if the driver is not installed There is no driver for this controller in the DSM kernel.

When you do this will be a lot simpler. But I'm confused, what's stopping you from passing the current controller through now? On-board AHCI works fine. If the issue is that the drives are split between ESXi and DSM, you can RDM the ones you want DSM to use into your VM with no issue, and leave the controller attached to ESXi.

I guess the other question is... why aren't you using DSM as a VM inside ESXi? Then this would all be moot and you would have no reason to dual-boot.

That would work, but 1) not too many people understand udev syntax, and 2) would be modifying the base DSM configuration which would be overwritten on upgrade. But OP should consider that as an option if they like.

Ok, I think I understand (would help if I went back and reread the first post). You have a dual-use server, and the USB is for ESXi boot but you don't want it accessible when using DSM, and you don't want to unplug it. I presume you also don't want to disable all USB disk support. So somehow we need to be able to identify that device specifically. The easiest way I can think of is to adapt my Synoboot script to dismount and clean up that specific USB dev. If you are a good Linux shell scripter, take a look at the embedded script and you'll see how to do this. https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/ If not, you'll need to identify the device is it mapping to so that I can mod the script. It should be something like /dev/sdn.

Tehuti support is also in the base 3615/3617 image. Which DSM version and platform are you trying to install? It should be DS3617xs (1.03b with CSM turned on) or DS918+ (1.04b and UEFI boot) and 6.2.3-25426

Console messages are sent to the serial port. I have never seen that 10Gbe card before, do you know if it is rebranded from one of the major manufacturers?

Make a 1Gbe card first in the MAC order. But frankly unless you are using wake-on-LAN services, there is no need to do MAC address changes at all. Why are you arrowing down to the "third/AMD" item? You should be using the first entry for baremetal AFAIK.

You need to post more information. If a loader device shows up as USB, that may mean that it is not being recognized properly, and it is not been remapped as a Synoboot device. This is not unique to your micro sd and will break upgrades and a few other nasty things. What DSM version and platform have you installed? Which loader? If you inventory the /dev/sd devices, which one is the micro sd card?

Mellanox is very compatible, I have this exact card myself and it works fine. Install on 1 Gbe and add the ConnectX-3 and see if that works better.

What other controllers are in the system? At least one virtual SATA controller for the loader, but do you have a second one? You will need to tweak your controllers, adjust SataPortMap and DiskIdxMap, or all of the above to correct it. https://xpenology.com/forum/topic/12470-how-to-play-around-with-hdd-mapping-with-sataportmap-and-diskidxmap/ If you see 1/2 of your HDD's and you are not out of slots, it's likely you have a port multiplier on your controller which is not supported. Post the controller type and someone here will know for sure.

BTRFS checksum errors indicate corrupted files. If they can be fixed with redundancy, it should show that in the log. These appear not to be correctable and need to be restored from backup. It's pretty unusual but I have personally encountered BTRFS checksum errors twice. In each case I was able to restore the affected file from a Snapshot located on the same machine. It's worth noting that if corruption of this type happened to another filesystem (i.e. ext4) there would be no way to know about it. It can happen spontaneously because of gamma rays or bitrot, but not with this frequency. So why is it happening in the first place? Is it still happening? Unknown, you need to figure it out. If you suspect you have memory problems then test the bejeezus out of it before subjecting your data to more errors.

Your original setup is not working because the loader is no longer in a usable state. If you install new, always burn a clean, new copy of the loader. If you are doing this and it still isn't working, a mistake is being made in the loader prep.

Error 13 or error 21? Try this: https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/ You don't want to change the bay count - leave it alone. Disk reconnect as you surmised is an indicator of a bad SATA cable or connector. You fixed it. Are they increasing? If not, don't worry about it. It does not indicate a failure mode on your drive and it is not a SMART failure trigger - your manufacturer won't RMA because of it. You cannot clear it however, the CRC error event is recorded in the SMART status of your disk. If DSM flags the drive as failed independent of the SMART status, then that's something to edit and fix, although in 6.2.x it's in a database and a real pain to get to. Bottom line, don't worry about it if it is not increasing.