Automated RedPill Loader (ARPL)

[EffortLessDev]

The day before wjz304 decided to stop his work, someone reported a new issue on his GitHub and asked why modules were not open source on his repo.  There was reference to something that was named "secret".  You could see it called out in the code.

 

I didn't see what wjz304 responded to him, but that seemed to upset him to the point of leaving the scene.  I don't want to believe wjz304 did something malicious, but he immediately closed everything and said he was accused of not disclosing driver source code.  It was an extreme reaction.  

 

I'm hoping @wjz304 could expand more on the topic since the question seemed fair.  

[vista1967]

Hello,

I tried the latest version 23.11.30  of ARC but I have a problem that my network card is not recognized (Realtek RTL8111H).

I am interested if anyone has a solution to this problem?

Thank you.

[Peter Suh]

1 hour ago, vista1967 said:

Hello,

I tried the latest version 23.11.30  of ARC but I have a problem that my network card is not recognized (Realtek RTL8111H).

I am interested if anyone has a solution to this problem?

Thank you.

 

Try switching to my TCRP-mshell.
This is the same Redfill-based loader that was previously based on ARPL.
Both loaders are compatible with each other.
https://github.com/PeterSuh-Q3/tinycore-redpill/releases/tag/v1.0.0.0

 

After switching to this loader, please tell me exactly which network module it points to.
I think it's probably r8168.

 

I also suggest this to @Flautista1988, another user who asked the same question.
If there is a problem with r8168 or r8169 in the integrated module of TCRP-mshell, we will switch to the final version of the module of rr.

[vista1967]

If this is of value to you for information when I run Arc?
Thanks, I'll try you too Loader TCRP-mshell.

 

[Peter Suh]

2 minutes ago, vista1967 said:

If this is of value to you for information when I run Arc?
Thanks, I'll try you too Loader TCRP-mshell.

 

 

ARC does not show the NIC module name at all.
Like RR, mshell also always displays the NIC module name.
You will know right away once you install it.

[vista1967]

I will test and report back.

Thank you

[Peter Suh]

1 hour ago, vista1967 said:

If this is of value to you for information when I run Arc?
Thanks, I'll try you too Loader TCRP-mshell.

 

 

I'm sorry. I think I have dyslexia.
I see r8168 in ARC. lol

[Flautista1988]

5 hours ago, Peter Suh said:

 

Try switching to my TCRP-mshell.
This is the same Redfill-based loader that was previously based on ARPL.
Both loaders are compatible with each other.
https://github.com/PeterSuh-Q3/tinycore-redpill/releases/tag/v1.0.0.0

 

After switching to this loader, please tell me exactly which network module it points to.
I think it's probably r8168.

 

I also suggest this to @Flautista1988, another user who asked the same question.
If there is a problem with r8168 or r8169 in the integrated module of TCRP-mshell, we will switch to the final version of the module of rr.

Ok, in RR, DSM installation is fine and successful, but in ARC, the loader config menu boot fine, and i can config the loader fine. But when loader boot to DSM, the network card did not respond, no appear in wnetwatcher, no ping, nothing. My network card is onboard realtek R8168.

In ARC if config a DS923+ the loader boot successful, and works fine 😶

Edited December 1, 2023 by Flautista1988

[wjz304]

12 hours ago, EffortLessDev said:

The day before wjz304 decided to stop his work, someone reported a new issue on his GitHub and asked why modules were not open source on his repo.  There was reference to something that was named "secret".  You could see it called out in the code.

 

I didn't see what wjz304 responded to him, but that seemed to upset him to the point of leaving the scene.  I don't want to believe wjz304 did something malicious, but he immediately closed everything and said he was accused of not disclosing driver source code.  It was an extreme reaction.  

 

I'm hoping @wjz304 could expand more on the topic since the question seemed fair.  

 

I think I need to explain:

 

Yes, I was a little extreme at the time, because I roughly guessed who that person was.
(A brand new account, so to speak, the account created specifically for the purpose of creating that issue) This is what makes me angry. 
So when he mentioned the open source agreement, I didn't think much about it. Since I can't publish it because the second release under the protocol requires public modification, I delete the repository and don't publish it.

 

If someone else asks, I may not do this, and may even invite him to revise it together.

 

In addition, as we all know, a month ago they were public. I changed it to non-public because 1. I unpacked the official drivers of all architectures and backed them up on github. Although this is nothing, I still don’t want to be retrieved. 2. I saw some very unhappy things( and don’t want to say more, related to the person who created the issue)

 

