TinyCore RedPill Loader (TCRP)

[Dvalin21]

@pocopico Just reporting, SA6400, FA6400, DVA1622, DS923+,  doesn't auto pull extensions on all the 7.2.0 builds. Also they all give the "unable to detect if encrypted". With that said, thank you for all the work with all of this. Its been a joy tinkering and testing with your software. It is most appreciated. 

[Al lex]

1 hour ago, foxbat said:

what it's the version of your DSM now please? thx

the same DSM 7.2-64570, with no mentions of update 1

[gericb]

Same here.  In the Update/Restore it wasn't showing U1.  Just updated mine manually DSM 7.2-64570 with the stand-alone 7.2-64570-U1 , no issues on my 920+, using TCRP M-Shell w/Friend current version.  The update isn't really relevant to my setup, but what the heck. 🤠

 

Version: 7.2-64570 Update 1 (2023-06-19)

 

Important notes:

Your Synology NAS may not notify you of this DSM update because of the following reasons. If you want to update your DSM to this version now, please click here to update it manually.

 

Your DSM is working fine without having to update. The system evaluates service statuses and system settings to determine whether it needs to update to this version.

Depending on your Synology NAS model, this update will restart the device.

 

Fixed Issues:

Fixed an issue where Btrfs volumes might not be able to run volume optimization successfully.

Fixed an issue where drive replacement might not work properly for SHR storage pools.

[Dvalin21]

Delete

Edited June 21, 2023 by Dvalin21

[crurer]

Hi,

 

I'll report a BUG in rev. 0.9.4.9b when using tinycore-redpill-uefi.v0.9.4.9.img with DSM 7.1.1-42962 Update 1 running as DS3615xs. Same behaiving when I've tried another model i.e. 3622xs+.

 

I'm using a FSC D3222-B1x Mainboard with I5-4460 + 16GB RAM. 8x 4TB WD red + LSI 9211-4i IT mode. As soon I connect a Mellanox ConnectX-3 10GB FC to one of the PCIe slots the system is shutting down (no reboot) when the system load seems finished to access the webui.

I can confirm with older rev. i.e. 0.9.3.x the system is running fine as expected. It really costs me some time to analyze the issue.

 

cheers Chris

[djvas335]

This is because of new all-modules integration where the problematic mlx4 driver is now bundled, I had to build my own all-modules to overcome this issue for my systems, I run connect-x3 40gb

 

 

3 hours ago, crurer said:

Hi,

 

I'll report a BUG in rev. 0.9.4.9b when using tinycore-redpill-uefi.v0.9.4.9.img with DSM 7.1.1-42962 Update 1 running as DS3615xs. Same behaiving when I've tried another model i.e. 3622xs+.

 

I'm using a FSC D3222-B1x Mainboard with I5-4460 + 16GB RAM. 8x 4TB WD red + LSI 9211-4i IT mode. As soon I connect a Mellanox ConnectX-3 10GB FC to one of the PCIe slots the system is shutting down (no reboot) when the system load seems finished to access the webui.

I can confirm with older rev. i.e. 0.9.3.x the system is running fine as expected. It really costs me some time to analyze the issue.

 

cheers Chris

 

[Dvalin21]

Was able to install 923+ 7.2. The only thing I see is that when selecting to add extra extensions like cpuinfo, did doesn't even show that it was pulled, although it shows up in the added extensions list. Thanks.

[The_Dave]

I get this error message while building the loader both with 918+ and 920+. I use the latest image. I don't think I did something wrong, because it worked before with exactly the same commands. I try to build with ./rploader.sh build ds918p-7.2.0-64570 or ./rploader.sh build ds920p-7.2.0-64570

 

 

 

 

Any idea how I can get the building done successfully?

Edited June 23, 2023 by The_Dave

[Peter Suh]

7 hours ago, The_Dave said:

I get this error message while building the loader both with 918+ and 920+. I use the latest image. I don't think I did something wrong, because it worked before with exactly the same commands. I try to build with ./rploader.sh build ds918p-7.2.0-64570 or ./rploader.sh build ds920p-7.2.0-64570

 

 

 

 

