Jump to content
XPEnology Community

RedPill - the new loader for 6.2.4 - Discussion


Recommended Posts

3 hours ago, reziel84 said:

many thanks for your support. i need to change nic from e1000e to vmxnet3 and now i'm able to find diskstation 7.0.1 in my network. i try to install .pat but at the end synology assistant give me an error. in the state there's "RECOVERABLE". if i try to recover the assistant tell me "impossible to recover systemn" but i don't understand the problem now.

please see picture below

immagine.thumb.png.a2308c917684d4c6a477b47f5033e7cb.png

 

Can you try to run the process directly via the http UI ? e.g. https://192.168.0.98 maybe we get a better result

Link to comment
Share on other sites

23 hours ago, haydibe said:

Hmm. I only see 1300, 1400 and 1500 in the mtu value list. If I enter any value above 1500, it intantly results in an error that indicates the mtu must be between 1300 and 1500. Is it because of Virtio-Io simply lacks that feature (even though I can use it on various other linux vms without issues), or is it because Synology withholds jumboframes from its consumer grade products?!  

 

@WiteWulf thank you for sharing the details :)

 

 

Jumbo frames is dependent on the hardware actually providing support. If the host's physical NIC doesn't support jumbos you won't be able to set it in the virtIO NIC, I believe. There's plenty of stuff out there if you google "virtio mtu 9000", but as I'm not familiar with virtio it doesn't make much sense to me.

Link to comment
Share on other sites

6 hours ago, asheenlevrai said:

Maybe your standard response post to people requesting images could include a link to instructions about how to build their own image (if these are available anywhere). I guess the GH from @ThorGroup? Or maybe the GH from @tossp?

(just my 2¢)

I'm very, very close to starting to write up some detailed howtos and FAQs on this, but a few things are holding me back:

- documentation is an arduous task, it needs to be kept up to date and that is time consuming. I'd need help

- the current state of this project (still not officially a beta) is such that it could change significantly at any time and render that effort pointless (this is based on what TTG have said about the intended future of the project: GUIs, bootable images to discover drivers reqs, etc.)

- TTG deliberately didn't provide step-by-step guides at this stage of the project so as to try and discourage users who aren't able to follow the existing documentation. Many *have* been able to do so, and there's a correlation between those users and the ones who are able to follow diagnostic instructions and provide detailed feedback, which is essential at this stage of the project

- this is TTG's project and I don't want to tread on their toes by going against what I've outlined above. I know there have been discussions in private between TTG and some of the "power users" in this thread where usability features have been offered ready to go and TTG have declined them

- TTG are still MIA. If there's no sign of them by the New Year I'll make a start on it, I promise

 

It would be *really* great if TTG would stick their head around the corner and say "hi", give us a little reassurance that they'll be back eventually, or even a "so long and thanks for all the fish" and give us the nod to carry on without them. Their code is extremely well written and documented, but it would need someone with serious linux kernel and driver skills to carry on active development, imho. All I can realistically offer is some documentation and FAQ maintenance.

  • Like 9
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, WiteWulf said:

I'm very, very close to starting to write up some detailed howtos and FAQs on this, but a few things are holding me back:

- documentation is an arduous task, it needs to be kept up to date and that is time consuming. I'd need help

- the current state of this project (still not officially a beta) is such that it could change significantly at any time and render that effort pointless (this is based on what TTG have said about the intended future of the project: GUIs, bootable images to discover drivers reqs, etc.)

- TTG deliberately didn't provide step-by-step guides at this stage of the project so as to try and discourage users who aren't able to follow the existing documentation. Many *have* been able to do so, and there's a correlation between those users and the ones who are able to follow diagnostic instructions and provide detailed feedback, which is essential at this stage of the project

- this is TTG's project and I don't want to tread on their toes by going against what I've outlined above. I know there have been discussions in private between TTG and some of the "power users" in this thread where usability features have been offered ready to go and TTG have declined them

- TTG are still MIA. If there's no sign of them by the New Year I'll make a start on it, I promise

 

