flyride

Upgrade to 7.1 or add support_disk_compatibility: no under synoinfo in user_config.json

Maybe. If you want to do this you're on the wrong forum.

DSM is installed onto a reserved partition of each hard disk you connect. Your data lives on the rest of the space on the disks. The USB loader is required to boot the DSM Linux OS and fool DSM into thinking that the hardware is Synology. The loader device doesn't have DSM installed to it, but it is modified to match the DSM software installation and the serial number you choose. You cannot remove the loader device, even after DSM is up and running. As you should understand from the Loaders and Platforms matrix, 1.02b is for DSM 6.1.x. 1.03b and 1.04b are for DSM 6.2.x. TCRP is for DSM 7.x.x. You must match both the DSM hardware platform (not your hardware) and the compatible DSM build version for the loader you choose.

You missed this note in the table. DS920+ seems unique but we don't know why. Other models continue to require FMA3. ** Based on history, DS920+ should require Haswell. There is anecdotal evidence gradually emerging that DS920+ will run on x86-64 hardware.

This is not unilaterally true. Technically some of the J-series are Celerons, and there are a number of Pentiums that have FMA3. Have to evaluate each chip.

There is some conflicting information out on the interwebs on this chip. However, nothing from Intel says it supports FMA3, which is believed to be the instruction set required by the kernel. https://ark.intel.com/content/www/us/en/ark/products/97143/intel-pentium-processor-g4560-3m-cache-3-50-ghz.html Here's an article that says it does support FMA3 https://www.techpowerup.com/cpu-specs/pentium-g4560.c1937 And wikichip says it doesn't https://en.wikichip.org/wiki/intel/pentium_gold/g4560 I would tend to believe Intel and wikichip.

The kernel that supports QuickSync requires Haswell or later. Sorry.

Yep, that is evidence that DSM thinks the fs is btrfs. Something has definitely happened to it. It's unusual that it cannot find its superblock, which suggests some indiscriminate writes to the beginning of the array. You already are looking at a recovery thread I did awhile ago that might have some techniques that will help. https://xpenology.com/forum/topic/14337-volume-crash-after-4-months-of-stability/#comment-107979 You might try to locate alternate tree roots within the filesystem - btrfs stores copies of critical metadata in various places for cases like this. Here are a few more rescue threads that may be of some help: https://xpenology.com/forum/topic/48356-help-volume-crashed-shr-btrfs/#comment-216944 https://xpenology.com/forum/topic/48253-volume-crashed-but-storage-pool-is-fine/#comment-219582

So you are trying to use your pre DSM 7 mount point. Your mount command would be sudo mount -v /dev/mapper/cachedev_0 /volume1 Not saying that it will work right now, but if you try that it may shed some light as to what the problem is. BTRFS normally fixes itself with no action on your part. If it mounts read-only, it usually means it cannot fix itself, which suggests that you should offload all your files, destroy the volume and rebuild it.

So it is not mounted. What filesystem type is it? cat /etc/fstab

Don't know, maybe post the results of a df to see what it thinks is mounted. If you reboot does it clear it up?

sudo umount /volume1

If you cannot figure it out by looking through the troubleshooting section of the guide, then post a question in the DSM Installation forum with details of your system, logs from the build, etc. There are plenty of examples of people requesting and receiving help there.

Unsure. I have TInycore running both UEFI and Legacy in test. I'm not disputing your experience or finding, but it it works, does it matter? For what it's worth, you are posting on the DSM 6 Jun loader thread, so what was written back in 2021 isn't applicable to Tinycore.

You must make your changes in user_config.json in TinyCore. It patches on each boot so if you edit DSM's files directly, they will be overwritten.

Data VMDK needs to be on SATA1:0. Add another virtual SATA controller. Data VMDK is not strictly necessary since you have LSI disks. Without data VMDK and no secondary SATA controller, SataPortMap=1 DiskIdxMap=1000 With data VMDK and a secondary SATA controller, SataPortMap=11 DiskIdxMap=1000

That looks good so far. That is all you will ever see from the VGA console. Can you connect to your NAS with find.synology.com or Synology Assistant?

You need the mapping beyond MaxDisks for Synoboot, but the mapping index needs to be reset so that the non-SATA ports can fill in at the end. There's a bug in the algorithm when the right combination of SATA and HBA's are in the system. I'll update it and get it over to @pocopico

Looking at this happening at another instance, try SataPortMap=1 and DiskIdxMap=1000

@pocopico it looks like the "breakdown" of the chained lspci -d ::XXX command (change you made in rploader) is doing something untoward. Someone reported this specifically with LSI earlier this week, but I can't duplicate it. @apriliars3 Don't connect your data vmdk to the same controller as your loader image. Add another SATA controller and move the vmdk to it. Then try to change DiskIdxMap to 1000. EDIT: the diskidxmap worked for another user so I'll update the satamap logic. You can manually edit in the meantime.

Shouldn't be. The backup command is misplaced however. That causes you to back up the base environment since you just booted it. Not sure if that will have any negative effect, but it definitely doesn't do anything productive. That said I don't think there is any need to restoresession or do anything else prior to postupdate. Maybe @pocopico or other dev can shed some light on this. When you update (downloads the latest rploader script) and fullupgrade (downloads new supporting files) you should be on the latest. There isn't anything to be gained by downloading a new image. That looks like a baremetal install to me. But in theory you should be able to pass through your VGA controller and make it work. You'll need to do some googling as it affects VMware itself.

Since we are hacking access to specific Synology platforms, for baremetal it always makes sense to me to try and match the platform configuration. So I am running DS918+ on an Asrock J4105 - virtually identical to the real DS918+ configuration. I am also running DS3622xs+ (originally DS3615xs) on a SuperMicro X11SSH-F board - also very close to the DS36xx hardware. But I test every platform on VM, and they all work one way or another, so if you are willing to put in the effort to learn how to use ESXi or Proxmox, it is very much achievable. Regarding the integrity of your data, a failed DSM install or upgrade doesn't put data at risk. A reckless upgrader may blow up the data partitions while they try unsavory things to get the system back up, but the worst that should happen is that data is inaccessible while you figure out how to get DSM back up and running. But as always, it is best to have a backup so that if YOU mess up, you can burn it down and build it back up without losing anything. I have a second copy (and for some data, a third) of everything. The tutorial gives you information on how to test a migration successfully. There are many success stories in the upgrade threads. That said there are a lot of little things that can go wrong migrating to or upgrading DSM 7. Even with extensive testing I still had a problem with the SuperMicro migration, and I had to rebuild DSM from scratch (but not my data).

https://archive.synology.com/download/Os/DSM

Sorry it wasn't successful. Before you switch hardware, know that you also have the option of virtualizing your system, or use a DSM platform with a device tree, such as DS920+