Any idea how I can get the building done successfully?

 

 

From DSM 7.2, use WEBUI as below.
http://YourTCRPIPAddr:80

 

And, please process the update to the latest version first.
"Additional Actions" -> "Full Upgrade Loader"

 

There is no problem with the WEBUI-type loader build,
Starting from 7.2, command-based builds may have problems.

 

The reason is that from 7.2, pocopico uses ARPL or TCRP M SHELL's integrated module pack method.
This integrated module pack is designed to work only with WEBUI.

[pcristi]

@The_Dave

With v0.9.4.9 try
./rploader.sh clean now
./rploader.sh build ds920p-7.2.0-64570 manual
./rploader.sh backup now
sudo reboot

If box running 7.1.1-49262 build corresponding loader
./rploader.sh clean now
./rploader.sh build ds920p-7.1.1-42962 manual
./rploader.sh backup now
sudo reboot

TCRP v0.9.4.9 with TCRP Friend v0.0.5j is support fly update from 7.1.1-49262 to 7.2.0-64570 if not custom module use.

LE: If need can add acpid addons 
./rploader.sh ext ds920p-7.2.0-64570 add https://github.com/pocopico/tcrp-addons/raw/main/acpid/rpext-index.json

Edited June 24, 2023 by pcristi

[Peter Suh]

13 hours ago, pcristi said:

@The_Dave

With v0.9.4.9 try
./rploader.sh clean now
./rploader.sh build ds920p-7.2.0-64570 manual
./rploader.sh backup now
sudo reboot

If box running 7.1.1-49262 build corresponding loader
./rploader.sh clean now
./rploader.sh build ds920p-7.1.1-42962 manual
./rploader.sh backup now
sudo reboot

TCRP v0.9.4.9 with TCRP Friend v0.0.5j is support fly update from 7.1.1-49262 to 7.2.0-64570 if not custom module use.

LE: If need can add acpid addons 
./rploader.sh ext ds920p-7.2.0-64570 add https://github.com/pocopico/tcrp-addons/raw/main/acpid/rpext-index.json

 

 

There are reasons we don't encourage command-style builds.

 

In your case you don't have an r8168 nic so the command build would have been fine.

 

Pocopico probably no longer uses the old way of managing checksums for each module.

 

That's why we encourage WEBUI.

[The_Dave]

Thank you for your help @Peter Suh @pcristi. It worked with the webui.

[pcristi]

@Peter Suh

 

r8168 is included in all-modules, not need not be added by automatic detection from rploader.sh, for avoid error and to get possibility to update on fly from 7.1.1 to 7.2.0 I recommended to use build rploader.sh with manual option.

WEBUI is working in progress, waiting for @pocopico to have time review satamap function to fix always report 8 port and to add multiple mac address support.
WEBUI working fine if user have a backup of user_config.json to restore or know to manage it from ssh.
WEBUI builds also allow to do fly update from 7.1.1 to 7.2.0 if not additional custom module is added 😀.

Thanks to everyone that make possible to use TCRP Friend.

[Peter Suh]

7 minutes ago, pcristi said:

@Peter Suh

 

r8168 is included in all-modules, not need not be added by automatic detection from rploader.sh, for avoid error and to get possibility to update on fly from 7.1.1 to 7.2.0 I recommended to use build rploader.sh with manual option.

WEBUI is working in progress, waiting for @pocopico to have time review satamap function to fix always report 8 port and to add multiple mac address support.
WEBUI working fine if user have a backup of user_config.json to restore or know to manage it from ssh.
WEBUI builds also allow to do fly update from 7.1.1 to 7.2.0 if not additional custom module is added 😀.

Thanks to everyone that make possible to use TCRP Friend.

 

