WiteWulf

I've never used HyperBackup in the past, but successfully completed a small (few GB) backup from one xpeno server to another.

No, that's expected behaviour. DSM doesn't report what's physically present, but what it expects to find on the target hardware for the firmware version you're running (DS3615xs in this case).

Come back when redpill is out of beta. (Spoiler: it’s not even considered to be *in* beta yet)

Check the syntax of your JSON config files, there's an error somewhere.

Your best bet is probably the Issues section for redpill-load and redpill-lkm in GitHub: https://github.com/RedPill-TTG

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).

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 🙏🏻

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

On the hardware tab it shows: 2x 8GB 1600MHz DDR3 ECC But in the BIOS setting for "Maximum Memory Bus Frequency" it's explicitly set to 1300MHz. Ah, Intel says max memory speed for that CPU (E3-1260L) is 1300MHz: https://ark.intel.com/content/www/us/en/ark/products/52275/intel-xeon-processor-e3-1260l-8m-cache-2-40-ghz.html That's correct

Hmm, yeah, that too 🤔 Why are you underclocking your RAM @Kouill?

I've gone through the spreadsheet and highlighted differences in configuration that I think may be relevant (I've ignored cosmetic stuff like power on boot logos and fn key prompts). What stands out to me is that @Kouill is running slower RAM, but that matches their CPU and is configured appropriately in the "Maximum Memory Bus Frequency" section of the BIOS. Also, I've got "Intel Virtualization Technology" disabled, as I'm not running a hypervisor and read that's best to have it turned off in that situation. But can this affect docker? It shouldn't, as docker is basically a glorified chroot 🤔 We've all got slightly different IRQ assignments, too.

They're passed to the kernel at boot time, so technically they're grub.cfg parameters, but practically on redpill they should go in the "extra_cmdline" stanza of <platform>_user>config.json, eg. { "extra_cmdline": { "pid": "0xc75c", "vid": "0x05dc", "sn": "1230LWNXXXXXX", "mac1": "001132XXXXX", "mac2": "001132XXXXXX", "nmi_watchdog": "0" }, "synoinfo": {}, "ramdisk_copy": {} } They can also be set manually on a running system, eg: echo 0 > /proc/sys/kernel/nmi_watchdog But this won't persist a reboot, obviously.

This isn't a bug, it's how DSM works. synoinfo.conf is recreated at every boot. Read the documentation: https://github.com/RedPill-TTG/redpill-load Modifications to synoinfo.conf need to be added to the "synoinfo" stanza in your <platform>_user_config.json files. This way they'll persist through reboots.

Thanks so much for taking the time to do this you two, I know it’s time consuming. I’ll have a look at the data properly later on.

Question: at what point during the boot process are extension scripts for “enhancements” run, and is there any control over it from user perspective? While trying to diagnose the kernel panic problems I’ve been having with bromolow on baremetal I’ve found that booting with nmi watchdog disabled, but manually enabling it after boot, seems to fix it. I figured I would keep nmi_watchdog=0 in grub.cfg, then use an extension/enhancement script to turn it back on again. Does that sound like an appropriate use of this functionality?

I've drawn up a quick spreadsheet with as much information as I could get relating to hardware, firmware, BIOS settings and general configuration. These are spread across four different tabs within the spreadsheet. https://docs.google.com/spreadsheets/d/1aBrWkJHzwBl6HcYqpBZhRyeX-5CxT5yTmXZ9p3d8zAY/edit?usp=sharing Feel free to comment on any of the settings you think are right or wrong. @Kouill could you compare this to your setup and either fill the sheet in with your details or just reply back here with anything you think is relevant, please?

No need to apologise, thank you for helping out! We've got a slightly different CPU, but when I collated a list of people's CPUs earlier it included a broad range of models. I'll go through my BIOS and make a note of all settings, page by page, so that we can compare.

Regarding soft lockups on hypervisor guests, I just found this: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/keeping-kernel-panic-parameters-disabled-in-virtualized-environments_managing-monitoring-and-updating-the-kernel Redhat explicitly state that in a vm guest you should have: nmi_watchdog=0 and softlockup_panic=0 ...to avoid spurious soft lockups. I think everyone running on a hypervisor should be setting these parameters in their setups 🤔

From what TTG said, the hard lockups (kernel panics) and soft lockups where quite different, though. I guess my question may only be relevant to those running on baremetal.

Yeah, you've got something in your PCIe slot, though. That may be significant.

@Kouill was kind enough to give me a copy of their boot img so I could attempt to replicate their influx-test without crashes. Unfortunately the influx-test kernel panic'd my system within a few seconds. NB. there were the following differences: - kouill boots their system from the internal microSD slot, whereas mine was on a USB stick on the internal port - in the grub.cfg I changed the serial number to match mine - in the grub.cfg I changed mac1 to match mine - in the grub.cfg I changed I added mac2 with my mac address

Yeah, just trying to figure that out. You added them to the bundled_exts.json file, though, so I don't believe they can be removed with ext-manager *edit* Never mind. Kouill gave me a copy of their boot loader image and it still kernel panics my system when running the influx-test

I've tried doing it exactly the same as you, but it fails whenever I try to create the image as Orphee removed some extensions from their repo that weren't working properly (they were never intended for public use, but psychoboi32 used them in their forked repo. I'm guessing that as you have the extensions cached locally it carries on building okay for you.

@Orphée @nemesis122 @pocopico @erkify @dodo-dk Hi folks, I asked you previously what CPU you had in your Gen8 machines when experiencing the kernel panic and soft lock issues, and thank you for your responses. In the main thread @Kouill has demonstrated a Gen 8 running the influx-test docker stress test and it not crashing their machine since they moved to using the onboard tg3 NIC rather than PCIe NIC. I've had less successful results on my system trying the same thing (it's more stable, but still kernel panics under load), but I'm curious to know what NIC you were using on your systems? If there's a commonality of a particular PCIe NIC with the kernel panics that could be significant.

There's hopefully a better way of managing extensions coming to haydibe's docker scripts soon....watch this space