Leaderboard

Did anyone said drivers? You said you wanted drivers - we are delivering on the promise to find a way to get them to you. Today's release brings, what we believe is, a huge update to the RedPill as a project, and we hope to the community and the ecosystem around it as a whole. TL;DR We're introducing a decentralized extension manager into the RedPill project which is able to automate drivers installation. If you're a user, and we didn't screw up badly, just update to the newest release and nothing should change just yet. Soon you can expect your custom drivers to

This update of the redpill_tool_chain helper is long overdue. From now on the name will be redpill-helper, as it realy is just a helper for redpill-lkm and redpill-load. You can find the redpill-helper v0.12 attached to this post. It now supports an "ext" action, which delegates the commands to the ext-manager.sh script inside a container. The extensions are cached on the host, thus extensions need to be added only once and will apply for all build profiles! This should put an end to the need to modify the script or to use the run action and add the extensions every

Hello! TL;DR: We've developed a new loader for v6.2.4/v7+ which contains a way to install custom extensions/drivers/mods. We're looking for feedback of the extension manager & kindly asking for drivers to be made compatible with it. First of all, let us thank you guys for all the driver packages you were always preparing - we used them ourselves. As some of you may be aware we are developing a new loader called RedPill. There's a long thread in the developer's section of the forum: Today we've added a long-awaited functionality of custom drivers. We've chos

Rest of the answers starting from beginning of page 84 and ending on page 86. ======================================================================== We will love to be wrong here but to our knowledge 918+ kernel does not have SAS functionality. These symbols are present in the kernel code but guarded by "ifdef MY_ABC_HERE" which presumably depends on the model/SAS support option. Eh... it is possible to emulate that. We know how technically. We can provide these symbols virtually in RP but it will require some digging to check what they should return. Since we

A quick update (we will write more tomorrow): the native mpt2sas driver works but it's present only on 3615xs platform. To activate it and make it working properly without any hacks just add this small extension: https://github.com/RedPill-TTG/redpill-sas-activator We also updated the kernel module to rewrite SAS => SATA ports so it should work with any off-the-shelf mpt2sas or mpt3sas driver.

A few compiled modules for DS918+ (4.4.180+). Most network drivers have been tested and work https://github.com/pocopico/4.4.180plus-modules

Hello, With @haydibe help and validation, here is the redpill_tool_chain v0.11 redpill-tool-chain_x86_64_v0.11.zip New feature : - Supports to bind a local redpill-lkm folder into the container (set `"docker.local_rp_lkm_use": "true"` and set `"docker.local_rp_lkm_path": "path/to/rp-lkm"`) Thanks @haydibe Tested with 6.2.4 and 7.0 both bromolow I can't test for DS918+ as I don't have the CPU for. But it should be OK

This post contains answers up to page 67. ====================================================== You should use extensions now and NOT modify any files manually. Please, do not modify the grub.cfg file. This isn't a supported method with RP and should not be used. You should add that option as an extra_cmdline in user_conf instead. That is... strange. We're adding it to our internal list as the disk test shouldn't randomly crash the pool This usually happens [on VMWare] when you use USB-boot and not SATA boot. VMWa

The RedPill is back! As some of you may be aware a lot of research materials as well as the code for parts of the kernel module were pulled from GH. We're happy to report it's back and fully public! Before further ado we have a small sneak-peek of the current state: Repositories Both LKM code and the research materials are present in two repositories. Both are automatic forks from our internal serves and are updated few times a day. - RedPill LKM: contains the current version of the Linux kernel module source code along with implementation details description - D

Oublie que t'as aucune chance! On sait jamais, sur un mal entendu ça peut passer! We believe in you!

A few, mainly network drivers have been added to my repo, please test and report in the GH issues page https://github.com/pocopico/rp-ext

