TinyCore RedPill Loader (TCRP)

pocopico · September 2, 2023

1 hour ago, inc0gnit0 said:
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!

You do have the boot image on different SATA controller right ?

inc0gnit0 · September 2, 2023

@pocopico Thank you for replying and thank you for building TCRP!

With the way it's set up in TrueNAS, I don't see how in the bhyve environment I can designate the boot drive img to be on a different SATA controller from a virtual perspective.

The only way I could think about would be to install the boot drive img on a physical USB and do a passthrough to the VM, that would likely put the boot image on a different controller. I will give that a try, but that isn't an ideal long-term solution.

There is a guide - https://xpenology.com/forum/topic/69420-tutorial-install-dsm-72-on-vm-bhyve-freebsd/ - where it appears that the author is successful. However I don't see how he's designated the boot image to be on a separate controller, even though he's editing the configuration files directly and I'm attempting this through the TrueNAS GUI.

ahci_device_limit="1"
disk0_type="ahci-hd"
disk0_name="tinycore-redpill-uefi.v0.9.4.9.img"
disk1_type="ahci-hd"
disk1_name="disk0.img"
disk1_opts="sectorsize=4096/4096"
disk1_size="10T"

Wondering if anyone else has any documented successes with this setup.

Edited September 2, 2023 by inc0gnit0

inc0gnit0 · September 2, 2023

Okay, I think that from searching as to what "ahci_device_limit" does, it limits the number of devices per controller.

So I guess this is what I would need to do - get this parameter set somehow to 1, and there will be 3 controllers, 1 for each drive apparently.

killseeker · September 2, 2023

@Peter Suh I've tried to find some more information about what is happening under the hood in Synology regarding these messages:

2023-09-03T00:06:32+10:00 Beast synostgd-disk[9340]: 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-09-03T00:06:32+10:00 Beast synostgd-disk[9340]: 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-09-03T00:06:32+10:00 Beast synostgd-disk[9335]: 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-09-03T00:06:32+10:00 Beast synostgd-disk[9335]: 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-09-03T00:06:32+10:00 Beast synostgd-disk[9348]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdm/device/../../scsi_host/host*/proc_name
2023-09-03T00:06:32+10:00 Beast synostgd-disk[9348]: 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-09-03T00:06:32+10:00 Beast synostgd-disk[9354]: 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-09-03T00:06:32+10:00 Beast synostgd-disk[9354]: 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-09-03T00:06:32+10:00 Beast synostgd-disk[9357]: 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-09-03T00:06:32+10:00 Beast synostgd-disk[9357]: 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

I've tracked them to the "systemctl status synostoraged.service":

● synostoraged.service - Synology daemon for monitoring space/disk/cache status
   Loaded: loaded (/usr/lib/systemd/system/synostoraged.service; static; vendor preset: disabled)
   Active: active (running) since Sat 2023-09-02 23:39:31 AEST; 33min ago
 Main PID: 16670 (synostoraged)
   CGroup: /syno_dsm_storage_manager.slice/synostoraged.service
           ├─16670 synostoraged
           ├─16673 synostgd-disk
           ├─16675 synostgd-space
           ├─16677 synostgd-cache
           ├─16678 synostgd-volume
           └─16680 synostgd-external-volume

Sep 03 00:12:32 Beast [3825]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdk/device/../../scsi_host/host*/proc_name
Sep 03 00:12:32 Beast [3825]: 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
Sep 03 00:12:32 Beast [3828]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdl/device/../../scsi_host/host*/proc_name
Sep 03 00:12:32 Beast [3828]: 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
Sep 03 00:12:32 Beast [3831]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdm/device/../../scsi_host/host*/proc_name
Sep 03 00:12:32 Beast [3831]: 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
Sep 03 00:12:32 Beast [3834]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdn/device/../../scsi_host/host*/proc_name
Sep 03 00:12:32 Beast [3834]: 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
Sep 03 00:12:32 Beast [3836]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdo/device/../../scsi_host/host*/proc_name
Sep 03 00:12:32 Beast [3836]: 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

