Jump to content
XPEnology Community

TinyCore RedPill Loader (TCRP)


pocopico

Recommended Posts

On 8/9/2023 at 8:00 AM, alirz1 said:

sudo: /usr/local/bin/grub-editenv: command not found
sudo: /usr/local/bin/grub-editenv: command not found
 

I as I can see try update from base tinycore-redpill.v0.8.0.x, error can ignore it if at first boot you can select with keyboard TCRP FRIEND entry to boot.
rploader.sh is deprecated on tinycore v0.9.4.9c but can give try
 

./rploader.sh update
./rploader.sh fullupgrade
./rploader.sh clean now
# edit/restore user_config.json to fit your environment
#./rploader.sh identifyusb now
#./rploader.sh satamap now
# vi user_config.json
# check the settings, pay attention to pid, vid, netif_num, SataPortMap, DiskIdxMap, maxlanport, netif_seq if need it
# build ds918p-7.1.1-42962 or ds918p-7.2.0-64570
./rploader.sh ext ds918p-7.1.1-42962 add https://github.com/pocopico/tcrp-addons/raw/main/acpid/rpext-index.json
./rploader.sh build ds918p-7.1.1-42962 manual 
sudo rm -rf /home/tc/oldpat.tar.gz
./rploader.sh clean now 
./rploader.sh backup now 
sudo reboot


Please noted "manual" option must be use if want to be available to update from 7.1.1-42962 to 7.2.0-64570 on the fly from DSM menu with help of TCRP FRIEND.

LE: TCRP FRIEND build with Peter Suh scripts v0.9.4.3-2 not support update from 7.1.1-42962 to 7.2.0-64570 from DSM menu at this time.
 

How do i disable "checking for latest friend" --> user_config.json --> "friendautoupd": "false"
ETH0 is now ETH1 and vice versa --> user_config.json --> change "maxlanport":"8", "netif_seq": "0 1 2 3 4 5 6 7" --> to "maxlanport":"2", "netif_seq": "1 0"
CTRL+C to stop TCRP FRIEND to boot DSM and edit /mnt/tcrp/user_config.json via shell or \\TCRPFRIEND\tcrpfriend\tcrp\user_config.json form a PC.

Enjoy TCRP FRIEND.

Edited by pcristi
Link to comment
Share on other sites

On 8/12/2023 at 7:15 AM, pcristi said:

I as I can see try update from base tinycore-redpill.v0.8.0.x, error can ignore it if at first boot you can select with keyboard TCRP FRIEND entry to boot.
rploader.sh is deprecated on tinycore v0.9.4.9c but can give try
 

./rploader.sh update
./rploader.sh fullupgrade
./rploader.sh clean now
# edit/restore user_config.json to fit your environment
#./rploader.sh identifyusb now
#./rploader.sh satamap now
# vi user_config.json
# check the settings, pay attention to pid, vid, netif_num, SataPortMap, DiskIdxMap, maxlanport, netif_seq if need it
# build ds918p-7.1.1-42962 or ds918p-7.2.0-64570
./rploader.sh ext ds918p-7.1.1-42962 add https://github.com/pocopico/tcrp-addons/raw/main/acpid/rpext-index.json
./rploader.sh build ds918p-7.1.1-42962 manual 
sudo rm -rf /home/tc/oldpat.tar.gz
./rploader.sh clean now 
./rploader.sh backup now 
sudo reboot


Please noted "manual" option must be use if want to be available to update from 7.1.1-42962 to 7.2.0-64570 on the fly from DSM menu with help of TCRP FRIEND.

LE: TCRP FRIEND build with Peter Suh scripts v0.9.4.3-2 not support update from 7.1.1-42962 to 7.2.0-64570 from DSM menu at this time.
 

How do i disable "checking for latest friend" --> user_config.json --> "friendautoupd": "false"
ETH0 is now ETH1 and vice versa --> user_config.json --> change "maxlanport":"8", "netif_seq": "0 1 2 3 4 5 6 7" --> to "maxlanport":"2", "netif_seq": "1 0"
CTRL+C to stop TCRP FRIEND to boot DSM and edit /mnt/tcrp/user_config.json via shell or \\TCRPFRIEND\tcrpfriend\tcrp\user_config.json form a PC.

Enjoy TCRP FRIEND.

Thank you. This is great information. Really useful.

Link to comment
Share on other sites

After usb broke down i made  a new one and tried to get it working again

whenever i give the command to build wit tcrp i get this message back

  Quote

tc@box:~$ Error : Platform not found :
-sh: Error: not found
tc@box:~$ ./rploader.sh build ds3622xs+-7.1.0-42661
Error : Platform not found :
rploader.sh
 

Tryint to go from 7.0.1  to 7.1.0 or higher to 7.2.1

Who can direct waht i am doing wrong or is going wrong?

After trying the 3615 and the 3617 build i got the same error

Is there someting down or have i screwed up tottaly?

 

Edited by ikkeenjij36
typo,s
Link to comment
Share on other sites

2 hours ago, ikkeenjij36 said:

After usb broke down i made  a new one and tried to get it working again

whenever i give the command to build wit tcrp i get this message back

  Quote

tc@box:~$ Error : Platform not found :
-sh: Error: not found
tc@box:~$ ./rploader.sh build ds3622xs+-7.1.0-42661
Error : Platform not found :
rploader.sh
 

Tryint to go from 7.0.1  to 7.1.0 or higher to 7.2.1

Who can direct waht i am doing wrong or is going wrong?

After trying the 3615 and the 3617 build i got the same error

Is there someting down or have i screwed up tottaly?

 

Got it working with command 

Quote

tc@box:~$ ./rploader.sh build ds3622xsp-7.2.0-64570
 

So tried this and now it works,all data intact and uodated to 7,2,0

Link to comment
Share on other sites

  • 2 weeks later...

[NOTICE]

Now, when using DS918+ and HBA in REDPILL, the hard drive serial number is displayed.

 

I've been hanging here all day today, and for the first time in a while, I'm bringing you some good news.

 

It seems that DS918+ will now rise again to the level of the most perfect model.

Transcoding, HBA everything is perfect.

This makes it the only model that supports these two conditions.

 

Until now, there has been a problem with not being able to distribute the serial number, which is the S.M.A.R.T information of the hard disk, when using it with HBA.

There was a fatal problem that made it difficult to replace the hard drive when using it in raid mode.

 

Today, the source of lkm5 for Kernel 5 developed for SA6400 was developed targeting Kernel 5, but various improvements were seen.

https://github.com/XPEnology-Community/redpill-lkm5

 

I imported only the improved parts of the existing lkm source for Kernel 4 and compiled it.

A new source that stands out is scsi_disk_serial.c / scsi_disk_serial.h.

I could smell it just by looking at the name, so I brought it right away. lol

scsi corresponds to the hba device and means the serial source of the disk.

 

https://github.com/PeterSuh-Q3/redpill-lkm/blob/master/shim/storage/scsi_disk_serial.c

 

Many experts came together to solve this problem in order to improve this source.

Development was completed 3 months ago, but it seems no one has thought to apply it to Kernel 4.^^

 

2023-08-307_37_10.thumb.png.ca031667824c9eb77c00f81d4fa27cbe.png

 

 

Currently only applied to M-SHELL.

I will spread this information separately to ARPL developers.

 

As always, you will need to rebuild your loader.

The lkm version that must be updated to the new version during the build process is 23.5.8.

https://github.com/PeterSuh-Q3/redpill-lkm/releases/tag/23.5.8

 

2023-08-307_24_57.thumb.png.9542d784400fa62c0795adbd5e5e0a3a.png

 

 

  • Like 3
Link to comment
Share on other sites

Hi All,

 

I'm struggling to install DS920p and load the MPT3SAS Driver.

 

I'm running the command to add it:

./rploader.sh ext ds920p-7.2.0-64570 add https://raw.githubusercontent.com/pocopico/rp-ext/master/mpt3sas/rpext-index.json

This appears to work correctly and pull the drivers. I see the following:

tc@box:~$ ./rploader.sh ext ds920p-7.2.0-64570 add https://raw.githubusercontent.com/pocopico/rp-ext/master/mpt3sas/rpext-index.json
Rploader Version : 0.9.4.9
Loader source : https://github.com/pocopico/redpill-load.git Loader Branch : develop
Redpill module source : https://github.com/pocopico/redpill-lkm.git : Redpill module branch : master
Extensions :   all-modules
  eudev
  disks
  misc
Extensions URL : "https://github.com/pocopico/tcrp-addons/raw/main/all-modules/rpext-index.json",
"https://github.com/pocopico/tcrp-addons/raw/main/eudev/rpext-index.json",
"https://github.com/pocopico/tcrp-addons/raw/main/disks/rpext-index.json",
"https://github.com/pocopico/tcrp-addons/raw/main/misc/rpext-index.json"
TOOLKIT_URL : https://sourceforge.net/projects/dsgpl/files/toolkit/DSM7.0/ds.bromolow-7.0.dev.txz/download
TOOLKIT_SHA : a5fbc3019ae8787988c2e64191549bfc665a5a9a4cdddb5ee44c10a48ff96cdd
SYNOKERNEL_URL : https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/25426branch/bromolow-source/linux-3.10.x.txz/download
SYNOKERNEL_SHA : 18aecead760526d652a731121d5b8eae5d6e45087efede0da057413af0b489ed
COMPILE_METHOD : toolkit_dev
TARGET_PLATFORM       : ds920p
TARGET_VERSION    : 7.2.0
TARGET_REVISION : 64570
REDPILL_LKM_MAKE_TARGET : dev-v7
KERNEL_MAJOR : 4
MODULE_ALIAS_FILE :  modules.alias.4.json
SYNOMODEL : ds920p_64570
MODEL : DS920+
Local Cache Folder : /mnt/sda3/auxfiles
DATE Internet : 30082023 Local : 30082023
Checking Internet Access -> OK
Cloning into 'redpill-lkm'...
remote: Enumerating objects: 1715, done.
remote: Counting objects: 100% (483/483), done.
remote: Compressing objects: 100% (95/95), done.
remote: Total 1715 (delta 415), reused 395 (delta 388), pack-reused 1232
Receiving objects: 100% (1715/1715), 5.84 MiB | 11.44 MiB/s, done.
Resolving deltas: 100% (1049/1049), done.
Cloning into 'redpill-load'...
remote: Enumerating objects: 5098, done.
remote: Counting objects: 100% (5098/5098), done.
remote: Compressing objects: 100% (2251/2251), done.
remote: Total 5098 (delta 2703), reused 4983 (delta 2644), pack-reused 0
Receiving objects: 100% (5098/5098), 125.90 MiB | 11.84 MiB/s, done.
Resolving deltas: 100% (2703/2703), done.
[#] Checking runtime for required tools... [OK]
[#] Adding new extension from https://raw.githubusercontent.com/pocopico/rp-ext/master/mpt3sas/rpext-index.json...
[#] Downloading remote file https://raw.githubusercontent.com/pocopico/rp-ext/master/mpt3sas/rpext-index.json to /home/tc/redpill-load/custom/extensions/_new_ext_index.tmp_json
################################################################################################################################################### 100.0%
[OK]
[#] ========================================== pocopico.mpt3sas ==========================================
[#] Extension name: mpt3sas
[#] Description: Adds LSI MPT Fusion SAS 3.0 Device Driver Support
[#] To get help visit: <todo>
[#] Extension preparer/packer: https://github.com/pocopico/rp-ext/tree/main/mpt3sas
[#] Software author: https://github.com/pocopico
[#] Update URL: https://raw.githubusercontent.com/pocopico/rp-ext/master/mpt3sas/rpext-index.json
[#] Platforms supported: ds1621p_42218 ds1621p_42951 ds918p_41890 dva3221_42661 ds3617xs_42621 ds3617xs_42218 ds920p_42661 dva3221_42962 ds918p_42661 ds3622xsp_42962 ds3617xs_42951 dva1622_42218 dva1622_42621 ds920p_42962 ds1621p_42661 dva1622_42951 ds918p_25556 dva3221_42218 ds3615xs_42661 dva3221_42951 ds3622xsp_42661 ds2422p_42661 ds3622xsp_42218 ds2422p_42962 rs4021xsp_42621 dva1622_42962 ds2422p_42218 rs4021xsp_42962 dva3221_42621 ds3615xs_42962 ds3617xs_42962 ds3615xs_41222 ds920p_42951 rs4021xsp_42218 ds2422p_42951 ds918p_42621 ds3617xs_42661 ds3615xs_25556 ds920p_42218 rs4021xsp_42951 ds920p_42621 ds918p_42962 ds3615xs_42951 ds3622xsp_42951 dva1622_42661 ds918p_42218 ds2422p_42621 ds1621p_42621 ds3615xs_42621 ds3615xs_42218 ds1621p_42962 ds3622xsp_42621 rs4021xsp_42661
[#] =======================================================================================


 

However when I do a build ./rploader.sh build ds920p-7.2.0-64570 I get the following:

[-] The extension pocopico.mpt3sas was found. However, the extension index has no recipe for ds920p_64570 platform. It may not be
[-] supported on that platform, or author didn't updated it for that platform yet. You can try running
[-] "ext-manager.sh update" to refresh indexes for all extensions manually.

 

Is there any know version of MPT3SAS that will work with the DS920P? I was keen to use it for the Intel Quick Shift transcoding options. My current install is ds3617xs however it doesn't support transcoding at all.

 

Thanks,

 

KS

 

Link to comment
Share on other sites

1 hour ago, killseeker said:

Hi All,

 

I'm struggling to install DS920p and load the MPT3SAS Driver.

 

I'm running the command to add it:

./rploader.sh ext ds920p-7.2.0-64570 add https://raw.githubusercontent.com/pocopico/rp-ext/master/mpt3sas/rpext-index.json

This appears to work correctly and pull the drivers. I see the following:

tc@box:~$ ./rploader.sh ext ds920p-7.2.0-64570 add https://raw.githubusercontent.com/pocopico/rp-ext/master/mpt3sas/rpext-index.json
Rploader Version : 0.9.4.9
Loader source : https://github.com/pocopico/redpill-load.git Loader Branch : develop
Redpill module source : https://github.com/pocopico/redpill-lkm.git : Redpill module branch : master
Extensions :   all-modules
  eudev
  disks
  misc
Extensions URL : "https://github.com/pocopico/tcrp-addons/raw/main/all-modules/rpext-index.json",
"https://github.com/pocopico/tcrp-addons/raw/main/eudev/rpext-index.json",
"https://github.com/pocopico/tcrp-addons/raw/main/disks/rpext-index.json",
"https://github.com/pocopico/tcrp-addons/raw/main/misc/rpext-index.json"
TOOLKIT_URL : https://sourceforge.net/projects/dsgpl/files/toolkit/DSM7.0/ds.bromolow-7.0.dev.txz/download
TOOLKIT_SHA : a5fbc3019ae8787988c2e64191549bfc665a5a9a4cdddb5ee44c10a48ff96cdd
SYNOKERNEL_URL : https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/25426branch/bromolow-source/linux-3.10.x.txz/download
SYNOKERNEL_SHA : 18aecead760526d652a731121d5b8eae5d6e45087efede0da057413af0b489ed
COMPILE_METHOD : toolkit_dev
TARGET_PLATFORM       : ds920p
TARGET_VERSION    : 7.2.0
TARGET_REVISION : 64570
REDPILL_LKM_MAKE_TARGET : dev-v7
KERNEL_MAJOR : 4
MODULE_ALIAS_FILE :  modules.alias.4.json
SYNOMODEL : ds920p_64570
MODEL : DS920+
Local Cache Folder : /mnt/sda3/auxfiles
DATE Internet : 30082023 Local : 30082023
Checking Internet Access -> OK
Cloning into 'redpill-lkm'...
remote: Enumerating objects: 1715, done.
remote: Counting objects: 100% (483/483), done.
remote: Compressing objects: 100% (95/95), done.
remote: Total 1715 (delta 415), reused 395 (delta 388), pack-reused 1232
Receiving objects: 100% (1715/1715), 5.84 MiB | 11.44 MiB/s, done.
Resolving deltas: 100% (1049/1049), done.
Cloning into 'redpill-load'...
remote: Enumerating objects: 5098, done.
remote: Counting objects: 100% (5098/5098), done.
remote: Compressing objects: 100% (2251/2251), done.
remote: Total 5098 (delta 2703), reused 4983 (delta 2644), pack-reused 0
Receiving objects: 100% (5098/5098), 125.90 MiB | 11.84 MiB/s, done.
Resolving deltas: 100% (2703/2703), done.
[#] Checking runtime for required tools... [OK]
[#] Adding new extension from https://raw.githubusercontent.com/pocopico/rp-ext/master/mpt3sas/rpext-index.json...
[#] Downloading remote file https://raw.githubusercontent.com/pocopico/rp-ext/master/mpt3sas/rpext-index.json to /home/tc/redpill-load/custom/extensions/_new_ext_index.tmp_json
################################################################################################################################################### 100.0%
[OK]
[#] ========================================== pocopico.mpt3sas ==========================================
[#] Extension name: mpt3sas
[#] Description: Adds LSI MPT Fusion SAS 3.0 Device Driver Support
[#] To get help visit: <todo>
[#] Extension preparer/packer: https://github.com/pocopico/rp-ext/tree/main/mpt3sas
[#] Software author: https://github.com/pocopico
[#] Update URL: https://raw.githubusercontent.com/pocopico/rp-ext/master/mpt3sas/rpext-index.json
[#] Platforms supported: ds1621p_42218 ds1621p_42951 ds918p_41890 dva3221_42661 ds3617xs_42621 ds3617xs_42218 ds920p_42661 dva3221_42962 ds918p_42661 ds3622xsp_42962 ds3617xs_42951 dva1622_42218 dva1622_42621 ds920p_42962 ds1621p_42661 dva1622_42951 ds918p_25556 dva3221_42218 ds3615xs_42661 dva3221_42951 ds3622xsp_42661 ds2422p_42661 ds3622xsp_42218 ds2422p_42962 rs4021xsp_42621 dva1622_42962 ds2422p_42218 rs4021xsp_42962 dva3221_42621 ds3615xs_42962 ds3617xs_42962 ds3615xs_41222 ds920p_42951 rs4021xsp_42218 ds2422p_42951 ds918p_42621 ds3617xs_42661 ds3615xs_25556 ds920p_42218 rs4021xsp_42951 ds920p_42621 ds918p_42962 ds3615xs_42951 ds3622xsp_42951 dva1622_42661 ds918p_42218 ds2422p_42621 ds1621p_42621 ds3615xs_42621 ds3615xs_42218 ds1621p_42962 ds3622xsp_42621 rs4021xsp_42661
[#] =======================================================================================


 

However when I do a build ./rploader.sh build ds920p-7.2.0-64570 I get the following:

[-] The extension pocopico.mpt3sas was found. However, the extension index has no recipe for ds920p_64570 platform. It may not be
[-] supported on that platform, or author didn't updated it for that platform yet. You can try running
[-] "ext-manager.sh update" to refresh indexes for all extensions manually.

 

Is there any know version of MPT3SAS that will work with the DS920P? I was keen to use it for the Intel Quick Shift transcoding options. My current install is ds3617xs however it doesn't support transcoding at all.

 

Thanks,

 

KS

 

Well I have resolved my issue another way, I found that PeterSuh's loader had an mpt3sas support with DS918+ so I've installed that and migrated successfully.

 

With Transcoding working straight away with the 918+ is there any reason to go 920+ now?

Link to comment
Share on other sites

Has anyone ever encountered this continuously appearing in their /var/log/messages?

 

2023-08-31T18:04:33+10:00 Beast disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdj/device/../../scsi_host/host*/proc_name
2023-08-31T18:04:33+10:00 Beast disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdj/device/../../scsi_host/host*/proc_name
2023-08-31T18:04:33+10:00 Beast synostgd-disk[19287]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdh/device/../../scsi_host/host*/proc_name
2023-08-31T18:04:33+10:00 Beast disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdh/device/../../scsi_host/host*/proc_name
2023-08-31T18:04:33+10:00 Beast synostgd-disk[19290]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdi/device/../../scsi_host/host*/proc_name
2023-08-31T18:04:33+10:00 Beast synostgd-disk[19290]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdi/device/../../scsi_host/host*/proc_name
2023-08-31T18:04:33+10:00 Beast synostgd-disk[19296]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdk/device/../../scsi_host/host*/proc_name
2023-08-31T18:04:33+10:00 Beast synostgd-disk[19296]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdk/device/../../scsi_host/host*/proc_name
2023-08-31T18:04:33+10:00 Beast synostgd-disk[19304]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdn/device/../../scsi_host/host*/proc_name
2023-08-31T18:04:33+10:00 Beast synostgd-disk[19304]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdn/device/../../scsi_host/host*/proc_name
2023-08-31T18:04:33+10:00 Beast synostgd-disk[19299]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdl/device/../../scsi_host/host*/proc_name
2023-08-31T18:04:33+10:00 Beast synostgd-disk[19299]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdl/device/../../scsi_host/host*/proc_name
2023-08-31T18:04:33+10:00 Beast synostgd-disk[19306]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdo/device/../../scsi_host/host*/proc_name
2023-08-31T18:04:33+10:00 Beast synostgd-disk[19306]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdo/device/../../scsi_host/host*/proc_name
2023-08-31T18:04:33+10:00 Beast synostgd-disk[19301]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdm/device/../../scsi_host/host*/proc_name
2023-08-31T18:04:33+10:00 Beast synostgd-disk[19301]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdm/device/../../scsi_host/host*/proc_name

 

Seem to continuously occur every time the synostgd service runs every minute.

 

My install is using a mpt3sas driver on DS918+ install. 7.2.0-64570 Update 1

Edited by killseeker
Link to comment
Share on other sites

17 hours ago, killseeker said:

Well I have resolved my issue another way, I found that PeterSuh's loader had an mpt3sas support with DS918+ so I've installed that and migrated successfully.

 

With Transcoding working straight away with the 918+ is there any reason to go 920+ now?

 

Device-Tree based platforms such as DS920+ (Gemini Lake, r1000, v1000) do not yet support HBA.
I asked jim3ma, who helped with the HBA issue of DS918+, to see if this part could be improved.
I hope you get a hopeful answer.
jim3ma is very interested in SA6400 development.

 

 

Link to comment
Share on other sites

24 minutes ago, Peter Suh said:

 

Device-Tree based platforms such as DS920+ (Gemini Lake, r1000, v1000) do not yet support HBA.
I asked jim3ma, who helped with the HBA issue of DS918+, to see if this part could be improved.
I hope you get a hopeful answer.
jim3ma is very interested in SA6400 development.

 

 

 

Thank you for the response Peter Suh, so not much I can really do but wait for better drivers / combability with HBAs,  if I want to use 918+?

 

2023-08-31T18:39:35+10:00 Beast synostgd-disk[12352]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdn/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:35+10:00 Beast synostgd-disk[12352]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdn/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:35+10:00 Beast synostgd-disk[12354]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdo/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:35+10:00 Beast synostgd-disk[12354]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdo/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:36+10:00 Beast synostgd-disk[12334]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdh/device/../../scsi_host/host*/proc_name

 

Otherwise go back to 3617xs but give up QVS working?

 

Do you think those above errors are anything to really worry about? I'm not seeing anything bad within DSM. only in /var/log/messages.

Edited by killseeker
Link to comment
Share on other sites

2 hours ago, killseeker said:

 

Thank you for the response Peter Suh, so not much I can really do but wait for better drivers / combability with HBAs,  if I want to use 918+?

 

2023-08-31T18:39:35+10:00 Beast synostgd-disk[12352]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdn/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:35+10:00 Beast synostgd-disk[12352]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdn/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:35+10:00 Beast synostgd-disk[12354]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdo/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:35+10:00 Beast synostgd-disk[12354]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdo/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:36+10:00 Beast synostgd-disk[12334]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdh/device/../../scsi_host/host*/proc_name

 

Otherwise go back to 3617xs but give up QVS working?

 

Do you think those above errors are anything to really worry about? I'm not seeing anything bad within DSM. only in /var/log/messages.

 

Even on Junior, I checked the log below in /var/log/messages.

 

Aug 31 10:17:26 synodiskport: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdc/device/../../scsi_host/host*/proc_name
Aug 31 10:17:26 synodiskport: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdc/device/../../scsi_host/host*/proc_name
Aug 31 10:17:26 synodiskport: disk/disk_rule_junior.c:109 Failed to get target on ST9500420AS 1.13.2 64570.0
Aug 31 10:17:26 synodiskport: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdd/device/../../scsi_host/host*/proc_name
Aug 31 10:17:26 synodiskport: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdd/device/../../scsi_host/host*/proc_name
Aug 31 10:17:26 synodiskport: disk/disk_rule_junior.c:109 Failed to get target on WD5000BPKT-22PK4T0 1.13.2 64570.0

 

 

I'm not sure if this is related to this lkm update.
due to a suspected problem
When I check Storage Manager, I see an error message asking me to update the drive database.

 

2023-08-317_38_07.thumb.png.ca9c2e26c86ea7e0eca1e9abc8d5132a.png

 

Recently, I removed example.com, the default RSS fake URL in tcrp, and changed it to point to Synology's real RSS server.

This change appears to be linked to errors related to the Drive database.
This error appears to be an attempt to determine the disk's firmware version.

 

After yesterday's lkm update, we developed and added one more addon.
It is a shell called Synology_HDD_db by @007revad , and I added it to my addon under the name drivedatabase.
https://github.com/PeterSuh-Q3/tcrp-addons/tree/main/drivedatabase

 

This addon has already been applied to M SHELL for TCRP, and will be added automatically when the loader is rebuilt.

If the storage manager's error prompts you to update the drive database, you must reboot once after installing DSM to activate this addon, which is installed as a service.

 

2023-08-318_15_50.thumb.png.039de46fa9efe9bad1ac62690bd26f3a.png

 

I expected this message to disappear after this addon was installed correctly, but

It's not like that.

 

2023-08-317_40_16.thumb.png.88647664bbc335a9301951db5d13582f.png

 

I think we need to wait and see whether the related issues are directly related to the stability of the disk controller.

 

 

The results of our inquiry to ChatGPT are as follows.

answer

 

The log message you provided seems to be generated by a software component or script related to disk management or monitoring. Let's break down the message to understand its components:

1. `synostgd-disk[24680]`: This indicates the name or identifier of the process or program that generated the log message. The number in square brackets might represent the process ID (PID) of the program.

2. `disk/disk_is_mv1475_driver.c:66`: This part of the message indicates the source code file (`disk_is_mv1475_driver.c`) and the line number (`66`) within that file where the issue occurred. It's likely that this is part of the internal implementation of the program.

3. `Can't get sata chip name from pattern /sys/block/sdd/device/../../scsi_host/host*/proc_name`: This is the actual error message. It seems to be indicating that the program is trying to retrieve the SATA chip name, but it's encountering a problem with the specified pattern. The pattern indicates a file path that should lead to the SATA chip name, but there seems to be an issue with how the program is trying to access it.

Based on the information provided, it seems that the program is attempting to gather information about a SATA device or chip using a specific file path pattern, but it's unable to retrieve the required information. This could be due to various reasons, such as incorrect path construction, missing files, or permission issues.

To further troubleshoot this issue, you could consider the following steps:

1. Check the provided path: Verify whether the path `/sys/block/sdd/device/../../scsi_host/host*/proc_name` actually exists on your system and contains the expected information. You can use the `ls` command to explore the file system and check if the path and files are accessible.

2. Permissions: Ensure that the program or process running this code has the necessary permissions to access the files and directories mentioned in the path.

3. Device status: Check the status of the SATA device (`sdd` in this case). Make sure the device is properly connected and functioning.

4. Log context: Look for additional log messages or context that might provide more information about what's causing the issue. Sometimes, there might be related log entries that offer more insight.

5. Code review: If you have access to the source code, review the code in `disk_is_mv1475_driver.c` at line 66. This might give you more information about the exact problem and how the program is attempting to retrieve the information.

If you're not the developer of the program and are encountering this error in a specific software application, it might be a good idea to reach out to the software's support or development team for assistance.

Edited by Peter Suh
  • Like 1
Link to comment
Share on other sites

2 hours ago, killseeker said:

 

Thank you for the response Peter Suh, so not much I can really do but wait for better drivers / combability with HBAs,  if I want to use 918+?

 

2023-08-31T18:39:35+10:00 Beast synostgd-disk[12352]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdn/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:35+10:00 Beast synostgd-disk[12352]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdn/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:35+10:00 Beast synostgd-disk[12354]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdo/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:35+10:00 Beast synostgd-disk[12354]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdo/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:36+10:00 Beast synostgd-disk[12334]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdh/device/../../scsi_host/host*/proc_name

 

Otherwise go back to 3617xs but give up QVS working?

 

Do you think those above errors are anything to really worry about? I'm not seeing anything bad within DSM. only in /var/log/messages.

 

Content related to material from our forum was searched 9 years ago.
I'm not sure if this is the solution.
https://xpenology.com/forum/topic/950-xpenology-and-sas-controller-hba/?do=findComment&comment=8793

  • Like 1
Link to comment
Share on other sites

2 hours ago, killseeker said:

 

Thank you for the response Peter Suh, so not much I can really do but wait for better drivers / combability with HBAs,  if I want to use 918+?

 

2023-08-31T18:39:35+10:00 Beast synostgd-disk[12352]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdn/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:35+10:00 Beast synostgd-disk[12352]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdn/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:35+10:00 Beast synostgd-disk[12354]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdo/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:35+10:00 Beast synostgd-disk[12354]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdo/device/../../scsi_host/host*/proc_name
2023-08-31T18:39:36+10:00 Beast synostgd-disk[12334]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdh/device/../../scsi_host/host*/proc_name

 

Otherwise go back to 3617xs but give up QVS working?

 

Do you think those above errors are anything to really worry about? I'm not seeing anything bad within DSM. only in /var/log/messages.

 

This is another result from Googling.
https://www.spinics.net/lists/raid/msg51309.html
I'm not sure if this is also a solution.

  • Like 1
Link to comment
Share on other sites

Thank you for taking the time to post this information Peter Suh, I will review and see if anything comes back.

 

Nothing appears to be having problems, all data is accessible and DSM appears to be working without any issues at all. Its purely these messages in the /var/log/messages file. Will see where this goes over the next while.

 

Cheers,

 

KS

Link to comment
Share on other sites

7 hours ago, Peter Suh said:

 

Even on Junior, I checked the log below in /var/log/messages.

 

Aug 31 10:17:26 synodiskport: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdc/device/../../scsi_host/host*/proc_name
Aug 31 10:17:26 synodiskport: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdc/device/../../scsi_host/host*/proc_name
Aug 31 10:17:26 synodiskport: disk/disk_rule_junior.c:109 Failed to get target on ST9500420AS 1.13.2 64570.0
Aug 31 10:17:26 synodiskport: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdd/device/../../scsi_host/host*/proc_name
Aug 31 10:17:26 synodiskport: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdd/device/../../scsi_host/host*/proc_name
Aug 31 10:17:26 synodiskport: disk/disk_rule_junior.c:109 Failed to get target on WD5000BPKT-22PK4T0 1.13.2 64570.0

 

 

I'm not sure if this is related to this lkm update.
due to a suspected problem
When I check Storage Manager, I see an error message asking me to update the drive database.

 

2023-08-317_38_07.thumb.png.ca9c2e26c86ea7e0eca1e9abc8d5132a.png

 

Recently, I removed example.com, the default RSS fake URL in tcrp, and changed it to point to Synology's real RSS server.

This change appears to be linked to errors related to the Drive database.
This error appears to be an attempt to determine the disk's firmware version.

 

After yesterday's lkm update, we developed and added one more addon.
It is a shell called Synology_HDD_db by @007revad , and I added it to my addon under the name drivedatabase.
https://github.com/PeterSuh-Q3/tcrp-addons/tree/main/drivedatabase

 

This addon has already been applied to M SHELL for TCRP, and will be added automatically when the loader is rebuilt.

If the storage manager's error prompts you to update the drive database, you must reboot once after installing DSM to activate this addon, which is installed as a service.

 

2023-08-318_15_50.thumb.png.039de46fa9efe9bad1ac62690bd26f3a.png

 

I expected this message to disappear after this addon was installed correctly, but

It's not like that.

 

2023-08-317_40_16.thumb.png.88647664bbc335a9301951db5d13582f.png

 

I think we need to wait and see whether the related issues are directly related to the stability of the disk controller.

 

 

The results of our inquiry to ChatGPT are as follows.

answer

 

The log message you provided seems to be generated by a software component or script related to disk management or monitoring. Let's break down the message to understand its components:

1. `synostgd-disk[24680]`: This indicates the name or identifier of the process or program that generated the log message. The number in square brackets might represent the process ID (PID) of the program.

2. `disk/disk_is_mv1475_driver.c:66`: This part of the message indicates the source code file (`disk_is_mv1475_driver.c`) and the line number (`66`) within that file where the issue occurred. It's likely that this is part of the internal implementation of the program.

3. `Can't get sata chip name from pattern /sys/block/sdd/device/../../scsi_host/host*/proc_name`: This is the actual error message. It seems to be indicating that the program is trying to retrieve the SATA chip name, but it's encountering a problem with the specified pattern. The pattern indicates a file path that should lead to the SATA chip name, but there seems to be an issue with how the program is trying to access it.

Based on the information provided, it seems that the program is attempting to gather information about a SATA device or chip using a specific file path pattern, but it's unable to retrieve the required information. This could be due to various reasons, such as incorrect path construction, missing files, or permission issues.

To further troubleshoot this issue, you could consider the following steps:

1. Check the provided path: Verify whether the path `/sys/block/sdd/device/../../scsi_host/host*/proc_name` actually exists on your system and contains the expected information. You can use the `ls` command to explore the file system and check if the path and files are accessible.

2. Permissions: Ensure that the program or process running this code has the necessary permissions to access the files and directories mentioned in the path.

3. Device status: Check the status of the SATA device (`sdd` in this case). Make sure the device is properly connected and functioning.

4. Log context: Look for additional log messages or context that might provide more information about what's causing the issue. Sometimes, there might be related log entries that offer more insight.

5. Code review: If you have access to the source code, review the code in `disk_is_mv1475_driver.c` at line 66. This might give you more information about the exact problem and how the program is attempting to retrieve the information.

If you're not the developer of the program and are encountering this error in a specific software application, it might be a good idea to reach out to the software's support or development team for assistance.

Hello @Peter Suh  THANK YOU VERY MUCH FOR YOUR ABOVE AND BEYOND ATTENTION and EFFORT in making all of this JUST WORK!

 

I wanted to pass on to you as well, that my 920+ just using standard SATA controllers, now too is showing unknown firmware.  I had previous used that script to have my HDD's recognized by DSM, and all had been just fine for a good while.  The only thing I have done, is on 2 separate times, just to catch some updates you created/added, I rebuild the loader, nothing more.  So whatever got changed/added/modified on the backend, that carried forward into the new builds, making no other modifications, that seems to have brought on this quirk. 😉  It doesn't appear to be detrimental in any way, but just wanted to give you some additional supportive feedback.

 

Thank YOU for being the Master you are!

  • Like 2
Link to comment
Share on other sites

4 hours ago, gericb said:

Hello @Peter Suh  THANK YOU VERY MUCH FOR YOUR ABOVE AND BEYOND ATTENTION and EFFORT in making all of this JUST WORK!

 

I wanted to pass on to you as well, that my 920+ just using standard SATA controllers, now too is showing unknown firmware.  I had previous used that script to have my HDD's recognized by DSM, and all had been just fine for a good while.  The only thing I have done, is on 2 separate times, just to catch some updates you created/added, I rebuild the loader, nothing more.  So whatever got changed/added/modified on the backend, that carried forward into the new builds, making no other modifications, that seems to have brought on this quirk. 😉  It doesn't appear to be detrimental in any way, but just wanted to give you some additional supportive feedback.

 

Thank YOU for being the Master you are!

 

Thank you for your feedback.

 

However, DS920+ is a platform that cannot use HBA, so it seems to have nothing to do with mptsas and the recently improved redpill.ko (lkm).
So, I think the cause of the unknown firmware coming out of DS920+ lies somewhere else.

 

There is already a solution to solve the unknown firmware issue, but there was no notice.
I will post a notice about this “drivedatabse” addon a little later.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Hi guys, i'm trying to install tcrp on TrueNas Core 13.0-U5.3 (bhyve).

 

I'm able to get the installation through with this configuration :

 

TCRP Image (RAW) (sda)
Storage #1 (DISK) (sdb)
Storage #2 (DISK) (sdc)

 

However, this is how it's presented when trying to set up the satamap :

 

tc@box: $ ./rploader.sh satamap now
Machine is VIRTUAL Hypervisor=

Found "00:02.0 Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH) 6 port SATA Controller [AHCI mode]"
Detected 6 ports/0 drives. Bad ports: -5 -4 -3 -2 -1 0. Override # of ports or ENTER to accept <6> ◊

Found "00:03.0 Intel Corporation 82801HR/HO/HH (ICHBR/DO/DH) 6 port SATA Controller [AHCI mode]"
Detected 32 ports/3 drives. Bad ports: 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32. 
Mapping SATABOOT drive after maxdisks WARNING: Other drives are connected that will not be accessible!

Computed settings: SataPortMap=11 DiskIdxMap=0010
WARNING: Bad ports are mapped. The DSM installation will fail!
Should i update the user_config.json with these values ? [Yy/Nn]

 

So it appears that two SATA Controllers are detected, with the first not holding any drives, and second holding the three drives (TCRP, Storage #1, Storage #2).

The "SATABOOT drive after maxdisks" issue seems to be the pain point, and the other drives indeed are unaccessible (synology loader indicates no drives are found).

 

What should I change with the setup or how should I configure the SataPortMap/DiskIdxMap in this configuration?

Do I need to find a way to blacklist/unload the SATA Controller at 00:02.0?

 

Any pointers would be much appreciated!

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...