you're right. If r8168 causes checksum problems, you can use the manual build option to prevent auto-detection.
This module may work well with a vanilla module that is already built into DSM.
In recent ARPL, @wjz304 has put a lot of effort into stabilizing r8168.
I think I need to discuss with wjz304 why there is some reason not to use only the vanilla module.

[djvas335]

Please can something be done with modules which crash system on startup when affected hardware is present ? The all-modules is creating issues each time the loader is recreated, is there an option to remove drivers which cause problems from it ? For me I need to remove the mlx4 driver as it crashes my system on startup. Any suggestions for this ?

[wjz304]

1 hour ago, djvas335 said:

Please can something be done with modules which crash system on startup when affected hardware is present ? The all-modules is creating issues each time the loader is recreated, is there an option to remove drivers which cause problems from it ? For me I need to remove the mlx4 driver as it crashes my system on startup. Any suggestions for this ?

At present, it should not be possible to achieve this,

But seeing your question, I came up with an idea to include masked parameters in cmdline,

[Peter Suh]

11 hours ago, djvas335 said:

Please can something be done with modules which crash system on startup when affected hardware is present ? The all-modules is creating issues each time the loader is recreated, is there an option to remove drivers which cause problems from it ? For me I need to remove the mlx4 driver as it crashes my system on startup. Any suggestions for this ?

 

Currently, this mlx4 has been removed from the DDSML method of MSHELL for TCRP.
In this removed state, the built-in modules (vanilla modules) already included in DSM are used instead.It has already been reflected in M SHELL by your

 

request a while ago, What other problems are there?

I didn't have your last feedback, so I asked another user with the same nic to test it. There was nothing wrong with his feedback.

 

In addition, if the user wants to exclude modules with additional issues,

I am considering using modprobe.blacklist in MSHELL's DDSML method using modprobe.

 

Edited June 26, 2023 by Peter Suh

[pocopico]

9 hours ago, Peter Suh said:

 

Currently, this mlx4 has been removed from the DDSML method of MSHELL for TCRP.
In this removed state, the built-in modules (vanilla modules) already included in DSM are used instead.It has already been reflected in M SHELL by your

 

request a while ago, What other problems are there?

I didn't have your last feedback, so I asked another user with the same nic to test it. There was nothing wrong with his feedback.

 

In addition, if the user wants to exclude modules with additional issues,

I am considering using modprobe.blacklist in MSHELL's DDSML method using modprobe.

 

 

Since we are using gnu tar to extract the modules at boot or at loader creation the exclusion of some modules is not a very difficult task.

 

If you want to specify a module to be excluded from DSM you can add modprobe.blacklist=mlx4 at your linux command line. 

 

I will include that in the next release of the HTML Builder.

 

How we identify the module that actually cause KPs is the most difficult part cause you have to read the KP message.

 

 

Edited June 26, 2023 by pocopico

[djvas335]

Actually I did give feedback that modules worked but there was some log noise before driver load if you remember we had a conversation on that, I now built the new loader using HTML builder and had issues again with the mlx4 driver thus my forum message, I overcame this for now by removing the mlx4 driver from the tgz and copying the rebuilt tgz via scp to its final location after the loader is built and rebuilding the loader again.

 

 

13 hours ago, Peter Suh said:

 

Currently, this mlx4 has been removed from the DDSML method of MSHELL for TCRP.
In this removed state, the built-in modules (vanilla modules) already included in DSM are used instead.It has already been reflected in M SHELL by your

 

request a while ago, What other problems are there?

I didn't have your last feedback, so I asked another user with the same nic to test it. There was nothing wrong with his feedback.

 

In addition, if the user wants to exclude modules with additional issues,

I am considering using modprobe.blacklist in MSHELL's DDSML method using modprobe.

 

 

[djvas335]

But I do not want to exclude the module mlx4 from loading in DSM, I want that the mlx4 module included in all-modules in the loader do not load so that the module included in DSM loads, the mlx4 included in the all-modules does not work and crashes my system when I access after the system started up. So what I want is for the vanilla mlx4 driver in DSM take over from the mlx4 included in the all-modules pack.

 

7 hours ago, pocopico said:

 

Since we are using gnu tar to extract the modules at boot or at loader creation the exclusion of some modules is not a very difficult task.

 

If you want to specify a module to be excluded from DSM you can add modprobe.blacklist=mlx4 at your linux command line. 

 

I will include that in the next release of the HTML Builder.

 

How we identify the module that actually cause KPs is the most difficult part cause you have to read the KP message.

 

 

 

[pocopico]

3 minutes ago, djvas335 said:

But I do not want to exclude the module mlx4 from loading in DSM, I want that the mlx4 module included in all-modules in the loader do not load so that the module included in DSM loads, the mlx4 included in the all-modules does not work and crashes my system when I access after the system started up. So what I want is for the vanilla mlx4 driver in DSM take over from the mlx4 included in the all-modules pack.

 

 

 

Sure, thats also a very valid option. You can change the tgz by adding or removing modules. The initial idea that we discussed with @fbelavenuto , was to match the redpill to the Juns loader extra module pack function. 

[Peter Suh]

9 hours ago, djvas335 said:

But I do not want to exclude the module mlx4 from loading in DSM, I want that the mlx4 module included in all-modules in the loader do not load so that the module included in DSM loads, the mlx4 included in the all-modules does not work and crashes my system when I access after the system started up. So what I want is for the vanilla mlx4 driver in DSM take over from the mlx4 included in the all-modules pack.

 

 

 

The actual operation of modprobe.blacklist=mlx4, an idea suggested by @pocopico, is in the Junior stage where the arpl/tcrp integrated module pack tgz is actually used (Early) or the intermediate stage just before DSM is loaded (Passed Junior - Late). I know.

 

I know that this tgz is discarded at the loading stage of DSM and only works as a vanilla module.

 

Doesn't the tgz integration module and the vanilla module in DSM have no correlation at the time of rcExit past the Late stage, which is the loading stage of DSM?

 

@pocopico, @wjz304

I'm also asking because I can't establish the concept of this part.

Edited June 27, 2023 by Peter Suh

[pocopico]

5 hours ago, Peter Suh said:

 

The actual operation of modprobe.blacklist=mlx4, an idea suggested by @pocopico, is in the Junior stage where the arpl/tcrp integrated module pack tgz is actually used (Early) or the intermediate stage just before DSM is loaded (Passed Junior - Late). I know.

 

I know that this tgz is discarded at the loading stage of DSM and only works as a vanilla module.

 

Doesn't the tgz integration module and the vanilla module in DSM have no correlation at the time of rcExit past the Late stage, which is the loading stage of DSM?

 

@pocopico, @wjz304

I'm also asking because I can't establish the concept of this part.

 

Its true but the cmdline is persistent and DSM modprobe will continue to blacklist the module past junior. 

[Peter Suh]

41 minutes ago, pocopico said:

 

Its true but the cmdline is persistent and DSM modprobe will continue to blacklist the module past junior. 

 

Thank you for answer.
To see how far the operation of the blacklist extends, I will test it myself today by modifying the cmdline in TCRP FRIEND.

[Peter Suh]

15 hours ago, djvas335 said:

But I do not want to exclude the module mlx4 from loading in DSM, I want that the mlx4 module included in all-modules in the loader do not load so that the module included in DSM loads, the mlx4 included in the all-modules does not work and crashes my system when I access after the system started up. So what I want is for the vanilla mlx4 driver in DSM take over from the mlx4 included in the all-modules pack.

 

 

 

There is one thing different from the last test with you.
The link below is a place where vanilla modules related to mlx4 are kept.
https://github.com/PeterSuh-Q3/arpl-modules/tree/main/vanilla/broadwellnk-4.4.302

 

In addition to mlx4_en.ko and mlx4_core.ko , we have confirmed that mlx_compat.ko has additional dependencies.
Have you tried the added version as a vanilla module up to mlx_compat.ko with MSHELL?
Could you please confirm that this test also shows the logs you are concerned about?