This post contains answers to questions up to beginning of page 84. ============================================================================ It's a holy grail to catch WHAT is actually causing that 100% spike when it happens. This is the clue of where the spinlock is taken but not released. Kernel points at influxdb and other DBs but we're sure it's not that. It's somewhere in the kernel itself. This is perfectly correct. Windows uses local time in RTC and Linux uses UTC. The behavior of windows dates back to the MSDOS days. Linux actually follows

You release this on a blog without any care about what ThorGroup said about this. You really should avoid publishing builded images containy Synology proprietary code. The main goal of ThorGroup project is to avoid this kind of things... And again, we are not even at beta stage yet... So making is too easy will make unaware/unprepared people breaking their current working DSM if something goes wrong. Will you support/help them one by one when it will happen ?

So a quick up-not-to-date You guys are writing so many post and we're committed to reading all of them and responding where needed. We promised to write something more last time but few of us had slightly unpredictable life events - given the fact we usually get together physically we encounter a small delay. 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

No problem, it's just when reporting problems or asking for help it's in everyone's interest to be as precise as possible in the initial report. "Booting" or "bootstrapping" (to use the old fashioned term) usually refers to the very first stage of loading code from a storage device once the BIOS has loaded. If you get as far as the "Booting the kernel." message your system has booted. It may not have successfully finished loading an operating system, but it's *booted* What a lot of people are incorrectly assuming (and this bears repeating) is that when they see the "B

I will release an RedPill extension soon for LSI cards (mptsas/mpt2sas/mpt3sas. I just need to find some time

Finally we've got some time to respond to the questions. We will try to respond to as many as possible so stay tight ======= Why there's a problem with compiling drivers when syno didn't publish kernel sources? This is going to be a separate post addressing "why you cannot randomly grab drivers and compile them" so we can link to it. Let us explain where's the problem, this applies to many questions really. There are few major issue with compiling drivers against a different sources. The three major ones are: 1) Versioning of syno kernel's is broken due

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.3-25426 Update 3 - Loader version and model: redpill-DS918+_6.2.4-25556_b1630506799 - Using custom extra.lzma: No - Installation type: BAREMETAL - ASRock J5005-ITX 8GB RAM - Additional comment :

Redpill devs might want to consider one of the below listed models for support in order to enable this very useful and new feature. FMI: https://kb.synology.com/en-us/DSM/help/DSM/StorageManager/volume_btrfs_dedup?version=7

I'm sure that is to sell those silly overpriced branded SSDs and nothing else. Even if Syno tests for a device model or serial range, this should be defeatable much like the NVMe patch approach. Please consider a platform like this, with full RAIDF1 and decent CPU support.

i am not sharing image may be i mistyped, i want to say there are people came for just images, they can use script for their own image rather than asking someone. Sent from my iPhone using Tapatalk

Quick update: Thanks to amazing reports from @WiteWulf the KP on 3615xs should be fixed now. For details see https://github.com/RedPill-TTG/redpill-lkm/issues/21#issuecomment-932690817 A different hard loockup seems to exist still but this shouldn't affect most of the people and judging by the last post in the issue it may not even be a bug but an over-reactive kernel protection mechanism. ==================================== We don't see a reason why not. The kernel should load it automatically. We never played with microcode updates manually but DSM isn't special h

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.

Just wanted to say thanks for all the hard work, the below is not my work but bits extracted from the thread so kudos to the posters. But this is what I used to get my machine booted. On first launch it did take a good amount of time to become discoverable, maybe 5-10 mins so be patient, after install I got a something is wrong message, wait another 5 mins and you should then be able to log in. I've just got this running on my baremetal ASROCK J3455-ITX MB with no modification. Rocking Applolake DSM 7.0.1 Added the below to global config for RedP

ssh into your dsm, once logged in paste this scrip; sudo mv /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt.bak && sudo curl -Lko /etc/ssl/certs/ca-certificates.crt https://curl.se/ca/cacert.pem your synocommunity packages will work again.

DS918+ bsp made by GitHub Actions DS3615xs src https://github.com/jumkey/redpill-load/commit/8605a0c1c726a64089e63b55eed9b2102c64276d

I made the bsp and config files of the new pat file for DS3615xs （I will make the bsp and config files of ds918+ later today） Welcome to test (I have not tested usability，If you can’t boot it, please leave a message to me!) And you can download the old pat of DS3615xs from here：https://share.llilii.cn/xpenology/pat/dsm7.0.1-42218/DSM_DS3615xs_42218_OLD.pat https://github.com/unknown-o/redpill-load

WoW !! Have the answer from synology, they will upload the GPL sources on SourceForge ASAP !! Wait & see !! They said the global deploy of 7.0.1 is not finished now, and we just have to wait 1 or 2 week to have the kernel sources

SO I am encountering an issue with Sabnzbd not connecting to my news servers (Eweka, Thecubenet) with an untrusted certificate from eweka error. I found the following post on Sabnzbd site which seems to translate to an OS issue with incorrect certificates due to an intermediate signing cert from Lets Encrypt that expired Sept 30 2021. Easy enough to fix on windows, but how about on XPE? https://www.sslshopper.com/ssl-checker. ... news.eweka.nl shows the certificate chain of eweka is correct. So problem is client side - which in my case is XPE https://scotthelme.co.uk/le

Oh, with red pill is possible, awesome! I hope they put it into the loaders section soon! (and not just in the developer one)

Looks very nice. When are you putting this project in the loader section? It looks like the first page is not edited since a long time. If there are new changes/features/updates/faqs/links to builds, should be great to have it edited in the first page (like version history/time-lined...). Is very hard to follow through that huge unorganized thread right now. Just my opinion. Such a great job! Thanks

Nice I can stop the container now My (ugly) edits : Makefile : @if [ "$(TARGET_PLATFORM)" == "bromolow" ]; then \ pushd $(REDPILL_LOAD_SRC) && \ ./ext-manager.sh add 'https://raw.githubusercontent.com/pocopico/rp-ext/master/tg3/rpext-index.json'; \ ./build-loader.sh 'DS3615xs' '$(TARGET_VERSION)-$(TARGET_REVISION)'; \ global_config.json : { "id": "bromolow-7.0.1-42218", "platform_version": "bromolow-7.0.1-42218", "user_

https://github.com/RedPill-TTG/redpill-load

Check this out for solution: https://github.com/SynoCommunity/spksrc/issues/4897 Essentially this commands can fix it: # ssh to your NAS first sudo -i mv /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt.bak curl -Lko /etc/ssl/certs/ca-certificates.crt https://curl.se/ca/cacert.pem

you can try my branch, I got 3615 7.0.1 working https://github.com/comicchang/redpill-load/tree/7.0.1

For those who might use VMWare Workstation to do some tests. Serial console from TCPIP is not available from GUI, and not officially supported. But you can edit your .vmx file to add : serial0.present = "TRUE" serial0.fileType = "network" serial0.fileName = "0.0.0.0:10021" serial0.network.endPoint = "server" serial0.startConnected = "TRUE" 10021 or whatever suits you. Then you can telnet to the serial port as usual.

Just Orphée! It's enough

Not sure why I didn't think about it earlier, but in fact you can checkout redpill-load on the host, configure "docker.local_rp_load_use": "true" and "docker.local_rp_load_path": "/path/where/your/local/redpill-load/copy/is" in global_config.json. And then use the ext-manager inside your local redpill-load copy before you perform your next auto build. This way there is no need to integrate the ext-manager inside the redpill-tool-chain, as it can be directly used inside the local redpill-load folder. Update: I just checked out of curiousity. This feature was available

Guys, i have created the repo based on popopico repo for adding the r8196 driver. but during the build the loader via toolchain 0.11 ./redpill_tool_chain.sh auto apollolake-7.0-41890 faced with error. [!] Extension "t-rex-xp.r8169" is not added/installed - did you misspell the name or forgot to do "ext-manager.sh add <URL>" first? I have done the following steps: 1. ./redpill_tool_chain.sh build apollolake-7.0-41890 2. ./redpill_tool_chain.sh run apollolake-7.0-41890 3. cd ./redpill-loader 4. ./ext-manager.sh add 'https://github.com/T-REX-XP/rp-e

Yeah ! I've tested it and it works for my baremetal Gen7 with LSISAS1068E loading MPTSAS.ko as well : [ 1845.535722] mptsas: ioc0: attaching sata device: fw_channel 0, fw_id 0, phy 0, sas_addr 0x1d225 [ 1845.548867] scsi 5:0:0:0: Direct-Access ATA HTE7275 A170 PQ: 0 ANSI: 5 [ 1845.551109] <redpill/scsi_notifier.c:65> Probing SCSI device using sd_probe_shim [ 1845.551402] <redpill/scsi_notifier.c:77> Triggering SCSI_EVT_DEV_PROBING notifications [ 1845.551707] <redpill/scsi_notifier.c:87> Calling original sd_probe() [ 1845.552027] <redpill/scsi_

This is really amazing. After I mount successfully, I directly see the /dev/sdX device and the hard disk in DSM. Therefore, it can be said that you may be the first person to use SAS devices on dsm7.0.

We think it should be 1 driver = 1 extension. This way you install driver for your ethernet, driver for your GPU, and a driver for your USB 3 chipset. This will also let us do another cool thing down the road: provide a small image which will boot on your hardware, scan it (essentially grab vids & pids), and suggest a platform and drivers needed to make it work. VID & PID info are embedded in the drivers on linux anyway so it's easy to extract. If you pack many drivers in one package you can easily run into conflicts and load way too much. Jun's loader loaded a ton... literally all mod

Working with latest @jumkey commits Did not test more than booting yet. @jumkeythanks

Support DSM 7.x . Available now !!

Affirmative. Everything right on spot! DSM6.2.4 builds use the kernel sources that are publicly available - thus the condition checks for the kernel sources beeing used is met and there is noreason to throw the warning. From my perspective there is nothing wrong with the warning on DSM7 builds, as it's a constant reminder that we need to switch from toolkit-dev to the kernel sources as soon as they are publicly available. This warning is a functional warning, not a technical warning. @dateno1 To "fix" this warning you just need to convince Synology to publis

@ThorGroup thank you for the update! And indeed, I spoted and incorporated the new make targets into the new toolchain builder version Taken from the README.md: Supports the make target to specify the redpill.ko build configuration. Set <platform version>.redpill_lkm_make_target to `dev-v6`, `dev-v7`, `test-v6`, `test-v7`, `prod-v6` or `prod-v7`. Make sure to use the -v6 ones on DSM6 build and -v7 on DSM7 build. By default the targets `dev-v6` and `dev-v7` are used. I snatched following details from the redpill-lkm Makefile: - dev: all symbols

Everything but the NIC driver is included in the default build, and the tg3 NIC driver is already in pocopico's repo: https://raw.githubusercontent.com/pocopico/rp-ext/master/tg3/rpext-index.json I see that pocopico has issued PRs for some of their extensions but they're still waiting on @ThorGroup to merge them.

There's a script which takes care of that. Its template is present in redpill-load repo in include/loader-ext/target_exec.sh_ - it is filled-in with by the extension manager. From the perspective of adding new drivers you should just add entries under kmods key like described in the documentation for devs and the target_exec script will take care of the rest (i.e. insmodding them etc). There are no interextension dependencies (i.e. between multiple extensions). However, when you specify multiple .ko to load in kmods key they're loaded in that order. There's a mechanism to forc

Hello guys, with the help of @Orphée and @Comic Chang's repo , @pocopico driver I wrote a script which gives you Redpill image please change VID/PID/Mac/Serial no. accordingly I tried in Linux VM GUIDE:- ```nano takeredpill.sh``` add your PID/VID/MAC/SN in the beginning of the script ```chmod +x takeredpill.sh``` ```sh takeredpill.sh```` output folder have image ** this is early stage may be error happen don't worry please ping me takeredpill.sh takeredpill.sh

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