RedPill - the new loader for 6.2.4 - Discussion

Orphée · October 14, 2021

1 hour ago, biubiu321 said:

really sorry my mistake.😂 You are so nice🤗

{

"extra_cmdline": {

"pid": "0x0001",

"vid": "0x46f4",

"sn": "1511LXXXXXXXX",

"mac1": "001132XXXXXX",

"DiskIdxMap": "0C",

"SataPortMap": "8",

"SasIdxMap": "0"

},

"synoinfo": {},

"ramdisk_copy": {},

"extensions": []

}

"DiskIdxMap": "1000",

"SataPortMap": "4",

coint_cho · October 14, 2021

On 10/14/2021 at 12:43 AM, coint_cho said:

Had an issue with the installation today, Gigabye GA-H81M-S2PV/Pentium G3250/4GB RAM baremetal. Tried to install DSM 7.0 with RedPill on it, drives shown up as 1 2 5 6 (Tested with DSM 6)

3 4 is technically empty but for some reason 3 4 is mapped to 5 6 and I couldn't install DSM 7, any idea what's happening and what parameters should I add to Synoinfo to remap the SATA drives?

My hardware is here, 1 SSD and 3 HDD, 1 SSD plugged into SATA 1, 2 3 4 is plugged into 4TB, 1TB, 1TB respectively. SATA is in AHCI mode and hotplug is enabled. LSPCI log (https://paste.ee/r/Qhxoo), and my config is here,

Updated to DiskIdxMap and SataPortMap to extra_cmdline and changed SataPortMap from 6 to 4. Still the same outcome

Edited October 14, 2021 by coint_cho

WiteWulf · October 14, 2021

Could we have a new thread just for DiskIdxMap/SataPortMap diagnostic? 🤣

angel038 · October 14, 2021

Hi all,

First, thank you for the great help you bring to us.

I'm on xpenology DSM 6.2.3-25426.

I saw this project wich can support DSM 6.2.4 and 7.0 but, i saw there is only a way to do this under Linux.

I'm not friendly with Linux, is there a way to build a bootable key under Windows?

Kouill · October 14, 2021

Docker desktop with ubuntu wsl

haydibe · October 14, 2021

1 hour ago, angel038 said:

I saw this project wich can support DSM 6.2.4 and 7.0 but, i saw there is only a way to do this under Linux.

Creation of the bootloader image requires docker, regardless of the OS. I use docker-ce on wsl2 (!=Docker for Desktop) with a modified Ubuntu 20.04 distro with enabled systemd (which is also the environment I created the toolchain builder in).

Once you have the image, you can use any tool that allows to "burn" the image on a usb stick.

Edited October 14, 2021 by haydibe

cferra · October 15, 2021

Would there be any any to accurately identify port map information prior to loader creation? Maybe a utility or process for this would assist in easing support questions.

haydibe · October 15, 2021

10 hours ago, haydibe said:

Creation of the bootloader image requires docker, regardless of the OS.

Oh, I realize this statement is not true ☺️ ...My toolchain builder requires docker.

Of course a bootloader image can be build without Docker on Linux, as long as the required gcc version for the platform and version is present.

It requires gcc < 5, e.g. 4.8.x or 4.9.x to build Bromolow boot image. Apollolake requires the same for a DSM6.2.4 bootloader or gcc 7.5.x for a DSM7.0 bootloader.

WiteWulf · October 15, 2021

12 hours ago, angel038 said:

I'm not friendly with Linux, is there a way to build a bootable key under Windows?

Not yet, its a long term goal of the project to have a more user friendly gui interface, but as this is still considered pre-beta a solid knowledge of Linux is required to build and potentially debug the loader.

If you’re not able to follow the instructions as they stand it’s not the right time for you to move to redpill.

Be patient 🙏🏻

WiteWulf · October 15, 2021

1 hour ago, cferra said:

Would there be any any to accurately identify port map information prior to loader creation? Maybe a utility or process for this would assist in easing support questions.

These sata portmap/disk index questions aren’t unique to redpill and have been asked and answered many types in other areas of the forum. Try using the site search tool (or using “site:xpenology.com” in Google).

marigo · October 15, 2021

Successfully created the bootloader via the instruction mentioned. (test-v7)

Installed DSM7 41890 from scratch on proxmox -> working fine as far as I can see

Upgraded DSM6.2.3 25426 (update 3) to DSM7 41890 with all settings migrated and also working.

Is there a list with known issues with this loader/DSM that doens't work?

WiteWulf · October 15, 2021

19 minutes ago, marigo said:

Is there a list with known issues with this loader/DSM that doens't work?

Your best bet is probably the Issues section for redpill-load and redpill-lkm in GitHub:

https://github.com/RedPill-TTG

Orphée · October 15, 2021

1 hour ago, dateno1 said:

https://blog.dateno1.com/?p=3853

I was uploaded Mega partition image (fat32=512M + ext2 = 200M)

1. Extend partition size

2. Add EFI boot support on DS918+ Image

3. Active FAT32 Partition for legacy boot

Just mount&replace custom.gz on image

Maybe you can't fill it all

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 ?

progressives · October 15, 2021

On 10/13/2021 at 6:23 PM, RedwinX said:

Just create a new disk :

dd if=/dev/zero of=redpill-template.img bs=1024k seek=256 count=0

+100M for the 1st partition

+75M for the 2nd

all for the rest

losetup -P /dev/loop18 redpill-template.img

mkdosfs -F32 /dev/loop18p1
mkfs.ext2 /dev/loop18p2

mv redpill-template.img boot-image-template.img

gzip redpill-template.img

cp redpill-template.img.gz to ext folder (replace the existing)

Works fine

The problem has been solved.

Edited October 15, 2021 by progressives

tcs · October 15, 2021

On 10/12/2021 at 4:11 PM, WiteWulf said:
Okay, mixed results for me, I'm sad to say. @ThorGroup may find the results useful, however.

I built a new bromolow 7.0.1-42218 image using redpill-helper-v.0.12 and jumkey's "develop" branch of redpoll-load, with pocopico's tg3 extension.

I disabled the PCIe NC360T NIC and re-enabled the internal NIC from the BIOS and booted from the new USB stick.

Initially the server looked good: all docker containers started, as did Plex Media Server, with no kernel panic.

I ran a metadata update on a large library in Plex with no crashes and updated my influxdb docker container, also without a crash.

Next I ran the test TTG had previously asked me to do over on GitHub:
docker run --name influx-test -d -p 8086:8086 -v $PWD:/var/lib/influxdb influxdb:1.8
docker exec -it influx-test sh

# inside of the container:
wget https://golang.org/dl/go1.17.1.linux-amd64.tar.gz &&
    tar -C /usr/local -xzf go1.17.1.linux-amd64.tar.gz &&
    rm go1* &&
    export PATH=$PATH:/usr/local/go/bin &&
    go get -v 'github.com/influxdata/influx-stress/cmd/...'
/root/go/bin/influx-stress insert -f --stats
This time I got a kernel panic:
[  518.193477] Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 6
[  518.228126] CPU: 6 PID: 28191 Comm: influx-stress Tainted: PF          O 3.10.108 #42218
[  518.267191] Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 04/04/2019
[  518.301214]  ffffffff814a2759 ffffffff814a16b1 0000000000000010 ffff880409b88d60
[  518.337704]  ffff880409b88cf8 0000000000000000 0000000000000006 0000000000000001
[  518.374045]  0000000000000006 ffffffff80000001 0000000000000030 ffff8803f4c4bc00
[  518.410480] Call Trace:
[  518.422504]  <NMI>  [<ffffffff814a2759>] ? dump_stack+0xc/0x15
[  518.451063]  [<ffffffff814a16b1>] ? panic+0xbb/0x1df
[  518.475140]  [<ffffffff810a9eb8>] ? watchdog_overflow_callback+0xa8/0xb0
[  518.508166]  [<ffffffff810db7d3>] ? __perf_event_overflow+0x93/0x230
[  518.539141]  [<ffffffff810da612>] ? perf_event_update_userpage+0x12/0xf0
[  518.571601]  [<ffffffff810152a4>] ? intel_pmu_handle_irq+0x1b4/0x340
[  518.603124]  [<ffffffff814a9d06>] ? perf_event_nmi_handler+0x26/0x40
[  518.634926]  [<ffffffff814a944e>] ? do_nmi+0xfe/0x440
[  518.659908]  [<ffffffff814a8a53>] ? end_repeat_nmi+0x1e/0x7e
[  518.688056]  <<EOE>>
[  518.698239] Rebooting in 3 seconds..
So this is a *huge* improvement on where I was before, but it still crashes if I really push it, and I'm not sure why @Kouill's server *didn't* crash running the same test 🤔

One thing to note is that the NC360T card is still physically installed in my machine, but disabled in the BIOS.

Just for giggles I ran this for you, not on an HP box, but a 3615 image 7.0.1-42218 on a supermicro X10SAE with an E3-1225 v3. It ran for an hour before I killed it, no issues other than it complaining about cache after filling up the disk which I expect is normal.

dateno1 · October 16, 2021

15 hours ago, Orphée said:

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 ?

I agree to worry about synology's copyrights

but Xpenology is not 'proprietary product' it hasn't any guarantee (include stored data)

if It is not alpha or beta version that is same

They has endure entire risk associated with the use that (Any damage, forced breaks in economic activity, loss of business or other data or information, claims or expenses, consequential or incidental damages, legal Flaw, as well as lost profits or lost savings caused by use of or related to using software)

I was added 'warning message' on blog's post

if You want I will delete post from here and will not upload anymore 'builded images'

but Everyone can't build bootloader and edit them

Edited October 16, 2021 by dateno1

cferra · October 16, 2021

49 minutes ago, dateno1 said:

I agree to worry about synology's copyrights

but Xpenology is not 'proprietary product' it hasn't any guarantee (include stored data)

if It is not alpha or beta version that is same

They has endure entire risk associated with the use that (Any damage, forced breaks in economic activity, loss of business or other data or information, claims or expenses, consequential or incidental damages, legal Flaw, as well as lost profits or lost savings caused by use of or related to using software)

I was added 'warning message' on blog's post

if You want I will delete post from here and will not upload anymore 'builded images'

but Everyone can't build bootloader and edit them

I’d say that documentation on how to do it is one thing but I’d think that linking to official “forum” sources for materials related to building the loader is the route to go - offering prepackaged images should be avoided.

tcs · October 16, 2021

1 hour ago, dateno1 said:

but Everyone can't build bootloader and edit them

Then they shouldn't be using redpill. It's not considered stable yet, or in any way ready for general consumption. If someone isn't capable of building a bootloader they should wait until the final version is ready for public consumption.

snowfox · October 16, 2021

hello，when I compile，input “./redpill_tool_chain.sh auto apollolake-7.0.1-42218”，i have this problem：

fatal: unable to access 'https://github.com/RedPill-TTG/redpill-lkm.git/': gnutls_handshake() failed: The TLS connection was non-properly terminated.

how to solve this problem？ i think maybe i need to use VPN. which VPN can i use under Ubuntu?

s2k7 · October 16, 2021

virtio driver with option "CONFIG_VIRTIO_PCI_LEGACY=y" wanted !

Thanks @ThorGroup, @pocopico for your great efforts.

In my virtualization system, the default virtio driver cannot worked.

But with option "CONFIG_VIRTIO_PCI_LEGACY=y" compiled by myself worked well.

I have to insert the modules manually after the system booting.

Thus, I cannot arrange a well formed img.

May I ask you to update virtio driver with option "CONFIG_VIRTIO_PCI_LEGACY=y" in the default extensions ?

My tested system: apollolake-7.0.1-42218.

haydibe · October 16, 2021

4 hours ago, snowfox said:

i think maybe i need to use VPN. which VPN can i use under Ubuntu?

A VPN is not required.

4 hours ago, snowfox said:

how to solve this problem？

With the level of provided details: I have no idea.

I can say that "auto" will not work if you require a http_proxy or https_proxy to access the internet (which almost no one uses in their home environment).

You can also try to check if things remedy after restarting the docker service (it was the solution to a couple of docker related problems in this thread).

pocopico · October 16, 2021

Well FYI,

I’ve figured out why some compiled modules when compiled get that big. E.g ixgbe 11MB or igb 8MB.

CONFIG_SLUB_DEBUG

CONFIG_DEBUG_INFO

are enabled on some of the syno released kernel sources and tool chain. When disabled the ixgbe size gets down to 400k vs 11MB

This actually means the current free space on partition 1 on the default boot_image_template should be enough.

I will need to recompile and test again some extensions. This needs some extra effort, any help is welcome so PM me if available.

Edited October 16, 2021 by pocopico

pocopico · October 16, 2021

2 hours ago, s2k7 said:

virtio driver with option "CONFIG_VIRTIO_PCI_LEGACY=y" wanted !

Thanks @ThorGroup, @pocopico for your great efforts.

In my virtualization system, the default virtio driver cannot worked.

But with option "CONFIG_VIRTIO_PCI_LEGACY=y" compiled by myself worked well.

I have to insert the modules manually after the system booting.

Thus, I cannot arrange a well formed img.

May I ask you to update virtio driver with option "CONFIG_VIRTIO_PCI_LEGACY=y" in the default extensions ?

My tested system: apollolake-7.0.1-42218.

I’ll take care of that and keep you posted

s2k7 · October 16, 2021

3 minutes ago, pocopico said:

Well FYI,

I’ve figured out why some compiled modules when compiled get that big. E.g ixgbe 11MB or igb 8MB.

CONFIG_SLUB_DEBUG

CONFIG_DEBUG_INFO

are enabled on some of the syno released kernel sources and tool chain. When disabled the ixgbe size gets down to 400k vs 11MB

I will need to recompile and test again some extensions. This needs some extra effort, any help is welcome so PM me if available.

you can try following command after compiling:

# strip --strip-unneeded virtio.ko

pocopico · October 16, 2021

You may also use INSTALL_MOD_STRIP=1 make flag while installing but IDK sometimes it strips sometimes it doesn’t. I’ll also try your solution and update you if it works or not

Edited October 16, 2021 by pocopico

RedPill - the new loader for 6.2.4 - Discussion

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites