Jump to content
XPEnology Community

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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
Share on other sites

3 hours ago, haydibe said:

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. 

 

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.

 

 

About the change with + => p is essentially keeping with the same translation layer as in the kernel so the models are named in the exact same way (and that we don't have special characters in file paths ;)).

 

As for the calling in docker we were thinking about something even simpler. Since we're playing with interactive interface it will be nice if users can just run the command in the container instead of editing a file. This is why ext-manager.sh script self-manages files based on commands. So that the author of an extension can just say "just call add [URL]" and call it a day. The "extensions" in the user config is something which we normally don't expect to be used as we wrote in the docs. This is only for a case where user has some interdependent extensions (e.g. you need to load thunderbolt driver first to then load RAID enclosure driver). The bundled-exts is even rarer of an occasion - this file defines extensions which are integral parts of the loader as we want to extract the LKM into an extension to make things simpler (similarly how we extracted VirtIO).

 

So to give you an example how we think it can work:

$ docker run -d --name rp -t .....

$ docker exec rp extension add 'https://.....'
The output of ext-manager.sh add 'https://.....'

$ docker exec rp build foo bar
The output of build-loader.sh foo bar

$ docker exec rp extension info test_dev.test_ext
The output of ext-manager.sh info test_dev.test_ext

 

It's actually simple - just symlink the .sh to /usr/local/bin/extension and /usr/local/bin/build. That way the docker just proxies the commands and we don't double the docs. It will also be simpler overall as we then have a unified interface. This also helps with one change which we have already planned: the add command for now accepts URLs but want it to accept URLs, names, and aliases. This way a user will be able to do "extension add trusted-dev.hp-222". As we mentioned in the previous post with time we want to also add (probably automatically) detection of VIDs & PIDs to the extensions so you will be able to essentially do "extension add fff1:fefe" and get the driver you need.

 

When we get something sensible (i.e. not bash) we can also help users with settings manager where they can simply do "docker exec user-set vid 1234" ... "docker exec user-set mac1 00ff....".

 

WDYT?

 

 

3 hours ago, svenger87 said:

No luck. Also with the boot-wait plugin.

image.png.210912e22c7cbb6753e2896aaadd0c19.png

image.png.d2976fc72e9c950cec21e97a936567bb.png

 

Do you have file /.no_synoboot? If so then check dmesg to diagnose WHY the synoboot is not appearing.

 

 

Edited by ThorGroup
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...