Leaderboard

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.

You need a new boot image created with the matching DSM version for each released DSM version. You cannot reuse a boot image across different DSM versions.

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.

SO I am encountering an issue with Sabnzbd not connecting to my news servers (Eweka, Thecubenet) with an untrusted certificate from eweka error. I found the following post on Sabnzbd site which seems to translate to an OS issue with incorrect certificates due to an intermediate signing cert from Lets Encrypt that expired Sept 30 2021. Easy enough to fix on windows, but how about on XPE? https://www.sslshopper.com/ssl-checker. ... news.eweka.nl shows the certificate chain of eweka is correct. So problem is client side - which in my case is XPE https://scotthelme.co.uk/lets-encrypt-o ... xpiration/ is a very long story, with this sentence "The certificate in here that is going to cause a problem is this one, the IdenTrust DST Root CA X3." ... "expiration date of 30th Sep 2021" ... which is today. Any ideas on how to fix this? I built a bunch of xpe servers for friends, and the calls are about to start!

done, hope they could track bugs and quirks better on gh.

Afaik only Intel network cards are supported ootb with the DS3615xs software. Synology removed other network drivers sometimes ago (DSM 6.1.x or so). So one solution is to use an Intel card (change mac address). Other solution is the driver extension for your onboard Broadcom network card (if already working?).

Running "load-builtin-sas.sh" for thethorgroup.sas-activator->on_boot Loading SAS controller(s) driver(s) Loading LSI SAS 6Gb driver from /lib/modules/mpt2sas.ko [ 2.111757] mpt2sas version 20.00.00.00 loaded [ 2.117289] mpt2sas0: 32 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (2022888 kB) [ 2.191254] mpt2sas0: MSI-X vectors supported: 1, no of cores: 2, max_msix_vectors: -1 [ 2.193247] mpt2sas 0000:0b:00.0: irq 73 for MSI/MSI-X [ 2.195245] mpt2sas0-msix0: PCI-MSI-X enabled: IRQ 73 [ 2.195719] mpt2sas0: iomem(0x00000000fd3f0000), mapped(0xffffc90008180000), size(65536) [ 2.197125] mpt2sas0: ioport(0x0000000000005000), size(256) [ 2.308337] mpt2sas0: Allocated physical memory: size(4964 kB) [ 2.309771] mpt2sas0: Current Controller Queue Depth(3305), Max Controller Queue Depth(3432) [ 2.310989] mpt2sas0: Scatter Gather Elements per IO(128) [ 2.370223] mpt2sas0: LSISAS2008: FWVersion(16.00.00.00), ChipRevision(0x03), BiosVersion(00.00.00.00) [ 2.372036] mpt2sas0: Dell 6Gbps SAS HBA: Vendor(0x1000), Device(0x0072), SSVID(0x1028), SSDID(0x1F1C) [ 2.373611] mpt2sas0: Protocol=(Initiator,Target), Capabilities=(TLR,EEDP,Snapshot Buffer,Diag Trace Buffer,Task Set Full,NCQ) [ 2.376558] mpt2sas0: sending port enable !! [ 2.384638] mpt2sas0: host_add: handle(0x0001), sas_addr(0x590b11c027f7ff00), phys(8) [ 2.387142] mpt2sas0: detecting: handle(0x0009), sas_address(0x4433221100000000), phy(0) [ 2.388790] mpt2sas0: REPORT_LUNS: handle(0x0009), retries(0) [ 2.389874] mpt2sas0: TEST_UNIT_READY: handle(0x0009), lun(0) [ 2.396730] scsi 1:0:0:0: SATA: handle(0x0009), sas_addr(0x4433221100000000), phy(0), device_name(0x50014ee26320545e) [ 2.408946] mpt2sas0: detecting: handle(0x000b), sas_address(0x4433221101000000), phy(1) [ 2.410586] mpt2sas0: REPORT_LUNS: handle(0x000b), retries(0) [ 2.411748] mpt2sas0: TEST_UNIT_READY: handle(0x000b), lun(0) [ 2.422008] scsi 1:0:1:0: SATA: handle(0x000b), sas_addr(0x4433221101000000), phy(1), device_name(0x50014ee26320252f) [ 17.648369] mpt2sas0: detecting: handle(0x000a), sas_address(0x4433221102000000), phy(2) [ 17.651123] mpt2sas0: REPORT_LUNS: handle(0x000a), retries(0) [ 17.652856] mpt2sas0: TEST_UNIT_READY: handle(0x000a), lun(0) [ 17.662223] scsi 1:0:2:0: SATA: handle(0x000a), sas_addr(0x4433221102000000), phy(2), device_name(0x50014ee20ef68994) [ 32.723942] mpt2sas0: detecting: handle(0x000c), sas_address(0x4433221103000000), phy(3) [ 32.726898] mpt2sas0: REPORT_LUNS: handle(0x000c), retries(0) [ 32.728908] mpt2sas0: TEST_UNIT_READY: handle(0x000c), lun(0) [ 32.743439] scsi 1:0:3:0: SATA: handle(0x000c), sas_addr(0x4433221103000000), phy(3), device_name(0x50014ee20dcd759f) [ 47.822440] mpt2sas0: detecting: handle(0x000d), sas_address(0x4433221104000000), phy(4) [ 47.825418] mpt2sas0: REPORT_LUNS: handle(0x000d), retries(0) [ 47.833947] mpt2sas0: TEST_UNIT_READY: handle(0x000d), lun(0) [ 47.847305] scsi 1:0:4:0: SATA: handle(0x000d), sas_addr(0x4433221104000000), phy(4), device_name(0x50014ee2647a1448) [ 62.933161] mpt2sas0: detecting: handle(0x000e), sas_address(0x4433221105000000), phy(5) [ 62.936117] mpt2sas0: REPORT_LUNS: handle(0x000e), retries(0) [ 62.938119] mpt2sas0: TEST_UNIT_READY: handle(0x000e), lun(0) [ 62.947998] scsi 1:0:5:0: SATA: handle(0x000e), sas_addr(0x4433221105000000), phy(5), device_name(0x5000c5008c5e912d) [ 78.018894] mpt2sas0: detecting: handle(0x000f), sas_address(0x4433221106000000), phy(6) [ 78.028297] mpt2sas0: REPORT_LUNS: handle(0x000f), retries(0) [ 78.030129] mpt2sas0: TEST_UNIT_READY: handle(0x000f), lun(0) [ 78.039803] scsi 1:0:6:0: SATA: handle(0x000f), sas_addr(0x4433221106000000), phy(6), device_name(0x5002538e49b3b3ca) [ 93.110287] mpt2sas0: port enable: SUCCESS i can confirm that it works now with the stock v20.0 mpt2sas.ko from DSM v7.0.1, no need for the custom .ko from @pocopico , all drivers (7 in my case) show up as /dev/sd* and DSM wants to install itself (did not try to proceed but i guess it works). still persist the problem that if the loader is on sata0:0 it reserves /dev/sda, so the first disk connected to the LSI shows up as /dev/sdb.