In addition, and what I said on github, so I won’t go into details here.

 

If anyone thinks I did something, just don't use it.
From beginning to end, few people have seen me recommending others to use RR, because it doesn’t do me any good whether you use it or not. On the contrary, the more people use it, the more uneasy I feel. I am always afraid of being targeted by syno officials.

 

But I just have a bit of perfectionism and always want to do better.

 

 

[MichelD]

11 hours ago, wjz304 said:

 

I think I need to explain:

 

Yes, I was a little extreme at the time, because I roughly guessed who that person was.
(A brand new account, so to speak, the account created specifically for the purpose of creating that issue) This is what makes me angry. 
So when he mentioned the open source agreement, I didn't think much about it. Since I can't publish it because the second release under the protocol requires public modification, I delete the repository and don't publish it.

 

If someone else asks, I may not do this, and may even invite him to revise it together.

 

In addition, as we all know, a month ago they were public. I changed it to non-public because 1. I unpacked the official drivers of all architectures and backed them up on github. Although this is nothing, I still don’t want to be retrieved. 2. I saw some very unhappy things( and don’t want to say more, related to the person who created the issue)

 

In addition, and what I said on github, so I won’t go into details here.

 

If anyone thinks I did something, just don't use it.
From beginning to end, few people have seen me recommending others to use RR, because it doesn’t do me any good whether you use it or not. On the contrary, the more people use it, the more uneasy I feel. I am always afraid of being targeted by syno officials.

 

But I just have a bit of perfectionism and always want to do better.

 

 

 

We very much appreciate your work and hope you'll change your mind. All the best.

[vista1967]

21 hours ago, Peter Suh said:

 

Try switching to my TCRP-mshell.
This is the same Redfill-based loader that was previously based on ARPL.
Both loaders are compatible with each other.
https://github.com/PeterSuh-Q3/tinycore-redpill/releases/tag/v1.0.0.0

 

After switching to this loader, please tell me exactly which network module it points to.
I think it's probably r8168.

 

I also suggest this to @Flautista1988, another user who asked the same question.
If there is a problem with r8168 or r8169 in the integrated module of TCRP-mshell, we will switch to the final version of the module of rr.

@Peter Suh

I installed the loader M-shell last night, it didn't want to on the first try, but I succeeded on the second try. My network card is recognized and works without problems. Thanks a lot for the advice!

[AlexeyN]

20 часов назад, wjz304 сказал:

But I just have a bit of perfectionism and always want to do better.

 

And because of that it was a great project. I really hope that a little later we will be able to remove the word was

[blindspot]

20 hours ago, wjz304 said:

 

I think I need to explain:

 

Yes, I was a little extreme at the time, because I roughly guessed who that person was.
(A brand new account, so to speak, the account created specifically for the purpose of creating that issue) This is what makes me angry. 
So when he mentioned the open source agreement, I didn't think much about it. Since I can't publish it because the second release under the protocol requires public modification, I delete the repository and don't publish it.

 

If someone else asks, I may not do this, and may even invite him to revise it together.

 

In addition, as we all know, a month ago they were public. I changed it to non-public because 1. I unpacked the official drivers of all architectures and backed them up on github. Although this is nothing, I still don’t want to be retrieved. 2. I saw some very unhappy things( and don’t want to say more, related to the person who created the issue)

 

In addition, and what I said on github, so I won’t go into details here.

 

If anyone thinks I did something, just don't use it.
From beginning to end, few people have seen me recommending others to use RR, because it doesn’t do me any good whether you use it or not. On the contrary, the more people use it, the more uneasy I feel. I am always afraid of being targeted by syno officials.

 

But I just have a bit of perfectionism and always want to do better.

 

 

I'm very sad because of this, he is the only dev that kept dsm 6.2.4 alive and it is also very frustrating thinking that maybe some other dev is involved in this situation. (He did said that someone wanted the source of the drivers he had). It really saddens me. But he deserves a break and hope he will be back someday. Thank you for your amazing work.

[RedCat]

Hi,

 

I need help. The story:

I have xpenology 7.2.1 under proxmox, TRPC loader. I have 5 hdd (100 gb virtual for system, 3 in raid, 1 single). It worked properly. I did a restart, it restarted, but i cant login, xpeno says: The system getting ready, please log in later.

Restart, result is same.

1. I tired to renstall loader, dont boot xpeno.

2. I changed loader to ARPL RR 23.11.10. I maked new loader.

