RedPill - the new loader for 6.2.4 - Discussion


Recommended Posts

4 minutes ago, pocopico said:

 

I know what you mean, problem is that mpt3sas module will name the devices in a way it cannot be interpreted correctly by DSM. Also not all synology models support SAS by default so here we are waiting for the RedPill magic

I think many people are using the HBA sas to SATA control card. Even if it cannot be used directly, the data can be read out through manual mounting, which is acceptable in a short time. The next step is to wait quietly for redpill magic.

I think I'm close to the truth that I can use it, but I still lack raid_class.ko, as shown in this picture. Thanks again. 😊

image.thumb.png.4a980e9d5ef5c5ce07eef2e3e0754870.png

 

3 minutes ago, Orphée said:

I know and I totally agree with you :)

Yes, I'm using this cable.

Link to post
Share on other sites
3 minutes ago, flybird08 said:

I think many people are using the HBA sas to SATA control card. Even if it cannot be used directly, the data can be read out through manual mounting, which is acceptable in a short time. The next step is to wait quietly for redpill magic.

I think I'm close to the truth that I can use it, but I still lack raid_class.ko, as shown in this picture. Thanks again. 😊

image.thumb.png.4a980e9d5ef5c5ce07eef2e3e0754870.png

 

Yes, I'm using this cable.

 

I think, raid_class and libsas, scsi_transport_sas are included in the DSM kernel.

Edited by pocopico
Link to post
Share on other sites
6 minutes ago, pocopico said:

 

I think, raid_class and libsas are included in the DSM kernel.

Bad news, neither seems to be included in the DS918+.

 

Quote

root@DS918:/# ls /lib/modules/r*
/lib/modules/r8168.ko  /lib/modules/raid0.ko  /lib/modules/raid10.ko  /lib/modules/raid456.ko  /lib/modules/raid6_pq.ko  /lib/modules/rodsp_ep.ko  /lib/modules/rpcsec_gss_krb5.ko
root@DS918:/# ls /lib/modules/lib*
/lib/modules/libiscsi.ko  /lib/modules/libiscsi_tcp.ko
 

 

Link to post
Share on other sites
9 hours ago, Orphée said:

You have to manually edit your global conf file.

Jumkey's repository is not part of official redpill_tool_chain release.

 

Here is mine (zoom on bromolow conf only)

 


        {
            "id": "bromolow-7.0.1-42218",
            "platform_version": "bromolow-7.0.1-42218",
            "user_config_json": "bromolow_user_config.json",
            "docker_base_image": "debian:8-slim",
            "compile_with": "toolkit_dev",
            "redpill_lkm_make_target": "dev-v7",
            "downloads": {
                "kernel": {
                    "url": "https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/25426branch/bromolow-source/linux-3.10.x.txz/download",
                    "sha256": "18aecead760526d652a731121d5b8eae5d6e45087efede0da057413af0b489ed"
                },
                "toolkit_dev": {
                    "url": "https://sourceforge.net/projects/dsgpl/files/toolkit/DSM7.0/ds.bromolow-7.0.dev.txz/download",
                    "sha256": "a5fbc3019ae8787988c2e64191549bfc665a5a9a4cdddb5ee44c10a48ff96cdd"
                }
            },
            "redpill_lkm": {
                "source_url": "https://github.com/RedPill-TTG/redpill-lkm.git",
                "branch": "master"
            },
            "redpill_load": {
                "source_url": "https://github.com/jumkey/redpill-load.git",
                "branch": "develop"
            }
        },

 

@Amoureux develop branch

 

can share the apollo conf file content for 7.0.1-42218? thank you

Link to post
Share on other sites

I changed 3615 to 918 at night. There is no problem of automatic restart at present.
However, although I can log in to synology account, as long as I set quickconnect, I will be forced to exit the account. I don't know whether it's synology's problem or a system bug.
Being able to log in to the account should mean the calculated Sn and MAC, right?

