TinyCore RedPill loader (TCRP) - Development release 0.9

[Peter Suh]

7 minutes ago, djvas335 said:

I attach screens from dmesg on my two systems, one with the original DSM driver and one with loader driver,please note the driver version

 

Could you please confirm with the command below?

ll /lib/modules | grep mlx4
lsmod | grep mlx4

uname -a

Edited May 31, 2023 by Peter Suh

[djvas335]

23 minutes ago, Peter Suh said:

uname -a

This is from a working system using the original driver from dsm3622xs built by disabling the card and reenabling it after the build, I am rebuilding the broken system and will send screen soon

[djvas335]

This is from the recently build system which does not work properly, it starts and works if I disable a card, however as soon as reenable the card, the system starts and when I go to the webinterface, the system immediately shuts down

 

 

[Peter Suh]

19 minutes ago, djvas335 said:

This is from the recently build system which does not work properly, it starts and works if I disable a card, however as soon as reenable the card, the system starts and when I go to the webinterface, the system immediately shuts down

 

 

 

What is your loader build command?
Did you build the latest version of pocopico's TCRP using the command method?
Or did you use the WEB UI builder?

[djvas335]

And this is the screen with the card enabled but before going to the webinterface that shuts down the system

[djvas335]

2 minutes ago, Peter Suh said:

 

What is your loader build command?
Did you build the latest version of pocopico's TCRP using the command method?
Or did you use the WEB UI builder?

I use cli, my loader commands are

 

./rploader.sh update now

./rploader.sh fullupgrade now

./rploader.sh serialgen DS3622xs+

./rploader.sh identifyusb now

./rploader.sh satamap now

./rploader.sh build ds3622xsp-7.2.0-64561

[Peter Suh]

18 minutes ago, djvas335 said:

I use cli, my loader commands are

 

./rploader.sh update now

./rploader.sh fullupgrade now

./rploader.sh serialgen DS3622xs+

./rploader.sh identifyusb now

./rploader.sh satamap now

./rploader.sh build ds3622xsp-7.2.0-64561

 

Recently, pocopico's TCRP started to use an integrated module pack such as ARPL and EUDEV method from 7.2.

https://github.com/pocopico/tinycore-redpill/blob/main/custom_config2.json#L1841

DSM 7.1 discussed the module dependencies of shibby and mlx4, but this issue seems to be recurring in DSM 7.2.
The core of the post content at the time was that in the case of the EUDEV method, the module dependency of mlx4 could not sequentially load the modules related to mlx4 in order.

Pocopico's 7.1 excludes EUDEV in the old fashioned way.
This old method is called DDSML in M SHELL.

My M SHELL optionally uses DDSML and EUDEV.
DDSML uses modprobe considering module dependencies.
Even if insmod is used, it is okay to load modules sequentially according to their dependency order. (Pocopico method)

Please switch to my M SHELL with the command below and build DS3622xs+ 7.2 with DDSML method.

curl -kLO https://raw.githubusercontent.com/PeterSuh-Q3/tinycore-redpill/master/my.sh.gz; tar -zxvf my.sh.gz ; ./rploader.sh backup; sudo reboot

Additional installation of the M SHELL loader in TCRP may require several reboots.

[djvas335]

Please note that DS3622xs+ already contains an mlx4 driver so if the problematic driver is removed from the integrated module pack it should fix the current issue, I built the loader before the integrated module pack and I had no issues such as this, by just disabling the card and reenabling it after the compilation process. Please note that if I left the card enabled, the outcome was as is now, a non working system. Also please note that the driver contained in the DS3622xs+ is more recent.

[Peter Suh]

17 minutes ago, djvas335 said:

Please note that DS3622xs+ already contains an mlx4 driver so if the problematic driver is removed from the integrated module pack it should fix the current issue, I built the loader before the integrated module pack and I had no issues such as this, by just disabling the card and reenabling it after the compilation process. Please note that if I left the card enabled, the outcome was as is now, a non working system. Also please note that the driver contained in the DS3622xs+ is more recent.

 

As you have confirmed, the modules in DSM's /lib/modules are not modules created in XPE.

The XPE module is only used in the installation phase for the Junior phase where DSM needs to be installed and helps the installation of DSM.
It is used only in the Junior phase and disappears.

However, the XPE module used in the DSM installation step affects the normal operation of the vanilla driver used after DSM installation.

Pocopico's XPE modules and
Compare the ko file in /lib/modules of your verified DSM.
https://github.com/pocopico/redpill-modules/tree/master/broadwellnk-4.4.302

The vanilla module you want to have already exists in DSM.
However, it seems that module loading has failed.

[djvas335]