It would be *really* great if TTG would stick their head around the corner and say "hi", give us a little reassurance that they'll be back eventually, or even a "so long and thanks for all the fish" and give us the nod to carry on without them. Their code is extremely well written and documented, but it would need someone with serious linux kernel and driver skills to carry on active development, imho. All I can realistically offer is some documentation and FAQ maintenance.

Even if I really would like that TTG to give us a sign of itself again, that will probably not happen  imho (unfortunately) If you can provide instructions, I try to help you with it, but that should happen in a separate thread and also create a thread for problems that will arise ..... This thread should be cleaned and only serve for devs, but that would have to be added in red and large in the first post by a moderator, because most of the first post persons should still read ... The far greater problem, however, will be to find someone who can and wants to continue the great work of TTG !! (just my 2¢)

Edited by Brunox
Link to comment
Share on other sites

On 9/22/2021 at 3:10 PM, apriliars3 said:

For test DS315xs with VMWare I add to global_config.json this lines:

 



{
            "id": "bromolow-7.0.1-42214",
            "platform_version": "bromolow-7.0.1-42214",
            "user_config_json": "bromolow_user_config.json",
            "docker_base_image": "debian:8-slim",
            "compile_with": "toolkit_dev",
            "redpill_lkm_make_target": "prod-v7",
            "downloads": {
                "kernel": {
                    "url": "https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/25426branch/bromolow-source/linux-4.4.x.txz/download",
                    "sha256": "af815ee065775d2e569fd7176e25c8ba7ee17a03361557975c8e5a4b64230c5b"
                },
                "toolkit_dev": {
                    "url": "https://sourceforge.net/projects/dsgpl/files/toolkit/DSM7.0/ds.bromolow-7.0.dev.txz/download",
                    "sha256": "a5fbc3019ae8787988c2e64191549bfc665a5a9a4cdddb5ee44c10a48ff96cdd"
                }
            },
            "redpill_lkm": {
                "source_url": "https://github.com/RedPill-TTG/redpill-lkm.git",
                "branch": "master"
            },
            "redpill_load": {
                "source_url": "https://github.com/jumkey/redpill-load.git",
                "branch": "develop"
            }
        },

 

For Apollolake need to add this lines:

 

 

It's very fast and easy make a build an .img for test, only need linux (In my case use Terminal on Ubuntu):

 

1. Install Docker       



sudo apt-get update
sudo apt install docker.io

 

2. install jq & curl:       



sudo apt install jq
sudo apt install curl

 

3. download redpill-tool-chain_x86_64_v0.10 https://xpenology.com/forum/applications/core/interface/file/attachment.php?id=13072

 

4. Go to folder and permissions to .sh



cd redpill-tool-chain_x86_64_v0.10
chmod +x redpill_tool_chain.sh

 

5. If you want edit vid,pid,sn,mac:



#edit apollolake
vi apollolake_user_config.json
  
#edit bromolow 
vi bromolow_user_config.json

 

6. build img



#for apollolake
./redpill_tool_chain.sh build apollolake-7.0.1-42214 && ./redpill_tool_chain.sh auto apollolake-7.0.1-42214

#for bromolow
./redpill_tool_chain.sh build bromolow-7.0.1-42214 && ./redpill_tool_chain.sh auto bromolow-7.0.1-42214

 

then the file was in redpill-tool-chain_x86_64_v0.10/images

 

7. For VMWare I convert .img to .vmdk with StarWind V2V Converter, and then add to Virtual Machine like sata. Also, change ethernet0.VirtualDeb = "e1000" to "e1000e on file .vmx

 

Thanks ThorGroup for the great work

photo_2021-09-22_14-50-27.jpg

global_config.json 8.09 kB · 208 downloads

For anyone looking for a tutorial, I point you to this post from @apriliars3. This is the closest your will get on a step by step and helps you setup the linux build machine (what libraries and packages are needed).

 