It would be specifically coming from this process: synostgd-disk which seems to run every minute in the background.

I am kind of at a loss of where else to check. My unix knowledge and troubleshooting skills are not that advanced, so I am unsure how else to help out here sorry.

Do you think we need to modify the synostgd-disk service and the tell it to use the mtp3sas driver to do its queries and checks as opposed to the mv1475_driver or mv_soc_driver? Or is this not how it works or not possible?

Even though I see these messages, my Storage manager appears healthy and happy:

Disks are also all visible, and shows serial numbers and all SMART information:

killseeker · September 2, 2023

Checking one of the disks - /dev/sdo, i see the following details:

root@Beast:/# cd /sys/block/sdo/device
root@Beast:/sys/block/sdo/device# ls -la
total 0
drwxr-xr-x 8 root root    0 Sep  2 23:39 .
drwxr-xr-x 4 root root    0 Sep  2 23:39 ..
drwxr-xr-x 3 root root    0 Sep  2 23:39 block
drwxr-xr-x 3 root root    0 Sep  2 23:39 bsg
--w------- 1 root root 4096 Sep  3 00:07 delete
-r--r--r-- 1 root root 4096 Sep  3 00:07 device_blocked
-r--r--r-- 1 root root 4096 Sep  3 00:07 device_busy
lrwxrwxrwx 1 root root    0 Sep  3 00:07 driver -> ../../../../../../../../../bus/scsi/drivers/sd
-rw-r--r-- 1 root root 4096 Sep  3 00:07 eh_timeout
-r--r--r-- 1 root root 4096 Sep  3 00:07 evt_capacity_change_reported
-r--r--r-- 1 root root 4096 Sep  3 00:07 evt_inquiry_change_reported
-r--r--r-- 1 root root 4096 Sep  3 00:07 evt_lun_change_reported
-r--r--r-- 1 root root 4096 Sep  3 00:07 evt_media_change
-r--r--r-- 1 root root 4096 Sep  3 00:07 evt_mode_parameter_change_reported
-r--r--r-- 1 root root 4096 Sep  3 00:07 evt_soft_threshold_reached
lrwxrwxrwx 1 root root    0 Sep  3 00:07 generic -> scsi_generic/sg8
-r--r--r-- 1 root root    0 Sep  3 00:07 inquiry
-r--r--r-- 1 root root 4096 Sep  3 00:07 iocounterbits
-r--r--r-- 1 root root 4096 Sep  3 00:07 iodone_cnt
-r--r--r-- 1 root root 4096 Sep  3 00:07 ioerr_cnt
-r--r--r-- 1 root root 4096 Sep  3 00:07 iorequest_cnt
-r--r--r-- 1 root root 4096 Sep  3 00:07 modalias
-r--r--r-- 1 root root 4096 Sep  3 00:07 model
drwxr-xr-x 2 root root    0 Sep  3 00:02 power
-rw-r--r-- 1 root root 4096 Sep  3 00:07 queue_depth
-rw-r--r-- 1 root root 4096 Sep  3 00:07 queue_ramp_up_period
-rw-r--r-- 1 root root 4096 Sep  3 00:07 queue_type
--w------- 1 root root 4096 Sep  3 00:07 rescan
-r--r--r-- 1 root root 4096 Sep  3 00:07 rev
-r--r--r-- 1 root root 4096 Sep  3 00:07 sas_address
-r--r--r-- 1 root root 4096 Sep  3 00:07 sas_device_handle
drwxr-xr-x 3 root root    0 Sep  2 23:39 scsi_device
drwxr-xr-x 3 root root    0 Sep  2 23:39 scsi_disk
drwxr-xr-x 3 root root    0 Sep  2 23:39 scsi_generic
-r--r--r-- 1 root root 4096 Sep  3 00:07 scsi_level
-rw-r--r-- 1 root root 4096 Sep  3 00:07 state
lrwxrwxrwx 1 root root    0 Sep  2 23:39 subsystem -> ../../../../../../../../../bus/scsi
-r--r--r-- 1 root root 4096 Sep  3 00:07 syno_disk_serial
-rw-r--r-- 1 root root 4096 Sep  3 00:07 syno_idle_time
-rw-r--r-- 1 root root 4096 Sep  3 00:07 syno_scmd_min_timeout
-r--r--r-- 1 root root 4096 Sep  3 00:07 syno_spindown
-rw-r--r-- 1 root root 4096 Sep  3 00:07 syno_standby_syncing
-rw-r--r-- 1 root root 4096 Sep  3 00:07 timeout
-r--r--r-- 1 root root 4096 Sep  3 00:07 type
-rw-r--r-- 1 root root 4096 Sep  3 00:07 uevent
-r--r--r-- 1 root root 4096 Sep  3 00:07 vendor
-r--r--r-- 1 root root    0 Sep  3 00:07 vpd_pg80
-r--r--r-- 1 root root    0 Sep  3 00:07 vpd_pg83

Peter Suh · September 2, 2023

1 hour ago, killseeker said:

Checking one of the disks - /dev/sdo, i see the following details:

root@Beast:/# cd /sys/block/sdo/device
root@Beast:/sys/block/sdo/device# ls -la
total 0
drwxr-xr-x 8 root root    0 Sep  2 23:39 .
drwxr-xr-x 4 root root    0 Sep  2 23:39 ..
drwxr-xr-x 3 root root    0 Sep  2 23:39 block
drwxr-xr-x 3 root root    0 Sep  2 23:39 bsg
--w------- 1 root root 4096 Sep  3 00:07 delete
-r--r--r-- 1 root root 4096 Sep  3 00:07 device_blocked
-r--r--r-- 1 root root 4096 Sep  3 00:07 device_busy
lrwxrwxrwx 1 root root    0 Sep  3 00:07 driver -> ../../../../../../../../../bus/scsi/drivers/sd
-rw-r--r-- 1 root root 4096 Sep  3 00:07 eh_timeout
-r--r--r-- 1 root root 4096 Sep  3 00:07 evt_capacity_change_reported
-r--r--r-- 1 root root 4096 Sep  3 00:07 evt_inquiry_change_reported
-r--r--r-- 1 root root 4096 Sep  3 00:07 evt_lun_change_reported
-r--r--r-- 1 root root 4096 Sep  3 00:07 evt_media_change
-r--r--r-- 1 root root 4096 Sep  3 00:07 evt_mode_parameter_change_reported
-r--r--r-- 1 root root 4096 Sep  3 00:07 evt_soft_threshold_reached
lrwxrwxrwx 1 root root    0 Sep  3 00:07 generic -> scsi_generic/sg8
-r--r--r-- 1 root root    0 Sep  3 00:07 inquiry
-r--r--r-- 1 root root 4096 Sep  3 00:07 iocounterbits
-r--r--r-- 1 root root 4096 Sep  3 00:07 iodone_cnt
-r--r--r-- 1 root root 4096 Sep  3 00:07 ioerr_cnt
-r--r--r-- 1 root root 4096 Sep  3 00:07 iorequest_cnt
-r--r--r-- 1 root root 4096 Sep  3 00:07 modalias
-r--r--r-- 1 root root 4096 Sep  3 00:07 model
drwxr-xr-x 2 root root    0 Sep  3 00:02 power
-rw-r--r-- 1 root root 4096 Sep  3 00:07 queue_depth
-rw-r--r-- 1 root root 4096 Sep  3 00:07 queue_ramp_up_period
-rw-r--r-- 1 root root 4096 Sep  3 00:07 queue_type
--w------- 1 root root 4096 Sep  3 00:07 rescan
-r--r--r-- 1 root root 4096 Sep  3 00:07 rev
-r--r--r-- 1 root root 4096 Sep  3 00:07 sas_address
-r--r--r-- 1 root root 4096 Sep  3 00:07 sas_device_handle
drwxr-xr-x 3 root root    0 Sep  2 23:39 scsi_device
drwxr-xr-x 3 root root    0 Sep  2 23:39 scsi_disk
drwxr-xr-x 3 root root    0 Sep  2 23:39 scsi_generic
-r--r--r-- 1 root root 4096 Sep  3 00:07 scsi_level
-rw-r--r-- 1 root root 4096 Sep  3 00:07 state
lrwxrwxrwx 1 root root    0 Sep  2 23:39 subsystem -> ../../../../../../../../../bus/scsi
-r--r--r-- 1 root root 4096 Sep  3 00:07 syno_disk_serial
-rw-r--r-- 1 root root 4096 Sep  3 00:07 syno_idle_time
-rw-r--r-- 1 root root 4096 Sep  3 00:07 syno_scmd_min_timeout
-r--r--r-- 1 root root 4096 Sep  3 00:07 syno_spindown
-rw-r--r-- 1 root root 4096 Sep  3 00:07 syno_standby_syncing
-rw-r--r-- 1 root root 4096 Sep  3 00:07 timeout
-r--r--r-- 1 root root 4096 Sep  3 00:07 type
-rw-r--r-- 1 root root 4096 Sep  3 00:07 uevent
-r--r--r-- 1 root root 4096 Sep  3 00:07 vendor
-r--r--r-- 1 root root    0 Sep  3 00:07 vpd_pg80
-r--r--r-- 1 root root    0 Sep  3 00:07 vpd_pg83

