ThorGroup

Sadly this "requires at least one btrfs volume that only consists of synology SSDs" - there's probably a reason for that.

You cannot use VMM when DSM is running as a VM itself. Technically it's possible (you can enable that option in VMWare) but the performance of VM inside of VMM will be like running Windows Vista on Pentium 133Mhz.

There's a script which takes care of that. Its template is present in redpill-load repo in include/loader-ext/target_exec.sh_ - it is filled-in with by the extension manager. From the perspective of adding new drivers you should just add entries under kmods key like described in the documentation for devs and the target_exec script will take care of the rest (i.e. insmodding them etc). There are no interextension dependencies (i.e. between multiple extensions). However, when you specify multiple .ko to load in kmods key they're loaded in that order. There's a mechanism to force extensions load order (extensions key in user_conf as described in dev docs for extensions) as a stop-gap. This should be rare however as drivers loading is for the most part asynchronous in linux anyway. Spot on: dependency graph is needed for that. It would TECHNICALLY be possible in bash but oh boy... that's insane in a very wrong way Being serious we're planning and preparing for a rewrite of extension manager so that it can support dependencies properly. The current solution is a good-enough PoC to see if the idea will work. We designed it and brainstormed through multiple people to give the community a PoC which is functional (this is probably close to a 10th iteration of the design of extensions itself) but maybe not with all bells and whistles right away. From the perspective of time choosing bash on principle of "it doesn't require installation" was a mistake.

With RP just add it to the synoinfo parameter in user_conf In general you can add up to 4 ports with RP now as the LKM only supports mac1-mac4 syntax. There's a newer syntax called "macs" which accepts comma-separated values but its validation was more complex and we didn't add it yet (but there's a todo in the code).

So a quick up-not-to-date You guys are writing so many post and we're committed to reading all of them and responding where needed. We promised to write something more last time but few of us had slightly unpredictable life events - given the fact we usually get together physically we encounter a small delay. So, regarding the SAS issue: the sas-activator may be a flop. We tested it with SSDs and few spare HDDs which obviously weren't >2TB. It seems like the driver syno ships is ancient and while it does work it only runs using SAS2 (limit to 2TB is one of the symptoms). Don't we all love that ancient kernel? Probably on systems with mpt3sas the situation isn't a problem. As to the native SAS support and how it works: in short it's useless. The SAS support in syno is tied to just a few hardcoded models. Most of them support only external ports (via eboxes). Some, like in a few FS* products support internal ports. Unfortunately, this is completely useless as the OS checks for custom firmware, board names, responses etc. Is it possible to emulate that? Yes. Does it make sense? In our opinion not at all. With the community-provided drivers we can all be fully independent of the syno-provided .ko in the image. As the LKM supports SAS-to-SATA emulation for the purpose of syno APIs thinking it's a "SATA" device further investment into true SAS doesn't really make sense. To be clear here: there's no loss of functionality or anything. Many things in the kernel actually use the "SATA" type. It seems like syno intended it to be a true SATA but down the road changed it to really mean "a normal SCSI-based disk". The reason why syno separates real SAS controllers is to offer .... hmm, a lot of hacks over their firmware and timing issues with LSI controllers. So in short emulating a true SAS type in syno will give us no benefits. Saying this we also, very cautiously, should probably make a recommendation: for anyone using a standard array of disks of 4-8 it's probably a better choice to go with a Marvell-based chip which works natively without drivers (and which syno uses as well). For bigger installations LSIs are still preferred (as they're cheap, work with low-cost used SAS drives, save on cabling etc etc). =============================================== And now a massive response stream to all questions That pesky /dev/sda may actually be a bug in the syno kernel. According to the IdxMap it should NOT present itself at the first spot grrr... we set it to map controller 1 to like 20 and it still used the first disk (and only the first) at /dev/sda. There may be a way to use remap of ports (another feature which syno uses extensively on their boards) to move it. It would actually explain why syno uses a long string of remaps (comically long, like 30-entries-long) instead of a map on some of their boards... as map seems to not work properly. We will play with it. Can you create an issue in the redpill-lkm repo, so we don't lose track of that? It may also be a problem with magic index shifting... it looks like Jun's loader may have been fixing a bug in syno's remap code. Yup... exactly the problem as described at the beginning of the post. It was too easy to simply load their drivers. This lead us to write that summary on the top - it looks like anyone dependent on the LSI card will need to use a 3rd-party driver as the syno one is ancient and only uses SAS2 (and thus the limit). For us, to be honest, the main drive towards DVA are the native nVidia drivers. While they surely can be installed on other DS it would be just simply easier to install them from the pkg manager and call it a day. As for the surveillance station stuff (and photo station and similar) patching binaries isn't that good of an approach. This is because they're checksumed. Maybe not these but others are. In general changing any of the signed syno files in the OS is a slippery slope - it's better to make sure the OS thinks it's a real motherboard rather than modify the system to not check something. The more things we can emulate in the kernel the better as updates are unlikely to break them (as they would break real hardware as well). See, the issue is while we can surely control a fan from PMU it's completely different on every motherboard. Like they never did put any standards in - guys from lm-sensors are pulling their hairs out to handle all that. We don't have a good idea just yet how to make this good so that everyone can just define their way of controlling the fans but this is something we have on the list as "todo" (albeit low priority as usually people just set their CPU and case fans from the bios, with newer motherboards you can even upload/set fan curves in the BIOS/UEFI itself). Yes we do (even if slowly!) GH is much easier to deal with simply because we can split multiple problems into "buckets" and easily ping people with that particular problem. Forum isn't really a good tool for that (but fantastic for a general discussion and support questions!). .ko can be included using RP extension. You can find examples and documentation in the redpill-load repo. It will simply load .ko you list automatically. Built-in card in gen8 should work with these drivers. To give you more context for the "SATA" thing: it's stupid. It looks like a huge legacy part in the syno code. As we wrote above "SATA" is used in the syno kernel additions as kind of "anything SCSI-based which is not a USB drive, not iSCSI and not cache-NVMe". There's no performance penalty or anything. In face they themselves treat VirtIO as "SATA". Ultimately, the kernel doesn't care about their types at all. These are only there to guide the OS what to do and not do with these drives (e.g. don't make swap partition or create OS partitions on iSCSI). It's like with VirtIO ethernet driver: DSM will show a warning that the network is 10/100Mb [as it sees it as "unknown"] but will happily push gigabits of traffic through it. As for the general advice if you use QEmu-based systems use Q35 unless you have a good damn reason for older chipset (e.g. Windows 98 VM or something along these lines). They keep the i440fx as the default as it's most compatible but in general Q35 is the one you should use for any modern OSes. As for NVMe SSD: these are well... PCI-Ex devices. They go through a slightly different pathway. But again: kernel doesn't care really. There are mods for the OS to see non-syno drives as valid SSD cache. However, with some kernel tweaks we can probably get rid of these modifications (hint: if there isn't a GH ticker it will be appreciate in the redpill-lkm repository, so we have this on our radar). pinging @haydibe here. The loader itself doesn't care [now] but probably the container config has some assumption somewhere. You can leave them, you can even set them to DEAD and BEEF - it will not cause any problems but a warning message during boot When they're set but not needed they're only validated to the point of "is this a hex number". [note to ANYONE doing supportsas=yes] You shouldn't really do that. This activates syno-specific SAS support which will break a lot of things. This flag is horribly misleading and used in aaaaa looot of syno code. This is way more than just loading the driver. This is more of a "activate our hacks for broken LSI firmware we flashed ... and do these totally not-SAS things on this controller ... and when you are at that can you maybe also tell the controller to take over controlling some of the leds ... oh, and load the driver". So folks, really, don't touch that option with a long pole - it's a trap. It would only be useful if full ebox emulation was present. We're working with haydibe on integrating the container build into the redpill-repo itself It just spun as a very cool project in this thread and it turns out it's actually great. Adding to what WiteWulf said here: yes, it's because of the kernel changes in ~v6. From the Linux perspective it doesn't care where messages are sent - every printk() goes to /dev/console. Something has to actually handle the /dev/console however. This needs a driver. To see messages on the screen you need to have some sort of framebuffer/vga-like driver. By default every desktop distro will obviously include vga driver in the kernel, but in embedded systems it's rare to include it. Syno simply stripped it from the kernel build. GRUB renders the text and passes control to the kernel and kernel decides to not reset the screen nor display anything on it. It's as simple as that, that's why what GRUB leaves never disappears from the screen We didn't try but probably if you use nV GPU for boot and then load nV drivers for transcoding the screen may turn simply black (or perhaps even disable the connected display?). 918+ is out of question for 1240v2 as it doesn't have MOVBE instruction and 4.4 as built by syno requires it. Even if it "boots" things will start randomly crashing. The 3615 speed shouldn't be limited by the platform itself. With such speeds you may need to tweak kernel networking but this is honestly the same on syno as for any other Linux box. We want to add 3617 but that hotplug issue is that annoying showstopper. As we were busy we didn't debug it much beyond what's said on GH. It's probably something stupidly small... It's more difficult because you're editing the image and making changes which will explode in the future. There's a reason why we automated that hard stuff into extensions Don't you have COMs inverted in the RBSU? Gen8 is such an amazing server but iLO... iLO was written past the Bellmer's curve (e.g. to enable PCI-passthrough you need RMRR hacks because HP decided to mess with it against the ACPI specs). If it detects synoboot it's all good and it means it detected the stick properly. In other words your vid/pid combo is correct. This is something new with these want_idx. Can you add it as an issue in the redpill-lkm repo? In general you shouldn't use the VirtIO SCSI Single. This is a completely different issue related to security checks in the DSM photo itself. If you google search within xpenology.com you will find many mentions and discussion on patching that in the system. In short: a real S/N is needed to make validation happy without DSM patching. Wait... are you saying this doesn't require the paid license but just a config edit?! Also: there's a new bash tool in the loader repo called "always-telnet" - you may find it useful with working with VMWare serial ports. Migrate it to Proxmox, it will be way less problematic,join the dark side ;] ESXi + gen8 is an issue in a lot of places. VMWare dropped support for newer versions, there are weird memory leaks in newer versions etc. It's REALLY not a good platform for ESXi (not that we're biased against ESXi in general but that's another story ;)). ...if only Gen8 had 32GB RAM support. Oh, wait, it can support it but Intel forced HP to disable it. We use and recommend Proxmox [not just for RP] - open source, not limited in features, fast, supported and doesn't cut out hardware. The only problem on gen8 is PCI-Ex passthru due to RMRR but if you search on GitHub there are patches. Exactly that patch - we use this ourselves for long time and it's rock stable. ESXi does essentially the same thing - just ignore bogus RMRR from HP. Ok, you surprised us here! Never heard of that before. However, we need to check how full vmtools do that. In the [red hot] queue. At this point, as many people tested it, we can just merge it but we really want to look at the kernel in a disassembler and see if nothing changed and the automatic path is correct. We try to make sure what we publish is well tested Sadly Intel artificially limited that with efuses... like ECC on i5 and i7 and many other things. Extensions itself don't depend on the software version per-se. You can make an extension compatible with yet-unreleased version as during installation we query for the version which is being built and we don't care where the extension or version is coming from. The power of open-source. Really the best HW transcoding with H265 support is an nVidia GPU. Something cheap and easy to get like P400. However, syno doesn't ship drivers for nV on systems other than their "AI" powered boxes for cameras. Great usecase for transcoding: watching movies on Oculus Quest in bed Also, cheap streaming sticks often freeze or reboot on higher quality local rips of BRs. Some SDR TVs also reallllllyy don't like HDR content. You probably installed too many drivers or found a bug causing a loop somewhere. You shouldn't really go above the space allocated (~50MB) as this is plenty for drivers you need on a single platform. Jun's loader modify the values if we remember correctly. In general, we just pass them to the kernel as-is. There's a validation in the kernel itself but we don't do a validation during image build due to painfuliness of coding such things in bash. In such cases just look at dmesg output when RP loads - it will say exactly what went wrong. The stupid thing is it should NOT be. Synoboot never appear as sda, it just looks like there's a bug in the syno code and despite them taking a different symbol (i.e. synoboot and not sdX) the counter for "used" letters is still incremented and not affected by their mapping. We need to find a good place to plug into that and fix it. It is used but doesn't always work as it should. You guys can also try playing with "sata_remap" or "ahci_remap" options. Their syntax is like: ahci_remap="0>16:16>0:1>17:17>1" and continues. Syno uses this a lot to rearrange ports. Don't forget about the "..." around that map. In JSON you have to escape it like \" Yup, exactly what we wrote above This isn't really RPs variable. These are remaps in the syno kernel. All of these "magic" options are defined in kernel/syno_bootargs.c and quite easy to understand. Sorry to be blunt but what you're doing in this script is very stupid (in a sense of code, not you as the author :)) and dangerous. You're adding compilation options which we're almost sure you have no idea about. You've got an error with the new GCC about the PIE relocation/ASLR so you just changed the makefile for the LKM to use -fno-pie... sure, go for it! That's definitely why that error was stopping the build process so that -fno-pie can be simply added to the build line (/s). We're strongly recommending a read of a post we put on page 55 which discusses some of the GCC stuff (which was discussed many times in this thread before). GCC isn't like Python or V8 - the version REALLY matters. Linux v3 will not build with >=5 for example. There are good reasons why kernel developers are extremely careful and have patches applied per GCC version in the code. The fact some code compiles is just at best 50% of the success with GCC. Additionally, you're going against everything we recommended here. Really, this script is a collection of all "what not to do" we warned against in this thread: don't compile LKM or kernel bootstrap with GCC >4.9.2 (yet the script just YOLOs it) don't install random drivers loading 101 unneeded ones (and that's why we developed the extensions at all, but the script just adds a collection of drivers even if most people don't need them) configure user_config for yourself which you gonna keep for long time and which is semantically valid (yet the script just obliterates it with sed, not even a jq which was installed) read the docs & configurable options in commands (yet the script just does a forceful "mv" instead just using an option already provided for that) and as a desert: it will fail if your path has spaces in it. To not be just grumpy and complain we will make a suggestion: utilize a docker image by @haydibe which works great and does things safely. It soon will be merged into the main repository as well. Obviously, as the project is open-source and on top of that a full-blown GNU, we cannot stop you from using it. However trust us on that: we collectively wasted long weeks on dealing with pesky bugs where things weren't compiled exactly right and in a proper environment. See sad update on the top. Also, you should NOT use supportsas=yes as it does WAY more than just "adding SAS support". There are even more things associated with it (e.g. SASModel kernel boot option, which you shouldn't use either ;)). We said that before but as a reminder if someone missed: don't add supportsas=yes. This doesn't do what it says it does sadly. Don't edit these files manually. You can set any options in these files by adding "synoinfo" section to your user_conf. There's an example in the repo. Any options you set will take priority over default ones. The automatic code takes care about figuring out which options to remove/add/modify and to do it in 4 different files across 2 environments. You should not use that script at all. Use the container recipes provided here by haybide.