3. ARPL found the xpeno, repaired it. It booting.

4. I can login the system, but said system partitions are broken, fix it. I push "fix" it.

5. I try to reboot. And dont boot again.

6. In loader I choose "force reninstall DSM"

7. repeat again from 3.

Sometimes it dont show partitons errors, but I go to partiton manager, i see, it repair itself.

It work until first reboot, because after fix, it cant boot again.

how can I fix this loop?

Edited December 3, 2023 by RedCat

[Orphée]

@RedCat it has nothing to do with the loader ARPL/RR itself but with a DSM issue.

 

You should create a "help" thread dedicated to your issue.

Here it will be lost between other answers as it is offtopic.

[abced]

On 12/1/2023 at 9:30 PM, wjz304 said:

 

I think I need to explain:

 

Yes, I was a little extreme at the time, because I roughly guessed who that person was.
(A brand new account, so to speak, the account created specifically for the purpose of creating that issue) This is what makes me angry. 
So when he mentioned the open source agreement, I didn't think much about it. Since I can't publish it because the second release under the protocol requires public modification, I delete the repository and don't publish it.

 

If someone else asks, I may not do this, and may even invite him to revise it together.

 

In addition, as we all know, a month ago they were public. I changed it to non-public because 1. I unpacked the official drivers of all architectures and backed them up on github. Although this is nothing, I still don’t want to be retrieved. 2. I saw some very unhappy things( and don’t want to say more, related to the person who created the issue)

 

In addition, and what I said on github, so I won’t go into details here.

 

If anyone thinks I did something, just don't use it.
From beginning to end, few people have seen me recommending others to use RR, because it doesn’t do me any good whether you use it or not. On the contrary, the more people use it, the more uneasy I feel. I am always afraid of being targeted by syno officials.

 

But I just have a bit of perfectionism and always want to do better.

 

 

 

Thank you for your work. Can you considering leaving the repo as a public archive? That way we can access all the knowledge that was shared in the issues.

 

Thanks

[RedCat]

9 hours ago, Orphée said:

@RedCat it has nothing to do with the loader ARPL/RR itself but with a DSM issue.

 

You should create a "help" thread dedicated to your issue.

Here it will be lost between other answers as it is offtopic.

Oh, thx. But where? I cant find correct help topic.

[Lestat_TI]

On 12/1/2023 at 1:52 PM, Flautista1988 said:

Ok, in RR, DSM installation is fine and successful, but in ARC, the loader config menu boot fine, and i can config the loader fine. But when loader boot to DSM, the network card did not respond, no appear in wnetwatcher, no ping, nothing. My network card is onboard realtek R8168.

In ARC if config a DS923+ the loader boot successful, and works fine 😶

 

For me there's no loader working anymore (Intel H61). I have a R8111C NIC (R8168) and the only loader that have this module is the ARC but it won't suport bromolow.

Anyone can help me how do i add this module to a ARPL loader?

[Lestat_TI]

5 hours ago, Lestat_TI said:

 

For me there's no loader working anymore (Intel H61). I have a R8111C NIC (R8168) and the only loader that have this module is the ARC but it won't suport bromolow.

Anyone can help me how do i add this module to a ARPL loader?

I still tryng many loaders and options on m-shell too like module process DDSML, EUDEV or prod vs Dev 

i even get able to install de DSM but after the 10 minuts count and reboot the lights of the NIC simple turn off!

 

Sorry for my bad english!

tnks for the attention!

[Peter Suh]

47 minutes ago, Lestat_TI said:

I still tryng many loaders and options on m-shell too like module process DDSML, EUDEV or prod vs Dev 

i even get able to install de DSM but after the 10 minuts count and reboot the lights of the NIC simple turn off!

 

Sorry for my bad english!

tnks for the attention!

 

 

mshell has a separate topic dedicated to it.
I don't think it's appropriate to discuss it in the ARPL topic.

 

 

 

[Rick4]

On 12/1/2023 at 11:37 AM, vista1967 said:

Hello,

I tried the latest version 23.11.30  of ARC but I have a problem that my network card is not recognized (Realtek RTL8111H).

I am interested if anyone has a solution to this problem?

Thank you.

You can add addons and modules in menu, tried / checked that driver exist? 

[vista1967]

52 minutes ago, Rick4 said:

You can add addons and modules in menu, tried / checked that driver exist? 

Hello, thank you for your answer!
I think the driver exists and is installed, I can see it on the sysinfo and network card led (yellow on the left and green on the right were flashing) everything is fine until I start the DSM kernel, from then on my card network is no longer recognized and only the yellow LED flashes to see the photos.
Which addon do you think I should add?

[djkjd]

HI hello can you help? Thank you very much, my motherboard ASUS P9A-I/C2750/SAS/4L/disk controller Marvell 88SE9485, using two loaders tried 3615 3622
https://github.com/PeterSuh-Q3/tinycore-redpill/releases/tag/v1.0.0.0
The 9485 driver cannot be correctly identified. What should I do to correctly identify it?

NAS:/$ lspci -vmm
Slot:   00:00.0
Class:  Class 0600
Vendor: Vendor 8086
Device: Device 1f01
Rev:    02

Slot:   00:01.0
Class:  Class 0604
Vendor: Vendor 8086
Device: Device 1f10
Rev:    02

Slot:   00:02.0
Class:  Class 0604
Vendor: Vendor 8086
Device: Device 1f11
Rev:    02

Slot:   00:03.0
Class:  Class 0604
Vendor: Vendor 8086
Device: Device 1f12
Rev:    02

Slot:   00:04.0
Class:  Class 0604
Vendor: Vendor 8086
Device: Device 1f13
Rev:    02

Slot:   00:0e.0
Class:  Class 0600
Vendor: Vendor 8086
Device: Device 1f14
SVendor:        Unknown vendor 8086
SDevice:        Device 0000
Rev:    02

Slot:   00:0f.0
Class:  Class 0806
Vendor: Vendor 8086
Device: Device 1f16
SVendor:        Unknown vendor 8086
SDevice:        Device 0000
Rev:    02

Slot:   00:13.0
Class:  Class 0880
Vendor: Vendor 8086
Device: Device 1f15
SVendor:        Unknown vendor 8086
SDevice:        Device 0000
Rev:    02

Slot:   00:14.0
Class:  Class 0200
Vendor: Vendor 8086
Device: Device 1f41
SVendor:        Unknown vendor 1043
SDevice:        Device 8638
Rev:    03

Slot:   00:14.1
Class:  Class 0200
Vendor: Vendor 8086
Device: Device 1f41
SVendor:        Unknown vendor 1043
SDevice:        Device 8638
Rev:    03

Slot:   00:14.2
Class:  Class 0200
Vendor: Vendor 8086
Device: Device 1f41
SVendor:        Unknown vendor 1043
SDevice:        Device 8638
Rev:    03

Slot:   00:14.3
Class:  Class 0200
Vendor: Vendor 8086
Device: Device 1f41
SVendor:        Unknown vendor 1043
SDevice:        Device 8638
Rev:    03

Slot:   00:16.0
Class:  Class 0c03
Vendor: Vendor 8086
Device: Device 1f2c
SVendor:        Unknown vendor 1043
SDevice:        Device 8646
Rev:    02
ProgIf: 20

Slot:   00:18.0
Class:  Class 0106
Vendor: Vendor 8086
Device: Device 1f32
SVendor:        Unknown vendor 1043
SDevice:        Device 8646
Rev:    02
ProgIf: 01

Slot:   00:1f.0
Class:  Class 0601
Vendor: Vendor 8086
Device: Device 1f38
SVendor:        Unknown vendor 1043
SDevice:        Device 8646
Rev:    02

Slot:   00:1f.3
Class:  Class 0c05
Vendor: Vendor 8086
Device: Device 1f3c
SVendor:        Unknown vendor 1043
SDevice:        Device 8646
Rev:    02

Slot:   01:00.0
Class:  Class 0104
Vendor: Vendor 1b4b
Device: Device 9485
SVendor:        Unknown vendor 1043
SDevice:        Device 8635
Rev:    c3

Slot:   02:00.0
Class:  Class 0104
Vendor: Vendor 1b4b
Device: Device 9485
SVendor:        Unknown vendor 1043
SDevice:        Device 8635
Rev:    c3

Slot:   04:00.0
Class:  Class 0604
Vendor: Vendor 1a03
Device: Device 1150
Rev:    02

Slot:   05:00.0
Class:  Class 0300
Vendor: Vendor 1a03
Device: Device 2000
SVendor:        Unknown vendor 1043
SDevice:        Device 84eb
Rev:    21

Slot:   0001:09:00.0
Class:  Class 0106
Vendor: Vendor 1b4b
Device: Device 9235
Rev:    11
ProgIf: 01

Slot:   0001:0c:00.0
Class:  Class 0106
Vendor: Vendor 1b4b
Device: Device 9235
Rev:    11
ProgIf: 01

 

NAS:/$ lspci -k
0000:00:00.0 Class 0600: Device 8086:1f01 (rev 02)
0000:00:01.0 Class 0604: Device 8086:1f10 (rev 02)
        Kernel driver in use: pcieport
0000:00:02.0 Class 0604: Device 8086:1f11 (rev 02)
        DeviceName:  Onboard IGD
        Kernel driver in use: pcieport
0000:00:03.0 Class 0604: Device 8086:1f12 (rev 02)
        Kernel driver in use: pcieport
0000:00:04.0 Class 0604: Device 8086:1f13 (rev 02)
        Kernel driver in use: pcieport
0000:00:0e.0 Class 0600: Device 8086:1f14 (rev 02)
        Subsystem: Device 8086:0000
0000:00:0f.0 Class 0806: Device 8086:1f16 (rev 02)
        Subsystem: Device 8086:0000
0000:00:13.0 Class 0880: Device 8086:1f15 (rev 02)
        Subsystem: Device 8086:0000
0000:00:14.0 Class 0200: Device 8086:1f41 (rev 03)
        Subsystem: Device 1043:8638
        Kernel driver in use: igb
0000:00:14.1 Class 0200: Device 8086:1f41 (rev 03)
        Subsystem: Device 1043:8638
        Kernel driver in use: igb
0000:00:14.2 Class 0200: Device 8086:1f41 (rev 03)
        Subsystem: Device 1043:8638
        Kernel driver in use: igb
0000:00:14.3 Class 0200: Device 8086:1f41 (rev 03)
        Subsystem: Device 1043:8638
        Kernel driver in use: igb
0000:00:16.0 Class 0c03: Device 8086:1f2c (rev 02)
        Subsystem: Device 1043:8646
        Kernel driver in use: ehci-pci
0000:00:18.0 Class 0106: Device 8086:1f32 (rev 02)
        Subsystem: Device 1043:8646
        Kernel driver in use: ahci
0000:00:1f.0 Class 0601: Device 8086:1f38 (rev 02)
        Subsystem: Device 1043:8646
        Kernel driver in use: lpc_ich
0000:00:1f.3 Class 0c05: Device 8086:1f3c (rev 02)
        Subsystem: Device 1043:8646
        Kernel driver in use: i801_smbus
0000:01:00.0 Class 0104: Device 1b4b:9485 (rev c3)
        Subsystem: Device 1043:8635
0000:02:00.0 Class 0104: Device 1b4b:9485 (rev c3)
        Subsystem: Device 1043:8635
0000:04:00.0 Class 0604: Device 1a03:1150 (rev 02)
0000:05:00.0 Class 0300: Device 1a03:2000 (rev 21)
        Subsystem: Device 1043:84eb
0001:09:00.0 Class 0106: Device 1b4b:9235 (rev 11)
0001:0c:00.0 Class 0106: Device 1b4b:9235 (rev 11)
 

 

NAS:/$ lspci -k | grep 'Kernel driver'
        Kernel driver in use: pcieport
        Kernel driver in use: pcieport
        Kernel driver in use: pcieport
        Kernel driver in use: pcieport
        Kernel driver in use: igb
        Kernel driver in use: igb
        Kernel driver in use: igb
        Kernel driver in use: igb
        Kernel driver in use: ehci-pci
        Kernel driver in use: ahci
        Kernel driver in use: lpc_ich
        Kernel driver in use: i801_smbus

 

MVSAS driver not loaded

 

 

 

 

 

 

 

 

dmesg linuxrc.syno.log

Edited December 4, 2023 by djkjd

[Flautista1988]

To those who have had problems with Realtek network cards. Have you tried booting the computer by EFI/UEFI?

Booting with UEFI, everything is now working like a charm

[vista1967]

3 hours ago, Flautista1988 said:

To those who have had problems with Realtek network cards. Have you tried booting the computer by EFI/UEFI?

Booting with UEFI, everything is now working like a charm

Thanks for your information, it doesn't work for me, I tried everything as explained on the ARC Wiki site, but it doesn't work.
I tested on 2 platforms Intel and AMD, the same network card r8168 cannot work with DS3622xs+ but it can work with DS923+ like yours, it does not work from the moment the DSM kernel is started, the same problem and I don't understand anything.
Avec RR and ARPL M-shell I have no problems.

Edited December 5, 2023 by vista1967