Please note the differences in driver version of original dsm and the one installed by the loader on these two screens, the 2017 one is dsm original and the 2014 one is the one installed by the loader, 

 

[Peter Suh]

1 hour ago, djvas335 said:

Please note the differences in driver version of original dsm and the one installed by the loader on these two screens, the 2017 one is dsm original and the 2014 one is the one installed by the loader, 

 

 

The important thing is that the time when the driver was created is not a problem,
There seems to be a problem with kernel version compatibility with mlx4_en.ko for DSM7.2 made by pocopico.
7.2 uses kernel version 4.4.302+
7.1 uses kernel version 4.4.180+.
If mlx4_en.ko for 7.2 is not compatible with the kernel version, an Unknown symbol message appears as above.
Looks like @pocopico should confirm.

Edited May 31, 2023 by Peter Suh

[djvas335]

Please note that it was always like this, the driver integrated in loader did not work thus while compiling I had to disable the card for the loader to not detect it and not add the said problematic driver.

[Peter Suh]

1 hour ago, Peter Suh said:

 

The important thing is that the time when the driver was created is not a problem,
There seems to be a problem with kernel version compatibility with mlx4_en.ko for DSM7.2 made by pocopico.
7.2 uses kernel version 4.4.302+
7.1 uses kernel version 4.4.180+.
If mlx4_en.ko for 7.2 is not compatible with the kernel version, an Unknown symbol message appears as above.
Looks like @pocopico should confirm.

 

One peculiarity is

In the case of Broadwell nk such as DS3622xs+, there is no dependency definition with mlx4_core.ko and mlx4_en.ko.
Only mlx4_core.ko is declared.

https://github.com/pocopico/rp-ext/blob/main/mlx4_core/releases/ds3622xsp_42218.json

   "kmods": {
     "mlx4_core.ko": ""
   },

In the case of DS920+, dependencies that were an issue with shibby last time are defined.

https://github.com/pocopico/rp-ext/blob/main/mlx4_core/releases/ds920p_42218.json

   "kmods": {
     "mlx4_core.ko": "",
     "mlx4_en.ko": ""
   },

In the case of DS3622xs+, I wonder if mlx4_en.ko is absolutely necessary.
It only causes unnecessary conflicts. Can I delete this module?

 

This description is only used in 7.1.

 

 

 

Edited May 31, 2023 by Peter Suh

[Peter Suh]

2 minutes ago, djvas335 said:

Please note that it was always like this, the driver integrated in loader did not work thus while compiling I had to disable the card for the loader to not detect it and not add the said problematic driver.

 

As mentioned above, it was possible in 7.1
7.2 is impossible because it is an integrated module method.

[Peter Suh]

9 minutes ago, djvas335 said:

Please note that it was always like this, the driver integrated in loader did not work thus while compiling I had to disable the card for the loader to not detect it and not add the said problematic driver.

 

If I delete the mlx4 module and redeploy it as you wish, are you willing to test it with M Shell?

[djvas335]

57 minutes ago, Peter Suh said:

 

If I delete the mlx4 module and redeploy it as you wish, are you willing to test it with M Shell?

Yes I can test no problem, can we please also do the test with the driver removed ?

[Peter Suh]

1 hour ago, djvas335 said:

Yes I can test no problem, can we please also do the test with the driver removed ?

 

First, we removed mlx4_en.ko, which is a problem with the first test.

Distribution of the removed integration module pack is complete.

 

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

 

Build DS3622xs+ 7.2-64561 from the M SHELL menu.
M SHELL does not recommend the command method.
Your menu interface should look like below.

 

In the menu, if EUDEV is selected first, switch to DDSML.
If you use it in your already built TCRP, user_config.json is referenced as it is.
There is nothing to modify on the menu, just proceed with the DS3622xs+ 7.2-64561 build.

If the problem persists in this process, we will prepare for the second test by removing mlx4_core.ko.
Instead, a separate NIC is required.

[djvas335]

I am having diffculty compiling the loader using mshell, I am getting this error

 

Mounting /dev/sdb1 to localdiskp1

/dev/sdb2 localdiskp2

cp: error writing 'localdiskp1/zImage': No space left on device

Modify Jot Menu entry

 

I also see that my partition table is different than yours, my sdx1 is smaller than yours, I am using latest tcrp image version tinycore-redpill-uefi.v0.9.4.6.img, can you maybe point to an image with correct partition layout please ?

 

 

Edited May 31, 2023 by djvas335

[pocopico]

15 minutes ago, djvas335 said:

I am having diffculty compiling the loader using mshell, I am getting this error

 

Mounting /dev/sdb1 to localdiskp1

/dev/sdb2 localdiskp2

cp: error writing 'localdiskp1/zImage': No space left on device

Modify Jot Menu entry

 

I also see that my partition table is different than yours, my sdx1 is smaller than yours, I am using latest tcrp image version tinycore-redpill-uefi.v0.9.4.6.img, can you maybe point to an image with correct partition layout please ?

 

 

 

 

Download latest release and use the TCRP Web builder 

 

[djvas335]

8 minutes ago, pocopico said:

 

 

Download latest release and use the TCRP Web builder 

 

I need to use mshell we are trying to diagnose an issue with the mlx4 driver

[PincoPalla]

3 hours ago, pocopico said:

TCRP Web builder 

Hi all, sorry I can't figure out how to view TCRP in web mode, I'm missing something, with ARPL it's clear to me (it gives me the IP+port number) but with TCRP with shell I can't do it, I tried to do a search in the threads but I'm probably wrong to ask the question because I can't find anything, can someone help me?? it's not important because you can do the same but it was just to learn. Thank you

[djvas335]

7 hours ago, Peter Suh said:

 

First, we removed mlx4_en.ko, which is a problem with the first test.

Distribution of the removed integration module pack is complete.

 

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

 

Build DS3622xs+ 7.2-64561 from the M SHELL menu.
M SHELL does not recommend the command method.
Your menu interface should look like below.

 

In the menu, if EUDEV is selected first, switch to DDSML.
If you use it in your already built TCRP, user_config.json is referenced as it is.
There is nothing to modify on the menu, just proceed with the DS3622xs+ 7.2-64561 build.

If the problem persists in this process, we will prepare for the second test by removing mlx4_core.ko.
Instead, a separate NIC is required.

I have managed to build a loader using M Shell, same issue please see below screens

 

[Peter Suh]

1 hour ago, djvas335 said:

I have managed to build a loader using M Shell, same issue please see below screens

 

 

 

That's too bad.
Then it's time to remove all-modules pack and test with only the vanilla modules you want.
But there are many things to prepare.

I will explain in advance because it would be good to increase your understanding of the vanilla driver (module) and proceed with this task.
I heard @wjz304's opinion about using the vanilla module alone, but the lack of compatibility makes it less likely that many devices will be supported.
This part is helped by the modified XPE module.

https://xpenology.com/forum/topic/56872-develop-and-refine-the-ds3622xs-loader/?do=findComment&comment=444930

First, I completely removed all-modules, an integrated module pack of TCRP, and applied it to my DELL T1700 with only vanilla modules.

Fortunately, in my case, the built-in e1000e and the separate e1000e are dually installed, and both work within the vanilla module.

I don't have a Mellanox nic, but I have it in place to verify vanilla status.

It looks like you already have another nic installed besides the mlx4, don't you?
Let's check in advance which nic is prepared with which PID/VID with the command below.
Please let me know the result.

lspci -vnn | grep 0200]
lspci -v | grep Kernel

Edited May 31, 2023 by Peter Suh

[djvas335]

3 hours ago, Peter Suh said:

 

 

That's too bad.
Then it's time to remove all-modules pack and test with only the vanilla modules you want.
But there are many things to prepare.

I will explain in advance because it would be good to increase your understanding of the vanilla driver (module) and proceed with this task.
I heard @wjz304's opinion about using the vanilla module alone, but the lack of compatibility makes it less likely that many devices will be supported.
This part is helped by the modified XPE module.

https://xpenology.com/forum/topic/56872-develop-and-refine-the-ds3622xs-loader/?do=findComment&comment=444930

First, I completely removed all-modules, an integrated module pack of TCRP, and applied it to my DELL T1700 with only vanilla modules.

Fortunately, in my case, the built-in e1000e and the separate e1000e are dually installed, and both work within the vanilla module.

I don't have a Mellanox nic, but I have it in place to verify vanilla status.

It looks like you already have another nic installed besides the mlx4, don't you?
Let's check in advance which nic is prepared with which PID/VID with the command below.
Please let me know the result.

lspci -vnn | grep 0200]
lspci -v | grep Kernel

Yes I have igb, please see below screen

 

 

 

 

[Peter Suh]

21 minutes ago, djvas335 said:

Yes I have igb, please see below screen

 

 

 

 

 

 

Since igb already has vanilla modules, it seems to work without installing all-modules like my T1700.

 

As in the caption below
Comment out LINE 293 of my.sh with #.
Delete LINE 2490 in custom_config.json.
Can this be done with the vi editor?

 

Modification to persist modified custom_config.json .

 

 

 

Once you have finished editing, build DS3622xs+ 7.2 again from the menu.

 

Determination of whether the all-modules integration pack has been correctly removed is successful if only misc and nvme-cache are mentioned in the Removing model exts directories at the end of the loader's build log as shown below and all-modules are not present.
There is nothing to delete because it has never been added.