There are multiple GH forks of the main repo from @ThorGroup. I am a fairly experienced developer (having done coding for better part of 20+ years including messing around heavily with docker and several other framework). In spite of that, I couldn't get any of the forks to work and spent better part of 2 weeks to recover everything without data loss (had a backup but still took it as a challenge to recover without reinstalling everything). I finally had success with @tossp's fork. It worked perfectly for me in the end.

 

But, throwing the above in here as caution - this project is not ready yet for someone who is not willing to roll up the sleeves and also go through some kind of exploring the unknowns if things don't go well (including reinstalling if needed)

 

In the post I quoted above, just change the repo fork that you are using in the (such as changing "https://github.com/jumkey/redpill-load.git" to "https://github.com/tossp/redpill-load.git if you decide to use tossp's fork instead of jumkey's ). Please also change the branch to match the fork (tossp doesn't have develop branch but instead of 42218-20211021 etc). 

 

I used @tossp's tool chain as well (https://github.com/tossp/redpill-tool-chain), though any tool chain for building should work. 

 

As everyone has remarked, you need to be fairly familiar with concepts of linux vms, command lines and git repo concepts in general). This is meant for a reasonable comfortable dev at the moment as we have seen so many nuances and unique problems so far. 

 

Edited by urundai
  • Like 5
Link to comment
Share on other sites

4 hours ago, WiteWulf said:

Jumbo frames is dependent on the hardware actually providing support. If the host's physical NIC doesn't support jumbos you won't be able to set it in the virtIO NIC, I believe. There's plenty of stuff out there if you google "virtio mtu 9000", but as I'm not familiar with virtio it doesn't make much sense to me.

The equipment is not the issue :) I have Connexant 10Gbps nics and a managed 10Gbps switch that support a mtu of 9k, that's whay I was wondering why it was only not available in dsm7. With vmnet3 and june's loader on 6.2.1 it works like a charm, and the same is true for every other linux vm I am running with virtio drivers. So the problem must be specific to DSM7 on DS918 somehow... I still need to spin up a ds3615xs and test and also test if it's different with DS918+ with vmnet3 interface.

Edited by haydibe
Link to comment
Share on other sites

8 hours ago, pocopico said:

 

You need to continue and install the PAT file. 

hi pocopico.i make this screenshot after i install PAT file. when i click on blu button "RICOPRIRE", the dsm restart a countdown from 10:00 minutes to 0:0 and after it return to the same screenshot with blue button.

do you know what i mean?

Link to comment
Share on other sites

2 minutes ago, reziel84 said:

hi pocopico.i make this screenshot after i install PAT file. when i click on blu button "RICOPRIRE", the dsm restart a countdown from 10:00 minutes to 0:0 and after it return to the same screenshot with blue button.

do you know what i mean?


If you don’t have any data on the data disk, I suggest you create a new one and start over.

 

I saw from the logs that you are using Sata boot option right ?

 

Link to comment
Share on other sites

1 minute ago, pocopico said:


If you don’t have any data on the data disk, I suggest you create a new one and start over.

 

I saw from the logs that you are using Sata boot option right ?

 

correct! sata boot option.  on my esxi configuration i have sata controller 0 port 0 with redpill boot on sata controller 0 port 1 the data disk of 20gb that's black one.

ok i try right now to delete data disk and recreate a new one and i report fast my result

Link to comment
Share on other sites

58 minutes ago, pocopico said:


If you don’t have any data on the data disk, I suggest you create a new one and start over.

 

I saw from the logs that you are using Sata boot option right ?

 

 

54 minutes ago, reziel84 said:

correct! sata boot option.  on my esxi configuration i have sata controller 0 port 0 with redpill boot on sata controller 0 port 1 the data disk of 20gb that's black one.

ok i try right now to delete data disk and recreate a new one and i report fast my result

 

 

nothing changed pocopico. i just remove data disk, add a new blank one and try to reinstall but after countdown 10:00 to 0 the system is "RECOVERABLE" but i don't understand why. i just try to use another PAT file but nothing, same error occurred. it's really strange.

in attached my log file, it's seem problem with EXT4, but i don't undterstand in wich way i can solve this.

please could you give me some suggestion about it?

serial.out

Link to comment
Share on other sites

13 hours ago, haydibe said:

So the problem must be specific to DSM7 on DS918 somehow... I still need to spin up a ds3615xs and test and also test if it's different with DS918+ with vmnet3 interface.

To be clear: those screenshots I provided of a NIC with MTU set to 9000 were on a DS918+ with DSM 7.0-41890 VM, running on ESXi 7.0U2 with a VMXNET3 NIC connected to a vSwitch, set to 10GbE. The vSwitch also has its MTU set to 9000 and has two physical 1GbE NICs on the host attached using the igbn driver.

  • Thanks 1
Link to comment
Share on other sites

16 hours ago, Brunox said:

This thread should be cleaned and only serve for devs, but that would have to be added in red and large in the first post by a moderator, because most of the first post persons should still read

I will certainly speak to the mods on the forum about locking this thread and starting new ones for support outside of the Developers Room

  • Like 1
Link to comment
Share on other sites

46 minutes ago, WiteWulf said:

I will certainly speak to the mods on the forum about locking this thread and starting new ones for support outside of the Developers Room

Whit links for downloading script to make own loader and image, a sort of howto and so on 

 

Link to comment
Share on other sites

So, few hour of reading manuals and i done upgade DS918+ 7.0-41890 RedPill v0.11 to DS918+ 7.0.1-42218 RedPill v0.12.
PROXMOX

2 System HDD 28Gb on RAID0 (virtual)

2 HDD 2Tb on RAID0 (passthrough)

1 HDD 8Tb (passthrough)

1 HDD 2Tb (passthrough)

 

Now 1 hour after start and its work normal.

  • Doker with QBittorent
  • Plex
  • Apache2+php+joomla
  • Surveillance station

 

I wonder what will happen next

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

10 hours ago, WiteWulf said:

To be clear: those screenshots I provided of a NIC with MTU set to 9000 were on a DS918+ with DSM 7.0-41890 VM, running on ESXi 7.0U2 with a VMXNET3 NIC connected to a vSwitch, set to 10GbE. The vSwitch also has its MTU set to 9000 and has two physical 1GbE NICs on the host attached using the igbn driver.

Thanks for the clearification! At least I know now it is not because of DS918+ or DSM7.0 in general 😭 😭 😭 😭  Ofc the pyhysical 10gpbs interface of the Proxmox host and the linux bridge (which does what the vSwitch does) were set to mtu9000 - it works without issues for everything else. Probably it's the virtio network driver then.

 

But I kind of lost interesst as I found no way to run my Swarm Cluster with mtu9000 - even though the container networks can be set to mtu 90000... the docker0 and docker_gwbridge interface used for the communication can not be change from mtu1500 to something else. As I am not eager to have a bag full of surprises, I reverted evertything back to mtu1500.... I didn't even bother to check if my Kubernetes cluster works with mtu9000..

Edited by haydibe
Link to comment
Share on other sites

On 9/7/2021 at 4:37 PM, pocopico said:

 

I actually feel lucky to even be able to install 7.01 on my G7 that for some reason refuses to die. 😂

Hi Pocopico, do you use any add on network card on g7? I complied all four possible versions of 7/7.01 and sadly none works with g7's on board lan. I can't find the IP after boot up.


Edit: I use latest redpill-help v0.12 to compile in ubuntu 20. I have successfully compiled working images w/ext for several machines.

 

Edited by Rebutia
to provide more information
Link to comment
Share on other sites

1 hour ago, Rebutia said:

Hi Pocopico, do you use any add on network card on g7? I complied all four possible versions of 7/7.01 and sadly none works with g7's on board lan. I can't find the IP after boot up.


Edit: I use latest redpill-help v0.12 to compile in ubuntu 20. I have successfully compiled working images w/ext for several machines.

 

 

No i'm using the onboard LAN. The required extension for the LAN is tg3.

 

Unfortunatelly due to CPU limitations, only 3615xs is possible on G7/G8

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

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