Thank you for your feedback.
After further investigation, I found three proc_names.

It contains the following contents
The .c sources probably wanted to find mpt2sas.

root@DS918p_n_HBA:/# find . -name proc_name
./sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host2/scsi_host/host2/proc_name
./sys/devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0/host1/scsi_host/host1/proc_name
./sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/scsi_host/host0/proc_name
root@DS918p_n_HBA:/# cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host2/scsi_host/host2/proc_name
mpt2sas
root@DS918p_n_HBA:/# cat ./sys/devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3:1.0/host1/scsi_host/host1/proc_name
usb-storage
root@DS918p_n_HBA:/# cat ./sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/scsi_host/host0/proc_name
ahci

I think the coding for the change in the way to access the path has not been modified.
Synology's kernel version is quite old, corresponding to kernel 4.
Linux currently has kernel 6, but Synology is now attempting kernel 5.
I think that the old kernel program sources are not being modified to keep up with the constantly changing new hardware.
Since the content appears to be intended to display simple text, it is presumed that it is not a critical error.

Edited September 2, 2023 by Peter Suh

hendry · September 3, 2023

hi @pocopico

can you compile v9fs drivers for latest build 7.2 ?

hendry · September 4, 2023

@pocopico why the result of loader.img does not have custom.gz file ?

in fact i add some custom extenstion before build the loader.

MODEL="DS918+"
PLATFORM="APOLLOLAKE"
GRUB_PROJECT="grub-2.x"
GRUB_VERSION="1"
DSM_VERSION="42218"

has custom.gz like this one

image.png.242033fa29adb6c47c64b0b81e3b2dc5.png

but on

MODEL="DS3622xs+"
PLATFORM="BROADWELLNK"
GRUB_PROJECT="grub-2.x"
GRUB_VERSION="1"
DSM_VERSION="42962"
no custom.gz

image.png.cc7f8c9200aad7b3aacda0b8e526b2b0.png

Edited September 4, 2023 by hendry

chiefg · September 4, 2023

I using a m-shell and have DVA3221 working with a Quadro P2000, transcoding is working fine,

currently on update 1,

can I update to update 4 manually?

SystemDevil · September 10, 2023

Hi guys, I desperately need your help. I was searching the forum, tried some things but this does not solve my issue.

I had installed DSM version 6.2.4-25556 + 1.04b loader on custom PC using DS918+ platform. Yesterday I tried to upgrade to TCRP and I followed steps described in the topic:

./rploader.sh update
./rploader.sh fullupgrade
./rploader.sh serialgen DS918+

./rploader.sh serialgen DS918+ realmac

./rploader.sh identifyusb
./rploader.sh satamap
./rploader.sh build ds918p-7.2.0-64570 (couse it is the newest version in platforms list - ./rploader.sh)

exitcheck.sh reboot

After reboot I have chosen the first option (...USB, Verbose) instead of proposed TinyCore RedPill FRIEND (btw I don't understand it's purpose and have not found any description regarding it).

then - https://finds.synology.com/ - system proposed to install new version and "save the data and configuration" - I choose that method.

- then I have manually dowloaded DSM_DS918+_64570.pat file from https://global.synologydownload.com/download/DSM/release/7.2/64570-1/DSM_DS918%2B_64570.pat?model=DS918%2B&bays=4&dsm_version=7.2&build_number=64570 and uploaded it to installation process dialog. At some point - reboot.

After this system trapped in recovery loop with reboots. I have tried to rebuild loader couple times (with rewriting USB), use ARPL, use lower version (7.1.1), "./rploader.sh postupdate". Nothing worked for me.

Edited September 10, 2023 by SystemDevil

Vodka2014 · September 10, 2023

24 minutes ago, SystemDevil said:

Hi guys, I desperately need your help. I was searching the forum, tried some things but this does not solve my issue.

I had installed DSM version 6.2.4-25556 + 1.04b loader on custom PC using DS918+ platform. Yesterday I tried to upgrade to TCRP and I followed steps described in the topic:

./rploader.sh update
./rploader.sh fullupgrade
./rploader.sh serialgen DS918+

./rploader.sh serialgen DS918+ realmac

./rploader.sh identifyusb
./rploader.sh satamap
./rploader.sh build ds918p-7.2.0-64570 (couse it is the newest version in platforms list - ./rploader.sh)

exitcheck.sh reboot

After reboot I have chosen the first option (...USB, Verbose) instead of proposed TinyCore RedPill FRIEND (btw I don't understand it's purpose and have not found any description regarding it).

then - https://finds.synology.com/ - system proposed to install new version and "save the data and configuration" - I choose that method.

- then I have manually dowloaded DSM_DS918+_64570.pat file from https://global.synologydownload.com/download/DSM/release/7.2/64570-1/DSM_DS918%2B_64570.pat?model=DS918%2B&bays=4&dsm_version=7.2&build_number=64570 and uploaded it to installation process dialog. At some point - reboot.

After this system trapped in recovery loop with reboots. I have tried to rebuild loader couple times (with rewriting USB), use ARPL, use lower version (7.1.1), "./rploader.sh postupdate". Nothing worked for me.

I am not a Pro at all but give this a try. I rebuilt my USB (make sure you use a new one so you have a backup) using the new M-Shell. I no longer run commands and it worked 100% for me - https://xpenology.com/forum/topic/61839-tinycore-redpill-loader-build-support-tool-m-shell/page/25/

https://github.com/PeterSuh-Q3/tinycore-redpill/releases

I used the latest release and followed the guide it is like 4 options to select and then you let it do is thing. Once done i rebooted and it asked me to migrate and it worked to Update 1.

Like i said i am not an Pro i just followed this guide.

Maybe @Peter Suh is able to help more with this.

Edited September 10, 2023 by Vodka2014

SystemDevil · September 11, 2023

On 9/10/2023 at 11:01 AM, Vodka2014 said:

I am not a Pro at all but give this a try. I rebuilt my USB (make sure you use a new one so you have a backup) using the new M-Shell. I no longer run commands and it worked 100% for me - https://xpenology.com/forum/topic/61839-tinycore-redpill-loader-build-support-tool-m-shell/page/25/

https://github.com/PeterSuh-Q3/tinycore-redpill/releases

I used the latest release and followed the guide it is like 4 options to select and then you let it do is thing. Once done i rebooted and it asked me to migrate and it worked to Update 1.

Like i said i am not an Pro i just followed this guide.

Maybe @Peter Suh is able to help more with this.

I was using ARPL - arpl/releases/tag/v1.1-beta2a from this post

which is linked in

and ARPL v1.1-beta2a seems like old package.

But anyway, @Vodka2014 thank you very much for your help, you saved my ass! I have managed to successfully complete migration to 7.2.0 and run my NAS + most of the settings are in place.

Edited September 11, 2023 by SystemDevil

Vodka2014 · September 12, 2023

Hi All,

My setup has crashed. I cannot log into my NAS and blelow are the specs:

DS3622xs+ / HP Microserver GEN8 / Latest IMG / Latest Friend / RAID 5 / EXT4 / LSI 9211-4i / DSM 7.2.0-64570 Update 3

I checked some things based on the commands above to see what is going on. It seems the system recovered BUT the Storage Pool and Disks seems to have issues,

systemctl status synostoraged.service
● synostoraged.service - Synology daemon for monitoring space/disk/cache status
Loaded: loaded (/usr/lib/systemd/system/synostoraged.service; static; vendor preset: disabled)
Active: inactive (dead)

find . -name proc_name

ps
PID TTY TIME CMD
11791 pts/0 00:00:00 sudo
11792 pts/0 00:00:00 ash
11855 pts/0 00:00:00 ps

df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md0 2385528 1430224 836520 64% /
devtmpfs 2994244 0 2994244 0% /dev
tmpfs 3048436 4 3048432 1% /dev/shm
tmpfs 3048436 8016 3040420 1% /run
tmpfs 3048436 0 3048436 0% /sys/fs/cgroup
tmpfs 3048436 280 3048156 1% /tmp

I really need some help to get my system up and running or downgrade, restore, remove the HBA and add back to the onboard etc...

Thanks in advanced.

Vodka2014 · September 13, 2023

My Issue Above has been confirmed as mpt3sas module issue and getting looked at.

Peter Suh · September 20, 2023

[How to check Redpill log when TCRP boot fails]

There are two main problems when booting MSHELL for TCRP.

In cases where the LAN card is not recognized and ping or connection to port 5000 is not possible,

This is a case where the disk is not recognized.

If you encounter this case, return to the screen below to build the TCRP loader.

Find the ./logs/jr folder under /mnt/sd#1, the first partition of the USB memory.

The reason it is written as sd# is because it can be variably changed to sda, sdb, sdc, etc.

First, open the linuxrc.syno.log file.

Did module loading fail or did the loader stop for some reason?

Related information is recorded.

If you would like to check more details

Just open the dmesg file.

There is so much information that it may be difficult to read.

If MSHELL for TCRP does not work well, please attach the two files linuxrc.syno.log / dmesg and let me know and I will analyze the error.

2023-09-126_36_59.png.9139cbbc8e01b7e113eb8d11ca3fc194.png

(This is how to download log files.)

Open a command window using cmd in Windows. Try the command as below.

mkdir c:\tmp
scp -r tc@192.168.82.131:/mnt/sda1/logs/jr/* c:\tmp
dir c:\tmp

You will receive several files.

It asks for the password and the password is P@ssw0rd.

The 0 after w is the number 0.

Edited September 20, 2023 by Peter Suh

sagrotan · September 22, 2023

No drives under 7.2 / 7.1 all fine

Using TCRP0.9.5.0 Mshell with a test VM on ESXI6.5U3 on a Microserver Gen8 with a E3-1265V2.

Synoboot at SATA0 (0:0)

Testdisk at SATA1 (0:0) 21GB

I can build a 7.1.1 loader with no problems and I am able to install DSM.

When I build the 7.2 loader with the same process, I always get "no drives detected".

Tried DS3622 and DS3617 and let MShell do the ID Magic with the Drives.

I am out of ideas what to test or where to read.

Anyone an idea?

Peter Suh · September 22, 2023

2 hours ago, sagrotan said:

No drives under 7.2 / 7.1 all fine

Using TCRP0.9.5.0 Mshell with a test VM on ESXI6.5U3 on a Microserver Gen8 with a E3-1265V2.

Synoboot at SATA0 (0:0)

Testdisk at SATA1 (0:0) 21GB

I can build a 7.1.1 loader with no problems and I am able to install DSM.

When I build the 7.2 loader with the same process, I always get "no drives detected".

Tried DS3622 and DS3617 and let MShell do the ID Magic with the Drives.

I am out of ideas what to test or where to read.

Anyone an idea?

Shouldn't SATA1 be (0:1) and not (0:0)?
I will now report the build results of 7.1.1 and 7.2 on ESXI 7.0.3 and MSHELL

There has been a file version mismatch issue in the TCRP FRIEND kernel download main domain since about 2 hours and 15 minutes ago.
Perhaps this was the cause.
Would you like to try rebuilding the loader now?
Please check (0:1) for SATA1.

Edited September 22, 2023 by Peter Suh

sagrotan · September 22, 2023

1 hour ago, Peter Suh said:

Shouldn't SATA1 be (0:1) and not (0:0)?
I will now report the build results of 7.1.1 and 7.2 on ESXI 7.0.3 and MSHELL

There has been a file version mismatch issue in the TCRP FRIEND kernel download main domain since about 2 hours and 15 minutes ago.
Perhaps this was the cause.
Would you like to try rebuilding the loader now?
Please check (0:1) for SATA1.

Thanks for your reply!

Tried directly again with SATA1 (0:0) and (0:1), but still no luck.

Out of ideas, I deleted SATA Controller 1 and moved storage disk to SATA0 (0:1) and now I am able to install DSM. Could it be something with SataPortMap/DiskIdxMap? I don't know.

My production VM has a LSI2008 attached via passtrough, but I still read about problems with mpt3sas. I think it's a good idea to stick at 7.1.1 for some time.

Peter Suh · September 23, 2023

[NOTICE]

mpt3sas module version upgrade from 41.00.00.00 to 46.00.00.00

@pocopico's 41.00.00.00 was January 2022 version of broadcom.

https://docs.broadcom.com/docs/Linux_Driver-RHEL7-8_SLES12-15_GEN35_PHASE_22.0_NVME.zip

It was replaced with 46.00.00.00, the final version this year.

https://docs.broadcom.com/docs/Linux_Driver-RHEL8-9_SLES12-15_GEN35_PHASE_27.0_NVME.zip

https://www.broadcom.com/support/download-search?pg=Storage+Adapters,+Controllers,+and+ICs&pf=Host+Bus+Adapters&pn=&pa=Driver&po=&dk=&pl=&l=true

It works flawlessly in ApolloLake, Broadwell, Broadwellnk, and Denverton, which were originally running.

There have been 5 version upgrades so far, but there don't seem to be many changes.

https://github.com/PeterSuh-Q3/arpl-modules/releases/tag/v1.60

Edited September 23, 2023 by Peter Suh

Netizen1 · September 25, 2023

Greetings, a returning user here. First off congrats on the work with TCRP, secondly, I hope I'm not posting in the wrong place 😅.

As a small project, I've been trying to put together the following using the latest TCRP loader (0.9.4.9)

Gigabyte GA-F2A68HM-H
AMD A6-7400K
8GB DDR3 memory
160GB disk for initial testing

After a couple of days scouring the forum and watching the process get streamlined, I've gotten to the point where I got ds920p-7.0.1-42218 loaded using ARPL, and ds920p-7.1.1-42962 using TCRP (not with M Shell). However, when I tried to update the DSM to update 6, I ended up in a recovery loop. Long story short, I've started over quite a few times and still can't seem to get TCRP to install a stable loader.

The last attempt, using the latest HTML feature added by pocopico, gave me the following error when I chose the USB boot.

Loading Linux:
error: kernel doesn't support EFI handover.

Note that I had to use "staticboot": "true" or else TCRP Friend freezes.

Any guidance would be appreciated.

Netizen1 · September 25, 2023

11 hours ago, Netizen1 said:
Greetings, a returning user here. First off congrats on the work with TCRP, secondly, I hope I'm not posting in the wrong place 😅.

As a small project, I've been trying to put together the following using the latest TCRP loader (0.9.4.9)

Gigabyte GA-F2A68HM-H

AMD A6-7400K

8GB DDR3 memory

160GB disk for initial testing

After a couple of days scouring the forum and watching the process get streamlined, I've gotten to the point where I got ds920p-7.0.1-42218 loaded using ARPL, and ds920p-7.1.1-42962 using TCRP (not with M Shell). However, when I tried to update the DSM to update 6, I ended up in a recovery loop. Long story short, I've started over quite a few times and still can't seem to get TCRP to install a stable loader.

The last attempt, using the latest HTML feature added by pocopico, gave me the following error when I chose the USB boot.
Loading Linux:
error: kernel doesn't support EFI handover.
Note that I had to use "staticboot": "true" or else TCRP Friend freezes.

Any guidance would be appreciated.

Update:
I went ahead and tried a couple of different models today, like the DS1029+, and DS918+, and I got the same error mentioned in my earlier post.

Makes me wonder how I managed to get the ds920p-7.0.1-42218 loaded in an earlier build, as well as with ARPL 🤔

Netizen1 · September 27, 2023

One more update from me. I retried the build with TCRP and ds920p-7.1.1-42962, and it works now. 🤯

Not sure what the problem with 42218 was, but at this point I don't care...

Just waiting for the repo to have 7.2.x support for r8168/r8169 before I attempt another upgrade.

Thanks for the help!

Edited September 27, 2023 by Netizen1

Peter Suh · September 27, 2023

4 hours ago, Netizen1 said:

One more update from me. I retried the build with TCRP and ds920p-7.1.1-42962, and it works now. 🤯

Not sure what the problem with 42218 was, but at this point I don't care...

Just waiting for the repo to have 7.2.x support for r8168/r8169 before I attempt another upgrade.

Thanks for the help!

Older AMD CPUs are not supported by ARPL's default GNU kernel and TCRP FRIEND (also the GNU kernel).
So, ARPL supports an option called Direct Boot.
In the case of TCRP, it is called Jot.

Pocopico's TCRP already exists alongside the FRIEND boot menu.
However, every time a SmallUpdate such as U1~ occurs, you must manually PostUpdate.
In the case of Mshell (TCRP), postupdate in Jot has been improved to be slightly more convenient.
ARPL will probably work better with direct boot and ramdisk patch without postupdate.

Try this method.

wirdo · September 27, 2023

Hi Peter,

I'm trying to switch over to your version of the loader (currently using arpl) but I cannot get it to boot after building the loader.

The reason for the switch is because I want to give 7.2 a shot. I've tried both 7.2 loaders and both give me the same outcome.

Using 918+ with real mac.

Thanks for all your efforts!

Edited September 27, 2023 by wirdo

Netizen1 · September 27, 2023

10 hours ago, Peter Suh said:

Older AMD CPUs are not supported by ARPL's default GNU kernel and TCRP FRIEND (also the GNU kernel).
So, ARPL supports an option called Direct Boot.
In the case of TCRP, it is called Jot.

Pocopico's TCRP already exists alongside the FRIEND boot menu.
However, every time a SmallUpdate such as U1~ occurs, you must manually PostUpdate.
In the case of Mshell (TCRP), postupdate in Jot has been improved to be slightly more convenient.
ARPL will probably work better with direct boot and ramdisk patch without postupdate.

Try this method.

I found the Direct Boot setting in ARPL while doing my research this weekend. I finally saw that pocopico exposed that setting in their HTML builder, and was able to get around some of my earlier issues. However, it appears that most of my problems were with TCRP's deployment of 42218 on my hardware.

When trying out Mshell, I expressly recall that I couldn't use JOT and 42218. When I tried to use 42218, it stayed as Friend, while the 7.1 and 7.2 showed JOT. There was also an issue during the loader build where I was running out of space on sdb3 and after so many days of trying to get it to work, I reverted to the TCRP to test the HTML builder, and that's what ended up working for me.

For now, it appears to be working with 42962 Update 6. Also, TCRP Friend worked as it should after I applied the patch to my install.

I honestly don't remember why I was so insistent on loading 42218 😅

TinyCore RedPill Loader (TCRP)

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation