WiteWulf

I'd strongly advise against running DS3615xs on an HP Gen8 (speaking from personal experience). It's known to be very susceptible to kernel panic crashes. I believe DS3622xs is considered the better choice for your hardware. Have a look here:

Ignore the bit about .ssh, I didn't read the instructions properly on the GitHub page

Hi Derrik, when asking for help please include as much information as possible. At a minimum: - hardware details - baremetal or hypervisor - bootloader version - DSM version - upgrade or fresh install Can you ping the machine? Does Synology Assistant see it? What do you see on the serial console?

Thanks for the docker link @Balrog, seems to be working well for me, although I had to drop mounting root's .ssh directory as I don't ssh as root and the dir doesn't exist. That part of the command is also missing from the author's install instructions on the docker registry. *edit* Slight wrinkle: VMware doesn't like that the docker container thinks it's Ubuntu, but the DSM vm is configured as "Other 3.x 64-bit linux" The configured guest OS (Other 3.x Linux (64-bit)) for this virtual machine does not match the guest that is currently running (Ubuntu Linux (64-bit)). You should specify the correct guest OS to allow for guest-specific optimizations. Actions

That sounds similar to the problems I've been having updating an old 7.0-41890 install: I reckon I might have to give your approach a try at some point

The server is a DS918+ on ESXi 7.0U2, it was initially built with an early redpill docker builder, using apollolake-7.0-41890 8x CPU, 16GB RAM, 2 NICs Boot loader image is on SATA0:0 500GB disk image on SATA1:0 Slight wrinkle with the setup: the network the VM sits on has no DHCP by design, it is a server VLAN in a datacenter that expects all devices to be statically configured. As such, each time I boot into TCRP I have to manually configure the NIC for network connectivity, but the DSM install is configured correctly with a static IP so operates fine once booted. I recently updated the bootloader to TCRP, still on apollolake-7.0-41890, there are no problems with this and I've repeated the process a couple of times to check it's building reproducibly. I want to update the DSM version to a recent version, but everything I've tried fails. Specific commands issued in TCRP are in italics The Control Panel in DSM offers an update to 7.1-42661, so I try that first: Update from Control Panel to Offered 42661 Install update Reboot vm Go into TCRP at boot Configure network ./rploader.sh update sudo ./rploader postupdate apollolake-7.1.0-42661 Reports “Found Version: 7.1-42661-0” and ask if I want to use this for the loader, I say yes Reports “The new small update version will be : 7.1-42661-0”, asks if I want to use this for the loader, I say yes exitcheck.sh reboot vm now uses up 100% on one core and console outputs a stream of rm: can’t remove ‘<file>’, but no significant disk activity observed in VMware I’ve left it like this for hours and it never seems to stop working through /proc /sys /dev etc. Can’t ping on network, not visible with Synology Assistant gave up and reverted to snapshot Manual update to 7.0.1-42218 Download .pat from archive.synology.com Install update Reboot vm Go into TCRP at boot Configure network ./rploader.sh update sudo ./rploader postupdate apollolake-7.0.1-42218 TCRP incorrectly identifies to update as 7.0.1-42218-5 and asks if I want to use this for the loader Selecting Y carries on with the build, selecting N exits to the prompt So I try to continue anyway… Reports “The new small update version will be : 7.0.1-42218-5”, asks if I want to use this for the loader, I say yes exitcheck.sh reboot Console output gets as far as “[ 5.337562] bootconsole [uart0] disabled” and stops CPU usage is similar to what was observed in the previous attempt, but with no console output I can’t see for sure Can’t ping on network, not visible with Synology Assistant gave up and reverted to snapshot Manual Update to 7.1-42661 (with Update 1) Download .pat from archive.synology.com Install update Reboot vm Go into TCRP at boot Configure network ./rploader.sh update sudo ./rploader postupdate apollolake-7.1.0-42661 TCRP again incorrectly identifies the update, as 7.1-42661-3 this time Accept it and try to build anyway exitcheck.sh reboot Console output again stops at “[ 5.371434] bootconsole [uart0] disabled”, with one CPU core max’d out Can’t ping on network, not visible with Synology Assistant gave up and reverted to snapshot Any ideas what I'm doing wrong, or any suggestions?

There shouldn't be any need to rebuild if your sata port map was configured correctly the first time around (I'm doing this myself with a TCRP DSM 7.1 install in ESXi at the moment). However, when asking for help please include as much information about your setup as possible to help us help you. Include: - loader and version - hardware details (including whether baremetal or virtual) - DSM version

You need to set the correct satamap and idxmap parameters for your system as cmdline options. I had the same problem running 918+ on ESXi. The parameters vary based on what your hardware is. Read back through this thread and you'll find information on how to configure/fix it.

The whole world doesn't speak English. If you don't understand the poster's native language leave it for someone else who does to respond 🙏

Thanks @Orphée, I just had a quick scan through the tinyloader thread, impressive stuff! Must have a play with that sometime soon now I've got a bit of spare time again. DS3622xs support sounds good; did I read somewhere that Synology are dropping support for DS3615xs that many of us use as a base?

Looks like you're running into the kernel panic issue we spent quite a while investigating last year: https://github.com/RedPill-TTG/redpill-lkm/issues/21 The workaround I found was to boot with NMI watchdog disabled, then turn it on manually after booting.

Hey people, sorry for going all quiet, life got on top of me for a little while after Christmas, what did I miss? Looks like TTG are still MIA, but there's been some great work done by the regulars to build on their work. Anyone fancy giving me the executive summary?

I foolishly suggested I would do something like that last year, didn't I? 😀 Give me a few days to get back into the day job (and catch up with the last few weeks' posts on here) and I'll get into it. I've got a few proposals to run over with you, haydibe, etc. before I take them to the site admins. The main redpill thread needs to die, basically....

This is looking very good, great work folks!!!

@Hammerfine the config file included with rp-helper only includes the DSM versions officially supported by TTG. For any other versions you'll need to add your own entries for repos maintained by others as haydibe pointed out.

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

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.

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.

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.

Hey Ozef, redpill really isn't ready for daily use yet. It's still considered alpha quality code with risks of instability or data loss. To protect users who aren't so technically able you won't find such step-by-step tutorials until the code is more stable. I appreciate that this is a huge and unwieldy thread now, but you'd do well to search for ThorGroup's posts and at least have a read through them, along with haydibe's scripts for running redpoll-load in docker. Add to this nobody's seen the primary developer of the project (ThorGroup) for almost 2 months now and I wouldn't be rushing to install this just yet unless you've got something to offer as a developer.

You need to make it yourself because the boot images contain copyrighted software belonging to Synology. The whole point of redpill-load is to enable people to build their own custom boot image using the software Synology make publicly available without redistributing that same Synology software with associated legal problems. Please don't ask for images and please don't provide them if anyone asks.

ignore

Nothing special. I just enabled it in DSM:

I'm using VMXNET3, not e1000e. It's on a vSwitch with a bonded 2x1GbE physical connection to a QNAP server acting as a filestore.

Working fine on my DS918+ on ESXi: