Jump to content
XPEnology Community

RedPill - the new loader for 6.2.4 - Discussion


Recommended Posts

Thanks a lot for your answer but that's not the case, I did several tests and it happens just when using my SSD Synology 6.2.3 disk. Furthermore if I disable the SATA port in the BIOS find.synology.com is able to detect the DS918+ in the next reboot. But obviously it says that there is no disk and ask me to insert one.

 

Obviously hot plug the disk in a NUC that is not intended for that is too risky.

 

Apparently something is happening when the Redpill bootloader finds a working system in the system disks that stops the boot process.

Link to comment
Share on other sites

8 hours ago, Peter Suh said:

 

@dolbycat

 

The tar command recognizes that the .pat file cannot be unpacked.
How did you get past this problem?
The tar version in my xubuntu is as follows and cannot be upgraded.

 

tar --version

tar (GNU tar) 1.30

Copyright (C) 2017 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

----------------------------------------------------------------------------------------

#] Unpacking /home/toolc/redpill-load/cache/ds918p_42621.pat file to /home/toolc/redpill-load/build/1648993060/pat-ds918p_42621-unpacked... [ERR]
[!] Failed to unpack tar

 

/bin/tar: This does not look like a tar archive
/bin/tar: Skipping to next header
/bin/tar: Exiting with failure status due to previous errors

*** Process will exit ***

 

 

chmod +x buildpat-918p-7.1-42621.sh

 

./buildpat-918p-7.1-42621.sh

 

 

Link to comment
Share on other sites

18 hours ago, Peter Suh said:

 

@dolbycat

 

The tar command recognizes that the .pat file cannot be unpacked.
How did you get past this problem?
The tar version in my xubuntu is as follows and cannot be upgraded.

 

tar --version

tar (GNU tar) 1.30

Copyright (C) 2017 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

----------------------------------------------------------------------------------------

#] Unpacking /home/toolc/redpill-load/cache/ds918p_42621.pat file to /home/toolc/redpill-load/build/1648993060/pat-ds918p_42621-unpacked... [ERR]
[!] Failed to unpack tar

 

/bin/tar: This does not look like a tar archive
/bin/tar: Skipping to next header
/bin/tar: Exiting with failure status due to previous errors

*** Process will exit ***

 

Just read lol. I create a script to unpack the pat file. You cannot unpack it with tar command directly because it's encrypted. The method to bypass it is to use an older pat file, like in the script. Thx to @dogodefi :)

  • Like 2
Link to comment
Share on other sites

12 hours ago, dolbycat said:

 

chmod +x buildpat-918p-7.1-42621.sh

 

./buildpat-918p-7.1-42621.sh

 

 

 

 

I had a special reason at work today, so I remotely accessed my home's synology.
It was an environment where Native Ubuntu was not available.
So, I installed Ubuntu as a docker component in the Synology and also used two synology custom Linux,

which seems to be an unsuitable environment for performing buildpat.

I created a /buildpat directory in the root and ran a shell, but I kept getting out of space messages.
Eventually, I returned home and finally succeeded in building within VM Xubuntu in the Mac-installed VirtualBox.
The built results are as follows.
During the build process, I saw the process of finding the lib below the relative path.../usr/lib.
I moved the /buildpat folder to the root in the same way.

 

537003518_2022-04-046_57_07.thumb.png.b1c657430c9b7fd2bed8d7744a10c395.png

Edited by Peter Suh
Link to comment
Share on other sites

On 4/1/2022 at 5:36 PM, RedwinX said:

Hi,

 

for those wants 918/920 7.1 : https://github.com/RedwinX/redpill-load

Just execute the script into buildpat folder first :)

 

 

nice i just made de mistake to update my 3615 with 7.1 instead of 7.0.1 update 3... i will try to adapt this to mine to get my hands on my nas again.

did pocopico provide any time when should be available? otherwise i might just wait a bit.

Link to comment
Share on other sites

3 hours ago, Peter Suh said:

 

 

I had a special reason at work today, so I remotely accessed my home's synology.
It was an environment where Native Ubuntu was not available.
So, I installed Ubuntu as a docker component in the Synology and also used two synology custom Linux,

which seems to be an unsuitable environment for performing buildpat.

I created a /buildpat directory in the root and ran a shell, but I kept getting out of space messages.
Eventually, I returned home and finally succeeded in building within VM Xubuntu in the Mac-installed VirtualBox.
The built results are as follows.
During the build process, I saw the process of finding the lib below the relative path.../usr/lib.
I moved the /buildpat folder to the root in the same way.

 

537003518_2022-04-046_57_07.thumb.png.b1c657430c9b7fd2bed8d7744a10c395.png

 

Here are the final success results and installation guides.

 

 

Link to comment
Share on other sites

Hi All,

 

I'm currently using Jun's bootloader for 6.2.3, I'm thinking to upgrade to DSM7, hence thinking to use redpill bootloader.

 

To change the redpill bootloader, I would need to using another usb drive and write the redpill image into it correct? But is my current file in my existing NAS will be intact? 

 

My current 6.2.3 is running intel 11th gen i5.

 

Thanks.

Edited by TEH YIH ANN
Link to comment
Share on other sites

4 hours ago, TEH YIH ANN said:

Hi All,

 

I'm currently using Jun's bootloader for 6.2.3, I'm thinking to upgrade to DSM7, hence thinking to use redpill bootloader.

 

To change the redpill bootloader, I would need to using another usb drive and write the redpill image into it correct? But is my current file in my existing NAS will be intact? 

 

My current 6.2.3 is running intel 11th gen i5.

 

Thanks.

If you build a red pill loader successfully (based on your system specs), boot into it, it should migrate your dsm 623 to dsm 7 as a normal Synology would. Just like putting those drives into a new Synology.

Link to comment
Share on other sites

I found a problem. When I installed DSM7.0.1 on the H610 and B660 motherboards, it was prompted that SATA1234 was disabled. After analysis, I came to the conclusion that perhaps the SATA controllers of H610 and B660 were castrated from the 8 SATA of Z690 and disabled. Caused by 4 SATA, so I can't install DSM because it always has 4 non-existing SATA ports disabled, hope H610, B660 are supported

Link to comment
Share on other sites

Heyyy

 

As a long time xpenology user I'm happy, but also sureprised, to hear about this project. I'm running xpenology virtualized on 3 different devices, all recognized as genuine devices using mac adresses and serial numbers that are genuine. So basically everything works like real synology boxes of 6.2.3 - all using image DS3517xs

 

I have held off any experiments with my devices but now since finding this project I'm interested in trying DSM 7.x soon..

Reading the first post does not give a lot of information ont he state of this mproject and the stability of running a xpenology install for DSM 7.x

 

So my initial question, without reading through all 158 pages of this thread is: Where can I get a good overall update of how good state this project is in. Is it yet recommended to run on "production" devices, as stable as I've been running xpenology DSM 6.x for several years and with awesome uptime on these virtualized DS3617xs devices?

 

Should I hold off just a bit longer? Are there any good tutorials in how to test this out anywhere?

 

Thanks for pointing me in the right direction and giving some overall summary of the current state.

 

Best regards and thanks for all the hard work!

Link to comment
Share on other sites

51 minutes ago, Jamzor said:

Heyyy

 

As a long time xpenology user I'm happy, but also sureprised, to hear about this project. I'm running xpenology virtualized on 3 different devices, all recognized as genuine devices using mac adresses and serial numbers that are genuine. So basically everything works like real synology boxes of 6.2.3 - all using image DS3517xs

 

I have held off any experiments with my devices but now since finding this project I'm interested in trying DSM 7.x soon..

Reading the first post does not give a lot of information ont he state of this mproject and the stability of running a xpenology install for DSM 7.x

 

So my initial question, without reading through all 158 pages of this thread is: Where can I get a good overall update of how good state this project is in. Is it yet recommended to run on "production" devices, as stable as I've been running xpenology DSM 6.x for several years and with awesome uptime on these virtualized DS3617xs devices?

 

Should I hold off just a bit longer? Are there any good tutorials in how to test this out anywhere?

 

Thanks for pointing me in the right direction and giving some overall summary of the current state.

 

Best regards and thanks for all the hard work!

 

To keep it simple... ThorGroup, the developer(s) of RedPill never came back since last October I guess. At the time the project was in a late alpha stage going to early beta stage.

They heavily tested RedPill on Proxmox and at the time everything was working fine and stable.

After that the community took over...

 

Is it recommended to run on "production"? I will answer the same way as I did to others before you. Even is Jun's Loader or RedPill loader or whatever loader the risk that something might go wrong is always there... but as you said Jun's loader has been running stable for me, you and many others for years. Same goes for RedPill. You can install it to a VM or as Baremetal it works.

 

Now about directions: You can find here the amazing work done by @pocopico and many others that helped him to make it super easy to install the red pill loader and add additional extensions and many other goodies and also a detailed guide written by @Peter Suh

 

 

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

@Jamzor @gadreel summed it up pretty good. I will add many people are running dsm7, but use common sense and always keep backup of data, since the whole project is community driven and mistakes are found and fixed almost daily is seems. I am running 2 instances on baremetal, with minor issues on 7.1, 7.0.1 was maybe more stable? not sure.... then again it could all be me! 😆

 

I also have several real synology devices, and all seem to interact with each other just fine. (psst! do it, it'll be fine)

 

Great advice and post from gadreel with direct links and terrific explanation.

Edited by phone guy
Link to comment
Share on other sites

8 hours ago, Jamzor said:

Heyyy

 

As a long time xpenology user I'm happy, but also sureprised, to hear about this project. I'm running xpenology virtualized on 3 different devices, all recognized as genuine devices using mac adresses and serial numbers that are genuine. So basically everything works like real synology boxes of 6.2.3 - all using image DS3517xs

 

I have held off any experiments with my devices but now since finding this project I'm interested in trying DSM 7.x soon..

Reading the first post does not give a lot of information ont he state of this mproject and the stability of running a xpenology install for DSM 7.x

 

So my initial question, without reading through all 158 pages of this thread is: Where can I get a good overall update of how good state this project is in. Is it yet recommended to run on "production" devices, as stable as I've been running xpenology DSM 6.x for several years and with awesome uptime on these virtualized DS3617xs devices?

 

Should I hold off just a bit longer? Are there any good tutorials in how to test this out anywhere?

 

Thanks for pointing me in the right direction and giving some overall summary of the current state.

 

Best regards and thanks for all the hard work!

 

 

I've been a long-time user of Jun Loader, and I knew Red-pill existed, but I used it in earnest around mid-February this year.

 

Here's how I feel about using it personally.

Among all platforms, ds3622xs+, which started to be supported from Red-pill, seems to be the most stable.

Compared to 7.0.1 when there was an S.M.A.R.T issue in HBA support, 7.1 is now in perfect condition because even that issue has been resolved.

 

I remember adjusting the extra driver because there was an issue with HBA in Jun loader and ds918+.
I think I will probably keep up with continuous DSM updates due to security issues while using them.

 

The reason why I can try a bold migration is because there is another backup Xpheology. (This backup still uses the JUN loader.)
I think it is the best way to test and approach it conservatively and safely, so I recommend it like this.

Edited by Peter Suh
Link to comment
Share on other sites

6 hours ago, Hemps said:

Those that are on DSM 7.1, did you just update from within DSM or do you have to build it from Tinycore?

 

You can build a 7.1 loaded and install fresh 7.1 from the ground up, as in fresh disk just boot and install 7.1 when you first log in to yourip:5000

 

If you upgrading and existing set of hdds, I think the correct process would be to install 7.1 from inside dsm (control panel>update>manual install dsm 7.1)

on the reboot, replace your current usb loader with the 7.1 usb loader you successfully created earlier. I believe that would be the correct way to upgrade, but I did not upgrade directly from dsm623 to dsm7.1, I went from Jun104b dsm623 to RP dsm701 to RP dsm7.1, as they became available.

Link to comment
Share on other sites

So I'm currently running DSM 7.0.1-42218 for DS3615xs on my HP MicroServer Gen 8.

I remember creating the USB loader using a modified repository and I had to insert the drivers for the internal ethernet controller as well.

What would be the easiest way to upgrade to 7.1 without losing data?

Link to comment
Share on other sites

59 minutes ago, MastaG said:

So I'm currently running DSM 7.0.1-42218 for DS3615xs on my HP MicroServer Gen 8.

I remember creating the USB loader using a modified repository and I had to insert the drivers for the internal ethernet controller as well.

What would be the easiest way to upgrade to 7.1 without losing data?

This guide was mentioned earlier in this thread:

 

Hope it helps.

Link to comment
Share on other sites

Hi guys,

 

I am using the 918+ ApolloLake dsm configuration. PID, VID and Mac address where set correctly. I get this error when I try to install :

 

We've detected errors on the hard drives (1, 2), and the SATA ports have also been disabled. Please shut down your DS918+ to replace or remove the hard drives and try again. 

 

I have a DESKTOP with E-2126G 16G RAM 4 HGST sata drives,the motherboard has 4 sata ports.

Edited by neevdg
Link to comment
Share on other sites

On 4/18/2022 at 3:14 PM, rojoone2 said:

This guide was mentioned earlier in this thread:

 

Hope it helps.

But will it also take into account, the custom serial numbers I've set? and the custom kernel modules for getting ethernet running on the Microserver Gen8?

Link to comment
Share on other sites

I have an AMD 3900x, using KVM hypervisor.

I am trying to spin up a DS1621+

 

Im using the below:

tinycore-redpill.v0.4.6.img for 1st SATA drive, creating a 2nd SATA drive at 40G. Boot into the tinycore, ifconfig to get IP, then ssh in to run the below commands.

sudo su
./rploader.sh update now
./rploader.sh fullupgrade now
./rploader.sh serialgen DS1621+ (copy the MAC address and using on the VM)
./rploader.sh satamap v1000-7.1.0-42661
./rploader.sh backup now
./rploader.sh build v1000-7.1.0-42661 auto
poweroff

 

With VM shutdown, I replace the MAC address with the one from above, then power the VM back on, botting from the Sata drive.

I get to 'Booting the kernel', but http://find.synology.com/ finds nothing.

Anything anyone can see I am doing wrong please?

截屏2022-04-27 01.42.55.png

Link to comment
Share on other sites

On 4/27/2022 at 12:48 AM, speedyrazor said:

I have an AMD 3900x, using KVM hypervisor.

I am trying to spin up a DS1621+

 

Im using the below:

tinycore-redpill.v0.4.6.img for 1st SATA drive, creating a 2nd SATA drive at 40G. Boot into the tinycore, ifconfig to get IP, then ssh in to run the below commands.

 

sudo su

./rploader.sh update now

./rploader.sh fullupgrade now

./rploader.sh serialgen DS1621+ (copy the MAC address and using on the VM)

./rploader.sh satamap v1000-7.1.0-42661

./rploader.sh backup now

./rploader.sh build v1000-7.1.0-42661 auto

poweroff

 

With VM shutdown, I replace the MAC address with the one from above, then power the VM back on, botting from the Sata drive.

I get to 'Booting the kernel', but http://find.synology.com/ finds nothing.

Anything anyone can see I am doing wrong please?

I got this working, with help, using this before build command, this loaded the correct drivers:

 

./rploader.sh ext v1000-7.1.0-42661 add https://raw.githubusercontent.com/pocopico/redpill-load/master/redpill-virtio/rpext-index.json

 

 

截屏2022-04-27 01.42.55.png

截屏2022-04-28 12.24.15.png

Link to comment
Share on other sites

just build the loader with 9p drivers but find some errors when loading drivers.

xpe              | Loading kmod #0 "9pnet.ko" for pocopico.v9fs (args: )
xpe              | [    5.624691] 9pnet: module has bad taint, not creating trace events
xpe              | [    5.626023] 9pnet: Installing 9P2000 support
xpe              | Loading kmod #1 "9pnet_virtio.ko" for pocopico.v9fs (args: )
xpe              | [    5.643141] 9pnet_virtio: Unknown symbol register_virtio_driver (err 0)
xpe              | [    5.644772] 9pnet_virtio: Unknown symbol unregister_virtio_driver (err 0)
xpe              | [    5.646305] 9pnet_virtio: Unknown symbol virtqueue_add_sgs (err 0)
xpe              | [    5.647698] 9pnet_virtio: Unknown symbol virtqueue_get_buf (err 0)
xpe              | [    5.649022] 9pnet_virtio: Unknown symbol virtqueue_kick (err 0)
xpe              | [    5.650337] 9pnet_virtio: Unknown symbol virtio_check_driver_offered_feature (err 0)
xpe              | [    5.652170] 9pnet_virtio: Unknown symbol register_virtio_driver (err 0)
xpe              | [    5.653604] 9pnet_virtio: Unknown symbol unregister_virtio_driver (err 0)
xpe              | [    5.655099] 9pnet_virtio: Unknown symbol virtqueue_add_sgs (err 0)
xpe              | [    5.656356] 9pnet_virtio: Unknown symbol virtqueue_get_buf (err 0)
xpe              | [    5.657601] 9pnet_virtio: Unknown symbol virtqueue_kick (err 0)
xpe              | [    5.658833] 9pnet_virtio: Unknown symbol virtio_check_driver_offered_feature (err 0)
xpe              | insmod: can't insert '9pnet_virtio.ko': unknown symbol in module, or unknown parameter
xpe              | ERROR: kernel extensions "9pnet_virtio.ko" from pocopico.v9fs failed to load
xpe              | Exit on error [99] rp ext init exec failure...

 

please make it fix for that.. 

thanks..

 

 

Link to comment
Share on other sites

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