Jump to content
XPEnology Community

Peter Suh

Member
 View Profile  See their activity

  • Posts

    2,764

  • Joined

  • Last visited

  • Days Won

    152

Peter Suh last won the day on August 30

Peter Suh had the most liked content!

26 Followers

See all followers

Recent Profile Visitors

17,661 profile views

Peter Suh's Achievements

Guru Master

Guru Master (7/7)

  • Helpful Rare

Recent Badges

1.1k

Reputation

4

Community Answers

  1. Peter Suh
    Switch to my tcrp-mshell , there is a link to the latest version on my profile. It is a loader that supports 7.2.2 without any problems and is a successor to pocopico's TCRP.
  2. Peter Suh
    What are your hardware specs? They should probably be listed on the top of the FRIEND console that you captured with your first question. MSI MOBOs are known to have the worst compatibility.
  3. Peter Suh
    Do not 100% trust the IP address shown on this FRIEND kernel screen. After 30 seconds, the IP address may change again for various reasons. This screen may not track and display the changed IP address. If you see two LEDs on the rear port of the NIC, it is recommended to double-check the reassigned address on the router.
  4. Peter Suh
    I removed the duplicates and rebooted 2 times. I confirmed that only 1 is maintained as expected. Thank you.
  5. Peter Suh
    For now, I've supplemented the script to check for existence as follows without discarding it. grep -q '^drive_db_test_url=' /tmpRoot/etc.defaults/synoinfo.conf || echo 'drive_db_test_url="127.0.0.1"' >> /tmpRoot/etc.defaults/synoinfo.conf
  6. Peter Suh
    If your story is correct, it could be that there is a record from before v2.2.45. I'll clean up my drive_db_test_url in my synoinfo.conf that is still in v3.5.101 and see how it goes. I think the junior using /tmpRoot is out of the question as it doesn't seem to have any effect at the moment and I'll have to stop the script. Also, there is still no way to trigger synosetkeyvalue in junior.
  7. Peter Suh
    The above script is an issue that occurred in the version that still maintains the previous state (v3.5.101) before the following script was used. echo 'drive_db_test_url="127.0.0.1"' >> /tmpRoot/etc.defaults/synoinfo.conf
  8. Peter Suh
    And this is another story. As you can see in the capture below, there are too many drive_db_test_urls defined in /etc/synoinfo.conf. Maybe they are being added every time I boot. My SYNO boots once a day.
  9. Peter Suh
    Thanks for the quick fix. However, it seems like the results are not going the way we want. First of all, since ash is used instead of bash in junior state, there is a problem with the check routine being broken. So I changed it to modify synoinfo.conf directly as follows. if [ "${1}" = "late" ]; then echo "Installing addon hdddb - ${1}" cp -vf hdddb.sh /tmpRoot/usr/sbin/hdddb.sh chmod +x /tmpRoot/usr/sbin/hdddb.sh echo "Add drive_db_test_url to synoinfo.conf" echo 'drive_db_test_url="127.0.0.1"' >> /tmpRoot/etc.defaults/synoinfo.conf echo 'drive_db_test_url="127.0.0.1"' >> /tmpRoot/etc/synoinfo.conf #echo "Excute hdddb.sh with option n." #/tmpRoot/usr/sbin/hdddb.sh -n mkdir -p "/tmpRoot/etc/systemd/system" DEST="/tmpRoot/etc/systemd/system/hdddb.service" echo "[Unit]" >${DEST} echo "Description=HDDs/SSDs drives databases" >>${DEST} echo "After=multi-user.target" >>${DEST} echo >>${DEST} echo "[Service]" >>${DEST} echo "Type=oneshot" >>${DEST} echo "RemainAfterExit=yes" >>${DEST} echo "ExecStart=/usr/sbin/hdddb.sh -nfreS" >>${DEST} echo >>${DEST} echo "[Install]" >>${DEST} echo "WantedBy=multi-user.target" >>${DEST} mkdir -vp /tmpRoot/etc/systemd/system/multi-user.target.wants ln -vsf /etc/systemd/system/hdddb.service /tmpRoot/etc/systemd/system/multi-user.target.wants/hdddb.service fi The synoinfo.conf value below was immediately confirmed at the first boot of DSM, but it was not successfully blocked as shown in the capture. It was confirmed that this script was used at some point in mshell and was omitted when the addon was replaced with hdddb. I think this script was valid at that time, but I don't know why it is not blocked now. https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/syno-hdd-db/src/install.sh#L139
  10. Peter Suh
    Perhaps, for XPE, if we add this additional processing, it will be applicable immediately after installing DSM. https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/hdddb/src/hdddb.sh#L559C1-L559C39 synoinfo="/etc.defaults/synoinfo.conf" -> synoinfo="/tmpRoot/etc.defaults/synoinfo.conf" https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/hdddb/src/hdddb.sh#L2097C9-L2097C69 /usr/syno/bin/synosetkeyvalue "$synoinfo" "$dtu" "127.0.0.1" -> /tmpRoot/usr/syno/bin/synosetkeyvalue "$synoinfo" "$dtu" "127.0.0.1"
  11. Peter Suh
    @Cornelius_drebbel, @007revad Sorry. In the case of mshell and rr, which are added as services due to the nature of Synology, the service is activated after going through the reboot process at least once after the initial installation of DSM, and hdddb.sh is executed with the -n option during this process. I did not recheck this. There is no problem with the hdddb script. (before reboot) (after reboot) In the case of rr, the addon repo is hidden, so you cannot see it, but a script almost identical to mshell is being used.
  12. Peter Suh
    For mshell and rr, I already checked that they are using the -n option. Could the combined options added here have the wrong effect? (mshell) (rr)
  13. Peter Suh
    The original @007revad version has been at 3.5.101 for months and there doesn't seem to be a patch for 7.2.2. https://github.com/007revad/Synology_HDD_db/releases mshell and rr are using the original 007revad version as is and are maintaining the same final version 3.5.101. https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/hdddb/src/hdddb.sh https://github.com/RROrg/rr-addons/blob/main/hdddb/all/usr/bin/hdddb.sh For now, we can only assume that this phenomenon is continuing, and if you perform a manual update, this phenomenon will disappear.
  14. Peter Suh
    If you are curious about the structure of /dev/md0, there is also a way to mount it directly and see it. In the case of TCRP, you can access the TTYD console via a web browser during the DSM installation phase. TTYD uses port 7681 and the account is root with no password. You can also mount it briefly and check the contents with the following script. mkdir -p /mnt/md0 mount /dev/md0 /mnt/md0/ cd /mnt/md0/ Perhaps, when changing to DSM 7, the trigger to expand the system partition from 2.4G to 8G was automatically executed from the script that runs first when Synology boots in Junior mode. If you want to analyze this as well, you can check the "linuxrc.syno.impl" file in the root path and TTYD access in Junior mode. Originally, QC might be related to package operation in genuine, but XPE seems to have implemented an attempt to bypass this in lkm by RP developers. Recently, when installing Apollo Lake on DSM 7.2.2, there was a problem in the part where the BIOS bypass process was set to not perform genuine check (probably through QC). @wjz304 and I analyzed /var/log/messages on Junior and found the cause of the above phenomenon that causes error code 21, and updated and compiled lkm once more for this. https://github.com/RROrg/rr/issues/2607#issuecomment-2315487946 I don't know much about ABB packages because I don't have experience with them, but /dev/loop0 seems to be confirmed on Junior. I don't know if /dev/loop0 is used because the ABB package is pre-installed, but the default log shows that it is not being used. It would be difficult to prove that this loop device, which is used for temporary virtualization and mounting, played a major role in destroying the system partition.
  15. Peter Suh
    Please double check if you accidentally missed the disks addon in ARC. If you don't miss it and the problem persists, try changing the loader to my mshell. https://github.com/PeterSuh-Q3/tinycore-redpill/releases/tag/v1.0.4.7
×
×
  • Create New...