Peter Suh

Yes, please show me the results of the command below. cat /var/log/*rc*

And, don't try anything unnecessary. Diagnosis comes first. The diagnosis process is still ongoing.

cat /var/log/*rc* The following log content should appear twice with the above command. REVISION = #69057 hdmodel 1100_MTFDDAK2T0TBN fwrev M0MU033 Insert firmware version:

I created a DB file as shown below. There is no problem creating DB files. I have one suspicion. Micron 1100 seems to have disappeared at the time this DB file was created. I think it disappears like that and then appears stably at this point when DSM has completed booting. Drive DB files are updated through Junior mode, which is very early in the DSM boot phase. I will tell you how to enter junior mode in Friend. I think I need to test running the same script as now in junior mode. When Friend is booting, there is 7 seconds to spare. Please enter the j key within these 7 seconds. In that state, it will remain in junior mode. There is no damage to your DSM or data, so you don’t have to worry. If it progresses to that state Using the IP address displayed on the screen Please enter http://192.168.50.223:7681 in your web browser. The login account is root and there is no password. Please try the command below first. cat /var/log/*rc* { "key": "1100_MTFDDAK2T0TBN", "value": { "M0MU033": { "compatibility_interval": [ { "compatibility": "support", "not_yet_rolling_status": "support", "fw_dsm_update_status_notify": false, "barebone_installable": true } ] }, "default": { "compatibility_interval": [ { "compatibility": "support", "not_yet_rolling_status": "support", "fw_dsm_update_status_notify": false, "barebone_installable": true } ] } } }, { "key": "2TB", "value": { "HP2818D8": { "compatibility_interval": [ { "compatibility": "support", "not_yet_rolling_status": "support", "fw_dsm_update_status_notify": false, "barebone_installable": true } ] }, "default": { "compatibility_interval": [ { "compatibility": "support", "not_yet_rolling_status": "support", "fw_dsm_update_status_notify": false, "barebone_installable": true } ] } } }

Backup and drive database processing do not seem to be related. Based on the log you provided, I will check if there are any problems with DB file creation and inform you of the results.

I created a script to check. Please download with root privileges as shown below and send the execution results. sudo -i curl -kLO https://raw.githubusercontent.com/PeterSuh-Q3/tinycore-redpill/main/syno-hdd-db.sh chmod +x syno-hdd-db.sh ./syno-hdd-db.sh

There is no reason for Synology to deliberately exclude only Micron models. I think it's just that the information wasn't recorded in the DB. Sent from my iPhone using Tapatalk

Apparently only the Micron 1100 information is missing. There seems to be a bug in syno-hdd-db. I might have to keep up with 007revad's recent improvements. I have a brief outing for 2-3 hours. I'll tell you what's needed later. Just a passing thought, this model name has a unique use of "_". I think there may be a problem with this part.

Could you please remove the pop-up message from this image? It interferes with comparing with drive information.

This is command. Just run the script below. No root privileges are required. jq '.disk_compatbility_info | to_entries | map(select(.value != null)) | .[-8:]' /var/lib/disk-compatibility/ds918+_host_v7.db

Because there are so many contents in the database, this command only checks the last 8 contents. Please check the db file name and location first as shown below. I tested with sa6400 instead. admin2@DS1621p:~$ ls /var/lib/disk-compatibility/*host_v7.db /var/lib/disk-compatibility/ds1621+_host_v7.db /var/lib/disk-compatibility/sa6400_host_v7.db jq '.disk_compatbility_info | to_entries | map(select(.value != null)) | .[-8:]' /var/lib/disk-compatibility/ds918+_host_v7.db { "key": "WD10JPVX-22JC3T0", "value": { "01.01A01": { "compatibility_interval": [ { "compatibility": "support", "not_yet_rolling_status": "support", "fw_dsm_update_status_notify": false, "barebone_installable": true } ] }, "default": { "compatibility_interval": [ { "compatibility": "support", "not_yet_rolling_status": "support", "fw_dsm_update_status_notify": false, "barebone_installable": true } ] } } }, { "key": "WD5000BPKT-22PK4T0", "value": { "01.01A01": { "compatibility_interval": [ { "compatibility": "support", "not_yet_rolling_status": "support", "fw_dsm_update_status_notify": false, "barebone_installable": true } ] }, "default": { "compatibility_interval": [ { "compatibility": "support", "not_yet_rolling_status": "support", "fw_dsm_update_status_notify": false, "barebone_installable": true } ] } } } ]

The syno-hdd-db addon that references the script in 007revad is already running in mshell. This is a script customized to suit the operation of Redpill. https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/syno-hdd-db/src/install.sh I will tell you the command to extract your drive information from the database file that this script modifies. Please wait a moment.

[NOTICE] Deploy virtual MAC address spoofing Addon mac-spoof This does not apply to users who only use real MAC addresses. Currently, the FRIEND kernel shows the process of spoofing a real MAC address with a virtual MAC address using a yellow message. So, when MAC spoofing processing is completed, a new DHCP IP address is assigned to the newly changed virtual MAC address. During this process, the spoofing status must continue to be transmitted at the Junior stage of installing DSM and at the OS_ON_LOAD point when DSM installation is completed and the OS is loaded. However, there are cases where this spoofing is released and a strange state where neither real MAC nor virtual MAC persists. (In the DSM control panel, the real MAC is displayed, but the IP already assigned to the virtual MAC is used, etc.) So, even within DSM, ADDON, which fixes explicit MAC spoofing, was added to MSHELL. To use this addon, you must re-enter the mshell TCRP loader build menu and build again. The command below on the right is a way to re-check whether the mac-spoof addon is properly installed. The green message is the process of spoofing from the real MAC address to the virtual MAC address. For this spoofed virtual MAC address, an IP address of 192.168.35.104 was assigned by the DHCP server (router). In Junior mode where DSM is installed, the mac-spoof addon runs and the IP is well fixed through virtual MAC spoofing. MAC spoofing in Junior mode ensures that the virtual MAC address is checked on the DSM control panel even after OS_ON_LOAD, when DSM installation is completed.

Anyway, it is true that MAC spoofing is messy. Because explicit MAC spoofing was not done, virtual MAC could not be used properly. If you want to keep a Real Mac, spoof a Real Mac. Replacing the MAC address with the same value from the original MAC address is meaningless because there is no change, but I decided to do spoofing through this mac-spoof addon anyway. https://github.com/PeterSuh-Q3/redpill-load/blob/master/bundled-exts.json#L11 https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/mac-spoof/src/install.sh The test was conducted successfully. MAC spoofing is processed as desired. The official announcement will be made tomorrow.

Today I researched how to spoof Mac address in Mshell. Although spoofing was already successful on Friend, there was an issue where it could not continue to DSM. Mac spoofing was handled within DSM with the command below. I confirmed that the Mac and IP addresses were renewed normally. sudo -i /sbin/ip link set dev eth0 address 00:E2:69:75:ED:28 /etc/rc.network restart I plan to inject this script in the form of a new addon. I decided to name it force_dhcp. I will announce this feature when it is released.

The first time you install DSM 7.2.1 Update 0, it probably won't take more than 4 minutes. Friend automatically changes to the latest version, Update 3, and automatically performs Ramdisk Patch. (Yellow text will stand out.) In this state, the process of upgrading from Update 0 to Update 3 takes time. This process involves reinstalling the Synology package, which takes the longest time and also causes network disconnection.

The output of balenaEtcher behaved strangely. I experienced it too.

I already know about this problem and would like to improve it. I remember seeing a revision history for this problem in some intermediate version of rr. However, I am just worried because the repo I can refer to has been closed. I will try to improve this area with his help.

And, although it may be a waste of your effort, @MoetaYuko has already completed a stable i915 module to enable transcoding on SA6400, as shown below. This i915 module has already been applied to rr and tcrp-mshell. However, the Intel CPU generations for which transcoding has been confirmed to operate are These are the 4th, 11th, 12th, and 13th generations. For other generations, the /dev/dri directory is checked and whether the i915 module is loaded is checked, but it does not work. I am still finding out what more detailed adjustments are needed.

In the case of SA6400, both rr and tcrp module loading methods do not directly inject modules using insmod or modprobe (dependency consideration). As shown in the script below, copy all modules to /lib/modules and prepare them. Regenerate dependencies with the command below. Of course, if modules that depend on i915 are not properly prepared, this command may also send an error message. depmod -a https://github.com/PeterSuh-Q3/tcrp-modules/blob/main/all-modules/src/install.sh#L62 Instead of directly injecting modules, we use “eudev”, designed and developed by ARPL’s Fabio. https://github.com/PeterSuh-Q3/tcrp-modules/blob/main/eudev/releases/install.sh

https://xpenology.com/forum/topic/65408-automated-redpill-loader-arpl/?do=findComment&comment=453947

This is RR’s current status as received from a community user. RR seems to be continuously being updated under the name BLACK SYNOLOGY NAS SYSTEM. However, it appears that it has been converted to domestic use for Chinese people with memberships. He is probably considering access for foreigners if membership is allowed. https://www.123pan.com/s/56Sfjv-1d0WH.html PASSWORD : RRRR Rather, I think that switching to a private membership-only Chinese domestic market can free him from Synology. In any way, I'm just happy that RR's development continues without stopping. https://drive.google.com/file/d/12EinJAx6O9hrjYVAqAtJWc6l5S5l4Vi9/view?usp=drive_link

XPENOLOGY is a program that hacks the limitations of the specifications of the genuine product. What you need to consider for the Ethernet card part is devices other than the genuine support list. There just isn't enough verified feedback data for the Ethernet modules (recompiled and manufactured by Redpill) used by each chipset. Sometimes, if the Ethernet module provided by Redpill does not work or is unstable, it may be removed and replaced with the original module originally provided by Synology (called a vanilla module). So far, the modules below have been such cases. In the case of DS920+ Gemini Lake, there was no such case. https://github.com/PeterSuh-Q3/arpl-modules/tree/main/vanilla/geminilake-4.4.302 In the case of DS3622xs+ Broadwell NK, the ixgbe and Mellanox modules are replaced with Vanillo modules and passed. https://github.com/PeterSuh-Q3/arpl-modules/tree/main/vanilla/broadwellnk-4.4.302 In the case of AQC107, it seems necessary to check in detail whether the module used is aqc111.ko or whether the Vanillo module works well enough. ------------------------------------------------------------------------------------------------ Also, here is additional information about the detailed chipset of Synology's genuine Ethernet. E10G17-F2 : Mellanox ConnectX-3 Pro CX312B E10G18-T1 : Aquantia AQC107-B1 E10G18-T2: Marvell QL41102 (MAC) + BCM84886 (PHY) E10M20-T1: Aquantia AQC107 (built-in PLX PCIe switch and 2EA M.2 slots) E10G21-F2: Intel X710 E25G21-F2: Intel XXV710 (estimated) E10G22-T1-Mini : Aquantia AQC107 E10G30-T2: Broadcom BCM57416 (estimated) E25G30-F2: Broadcom BCM57414 (estimated) Model name - If it starts with T, it is 10GBASE-T (RJ45), if it starts with F, it is SFP+ or SFP28, and the last number is the number of ports. E10G18-T1, E10M20-T1, and E10G22-T1-Mini also support 2.5G/5G standard IEEE 802.bz.

Do you have any more questions about this inquiry about scalability? Can I close the issue? https://github.com/PeterSuh-Q3/tinycore-redpill/issues/17

In fact, you need help from other developers to code for the stability of the module rather than from people to test it. There are currently no people active in TTG. Chinese developers have helped us a lot so far.