/\ Yes, that definitely - as 3615xs has syno-built SAS modules the activator will install on 3615xs only (and the extension intentionally doesn't have a recipe for 918). However, with the LKM changes a standard unmodified mpt code should work properly.

A quick update (we will write more tomorrow): the native mpt2sas driver works but it's present only on 3615xs platform. To activate it and make it working properly without any hacks just add this small extension: https://github.com/RedPill-TTG/redpill-sas-activator We also updated the kernel module to rewrite SAS => SATA ports so it should work with any off-the-shelf mpt2sas or mpt3sas driver.

Quick update: Thanks to amazing reports from @WiteWulf the KP on 3615xs should be fixed now. For details see https://github.com/RedPill-TTG/redpill-lkm/issues/21#issuecomment-932690817 A different hard loockup seems to exist still but this shouldn't affect most of the people and judging by the last post in the issue it may not even be a bug but an over-reactive kernel protection mechanism. ==================================== We don't see a reason why not. The kernel should load it automatically. We never played with microcode updates manually but DSM isn't special here. Do you have two images where one is working on Q6600 and one is not? One of our devs may even have Q6600 on P5B Deluxe somewhere but it's a very old platform and we don't know if it still works after so many years That sounds REALLY good actually! We may try for a test installation observing 3D printers. We wonder how they actually detect what's a real S/N<=>MAC combo and what's not. We doubt it's calling to the outside API... because if it's that simple adding an emulation is probably pretty trivial. It's probably more a checksum than anything. The DVA support is really held mostly by the S/N generation. Despite our efforts of searching around we weren't able to find how previous S/N generators were written (i.e. based on what information). FYI: no packages from v6 will really work on v7 without modification. They changed a lot, actually modernizing the package manager. Even simple things like Plex needed a new package for v7. A real-life DLC.... the thing is what's the point of paying for a SERVER if you don't have any OOB management? That's probably why they release Gen10+ so quickly after Gen10 as people were still buying Gen 8. Yes, the final goal is to have the default be just the "dev.ext_name" installation but with always-available option to use manual URL. The repo has a simple format for now as we don't have a plan HOW it will be structured. However, we are definitely want to keep everything static to avoid having any active servers (more like apt/dpkg and unlike NPM). Currently, the extension names are only mean to force the order of loading. 99% of the users will never use that key. We're currently messaging with @haydibe to see how to make extensions interface nice with containers. Remember that this method will RESET this setting when you update RP in the future. That's why we say to add this to the user_conf For testing it's easier to press "e" in the GRUB menu to edit the entry, add params which you want to test, and then press Ctrl+x to boot modified entry. Are you sure you don't have some compatibility mode set in the BIOS? As 32bit has a limit to 4GB and there were hacks to extend that for OSes like Windows XP. Look under things like "PAE", "Physical Address Extension" or a selector for OS type (some BIOSes have selector like DOS/Legacy/Other - usually picking Other disables all magic wizardy hacks). RP does not need [or shouldn't] the Jun's hack to "hide" the loader as the 13th disk as we set synoboot in kernel and that disk is never visible to the DSM UI. So calculate everything as if that disk was never there. Your first disk can certainly land at "/dev/sda" (in Jun's loader some platforms could never use sda but started from sdb). Depending on the platform the boot from SAS should work (typing from memory here). In general, we try to be pretty flexible as to what "SATA boot" is and make it "anything SCSI matching the size except USB". If you're running 3615xs there's also SasIdxMap <frantically checking housing prices in Romania> Correction: you can do pretty much what you want on the internet from RU as long as you do it to countries which aren't Russia. Not getting political but there's a reason why a lot C&C servers for malware are ran in Russia. Gen8 has a broadcomm card. The driver, if someone compiles it, should work. The KP should be fixed for the most part on 3615xs - see GH issue for details: https://github.com/RedPill-TTG/redpill-lkm/issues/21#issuecomment-932690817 As for the ethernet use VirtIO if you can [i.e. not on VMWare] as it's a paravirtualized interface [=low overhead/faster] and e1000e otherwise (doesn't need drivers). e1000 is a different card.

Look at the last post - somebody found a solution. It's just they hardcoded PCI ids for these We never looked at NVMe cache ourselves but if needed something can probably be done in the kernel to make it work. Depending on how their library works (i.e. does it just check for these devices and use /dev or actually use PCI commands directly [probably not]) we can maybe just fake them.

Even if you forcefully insert them that's a bad idea - you can yolo things in user space but not in the kernel as userspace is guarded by the kernel and kernel is only guarded by a sparse memory managemnt unit checks The kernel space has literally no memory protection per se (ok, there are small bits here and there but this is mostly bug-catching and not protection between drivers due to performance reasons). It's a PITA that kernel modules in Linux are specific to that exact version up to the t but that's a small price to pay for a great kernel. That decision was famously made in 1991 (if someone's interested google for Linux vs Minix and now-legendary exchange between Linus T and Minix author - it could be a hollywood movie). This is why RedPill extensions system is VERY specific to the versions of modules so nobody accidentally even try loading wrong driver's version as this is much more dangerous on Linux than on Windows or macOS. Drivers on Linux are literally running on the same privilege level as the kernel itself. On macOS more and more are in userspace or are at least partially isolated. This is why nobody should experiment with e.g. SAS drivers on a drive with data which they care about [unless tested by many and confirmed working properly].

Rest of the answers starting from beginning of page 84 and ending on page 86. ======================================================================== We will love to be wrong here but to our knowledge 918+ kernel does not have SAS functionality. These symbols are present in the kernel code but guarded by "ifdef MY_ABC_HERE" which presumably depends on the model/SAS support option. Eh... it is possible to emulate that. We know how technically. We can provide these symbols virtually in RP but it will require some digging to check what they should return. Since we don't care about REAL SAS support (as syno-supplied controllers have a custom firmware anyway) we can just shim them. However, we see some success from @pocopico and @Orphée here so we will... wait for an extension maybe? THAT WE CAN FIX! We can add that symbol if needed. We saw Jun replacing that symbol but we had no idea why. Famous last words: that should be easy. 36xx is rocky with v7 overall. We've lost two pools on a real DS - a complete ext4 crash. Surprisingly btrfs is more stable this time, but someone reported here data loss with btrfs as well. However, there's a shell hack to forcefully just load USB device kernel modules. It's just they're through with supporting that probably. Yes, you are correct. We were thinking about that as well but decided against dividing drivers. There's no harm in loading all of them in pre-boot. On some of our servers (unrelated to DSM) we have 10Gb/s networking in initramfs to boot from them. We couldn't find an argument for splitting drivers to core and non-core besides size. Since loading a ramdisk layer seem to work up to ~430MB we don't think we will hit that limit any time soon. We don't copy modules like Jun did - we just load them from memory to different memory. You don't need to unload and reload them on runtime. On hot-plug systems you may do that but syno doesn't do that themselves either and essentially loads drivers based on configs in preboot. If the .ko is shipped within the PAT go for it and load it - at least we know it's compilled properly. It may still have missing symbols but see beginning of this post. ...and this is exactly why we run a Proxmox. A VM for DSM + a VM for stuff like HA, NUT, or Avahi. Trying to put it on a NAS is already tricky but I'm sure it will piss off a lot of real DS users as for most the NAS is their only server. Teeechincaaaaally speaking as long as the NUC is able to BOOT from the USB3.0 the RP shouldn't have a problem interacting with it as it loads all drivers, including USB3. The only issue may be the driver for the controller itself - if it's not supported by the native Linux xHCI driver you will need to add it as an extension. See the roadmap [few posts from this account back] We want to fix the SAS thing [which as we see guys are already figuring out here] and integrate container build into the load repo - then an instruction will be posted. We also want to solve that annoying crash/lockup issue with 3615xs as we cannot call it stable or even beta if every database crashes it within minutes-hours. Yes, we're trying - the biggest issue, which is slightly funny, is that we have hard time reliably crashing it. That isn't a problem - you just need to set SataDisk... params properly to move disks and it will fix itself. See: https://xpenology.com/forum/topic/44285-proxmox-hba-passthrough-second-virtual-controller-not-detected/?do=findComment&comment=204352 With all due respect: looking at this thread we see many people don't know what to edit and what to put (e.g. randomly stuffing sata_pcislot or doing replacements of hwmon configuration parameters). Doing a quick "e" in grub and adding something which YOU know what it does is obviously something we do as well, however advising people to open images and edit grub.cfg isn't wise. A prime example are disk/controllers settings: you can spend days trying random values found all over the forum OR spend 15-20 minutes understanding what these values do and configure them per your system. Many people don't realize some values are specific to their own config. Additional issue, which we repeated multiple times here, is sharing the loader image. It's a VERY bad idea. Read the first post in this thread: we didn't start RP. The original thread is gone, original repos are gone, ... there's a reason for that and it's not one you want to step into. Trust us on that: sharing precompiled images is a very bad idea. The kernel and modules are open source and under GPL - you can do literally whatever you want with them. However, the final image contains proprietary syno modules and their userland tools which are as far from open source as possible. Connect the dots here why we say to not share the full image and went into a huge effort of creating tools to build the image. It would be much easier to drop an .img or .vmdk and call it a day but the times changed. ======================================================================== Yay! We're done - it took some time Now we need to think about a great PM from @haydibe ^^

This post contains answers to questions up to beginning of page 84. ============================================================================ It's a holy grail to catch WHAT is actually causing that 100% spike when it happens. This is the clue of where the spinlock is taken but not released. Kernel points at influxdb and other DBs but we're sure it's not that. It's somewhere in the kernel itself. This is perfectly correct. Windows uses local time in RTC and Linux uses UTC. The behavior of windows dates back to the MSDOS days. Linux actually follows ACPI specs. This is normal to see when you run any Linux on a PC as ancient RTC spec has no way of setting timezone. Just a small quirk - if you're not dualbooting windows you can just ignore that. That is a very important clue - it may be something related to vUART driver we wrote as it uses a LOT of spinlocks. Do you mean auto power on? This feature is not supported - we didn't emulate it. Do you rely on it? Do you use it? We can add it - as we explained in one of the updates we didn't bother adding it as it isn't easy and it's broken on many motherboards anyway. If you will like to see that feature added please open issue on GitHub in the redpill-lkm repository. Please don't share the final image. Especially if the link points to any of your servers - the final image contains copyrighted material and may get you into troubles. We (and @WiteWulf below) explained it few times here already. As for the 3617xs see the "mysteries.md" file in dsm-research repo on our GH - we aren't actively working on it right now for reasons described there. We probably come back to it when we have some spare time. Ryzens + v3.10 is usually fixable by injecting newer microcode But running a full ryzen bare metal with 3515xs.... why, just why? That's a good addition actually - it's simple to add that in GRUB Can you add an issue in the redpill-load repo maybe? That isn't actually related to RP - you need to see on your router where the traffic is going, or try tcpdump on DSM itself to see where it sends/receives data. Yes, when we add 3617xs support you can just upgrade in-place. It will work like moving disks from one DS to another. Boot shouldn't take that long - it should take under a minute really. kvm64 has many instructions disabled. Ideally when you can you should use host every time for any VM (no matter what it is in general if you're running something modern). We didn't look into that update but most likely just the flash updater has to be blocked overall (we blocked it based on other things but we didn't see an actual PAT to test it). Running it may just crash the machine. This is a great point actually. Even VMWare discourages from passing disks itself (and SMART is just one of many issues with passing a disk). Passing disks is bad on any hypervisor we saw as SMART is not proxied. It could be but there are security issues with that so no hypervisor does that. Please, REMOVE supportsystemtemperature & supportsystemwarning. Actually to properly do that (since using that hack you actually damaged your OS) you should change them to "yes", boot once, and then remove them from your config. We are jealous ^^ Eastern Europe? You can now pack it into an extension. Let us know in case of problems. You can now use an extension and RP will load it automatically on boot. Syno doesn't have depmod and use forceful/static insmod rather than intelligent modprobe. Whoever made that.... has no idea about the loader. We're sorry for harsh words but you CANNOT - ABSOLUTELY CANNOT - SAY that a single bootable image supports "6.2.4 to 7.0.1". Each version requires a static kernel patch. You can boot with an incompatible kernel - sure - but this is a disaster and nobody should ever do that. Never ever. You should NOT edit grub.cfg. If you want to change parameters you should use user_conf.json We love that! We will definitely look at compressing images on v7 as it's annoying they're not. Now since the extensions are supported you can inject drivers See the details in our last announcment post (scroll up - it should glow green as "popular"). As we wrote in the post above - the auto power on is not supported by design as we got frustrated that out of 6 motherboards we tested it worked only on one and only with max 2 scheduled events. If you rely on it we can add it - please add an issue to redpill-lkm repo. It will come with a disclaimer "it may not work" as auto-poweron on PCs is very finicky and we cannot do more than ask the BIOS (or rather the RTC chip) "pretty please set the schedule". Actually the update shouldn't override files on synoboot1 (as these are treate more like a ROM on real devices and serve as a backup boot in case the synoboot2 fails), but attempting to boot the kernel from version A with OS files from version B will not end well... ever. This is sadly coincidental, as we didn't touch locks there We're still debugging that. The most annoying thing is that it actually doesn't crash very reliably on our gen 8s. It does but rarely. You shouldn't use just any random MAC. There's many octets you can change but some have special meaning - just let ESXi (or whatever you use) generate it for you and put it in the user_conf. If you're just starting with virtualization we recommend Proxmox instead of ESXi for many reasons. TECHNICALLY yes, but in practice we want to make it in-place. So you just run a docker command on the DSM itself which will build everything and instead of spitting out the image it will just update the /dev/synoboot in-place. At which point you can just update from the DSM panel and reboot. We didn't develop an auto-patching-on-boot as if you use any custom drivers you have to change them anyway and things get complicated quickly. Seeing as syno doesn't release updates very often (ok, maybe except broken v7 releases) it's not that big of a problem. Our priority is on stability (yes, we know how it sounds with the crashing 3615xs now but trust us ;)) rather than having a thread where users cry that they updated, rebooted and now the system is not working at all. That shouldn't be possible. In the hackintosh community it works similarly if you do everything right: you cannot accidentally update to an incompatible release. Check what they did rebrand Of course if you use their official NIC it will work but there are many cards which are just supported. The easiest way is to check which chipset their NICs use and find a generic from Intel/HP/Dell/etc. Sometimes Intel one will run you $150 but if you search by chipset you will find the same things branded with HP for $50. Like we have a lot of HP 360T deployed as they're solid Intel 2x1G NICs and are laughably cheap (like $15). Did you built it with old GCC? (like 4.9-old) You can't build modules for old kernels using new GCCs. Pro tip: NC360T works in x1 slot You can either order a raiser from x1 to x4 or use a saw (no, we're not joking). http://www.invisiblerobot.com/pcie_x1/ - you're trying this at your own risk but it does work and with 2x1Gb it shouldn't bottleneck. That warning is [sadly] normal as we don't have sources for the kernel. That warning is there as we're using a struct which is... well... HOPEFULLY correct If it's not we may be in trouble. There's a slim chance it's not but who know what they tinkered with? It's working, but we are scared of the SATA boot on 918+ because of that. As we [hope] most of us are adults here there may have been few too many adult beverages when someone said "but guys guys listen... what if we EMULATE USB WITH SATA!" ... and as crazy as it sounds this is how the SATA boot was born on 918+ but the warning is there to scare away anyone from trying something like that with another crazy idea. It's just the toolkit headers don't come with full headers but only public ones (which is EXACTLY to prevent module authors from exploiting private API of the kernel). The VID/PID with SATA boot is completely irrelevant. We just flat-out ignore it completely. There's even a warning in dmesg (which can be safely ignored, it's just more for analyzing logs) that these parameters were completely ignored. Something went bad... really really REALLY bad. But this is most likely the same annoying bug as with crashing influxdb and CPU soft lockup. See https://github.com/RedPill-TTG/redpill-lkm/issues/21 But also as @WiteWulf suggested DON'T use a single vCPU with one vCORE. Versions of DSM with >1 core assume in many places that the system has at least 2 cores. Don't ask us to comment on that Also you need at least 600MB ram (even if it technically runs on 512). So many people praise Surveillance Station... maybe we should actually try it. Slightly OT but if you're using it (or anyone else): do you recommend it? We mostly use Ubiquity gear for that and it's ... OK, but not really stable. Didn't they remove iLO from Gen10 and added as a separate purchase in Gen10+? That temperature isn't real. We wrote about this in a previous post. Currently we sweep-emulate fake temps and voltages inside of the kernel module (to satisfy HWMON subsystem). What we have on our todo list is adding real CPU temp - other params cannot really be read natively as there's no single standard which one is which sensor (you read sensors and which sensor is what depends on mobo/bios/configuration of the bios/boot mode/etc). Temp is fake, cpu frequency is real, cpu model is.... whatever synology thinks it is The cpu model is just cosmetics, doesn't really affect anything - just a pretty thing to show on spec sheet (and its not read from the real microcode but guessed by mfgBIOS based on different parameters). We randomize temperature and then hover around it. Don't edit manually the grub.cfg - add it to the user_conf in the extra_cmdline section. Be careful with setting multiple vCPUs - they tinkered with number of CPUs (not cores) in the kernel. It cannot be trusted to work properly on systems which ship with single CPU (i.e. all but some rack stations? do they even ship with 2 CPUs?). Yes, that's a quirk of the syno code itself - it doesn't care about lower/upper case but does care about : in the MAC. During boot RP actually errors-out with that on serial console as it verifies the MAC a bit (just length really). Don't add random parameters like that. First of all, you should NOT edit grub.cfg but put your params in user_conf.json instead. Second for the disk parametrs see this great explanation: https://xpenology.com/forum/topic/44285-proxmox-hba-passthrough-second-virtual-controller-not-detected/?do=findComment&comment=204352 Third: do NOT add sata_uid or sata_pcislot - these are Jun's custom parameters which were never implemented but were left there. The difference is Jun's loader was removing them from cmdline so that DSM cannot see them - RP does not as we never used them. Making them visible to DSM shows the DSM clearly it's running on non-official hardware. Can you make extensions out of those? So it seems PostgreSQL is the best for triggering that crash (DSM index, plex, music - all use PgSQL). Noted This is unrelated to syno - this is the kernel yelling at the manufacturer of your USB device which has no S/N (any USB device should have it... a lot don't ignore the USB spec). This will not break anything - it's just the kernel being pedantic. It's just semantics - SAS command set uses SCSI like SATA with some differences like how SMART is handled. The situation is similar with PCI and PCI-Express. The physical interface matters to the controller, to the OS it's abstracted under a single SCSI interface (yes, the same ancient SCSI) no matter if the physical disk is a SAS or SATA one. There are even breakout boards for SATA drivers allowing for dual-channel SAS connection (for redudancy). SAS and 918+ isn't something which will ever work natively. However, if we force DSM to see SAS as SATA.... that's a different story. Do NOT edit grub.cfg - edit user_conf.json We knew someone will catch our quick final tests with public repos They were public before the post for probably total of 10 minutes. See ============================================================================ This post reached 50 quotes - we will continue in the next one.

This post contains answers up to page 67. ====================================================== You should use extensions now and NOT modify any files manually. Please, do not modify the grub.cfg file. This isn't a supported method with RP and should not be used. You should add that option as an extra_cmdline in user_conf instead. That is... strange. We're adding it to our internal list as the disk test shouldn't randomly crash the pool This usually happens [on VMWare] when you use USB-boot and not SATA boot. VMWare doens't support USB boot unless you use a physical USB stick connected to a USB-2.0 port [as booting from 3.0 is not exactly working]. The issue is actually both ESXi and other VMWare products internally support both. However, newer ESXis don't like just flat VMDKs for some reason. Even generating the descriptor it fails to boot half of the time when the image is not "blessed" by the VMWare's own tool. FYI image will always be 128MB (unless we change the base) - you will only see a real change in size when you compress it with e.g. ZIP so it removes all the empty space in it. Gen 8 is on our list to figure out fully as we have quite a few of them FYI: That is slightly playing with fire. Internally they assume (at leas in v6) that the disk will be 3 characters in a form of "sdX" unless we missed something. The fact it shows up in the GUI doesn't mean it works correctly. There is probably a reason why they don't sell units with >26 internal drive bays That randomly popsup even on real hardware. Sometimes threads of scemd crash/freeze and it tries for some time to recover them before killing and restarting. Nothing to worry about unless it happens constantly. Correction: it's not the Linux being confused but the mfgBIOS code. Linux doesn't care - this is why the network may appear to work. But syno services do care. Instead of using the API they went around it so when the MACs aren't in order some things try to use the normal API where others use the syno API... and this is what happens. We usually just boot with one random MAC defined and just "ip a" quickly to see how the kernel sees ethernets in that particular system. Any time you see gpioerrors on 918+ it means the module didn't load at all. You should check dmesg. Now the problem shouldn't really exist as if RP fails to load it will deliberately panic the kernel with a detailed log to avoid such "wtf" situations. FYI this seems like the bug reported for the kernel crashing: https://github.com/RedPill-TTG/redpill-lkm/issues/21 That is extremely hard to debug as kernel lockup is essentially "welp, someone tried to take a spinlock but there's another spinlock running". The fact we cannot compile our own kernel, due to broken sources from syno, makes debugging this issue a nightmare. Take a drink for D3x - she's trying to find the issue for some time now. Preliminary testing shows that may not even be the issue with RP but with the kernel mods by syno itself. Oh yes, iommu... that is sometimes tricky. In general IOMMU should be disabled unless you use VMs as it causes more problems even on standard Linux distros. Intel MMU implementation is very... very.... hacky. They improved a lot since 9th gen but older ones are often unstable. A lot of times installing a microcode update helps. ...and now we have extensions We hope you like it as we see you play with drivers a lot. That should be fixed now as @pocopico mentioned. We dialed down these debug messages. They're actually perfectly fine. That external storage warning is not and there's an issue on GH for this one as we recall correctly. It should be the same as this one: https://github.com/RedPill-TTG/redpill-load/issues/30 See We have a limited set of hands and try to prioritize getting as many things correctly as we can on the current version. Adding v7.0.1 when we have v7.0 is trivial but adds another thing to test and potentially debug the issues if any. As we described in the roadmap we want to merge all new software releases. Going further we will merge them much faster when the major load we have is a new release and not 42 different things to check and patch + new version We try to make this about quality and thus we don't blindly merge new releases either - we check every single kernel manually to see if nothing actually changed and don't just use autogenerated patches (as you know, any time you code something - like a generator - you will never trust it as an author ;)). See https://github.com/RedPill-TTG/redpill-lkm/issues/21 We know it's an issue create by you but we're leaving a link to have trace here: https://github.com/RedPill-TTG/redpill-load/issues/30 Thank you for creating this is an issue so we can track it easier Now you can use extensions instead of tinkering with rd. Do you feel comfortable publishing these modules as extensions? Also, there's an issue for the telnet. We think it can be made an extension as well: https://github.com/RedPill-TTG/redpill-load/issues/31= https://github.com/RedPill-TTG/redpill-lkm/issues/21 v7 is a huge beta... on 36**xs we will call it an alpha., and we're not talking about RP+v7 but overall v7. In our production environment no [real syno] devices are running v7 as the real gain is minuscule in comparison to alllll the bugs (some potentially causing data loss) which are there. Give it 6-8 months at least. The issue here is that if we recommend to users to use random forks where everyone changes random things it will be really impossible to support in any way from our end. This will end up with "oh, I used this fork mixed with that which changed 10 scripts and it's broken - why?" Not that we want to discourage forking in any way but we already see a flow of issue from forks where users are confused and create issue that modules are not being copied where this was hacked around in one of the forks. Thank you for stripping the custom forks from the image - we think the forks are great for tinkering by developers but when users try to use them without any knowledge of what they really it's a recipe for a fire in a forest. This was nicely shown by the quick supportsystemtemperature hack which breaks more than it fixes. We already see people putting toolchain version in their signatures which shows us they don't understand that the actual toolchain doesn't affect how the loader works and that it's only used to create the build environment. "Generating completely fake SMART" means that DSM asked for SMART data using ATAPI interface and your LSI rejected that request and so that RP stepped in and provided something fake to make the DSM use the disk at all. Theoretically it would be possible for RP to ask the SAS controller for the SMART using the SAS way and translate that information but this isn't a simple project. There are at least 6 different ways of asking for SMART. Three of them (!) are incorporated in parts (!!) into ATA/ATAPI. Of course SAS went a different direction and has way different ways of requesting and reporting SMART. It's a mess. With native syno SAS support their controllers seem to support ATAPI on SAS (probably custom firmware) and this is why on real hardware it "just works". Feel free to put an issue on GitHub in the redpill-lkm repo so we don't forget. However, we're certain it wouldn't be implemented very soon (but most definitely we would love to have that feature). As for the iLO 4 Advanced there's a beta key which happens to work on retail version. We don't know how legal is to use it but if you google it you can find it for free. Did they leve it on purpose? Is it some sort of an engineering key? Who knows. Most likely these keys for few bucks on ebay are these resold beta keys. The swap has to be done 100% of the time on 3615xs. The only time when you would want to leave it swapped is if you did swap them in your BIOS (i.e. set first serial port to 0x2F8 instead of 0x3F8). You can modify these values in the config if you need to move drives around. Don't modify them blindly - you need to understand it That ignore message means the RP ignored it as it doens't need to do anything with it. The kernel itself interprets that properly and configures the serial port. The issue is on 3615xs syno swapped ttyS0 and ttyS1, so if you type ttyS0 to the kernel it will really start sending data to a physically soldered port ttyS1 on the motherboard. You can swap the loader image and boot - then it will prompt you for PAT and just migrate as normal. But as others said: you should always have a backup as RAID is not a backup. Even if you run a ZFS on an official system for iX you should do a backup We are amazed by r/DataHoarders and their backups of 4-digit number of TBs. ...you do have a backup, right.... right?....right? There will be a clear instruction with the beta - stay tuned. This is an annoying "feature" of syno you've discovered few posts after The reason why it works from dev is that they implemented that security feature rather poorly. Normally to disable it you need to do "echo 1 >/proc/sys/kernel/syno_install_flag" and then you can mount /dev/synoboot freely. Keep in mind (or rather others reading it as you seem to know what you are doing) you should NOT edit ANY files in the image manually. Please, use the extension mechanism instead since we have it now. General tab is fixed for some time now (hwmon emulation). Can you publish the driver as an extension instead? We always try - all of us work/worked in development professionally and we realize how hard is to work with "clever" code. YOU know how it works when you wrote it. A week later neither you nor your friends know what's going on and everybody starts avoiding that part of the code like fire... after a year or two you have the same functionality implemented 5x by 10 different people and nobody knows what's going on. With RP we try to avoid that. It's nice that someone sees that effort. The only way to get SMART working is to pass the whole HBA device. In theory QEmu and others could proxy and filter SMART commands per drive but there's too great surface for attacks and weird behaviors for QEmu/VMWare to do it. You have to remember that "SMART" is really a combination of multiple unofficial ATA commands which were glued together by different manufactures. Then ATAPI tried to codify them and we got a ... huge mess held with several rolls of duct tape. This is why we have to step around a lot of undefined behaviors (like optional log directory SMART command which breaks DSM if it's not supported... but it's officially optional but someone assumed it's always there as modern drives support it). Are they... serious? Sharing a printer is one of the few nice features people actually use on NASes. It seems like a great candidate for an RP extension to run that script on boot Maybe you will like to contribute and create such one so it's an easy install? There are guides how to install NVidia drivers directly from spk from synology. This is the way to really do it. They offer them for their "AI" survivalence station model. This is actually a bug in canvas on FF with to strict privacy settings. We saw that somewhere else outside of DSM. We tried to search for that but no luck. All in all that's not a bug in DSM but in FF. There are canvas security settings in FF - if you make them more permissive for DSM address it should work. We think now it can be automated by an extension - let us know. For anyone who finds this: please, don't do it. We explained in the previous update post that a HWMON emulation was needed instead as putting these lines in. This is a standard AHCI controller. It should work out of the box - you're probably missing a proper Sata config extra_cmdline params and the drives connected to it "land" outside of the zone DSM scans. This is fixed now - it's was a race condition between partscan in linux and loop attachement. There's a plan to support real sensors and "emulate" values by reading them from sensors modules but emulating fake ones was an easier starting point than translating lm-sensors to syno-HWMON. You can still install lm-sensors or any other monitoring tools you like and monitor everything. It's not like syno API is accessible outside of CPU temp and HDD temps.... sadly. At least on non-syno hardware you have an option to use Linux tools - on real ones people are annoyed that they can't. At least we now know /proc entry can be read by a custom script if needed. There are many threads on syno form askim them for some monitoring beyond CPU temp. You should NOT change console parameter. This will break many things (DSM has secuyrity features checking for that parameter; RP assumes that it's at the platform-correct value etc.). We think the ship has sailed We will open a new thread with the beta release (which only really misses SAS and container support if we remember our own roadmap correctly). This topic will be probably closed and we will get a new one strictly for dev with maybe some moderators help to keep the stuff seprated DVA is on our roadmap for another reason - official NVidia drivers. The "AI" survivalence station is something which we personally have no interest in, but it will be there anyway if DVA is emulated. That excessive usage of CPU is actually a missed spinlock somewhere. The kernel doesn't monitor them in any way when debugging is disabled - it will "spin" [i.e. use all CPU cycles on a given core] forever if not unlocked. It's done that way in kernel as spinlocks usually last microseconds (so using other locks would waste even more CPU). When the lock is forgotten/lost somewhere a "deadlock" scenario arises. It will be detected only after some timeout and ideally when another lock tries to execute on the same CPU. It's very hard to debug that over all. ====================================================== Answers will continue in a separate post, as this post cites maximum number of 50 posts

Finally we've got some time to respond to the questions. We will try to respond to as many as possible so stay tight ======= Why there's a problem with compiling drivers when syno didn't publish kernel sources? This is going to be a separate post addressing "why you cannot randomly grab drivers and compile them" so we can link to it. Let us explain where's the problem, this applies to many questions really. There are few major issue with compiling drivers against a different sources. The three major ones are: 1) Versioning of syno kernel's is broken due to backporting 2) Drivers modification 3) Kernel <=> driver modification 4) Data structures missing in toolchains for in-tree drivers Now let us explain each one of them separately and why this is an issue. There's a lot to unpack here. First lets address few terms which are used in kernel development: "in-tree" = code which exists within the source of the kernel; in terms of drivers it means you will find it under "drivers/" (e.g. in drivers/scsi/mpt2sas) "vanilla kernel" = source of the kernel which is the official version from kernel.org "kernel headers" = .h files present in the toolchain. These are NOT all kernel's .h files but only a subset of public API kernel provides. You will find these under "include" or in the syno toolchain. What's important they DO NOT contain private interaction between modules. That's why if e.g. mpt3sas driver wants something from mpt2sas you cannot use toolchain to compile mpt3sas and you NEED full sources. "upstream it" = make your custom patch for the kernel and get it accepted into the normal kernel sources 1) Versioning & backporting Syno, like many other companies, take the kernel and modify it in house. This is something which kernel devs don't really like but since it's an open-source project everyone can. However, after some time these companies realize they want new features from new kernel but cannot get them as their modifications no longer apply to a new version. What they do is "backporting". They grab their e.g. 3.10.108 which was modified to oblivion, then download the e.g. 3.19.0 and check commits which add features they want. They get that commit and apply to their 3.10.108 making it 3.10.109. This is incorrect and broken. But that't not the biggest problem. In case you don't see it: this poses a HUGE problem for using drivers from the vanilla kernel. Often times if you take a driver from vanilla 3.10 you will realize that suddenly doesn't work at all... as in fact they previously lifted a newer one from 3.20 and stuffed it in 3.10. Good luck loading such driver and using it. For that reason alone you CANNOT use vanilla kernel code as you don't know which version of the code has to be used. Sure, there are ways to figure this out, but the only sane approach is to use the source provided by syno. In case of small-ish bumps in kernel it's usually safe to get e.g. driver from kernel from 3.10.105 and fake the version compiling for 3.10.108 hoping not much changed. 2) Drivers modification Syno modifies in-tree drivers directly. To be honest they have no way around it as they apply vendor-specific hacks for e.g. timing bugs in certain chips. They should upstream it but... that's a different story and it's not as easy as it seems. Depending on WHAT was changed in the driver sometimes you can use kernel from a different kernel version. How do you know it's safe? Well... it's hard. If you don't have the sources for the new kernel (since if you did you wouldn't bother lifting the driver from an older version) you cannot know if the data structures changed. If they did you're pretty much toasted. Languages like C or ASM (or hardware in general) doesn't have magical way of discovering sizes of things. Everything is based on static assignment (ok, not everything, but lets make a simplification here). This means if syno decided to add a field to a struct [it's like an object] in mpt3sas driver and that field was added to a struct used ONLY in mpt3sas driver you can probably load the old driver and be fine. However, if they added a new argument to a "public" function (function used outside of the mpt3sas driver) or a new field to a struct used externally from the mpt3sas driver things may APPEAR to work. Every time such function is called or struct is used more and more memory and/or stack gets corrupted. Eventually you will crash something very badly and you will be lucky if that was at least the driver and not something unrelated which was just in the same area. In kernel there's virtually no protections of one piece of code breaking memory of the other. There are small protection for the kernel CODE itself and some sensitive areas but it's not like in the user space where one process trying to write into memory of another process will simply be killed - in the kernel you just corrupt the memory silently. 3) Kernel <=> driver interactions Scrolling through the questions we saw that some of you load drivers and see missing symbols. Well, this is the effect of 2). When they modify the drivers they often add their own hooks by just placing a f... gSynoFoo() call somewhere in the driver. Honestly we think it's very sloppy but it is how it is. The issue here is two-fold: if you compile a driver from vanilla kernel you will not have these calls so things may look correctly... but these calls were placed there for a reason and other things exepect them to happen. Sometimes the issue may be really small like performance drop or hibernation not working correctly. Sometimes you may step into a data loss with a certain controller which syno fixed in their kernel after getting a possible fix from the manufacturer... you don't know. if you try to add e.g. SAS to a non-SAS model things break badly. This is because it's not as simple as flipping the flag in synoinfo. By doing so you're telling the DSM "this model supports SAS". But the issue here is that models which REALLY support SAS have A LOT of code which is compiled only and only when the kernel config option for SAS was enabled. This config option being disabled literally REMOVED a bunch of code from many places when they compiled the kernel without SAS support. That's also the reason why getting SATA boon on 918+ was so challenging as the SATA-DOM code is literally removed on 918+. Bottom line is don't try to activate functions which depend on the kernel features being present. You can tweak number of disks, supported number of cameras and other user-land features but not re-enable features which are partially kernel and partially userland. It's like trying to pump diesel fuel into gasoline car after drilling a larger hole to fit the bigger diesel nozzle into the tank. There's no straightforward way to KNOW if the feature you want to activate has a kernel component. However, going through ALL options in synoconfigs/KConfig.* files will give anybody an idea what sort of things can or cannot be activated. In general anything involving in-kernel drivers is a no-no (e.g. iGPU acceleration will not work on 3615xs most likely but NVidia GPU probably will). 4) Data structures missing in toolchains for in-tree drivers You cannot get the code of a in-tree driver and compile it against the toolchain. This is because in-kernel drivers have access to many more things and link internal kernel files. Should they? Most likely no. However, the kernel is 30 YEARS OLD codebase and only recently they started to encapsulate drivers from using internal things. In most cases it's better to stick to the hardware which is officially supported. We have v7 sources for geminilake which we took some hints from (e.g. about synobios structures). If there's a particular driver we can look and compare with v6. However, if there's anyone who has experience with drivers (@IG-88?) we can share the archive in a PM as syno pulled it from SF. Why they did pull it? It's possible it contains code from e.g. broadcomm which is under an NDA and should never be published as it's not GPL.

We think it should be 1 driver = 1 extension. This way you install driver for your ethernet, driver for your GPU, and a driver for your USB 3 chipset. This will also let us do another cool thing down the road: provide a small image which will boot on your hardware, scan it (essentially grab vids & pids), and suggest a platform and drivers needed to make it work. VID & PID info are embedded in the drivers on linux anyway so it's easy to extract. If you pack many drivers in one package you can easily run into conflicts and load way too much. Jun's loader loaded a ton... literally all modules. In a system with just extra.lzma to get virtio we see 178 kernel modules - mptsas, mpt2sas, mp3sas, vmxnet, megaraid... and many many more which have nothing to do with the platform. Of course, naturally some drivers will have multiple kernel extensions as it makes no sense to separate them. For example VirtIO is technically like 5 drivers but we never saw anyone using just VirtIO-SCSI but not load VirtIO-NET. With some HBAs it may also make sense to make a bundle containing like 3 drivers for LSI cards. But definitely bundling e.g. VirtIO and LSI woudln't make sense. It's a delicate balance Same for CPU governor: for example we don't need it at all as we either want performance on a bare metal server-server or run it under a VM. This is why we didn't want to bundle it as many folks will not use it. To be honest the concept of power management on Linux is slightly foreign for all of us as we either lazily use Dells supported by Ubuntu or run Linux on servers which don't really care about PM.

About the change with + => p is essentially keeping with the same translation layer as in the kernel so the models are named in the exact same way (and that we don't have special characters in file paths ;)). As for the calling in docker we were thinking about something even simpler. Since we're playing with interactive interface it will be nice if users can just run the command in the container instead of editing a file. This is why ext-manager.sh script self-manages files based on commands. So that the author of an extension can just say "just call add [URL]" and call it a day. The "extensions" in the user config is something which we normally don't expect to be used as we wrote in the docs. This is only for a case where user has some interdependent extensions (e.g. you need to load thunderbolt driver first to then load RAID enclosure driver). The bundled-exts is even rarer of an occasion - this file defines extensions which are integral parts of the loader as we want to extract the LKM into an extension to make things simpler (similarly how we extracted VirtIO). So to give you an example how we think it can work: $ docker run -d --name rp -t ..... $ docker exec rp extension add 'https://.....' The output of ext-manager.sh add 'https://.....' $ docker exec rp build foo bar The output of build-loader.sh foo bar $ docker exec rp extension info test_dev.test_ext The output of ext-manager.sh info test_dev.test_ext It's actually simple - just symlink the .sh to /usr/local/bin/extension and /usr/local/bin/build. That way the docker just proxies the commands and we don't double the docs. It will also be simpler overall as we then have a unified interface. This also helps with one change which we have already planned: the add command for now accepts URLs but want it to accept URLs, names, and aliases. This way a user will be able to do "extension add trusted-dev.hp-222". As we mentioned in the previous post with time we want to also add (probably automatically) detection of VIDs & PIDs to the extensions so you will be able to essentially do "extension add fff1:fefe" and get the driver you need. When we get something sensible (i.e. not bash) we can also help users with settings manager where they can simply do "docker exec user-set vid 1234" ... "docker exec user-set mac1 00ff....". WDYT? Do you have file /.no_synoboot? If so then check dmesg to diagnose WHY the synoboot is not appearing.

Hello! TL;DR: We've developed a new loader for v6.2.4/v7+ which contains a way to install custom extensions/drivers/mods. We're looking for feedback of the extension manager & kindly asking for drivers to be made compatible with it. First of all, let us thank you guys for all the driver packages you were always preparing - we used them ourselves. As some of you may be aware we are developing a new loader called RedPill. There's a long thread in the developer's section of the forum: Today we've added a long-awaited functionality of custom drivers. We've chosen to go with a more modular approach rather than offering a clone of Jun's loader functionality of extra.lzma archive. Our solution relies on a simple extension manager which is responsible for downloading and packing drivers automatically. This lets users install only the drivers they need while also mixing-and-matching multiple ones. With "extra.lzma" the limitation was that users either had to build their own packages or choose between having the HBA driver or VirtIO driver... that, in our opinion, was a poor experience. Additionally, the new format allows you to keep a single git repository containing both the metadata for RedPill extension manager and the build environment you use to compile drivers. We would like to collect your opinion on the new extension manager we created and ask you to port your drivers to the new format. We prepared two documents: https://github.com/RedPill-TTG/redpill-load/blob/master/docs/extensions-overview.md (summary of what the extension manager is capable of and how to use it manually) https://github.com/RedPill-TTG/redpill-load/blob/master/docs/extensions-for-devs.md (document intended for people creating extensions/compiling drivers detailing the architecture) In addition, we published two packages, which can serve as an example: https://github.com/RedPill-TTG/redpill-virtio (VirtIO driver) https://github.com/RedPill-TTG/redpill-boot-wait (shell-only package; this will be similar to how e.g. a CPU governor mod can be implemented) There's currently no central way to discover packages but is it planned. For now we're simply collecting links to indexes in a separate git repo - https://github.com/RedPill-TTG/redpill-extensions - you can just toss a link there from the GitHub web UI without cloning the repo. What do you all think? special cc @IG-88 p.s. We didn't post this in the driver's extensions subforum as this topic isn't intended for users. When some drivers are built and the official beta version of RedPill is published we will create a separate thread there.

Did anyone said drivers? You said you wanted drivers - we are delivering on the promise to find a way to get them to you. Today's release brings, what we believe is, a huge update to the RedPill as a project, and we hope to the community and the ecosystem around it as a whole. TL;DR We're introducing a decentralized extension manager into the RedPill project which is able to automate drivers installation. If you're a user, and we didn't screw up badly, just update to the newest release and nothing should change just yet. Soon you can expect your custom drivers to be added with a single command. Wait, did you just built... a package manager?! Yes, yes we did. In short after reviewing multiple solutions like ipkg nothing fit the bill with what we actually needed. The distribution of drivers and shell hacks is a pretty unique use-case. We needed to make it work in the minimal initramfs environment. It is not as crazy as it may sound, but the planning for that move was ongoing for quite some time. We mentioned it here and there in passing, that was part of the reason why we discouraged from just blindly stuffing drivers into the core ramdisk and hacking the scripts as we sort of knew what's coming soon However, as you probably realized by now we try to underpromise to avoid disappointment. Lessons learned from the history & other projects Previously used loader by the community (Jun's loader) used a system of a single ramdisk-like "extra.lzma" archive. This method, while worked, lacked flexibility and required hand-assembly by the packers. As we observed this lead to multiple versions of the whole loader image floating around - some with VirtIO, some with ethernet drivers, some with SAS HBA drivers, some with VirtIO **and** SAS HBA... Additionally, while reporting problems on the forum people usually reported whether they "used extra.lzma" which without the context was limited in information. In addition, to add extra functionality beyond kernel modules, a custom hacks had to be developed. The extension management shipping with the "redpill-load" hopes to alleviate the pain of packing and managing all extensions and mods. During the design process we took inspiration from both the Xpenology and Hackintosh communities, attempting to bring what's best. We set the following objectives while developing the current version: as simple and as automated as possible for users in practice users need only a single "add" command and a URL to add an extension updates are checked any time a user builds a new image updates are offered not only on per-platform basis but extension can be updated for the currently existing platform (however, this still requires image rebuilt) if no interdependent extensions are installed users don't need to do a thing as by default all added extensions are added to the image no more manually sharing zips over Mega or in attachments needed easy for developers/packers the most basic extension requires 3 files: index file, recipe file, and the file which is delivered JSON configs were organized such that it's easy to maintain a repo with multiple versions of them (more on that in the documentation for developers - see below for a separate thread) the structure is designed for maximum reusability and extension error-proof most errors are meant to be self-fixable (even if user caused them) when an error is displayed it tries to offer a reason and a possible way to fix it (like in `git`) all extensions offer multiple links pointing users to the correct place (do they have a problem with USING the extension? or maybe they have a problem with it being unstable? or maybe they want to see the forum thread where they can ask the author questions? => it's all supported) the code will prevent users from creating an image with a newer version of OS if extensions they rely on are not updated (as what's the point of updating to a new OS release if your ethernet driver doesn't work yet?) flexible in nature at first, we jotted the idea as delivering kernel extensions/drivers, but we quickly realized it's not enough the current (early) version allows for pretty much any customization of the OS before it's booted with custom scripts (e.g. changing CPU governor) current implementation is more a PoC (that's why it's a messy shell script monstrosity), but with feedback can be eventually built to a much higher standard; more on that below decentralized we don't want to exert any control or force anyone to do anything: this is our goal from the beginning the extension manager is designed to be not only open-source but open in nature. We deliberately don't offer any centralized repository and simply rely on community and the trust within it to offer a quality contribution the system is fully anonymous: we don't collect any statistics, nothing is sent to any of endpoints controlled by us We need the community support! This is a calling for developers & packers which normally provided drivers in the extra.lzma format to also consider providing drivers in a form of RedPill extensions. We hope we don't ask too much here but we know without your support and hard work plenty of things would never be possible. We certainly don't have the manpower to provide drivers for all network cards, HBAs, GPUs and other things people use. To filter-out the noise we created a separate thread to discuss the extensions manager and get suggestions from the developers itself: We created a separate thread to let people compiling drivers & preparing hacks get notifications of a lesser volume than here. Currently available packages As a proof-of-concept we didn't create just a throwaway example extension which isn't actually usable. Instead, we extracted the VirtIO driver into a package: https://github.com/RedPill-TTG/redpill-virtio In addition, we added a small new package which is shell-only (hint: someone can easily base the CPU governor package on it ;)) which blocks the boot process until /dev/synoboot is ready and is more useful in leaving a log as this seems to be one of the most popular problem users are facing. See https://github.com/RedPill-TTG/redpill-boot-wait for details. Both packages mentioned above are autoinstalled. In the future the VirtIO package will be optional (as it does nothing on e.g. ESXi or bare metal). The RedPill LKM will be an extension itself in some time as well (but for now we didn't want to break the @haydibe docker and forking scenarios until we have a good solution for that). The future The current extension manager is conceptually an MVP and can be used. It provides the basic functionality expected from a package manager and delivers the most important thing: drivers. However, this is definitely not its final form. Our goal now was to get it to the usable state and ensure the format of packages will not need to be changed (putting burden on people providing drivers) but rather enhanced as needed. The current biggest hurdle is the fact the package manager is written in bash, along with the loader generator. We're already prototyping a much better solution The end goal is to have a user simply start a docker image on any OS (whether it's Linux, macOS, Windows, or... DSM itself) with a single command and get a web interface where the loader can be generated, updated, and customized (similarly to how you do in the Hackintosh community). Packages discoverability While the packages are (and will be) decentralized we are already thinking about a better discoverability of packages Ideally we want to model a [much simpler yet similar] system to npmjs or packagist but server straight from a github repository anonymously and safely Discoverability will let us provide a small bootable image which can simply scan the hardware and tell you which packages you need and if maybe some hardware is not supported at all Currently we're simply collecting links to indexes - https://github.com/RedPill-TTG/redpill-extensions - some form of static generator with a list will come later So, what do you guys think? //parts of this post were incorporated into the documentation in the redpill-load repository - if you're reading this after some time it's better if you head to the repository directly and see the documentation there as things probably have changed: https://github.com/RedPill-TTG/redpill-load ========================= Yes, we promised to respond to all the posts - we will That last week was unusually busy - we will try to be better about that. ========================= Note to @haydibe: we tried not to break the docker toolchain - can you triple-test? We also left a separate env variable called MRP_SRC_NAME which is used instead of "./ext-manager.sh" when displaying any help/error messages in the extension manager. You may want to replace it with docker command so users aren't confused.