/\ 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.

Please bear in mind that this will only work on DS3615 and not on 918. The 918 requires additional modules to be loaded prior loading any SAS modules otherwise you will fail to satisfy their dependencies.

dsmv7 has also problem with some synocommunity packages that wont install because some (like cmd tools) uses root :S not that great of an upgrade this v7 😕

@WiteWulf, thx, now it is booting from the usb.

I uses the portable partion Manager from xpenology Tools to set the first as active.

Okay when you say "my Hp Gen 8 don't boot", exactly what are you seeing on your machine? Is it actually not booting from the USB stick and trying to PXE boot from the NIC (or whatever the next device is in your boot order), or is it booting from the USB stick into the linux kernel and you're just not seeing any output to screen after this output?: Loading Linux... Loading initramfs... Starting kernel with USB boot early console in decompress_kernel Decompressing Linux... Parsing ELF... done. Booting the kernel.

Not sure why I didn't think about it earlier, but in fact you can checkout redpill-load on the host, configure "docker.local_rp_load_use": "true" and "docker.local_rp_load_path": "/path/where/your/local/redpill-load/copy/is" in global_config.json. And then use the ext-manager inside your local redpill-load copy before you perform your next auto build. This way there is no need to integrate the ext-manager inside the redpill-tool-chain, as it can be directly used inside the local redpill-load folder. Update: I just checked out of curiousity. This feature was available since v0.6

@u357 Edit : lspci result : root@Xpen70:~# lspci -nn 0000:00:00.0 Host bridge [0600]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge [8086:7190] (rev 01) 0000:00:01.0 PCI bridge [0604]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge [8086:7191] (rev 01) 0000:00:07.0 ISA bridge [0601]: Intel Corporation 82371AB/EB/MB PIIX4 ISA [8086:7110] (rev 08) 0000:00:07.1 IDE interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 IDE [8086:7111] (rev 01) 0000:00:07.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 08) 0000:00:07.7 System peripheral [0880]: VMware Virtual Machine Communication Interface [15ad:0740] (rev 10) 0000:00:0f.0 VGA compatible controller [0300]: VMware SVGA II Adapter [15ad:0405] 0000:00:11.0 PCI bridge [0604]: VMware PCI bridge [15ad:0790] (rev 02) 0000:00:15.0 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:15.1 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:15.2 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:15.3 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:15.4 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:15.5 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:15.6 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:15.7 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.0 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.1 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.2 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.3 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.4 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.5 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.6 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.7 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.0 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.1 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.2 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.3 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.4 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.5 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.6 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.7 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.0 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.1 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.2 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.3 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.4 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.5 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.6 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.7 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:02:00.0 USB controller [0c03]: VMware USB1.1 UHCI Controller [15ad:0774] 0000:02:01.0 USB controller [0c03]: VMware USB2 EHCI Controller [15ad:0770] 0000:02:03.0 SATA controller [0106]: VMware SATA AHCI controller [15ad:07e0] 0000:03:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3] 0000:0b:00.0 RAID bus controller [0104]: Broadcom / LSI SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] [1000:0072] (rev 03) 0001:07:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Controller [1b4b:9235] (rev 11) 0001:08:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Controller [1b4b:9235] (rev 11) 0001:09:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Controller [1b4b:9235] (rev 11) 0001:0a:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Controller [1b4b:9235] (rev 11) Edit again : Actually I can remove DiskIdxMap=0C it seems no matter what, this option is ignored. As long as I keep SataPortMap=4. Everything works, and first SAS/SSD disk is detected as drive 5. Edit again again : So I confirm, When I use virtual disk on virtual SATA1 controller, it works as expected : DiskIdxMap=1000 SataPortMap=4 Virtual 16GB disk is shown as drive 1. Disk /dev/sda: 16 GiB, 17179869184 bytes, 33554432 sectors Disk model: Virtual SATA Hard Drive Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x2d4890c5 Device Boot Start End Sectors Size Id Type /dev/sda1 2048 4982527 4980480 2.4G fd Linux raid autodetect /dev/sda2 4982528 9176831 4194304 2G fd Linux raid autodetect /dev/sda3 9437184 33349631 23912448 11.4G fd Linux raid autodetect Whereas same settings with virtual SATA1 controller removed and only HBA passtrough card, it always appears at drive 5. lspci result with only virtual drives (working as drive 1) root@Xpen_70:~# lspci -nn 0000:00:00.0 Host bridge [0600]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge [8086:7190] (rev 01) 0000:00:01.0 PCI bridge [0604]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge [8086:7191] (rev 01) 0000:00:07.0 ISA bridge [0601]: Intel Corporation 82371AB/EB/MB PIIX4 ISA [8086:7110] (rev 08) 0000:00:07.1 IDE interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 IDE [8086:7111] (rev 01) 0000:00:07.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 08) 0000:00:07.7 System peripheral [0880]: VMware Virtual Machine Communication Interface [15ad:0740] (rev 10) 0000:00:0f.0 VGA compatible controller [0300]: VMware SVGA II Adapter [15ad:0405] 0000:00:11.0 PCI bridge [0604]: VMware PCI bridge [15ad:0790] (rev 02) 0000:00:15.0 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:15.1 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:15.2 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:15.3 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:15.4 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:15.5 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:15.6 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:15.7 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.0 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.1 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.2 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.3 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.4 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.5 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.6 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:16.7 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.0 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.1 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.2 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.3 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.4 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.5 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.6 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:17.7 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.0 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.1 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.2 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.3 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.4 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.5 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.6 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:00:18.7 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 0000:02:00.0 USB controller [0c03]: VMware USB1.1 UHCI Controller [15ad:0774] 0000:02:01.0 USB controller [0c03]: VMware USB2 EHCI Controller [15ad:0770] 0000:02:03.0 SATA controller [0106]: VMware SATA AHCI controller [15ad:07e0] 0000:02:04.0 SATA controller [0106]: VMware SATA AHCI controller [15ad:07e0] 0000:03:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3] 0001:07:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Controller [1b4b:9235] (rev 11) 0001:08:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Controller [1b4b:9235] (rev 11) 0001:09:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Controller [1b4b:9235] (rev 11) 0001:0a:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Controller [1b4b:9235] (rev 11)

I will release an RedPill extension soon for LSI cards (mptsas/mpt2sas/mpt3sas. I just need to find some time

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.

Offtopic, there were some questions why someone would want 10 Gbps networking...well Digi ISP (RCA-RDS) Romania announced new subscriptions for 10 and 2.5 GBps. 10 Gbps costs 10.11 EUR/11.72 USD(50 RON) and 2.5 Gbps costs 9.10 EUR/10.55 USD (45 RON). That is for FTTH , fiber to the home, no need for business subscription. So...I guess 10 Gbps is the new standard, or ar least 2.5 Gbps. https://www.digi.ro/anunturi/digi-lanseaza-internetul-de-10-gbps-fiberlink-10-g-cel-mai-rapid-internet-din-romania-29465 We need to push 10 Gbps cards compatibility.