WiteWulf

Everything but the NIC driver is included in the default build, and the tg3 NIC driver is already in pocopico's repo: https://raw.githubusercontent.com/pocopico/rp-ext/master/tg3/rpext-index.json I see that pocopico has issued PRs for some of their extensions but they're still waiting on @ThorGroup to merge them.

Go back and read through ThorGroup's posts in this thread, there aren't many of them and you'll learn a lot. A GUI of some sort is definitely planned, just not sure if it'll be around in time for the beta. Choosing and adding drivers is always going to be necessary as storage space restrictions mean that everything can't be loaded by default, but again, there was talk of a custom image that could be loaded before building a redpill boot stick that will figure out what drivers might be necessary for a given system.

Yes, I realise that. It’s the redpill-load repo, though, not redpill-lkm, so this only affects how the image is built and not the code that’s actually run on the system. I’m using haydibe’s docker scripts to build my images (kouill appears to be building by hand) and couldn’t get them to run successfully using the 420Xnu redpill-load repo (which I’m unfamiliar with), so I used jumkey’s repo, which is a known-good alternative to the official TTG repos for unsupported DSM versions, and is what I’ve been using for all the other builds I’ve been testing.

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.

Amazing! I'm going to build a 7.0.1 bromolow image with tg3 now and see if I can replicate.

But only if you're trying to use the onboard NIC. If the onboard NIC is disabled and you're using something else (USB or PCIe) you should ensure the correct drivers for the hardware are included. It's *VERY* helpful if people posting requests for assistance include a detailed breakdown of the hardware and software they're trying to use to avoid us having to ask extra questions (or make assumptions, which often turn out to be wrong).

You can do it either way, but haydibe's docker script is much simpler and almost officially supported by TTG (as official as anything gets). Use haydibe's script, you'll get the same image output at the end of it with a lot less effort.

https://github.com/RedPill-TTG/redpill-load

Have you included the tg3 driver in your build? Are you using a PCIe NIC? Have a look on the serial console and see what's happening. Login in as 'root' (no password) and run 'ifconfig', do you have anything other than 'lo' listed? If you have eth0/eth1 listed, what IP addresses do they have?

To help others who may have the same issue could you explain what you did to fix it, please?

You should confirm that all your HDDs are visible to the new loader. Build the image with the early telnet daemon extension so you can log into it, see the console output, and check that all your storage devices are visible.

Can you confirm the above? Your system no longer kernel panics under load when using the tg3 drivers? If so this is very important. Could you please try running the docker influx-test on your system as described by TTG here? This test is guaranteed to crash my Gen8 100% of the time with NMI watchdog enabled. If it turns out to be an interaction with the PCIe bus or the NC360T card and drivers I'm using this could help solve the problem.

Can we keep driver requests in the relevant thread, please? Just trying to keep the signal:noise ratio in this thread a little more manageable 😀

There’s a known issue with Gen8 hardware and redpill with all supported versions of DSM that you could be running into: https://github.com/RedPill-TTG/redpill-lkm/issues/21 There’s a workaround (not a fix!) detailed in that Issue, but it’s not recommended unless you really understand what you’re doing.

Thanks, see my last post, though: I linked to the wrong post by mistake.

These tests were specifically for kernel panics on HP Gen8 Microserver hardware, both bare metal and with a hypervisor. If you’re not running a Gen8 (which I don’t think you are, there’s no point. If you’re not confident with Linux you’re going to struggle to execute those tests, so I’d advise against it. You’d need to install Docker from the Synology packages manager, ssh in to the server and run the commands as detailed by TTG. @Mixpower I actually linked to the wrong post in that GitHub issue: these are the tests I’d like you to try if you can: https://github.com/RedPill-TTG/redpill-lkm/issues/21#issuecomment-932808905

- what version of the toolchain are you running? - what’s the host OS? I just Googled “temporary failure resolving deb.Debian.org” (try it!) and it seems to be very common with docker and is often caused by host firewall settings.

Nice one! Would you be willing to do some testing (and potentially crash your box; *probably* no data loss 😀)? If so, put docker on it and try running the tests TTG got me to do here: https://github.com/RedPill-TTG/redpill-lkm/issues/21#issuecomment-932690817

It’s right there in the error message

Hehe, you don't want much, do you? 😃 I think AMS relies on a lot of hardware monitoring that isn't implemented in redpill yet, so it may be a bit early yet. Also, it would be really helpful when requesting driver, etc. for others to prepare as extensions if you could provide links to source

It's worth pointing out that extensions that are in a usable state already should be listed in: https://github.com/RedPill-TTG/redpill-extensions ...and people should look there first.

Well the site has a search function people could use, although I admit to finding it frustrating to use at times. I find it a lot easier to use Google with the searc tag "site:xpenology.com" to limit results to this site. I think the frustration comes primarily from people asking questions that are *really* easy to answer by searching, and secondarily from those who expect this to "just work", despite repeated notices from TTG that this shouldn't be considered beta code yet. Any documentation or FAQ collection that's made now will be superceded by the look of what been mentioned for TTG's roadmap. Having said all that, I agree with pocopico's point that it's the people who are keen to experiment that's driving the development and bug fixing right now, so a balance needs to be struck.

I just built bromolow-6.2.4-25556 with a freshly unzip'd redpill-tool-chain_x86_64_v0.11 and had no errors PEBKAC

42218 is not a supported version at present, don't expect extension repos to have everything necessary for it to build

As I understand it you shouldn't be modifying synoinfo.conf as it gets overwritten when you upgrade. Read the documentation and you'll see that any changes you want to be make to synoinfo.conf should be put into the synoinfo stanza in <platform_user_config.json before you build your image. This way your changes are also kept outside of the target system and are easier to reuse in the future.