Update time! 💊 This week the updates are going to be less exciting but nonetheless very important, and the first point talks about that in more details. THE BUILD HAS CHANGED - READ ME We're putting this as the first and in red so people see it. The LKM build now requires a version to be specified. We know this will break the @haydibe toolchain but we're sure he will fix it quickly as this is a small change. For reasons why read further. Also, if you used a hack to "fix" the Info Center on 3515xs make sure to read "Hardware monitoring emulation" section carefully. A roadmap Lets first address why this week is less exciting: we spent most of the time testing various scenarios and tracking hidden-yet-missed bugs. This is most likely the second to last round of updates before we release a beta version. The beta version can be used in a day-to-day testing and should be free of dangerous crashes (ok, maybe except that strange kernel lookup - we're looking into it). In the beta some features may still be missing but overall we're already testing a few instances and it's looking good We don't have an official roadmap as someone here asked. However, this is the rough list of things we want to address in that order: Custom drivers support*: there's a hack discussed here to add drivers to a ramdisk. However, this isn't a sustainable solution for many reasons. Mainly the reason is a very limited size. The current ramdisk, especially on systems without compression, is almost at the limit and on slower systems can crash with even a few megabytes more added to it. This seems to be especially unstable on v7 Linux v4 kernel. The solution we're working on will simply include modules on the partition which are loaded in pre-boot and copied to the main OS partition on boot. Naturally from the perspective of the user it will involve simply adding a line to user_conf and dropping a file in "custom". For people digging deeper it will be also much easier as this involves no repacking: simply mount the partition and drop more files in and they will be copied 1:1 and loaded as needed. Full SAS support*: while cheap HBA cards are great and something we actually will recommend for home builds (as they're cheap, stable, and offer 4-6 ports), LSI is king for bigger arrays. We want to make sure these are working as intended making both DSM and Linux happy (which isn't easy in v7 ;)). UEFI support*: there are board which cannot boot in legacy mode. We want to fully test this and offer an official UEFI support in the RedPill. Add support for newest revisions of the OS to 918+ and 3615xs* Step-by-step instruction*/**: essentially we want you guys to help us test not only the code but also a guide It will be published alongisde the beta version. We will prepare it in a form of a GH page so that we can easily incorporate feedback (as we cannot edit posts after ~1h). After we resolve problems with it we will go ahead and publish an RC version on the main forum so that it becomes an official version released for usage by less experienced folks who still want to poke around the OS. Integrate build process into the main repository**: @haydibe is doing an AMAZING job here and we cannot thank him enough. As we discussed with him before we want to incorporate the docker directly into the redpill-load repo and enable LKM builds on GH, so that everything is automated and synchronized as soon as we publish an update. Small fixes: add native support for CPU governor, fix CPU detection to match the model (as some things on v7 react strangely if the CPU doesn't match the model), fix various internal code-smells in the kernel code Add support for GPU acceleration: in short we want to explore adding platform like DVA3221 AMD support: let's just say we aren't fans of Intel recently We want to add a model which natively supports AMD CPUs Work on making mfgBIOS LEDs/buzzers/hwmon stuff more real or at least publish an interface which can be used by others to add an arduino or similar. Things marked with * are aimed to be done by the beta release. Things marked with ** we are HOPING to get done before the beta but we cannot promise Fixed I/O scheduler not found errors Many people reported these, and we finally found some time to look at them. Fixing them should fix the disk scheduling and improve performance in some scenarios. All in all you shouldn't ever see them from now on. Commit: https://github.com/RedPill-TTG/redpill-lkm/commit/aaa5847c589b84783471f9a600eeb12fbf2dc31c Hardware monitoring emulation One of the big features boosted by syno in v7 is central monitoring. However, with that it looks like in v7 the hardware monitoring and things around that has changed a lot from v6. In short v6 allowed for things being out of whack here and there with the hardware sensors while v7 assumes all sensors are in order... and when they're not things break unexpectedly. For example that bug with General tab not loading in Info Center was just a tip of an iceberg. It was just a symptom of a MUCH MUCH bigger issue. If you do "cat /run/hwmon/*" on a DSM loaded with Jun's loader you will get: # cat /run/hwmon/* { "CPU_Temperature": { } } This isn't going to fly on v7. The Info Center is just the beginning of problems. High scemd usage at times was also caused by the lack of hwmon emulation (which again, wasn't strictly needed on v6). After painstakingly analyzing the synobios.h from the kernel and toolchains while also scratching our heads at how one of the drivers for ADT chip (fan controller on a real DS) was modified we think we've nailed it: # cat /run/hwmon/* { "CPU_Temperature": { "CPU_0": "61", "CPU_1": "61" } } { "System_Fan_Speed_RPM": { "fan1_rpm": "997", "fan2_rpm": "986" } } { "System_Thermal_Sensor": { "Remote1": "34", "Local": "32", "Remote2": "34" } } { "System_Voltage_Sensor": { "VCC": "11787", "VPP": "1014", "V33": "3418", "V5": "5161", "V12": "11721" } } The output above comes from a 3615xs instance. On 918+ you will see only CPU_Temperature and hdd backplane status as physically 918+ does not monitor anything else. You can read more about that in the new document in the research repo: https://github.com/RedPill-TTG/dsm-research/blob/master/quirks/hwmon.md All values above are fully emulated as on a VM we have no way of reading them and on a real hardware the only standardized one which we can pass along is the CPU temp (as voltages and thermal sensors vary widely between motherboards). We have a "todo" to make CPU temperature real on bare metal. The ugly part, which forced us to change the LKM build to require major version of the OS to be specified, is that syno changed so many things between v6 and v7 that they forgot to make proper headers. As you can see in the https://github.com/RedPill-TTG/dsm-research/blob/master/quirks/mfgbios.md document they just like that moved two fields in the middle of the struct. You never ever do that. Not without at least some ifdef (which they did for other things). The issue is that change we've found is not present in all toolchains, it's not documented anywhere and we discovered it by accident by comparing files. There's really no sane way to detect that (we've tried really hard). This is why we were forced to add (ugly) requirement for v6/v7 to be specified while building the kernel module. If we find a saner way we will go back and make it automatic again. With the hwmon being emulated there are two VERY important things: you CANNOT disable "supportsystemperature" and "supportsystempwarning"! The hack someone posted here with sed - https://gist.github.com/Izumiko/26b8f221af16b99ddad0bdffa90d4329 - should NOT be used. We cannot stress this enough. Anyone who used it and keeps the installation MUST put "supportsystemperature: yes" and "supportsystempwarning: yes" into user_config at least for a single boot. This is because these values (with =no) are now baked into your OS partition and you MUST fix them to the default "yes". As the loader script doesn't have them specified anywhere it will not touch them anymore. you CANNOT disable ADT support. This comes back way to the Jun's loader and deleting "supportadt7490" on 3615xs. If you're not installing from scratch on a new disk but playing with the same on you MUST put "supportadt7490: yes" to your user_config at least for one boot. Commits: https://github.com/RedPill-TTG/redpill-lkm/commit/72cb5c3620711bcabcfe6e1c67ebfbeca6f7e6bf (mfgBIOS structures v6/v7 changes) https://github.com/RedPill-TTG/redpill-lkm/commit/16adab519d6c4cc604e3fb680fb041e8ddd2167e (HWMON definitions) https://github.com/RedPill-TTG/redpill-lkm/commit/7d95ce2ec7d35493227196be58bbd2c7ca2704f8 (HW capabilities emulation) https://github.com/RedPill-TTG/redpill-lkm/commit/014f70e7127abdf28b47fe58f35086296b5d78ca (HWMON emulation) https://github.com/RedPill-TTG/redpill-load/commit/78c7bf9f903a73d51013a859f590c09ee835f8e7 (remove legacy ADT hack) Fix RTC power-on bug On 918+ the scemd complained about auto power-on setting failing. Now this is fixed and scemd no longer triggers an internal error state. This was happening when OS was sending an empty schedule. Commit: https://github.com/RedPill-TTG/redpill-lkm/commit/80a2879aae23d611228c8791b35e237bfa0ec7a8 Add support for emulated SMART log directory This is an internal change in the SMART emulation layer. Syno uses slightly out-of-spec approach (again, hello v7 mess) and assumes all disks implement one of the ATAPI functionalities which is actually optional. This may actually cause some real disks to fail as well on a real v7 so they will probably eventually fix it themselves. For the time being we did it in RP. Commit: https://github.com/RedPill-TTG/redpill-lkm/commit/278ee99a4dcb8fb8f025915118e7df93824e9bfc ------------------------------------------------------------------------ Today's update is rather short as HWMON layer took us a ton of time to properly research and figure out how to actually do it. There were literally 5 different implementation until we got it right. That being said the forum deleted our responses to comments which we were typing here so we will write them again... but probably tomorrow morning. We will try to sit together tomorrow morning (ok, developer's morning ;)) and write responses again. @WiteWulf Can you try deleting the line with "register_pmu_shim" from redpill_main.c (in init_(void) function) and rebuilding the kernel module? You can then use inject_rp_ko.sh (lkm repo) script to inject it into an existing loader image or rebuild the image. With that you shouldn't have PMU emulation anymore (so the instance can be killed in ~24-48h) but we can see if it's kernel panicking.

New release update! 💊 This is the biggest release to date and ESXi users will be especially happy to see it! SATA boot support for 918+ (and others) Remember how we said it's nearly impossible to add SATA boot support for 918+ as the kernel physically lacks the code to support SATA DOM on that platform? Well, we've said NEARLY impossible as we had an idea but didn't want to disappoint anyone if it failed. It didn't. With this release we're introducing a SATA boot support for platforms which natively lack the support for it. This is mainly aimed towards hypervisors without emulated USB support (looking at you ESXi). How it works is rather crazy: we're taking the SATA drive and masking it as a USB drive just for a short while to fool the SCSI driver into giving the drive a correct type (but not long enough to cause problem with reading the data). We weren't sure if this can even work or how good it will work. It turns out it does work, and it looks to be stable. However, due to the nature of this code we're only recommending (at least for now) using it when there's no other way to boot. A physical USB flash drive passed through to a VM will be a better choice. Keep in mind this does not apply to native SATA DOM (e.g. on 3615) - this one is as stable, if not even more, than USB. You can easily distinguish which mode is used by looking at boot parameter "synoboot_satadom": native DOM will be synoboot_satadom=1 while this emulated one will be enabled with "synoboot_satadom=2". Technically you can actually use this emulated mode on platforms supporting native SATA DOM (not that there's a reason). For details see the following commits: https://github.com/RedPill-TTG/redpill-lkm/commit/de5099c01564e5193860f51f448702d2fa165df5 (main module code) https://github.com/RedPill-TTG/redpill-lkm/commit/1a3039f3b030b4351b23ba4e909e6232d9a58228 (refactored SATA DOM shim) https://github.com/RedPill-TTG/redpill-lkm/commit/061b3e643d4bca663f24fb3dee397ecb77d8e44c (naming change to avoid confussion) https://github.com/RedPill-TTG/redpill-load/commit/15feb4b6e8651d77be19d18b936e8aba780520ab (redpill load support for SATA on 918+) Disk SMART emulator One of the biggest issues reported was the inability to create pools on ESXi (or any VMWare products). This bug was traced on GH as well: https://github.com/RedPill-TTG/redpill-lkm/issues/14 . There were multiple theories and the community stepped up and came up with workarounds. However, this state wasn't sustainable for a long time so we went digging. Oh boy. v7 made a lot of changes in how disks are handled. One of the biggest changes is that now all drives used by the system in pools must support SMART (and actually multiple parts of it). Without that things will break horribly, even if a workaround is used to create a pool. The pools creation worked on Proxmox only because QEmu actually emulates a minimal (but sufficient for basic operation) SMART support for all its virtual drives. With this release we implemented a full-blown emulated support for SMART on any drive which doesn't support it. The module makes everything glow green and report no problems. Even the health tab and automatic SMART tests will not cause any problems and appear as they were really executed. Obviously the emulated SMART has no diagnostic value and the drive should be monitored externally. The SMART emulation goes beyond being useful under ESXi. We've identified three main scenarios where the SMART data is/can be missing: running under ESXi (it doesn't support SMART at all) running VirtIO disks connected to SCSI ports (see below) using RAID cards which don't work in a real HBA mode With the commit https://github.com/RedPill-TTG/redpill-lkm/commit/d032ac48c00f78b11516f2f2112970bc51bf68be out of the way we can officially confirm full support for ESXi. We didn't close the issue on GH yet awaiting feedback. Added support for SCSI VirtIO ..and there's more disk updates in this release! Proxmox (and all other VirtIO-enabled hypervisors like QEmu, libvirt [used in e.g. unRAID], or VirtualBox) allow the drives to be passed as either SATA or SCSI. There are technical differences between them. However, the main one while actually using it is that you can add up to 6 SATA devices (0-5) while SCSI allows for up to 31 (0-30). This release adds the support for VirtIO SCSI drives. This includes SMART emulation described above as well, as QEmu doesn't provide SMART for non-SATA devices. As SATA devices ultimately use SCSI protocol and share the vast majority of the protocol we simply convince the OS to treat VirtIO SCSI drives as they were SATA. This isn't really a hack. The official syno kernel does the same thing BUT only for "NEXTKVMX64" platform (VDSM?). We simply retrofitted that feature to work on all platforms. You can also use an SCSI drive for booting and mix SATA & SCSI disks as well. The core functionality can be found in the commit: https://github.com/RedPill-TTG/redpill-lkm/commit/2ce06db3ef69b6ea28c49754c101fd0832abec04 SCSI drives monitoring subsystem This is more of a dev-only functionality, but lies in the core of all the features described above. In short, Linux kernel contains a mechanism for publishing and subscribing to events. Unfortunately it's a rather new and niche subsystem. The SCSI driver, as one of the oldest parts of the Linux kernel, doesn't support the notifications. In order to react to new drives being connected to the system we developed an extension for the SCSI driver adding that functionality. We will probably pursue upstreaming of these changes, so one day they can land in the kernel natively. For details see the following commits: https://github.com/RedPill-TTG/redpill-lkm/commit/098bae23fe21ccd495e57b846539704899fda639 (add the notification subsystem) https://github.com/RedPill-TTG/redpill-lkm/commit/ccc58c0883c3f0cc8a8599918cc0d5cd9491f678 (extract common SCSI functionality to a submodule) Multiple build modes & hiding from the system The previous version of the module was always built in the dev mode. In addition to being heavy at whooping 4MB, due to the debugging information included, it also contained extensive logging and multiple exported symbols. With this release made substantial progress in hiding the module from the OS. Now the module can be built in three different modes: dev: all debug symbols are included, standard debug messages are printed. This is essentially the current mode as it is. It's still the default one when running make without parameters test: module is stripped from debug symbols and displays only warnings, errors, critical and BUG messages. This means the output is significantly reduced while still allowing to catch problems occurring. This is the recommended mode to run on test installations. However, when reporting bugs we will prefer to get the output from the dev build as it contains much more information of what lead to the bug. prod: module is fully stripped from debug symbols, contains absolutely no logging, and in addition it makes an effort to hide itself from the OS. It will not be visible in the lsmod, it will not publish its symbols in /proc/kallsyms and once loaded it cannot be unloaded. If it crashes in this state the stack trace will point to an anonymous kernel address rather than to a loaded module. For details see the following commits: https://github.com/RedPill-TTG/redpill-lkm/commit/960ade5ea759105954afa5fcb0bfc15e31e51656 (logging is stealth-dependent) https://github.com/RedPill-TTG/redpill-lkm/commit/41f11eee29191bea475120e94dae9a5938592e23 (hide module in stealth mode) https://github.com/RedPill-TTG/redpill-lkm/commit/5da6629cc5afad983a9d31a041c109cae4c705ea (raw printing disabled in stealth) https://github.com/RedPill-TTG/redpill-lkm/commit/04865d444f4cb79877f4527ba3e757583a5634a6 (multiple build modes) https://github.com/RedPill-TTG/redpill-lkm/commit/690c92ab60321e12ad9024a6b91b2c8ce29b19e0 (remove identifying information from module file) Why the correct compiler is so important? We had a discussion here some time ago about using different GCC versions and playing with different configurations. We've got a tangible example now, which made our blood boil for a good whole day. The code which is native to the kernel triggered a bug in the GCC itself: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63567 In short this problem wasn't present in earlier versions of the GCC, but it is affecting GCC >4 and <5. This is a serious problem as the module is written with C99 in mind and the bug occurs when code is compiled in any mode besides C89. Well, normally you would upgrade your GCC. However, Linux <3.18 will NOT compile even with GCC 5.0 - the absolute latest one is 4.9.x. The workaround we've used was to extract the offending piece of code to a separate compilation unit compiled in C89 mode where rest of the code is still being compiled in [sane] C99 mode. We're leaving this story as a warning how compiler version can have big effects on even code which is written in a clean manner. In the C world, despite so many years of advancements, there are still monsters in the closet like that -------------------------------------------------------------------------------------------------------- Assorted smaller changes & fixes we've made: Fix RTC scheduling crash When auto power-on scheduling was modified in any way the action triggered on platforms with no native RTC support (e.g. 918+) was causing a soft-crash in the RTC proxy. It was reported in https://github.com/RedPill-TTG/redpill-lkm/issues/17 and fixed in https://github.com/RedPill-TTG/redpill-lkm/commit/29637db757d8ad0240e161136db814d5bfd31c33 Fix SATA DOM shimming on older HDDs Some older HDDs (and possibly some real SATA DOMs) don't implement so-called CAP16 command used to query the capacity. Due to a bug in our capacity estimation code the CAP10 fallback wasn't triggered for disks without CAP16 support. Now this is fixed and capacity should be detected for all drives properly. Related commit: https://github.com/RedPill-TTG/redpill-lkm/commit/524690549cb7cad96de50cc350a9e13f520f53fa Fix execve() debugging crashes Did you know that Linux launches few thousand binaries every time it boots? We didn't either. Enabling (a very noisy yet helpful) execve() debug mode caused some crashes. It was really about edge cases in arguments parsing. As we are working with the code remembering the Linux code from 1992 some things slip through the cracks. With the commit https://github.com/RedPill-TTG/redpill-lkm/commit/1a6665bc71f7a73b02a3c150aad746d359caf9a4 the debugger shouldn't cause crashes. If you experience it let us know via an issue. GCC warnings are now gone To avoid confession (which was reported here and on GH) while making the code overall better we went ahead and fixed all GCC warnings. One of the main ones was the validate_nets cropping up on all platforms: https://github.com/RedPill-TTG/redpill-lkm/commit/0a91024b5ed4e51382015d098f0c4ed04417700f Transition to new override symbol is complete As mentioned in the previous post new, more stable and faster, override symbol logic has been implemented. Now it's used across the board. Old method has been completely removed. In the process we've also found a rare set of circumstances where the override could fail completely and crash the kernel. This has been fix as well. For details see the following commits: https://github.com/RedPill-TTG/redpill-lkm/commit/bca616c134b6ad95f92b0caf6ff2481356c5cbc7 https://github.com/RedPill-TTG/redpill-lkm/commit/b08f6a8c932abce00349ff4e152593be1072b565 https://github.com/RedPill-TTG/redpill-lkm/commit/479d0050e6a0aad33b7aed54f53a244ae00ff244 https://github.com/RedPill-TTG/redpill-lkm/commit/9ed56540fd2cdf7d0be531709810cde3ab07fea1 More consistent logging To make debugging & reporting from users easier we unified how each shim/submodule reports its state. This also serves as a general clean-up of these logs. For details see the following commits: https://github.com/RedPill-TTG/redpill-lkm/commit/c110c8baf11b1e286f3ba9501d10ed63f7c2e5b1 https://github.com/RedPill-TTG/redpill-lkm/commit/4b164c3500ecfd82e9480e67327e66a0b38be1c0 https://github.com/RedPill-TTG/redpill-lkm/commit/8154a28872a9e3fca3ef9b985bc5a9f07e3d5f94 https://github.com/RedPill-TTG/redpill-lkm/commit/e42a0e6c3beebf0d8da71cef42e0db1001927deb Build env. improvements We've validated and enabled concurrent build for the LKM. Concurrent builds speed up the build times of the kernel module drastically. Commit: https://github.com/RedPill-TTG/redpill-lkm/commit/363f6d4d6459f05f7b49c0e72c8e4e3dddf5690e VMDKs are build in addition to raw images in the mass build script, see: https://github.com/RedPill-TTG/redpill-load/commit/24894ae306648353e71214839e0aac8317e05816 - the only issue here is that these VMDKs doesn't seem to be recognized natively by ESXi (at least not 7.0.2) and require one extra command on the ESXi itself. If anyone knows the solution working on Linux we will be glad to hear it. Due to the closed-source nature of ESXi we have no idea why ESXi dislikes perfectly valid VMDKs here. Oddly enough they work perfectly in other VMWare products. Go figure. The attach/mount race condition which randomly cropped up for some people (e.g. https://github.com/RedPill-TTG/redpill-load/issues/10 ) started happening on one of our member's machines as well. The underlying issue is simply the timing: losetup on linux does NOT wait for the partitions scan, so it's possible that the mount command executes after /dev/loopX has been created but before the kernel had a chance to scan partitions. This issue, funny enough, usually happens when listening to music in Spotify. The fix was dead-simple: https://github.com/RedPill-TTG/redpill-load/commit/cecf8416ee0219f534b976e0879bf7e2923827f7 CLion should be happy again with the code - we've fixed special UAPI include path (https://github.com/RedPill-TTG/redpill-lkm/commit/4b5905039815647508ae7e0305715f1b0bfff923 ) as well as duplicated defs (https://github.com/RedPill-TTG/redpill-lkm/commit/8347a4116217191e31711e72d7d849464e348064 )

