Jump to content
XPEnology Community

Redpill Loader information thread


ed_co

Recommended Posts

Hello,

 

I know this is the developer's room.

 

First of all, thanks to all the developers doing the amazing work on the Redpill project, it looks like is working very nicely lately, and it looks like it is an option now.

 

I know the Redpill project is considered non production ready right now, but it looks like it is being used for a lot of people. Jun's loader was considered beta at some point too, and there were not too many iterations from it, and became the production one. And I think that Redpill could have even more iterations and could be more polished than Jun's right now -I could be wrong-, as I see there are a lot more platforms to chose from.

 

I have seen is being used for a lot of people that migrate from Jun's loader info. I personally have Jun's 918+ baremetal currently.

But still, even it there is a lot of information, the threads are very confusing to follow (yes it is in developer's room, I know), but very unorganized. I posted several times and months ago in the Redpill main thread talking about this, but still there is no change about how the information is spread/organized. I don't know how to even start, and I would like to understand how this works, and what are the differences in how it works.

 

Questions:

- Is there any place with a comparison feature information redpill vs jun, to see wha tis the current status of it? Limitations/differences from each one, and know the viability of using it right now.

- Is there any place with all the installation methods (tinycore/non-tiny core and with VM/baremetal)... An ultimate guide replying to all these questions would be very appreciate it for people like me which are not OS developers and would like to start with it. Even if there are guides to follow about some of the methods, it doesn't explain the options out there of why to chose one or the other, and the difference between them.

- Is it time to put it as a viable Loader along with Jun's in the loader section?

 

This could be the place to gather all the information in detail for people who want to be informed about how this works, and maybe start with it.

 

Sorry about the place I posted this topic, and please feel free to move it to a more proper location.

Thanks,

 

E.

 

 

Edited by ed_co
  • Like 3
Link to comment
Share on other sites

  • ed_co changed the title to Redpill Loader information thread

You make several good points.  I've had the following written up for some time but haven't posted but it appears now is the time as it overlaps with your opinion.

 

This is just my opinion, and one not even doing active development - but there are three issues that probably need resolution:

 

1. A comprehensive installation guide

2. An automated fix for the minor version upgrade procedure

3. More success data for complex installations and issue recovery

 

Regarding the latter, I am still periodically reading about how large arrays suddenly drop off.  Do we know why?  Are we sure that they are recoverable?  This is the main reason I haven't moved my production data to a new loader or DSM 7.

 

There also seems to be a move to proliferate to a lot of Synology hardware platforms.  This is good on the developer side if it enhances the available hardware ecosystem.  It's bad for testing and predictability as it has the potential to severely dilute each platform's population and issue reporting.  Personally, I'd like to see the dev community consolidate on specific platforms before calling it mainstream.

 

I will add to the Loaders and Platforms matrix when Redpill solutions are published for non-dev release.

  • Like 3
Link to comment
Share on other sites

  • 1 month later...
On 3/16/2022 at 11:02 AM, flyride said:

3. More success data for complex installations and issue recovery

 

Regarding the latter, I am still periodically reading about how large arrays suddenly drop off.  Do we know why?  Are we sure that they are recoverable?  This is the main reason I haven't moved my production data to a new loader or DSM 7.

 

Building off this, I have noticed in the past that many users experienced issues with docker, specifically databases that cause high CPU usage. This would cause Redpill to crash, and was something @ThorGroupwas going to look into before they disapeered. Just this week, I noticed crashing behavior in Redpill when Synology Drive attempts to index a lot of files, which sucks because it makes using Synology Drive pretty unstable on Redpill, which is a major feature to be missing out on. Indexing involves database operations in DSM of course so obviously there are still stability issues in Redpill with things that involve databases unless they are small databases.

 

My concern is.... it seems that fixes to problems like that are handled in Redpill-LKM or even the base Redpill-Load. As far as I know, there have been zero developments to RP-LKM since TTG left. All of this work people have been doing lately to make installing Redpill easier like RPTC, etc. are amazing... but, they jump the gun in the sense that they are just allowing easier install of a buggy implementation of LKM. This is just going to cause headaches for everyone especially as more people install with these easy tools and then have problems like the above. I'm really hoping someone is capable of actually updating RP-LKM to make the underlying system more stable.

  • Like 1
Link to comment
Share on other sites

All are valid points. The question is - as im not really sure - if there was ever the same for Juns loader.

 

The @ThorGroupwork is left somewhat hanging between developer and alpha release. On one side the good thing is that their work is open source and available for further development and improvement.  On the other side, there is no person or group willing to undertake the task. 

 

The issue with the crashing under heavy load was solved sometime before they went silent. At least they have tried to minimize the risk of crashing. I'm not sure though that they succeded to properly fix it.

 

Juns solution might though seem better but Syno did change a lot as well. Also with Juns loader you are stuck in 6.2.3 and you are missing application features.

 

  • Like 1
Link to comment
Share on other sites

Indeed all points are valid but there is no going back now.

 

Whether Jun's loader was more stable or not, we are comparing apples with oranges and that ship already sailed.

 

Since ThorGroup loader is open source I want to believe when the time comes hopefully somebody will rise from the community with the necessary skills to take over...

Edited by gadreel
  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...
On 4/19/2022 at 4:30 PM, ilovepancakes said:

 

Building off this, I have noticed in the past that many users experienced issues with docker, specifically databases that cause high CPU usage. This would cause Redpill to crash, and was something @ThorGroupwas going to look into before they disapeered...

 

But is this just with docker? Or in baremetal installations happen as well? Because docker has some limitations too. If this just happens in an dockerized environments, I don't think it should be an issue. DMS itself was never thought to be something to be run inside any VM/container and IMHO, and just IF it is behaving correctly baremetal, I don't see any problem with it.

 

Another point I haven't mentioned before: I think a lot of problems which seems that are about stability, is just because there is no proper documentation, and a lot of people in the development room trying and making mistakes that wouldn't happened if there were such complete documentation, so having it, it could decimate the problems/mistakes/issues threads, which are making it to look like is more unstable that it really is (I could be wrong).

 

Edited by ed_co
Link to comment
Share on other sites

On 4/30/2022 at 9:18 PM, phone guy said:

Proper documentation of the commands would be helpful.  I have noticed there are several build commands (auto, manual and static) but I have never seen a definition between all 3.  This is just one example.

But not just documentation about a certain tool, but globally. Something which unifies every tool we need for the entire process is a must.

  • Like 1
Link to comment
Share on other sites

  • 5 weeks later...
  • 7 months later...

Hello guys,

 

The amount of documentation here had increased a lot, and I wanted to say thanks to @flyride and everyone else who made it possible. Now is amazingly better than before.

If some of the information I am about to ask is already in place -and my understanding is wrong-, apologies in advance, I will correct/update the post.

I still see several things that could be improved information/documentation wise:

 

0) As per today is there any limitation if you compare RedPill Loader vs Jun's loader?

Just to know if all the Jun's functionalities are achieved/surpassed with this new Loader or still there are any things that are better in Jun's loader that couldn't be achieved with the RedPill Loader (and not talking about being monolithic).

 

1) RedPill Loader and methods of installation information.

Now a lot of people is using RedPill Loader, using TinyCore RedPill Loader (TCRL) or Automated RedPill Loader (ARPL).

It looks they are treated like if both were different loaders (in fact, there is just one guide made by flyride for TCRL, but non for ARPL), but (I guess) they are using the same exact loader (or not?). I asked that because now to me, is hard to separate the concepts and the loader.

I even thought at first that ARPL was another level of abstraction over the TCRL, but it looks like is not.

Several questions about it:

- Is the RedPill Loader (not TCRL or ARPL), being developed separately (and still active and changed often?, as the ThorGroup left the project?), or is being developed in conjunction of the TCRL or ARPL?

- Which leads to, would love to know the boundaries of each one. What exactly does RedPill Loader, TCRL and ARPL.

- If we install one of the TCRL, or ARPL, then are we constrained afterwards in any way, I mean, we can swap from TCRL to ARPL and viceversa at any point.

- @flyride, can you update the RedPill Loader guide for not just using TCRL but choosing ARPL be done. If you chose between them, why one over the other, if it matters.

- And this could be a question for both developers of TCRL (@pocopico) and ARPL (@fbelavenuto). Why not unifying both TCRL and ARPL? As it looks like would benefit both approaches and probably easy to maintain and not waste individual efforts.

 

2) Information about how to update to a new version of DSM, and updating the loader too.

Information about updating to a new DSM version. What are the steps needed for that (probably I guess based on the method we used to install it). For what I understand if we update to a new version the RedPill Loader will not work anymore and has to be updated.

- What could be the procedures for updating, if there are any automated process for it to make it easier for the users perspective?
- Is possible to make it with DSM update directly or has to be manual?

 

3) RedPill Loader future questions

* Regarding changing limitations to some platforms. Like for these examples:

- Would be possible to change for example the numbers of max cores in a DS918+ platform?

- Or in DS3622xs+, should be possible to add transcoding on it?
Is there any way to compile and make a compatible kernel for the DSM to achieve that?

* Any way to make the Loader update proof?

* Any other future plans which could be discussed?

 

Thanks guys, and sorry for the big chunk of text.

 

E.

  • Like 2
Link to comment
Share on other sites

  • 4 weeks later...
On 1/31/2023 at 4:44 PM, ed_co said:

If we install one of the TCRL, or ARPL, then are we constrained afterwards in any way, I mean, we can swap from TCRL to ARPL and viceversa at any point.

What I really wanted to know here as well was TCRL vs ARPL, pros/cons/limitations.
The reason of the previous post was mostly, what path to choose in order to get the Red Pill installed, is what anyone could think at the moment to install DSM7.X, and this is not clarified out there.

Edited by ed_co
Link to comment
Share on other sites

40 minutes ago, ed_co said:

What I really wanted to know here as well was TCRL vs ARPL, pros/cons/limitations.
The reason of the previous post was mostly, what path to choose in order to get the Red Pill installed, is what anyone could think at the moment to install DSM7.X, and this is not clarified out there.

 

I summarize the Pros and Cons of the REDPILL loaders below.

 

1.TCRP Jot loader

Pros: The loading time of the loader is fast, hardware compatibility is good, and it is stable.

Cons: Sometimes the three partitions of the loader are not well recognized.

           DSM Small Revision does not have an auto-patch feature.

           Since there is no DSM automatic patch, if you fall into an infinite recovery loop when updating a revision, you must patch it separately using Jot Mod Post Update.

 

2. ARPL Jun Loader

Pros: DSM update is easy even without automatic patching because it contains the function to fake the Small revision of the Jun loader used in the past DSM6.

           New features of the loader are constantly being uploaded, and Addons that supplement the features of the redfill are being developed.

          https://github.com/fbelavenuto/arpl-addons

           Convenient menu method support for loader build,

           You can check the IP assigned from the router directly on the console. (This is a feature I requested from fabio. ^^)

Cons: Stability tends to drop a bit due to frequent updates.

           The loading time of the loader is approximately 3 minutes.


3. TCP Friend Loader

Pros: A loader made by taking the strengths of Jot and Jun.

            DSM Small Revision auto-patch function is included.

            Since it inherited the Jot method, fast loading time, stability and compatibility are guaranteed.

            ARPL's Addon has the same partially implemented contents as M SHELL for TCRP.

          https://github.com/PeterSuh-Q3/tcrp-addons

           Convenient menu method support for loader build, (M SHELL exclusive function)

           You can check the IP assigned from the router directly on the console.

Cons: On AMD CPUs, the original Synology platform works only with v1000 / r1000, etc. corresponding to AMD.

           There are cases where the loader fails to boot due to conflicts with the NVMe cache, but this has not been reported much.

Edited by Peter Suh
  • Thanks 2
Link to comment
Share on other sites

Wow @Peter Suh, thanks. Looks like you have very low level understanding of the internals of the loader. Which makes me wonder what is the common part of them, as it seems they are very different. Don't understand what exactly does the common part (RedPill) of them.

I don't understand where the Jot, Jun and Friend loader naming came from regarding RedPill, first time I read it. Is your personal terminology?
Is confusing, as I just thought there were two loaders (TCRP and ARPL), but it looks like they are three. Can you post the link of the third one?

Edited by ed_co
Link to comment
Share on other sites

14 hours ago, ed_co said:

Wow @Peter Suh, thanks. Looks like you have very low level understanding of the internals of the loader. Which makes me wonder what is the common part of them, as it seems they are very different. Don't understand what exactly does the common part (RedPill) of them.

I don't understand where the Jot, Jun and Friend loader naming came from regarding RedPill, first time I read it. Is your personal terminology?
Is confusing, as I just thought there were two loaders (TCRP and ARPL), but it looks like they are three. Can you post the link of the third one?

 

What they have in common is that they are all loaders based on REDPILL,
As already explained in the text, it is up to the user to check the pros and cons of each loader and choose the loader that suits his/her taste.

The naming of Jot, Jun and Friend loader was decided by the developer who developed each loader.

If you want a third github source, there is a link below, but it doesn't explain enough.
https://github.com/pocopico/tcrpfriend
Rather, I have not seen any material that explains in more detail than what I described above.

  • Thanks 1
Link to comment
Share on other sites

On 3/4/2023 at 4:19 PM, Peter Suh said:

The naming of Jot, Jun and Friend loader was decided by the developer who developed each loader.

I don't see any reference to "Jot" name in TCRP, in its thread: link.

I don't see any reference to "Jun" name in ARPL, in its thread: link.

Good to know, that "friend", is from pocopico. That's a pity there is not a thread dedicate to this specific loader, as it is stated that is not the same as the TCRP. Maybe @pocopico could share some advice, or wants to start a thread about it, so not being confused with the TCRP

Edited by ed_co
Link to comment
Share on other sites

7 hours ago, ed_co said:

I don't see any reference to "Jot" name in TCRP, in its thread: link.

I don't see any reference to "Jun" name in ARPL, in its thread: link.

Good to know, that "friend", is from pocopico. That's a pity there is not a thread dedicate to this specific loader, as it is stated that is not the same as the TCRP. Maybe @pocopico could share some advice, or wants to start a thread about it, so not being confused with the TCRP

 

Below, ARPL fabio's greetings mention JUN and jumkey.
I used forum knowledge and code from various loaders developed by TTG, pocopico, jumkey, Jun and many others.

Jun's loader has a history before Redpill.

Jun -> jumkey -> fabio
These three developers are involved with the Jun loader.
Jun's history has been mentioned in most of our forum topics in the past.
Since then, the history of jumkey, a redpill, started from the topic below.
https://xpenology.com/forum/topic/61702-yet-another-juns-mod

 

I don't know exactly when the term JOT started.
From the time when jun load for jumkey's redpill came out
It seems that the moderators named it to distinguish it from the existing TCRP.
I think I saw it somewhere in a tutorial, but it's hard to find now.

 

FRIEND started when pocopico developed version 0.9 of TCRP below and announced the release in the middle of this topic.
https://xpenology.com/forum/topic/62871-tinycore-redpill-loader-tcrp-development-release-09/page/3

As you said, there is no topic yet that clearly guides and explains all of this.

  • Thanks 1
Link to comment
Share on other sites

10 hours ago, ed_co said:

I don't see any reference to "Jot" name in TCRP, in its thread: link.

I don't see any reference to "Jun" name in ARPL, in its thread: link.

Good to know, that "friend", is from pocopico. That's a pity there is not a thread dedicate to this specific loader, as it is stated that is not the same as the TCRP. Maybe @pocopico could share some advice, or wants to start a thread about it, so not being confused with the TCRP

 

 

Jun and Jot is a "terminology" that was used initialy by Jumkey and are in terms of conseption the same thing. A buildroot that performs all the actions after an upgrade and then uses kexec to boot dsm using the patched kernel and the patched ramdisk.

 

Jumkey analyzed the buildroot concept and introduced that on his own repo and then it was adapted by TCRP and later by ARPL.

 

TCRP friend came later than ARPL cause that was the time for TCRP to adjust to new technics. TCRP friend has its own repo and its own wiki.

 

https://github.com/pocopico/tcrpfriend/wiki

 

Of course both TCRP and ARPL are based on the same initial concepts but with some enhancements. ARPL currently, as it was designed from scratch having all these technics in mind, will adjust easier in a future upgrade. Some TCRP friend features are uniq like static IPs, Hidden boot messages, loader backup etc. But still missing some features, like eudev. Eudev was adopted partially but will break in case of an update by TCRP friend as this is not yet implemented. 

 

Also Fabio further assisted with numerous issues like. dtbpatch, kernel patch, LKM development, new patch development etc.

 

I'm further developing the TCRP loader and will adopt all these in a future release.

 

image.thumb.png.2868dfa314a2c3f4d5625f8cfa307c02.png

 

 

 

Edited by pocopico
  • Like 5
  • Thanks 3
Link to comment
Share on other sites

@pocopico, I know it could be a stupid question but you are saying that even if you have to start a new installation you would do it with ARPL. So, why not joining forces with ARPL and keep extending the ARPL, (maybe with the help/ideas of some of the TCRP and TCRP friend code) and just improving this one, so it would be more efficient for everyone, being more developers involved working together?

I mean, I am sure that there would be a reason, just curious.

 

I am still with my DSM 6.2.3 with Jun's loader, holding up to update. If I don't upgrade with ARPL is because of the stability issues Peter mentioned, and because still I don't know what I have to do, when a new version arises (don't know what is the procedure to update to another minor version -nor major-, with Jun's loader was trivial, but not sure here neither in ARPL or TCRP). Which I would love to know, but I haven't find any explanation of the procedure in any thread.

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

31 minutes ago, ed_co said:

@pocopico, I know it could be a stupid question but you are saying that even if you have to start a new installation you would do it with ARPL. So, why not joining forces with ARPL and keep extending the ARPL, (maybe with the help/ideas of some of the TCRP and TCRP friend code) and just improving this one, so it would be more efficient for everyone, being more developers involved working together?

I mean, I am sure that there would be a reason, just curious.

 

I am still with my DSM 6.2.3 with Jun's loader, holding up to update. If I don't upgrade with ARPL is because of the stability issues Peter mentioned, and because still I don't know what I have to do, when a new version arises (don't know what is the procedure to update to another minor version -nor major-, with Jun's loader was trivial, but not sure here neither in ARPL or TCRP). Which I would love to know, but I haven't find any explanation of the procedure in any thread.

 

We are cooperating for some issues with Fabio and we are discussing whats next. In the meantime i think its on common interest to continue working on separate loaders for the time being. Personally, I dont think that ARPL is less stable than TCRP. I find them both well established and working. 

 

Remember that with Juns loader in the past we didnt have much success with the updates and the ability to update stopped at some point. Redpill started at 6.2.4 and has gone all the way up to 7.1.1 U4. Started with the already known models and went to a whole bunch of options as far as models are concerned. That required a lot of dedication and work from the community. 

 

I own a legit syno device and I will of course always encourage people to spend some money and buy the legit hardware, but in the other side if someone wants to try and play around even with all issues with the loaders its something that is possible also, BUT minor issues, setbacks and limitations should be always expected, even though we are always trying to get around these.

 

As far as your upgrade is concerned, please try first with unused disks and maybe a virtual machine to familiarize yourself with the loaders and then proceed with an upgrade on your production data.

 

Edited by pocopico
  • Like 2
Link to comment
Share on other sites

Thanks for the reply @pocopico.

  

3 hours ago, pocopico said:

As far as your upgrade is concerned, please try first with unused disks and maybe a virtual machine to familiarize yourself with the loaders and then proceed with an upgrade on your production data.

In my opinion, ideally we shouldn't even need to think in the loader itself, once it is configured and working. So not sure if familiarize for just using it ideally several times needs to be done. Like I did with Jun's loader. I think, since I configured, I have never had to change it at all and never need any interaction with it anymore. For updates, as I had it configured as manual, I was making sure everytime I was updating, that the new released update was already reported as a successful update, that's it. IMHO, I don't see a loader like a thing you have to interact or use again and again.

 

I personally owned a DS1512+, during a total of almost 4 years. After a couple of years, I started with a custom Xpenology build with similar budget, and I couldn't believe that I was having the SAME stability, with far away better hardware, not having the slowlyness I had in the past with the legit synology device, and after more than a year having both devices I gave the DS1512+ to a friend, and never looked back. The hardware I managed to gather, for less than Eur1000 (without disks) was better than Eur2500 hardware device, so for me was a no brainer. I never had any single error nor stability problem with Jun's loader DS918+ DSM6.2.3, which currently I am locked to. At least being 100% stable, like real synology hardware.

Now I find is the moment to update it. And that's why all these questions here.

 

Would love to see if there is any tutorial/guide for the updating process to a new version of DSM (like for example from DSM 7.0.1 to DSM 7.1.1). Like the guides that @flyride does, cause they are amazingly easy to follow and very informative.

This is the thing I fear the most, as I don't wanna risk the data in every update I would like to perform. It looks like the loader have to be modifed in every DSM version update, so it is a little scary. I am looking forward a loader who could be updated to a new version of DSM in a similar way of the Jun's loader did (not in the same way it did it, being one loader for all the versions, but maybe autoupdating itself in every update with no user intervention, being stable). Ideally if I could install/configure the loader, and never touch it again, is the way to go. Maybe is already there, but what I have not seen is a guide/tutorial about the update process.

Edited by ed_co
Link to comment
Share on other sites

17 minutes ago, ed_co said:

It looks like the loader have to be modifed in every DSM version update, so it is a little scary

 

Thats not true, as long as the kernel version remains the same the updates should be painless. 

 

DSM6.  – Linux Kernel 4.4.59+

DSM7 7.0.1 so far up to Version: 7.1.1-42962. – Linux Kernel 4.4.180+

 

So as long as you are on the same kernel version the updates are painless. Its only when you move to a new kernel version. And this is about to happen at 7.2.

 

So if you create the TCRP Friend loader or ARPL you should be fine from 7.0.1 -> 7.1.1 U4 (until now)

 

Bear in mind though that some software and features stopped working on 7.x 

 

A lot of users have created youtube step-by-step guides for ARPL and TCRP.

 

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

15 minutes ago, pocopico said:

So as long as you are on the same kernel version the updates are painless. Its only when you move to a new kernel version. And this is about to happen at 7.2.

I guess the painless ones, does not need to do anything but apply the .pat and that's it? Or is there something more to do?

But yep, I wanna know exactly how to proceed in the ones that are a pain. Exactly the guide I am looking for.

 

15 minutes ago, pocopico said:

Bear in mind though that some software and features stopped working on 7.x 

Could you be more explicit? What exactly stopped working? Did happened in all the 7.x versions or just from an specific subversion?

 

15 minutes ago, pocopico said:

A lot of users have created youtube step-by-step guides for ARPL and TCRP.

I don't need a guide for installing ARPL or TCRP. But a guide once you have the loader working, to update from one version to subsequential versions (being a pain or painless udpate, for both).

 

Thanks again @pocopico for your replies.

Edited by ed_co
Link to comment
Share on other sites

21 hours ago, ed_co said:

Could you be more explicit? What exactly stopped working? Did happened in all the 7.x versions or just from an specific subversion?

 

I believe what he meant is that not all apps that used to work in DSM6 will work in DSM7.

Some of them reached EOL and others were replaced.

 

I don't have a list (probably Synology published one at some point), but I know that, for instance, there was a Dokuwiki package available in DSM6 Package Center and they stopped offering the package in DSM7 (You need to install DW manually on your Synology NAS since DSM7 if you want it).

AFAIR there was also some major changes for Synology Photo and related apps.

 

Best,

-a-

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

×
×
  • Create New...