(My 3615 didn't have this problem before)

Link to post
Share on other sites
2 minutes ago, Null said:

I changed 3615 to 918 at night. There is no problem of automatic restart at present.
However, although I can log in to synology account, as long as I set quickconnect, I will be forced to exit the account. I don't know whether it's synology's problem or a system bug.
Being able to log in to the account should mean the calculated Sn and MAC, right?

(My 3615 didn't have this problem before)

You changed SN and MAC from real DS3615xs to real DS918+, did you ?

Link to post
Share on other sites
Just now, Orphée said:

您将 SN 和 MAC 从真正的 DS3615xs 更改为真正的 DS918+,是吗?

Yes, I think it is
(I calculated the Sn and MAC code of 918, so I'm not sure it must be right. Does being able to log in to an account mean it's right?)

Link to post
Share on other sites
16 minutes ago, svenger87 said:

I´m struggling with installing the PAT file. The Webassistant shows the PAT is corrupted.
System is a Intel NUC RTL 8111H card. Any hints whats wrong?

 

Edit: Ah. I think i need to edit the SATA params in the grub.cfg.

image.thumb.png.4d51abb050395eea66c91f055ef841e8.png

Okay. It's the missing synoboot issue some members had earlier before. 

Link to post
Share on other sites
3 minutes ago, Null said:

Yes, I think it is
(I calculated the Sn and MAC code of 918, so I'm not sure it must be right. Does being able to log in to an account mean it's right?)

I'm not talking about calculated SN an MAC.

In order to use synology services you must have real genuine SN and MAC from a real DS918+ (or DS3615xs etc...)

But still, using these services with Xpenology is strongly discouraged.

  • Like 1
Link to post
Share on other sites
1 minute ago, Orphée said:

我不是在谈论计算的 SN 和 MAC。

要使用 Synology 服务,您必须拥有来自真正DS918+(或 DS3615xs 等...)的 真正正版SN 和 MAC

但是,强烈建议不要将这些服务与 Xpenology 一起使用。

ok,i will do it tomorrow ,thanks

Link to post
Share on other sites

Well done @ThorGroup!

Once again a marvelous update that brings a lot of excitement to all of us :)

 

I did check the toolchain builder builds for the 6.2.4 and 7.0 configurations that are supported out of the box (=configurations from TTG's redpill-load repository).

All of them use the new plugin manager and build like a charm. Though I haven't checked the generated image yet.

 

I noticed the cached pat files fpr apollolake are re-downloading from redpill-load's build-loader.sh, but this time the `+` character is replaced with a `p` character in the output filename. Thus `ds918+_25556.pat` became `ds918p_25556.pat`. Who ever is affected can simply replace the + in the filenames with a p and prevent the files from beeing re-downloaded again.

 

Additionaly I tested jumkey's apollolake-7.0.1-42218, which is not yet alligned with the recent changes in redpill-load. 

 

1 hour ago, ThorGroup said:

We also left a separate env variable called MRP_SRC_NAME which is used instead of "./ext-manager.sh" when displaying any help/error messages in the extension manager. You may want to replace it with docker command so users aren't confused.

I must admit, this one went over my head :) I was going to check how `build-loader.sh` calls `ext-manager.sh` and then simply add an array to declare plugins in the toolchain builders global_config.json and execute the command for each element before executing the loader build.

 

Update: the ext-manager.sh syntax is straight forward, no need to check how build-loader.sh uses it. Though, I have to find a clever way to pass in an array, even though docker doesn't support to use arrays as environment variables.

 

Edited by haydibe
Link to post
Share on other sites
1 hour ago, haydibe said:

Update: the ext-manager.sh syntax is straight forward, no need to check how build-loader.sh uses it. Though, I have to find a clever way to pass in an array, even though docker doesn't support to use arrays as environment variables.

I think I found a clever way. I added "extensions": to each platform version with "id": and "url": fields, and pass in the whole extensions array as a single string and process it inside the container. Now I need some extensions to take this addition to a test drive.

 

I also added support for a custom_config.json that allows to merge its values with the global_config.json. This would allow to keep individual platform version configurations in your own config file, which won't be replaced by a new release of the toolchain loader. 

 

  • Like 2
  • Thanks 2
Link to post
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.