This post contains responses to questions from mid-page 47 only and was split due to forum's limitations. To see release updates jump to a post on the bottom of page 55: ---------------------------------------------- DO NOT use vanilla kernel sources to build modules for the DSM unless you know what you're getting into. We cannot stop you of course but you should know it's like playing with fire over a tank of gasoline. Let us explain. Syno, despite the version number attached in the kernel, modifies source heavily. So their 4.4.123 can be anything. They back port a lot of things, they break the ABI by modifying structs in the middle etc... original/vanilla kernel sources are mostly useless in dealing with DSM. Building a module against them and loading it is like playing a russian roulette - it may work sometimes but you never know what's going to happen tomorrow. This is especially crazy if you try to build your HBA driver (i.e. you're trusting your data to a driver built with incompatible sources... one shifted struct and you can lose all your data on all disks pretty easily). If you wanna play with something not important like network card and you check the kernel source for that module in the previous syno GPL releases and confirm it wasn't modified you can try. But again, this is a very risky endeavour. This is an old hack which should never be used for v7. New version of the RP solves the problem on ESXi. This hack is a very very very bad idea on v7. There are some new self-destruction routines which check that. DO NOT symlink synoboot, DO NOT use mknod to fake it. This MUST be done through the kernel. You can ignore all warnings we made but please, don't ignore this one. The link you posted is actually a quite good summary for macOS You should use BIOS boot rather than EFI if possible. Also, 7.0.1 is not supported yet. Check the log over serial console. For the PAT they're always left in cache folder so you don't need to re-download them from syno. ...and this is painful. They ignore GPL left and right. They recently posted sources for v7.... and pulled them after like an hour. There's a question posted on their forum on SF and they're not responding. Faces detection isn't working as it requires a REAL serial number (or someone to patch the new binary, this is outside of the scope of the loader). Login is always root:[empty password] for preboot environment. Later on when the system boots this obviously doesn't work for security reasons. The format of packing depends on the version. Check dsm-research repo under ramdisk document as syno broke the kernel. In general, the rd.gz shouldn't be tinkered with manually without proper knowledge. As we mentioned above FixSynoboot is not part of the RP for a good reason. Synoboot is actually being checked in v7 after DSM is booted. Are there any other errors during the benchmark? In dmesg or /var/log/messages? You should not edit these files by hand... user_config.json contains a provisioning for this and the documentation explains why you cannot edit these files like that (TL;DR: dsm overrides them and they need to be fixed on every reboot, it is done automatically by RP). Small correction: RedPill supports it from the beginning - it is described in the documentation in the redpill-load repository. Again, this is also supported and documented. It's the "extra_cmdline" parameter in user_config.json which ensures options are placed in all kernel boot cmdlines/params and if needed override some default ones etc. To our knowledge the absolute max is 26 as DSM doesn't support /dev/sdaa /dev/sdab /dev/sdac etc. naming. Since there's only 26 letters you can only use 26 disks. Their eboxes work differently and that's how on a real DS you can get >26 drives. This is related to the Map parameters. Jun's loader used a hack to "hide" the loader image - RP doesn't need it. You need to configure mapping properly. This is a good description on how it works: It actually does matter for some things - with invalid MAC the DHCP sometimes doesn't work. That's why it must match. You can try specifying that you have 2 network interfaces and putting your real MAC into one and the one matching S/N into the other. If you're using proxmox however you can put that MAC in the virtual network interface on proxmox and that way you will have a matching boot setting with the actual card MAC. This is actually something we do as we have many VMs on many hosts to boot the kernel but just one user_config. Regenerate loader image. It is corrupted according to the last error message. Keep in mind we don't support 7.0.1 yet. While these errors don't look fatal having a broken filesystem is another complication which may cause problems (and FAT is very prone to being damaged... to the point that syno itself keeps two copies). Haha, nice to see an admin here. It's just 55 pages There's a detailed description of the problem in the ramdisk document in dsm-research repository. TL;DR: syno broke the kernel routines for decompression... [a minute of silence as we don't want to swear in public]. This is the reason why we advise against using versions needing editing of the image by hand. RD.gz compression type is just one of the stupid little quirks to take care of - we automate that to not think about that ourselves. We deliberately didn't do this as we explained before in this thread. Current release is intended for developers and should not be used by regular users which aren't able to run a bash script. We will provide a precompiled modules when (very soon at this point ;)) the project reaches at least a beta state. One person was even nice enough to provide a PR on GH to automate the build (THANKS!). The overwhelming number of posts in this thread are from people who downloaded a random image and started modifying configs inside it without even reading the documentation. When we ask for any logs there's usually silence which doesn't help us solve the underlying issue. Yes, that's normal - if you didn't physically do "rmmod apollolake_synobios" you're good. This is a debug message which is very helpful if a kernel panic happens right after "synobios: unload". mfgBIOS module doesn't handle being unloaded manually. Add it to the extra_cmdline in user_config.json and rebuild the loader image. No, this isn't any official build. If you want to try playing with it you should use the official loader builder (with or without @haydibe docker). However, keep in mind that as of right now the loader is still in the alpha stage (however, beta will be coming soon with precompiled binaries of the module). Sharing full loader images is something which will get people into troubles (as we explained before). THANK YOU!! This is exactly the message we're trying to send - there are hacks, we can load custom drivers, we do that on dev machines, we also do other weird things like restoring snapshots with memory and taking them mid-load or using hardware breakpoints... but this isn't something which a non-kernel developer should ever try. It's like playing with fire. However, ultimately we want a robust solution which does work for most/all of the cases instead of hacking the ramdisk and modifying files to do an insmod... and what if you put a driver which is slightly too large? (ramdisk has a strict limit). Well, the kernel is gonna boot with a partial ramdisk and everything will start collapsing with random errors. This is a nightmare to debug... ask us how we know We're all for PRs and other contributions. We will definitely incorporate the improvement from posts here (e.g. the temperature breaking general tab) but it's way harder when other users start to (often unaware and confused) use other mods posted as attachments here and begin reporting bugs as RP bugs. Your docker image is always nicely documented and robust contributing to a great value here. However, some other mods* asking people to mount images and edit menu entries for grub ends up in broken installations as it skips the whole process and all the checks left in place for a reason. There are very good reasons why we're not sharing complete images and why we spend many many many hours developing the generator. The RP started in a different thread, its code was shared in different GH repos, the initial work wasn't done by us... and it's now unavailable. Full loader images contain way more than the GPL kernel. They contain syno's proprietary and copyrighted binaries. Distributing them is... problematic at best. *for the record here: nothing personal against anybody, we don't even remember nicknames half of the time as there are so many posts. We don't mind if someone publishes a modified version. It's just that it's incredibly hard for us to support modifications which are published as binaries with no instructions, a PR, and directly contradict the process we develop for building images. We love contributions, we run RP as an open-source initiative for a reason! We only try to limit confussion of less experienced folks We're thinking about looking at one of the nvidia-based ones as they support both nvidia and intel quick sync. Especially that on an AMD system you can get something like Quadro P200 for cheap and have 7 streams of HVEC with little CPU usage. This is one of our big things - with AMD being so affordable and so powerful now... it will be great to have support for it. The biggest roadblock are S/N generation methods. The generators we've seen from the community support 3615/918/3617. Is there any description on how these S/N are generated? How these values were discovered? The redpill-load has a mode where you can repack the kernel and let it continue. The resulting bsp can be bigger or smaller depending on the compression results (as the bsdiff should be run on compressed image). As long as it's a proper diff the size doesn't matter here. The REAL changes are just a few bytes - the resulting bsp is bigger than that due to compression and bsdiff header. For details as to how to "be guided" to build a new platform look at variables on the top of build-loader.sh file. You need to set BRP_LINUX_PATCH_METHOD=repack and few others (set this one - it will tell you which ones are missing) and then try to build an image of a platform which has no .bsp file. It will go up to the kernel patching, stop and let you patch the kernel. Then you restart the same process and it will detect patched kernel and recompress it etc. In the end it will leave these two compressed files for you to bsdiff We want to have proper docs for this but it's all about time and number of hands Does it even matter what DSM shows in the settings for network speed? For VirtIO it shows Unknown or 10/100 while everything is working at few Gb/s. We will simply try iperf3 test and check if the speed is really <=1Gb/s between DSM and some other host and then try to tinker with it. If it's >1Gb/s it doesn't matter if the panel shows 10/100/1000 as this isn't really read directly from the interface or driver. Hm, can you describe what you've changed to make the EFI working? (sorry if you did and we've missed it in the sea of posts) We don't want to unnecessarily duplicate the work if you made it already We think it just needs the new template image for the GRUB which supports EFI boot as the syno-specific files are copied anyway (whether GRUB supports EFI boot or not). Hm, that can be tricky then as AFAIK syno kernel doesn't support serial over USB. Are you able to see it connecting to the network at all? (e.g. on your router's DHCP leases/clients table). Thank you for the offer We have a few LSI cards but currently none of them is in any of the servers which we can play with. It just happens that for pure HBA we usually use cheap SATA cards and not good LSI controllers (as they need flashing in IT mode and not all of them play nice with SMART etc). Good question. Can you try unpacking the update PAT (use tar -xvf FILE.pat) and seeing if there's a different zImage inside? If there isn't you're good to go to just update.

Continuation of questions starting from mid-page 37 (forum doesn't allow for more than 50 quotes per post): You cannot change that - that will require rebuilding of the kernel which isn't possible (as syno doesn't share compilable sources of the kernel). You theoretically can use mknod but this causes problems with v7 (synoboot used to be done this way on 918+). Stay tuned: we will figure this out Yeah, Linux and md doesn't care - only the DSM has some hardcoded assumptions for paths which we need to emulate You don't need a real S/N to run it. Some services (e.g. faces detection in photos) need it but rest of the things don't. What's important is not using the same S/N for multiple people because sooner than later they will start blacklisting them. Today's update should make ESXi working. [will be posted on GH after we finish writing all of the posts] Do not use ready-made images. You don't know what's in them nor we can help with those. Additionally, posting them here is a substantial risk as, unlike the generator, full images contain copyrighted materials which cannot be distributed legally. We will not go into details but the RP project started in a different thread... with different repos... by a different author... none of that is accessible anymore. Add 2 and 2 yourself. We only see a one big problem here - an EFI is being added on the side but nobody opens a PR for it. Instead, there are random zips flying around. Nothing against you (your help with docker is amazing!). However, soon we will not be able to help with issues as some of them stem from people running a modified version grabbed from an attachment... Do you have details how you triggered that error? We didn't look into 7.0.1 yet. It should be working with the new release today [will be posted on GH soon after we finish all posts] It does now - today's update adds this. That is perfectly normal when compiling modules against kernel sources which weren't compiled in that directory. In essence, it means that the kernel cannot determine dependencies between multiple modules (which is important for e.g. distributing a driver for Ubuntu, but here it doesn't matter at all). Fixed in today's release - that warning is actually an old GCC artifact but we worked around it with a slightly different syntax. Try the port INSIDE of the case. HPE bios on microserver is strange sometimes. S/N must be unique (can be generated but must be unique); MAC is needed for DHCP. You should not edit the grub config manually. You need to put it as a disk image, not an ISO image. These are quite different - that's one. Second you have a syntax error somewhewre but the forum replaced bunch of characters. You need to post in a code block tag so the forum doesn't replace anything. What CPU do you have? If it just hard-reboots it means the CPU just crashed, which usually means that it doesn't support some instructions. If you dd the raw image (dd if=file.img of=/dev/rdiskX => make sure you sure rdisk and not disk) you don't need to manually modify the partition. Before you do that you should check the disk with diskutil list to get the number and unmount all existing partitions using diskutil unmount (not eject from the Finder). This is actually posted in the research repo. However, we strongly advise against manually tinkering with the rd.gz file - the loader generator can copy files where needed. It's better to compile modules against synology's source published on sourceforge as they modify structs. Building against vanilla kernel sources may have catastrophic consequences, especially if you're trying to build some driver. We're working on a solution for drivers. This is currently what's stopping us from formally calling it a beta Yes.... Intel decided to add a single instruction (MOVBE) to only the Atom line... then a few years later they've added it to the Xeons. Go figure... that's why 918+ requires a newer CPU with MOVBE support. If you search for "MOVBE intel cpu" you will find many topics not related to xpenology as this is a much bigger problem. As for the SN/MAC: the mac needs to match your real ethernet adaptor. As for the S/N you can google "xpenology s/n generator" and there are tools prepared by the community. You need to use a serial console on your hypervisor, login as root:[no password] and check the /var/log/messages - it will say what went wrong somewhere on the bottom. Did you try updating the BIOS? We've seen such errors on Debian on an Asus motherboard and updating the BIOS solved the issue. That is a bug in the DSM itself (JS error on the page...). It happens on a real hardware as well... albeit not always hmmm. However the only broken page is the Info Center => General. Yay! A nice fix We will add this to the main loader generator. These errors are normal. If you look at them just below it the array is mounted. It jus first tries one thing, failes, and then tries another thing and succeeds. You can generate it with the loader generator. Please, do not use premade images. Your vid/pid combination is most likely invalid, or you connected the usb flash drive to a USB3 port. Try doing "dmesg | grep usb_boot_shim" - it will tell you what drives it saw and if any was shimmed as boot disk. Are you sure your RAM is ok? Are you running ECC there? Check the iLO log as well. Try disabling HPET as well. You should define both. DSM is... hacky... in terms of ethernet interfaces. All of them should be accounted for with different MAC addresses. Are you able to connect to the machine using a serial port? Please add them to your user config under extra_cmdline and rebuild the loader image. Correct, this table still applies. This is due to how syno builds their kernels and how Intel artificially limits instruction sets on some CPUs [fun fact, some older Xeons have the MOVBE in the microcode but it's disabled] So what exactly fails with the upgrade? Are you able to recover the log? In order to see any logs you must attach a serial/COM port. Syno kernel doesn't support VGA output (so as soon as the grub passes the control to the kernel nothing is passed to the GPU). If you boot with ttyS0 iLO should be able to access that port. When you log in to the iLO using ssh (use the same credentials as for the web) there's a virtual serial port emulator (vsp command IIRC from memory). Connect to it before booting and you should start seeing messages right after the screen says "Booting the kernel". You can put it in your user_config.json and it should work... how did you get that S/N? Do not use strip on kernel modules - there are many problems with that. Some options will strip e.g. modinfo which will make the module useless for the kernel. Yes, the built-in card was broken only for a short while. 6.2.3 restored the driver. We didn't test if v7 removed it again (hopefully not). If your loader is at /dev/vda1 then something is very wrong... it shouldn't be. It should be at /dev/synobootN. Editing the grub.cfg manually is not (and will not be) supported. VMM doesn't allow for virtual USB drive. You need to use SATA boot. However, if you're using VMM you should probably install the official VDSM image. NC360T is a good and solid card, even outside of the DSM ecosystem. It's a HP product but it's cheap and readily available (even new). We have probably 30+ of these cards in different servers. After you build the loader the correct PAT file will be in the "cache" folder. You don't need to download it manually from syno. We will like to but we don't have permissions to edit old posts Who should we contact on the form regarding that? v7 should be considered a beta (even if syno says it's stable) on any hardware, including that sold by synology. There are nasty bugs in it unrelated to xpenology. That smells like an ancient docker version in the DSM itself... we saw this before and they fixed the issue after like 6-7 months. It may be the case again. Fixed in the new release (bug in memory handling). It's a shame that Intel artificially limited MOVBE instruction to Atoms and then enabled it again only in new Xeons. That's actually the only reason why 918+ doesn't work on older CPUs. Yes, add them as key:value pairs to "extra_cmdline" key in your user_config.json You can't get them - syno didn't publish them yet... the only way to compile modules is to do it with their toolchain sources. -------------------------------------------------------- [to be continued in a next post due to forum limits]

Today we will break the tradition a bit and respond to all questions first. Since the forum has a limit of 50 quoted posts we have to split our response into multiple posts The last post will be with the actual code updates so if you're reading it and not seeing a post with updates - just wait - we're writing as you're reading this. ------------------------------------------ It's fixed in the today's relese [will be up on GH after the update post] The difference between synoinfo and cmdline is subtle but important. The synoinfo defines the properties of the platform and is mainly used to configure the DSM itself (e.g. how many drives it sees in the UI, does it allow for creation of the SHR etc). These settings can often be changed and everything will work. For example some models don't support VMM not because it wouldn't run but because running anything besides a hello world on it will exhaust all the resources. Cmdline parameters in the other hand configure the kernel directly. Changing them to something inappropriate can often lead to the sysem not booting at all or not seeing disks or not being able to get an IP address from DHCP (e.g. when you set a wrong MAC). The DiskIdxMap, SataPortMap, and SasIdxMap are all cmdline parameters. Putting them in the synoinfo section will produce no results. They must be put in cmdline as they're read by the SCSI driver in the kernel. There's no connection between synoinfo and cmdline reading routines at all. As for how to configure them that short thread explains this very well: Setting SasIdxMap does nothing if you have no SAS controller. These options are internally stored in variables inside of the kernel but only used when the actual drive is connected to a given controller. Without that they have no effect. You only need to replace the boot image. In fact internally we simply have a drive in proxmox with "sata0: file=/our/data/store/image.img". We just replace the file and restart the VM to boot from a new one. Due to some QEmu peculiarities it's recommended to shut down the VM, wait few seconds, and start it again (as restart SOMETIMES may not read the full image again for some unknown reasons). The 918+ now has an experimental SATA support As haydibe mentioned you need to configure the mapping. Q35 is better because it's a newer platform + supports things like PCI-Ex passthrough. Once you configure the proper DiskIdxMap and SataPortMap it will see all disks (and the array will not be crashed as it will not see disks as missing). This whole problem exists because disks beyond 26th are starting to be named e.g. /dev/sdaa, /dev/sdab, /dev/sdac... and this schema is not supported by the OS. To our knowledge there are no devices from syno with >26 disks without a SAS controller. These XMLs are a standardized way to use libvirt. Proxmox went its own way as both were developed kind of in the same time. Additionally, what most of the people don't know, configuration "files" in proxmox aren't files - they're stored in a synchronized SQLite database and just presented as a filesystem This allows for efficient cluster synchronization. We didn't try ourselves but you can attempt to set synoinfo "maxdisks" parameter beyond 16. Theoretically it should be able to host 26 drives if mapping in cmdline is set properly. That's the goal - we want to provide an interface which simply sends commands to an arduino-like device which can serve that. The fan control is... strange. It seems to always send "k" no matter what. There is probably something we've missed (or maybe it goes through the mfgBIOS ioctl? either way both outputs need to be combined). That could be an issue with the card being seen as a proper SAS device. After quickly asking around none of have any free LSI card running in a server to test but we will look into it. Can you put a GH issue in the kernel module repo? It probably needs a small kick similar to VirtIO SCSI - currently as you see the SCSI driver attempts to add a disk with a "/dev/" name (literally empty name) which should and will fail. The problem lies somewhere in the syno modifications to the SCSI driver. That is a good point. We will take this into consideration then and offer a hybrid-boot version supporting BIOS and EFI in a single image, with the default recommendation of a BIOS boot. Someone mentioned the problem with facial recognition & v7. There should be a separate thread for that as this is an issue with the photo app and its checking of S/N (it has to be a real one or the binary of photo app must be patched). This is out of scope of the loader part See the next post with updates - now ESXi is supported with SMART emulation. With this update you can use 918+ [will be on GH after the update post below]. We are looking into one of the models with native support for nVidia GPUs so that transcoding can work with either Intel QS or NVENC. While there are hacks to run the nVidia driver on other platforms its cumbersome and possibly unstable (as, putting it mildly, nV drivers are .... picky). We want to go that route as people with AMD cannot use Intel QS and cards like Quadro P200 are cheap, low power (peak of like 25-30W), and have plenty of enc/dec power (IIRC 7 streams at once). Yes, on Windows it's a pretty good tool. On macOS or Linux the dd is the simplest and already present in the system Now [will be on GH after the update post below] the support for ESXi & SATA boot on 918+ so you should be good to go. What we actually do is qemu-img on Linux + vmkfstools - ESXi is very picky as to VMDKs. Older versions worked great but ESXi 6 and 7 often refuse to properly use VMDKs created by something else than VMWare products. This is why "vmkfstools -i input.vmdk output.vmkd -d thin" works and actually makes an image which works properly with VMWare. Ah, yes... it seems like new syno SCSI driver sees the disks as SAS instead of SATA. You have to play with SasIdxMap then... or we can add a small patch like with VirtIO SCSI to make sure they're treated like SATA. However, DSM should theoretically handle it just fine for data disks (but not for the boot disk). Once we get a free LSI to test we will look into that. Can you post an issue on GH in the kernel module repo? If you use ESXi try doing "vmkfstools -i input.vmdk output.vmkd -d thin" on the ESXi box after qemu-img - for some weird reason newer versions of ESXi refuse to even see a normal VMDK if it wasn't made by their tools... Now, with SMART emulation, that workaround is no longer needed A new release will be posted on GH as soon as we finish fighing with the forum edit to post all posts. The issue with baremetal is that you cannot see any output or console if you don't have a serial port. The syno kernel is built without VGA support, so you only see the output from preboot as kernel simply doesn't initialize GPU (so it's not really frozen per se but just not initialized after GRUB passes the control to the kernel). These errors are perfectly normal. The one about syscall table relates to the kernel not exporting the symbol and RP having to manually scan the memory for it. Rest of the errors about USB and GPU are there because we're faking existence of a hardware which doesn't really exists, so drivers are trying to initialize it and realize it's not there (but the OS still thinks it's there - working or not ;)). Q35 for platform. As for USB vs SATA it doesn't really matter. SATA is easier to configure as you can do it from the GUI, while virtual USB requires editing of the VM config from the terminal (the officially support that, just the GUI is not there). Options you put in synoinfo belong in extra_cmdline. Besides, that if you're getting a file corrupted error on proxmox try shutting down the VM with "Stop", wait few second, start it again. If it still doesn't work you probably have a corrupted file (which we saw happening here a few times) - just regenerate the loader again. Syno kernel doesn't enumerate disks starting from /dev/sda, so you first disk lands on like 7th position. If you don't care and you don't have a lot of disks you don't have to confiure the mapping. As for the vid/pid these are needed when you're booting from a virtual USB drive on Proxmox (and 0x46f4/ 0x0001 are just the ids which QEmu hardcoded in their source). If you're using a real/physical USB drive you need to pass its parameters. In your case vid/pid is 0930/6545 (proxmox shows it in the dropdown). Isn't 99% a reboot? What happens after reboot? Hm, files seems to be correct in the repos. You can try scrapping both pulls and re-pulling both repos. Previously we used symlinks which was a nightmare. It looks like you still have an old file with symlinks-based approach (and you stepped into an issue with them). Nope, it's just your drive will be shown in a semi-random place and not as a 1st one. The mapping really makes a difference only when you have like 8-9 drives and you go beyond the limit (since it will start with 1st hdd at like 7th position). The disk map is more of a "cherry on the top" so it looks properly in the UI. Yes, it requires a new kernel patch for new version as offsets change. We were tinkering with making it an automatic patcher but it's still a risk after every version. With the rate of changes in new DSM versions now we're not sure if developing an auto-patching in the preboot makes sense as likely with new version something else has to be updated aswell. You absolutely can never ever use old bsp files on a different version of the file. bsp file is like a diff but binary and using it on a different version causes random bytes to be patches in the kernel image. New bsp file can usually be generated by using php scripts from the tools folder. However, for normal use we don't expect non-developers to be doing this as you should blindly generate a bsp and call it a day - there are some checks to verify in a disassembler. The fact that a patch is generated doesn't mean it will work properly. We will strongly advise to never post full loaders, especially not on the forum if we want it to exist. The loader image contains proprietary syno code and cannot be distributed in any shape or form without risking a copyright strike. This is why we developed a tool to build a loader as the tool doesn't contain any proprietary code and the kernel patches are for a GPL kernel so... The tools are all there If you run the loader in patch mode without the bsp it will ask you to patch the kernel and rebuild everything. It will even leave the files so you can simply call bsdiff on two files and call it a day. There's a partial documentation for that in the load repo. We didn't touch 7.0.1 as we were busy with the code but we don't expect any problems with 7.0.1 - it simply needs a new binary patch file. Can you try with debug mode enabled? (add BRP_DEBUG=1 before the command so it becomes BRP_DEBUG=1 ./build_loader....). It will print much more information why it couldn't repack the ramdisk. It doesn't see your bootloader source. Are you using USB or SATA? If it's USB you probably set a wrong VID/PID or connected the USB to a USB3 port (which most of the time will not work due to drivers issues, as 3.0 is a very complex spiderweb in comparison to 2.0). That is actually unrelated. This is something which happens all the time, including on real DS hw. The "sdx" refers to like /dev/sdX or /dev/sd<anythingHere>, not the actual sdx drive. You can check the dmesg log. Do "dmesg | grep usb_boot_shim" and it will show you what it saw and if it was shimmed, or maybe the usb stick disconnected or something else. That should actually be automatic and built-in into syno scripting. If it doesn't work can you post an issue in the GH loader generator repo, so we can look at it? Maybe it changed in v7. The *Map parameters should be in extra_cmdline. We explained this in details in a response to below. See https://xpenology.com/forum/topic/44285-proxmox-hba-passthrough-second-virtual-controller-not-detected/ If you're planning to migrate it's better to use Proxmox, ESPECIALLY on microserver. We actually have quite a few of these little cute boxes. If you want to migrate you can leave harddrives as-is and just boot the proxmox out of a SATA drive (you can use the ODD port, it should be on the side of the motherboard and IIRC it's blue and supports only 1.5Gb/s transfer speed). We will be playing with bare metal but it's currently about the drivers. However, gen 8 should work as the ethernet drivers are already included in the DSM. That being said bare metal support is planned as well Yup, this is exactly how we test things. If you want to edit the loader and you're on linux you can do "losetup -pF image.img" and do a "mount /dev/loop0p1 /mnt" - then you have a normal grub config file in /mnt. The loader generator does the same thing really. Since it's in bash and with a lot of comments you can take a peek how it does things pretty easily. Some of our folks needed a LOT of convincing to go VM... some are still grumpy about that. But the technology went really far and virtualization nowadays is way less problematic than bare metal, while also being very efficient in terms of performance. But as we said before ESXi is probably not the greatest choice - Proxmox works much better. If you have any questions regarding it on microserver feel free to ping us: these are amazing machines to this day. Some of ours run with 10 disks [for uninitated: by default they have 4 slots] Hm, we don't have a centralized place with list of things which are working/not. However, if something isn't an issue on GH it's probably working as we try to add issue we find there as well. Currently, after today's updates [one of my colleagues is writting that post as I'm answering questsions], we can say it's a beta-which-we-don't-call-a-beta It will be a problem with booting from SAS but isn't DSM seeing them as data disks? Which LSI card are you running? Can you put an issue on GH in the kernel module repo for this, so we don't forget? Is Parallels also lacking SMART? It should work with the new release from today. We didn't test specifically on Parallels but the code we wrote isn't specific to ESXi (and it even works with a IDE => SATA adapter which we tested for fun). Do you have a serial console by any chance? If so can you post the full dmesg output? Yes, you can add any driver like that really. You may need to modify the patch for init file to do an insmod. It's not a solution for a long-term and easy-to-use loader but if we use it to add an ethernet driver as well. Your problem lies in lack of /dev/synoboot. Previously if you were using ESXi and you had to use a physical USB flash drive. Since this release you can experiment with SATA boot. Your log shows you've booted with USB boot but you have no usb drives in your system. Try booting from the port INSIDE of the microserver. Some of the ports on the microserver are finicky for booting as HPE BIOS is strange at times. ESXi doens't play well with older hardware. Proxmox will be a better choice here They (syno) heavily modify the drivers and the kernel. The array will be fine if the DSM will be able to recognize the SAS devices as the arrays are recognized and built using metadata on disks itself. Where the devices are doesn't matter for the raid subsystem, only the DSM tools care. On a normal Linux box you can have the drive be under /dev/test123 and it will work This is why you should never clone 1:1 disk with arrays on the same system which mounts them. ------- to be continued in the next post due to forum limits

It has been over a week but we're not slowing down! PMU emulation is here This was the biggest feature we were working on, which involved fixing many things around to actually make it stable. The current implementation keeps all the data internally. None of the requests sent by the actual OS needed to be responded to directly, as we shimmed mfgBIOS. However, the interface allows for a very easy plug-in of any hardware-based emulation of the PMU to emulate LEDs etc. The important part here this was one of the bigger roadblocks to make the implementation stable and actually know what the OS is asking for. The PMU emulation appears to be stable from our testing but we are sure you guys will find something quickly The PMU shim was enabled in https://github.com/RedPill-TTG/redpill-lkm/commit/23578eb Driver watching subsystem Since we've changed how the LKM is loaded to make sure we shim everything as quickly as possible it introduced a lot of race conditions. This bit us severely during PMU testing and actually delayed this post & update by a few days. The new driver watching subsystem allows for a quick and easy drivers watching so that we actually load things AS SOON as drivers are initialized by the system (but not earlier). See the following commits for details: https://github.com/RedPill-TTG/redpill-lkm/commit/a34a54b https://github.com/RedPill-TTG/redpill-lkm/commit/3f90ee3 Refactor symbols override We were getting reports about execve() shim being unreliable (e.g. in this issue: https://github.com/RedPill-TTG/redpill-lkm/issues/3 ). However, even thou we patched the problem the underlying issue was still there and the problem was cropping up in other places as well. This took as quite literally close to 100h to track and fix. The previous implementation which we inherited had a critical bug - it wasn't handling the memory barriers & unlocking properly. To be fair, we cannot blame anyone here as the Linux kernel is lying a bit. The thing is the kernel developers over the years try to make harder and harder to modify (or in their, very correct, view damage) the running kernel. The previous implementation (unintentionally) relied on x86 CR0 which is a per-core flag completely disabling memory protection. This didn't allow for flexible memory management (limiting performance of original calls), forced preemption disabling (i.e. kernel couldn't reschedule tasks flexibly), and others. Normally, the kernel contains an API called set_memory_rw/set_memory_ro, which was actually called from the previous implementation. However, these calls did nothing to the kernel memory as somewhere before v3.0 (~2.6, we didn't check precisely) the kernel introduced a forceful kernel region protection. This means that the kernel SILENTLY removed the R/W flag from our requests.... we solved that by using the low-level page table API directly. By itself that wasn't difficult to implement. But to find the core of the problem, that was occurring randomly and required a full reboot every time we wanted to test the change, frustrated us greatly. But we are here for fun so we did it Along the new change we reworked the API to make memory management there easier (=less buggy). The new implementation is not yet used everywhere yet. Currently, the driver watcher (used for vUART and in consequence for PMU shim) is the first test bed. However, we are confident enough that we went ahead and closed the execve() issue. See this commit for details: https://github.com/RedPill-TTG/redpill-lkm/commit/140250a Rework UART swapper [3615xs] Anyone who tried to use the serial console on 3615 saw that annoying "-" added every letter entered. Sadly that was a symptom of a bigger issue. We saw these reports in multiple issued (e.g. https://github.com/RedPill-TTG/redpill-load/issues/6 ). Annoyingly the method used was also buggy which was shown in https://github.com/RedPill-TTG/redpill-lkm/issues/10 - now all the problems are gone. The console on devices with swapped UARTs (e.g. 3615xs) works perfectly on any software. See these commits for details: https://github.com/RedPill-TTG/redpill-lkm/commit/22d4019 https://github.com/RedPill-TTG/redpill-lkm/commit/601c7e9 ====================================== Smaller changes Linux v4 & FIFO changes Linux v4 (or actually Linux v3.13+ to be precise) introduced annoying changes in the FIFO handling by changing the API. This was also responsible for warnings logged during build for 918+ platform. Now it all should be fixed. See the commit for details: https://github.com/RedPill-TTG/redpill-lkm/commit/4427b74 Fix Linux v4 [918+] IRQ scheduling This is small-yet-important fix. It will make sure the vUART is stable on Linux v4 and doesn't cause kernel warning regarding scheduler. See this commit for details: https://github.com/RedPill-TTG/redpill-lkm/commit/0891902 GRUB now supports serial console Following what Jun's loader had and what is actually very useful while playing on systems like QNAP and other bare-metal ones without GPU (or with GPU capable of using an ancient VGA only ;)). See the commit: https://github.com/RedPill-TTG/redpill-load/commit/72360ef More docs We've added more details about mfgBIOS ioctls and PMU itself. Most (but not all) commands are actually somewhat documented in the SDK with vague constants. See these commits: https://github.com/RedPill-TTG/dsm-research/commit/f713373 https://github.com/RedPill-TTG/dsm-research/commit/5c6db49 ================================================================================================== Now we will try to reply to as many comments as possible That shouldn't actually be required. Any number of controllers (up to 26 drives total) should work properly as long as an expander is not used (as these aren't supported by DSM kernel). Jun's loader does not use DSDT patching. It actually monkey-patches routines in the kernel which are responsible for listing devices to the userland. RP takes a different approach by emulating a separate PCI bridge (the vPCI submodule). Messing with DSDT is... messy. It can be done as the hackintosh community is doing that but then it requires separate patches for every platform or their automation. Since we have an open-source kernel (more or less) it's easier to patch it there. Why would you do that? If you're doing bare metal the DSM is perfectly fine with using an SSD. Emulating SSD as HDD can actually be destructive to the SSD as the OS will not know that the underlying storage is a flash media. If you want to use the internal SSD/flash storage as the install media you surely can. If it's a SATA-based one just boot with SATA support. If it's USB just take the vid/pid and put it into the config. In such cases, as long as they're x86_64 based (not just 32 bit like some older atoms), it should work on bare metal. There is something strange about how ESXi emulates HDDs indeed. We have it on our list. As w workaround someone posted a way to manually create disks and put them into a pool (kind of side-stepping the UI) in the GH issue. From what we know it shouldn't be a problem at all if used like this as internally DSM uses just a combo of MDs and LVMs anyway. The UEFI boot actually causes an another set of problems. The DSM is perfectly happy when booted using legacy boot as long as the "withefi" option is enabled. The issue with UEFI is that is not really standarized (or we should say it's very loose). Since EFI can initialize devices and what not on some platforms e.g. serial ports or USB ports aren't working when booted into Linux. This is why we opted to force the loader into legacy/BIOS mode. This isn't a limitation per se - it's just how we configured the GRUB and if needed it can be easily enabled to boot in UEFI mode if desired. The SATA DOM may be A TAD BIT more stable (i.e. more consistant to boot), just MAYBE a tiny bit, but if it boots it doesn't matter. The USB boot relies on precise timing while SATA shim has an exclusive control over the driver - that's why, in short, the SATA DOM may be a tiny bit better. However, where it makes an actual difference is when your boot drive is not emulated. SATA DOMs are meant to run 24x7, they're meant to sit in a hot case for years, they're meant to be overwritten many times. USB sticks... not so much. SATA DOMs are often times slower and more expensive. So in essence if you can replace the physical USB flash drive when it fails and doesn't boot after a reboot go with USB as it's easier to grab and update/edit. If you want something rock solid and/or you cannot easily replace it if it fails go with the SATA DOM The sata_uid and sata_pcislot doesn't have any effect. In fact you should NOT include them as they're not masked from the cmdline presented to the OS. As far as we can see they never did have any effect even in Jun's loader. That is most likely not gonna work as syno kernel only supports boot drives originating from the SCSI driver (and its derivatives like USB). SD/MMC cards are handled by a different driver. Since we cannot modify the kernel itself it may be hard to pull off. While we may simulate its presence as /dev/synoboot other things will start falling apart as everything in DSM expects /dev/synoboot to be an SCSI-complaint device, have an SCSI type etc Hm, so what's actually different here from the "normal" way ESXi creates disks? We don't use ESXi very often - you seem to have more experience with it Your boot disk may be too big if DSM tries to format it. Your disks moved beyond the sdz limit. DSM doesn't support sdaa-sdaz enumeration (only single letters). You need to play with the SATA mapping. See this post: https://xpenology.com/forum/topic/44285-proxmox-hba-passthrough-second-virtual-controller-not-detected/?do=findComment&comment=204352 Huge thanks for helping everybody with the docker - it's amazing. We just saw your PM... yes, that one from like 3 weeks ago (sorry!!! we must've clicked the notification and dismiss it). We couldn't give enough likes! Correct us if we are wrong but the log says you only have a single ~34GB SATA drive and you're booting with SATA DOM support. For it to work you need the loader image to be mounted as SATA and it has to be <=1GiB. Do not use sata_uid and sata_pcislot - this will not cause problems in the current versions but it can in the future. This is an issue tracked on GH: https://github.com/RedPill-TTG/redpill-lkm/issues/14 There's a workaround but not a proper solution yet. As for the info center it's a JS bug in the DSM itself. Be careful with blindly copying SATA maps from Jun's loader. We're emulating SATA DOM differently and thus you will lose one drive if you just copy it. Look at We deliberately disabled UEFI boot (see above for more reasoning). You can use SeaBIOS with Q35 (or others). To our knowledge there's no disadvantage of using BIOS mode. Yes, this is specifically made to disable BIOS update which normally is done on syno hws. If ran on any other hardware it will either crash the CPU (the VM or physical box will act like the reset button was pressed), or it will damage the BIOS (if running on a real hw and the motherboard happens to use the same Insyde BIOS). See more on that here: https://github.com/RedPill-TTG/dsm-research/blob/master/quirks/hw-firmware-update.md We will have a way to load drivers in the stable release In general, you shouldn't have the DSM panel open to the public internet (with reverse proxy or not ;)). Syno's docker is ancient and modified. (at least on v6). It's good for simple things but anything more advanced... oh boy, we've tried and it's painful We've fixed the kfifo stuff (see update notes at the beginning of this post). Other ones are harmless. We're planning to fix them as they shouldn't be there if we care about the code quality (and we do!). That's an amazing idea! We shouldn't run out of "free minutes" as the LKM compilation doesn't use a lot of resources. Can you create an issue in the loader repo, so we don't lose it in the sea of posts? The only thing which we cannot build on GH are full loader images as they contain syno propraitary binaries from PATs. When using virtio CONTROLLER your disk should be set to SATA and not to virtio PORT. The disk must present itself as SCSI-complaint to the Linux kernel so that syno patches pick it up properly. To get the logs you need to add a serial port (Even better if you can add 2). Then you can access them by typing "qm terminal 101 -serial0" where 101 is the id of your VM and the "serial0" is the number of your serial port on the VM counting from 0 up to 3. That is often caused by a weird issue in QEMU where if you reset the machine too quickly it will not respond to some SCSI commands. If it happens all the time try stoppping the VM, placing the file again, wait ~10s, and start the VM again. Huh.... it's spamming these hardcore. They probably didn't predict that they cannot access the API. That's actually a DSM bug - if you look into Chrome dev console you will see that the UI gets the data from the backend but the JS fails to display the tab. It can be safely ignored - they will probably fix it as this is still a beta on 3615. If not there's really nothing you're losing here There are actually perfectly normal, regardless of the hardware (i.e. they appear on a real hw as well). See the haydibe post as well as this guest post with screenshots: sata_uid and sata_pcislot are parameters which were read by the Jun's loader but never actually used for anything. We're speculating that he wanted to shim the SCSI driver but decided against (as this is a buuumpy road as we've found). In previous DSM versions a userland hack was useful, now not so much. While running RP you should NOT add these parameters as they're not removed from cmdline. While this doesn't cause any issues yet it may start in future DSM versions. The comment in the shim - https://github.com/RedPill-TTG/redpill-lkm/blob/master/shim/boot_dev/sata_boot_shim.c - explains in details various methods of searching for the SATA DOM and addresses why relying on the location isn't a good idea If this atom supports MOVB you can even run 918+ build. However for this hardware 3615xs build is probably the best. Regardless, that CPU is very slow. It will run... it will.... but the experience will be pretty miserable. You should NEVER modify scemd as it's protected by a checksum and it will trigger autodestruction with time limit. Normally the RP kernel module blocks all update files. Are you talking about "updater" file? This is the main updater file which does the whole DSM installation. It will. We didn't get to the ESXi weirdness with drives. It may be the problem with hddmon or SMART. Proxmox/QEMU emulate a partial SMART (fully fake but it's there). This is what may be missing on ESXi. We believe there should be a separate topic for the face detection problem. It was discussed somewhere on the page 22-24 - we're not sure if anyone created a separate topic (and it's a completely separate from the loader). In our experience Proxmox was superior. ESXi is amazing for enterprise when you're running a fully supported hardware. In any other circumstances Proxmox is most likely a better choice. Especially that ESXi free version is more like a trial version of the full thing. @haydibe hit the nail in the head with explanation. If you like ESXi definitely stay on it. It will be working on it. The issue with ESXi is that it's mostly concentrated on supporting Windows and its quirks. It's less friendly towards Linux guests and their quirks (e.g. it doesn't emulate SMART from what we see, at least on the free version). Currently - no. We will have a sane method of adding drivers in the future. That seems like a completely borked loader code hmm... the variable is not replaced + it seems like the kernel module didn't load at all. Can you try again with the newest version and if not working post the issue on GH? It's much easier to manage it rather than reply to mixed posts We need to investigate that small part further - can you create a GH issue for this in the loader repo? These errors seem to be coming from inside of the Linux-made driver for the HBA card. There may be some problem with IRQs on your platform? You need to make your ethernet as e1000e or virtIO - then it should see it You should be able to double click the adapter in the VM config and change that.

With SATA supported we will say there isn't even a need for any config as the default one works perfectly (just clicking through in the Proxmox UI). As for the one you posted we're curious about two things: Why set the cpu to SandyBridge manually? Why e1000 instead of VirtIO? (virtio will be more performant as it doesn't do a full emulation)