RedPill - the new loader for 6.2.4 - Discussion


Recommended Posts

2 hours ago, mounsif said:

srv: dell poweredge t420 

Os: vmware esxi 7.0.3

compile loder : redpill v0.11

Raid 1 = 4 hard disk sas 

global_config.json 5.67 kB · 7 downloads

Thank you. Global config is generic but can you also share the bromolow or Apollo user config as well? (please take out the serial number). 

 

Also, can you explain the Sas part of the comment? Are these SATA disks or Sas ?

Edited by urundai
Link to post
Share on other sites
2 hours ago, pipsen said:

Hello together,

 

I have read hundreds of posts here, but I still habe no success in booting my DSM 7.0.1 baremetal on my Intel NUC7i3 (just one M.2 SSD inside, nothing else).

 

This is what I did:

  • downloaded https://github.com/tossp/redpill-tool-chain
  • created apollolake_user_config.json with VID, PID, SN, MAC
  • compiled redpill-DS918+_7.0.1-42218_b1635455689.img and wrote it on USB stick

Result:

  • Image is booting and I can access it via Web Interface
  • "detected errors on the hard drives (2)"
  • tried several SataPortMap and DiskIdxMap combinations (00 1 / 0C 1 / etc...) in grub.cfg
    => either detected errors or no harddisk detected at all
  • tried to connect via telnet => connection refused
  • downloaded a redpill 42214 image from a post here and adapted VID, PID, SN, MAC => same problem

What is now the final solution of all these hints in these 116 pages to get rid of this problem? 😑

 

Thank you!

 

Screenshot_20211029_023746.png

apollolake_user_config.json

Link to post
Share on other sites
1 hour ago, mounsif said:

SAS disks

I am not familiar with SaS, hope someone that tried redpill with Sas disks before can help you further.

 

I also noticed that you included both bromolow and apollo configs. Which one are you building? I notice both mac1 and serial are xxxxxx... wanted to make sure that because you masked it for uploading and you have updated the default files with the actual serial number and mac in your local copy that you are using for building. 

Link to post
Share on other sites
2 hours ago, mounsif said:

SAS disks

As I understand it there is a problem with the Synology kernel not recognising SAS disks >2TB, something to do with it being a very old driver version. I'll see if I can dig up a reference to it.

 

...

 

Here:
https://xpenology.com/forum/topic/45795-redpill-the-new-loader-for-624-discussion/page/101/?tab=comments#comment-219467

 

Quote

 

So, regarding the SAS issue: the sas-activator may be a flop. We tested it with SSDs and few spare HDDs which obviously weren't >2TB. It seems like the driver syno ships is ancient and while it does work it only runs using SAS2 (limit to 2TB is one of the symptoms). Don't we all love that ancient kernel?  Probably on systems with mpt3sas the situation isn't a problem.

 

As to the native SAS support and how it works: in short it's useless. The SAS support in syno is tied to just a few hardcoded models. Most of them support only external ports (via eboxes). Some, like in a few FS* products support internal ports. Unfortunately, this is completely useless as the OS checks for custom firmware, board names, responses etc. Is it possible to emulate that? Yes. Does it make sense? In our opinion not at all. With the community-provided drivers we can all be fully independent of the syno-provided .ko in the image. As the LKM supports SAS-to-SATA emulation for the purpose of syno APIs thinking it's a "SATA" device further investment into true SAS doesn't really make sense. To be clear here: there's no loss of functionality or anything. Many things in the kernel actually use the "SATA" type. It seems like syno intended it to be a true SATA but down the road changed it to really mean "a normal SCSI-based disk".


The reason why syno separates real SAS controllers is to offer .... hmm, a lot of hacks over their firmware and timing issues with LSI controllers. So in short emulating a true SAS type in syno will give us no benefits. Saying this we also, very cautiously, should probably make a recommendation: for anyone using a standard array of disks of 4-8 it's probably a better choice to go with a Marvell-based chip which works natively without drivers (and which syno uses as well). For bigger installations LSIs are still preferred (as they're cheap, work with low-cost used SAS drives, save on cabling etc etc).

 

 

Edited by WiteWulf
Link to post
Share on other sites
18 minutes ago, WiteWulf said:

As I understand it there is a problem with the Synology kernel not recognising SAS disks >2TB, something to do with it being a very old driver version. I'll see if I can dig up a reference to it.

 

...

 

Here:
https://xpenology.com/forum/topic/45795-redpill-the-new-loader-for-624-discussion/page/101/?tab=comments#comment-219467

 

 

thx for you help I noticed you are using ESXI can you upload a img of it 🤗

  • Angry 1
Link to post
Share on other sites
19 minutes ago, mounsif said:

thx for you help I noticed you are using ESXI can you upload a img of it 🤗

 

No, sorry. If you read ThorGroup's many posts on the subject, one of the basic ideas of RedPill is to allow users to build their own images easily and not need to share images which include copyrighted Synology material. ThorGroup suggested that an earlier version of this project (from another team of developers) was shut down for exactly that reason.

 

Please don't share images and please don't ask others to share them. It's risks the future of the project if it's redistributing Synology's software.

 

From ThorGroup:
 

Quote

There are very good reasons why we're not sharing complete images and why we spend many many many hours developing the generator. The RP started in a different thread, its code was shared in different GH repos, the initial work wasn't done by us... and it's now unavailable. Full loader images contain way more than the GPL kernel. They contain syno's proprietary and copyrighted binaries. Distributing them is... problematic at best.

 

Edited by WiteWulf
  • Like 2
  • Thanks 1
Link to post
Share on other sites
9 hours ago, pipsen said:

 

Thank you! I did now:

  • ./redpill_tool_chain.sh auto apollolake-7.0.1-42218 with your user_config
  • used your user config with adapted MAC address and Serial Number
  • Now I get again "No hard disks detected in DS918+"

Same problem 😕

M.2 AHCI or NVMe SSDs 

Link to post
Share on other sites

Been trying to get DSM 7 running on this motherboard X10SDV-6C+-TLN4F, it has an embedded Xeon CPU, I'm using a LSI 9211-8i it mode and integrated 10gb nic.

 

I can get it to boot and I'm able to find it and start the setup process however it always gives me the same error "detected an issue with hd X all SATA ports have been disabled.

 

I loaded the mpt2sas, mpt3sas, together separate and none at all always with the same issue, If I disabled the onboard SATA then no HDs are found.

 

What's the correct setting to increase SATA ports?

Link to post
Share on other sites
10 hours ago, wahabe said:

hi,

which version of redpill tool chain did you use?

 

i tried with

  • 11 but then i get checksum error
  • 12 but then i have issue with the branch

so i have edited the global_config.json to add the 7.0.1-42218

 

build_configs": [
    {
                        "id": "bromolow-7.0.1-42218",
                        "platform_version": "bromolow-7.0.1-42218",
                        "user_config_json": "bromolow_user_config.json",
                        "redpill_lkm_make_target": "test-v7",
                        "docker_base_image": "debian:8-slim",
                        "compile_with": "toolkit_dev",
                        "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"
                                }
                        }

 

then

 

/rp-helper.sh build bromolow-7.0.1-42218

/rp-helper.sh run bromolow-7.0.1-42218

make build_all

 

[-] The extension thethorgroup.boot-wait was found. However, the extension index has no recipe for ds3615xs_42218 platform. It may not be
[-] supported on that platform, or author didn't updated it for that platform yet. You can try running
[-] "ext-manager.sh update" to refresh indexes for all extensions manually. Below are the currently known information about
[-] the extension stored locally:

 

thank you for your feedback :-)

Link to post
Share on other sites
1 hour ago, titoum said:

so i have edited the global_config.json to add the 7.0.1-42218

 

... and the error message is the same like it was with the build config in custom_config.json, wasn't it?

 

If an extension does not support a platform and dsm revision (in you case ds3615xs_42218), then the extension needs to be removed for a successfull build.

Currently TG's repos do not support 7.0.1 builds, neither do their exensions. Please raise an issue at whoever's rp-load repo you use. 

 

 

 

Edited by haydibe
Link to post
Share on other sites
2 hours ago, titoum said:

hi,

which version of redpill tool chain did you use?

 

i tried with

  • 11 but then i get checksum error
  • 12 but then i have issue with the branch

so i have edited the global_config.json to add the 7.0.1-42218

 


build_configs": [
    {
                        "id": "bromolow-7.0.1-42218",
                        "platform_version": "bromolow-7.0.1-42218",
                        "user_config_json": "bromolow_user_config.json",
                        "redpill_lkm_make_target": "test-v7",
                        "docker_base_image": "debian:8-slim",
                        "compile_with": "toolkit_dev",
                        "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"
                                }
                        }

 

then

 

/rp-helper.sh build bromolow-7.0.1-42218

/rp-helper.sh run bromolow-7.0.1-42218

make build_all

 


[-] The extension thethorgroup.boot-wait was found. However, the extension index has no recipe for ds3615xs_42218 platform. It may not be
[-] supported on that platform, or author didn't updated it for that platform yet. You can try running
[-] "ext-manager.sh update" to refresh indexes for all extensions manually. Below are the currently known information about
[-] the extension stored locally:

 

thank you for your feedback :-)

redpill-helper

Link to post
Share on other sites
4 hours ago, haydibe said:

... and the error message is the same like it was with the build config in custom_config.json, wasn't it?

 

If an extension does not support a platform and dsm revision (in you case ds3615xs_42218), then the extension needs to be removed for a successfull build

 

hi haybide,

actually, i didn't get this msg with the version 11 -> i only got checksum error.

 

regarding extension, i didn't activate any in the v12. so i am wondering if those 2 ootb extension are required or not then.

 

Link to post
Share on other sites

  

20 minutes ago, titoum said:

regarding extension, i didn't activate any in the v12. so i am wondering if those 2 ootb extension are required or not then.

 

You should realy speak to the github repo maintainer of the rp-load fork you use, as it is in their responsibility to provide the extensions that work with their repo (or at least point to compatible existing extenions made by someone else for that platform and revision), as TTG only provdes extenions for 6.2.4 and 7.0 Everything related to 7.0.1 is in the hands whoever made the 7.0.1 repo.

 

The forced extensions are declared in the `bundled-exts.json` of the redill-load repository you declared. I don't believe that removing the offending extensions is the right way to go. I would recommend to raise this concern to the repo owner and ask him to take care of this issue.

 

Fun fact: you can use `custom_bind_mounts` to mount a local copy of your own bundled-extensions.json into the container at /opt/redpill-load/bundles-extensions.json and make it mount on top of the existing file from the repo. On linux (and how I recently learned on DDf MacOS) you can mount single files(!), on DDf Windows this is not possible.

Edited by haydibe
  • Like 1
Link to post
Share on other sites

I have this issue with bromolow 7.0.1-42218 and  rp-helper v0.12

 

