rr Issue with migration from DS925+(v1000nk) to other platforms

RR used the latest version 25.4.2. When building the loader with a different model for migration from DS925+(v1000nk) to another platform and booting RR's DSM, Migration cannot be done because the mount of the /dev/md0 partition failed.

root: Failed to mount /dev/md0 on /recovery_root_mount
umount: can't unmount /recovery_root_mount: Invalid argument
Mounting /dev/md0 /tmpRoot
mount: mounting /dev/md0 on /tmpRoot failed: Invalid argument
Trying to mount /dev/md0 with btrfs super-recover
/linuxrc.syno.impl: line 585: /sbin/btrfs: not found
mount: mounting /dev/md0 on /tmpRoot failed: Invalid argument
Trying to mount /dev/md0 without free space cache
mount: mounting /dev/md0 on /tmpRoot failed: Invalid argument
Trying to mount /dev/md0 without log tree
mount: mounting /dev/md0 on /tmpRoot failed: Invalid argument
Trying to mount /dev/md0 with backup roots
mount: mounting /dev/md0 on /tmpRoot failed: Invalid argument
mount /dev/md0 fail, returns 1
Exit on error [3] no init exists...

The only migration is possible with DS1621+(v1000). I am only guessing that it is possible because they are similar platforms.

The junior log of RR captured through the telnet port is as follows.

rr_925p_to_6400_mig.log rr_925p_to_923p_mig.log rr_925p_to_918p_mig.log rr_925p_to_1621p_mig.log

I thought that the cause of this problem was the absence of the /sbin/btrfs binary, so I added the case of mshell separately and added btrfs-progs v4.0 as an Addon in advance, but there was no change in the issue.

https://github.com/PeterSuh-Q3/tcrp-addons/tree/main/abusyboxupgrade/auxfiles/usr

May 04 '25 11:05 PeterSuh-Q3

请填写以下信息.
Please fill in the following information.

Install ENV: (You can find it in the boot interface.)

DMI:
CPU:
NIC: (pid & vid)

RR version: (You can find it in the update menu.)

RR:
addons:
modules:
lkms:

DSM:

model:
version:

Issue:

logs:

(## 因为 log中存在 SN/MAC 等一些敏感信息, 当提供完整文件时请自行抹除他们, 当然你也可以发送到我的邮箱. ##)
(## Because the log contains some sensitive information such as SN/MAC, please delete them when providing the complete file. Of course, you can also send it to my email. ##)
...

(请先看一下#173、#175、#226 的内容)
(Plz review the content of #173, #175, #226 first)
...

(如果你只是说 XXX 不能用, 什么详细信息也不提供, 我也只能说感谢你的反馈.)
(If you just say XXX doesn't work without providing any details, I can only say thank you for your feedback.)
...

May 04 '25 11:05 github-actions[bot]

I just found a solution.

If you look at the normal log of DS1621+, you can see that the btrfs related modules are being loaded.

Insert synorbd kernel module
Insert synofsbd kernel module
Insert sha256 kernel module
:: Loading module xxhash ... [  OK  ]
:: Loading module ecryptfs ... [  OK  ]
:: Loading module zstd_decompress ... [  OK  ]
:: Loading module zstd_compress ... [  OK  ]
:: Loading module xor ... [  OK  ]
:: Loading module raid6_pq ... [  OK  ]
:: Loading module btrfs ... [  OK  ]
All disk ready or timeout execeed

However, if the module is missing, the module loading log will not appear.

Insert synorbd kernel module
Insert synofsbd kernel module
Insert libsha256 kernel module
Insert sha256 kernel module
All disk ready or timeout execeed

TCRP-MSHELL has added the related BTRFS module pack as a separate Addon.

https://github.com/PeterSuh-Q3/tcrp-addons/tree/main/covermissingbtrfs/auxfiles

By applying the BTRFS module pack, migration from DS925+ to SA6400 can proceed normally as shown below.

Insert synorbd kernel module
Insert synofsbd kernel module
Insert libsha256 kernel module
Insert sha256 kernel module
:: Loading module xor ... [  OK  ]
:: Loading module raid6_pq ... [  OK  ]
:: Loading module zstd_compress ... [  OK  ]
:: Loading module btrfs ... [  OK  ]
All disk ready or timeout execeed
Assemble args: -u 18754293:863b20f6:05d949f7:b0bbaec7 /dev/sata1p1 /dev/sata3p1 /dev/sata4p1
mdadm: /dev/sata3p1 has wrong uuid.
mdadm: /dev/sata4p1 has wrong uuid.
mdadm: /dev/md0 has been started with 1 drive (out of 16).
Partition Version=9
Checking btrfs rootfs on /dev/md0
return value: 
All components of md0 have partition layout above v9.
ForceNewestLayout: Skipped
Mounting /dev/md0 /tmpRoot
------------upgrade
Begin upgrade procedure
Failed to found any patch
No upgrade file found
End upgrade procedure
============upgrade
------------bootup-smallupdate
Failed to AssertFileKeyValueEqual
  value1: /etc.defaults/synoinfo.conf:unique -> synology_epyc7002_sa6400
  value2: /tmpRoot/etc.defaults/synoinfo.conf:unique => synology_v1000nk_ds925+
Skip bootup smallupdate, because root is not matched to junior
============bootup-smallupdate
Failed to AssertFileKeyValueEqual
  value1: /etc.defaults/synoinfo.conf:unique -> synology_epyc7002_sa6400
  value2: /tmpRoot/etc.defaults/synoinfo.conf:unique => synology_v1000nk_ds925+
Exit on error [7] root not matched with junior...

May 04 '25 16:05 PeterSuh-Q3

In the case of Geminilake, btrfs.ko remains and does not disappear.

May 06 '25 09:05 PeterSuh-Q3

该问题似乎并不影响型号的迁移