flyride

If you deploy XPenology as a VM then you can work around hardware that would otherwise be incompatible or less compatible as baremetal. For example, I can use my enterprise NVMe disks as regular storage (a disk pool and volume), and also RAID F1 which is only supported in DS3615/17xs, both at the same time deployed as a ESXi VM. If you have a need for other VM's and they do not need very high speed access to DSM volumes (meaning they can be NFS connected or even use hypervisor storage), then arguably ESXi is a better pure hypervisor instead of a container inside DSM.

I read your post and I'm not really sure what feedback you are looking for. You seem well informed based on your mostly rhetorical questions. This post covers most of what you are discussing: https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/

Your concern is whether your processor cores are all active with DSM, and by the looks of /proc/cpuinfo, they are not. My only thought is to ask if you are running a VM with processor restrictions?

When I look at /proc/cpuinfo, I see an output block for each thread (core ID increments and core count is accurate with 4 cores). You only have 1. That would be alarming to me.

There isn't anything "supported" at all. You get to decide what hardware is compatible or not. There is a lot of info to help you with your decision, however. Here's another thread where someone else asked basically the same question today: https://xpenology.com/forum/topic/31360-motherboard-help/?tab=comments#comment-154346

Take a look at this and this and you will get a good sense of what folks are successfully using. EDIT: also https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/ may be helpful to you

I have no idea. Not enough information to investigate the problem.

Synoboot problems and the exposure of the boot loader device can happen with earlier versions, but does not very frequently. It won't hurt to install the script and see if it helps you. However, hard disk numbering and position is controlled by DiskIdxMap and SATAPortMap which is a configuration in the loader. Since everyone's hardware configuration is different, it's an analysis and application based on your observations of your own system. You might want to read up on that if the script doesn't solve (or completely solve) your problem.

If you left out the line to run in host mode, you might have to add iptables edits. But in host mode it should not be necessary.

https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Storage/What_is_Synology_Hybrid_RAID_SHR Same size, not necessarily. Different size, maybe. Upsides = flexibility and maximize storage for dissimilar drives. Downsides = potentially variable performance depending on drives selected, longer rebuild times, and more complexity in the case of a problem. For their first array, most people choose SHR. For their 10th array, I would argue many choose not to SHR.

The problems are mostly solved now, and involved migrating from 6.2.2 to 6.2.3. Clean install of 6.2.3 is fairly trouble-free.

Even if DSM is Linux, the Synology utilities that make DSM what it is definitely not Linux standard. udev is completely customized. smartd is completely customized. The disk cache is customized. RAID5 is customized. And all the configuration that you can do through the DSM UI is through Synology's own binaries, not the Linux standard utilities. So if you want to configure a 60-drive array (or whatever) you might be able to get the Linux side of DSM to mount it, but Synology's utilities won't touch or will immediately scramble it. Not too long ago I tried to help a guy with an array recovery and the system was left in a Linux functional state where his data was all accessible, but then he decided to use DSM utilities to "fix" something and poof- all gone. Synology wants things the way they want them. They don't code their stuff to be fully interoperable with standard Linux. That's why the loaders and all the core scripts, patches etc are trying to keep DSM in a completely pristine, unadulterated state.

I had a similar problem, no real rhyme or reason for it. I found a post with another fellow who found it working mysteriously later. I finally just did a migration install to reinstall DSM and that fixed it. Sort of a sledgehammer to pound a nail; I'm sure it was something simple but I couldn't figure it out.

The chart's guidance is quite specific on the matter.

Check on Synology website about which models can migrate. There are limitations. But yes, migration is possible if you have supported hardware. As always, have a backup.

That is incorrect. Without the patch they are not recognized at all by Synology's utilities (they are accessible by Linux). You can hack them in as storage but it is not supported or safe, and it does not matter whether the patch is installed or not. If you want to remove the patch, put the original file back.

Only modify extra_args. Leave other settings (including sata_args) alone.

The backup is the image you used to build the stick. You can replace/overwrite the stick with that image anytime and the system will boot right up.

Driver extensions not required for J4105 (EDIT: possibly for transcoding but not for basic functionality). USB stick is not for installation. It IS the boot device. It has to stay in.

There are posts here that show how to self-register, I think it's just through a web page. This is only necessary if you want Syno's native app to transcode. Search is your friend. There are many, many threads filled with folks trying to figure out how to transcode.

Serial port or SSH, those are your options.

Something in here might help you.

Addendum created to post #2 which describes changes required to run NFS without container root (privileged: true).

If your files are accessible read-only, I would not continue trying to repair the filesystem. BTRFS is designed to self-heal while running and if it can't, the underlying corruption probably can't reliably be removed. This is different than ext4 where the only way to correct a problem is through the administrative launch of e2fsck. I would save your files elsewhere, delete the btrfs volume, rebuild it, and copy your files back on. All BTRFS documentation recommend the same.

Again if it wasn't clear from @jensmanders reply, you are testing with one IP stream. Each session can only use one of the paths. If you open up a deliberately multi-network threaded application or run multiples independents in parallel, you might see both in use concurrently. It's 100% dependent upon the algorithm. Some algorithms will only EVER assign you one IP for all sessions a static timeframe, some will do it on IP session. Set up a test with multiple devices and multiple concurrent activities to be sure.