#] Checking runtime for required tools... [OK]
[#] Adding new extension from https://github.com/jumkey/redpill-load/raw/develop/redpill-virtio/rpext-index.json... 
[#] Downloading remote file https://github.com/jumkey/redpill-load/raw/develop/redpill-virtio/rpext-index.json to /opt/redpill-load/custom/extensions/_new_ext_index.tmp_json

curl: (35) Unknown SSL protocol error in connection to github.com:443 
[!] Failed to download https://github.com/jumkey/redpill-load/raw/develop/redpill-virtio/rpext-index.json to /opt/redpill-load/custom/extensions/_new_ext_index.tmp_json



*** Process will exit ***

[!] Failed to add "https://github.com/jumkey/redpill-load/raw/develop/redpill-virtio/rpext-index.json" as an extension:


,

*** Process will exit ***
[!] Failed to install thethorgroup.virtio bundled extension - see errors above

*** Process will exit ***
Makefile:30: recipe for target 'build_redpill_load' failed
make: *** [build_redpill_load] Error 1

 

Link to post
Share on other sites

i have successfully created with tossp/redpill-tool-chain an bromolow 7.0.1 image and converted it to an VMDK File for my HP GEN8 ESXI Test System.

first i had some issues with my 50GB Test SATA HDD.. i have to move them from Sata Controller 1 to Sata Controller 0 => 0:1, RedPill VMDK is on Controller0 0:0 to get the the HDD visible

Link to post
Share on other sites
3 hours ago, haydibe said:

  

You should realy speak to the github repo maintainer of the rp-load fork you use, as it is in their responsibility to provide the extensions that work with their repo (or at least point to compatible existing extenions made by someone else for that platform and revision), as TTG only provdes extenions for 6.2.4 and 7.0 Everything related to 7.0.1 is in the hands whoever made the 7.0.1 repo.

 

hi haydibe,

 

thank you for clarification and thanks to @apriliars3, i was able to sort out and edit the bundle to point to jumkey :-)

 

so for those that are still on baby steps and want to build bromollow 7.0.1-42218

 

edit the global_config.json with the proper version:

{
                        "id": "bromolow-7.0.1-42218",
                        "platform_version": "bromolow-7.0.1-42218",
                        "user_config_json": "bromolow_user_config.json",
                        "redpill_lkm_make_target": "test-v7",
                        "docker_base_image": "debian:8-slim",
                        "compile_with": "toolkit_dev",
                        "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/jimmyGALLAND/redpill-load.git",
                                "branch": "develop"
                        }
        }

 

then you build as usual:  /redpill_tool_chain.sh build bromolow-7.0.1-42218

then you run: ./redpill_tool_chain.sh run bromolow-7.0.1-42218

 

once in the docker: 

 

cd redpill-load

vi bundled-exts.json

change the lines by the one of jumkey in my case: https://github.com/jumkey/redpill-load/blob/develop/bundled-exts.json see content of this file for latest version.
then go back at the root folder and make build_all.

 

cheers.

 

edit: just tested and updated like a breeze o//
thank you all for your hard work and help

Edited by titoum
  • Thanks 2
Link to post
Share on other sites

@titoum: I have some notes to your approach:

  

Instead of doing this:

54 minutes ago, titoum said:

then you run: ./redpill_tool_chain.sh run bromolow-7.0.1-42218

 

once in the docker: 

 

cd redpill-load

vi bundled-exts.json

change the lines by the one of jumkey in my case: https://github.com/jumkey/redpill-load/blob/develop/bundled-exts.json see content of this file for latest version.
then go back at the root folder and make build_all.

You can simply download the file from yumkey's repo and put it e.g. in the rp-helper folder, then use the custom_bind_mounts like mentioned earlier.

 

 

 

54 minutes ago, titoum said:

edit the global_config.json with the proper version

 The intended approach for rp-helper v0.12 is to create a custom_config.json for your custom configurations ;) There is no need to butcher the global_config.json....

On Linux, you can get the file with `wget -L https://raw.githubusercontent.com/jumkey/redpill-load/develop/bundled-exts.json -o bundled-exts.json`  in your rp-helper folder and use a custom_config.json like this:

 

{
    "docker": {
        "use_custom_bind_mounts": "true",
        "custom_bind_mounts": [
            {
                "host_path": "bundled-exts.json",
                "container_path" :"/opt/redpill-load/bundled-exts.json"
            }
        ]
    },
    "build_configs": [
        {
            "id": "bromolow-7.0.1-42218",
            "platform_version": "bromolow-7.0.1-42218",
            "user_config_json": "bromolow_user_config.json",
            "redpill_lkm_make_target": "test-v7",
            "docker_base_image": "debian:8-slim",
            "compile_with": "toolkit_dev",
            "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/jimmyGALLAND/redpill-load.git",
                "branch": "develop"
            }
        }
    ]
}

 

Afterwards you can use the auto action for this build config without manual steps required...

Edited by haydibe
  • 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.