Jump to content
XPEnology Community

Leaderboard

Popular Content

Showing content with the highest reputation since 09/23/2017 in all areas

  1. The RedPill is back! As some of you may be aware a lot of research materials as well as the code for parts of the kernel module were pulled from GH. We're happy to report it's back and fully public! Before further ado we have a small sneak-peek of the current state: Repositories Both LKM code and the research materials are present in two repositories. Both are automatic forks from our internal serves and are updated few times a day. - RedPill LKM: contains the current version of the Linux kernel module source code along with implementation details description - DSM Research/Docs: hosts documentation for developers regarding the inner details of DSM boot process While the dates and authors in both repos are anonymized, the history is preserved. Thus, your forks and PRs will work properly. The Current State As of now the DSM installs & boots properly (sort of, continue reading). We are currently working on a toolset for generating the loader image automatically so that testing new iterations is easier for people not familiar with full inner workings of the kernel component & the bootloader itself. The tool with instructions will be published in a separate repo. The kernel module is currently missing the PCI-IDs shimming and RTC emulation. While the latter is most likely not crucial, the former must be implemented. However, it's not really straight-forward as naturally the kernel doesn't have a high-level API to lie about nonexisting hardware The current revision of the LKM causes some errors to be sent to the PMU. If anyone in the community (@Vortex? @IG-88?) has an idea of what is the source of these we will be grateful for some pointers. --R--R-p--R-4 -9 --R-r-K-8-3-8 As of now we're working on a robust PCI emulation layer. This isn't hard in theory but has many pitfalls if we want to do it properly and none of us ever studied inner workings of PCI on x86 As described in the PCI document in the research repo there are three methods. We picked the third one (full PCI emulation) as it allows for creation of devices which are indistinguishable from real ones. While this is the hardest to pull off properly, it doesn't rely on a hack but rather an official and documented Linux API. Q&A Who are you? We're a group of passionates dating back to the (great) phreaking times. If you know where to look you will find us on IRC Can I get involved in the development? Yes! As this project took a lot from the community we strongly believe it should continue to be shared and developed under GPL. We greatly appreciate any PRs on GH. I'm not a developer, can I help? At this stage most likely not. However, we wish to have some testing version not too far in time. For various reasons we cannot (and not willing to) accept any donations. If you want to make us feel better leave a like and a good word for us, as naturally this isn't our full-time job :))) Why is making the code public matters? We believe that the code of the loader MUST be public. We aren't sure if the general community is aware of the degree of control the "loader" has over their box. Despite the name it is not just a load-and-leave situation. The majority of the loader code is active in the system for the whole time (you can check that by doing lsmod and looking for an entry which doesn't look like a proper module name but one or more random characters). The kernel module can do literally anything you can as root... and more. It can read files, send them in the background somewhere, hide files from you, execute programs with higher-than-root privileges without showing them in any tools, use your CPU while showing 0% in htop etc... and the worst part is that you will never know that it happened (unless you're monitoring your device from the outside). However, after this scary paragraph we can say two things: Jun's loader doesn't seem to do any evil things, and the actions any loader needs to perform in the system after the initial load are minimal (e.g. fake responses to "turn on HDD led"). We've also reviewed the code we cloned and it's a solid base. Additionally, making the code open means anybody can tinker with it and adjust to new scenarios instead of relying to bit-patching a .ko. What happened to previous repos? Are you crediting the previous author? The author of the original code wishes to distance himself from the project and we are respecting that. That's all we know. Do you/anyone have the code of Jun's loader? We saw that there's some confusion on the forum regarding Jun's loader and why the work had to start from scratch. Neither the Jun's loader code nor any deeper implementation details regarding inner working of his amazing loader were ever shared with the public. We weren't able to obtain the code through our sources either. There's a good chance he never shared the with anybody. Is Syno trying to block the loader? While we cannot comment on any actions, we can surely talk about the code. The new kernel contains something which isn't present before 25556: https://github.com/RedPill-TTG/dsm-research/blob/master/quirks/boot_params-validation.md It is true that the "va not found" error triggered by the Jun's loader when used with >6.2.3 is indeed related to offsets which changed in the new build. However, the rabbit hole doesn't stop there. The new "boot_params" check doesn't seem to have any other purpose than detecting violation of the chain of trust. So did the new kernel build broke the loader intentially? Most likely not (it's probably a by-product of the new validation code present very early in the image) but why the boot params validation was placed in 6.2.4 in the first place? We leave the interpretation to the reader. When we can expect a stable release? Will it work on v7? We cannot promise any date for two reasons: 1) we can hit an unexpected roadblock (e.g. see errors mentioned above), and 2) we will like to test it and have it working on v6.2.4 and v7 as well (as of now v7 is available for selected devices only and from our tests it is not fully stable even on the devices it was officially released). Some of the protections found in v6 were pulled from v7... but don't worry, they will be back as soon as they port them... it's a carrot and a stick situation. cc for people who followed the original topic: @AleAmadoC @alexku44 @Amoureux @Balrog @blindspot @Bobbenoster @Bobur @coolinx @dimcheff @Fede @FiberInternetUser @gadreel @ilovepancakes @impala_84 @intrax @jarugut @juud @kiwiuk @lemon55 @loomes @minigranis @NeoID @Nuno @Piteball @pkdick1 @pro_info @profet @rufik @s2k7 @scoobdriver@setsunakawa @smilenkovski @smileyworld @smoojay @snakefox666 @Snyaify @SpiRe @T-REX-XP @The Chief @toolazy @vasiliy_gr
    108 points
  2. Hi, everyone, Thanks for you patience. A new ds918 loader support 6.2/6.21 is uploaded. whats new: uefi issue fixed. i915 driver updated. link https://mega.nz/#F!Fgk01YoT!7fN9Uxe4lpzZWPLXPMONMA (for DS918+) - v1.04b ---Beginning of addition by polanskiman--- link https://mega.nz/#!OV4gVKyZ!dCgfXx1bgAOyvbFwFiov3s7RSNoFuqnAcNmSllLoUiw (for DS3615xs) - v1.03b link https://mega.nz/#!zcogjaDT!qIEazI49daggE2odvSwazn3VqBc_wv0zAvab6m6kHbA (for DS3617xs) - v1.03b Please read this topic to know what loader to chose: ---End of addition by polanskiman---
    100 points
  3. Hello everyone, I would like to share a personal project that I am developing. It is another loader for TTG Redpill, intended to be as automatic and user-friendly as possible. The link is below, download the image and record it on a flash drive, the rest is done on the same computer. I'm Brazilian and I'm not good at English language, so forgive me for translation errors. I used forum knowledge and code from various loaders developed by TTG, pocopico, jumkey, Jun and many others. Hope you like it. https://github.com/fbelavenuto/arpl Edit: An important information that I forgot to mention is that I developed a simple patch to no longer display the DUMMY port error on models without device-tree, the user will be able to install without having to worry about it
    66 points
  4. As DSM 6.2 finally released, I spent a few days to identify new kernel side validation mechanism, and got some ideas to work around it, the early-stage experiment seems work, so, the exciting part(for me) is done. A new loader will be released when it is ready.
    57 points
  5. Hello! I am xpenology user. And I am an IT engineer who creates shell scripts as hobbies. Please understand that it is written by a google translate site. because i’m korean who is not fluent in English. I created a tool to change cpu information for Xpenology’s users. Modify the actual cpu name and cores of your pc or server. Howto Run ============================================================= 1. Download attached file on your PC (ch_cpuinfo.tar) (ch_cpuinfo_en.tar) / (ch_cpuinfo_kr.tar is file for korean) 2. Upload file to your DSM location (by filestation, sftp, webdav etc....) 3. Connect to ssh by admin account. (dsm > control panel > terminal & snmp > terminal > enable ssh check) 4. Switch user to root: sudo su - (input admin password) 5. Change directory to where ch_cpuinfo.tar file is located: cd /volume1/temp 5-1. in another way, Download ch_cpuinfo.tar with wget wget https://github.com/FOXBI/ch_cpuinfo/releases/download/ch_cpuinfo/ch_cpuinfo.tar 6. Decompress file & check file: tar xvf ch_cpuinfo.tar ls -lrt (check root’s run auth) 7. Run to Binary file ./ch_cpuinfo or ./ch_cpuinfo.sh (If you use busybox in DSM 5.x, you can use it as a source file) 8. When you execute it, proceed according to the description that is output. 9. Check your DSM’s CPU name, CPU cores at “information center” made a video of the how to run ch_cpuinfo. Extra Action If you want to use ch_cpuinfo in your language Modify and use the LANG.txt file in the same path as ch_cpuinfo. It is possible to use after changing the English content of each variable after translation and changing the value of CUSTLANG in line 8 to Y. Sample image(by Google trans) ==================================================== Addtional, Adjust binary to excute file made by shc(http://www.datsi.fi.upm.es/~frosal) The tool does not inclue worms, bad code. If you want to edit the CPU information yourself manually, please refer to the contents below. ——————————————————————————————————————————————————————————————— Location : /usr/syno/synoman/webman/modules/AdminCenter Source : admin_center.js / admin_center.js.gz(above 6.2) Add Before -> if(Ext.isDefined(h.cpu_vendor)&&Ext.isDefined(h.cpu_family)&&Ext.isDefined(h.cpu_series)){ o.push([_T("status","cpu_model_name"),String.format("{0} {1} {2}",h.cpu_vendor,h.cpu_family,h.cpu_series)])} if(Ext.isDefined(h.cpu_cores)){o.push([_T("status","cpu_cores"),h.cpu_cores])} Add contents: h.cpu_vendor="Intel";h.cpu_family="Xeon";h.cpu_series="E3-1220 V3";h.cpu_cores="4 Cores (1 CPU/4 Cores | 4 Threads)"; h.cpu_detail="<a href='https://ark.intel.com/content/www/us/en/ark/search.html?_charset_=UTF-8&q=E3-1220 V3' target=_blank>detail</a>" Change contens: String.format("{0} {1} {2}",h.cpu_vendor,h.cpu_family,h.cpu_series) to String.format("{0} {1} {2} {3}",h.cpu_vendor,h.cpu_family,h.cpu_series,h.cpu_detail) ——————————————————————————————————————————————————————————————— Finally, All descriptions are based on version 6.2, and the actual executable file supports 5.x, 6.x and 7.x Publish the source through github(https://github.com/FOXBI/ch_cpuinfo). For versions DSM 6.x and later, you can use the binary as before. If you use busybox in DSM 5.x, you can use it as a source file(ch_cpuinfo.sh). Please contact me by comment or bug report, i’ll respond to you as much as possible within my ability. Test & Made Environment ———————————————————————————————————— Base Server : HP ML310e v2 gen8 + VMware ESXi 6.0 + RDM DSM : DSM 6.2.3-25426 Update 3 (DS3615xs) Base Server : HP ML310e v2 gen8 + VMware ESXi 6.0 DSM : DSM 7.0.1-42214 (DS3615xs) Base Server : HP ML310e v2 gen8 + VMware ESXi 6.0 DSM : DSM 7.0.1-42214 (DS918+) Base Server : HP ML310e v2 gen8 + VMware ESXi 6.0 DSM : DSM 6.2.4-25556 (DS3615xs) Base Server : Intel E5-2630 v2 + VMware ESXi 6.7u2 DSM : 6.2.2-24922 Update 2 (DS3617xs) ———————————————————————————————————— Change Log Update new version (ch_cpuinfo ver 4.2.0-r01) 2023.02.18 - Application of AMD's CPU information collection function improvement - xpenlib(cpu_info.sh) refered https://github.com/FOXBI/xpenlib/blob/main/cpu_info.sh Update new version (ch_cpuinfo ver 4.2.1-r01) 2023.03.05 - Fixed error when users of previous version perform redo with version 4.2.0-r01 (Thanks for the @Mentat report.) I am sorry for not being able to actively respond to your inquiries due to busy life. Thank you!! Have a nice day!! Cheer up!! We can do it!! Reduce activity & Stay home & Wear a Mask!! Let's overcome COVID-19 !! Let's pray and support together for the two countries where the earthquake caused great damage and many deaths and missing people. ============================================= Download links: ch_cpuinfo ver 4.2.0-r01 - new version update -> ch_cpuinfo ver 4.2.1-r01 - new version update -> ch_cpuinfo.tar Reference images # 1.04b + DS918+ # 1.03b + DS3615xs # 1.03b + DS3617xs # Normal output is possible even when using more than 8core. # Support DSM 7.x
    54 points
  6. When setting up an XPEnology system, you must first select a DSM platform and version. XPEnology supports a few specific DSM platforms that enable certain hardware and software features. All support a minimum of 4 CPU cores, 64GB of RAM, 10Gbe network cards and 12-disk arrays. When you choose a platform and the desired DSM software version, you must download the correct corresponding loader. That may not be the "newest" loader available. The last 6.x version (6.2.4-25556) is functional only with the TCRP loader. TCRP is very different than the Jun loader. If you want to learn more, or if you are interested in deploying the latest 7.x versions, see the 7.x Loaders and Platforms thread. Be advised that installing 6.2.4 with TCRP is basically the same procedure as installing 7.x. Each of these combinations can be run "baremetal" as a stand-alone operating system OR as a virtual machine within a hypervisor (VMWare ESXi is most popular and best documented, but other hypervisors can be used if desired). Review the table and decision tree below to help you navigate the options. 6.x Loaders and Platforms as of 16-May-2022 Options Ranked DSM Platform DSM Version Loader Boot Methods*** Hardware Transcode Support NVMe Cache Support RAIDF1 Support Oldest CPU Supported Max CPU Threads Notes 1,3a DS918+ 6.2.0 to 6.2.3-25426 Jun 1.04b UEFI, BIOS/CSM Yes Yes No Haswell ** 8 6.2.0, 6.2.3 ok, 6.2.1/6.2.2 not recommended for new installs* 2,3b DS3617xs 6.2.0 to 6.2.3-25426 Jun 1.03b BIOS/CSM only No No Yes any x86-64 16 6.2.0, 6.2.3 ok, 6.2.1/6.2.2 not recommended for new installs* DS3615xs 6.2.0 to 6.2.3-25426 Jun 1.03b BIOS/CSM only No No Yes any x86-64 8 6.2.0, 6.2.3 ok, 6.2.1/6.2.2 not recommended for new installs* DS918+ 6.2.4-25556 TCRP 0.4.6 UEFI, BIOS/CSM Yes Yes No Haswell ** 8 recommend 7.x instead DS3615xs 6.2.4-25556 TCRP 0.4.6 UEFI, BIOS/CSM No No Yes any x86-64 8 recommend 7.x instead DS916+ 6.0.3 to 6.1.7 Jun 1.02b UEFI, BIOS/CSM Yes No No Haswell ** 8 obsolete, use DS918+ instead DS3617xs 6.0.3 to 6.1.6 Jun 1.02b UEFI, BIOS/CSM No No Yes any x86-64 16 6.1.7 may kernel panic on ESXi 4 DS3615xs 6.0.3 to 6.1.7 Jun 1.02b UEFI, BIOS/CSM No No Yes any x86-64 8 best compatibility on 6.1.x * 6.2.1 and 6.2.2 have a unique kernel signature causing issues with most kernel driver modules, including those included in the loader. Hardware compatibility is limited. ** FMA3 instruction support required. All Haswell Core processors or later support it. Only a select few Pentium, and no Celeron CPUs do. ** Piledriver is believed to be the minimum AMD CPU architecture to support the DS916+ and DS918+ DSM platforms. *** If you need an MBR version of the boot loader because your system does not support a modern boot methodology, follow this procedure. CURRENT LOADER/PLATFORM RECOMMENDATIONS/SAMPLE DECISION POINTS: 1. DEFAULT install DS918+ 6.2.3 - also if hardware transcoding or NVMe cache support is desired, or if your system only support UEFI boot Prerequisite: Intel Haswell (aka 4th generation) or newer CPU architecture (or AMD equivalent) Configuration: baremetal loader 1.04b, DSM platform DS918+ version 6.2.3 Compatibility troubleshooting options: extra.lzma or ESXi 2. ALTERNATE install DS3617xs 6.2.3 - if RAIDF1, 16-thread or best SAS support is desired, or your CPU is too old for DS918+ Prerequisite: USB key boot mode must be set to BIOS/CSM/Legacy Boot Configuration: baremetal loader 1.03b, DSM platform DS3617xs version 6.2.3 Compatibility troubleshooting options: extra.lzma, DS3615xs platform, or ESXi 3. ESXi (or other hypervisor) virtual machine install - generally, if hardware is unsupported by DSM but works with a hypervisor Prerequisites: ESXi hardware compatibility, free or full ESXi 6.x or 7.x license Use case examples: virtualize unsupported NIC, virtualize SAS/NVMe disks and present as SATA, run other ESXi VM's instead of Synology VMM Option 3a: 1.04b loader, DSM platform DS918+ version 6.2.3 Option 3b: 1.03b loader, DSM platform DS3617xs version 6.2.3 (VM must be set to BIOS Firmware) Preferred configurations: passthrough SATA controller and disks, and/or configure RDM/RAW disks 4. FALLBACK install DS3615xs 6.1.7 - if you can't get anything else to work Prerequisite: none Configuration: baremetal loader 1.02b, DSM platform DS3615xs version 6.1.7 SPECIAL NOTE for Intel 8th generation+ (Coffee Lake, Comet Lake, Ice Lake, etc.) motherboards with embedded Intel network controllers: Each time Intel releases a new chipset, it updates the PCI id for the embedded NIC. This means there is a driver update required to support it, which may or may not be available with an extra.lzma update. Alternatively, disable the onboard NIC and install a compatible PCIe NIC such as the Intel CT gigabit card.
    53 points
  7. Hi! I made a little tool which can help you to get your XPEnology up & running without installing any software. It contains (as portable versions): - Nirsoft's USB device view (helps to identify the VID & PID of your USB boot media) - V2.76 - XPEnology Serial Generator for DS3615XS, DS3617XS and DS916+ (a converted version of the HTML site) - Win32 DiskImager (to write your modified synoboot.img to your USB boot media) - V1.0 (only available in V1.4.1) - OSFMount x64 (to mount the synoboot.img and modifiy it) - V1.5 - Notepad++ (best editor for changing values inside grub.cfg) - V7.5.3 - Synology Assistant (useful tool from Synology to find your XPEnology and install DSM) - V6.2-23733 - TFTP/DHCP portable (a small TFTP, DHCP and Syslog server by Ph. Jounin) - V4.6.2 - MiniTool Partition Wizard 10 (helps assigning already formatted/written USB devices to modify existing grub.cfg) - V10.3 - SoftPerfect Network Scanner - V6.2.1 - USB Image Tool - V1.75 - New: Rufus - V3.3 In the section "Downloads" all links open corresponding websites to download the files. For beginners I added a small HowTo for bare-metal installation. Update New link for download: https://mega.nz/#F!BtViHIJA!uNXJtEtXIWR0LNYUEpBuiA The download link/folder also contains @IG-88's extra.lzma (V0.6) for the DS918+. You'll have to run it "As Administrator" because some of these tools (like Win32 DiskImager) need to be executed with higher rights. It's possible that the SmartScreen filter will give you a warning, because the EXE isn't signed. Bug reports and comments are welcome Cheers Current version: V1.4.2 (2018-11-19)
    52 points
  8. Hi all, A while ago I've started experimenting with a solution that would not require docker and/or a system running linux, but just a simple image that you can boot on your physical/virtual system and create the loader from there. I started with the plain disk image of 200MB size and tried to fit all in this image. As always first partition of the image is the synoboot1, second synoboot2 and third one (synoboot3) is tinycore. Tinycore is a simple linux distribution that can boot to a GUI so you can start creating the loader. Most network modules are included so you can verify also the extensions required on your system. A script will take care most of the actions that you would manually perform and just copy the loader contents to the 1st and 2nd partition. The loader is created from a pre-compiled redpill extension (should work) or you can compile it yourself (still testing). You can bring over and use the rp-helper configuration files so you dont have to do that again. To connect using ssh you will need first to reset the tc user password by typing # passwd tc The image can be found here: https://github.com/pocopico/tinycore-redpill Before starting the loader creation just run # ./rploader.sh update now and answer y I would appreciate any findings to improve the image.
    46 points
  9. NOTE: This problem is consistently manifested when running Jun's loader on a virtual machine with 6.2.3, but some also have problems on baremetal, and under certain conditions, other 6.2.x versions. The fix can be implemented safely on all Jun loader installs. You can verify if you have the issue by launching SSH and issuing the following command: $ ls /dev/synoboot* /dev/synoboot /dev/synoboot1 /dev/synoboot2 If these files are not present, your Synoboot devices are not being configured correctly, and you should install the fix script. If synoboot3 exists that is okay. TL;DR: When running DSM 6.2.3 as a virtual machine (and sometimes on baremetal), Jun's 1.03b and 1.04b bootloaders fail to build /dev/synoboot Bootloader SATA device normally mapped beyond the MaxDisks limit becomes visible if /dev/synoboot is not created DSM 6.2.3 update rewrites the synoinfo.cfg disk port bitmasks which may break arrays >12 disks, and cause odd behavior with the bootloader device Background: Setting the PID/VID for a baremetal install allows Jun's loader to pretend that the USB key is a genuine Synology flash loader. On an ESXi install, there is no USB key - instead, the loader runs a script to find its own boot device, and then remakes it as /dev/synoboot. This was very reliable on 6.1.x and Jun's loader 1.02b. But moving to DSM 6.2.x and loaders 1.03b and 1.04b, there are circumstances when /dev/synoboot is created and the original boot device is not suppressed. The result is that sometimes the loader device is visible in Storage Manager. Someone found that if the controller was mapped beyond the maximum number of disk devices (MaxDisks), any errant /dev/sd boot device was suppressed. Adjusting DiskIdxMap became an alternative way to "hide" the loader device on ESXi and Jun's latest loaders use this technique. Now, DSM 6.2.3: The upgrade changes at least two fundamental DSM behaviors: SATA devices that are mapped beyond the MaxDisks limit no longer are suppressed, including the loader (appearing as /dev/sdm if DiskIdxMap is set to 0C) The disk port configuration bitmasks are rewritten in synoinfo.conf: internalportcfg, usbportcfg and esataportcfg and on 1.04b, do not match up with the default MaxDisks=16 anymore (or if you have modified MaxDisks). NOTE: If you have more than 12 disks, it will probably break your array and you will need to restore the values of those parameters Also, when running as a virtual machine (and sometimes on baremetal), DSM 6.2.3 breaks Jun's loader synoboot script such that /dev/synoboot is not created at all. Negative impacts: The loader device might be accidentally configured in Storage Manager, which will crash the system The loader partitions may inadvertently be mapped as USB or eSata folders in File Station and become corrupted Absence of /dev/synoboot devices may cause future upgrades to fail, when the upgrade wants to modify rd.gz in the loader (often, ERROR 21 or "file corrupt") Unpacking Jun's synoboot script reveals that it harvests the device nodes, deletes the devices altogether, and remakes them as /dev/synoboot. It tries to identify the boot device by looking for a partition smaller than the smallest array partition allowed. It's an ambiguous strategy to identify the device, and something new in 6.2.3 is causing it to fail during early boot system state. There are a few technical configuration options can can cause the script to select the correct device, but they are difficult and dependent upon loader version, DSM platform, and BIOS/EFI boot. Fix: However, if Jun's script is re-run after the system is fully started, everything is as it should be. So extracting the script from the loader, and adding it to post-boot actions appears to be a solution to this problem: Download the attached FixSynoboot.sh script (if you cannot see it attached to this post, be sure you are logged in) Copy the file to /usr/local/etc/rc.d chmod 0755 /usr/local/etc/rc.d/FixSynoboot.sh Thus, Jun's own code will re-run after the initial boot after whatever system initialization parameters that break the first run of the script no longer apply. This solution works with either 1.03b or 1.04b and is simple to install. This should be considered required for a virtual system running 6.2.3, and it won't hurt anything if installed or ported to another environment. FixSynoboot.sh
    45 points
  10. Before installing XPEnology using DSM 7.x, you must select a DSM platform and loader. XPEnology supports a variety of platforms that enable specific hardware and software features. All platforms support a minimum of 4 CPU cores, 64GB of RAM, 10Gbe network cards and 16 drives. Each can run "baremetal" as a stand-alone operating system OR as a virtual machine within a hypervisor. A few specific platforms are preferred for typical installs. Review the table and decision tree below to help you navigate the options. NOTE: DSM 6.x is still a viable system and is the best option for certain types of hardware. See this link for more information. DSM 7.x LOADERS ARE DIFFERENT: A loader allows DSM to install and run on non-Synology hardware. The loaders for DSM 5.x/6.x were monolithic; i.e. a single loader image was applicable to all installs. With DSM 7.x, a custom loader must be created for each DSM install. TinyCore RedPill (TCRP) is currently the most developed tool for building 7.x loaders. TCRP installs with two step-process. First, a Linux OS (TinyCore) boots and evaluates your hardware configuration. Then, an individualized loader (RedPill) is built and written to the loader device. After that, you can switch between starting DSM with RedPill, and booting back into TinyCore to adjust and rebuild as needed. TCRP's Linux boot image (indicated by the version; i.e. 0.8) changes only when a new DSM platform or version is introduced. However, you can and should update TCRP itself prior to each loader build, adding fixes, driver updates and new features contributed by many different developers. Because of this ongoing community development, TCRP capabilities change rapidly. Please post new or divergent results when encountered, so that this table may be updated. 7.x Loaders and Platforms as of 06-June-2022 Options Ranked 1a 1b 2a 2b 2c 3a 3b DSM Platform DS918+ DS3622xs+ DS920+ DS1621+ DS3617xs DVA3221 DS3615xs Architecture apollolake broadwellnk geminilake v1000 broadwell denverton bromolow DSM Versions 7.0.1-7.1.0-42661 7.0.1-7.1.0-42661 7.0.1-7.1.0-42661 7.0.1-7.1.0-42661 7.0.1-7.1.0-42661 7.0.1-7.1.0-42661 7.0.1-7.1.0-42661 Loader TCRP 0.8 TCRP 0.8 TCRP 0.8 TCRP 0.8 TCRP 0.8 TCRP 0.8 TCRP 0.8 Drive Slot Mapping sataportmap/ diskidxmap sataportmap/ diskidxmap device tree device tree sataportmap/ diskidxmap sataportmap/ diskidxmap sataportmap/ diskidxmap QuickSync Transcoding Yes No Yes No No No No NVMe Cache Support Yes Yes Yes Yes Yes (as of 7.0) Yes No RAIDF1 Support No Yes No No Yes No Yes Oldest CPU Supported Haswell * any x86-64 Haswell ** any x86-64 any x86-64 Haswell * any x86-64 Max CPU Threads 8 24 8 16 24 (as of 7.0) 16 16 Key Note currently best for most users best for very large installs see slot mapping topic below AMD Ryzen, see slot mapping topic obsolete use DS3622xs+ AI/Deep Learning nVIDIA GPU obsolete use DS3622xs+ * FMA3 instruction support required. All Haswell Core processors or later support it. Very few Pentiums/Celerons do (J-series CPUs are a notable exception). Piledriver is believed to be the minimum AMD CPU architecture equivalent to Intel Haswell. ** Based on history, DS920+ should require Haswell. There is anecdotal evidence gradually emerging that DS920+ will run on x86-64 hardware. NOT ALL HARDWARE IS SUITABLE: DSM 7 has a new requirement for the initial installation. If drive hotplug is supported by the motherboard or controller, all AHCI SATA ports visible to DSM must either be configured for hotplug or have an attached drive during initial install. Additionally, if the motherboard or controller chipset supports more ports than are physically implemented, DSM installation will fail unless they are mapped out of visibility. On some hardware, it may be impossible to install (particularly on baremetal) while retaining access to the physical ports. The installation tutorial has more detail on the causes of this problem, and possible workarounds. DRIVE SLOT MAPPING CONSIDERATIONS: On most platforms, DSM evaluates the boot-time Linux parameters SataPortMap and DiskIdxMap to map drive slots from disk controllers to a usable range for DSM. Much has been written about how to set up these parameters. TCRP's satamap command determines appropriate values based on the system state during the loader build. It is also simple to manually edit the configuration file if your hardware is unique or misidentified by the tool. On the DS920+ and DS1621+ platforms, DSM uses a Device Tree to identify the hardware and ignores SataPortMap and DiskIdxMap. The device tree hardcodes the SATA controller PCI devices and drive slots (and also NVMe slots and USB ports) prior to DSM installation. Therefore, an explicit device tree that matches your hardware must be configured and stored within the loader image. TCRP automatic device tree configuration is limited. For example, any disk ports left unpopulated at loader build time will not be accessible later. VMware ESXi is not currently supported. Host bus adapters (SCSI, SAS, or SATA RAID in IT mode) are not currently supported. Manually determining correct values and updating the device tree is complex. Device Tree support is being worked on and will improve, but presently you will generally be better served by choosing platforms that support SataPortMap and DiskIdxMap (see Tier 1 below). CURRENT PLATFORM RECOMMENDATIONS AND DECISION TREE: VIRTUALIZATION: All the supported platforms can be run as a virtual machine within a hypervisor. Some use case examples: virtualize unsupported network card virtualize SAS/NVMe storage and present to DSM as SATA run other VMs in parallel on the same hardware (as an alternative to Synology VMM) share 10GBe network card with other non-XPEnology VMs testing and rollback of updates Prerequisites: ESXi (requires a paid or free license) or open-source hypervisor (QEMU, Proxmox, XenServer). Hyper-V is NOT supported. Preferred Configurations: passthrough SATA controller and disks, and/or configure RDM/RAW disks This post will be updated as more documentation is available for the various TCRP implementations.
    42 points
  11. DSM 6.2.3 will not work with these drivers, if you install or update you will fall back to "native" drivers that come with DSM, like no realtek nic on 3615/17 but on 918+ or no mpt2/mpt3sas on 918+ or no broadcom onboard nic on HP microserver or Dell server read this if you want to know about "native" drivers https://xpenology.com/forum/topic/13922-guide-to-native-drivers-dsm-617-and-621-on-ds3615/ synology reverted the changes made in 6.2.2 so the old drivers made for 6.2.(0) are working again and there are new drivers made for 6.2.3 too (we got recent kernel source from synology lately) https://xpenology.com/forum/topic/28321-driver-extension-jun-104b-for-dsm623-for-918/ This is the new 2nd test version of the driver extension for loader 1.04b and 918+ DSM 6.2.2, network drivers for intel and realtek are now all latest and the same as in 3615/17 from mid. december (also broadcoam tg3 driver is working), tries to address the problems with the different GPU's by haveing 3 versions of the pack additional information and packages for 1.03b and 3615/3617 are in the lower half under a separate topic (i will unify the 918+ and 3615/17 parts later as they are now on the same level again) mainly tested as fresh install with 1.04b loader with DSM 6.2.2, there are extra.lzma and extra2.lzma in the zip file - you need both - the "extra2" file is used when booting the 1st time and under normal working conditions the extra.lzma is used (i guess also normal updates - jun left no notes about that so i had to find out and guess). Hardware in my test system used additional driver: r8168, igb, e1000e, bnx2x, tn40xx, mpt2sas The rest of the drivers just load without any comment on my system, i've seen drivers crashing only when real hardware is present so be warned, i assume any storage driver beside ahci and mps2sas/mpt3sas as not working, so if you use any other storage as listed before you would need to do a test install with a new usb and a single empty disk to find out before doing anything with your "production" system i suggest testing with a new usb and a empty disk and it that's ok then you have a good chance for updating for updating its the same as below in the 3615/17 section with case 1 and 2 but you have extra.lzma and extra2.lzma and you will need to use https://archive.synology.com/download/DSM/release/6.2.2/24922/DSM_DS918+_24922.pat most important is to have zImage and rd.gz from the "DSM_DS918+_24922.pat" file (can be opened with 7zip) together with the new extra/extra2, same procedure as for the new extra for 3615/17 (see below) all 4 files extra.lzma, extra2.lzma (both extracted from the zip downloaded), zImage and rd.gz go to the 2nd partition of the usb (or image when using osfmount), replacing the 4 files there if you want the "old" files of the original loader back you can always use 7zip to open the img file from jun and extract the original files for copying them to usb if really wanting to test with a running 6.2.x system then you should empty /usr/lib/modules/update/ and /usr/lib/firmware/i915/ before rebooting with the new extra/extra2 rm -rf /usr/lib/modules/update/* rm -rf /usr/lib/firmware/i915/* the loader will put its files on that locations when booting again, this step will prevent having old incompatible drivers in that locations as the loader replaces only files that are listed in rc.modules and in case of "syno" and "recovery" there are fewer entries, leaving out i915 related files, as long as the system boots up this cleaning can be done with the new 0.8 test version there a 3 types of driver package, all come with the same drivers (latest nic drivers for realtek and intel) and conditions/limitations as the 3615/17 driver set from mid. december (mainly storage untested, ahci and mpt3sas is tested). 1. "syno" - all extended i915 stuff removed and some firmware added to max compatibility, mainly for "iGPU gen9" (Skylake, Apollo Lake and some Kaby Lake) and older and cases where std did not work, i915 driver source date: 20160919, positive feedback for J3455, J1800 and N3150 2. "std" - with jun's i915 driver from 1.04b (tested for coffee lake cpu from q2/2018), needed for anything newer then kaby lake like gemini lake, coffee lake, cannon lake, ice lake, i915 driver source date: 20180514 - as i had no source i915 driver is the same binary as in jun's original extra/extra2, on my system its working with a G5400, not just /dev/dri present, tested completely with really transcoding a video, so its working in general but might fail in some(?) cases, also 8th/9th gen cpu like i3/i5 8100/9400 produce a /dev/dri, tested with a 9400 and it does work 3. "recovery" - mainly for cases where the system stops booting because of i915 driver (seen on one N3150 braswell), it overwrites all gpu drivers and firmware with files of 0 size on booting so they can't be loaded anymore, should also work for any system above but guarantees not having /dev/dri as even the firmware used from the dsm's own i915 driver is invalid (on purpose) - if that does not work its most likely a network driver problem, safe choice but no transcoding support start with syno, then std and last resort would be recovery anything with a kernel driver oops in the log is a "invalid" as it will result in shutdown problems - so check /var/log/dmesg the often seen Gemini Lake GPU's might work with "std", pretty sure not with "syno", most (all?) testers with gemini lake where unsuccessful with "std" so if you don't like experimenting and need hardware transcoding you should wait with the version you have the "_mod" on the end of the loader name below is a reminder that you need to to "modding" as in make sure you have zImage and rd.gz from DSM 6.2.2 on you usb for booting, the new extra.lzma will not work with older files 0.8_syno ds918+ - extra.lzma/extra2.lzma for loader 1.04b_mod ds918+ DSM 6.2.2 v0.8_syno https://gofile.io/d/mVBHGi SHA256: 21B0CCC8BE24A71311D3CC6D7241D8D8887BE367C800AC97CE2CCB84B48D869A Mirrors by @rcached https://clicknupload.cc/zh8zm4nc762m https://dailyuploads.net/qc8wy6b5h5u7 https://usersdrive.com/t0fgl0mkcrr0.html https://www104.zippyshare.com/v/hPycz12O/file.html 0.8_std ds918+ - extra.lzma/extra2.lzma for loader 1.04b_mod ds918+ DSM 6.2.2 v0.8_std https://gofile.io/d/y8neID SHA256: F611BCA5457A74AE65ABC4596F1D0E6B36A2749B16A827087D97C1CAF3FEA89A Mirrors by @rcached https://clicknupload.cc/h9zrwienhr7h https://dailyuploads.net/elgd5rqu06vm https://usersdrive.com/peltplqkfxvj.html https://www104.zippyshare.com/v/r9I7Tm0K/file.html 0.8_recovery ds918+ - extra.lzma/extra2.lzma for loader 1.04b_mod ds918+ DSM 6.2.2 v0.8_recovery https://gofile.io/d/4K3WPE SHA256: 5236CC6235FB7B5BB303460FC0281730EEA64852D210DA636E472299C07DE5E5 Mirrors by @rcached https://clicknupload.cc/uha07uso7vng https://dailyuploads.net/uwh710etr3hm https://usersdrive.com/ykrt1z0ho7cm.html https://www104.zippyshare.com/v/7gufl3yh/file.html !!! still network limit in 1.04b loader for 918+ !!! atm 918+ has a limit of 2 nic's (as the original hardware) If there are more than 2 nic's present and you can't find your system in network then you will have to try after boot witch nic is "active" (not necessarily the onboard) or remove additional nic's and look for this after installation You can change the synoinfo.conf after install to support more then 2 nic's (with 3615/17 it was 8 and keep in mind when doing a major update it will be reset to 2 and you will have manually change this again, same as when you change for more disk as there are in jun's default setting) - more info's are already in the old thread about 918+ DSM 6.2.(0) and here https://xpenology.com/forum/topic/12679-progress-of-62-loader/?do=findComment&comment=92682 I might change that later so it will be set the same way as more disks are set by jun's patch - syno's max disk default for this hardware was 4 disks but jun's pach changes it on boot to 16!!! (so if you have 6+8 sata ports then you should not have problems when updating like you used to have with 3615/17) Basically what is on the old page is valid, so no sata_*, pata_* drivers Here are the drivers in the test version listed as kernel modules: The old thread as reference !!! especially read "Other things good to know about DS918+ image and loader 1.03a2:" its still valid for 1.04b loader !!! This section is about drivers for ds3615xs and ds3617xs image/dsm version 6.2.2 (v24922) Both use the same kernel (3.10.105) but have different kernel options so don't swap or mix, some drivers might work on the other system some don't at all (kernel oops) Its a test version and it has limits in case of storage support, read careful and only use it when you know how to recover/downgrade your system !!! do not use this to update when you have a different storage controller then AHCI, LSI MPT SAS 6Gb/s Host Adapters SAS2004/SAS2008/SAS2108/SAS2116/SAS2208/SAS2308/SSS6200 (mpt2sas) or LSI MPT SAS 12Gb/s Host Adapters SAS3004/SAS3008/SAS3108 (mpt3sas - only in 3617), instead you can try a fresh "test" install with a different usb flash drive and a empty single disk on the controller in question to confirm if its working (most likely it will not, reason below) !!! The reason why 1.03b loader from usb does not work when updating from 6.2.0 to 6.2.2 is that the kernel from 6.2.2 has different options set witch make the drivers from before that change useless (its not a protection or anything), the dsm updating process extracts the new files for the update to HDD, writes the new kernel to the usb flash drive and then reboots - resulting (on USB) in a new kernel and a extra.lzma (jun's original from loader 1.03b for dsm 6.2.0) that contains now incompatible drivers, the only drivers working reliable in that state are the drivers that come with dsm from synology Beside the different kernel option there is another thing, nearly none of the new compiled scsi und sas drivers worked They only load as long as no drive is connected to the controller. ATM I assume there was some changes in the kernel source about counting/indexing the drives for scsi/sas, as we only have the 2.5 years old dsm 6 beta kernel source there is hardly a way to compensate People with 12GBit SAS controllers from LSI/Avago are in luck, the 6.2.2 of 3617 comes with a much newer driver mpt3sas then 6.2.0 and 6.2.1 (13.00 -> 21.00), confirmed install with a SAS3008 based controller (ds3617 loader) Driver not in this release: ata_piix, mptspi (aka lsi scsi), mptsas (aka lsi sas) - these are drivers for extremely old hardware and mainly important for vmware users, also the vmw_pvscsi is confirmed not to work, bad for vmware/esxi too Only alternative as scsi diver is the buslogic, the "normal" choice for vmware/ESXi would be SATA/AHCI I removed all drivers confirmed to not work from rc.modules so they will not be loaded but the *.ko files are still in the extra.lzma and will be copied to /usr/modules/update/ so if some people want to test they can load the driver manually after booting These drivers will be loaded and are not tested yet (likely to fail when a disk is connected) megaraid, megaraid_sas, sx8, aacraid, aic94xx, 3w-9xxx, 3w-sas, 3w-xxxx, mvumi, mvsas, arcmsr, isci, hpsa, hptio (for some explanation of what hardware this means look into to old thread for loader 1.02b) virtio driver: i added virtio drivers, they will not load automatically (for now), the drivers can be tested and when confirmed working we will try if there are any problems when they are loaded by default along with the other drivers they should be in /usr/modules/update/ after install To get a working loader for 6.2.2 it needs the new kernel (zImage and rd.gz) and a (new) extra.lzma containing new drivers (*.ko files) zImage and rd.gz will be copied to usb when updating DSM or can be manually extracted from the 6.2.2 DSM *.pat file and copied to usb manually and that's the point where to split up between cases/way's case 1: update from 6.2.0 to 6.2.2 case 2: fresh install with 6.2.2 or "migration" (aka upgrade) from 6.0/6.1 Case 1: update from 6.2.0 to 6.2.2 Basically you semi brick your system on purpose by installing 6.2.2 and when booting fails you just copy the new extra.lzma to your usb flash drive by plugging it to a windows system (witch can only mount the 2nd partition that contains the extra.lzma) or you mount the 2nd partition of the usb on a linux system Restart and then it will finish the update process and when internet is available it will (without asking) install the latest update (at the moment update4) and reboot, so check your webinterface of DSM to see whats going or if in doubt wait 15-20 minutes check if the hdd led's are active and check the webinterface or with synology assistant, if there is no activity for that long then power off and start the system, it should work now Case 2: fresh install with 6.2.2 or "migration" (aka upgrade) from 6.0/6.1 Pretty much the normal way as described in the tutorial for installing 6.x (juns loader, osfmount, Win32DiskImager) but in addition to copy the extra.lzma to the 2nd partition of the usb flash drive you need to copy the new kernel of dsm 6.2.2 too so that kernel (booted from usb) and extra.lzma "match" You can extract the 2 files (zImage and rd.gz) from the DSM *.pat file you download from synology https://archive.synology.com/download/DSM/release/6.2.2/24922/DSM_DS3615xs_24922.pat or https://archive.synology.com/download/DSM/release/6.2.2/24922/DSM_DS3617xs_24922.pat These are basically zip files so you can extract the two files in question with 7zip (or other programs) You replace the files on the 2nd partition with the new ones and that's it, install as in the tutorial In case of a "migration" the dsm installer will detect your former dsm installation and offer you to upgrade (migrate) the installation, usually you will loose plugins, but keep user/shares and network settings DS3615: extra.lzma for loader 1.03b_mod ds3615 DSM 6.2.2 v0.5_test https://gofile.io/d/iQuInV SHA256: BAA019C55B0D4366864DE67E29D45A2F624877726552DA2AD64E4057143DBAF0 Mirrors by @rcached https://clicknupload.cc/h622ubb799on https://dailyuploads.net/wxj8tmyat4te https://usersdrive.com/sdqib92nspf3.html https://www104.zippyshare.com/v/Cdbnh7jR/file.html DS3617: extra.lzma for loader 1.03b_mod ds3617 DSM 6.2.2 v0.5_test https://gofile.io/d/blXT9f SHA256: 4A2922F5181B3DB604262236CE70BA7B1927A829B9C67F53B613F40C85DA9209 Mirrors by @rcached https://clicknupload.cc/0z7bf9stycr7 https://dailyuploads.net/68fdx8vuwx7y https://usersdrive.com/jh1pkd33tmx0.html https://www104.zippyshare.com/v/twDIrPXu/file.html
    42 points
  12. Loader Information and Background RedPill is the core technology that enables DSM 7.x to run on non-Synology hardware. This post is intended to serve as a definitive tutorial/reference for configuring @pocopico's TinyCore RedPill (TCRP) loader. It explains how to install TCRP on baremetal, i.e. with DSM as the only operating system on your NAS hardware. A tutorial to install TCRP using the ESXi hypervisor is located here. There are other hypervisor tutorials in the Tutorials and Guides forum. TCRP uses a two step-process. First, a Linux OS (TinyCore) boots and evaluates the NAS hardware configuration. Therefore, it is best to have the hardware you plan to use (disk controllers and network cards in particular) installed prior to starting the TCRP setup. Then, an individualized loader (RedPill) is created. This loader is used to install and run DSM. After that, you can switch between starting DSM with RedPill, and booting back into TinyCore to adjust and rebuild the loader as needed. Basic Linux command line skills are needed to complete the installation. The tutorial provides examples of the commands that are needed, but exact syntax and capitalization are critical. If unfamiliar, research and review the following minimal list of commands: ls show the files in the current directory cat <file> show the contents of the specified file pwd show the current directory name cd <directory path> change to the specified directory (same rules as Windows, except with forward slashes instead of backslashes). With no argument, it returns to the “home” TCRP directory vi <file> a file editor, for manual editing of configuration files if required Ongoing Development This tutorial is maintained for consistency with the pocopico stable repository. Since TCRP is completely open-sourced, anyone can fork their own repo and contribute to development, and pocopico now maintains a separate development repo. As the best features and ideas are fully vetted and tested, they may be incorporated into the stable repo over time. If you use a repo, script or shell other than the pocopico stable repo, the loader may behave quite differently and the instructions and troubleshooting steps in this tutorial might no longer apply. In an open-source community, you can use any development resource you want, but you add the additional responsibility of understanding, vetting and testing that code on your system. Migration Step 1. Choose a DSM Platform/Architecture Evaluate your intended NAS hardware and your the intended use of DSM, and select a platform that best meets your needs. Reference information here: https://xpenology.com/forum/topic/61634-dsm-7x-loaders-and-platforms/ Write down the selected platform (e.g. DS918+), the corresponding architecture (e.g. apollolake) and whether the platform uses SataPortMap/DiskIdxMap or Device Tree for slot mapping. This information will be needed later. Now, make sure the NAS hardware is compatible, and prepare it correctly: x86-64-compatible CPU with two cores or more Each platform have maximum threads support! Any threads in excess will be ignored For certain platforms, Intel CPUs must be 4th generation “Haswell” or newer with FMA3 instruction set The corresponding AMD CPU architecture is “Piledriver” or newer AMD-based systems may require deactivation of the C1E option in the BIOS 2GB of RAM or more 2GB or larger USB flash drive Configure the BIOS to boot from the USB flash drive ONLY SATA disk controllers are preferred, but SCSI/SAS are compatible IMPORTANT: All SATA controllers must be configured to AHCI mode SATA controllers with port multipliers are not compatible ATA controllers are not compatible (disable embedded ATA in BIOS if possible) At least one SATA/SCSI/SAS drive (HDD or SSD), minimum size 21GB IMPORTANT: Enable SATA port hotplug on each disk port, if hotplug is supported by the BIOS/controller IMPORTANT: Disable M.2 SATA ports that are not in use, if supported by the BIOS/controller NVMe drives are not usable except as dedicated cache devices Host Bus Adapters are not currently compatible with Device Tree platforms Install any NVMe drives intended as cache devices On Device Tree platforms, NVMe drives must be installed prior to loader installation in order for them to be recognized Step 2. Download TCRP and Write Image to the USB Flash Drive The latest pocopico stable loader code is always linked here: https://xpenology.com/forum/topic/7848-links-to-loaders/ Download the tinycore-redpill 7.x loader and save it to your personal computer. Then, open it with a zip manager to show the boot images: tinycore-redpill.vX.X.X.img.gz (for BIOS/CSM/Legacy boot from USB flash drive) tinycore-redpill-uefi.vX.X.X.img.gz (for UEFI/EFI boot from USB flash drive) tinycore-redpill.vX.X.X.vmdk.gz (for virtual machine SATABOOT from disk image) Select the boot image that matches the boot capability of the NAS motherboard. If unsure, choose BIOS/CSM/Legacy boot. Save the gzip file to your personal computer, then open it with a zip archive manager and save the uncompressed version. Write the uncompressed image to the USB flash drive using Win32DiskImager or other appropriate tool. The USB flash drive is used to store TinyCore and the RedPill loader that it generates. It is a permanent component of an operational XPEnology system. Do not remove it, even after the DSM installation is complete and the NAS is fully up and running. Step 3. Boot into TinyCore and Complete Pre-Configuration Updates Start your NAS with the USB flash drive installed and TinyCore will boot. Then, launch a command-line session with either of these methods: Click the Terminal icon at the bottom right of the TinyCore desktop to launch a console window Use a ssh client (e.g. PuTTY) on your computer to connect a network-based console Consult your DHCP server/router for the IP address assignment (TinyCore's host name is "box") Login credentials: tc/P@ssw0rd When the Linux command line prompt ($) is displayed, update the TCRP script ./rploader.sh update Checking Internet Access -> OK Checking if a newer version exists -> There is a newer version on the repo should we use that ? [yY/nN] Y OK, updating, please re-run after updating Updating tinycore loader with latest updates Backing up files to /mnt/sda3//mydata.tgz Then, update the TCRP support files ./rploader.sh fullupgrade <downloads snipped> Current /home/tc size is 114M , try to keep it less than 1GB as it might not fit into your image Should i update the sda with your current files [Yy/Nn] Y Backing up home files to sda : Backing up files to /mnt/sda3//mydata.tgz Finally, choose a DSM release number Each DSM build as provided by Synology has a release number. You can display the combinations of platforms and releases supported by TCRP by just running the script with no arguments ./rploader.sh <command help snipped> Available platform versions: ---------------------------------------------------------------------------------------- apollolake-7.0-41890 apollolake-7.0.1-42218 apollolake-7.1.0-42661 broadwell-7.0.1-42218 broadwell-7.1.0-42661 broadwellnk-7.0.1-42218 broadwellnk-7.1.0-42661 bromolow-7.0.1-42218 bromolow-7.1.0-42661 denverton-7.0.1-42218 denverton-7.1.0-42661 geminilake-7.0.1-42218 geminilake-7.1.0-42661 v1000-7.0.1-42218 v1000-7.1.0-42661 Step 4. Configure System-Specific Parameters Custom system parameters are stored in the user_config.json file. This can be manually edited, or TCRP can help determine appropriate values for the hardware. USB flash drive VID/PID: TCRP can query the USB flash drive for the hardware vid/pid values that DSM uses to identify the loader during bootup ./rploader.sh identifyusb Found: Superdisk Flash SerialNumber: 123456 Vendor ID: 0x1234 Product ID: 0x0001 Should i update the user_config.json with these values ? [Yy/Nn] Y Serial number/MAC: TCRP can automatically generate a serial number for the platform selected in step 1. Additionally, it will generate a random MAC address for the NAS network card. If you prefer to use the actual hardware MAC address instead, append "realmac" to the command. Example 1: random MAC address ./rploader.sh serialgen DS3622xs+ Serial Number for Model : 20C0SQRLR47QM Mac Address for Model DS3622xs+ : 00:11:32:80:B2:36 Should i update the user_config.json with these values ? [Yy/Nn] Y Example 2: real MAC address ./rploader.sh serialgen DS3622xs+ realmac Serial Number for Model : 2150SQRGS7N5T Mac Address for Model DS3622xs+ : 00:11:32:57:3A:9B Real Mac Address : 00:0C:24:62:3E:3D Notice : realmac option is requested, real mac will be used Should i update the user_config.json with these values ? [Yy/Nn] Y Drive Slot Mapping: TCRP can try to determine how to map the NAS disk controller ports to DSM slots. If the chosen platform uses SataPortMap/DiskIdxMap for port mapping, the command below will do this. If it uses Device Tree for slot mapping, the command may be skipped, as the Device Tree is configured automatically during the loader build. ./rploader.sh satamap Found "02:02.0 SATA AHCI controller" Detected 4 ports/2 drives. Override # of ports or ENTER to accept: <4> Recommended settings: SataPortMap=4 DiskIdxMap=00 Should I update the user_config with these values ? [Yy/Nn] Y If the port count is not what you expect, it may be due to the motherboard design servicing physical ports with multiple controllers, or because of M.2 SATA slot support. If necessary, the port count can be overridden with whatever you like. NOTE: If you see a WARNING message, it is certain that either some of your drives are inaccessible or the DSM install will encounter problems. Evaluate and investigate the issue. The satamap command can be rerun as many times as needed to understand the system. Manual Review: With prior loaders (such as Jun's), the configuration of these parameters was completely manual. There is no single setup that works for all hardware. Even after using the tools above, please review and verify the parameters, understand what they do, and manually edit if needed. Whatever changes rploader.sh makes to the user_config.json file can be reviewed by displaying the file contents cat user_config.json and overridden by editing the file vi user_config.json You can also add a simpler editor, nano tce-load -iw nano nano user_config.json And there is also a graphical editor accessible from the TinyCore desktop Step 5. Optional: Manually Add Driver Extensions While TCRP can automatically add drivers based on the detected NAS hardware, it isn’t foolproof. You might want to build a loader for a device you don’t actually have yet. And there are features that are "opt-in" only. So, a process exists to manually add drivers and other functionality. Extensions are stored in repositories hosted on the web. All the extensions in the main repository are viewable here: https://github.com/pocopico/rp-ext To list all the extensions recommended by TCRP's hardware detection algorithm, use ./rploader.sh listmods <architecture>-<version>-<DSMreleasenumber> ./rploader.sh listmods apollolake-7.1.0-42661 To add a specific extension, choose from the list and reference the architecture from Step 1. ./rploader.sh ext <architecture>-<version>-<DSMreleasenumber> <extensionurl> ./rploader.sh ext apollolake-7.1.0-42661 add https://raw.githubusercontent.com/pocopico/rp-ext/master/redpill-acpid/rpext-index.json ./rploader.sh ext denverton-7.1.0-42661 add https://raw.githubusercontent.com/pocopico/rp-ext/master/v9fs/rpext-index.json The examples illustrate adding ACPI and VIRTIO support. These are often chosen enhancements to a basic installation. Step 6. Build the Loader When all preparation steps are complete, build the loader using the command structure ./rploader.sh build <architecture>-<version>-<DSMreleasenumber> Example #1: DS3622xs+, auto detect hardware ./rploader.sh build broadwellnk-7.1.0-42661 Example #2: DS918+, use preselected drivers ./rploader.sh build apollolake-7.1.0-42661 manual TCRP will download resources from the Internet to complete the complex process of the loader build. When finished, it will write it to the USB flash drive and add new items to the GRUB boot menu. Review the output for any errors and make corrections if necessary. Step 7. Optional Backup Tasks Save the TinyCore configuration state as the default, so that the next boot of TInyCore starts with all your settings ./rploader.sh backup Back up the generated RedPill loader partition to available space on the USB flash drive ./rploader.sh backuploader Step 8: Restart and Boot DSM Using the Grub USB Option Cleanly shutdown and reboot with the TinyCore command exitcheck.sh reboot First, the GRUB Menu is displayed. If necessary, use the arrow keys to ensure that USB is selected and press ENTER. The loader will show some initialization information and silently boot DSM. Nothing else will be displayed unless a serial console is attached (see the Troubleshooting section below). Wait a few minutes, then launch either https://find.synology.com or the Synology Assistant desktop utility. If the loader is working properly, a new "SynologyNAS" will be displayed as Not installed (for a new build) or the name of your existing Migratable NAS (if upgrading from a previous version). Use your browser to connect to the NAS. If "Something went wrong" is displayed, jump to the Basic Troubleshooting section below. Otherwise, browse to the Synology Download Center and download the DSM install PAT file that matches the platform and release number specified in the loader build. Do not use the PAT file stored in TinyCore. It has modifications that are incompatible with DSM installation. However, its name may help identify the correct PAT file to download below. There can be several files that appear to be candidates. PAT files marked VirtualDSM will not work. Also there can be patch PAT files with the same numbering. These will not work and will usually be smaller than 50MB. The correct PAT file is 300MB or larger. Once the correct DSM PAT file is saved to your personal computer, upload it to the NAS. Follow the prompts to complete the installation. FOR UPGRADES ONLY: If Synology Assistant shows Not installed, or if prompted to erase the disks during the upgrade, STOP! Some or all of your array disks are not visible to DSM. This must be resolved via troubleshooting and reconfiguration before installing DSM 7.x. IMPORTANT: During the install, always select DSM manual updates. If a new install completes normally, but then fails after the reboot, it may be that DSM has attempted to auto-update itself with incompatible code. Basic Troubleshooting Where to Post for Help It’s easy for requests for installation help to get lost in various unrelated forum threads. Post requests for help as a new topic in the DSM Installation Forum. At a minimum, state the hardware configuration, selected platform, DSM version, user_config.json information (delete or redact the serial number and configured MAC address) and any information from debugging analysis that you have done. DON’T post general requests for help on this thread. Please DON’T post general requests for help on TCRP or RedPill development threads unless providing feedback on a dev issue.
    40 points
  13. edit 14.05.2020: 6.2.3 is back online as v25426, for newer coffeelake cpu's with problems using hardware transcoding (dev/dri present after boot) there is a new videostation that fixes the problem https://xpenology.com/forum/topic/28321-driver-extension-jun-104b-for-dsm623-for-918/?do=findComment&comment=144918 edit2 02.06.2020: as @richv31 pointed out here https://xpenology.com/forum/topic/21663-driver-extension-jun-103b104b-for-dsm622-for-3615xs-3617xs-918/?do=findComment&comment=148564 there seems to be a serious problem with 918+ and scsi/sas drivers, at least with mpt2sas/mpt3sas, not just with 6.2.2/6.2.3 it also happens with jun's original loader 1.04b and dsm 6.2.0 (23824), breaking raid sets after not properly waking up from hdd hibernation means potential data loss i had a two disk raid1 set on a lsi 9211-8i and after disks spinning down only one came up and i saw some really worrying messages on the serial console, i was not able to log in to the system, not on the web gui, even not on the serial console, the whole system was in lock down and only switching off seemed to work as of the problems with not getting s.m.a.r.t. values i used juns old original raid_class.ko, scsi_transport_sas.ko, scsi_transport_spi.ko to get the old state back (replacing my newly made ones from more recent synology kernel source 24922 ) in 0.11/0.12 - these version inherit the problem that seems to be present since the beginning with loader 1.04b anyone using mpt2sas/mpt3sas and disk hibernation on 918+ should disable it for now to not risk any data loss the new 0.13 for 918+ will have the raid_class.ko, scsi_transport_sas.ko, scsi_transport_spi.ko from kernel source 24922, that version did work on testing on my system without breaking anything and without such alarming errors on wakeup of disks, there will be no smart data but at least it seems safer then disks not waking up properly for "proper" lsi sas controller support i'd suggest using 3615 or 3617 as it is "native" in these units and should work better, maybe there are kernel options missing in the 918+ kernel and that cant be fixed, if anyone finds out more just add a comment (i might not have the time to dig into this) the other alternative is to use sata/ahci instead of scsi/sas with 918+, that works without problems on my system using 918+ (12 disks), JMB585 based controller seem to be the best choice atm as they support pcie 3.0 and can have up to 2000 MByte/s for its 5 sata ports (the older marvell and asm chips use only pcie 2.0 limiting the data rate to 500 MB/s or 1000 MB/s, even 8 port controller with two of the older chips use a pcie bridge chip with just two lanes making them terrible choice for a high port count - might be ok with just one or two 1GBit nic's but will at least limit the rebuild speed and ssd's should be kept away from these controllers and place in internal sata ports) for Instructions about installing or updating please read "Driver extension jun 1.03b/1.04b for DSM6.2.2 for 3615xs / 3617xs / 918+" if i have time i will write more in this place the new package is not well tested i just did some tests with hardware i have at hand (ahci, e1000e, r8168, igb, bnx2x, mpt2sas/mpt3sas) and tested update from 6.2.2 to 6.2.3 basically synology reverted the kernel config change made in 6.2.2 back to what was before so old drivers from original 1.04b loader (and older driver i made before 6.2.2) should work again - but as synology also introduced there own new i915 driver with 6.2.3 there will be a conflict when jun's i915 driver is loaded with 6.2.3 there are two positive new things, synology released a nearly recent kernel source code (24922) and 6.2.3 has a new i915 driver supporting as much gpu hardware as jun's backported i915 driver in loader 1.04b - so there is no need for jun's i915 driver anymore and in theory we should have good support for apollo lake, gemini lake and other newer hardware but it seems not all new UHD630 is supported as there is dev id "3E98" unsupported (i5-9400, i5-9600k, i7-9700t, i7-9700), ark.intel.com and wikichip.og are usually good sources to check the id https://ark.intel.com/content/www/us/en/ark/products/134898/intel-core-i5-9400-processor-9m-cache-up-to-4-10-ghz.html edit: there seems to be versions of the i5-9400 with a "3E92" GPU this versions don t need the patched driver, they will run with the default driver, /dev/dri should be present ootb, it also can be checked in /var/log/dmesg when searching for "[8086:3e92]" https://en.wikichip.org/wiki/intel/core_i5/i5-9400 there is also a good document from intel listing all coffeelake's https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-cfl-vol01-configurations.pdf coffeelake cup's without driver support (no hardware transcoding), SKU numbers should be listed when buying and can be checked on the box i9 SKU S82 i7 SKU S82 i5 SKU S6f2 a new 10th gen i5-10500 / i3-10300 have device id's "9BC8" and there are no "9xxx" numbers in the driver we use so don't expect any newer gen10 cpu to work with hardware transcoding even when it "only" has UHD630 igpu edit: there are also even lower end 10th gen cpus (2 core) with a different GPU device id "9BA8" like G5920, G5925, G6400 with a iGPU UHD 610, the equivalent in the 9th gen would be a G5400 and that comes with pci device id's 3E90/3E93, so we need to edit a different entry when patching for this edit: i made a modded i915 driver were the pci device id of the 9th gen UHD 630 iGPU (3E92/3E93) is replaces with the device id's of the newer/different UHD 610/630 iGPU's that are unsupported 8086:3E92 => iGPU UHD 630, Low End Desktop 9 Series (original driver) -> 8086:3E98 => iGPU UHD 630, High End Desktop 9 Series (i5-9400, i5-9600k, i7-9700t, i7-9700) 8086:9BC8 => iGPU UHD 630, Low End Desktop i5-10500, i5-10600T and lower 8086:9BC5 => iGPU UHD 630, High End Desktop i510600K and higher 8086:3E93 => iGPU UHD 610, Low End Desktop 9 Series -> 8086:9BA8 => iGPU UHD 610, low End Desktop Series like G6400 the zip file contains 3 versions in every one is 3E92 replaced with the one we want to get working, as its just a crude binary patch i choose 3E92 as it seemed the most similar device, was tested for 3E98 iGPU and seemed to work, for the 10th there is at least one positive feedback with plex its intended to be used with the extra/extra2 from this thread as this removes jun's old i915 driver (not just one file) that will prevent synologys new driver to work properly the patched i915.ko file is supposed to be copied to /usr/lib/modules/ and replaces the original file from synology for 6.2.3 Update3 (added 9BA8 support) https://gofile.io/d/4fFJA5 https://dailyuploads.net/x3e0nkxk6p0e https://usersdrive.com/zfl9csl91xwr.html https://www34.zippyshare.com/v/304gfbnO/file.html SHA256: EC2447F47FEE6457FE3F409E26B83E5BF73023310E10A624575A822FDBC10642 a little warning, in worst case the system might crash or freeze when transcoding and and such undefined states and hard resets can result i data loss (cache) or damaged raids (depending on the load of the system at this time) so until its more tested it should not be used on system with "important" data and a recent backup - ok i know its a little over cautious but i dont like the thought someone looses data because of this nice to have feature (software mdadm raids can be repaired in most cases if the worst happens) -> positive feedback for a i5-9400, i5-9600K, i9-9900T (8086:3E98) to fully working -> positive feedback for a G6400 (8086:9BA8) to have /dev/dri -> one user positive feedback for a i5-10600T (8086:9BC8) to fully working with plex -> one user negative feedback for a i5-10500 (8086:9BC8) to get /dev/dri devices but no transcoding with emby -> one user negative feedback for a i9-10900 (8086:9BC5) system does not boot anymore - seems to be a solid hands off? edit: there is a driver source patch for 10th gen that came up along 7.x and 9BC5 was confirmed to work with this new driver, so anyone with a 10th gen gpu and trouble can change to 7.x (tc rp loader) ot can try these 6.2.3 modules from this link (i915_918_623.7z) https://xpenology.com/forum/topic/59909-i915ko-backported-driver-for-intel-10th-gen-ds918-ver-701-up3/?do=findComment&comment=277236 i completely removed jun's i915 drivers from the extra/extra2 and changed/added the i915 firmware needed, also i took care of the "old" i915 drivers on the installed system in /usr/lib/modules/update/, they are now deleted on boot so if you come from 6.2.2 and used extra/extra2 std or recovery or you did already used juns original 1.04b extra/extra2, it should work as soon as you boot up (when drivers in "update" are not present then the default drivers from synology will be used and with the added i915 in place it will work on most intel gpu's up to coffee lake) the driver versions are the same as in the 6.2.2 extra/extra2 but are newly compiled, as every driver from 6.2.2 is renewed all the old drivers are overwritten and there should be no crashing drivers on boot (which can prevent proper shutdown or reboot) we now have one universal i915 driver (and not jun's and synologys) its back to one package for all cpu/gpu, if needed there will be a recovery version too i only did test a new created loader from 1.04b image file with zImage and rd.gz from "DSM_DS918+_25426.pat" and the new extra.extra2, it will also work with the 6.2.0 kernel that is by default in the 1.04b image if there are problems getting hardware transcoding to work it might help to disable vt-x/vt-d in bios (reported on a J5005 Gemini Lake), but there are other possible reasons because of the licensing thats needed for this to work, but at least it will not hurt as as lon as you dint intent to use the vmm package if you accidentally updated 6.2.2 to 6.2.3 and now have problems like no network after boot, no proper shutdown/reboot or missing /dev/dri (hardware transcoding) then you just copy the new extra/extra2 to your already updated usb drive (the update to 6.2.3 already installed the new kernel on it) with latest updates of win10 there is no drive letter anymore, its possible to still do it with the tools already used for creating the usb drive, read the usb to a imgae file with "Win32DiskImager 1.0" (activate "read only allocated partitions"), mount that image with osfmount (like in the tutorial section), overwrite old /extra/extra2.lzma and write the image back to usb with Win32DiskImager extra.lzma/extra2.lzma for loader 1.04b ds918+ DSM 6.2.3 v0.13.9 some intel and realtek driver updated so hopefully more onboard nic's will work (like realtek 8125), also realtek 8152 is newer so all 2.5G usb solutions from realtek schould work, there is still no way for the intel 2.5G nic as there is no standalone driver for older kernel versions, removed fireware, added bnxt_en and sr_mod/cdrom, nic Killer E2500, added *vf.ko in rc.modules https://pixeldrain.com/u/jHa2eYrc https://gofile.io/d/mUFYxQ 1CED32FCF63EB54DAA44335FA1EFBCE408D41A3E16D55771D35B0FD423F0B9CF extra.lzma/extra2.lzma for loader 1.04b ds918+ DSM 6.2.3 v0.13.3 scsi/sas disks will have no s.m.a.r.t. infos with lsi sas controllers (see edit2 above), newer atlantic.ko driver 2.3.4, r8125 added to rc.modules, used latest source for realtek drivers r8101/r8125/r8152/r8168/r8169, bna.ko firmware corrected https://pixeldrain.com/u/pkBY9XjC https://gofile.io/d/FvoFdo SHA256: EF6F26999C006A29B3B37A7D40C694943100F0A9F53EC22D50E749F729347EC6 for special purpose and tests, extra.lzma/extra2.lzma for loader 1.04b ds918+ DSM 6.2.3 v0.12.1 - this version shows s.m.a.r.t. info and serial of disks for lsi scsi/sas but might corrupt the raid when disk hibernation is active (see warning above) https://pixeldrain.com/u/kZJdPj1H https://gofile.io/d/nsglbX SHA256: 9089D38A4975AB212553DA7E35CE54027DE4F84D526A74A46A089FC7E88C1693 extra.lzma for loader 1.03b ds3615 DSM 6.2.3 v0.12.1_test, added virtio/9p, CDROM drivers, nic Killer E2500 lhttps://pixeldrain.com/u/Rx4tV6ay https://gofile.io/d/RnX1QA SHA256: E72820BF648CFD7F6075DEEB1208A3E0D8A61F38289AE17AC7E355910B9B0E0E extra.lzma for loader 1.03b ds3615 DSM 6.2.3 v0.11_test, same added drivers as for 6.2.2 like newer intel drivers, 10G nics, ... https://pixeldrain.com/u/5aN77nWf https://gofile.io/d/PMIDrX SHA256: 5DE93F95841CC01F9E87EE4EE2A330084B447E44EBAA6013A575A935D227D4AF extra.lzma for loader 1.03b ds3617 DSM 6.2.3 v0.12_test (2/2022), added virtio/9p, CDROM drivers, nic Killer E2500 https://pixeldrain.com/u/xmhCVxck https://gofile.io/d/VRtmC1 SHA256: B9AC8705D5D9DCEED1C0315346E4F2C7C4CD07C4ED519FC9901E8E368A3AE448 extra.lzma for loader 1.03b ds3617 DSM 6.2.3 v0.11.2_test, same added drivers as for 6.2.2 like newer intel drivers, 10G nics, ... (0.11.2 because i forgot bnx2/bnx2x firmware and mpt2/mp3 driver problem when updating from 6.2.2 in 0.11) https://pixeldrain.com/u/zwAJzKa9 https://gofile.io/d/0Tx8A7 SHA256: D467914E55582D238AC5EC4D31750F47AEB5347240F2EAE54F1866E58A8BD1C9
    37 points
  14. Hi all:) After a little bit of reverse engineering I was able to bypass the license checking mechanism introduced in DSM 6 successfully with a simple two line binary patch of synocodectool and therefore enable transcoding without a valid serial number[emoji4]. I wrote a little script to make it easier for everyone. For more information please check the github repo: https://github.com/likeadoc/synocodectool-patch HOWTO: 1. wget https://raw.githubusercontent.com/likeadoc/synocodectool-patch/master/patch.sh 2. chmod +x patch.sh 3. ./patch.sh Done:) If things go wrong simply restore the original file: ./patch.sh -r Cheers
    33 points
  15. As i have annouce on a previous message, it has been decided to split development and stable TCRP releases. In an effort to properly document the deplot. => So stable release will remain at 0.8 version and can be accessed through the main repo : https://github.com/pocopico/tinycore-redpill/tree/stable No new features will come through the stable release. Only fixes will be applied as they come along. => Development release 0.9 will bring new features, refinement of old processes etc. So far the development release includes the following : Current : - New images containing latest development rploader.sh version 0.9.0.2 - New background wallpaper when landing into TCRP desktop - New system status landing page when you start desktop. You can now easily find your IP addess on screen. - rploader.sh development release 0.9.0.2 - Several missing packages from Tinycore (ntpclient/file/php-8-cli/scsi modules etc) Roadmap : - User manual module compilation process. - User manual extension creation - Custom.gz re-engineering Tinycore image will remain at version 12 as the binutils on 13.1 have gone passed the required maximum for module compilation. You can head to the development repo to download new images if you would like to test : https://github.com/pocopico/tinycore-redpill/tree/main Please report any development additions and improvements you would to include on this thread. Do not post install issues here.
    30 points
  16. I think I need to explain: Yes, I was a little extreme at the time, because I roughly guessed who that person was. (A brand new account, so to speak, the account created specifically for the purpose of creating that issue) This is what makes me angry. So when he mentioned the open source agreement, I didn't think much about it. Since I can't publish it because the second release under the protocol requires public modification, I delete the repository and don't publish it. If someone else asks, I may not do this, and may even invite him to revise it together. In addition, as we all know, a month ago they were public. I changed it to non-public because 1. I unpacked the official drivers of all architectures and backed them up on github. Although this is nothing, I still don’t want to be retrieved. 2. I saw some very unhappy things( and don’t want to say more, related to the person who created the issue) In addition, and what I said on github, so I won’t go into details here. If anyone thinks I did something, just don't use it. From beginning to end, few people have seen me recommending others to use RR, because it doesn’t do me any good whether you use it or not. On the contrary, the more people use it, the more uneasy I feel. I am always afraid of being targeted by syno officials. But I just have a bit of perfectionism and always want to do better.
    29 points
  17. Перед тем как что-то менять в своей работающей системе, настоятельно рекомендуется сделать резервные копии своих особо ценных данных, чтобы потом не жалеть об их безвозвратной потере. Все, что вы творите - это ваш страх и риск, никто не побуждает вас это делать. Самый простой и надежный способ безопасно попробовать - выключить хрень, отключить все диски и загрузочную флешку от действующей системы, взять чистый диск и другую флешку и попробовать установить новую версию загрузчика и системы, если прокатило, то делать уже на действующей системе. 1. Как установить (подготовительные работы описаны для компа с Windows): а) скачать образ загрузчика 1.04b (исходная тема тут), создать каталог в корне диска без символов на кириллице, например, c:/918/ и поместить туда образ загрузчика б) определить VID/PID флешки или картридера в который она вставлена (Панель управления - Диспетчер устройств - Контроллеры USB - Ваша флешка/ридер - Свойства - Сведения - ИД оборудования, нужно для того, чтобы система DSM опознала этот диск и не пыталась устанавливать себя на него, если неправильно определите и пропишите эти параметры, то система будет вылетать по ошибке 13 при установке в) скачать, установить и запустить программу OSFmount, смонтировать Partition 0 (15 Mb) из файла загрузчика, перед монтированием убрать галку Read-only drive г) скачать, установить и запустить программу Akelpad, открыть файл grub/grub.cfg на ранее смонтированном диске, правим, сохраняем: set vid=0xA234 #VID флешки/ридера set pid=0xB678 #PID флешки/ридера set sn=1780PDN123456 #sn set mac1=001132123456 #mac первой сетевой карты set mac1=001132123457 #mac второй сетевой карты, второй и последующий отличаются от первого на +1 в последнем разряде в шестнадцатеричной системе ... set netif_num=2 #количество сетевых карт ... set sata_args='SataPortMap=6' #контроллер sata, значения: 6 - 1 контроллер на 6 портов; 22 - 2 контроллера по 2 порта; 42 - 2 контроллера, первый на 4 порта, второй на 2 и т.п. Где брать sn и mac - ваша головная боль, гугл в помощь, система установится и будет работать с теми, которые изначально прописаны в загрузчике, но с ограничением функционирования некоторых сервисов и модулей, таких как: QC, пуш уведомления, активация кодеков для транскодинга, установка лицензий syno... Но для большинства и без них будет достаточно. На форуме писали, что прокатывало с sn и mac от других реальных моделей syno, но так не пробовал, поэтому утверждать не буду, кто хочет - дерзайте. д) размонтировать диск в OSFmount е) скачать, установить и запустить программу Rufus и записать ранее подготовленный образ на флешку з) вставить флешку в машину, на которой планируете запустить хрень, подключить диски, включить питание ж) отключить брандмауэр в антивирусе, в браузере набрать http://find.synology.com или установить Synology Assistant с сайта syno и найти вновь установленную хрень в вашей сети и) установить DSM установить хрень следуя инструкциям программы установки и приступить к настройке (как это делать здесь не описываю, ибо все ответы есть в базе знаний syno) Для ленивых есть утилита, где собраны основные проги для Windows x64 2. Если хрень не обнаружилась в сети, то скорее всего в загрузчике нет драйверов для ваших сетевых карт и/или для sata контроллеров. a) запустить программу OSFmount, смонтировать Partition 1 (30 Mb) из файла загрузчика, перед монтированием убрать галку Read-only drive б) скачать extra.lzma из этой темы и перезаписать в смонтированном диске в) размонтировать диск и перезаписать образ с добавленными драйверами на флешку г) попробовать запустить и найти хрень в сети, если не получилось, то увы и ах, либо просить, чтобы добавили дрова для ваших устройств в этой теме или самому их добавлять - теория тут 3. Транскодинг (нужны sn и mac от реальной железки) С наибольшей степени вероятности запустиnся на процессорах Intel начиная с 4го поколения (Haswell), но есть нюансы с моделями материнских плат и биосами. Проверяем следующим образом: hardware (hw) транскодинг - в корне системы должен быть каталог /dev/dri с тремя подкаталогами внутри, если его нет, но нет и hw транскодинга, чтобы проверить - ищем каталог в терминале/ssh командой cd /dev/dri. software (sw) транскодинг - должны подняться соответствующие кодеки, проверить можно командой в терминале/ssh cat /usr/syno/etc/codec/activation.conf Если результат такой, то он есть: {"success":true,"activated_codec":["hevc_dec","h264_dec","h264_enc","mpeg4part2_dec","ac3_dec","vc1_dec","vc1_enc","aac_dec","aac_enc","mpeg4part2_enc"],"token":"абракадабра"} Если ничего похожего нет, то нет и транскодинга. P.S. Просьба к админам прибить тему в шапке и дать мне доступ на редактирование первого поста этой темы, буду добавлять по мере поступления вопросов, ибо задолбали оленеводы, которые задают вопросы по установке, во всех подряд темах.
    27 points
  18. This is an updated tutorial version from the one I made last year. It will enable you to migrate from DSM 5.2 to DSM 6.1.7 directly without the need to upgrade to DSM 6.0.2 first. If for some reason you want to upgrade to DSM 6.0.2 first or simply you do not want to upgrade to DSM 6.1.7 but only to DSM 6.0.2 then use the link above. To upgrade from DSM 6.0.2 to DSM 6.1.7 read here. As most of you know by now Jun was able to find a way to install DSM 6 on non Synology boxes. Here is the thread that I recommend reading. At least make an effort and read the OP: https://xpenology.com/forum/topic/6253-dsm-6xx-loader/ Below is what you need for the operation. I will assume you are doing all this under Windows 10, 8, 7 or XP. If you are on a MAC computer have a look at this post I made on how to burn the image to a USB drive and then mounting the USB drive for editing the content. The rest of the tutorial still applies. If you are currently using DSM 5.1 or below first update to DSM 5.2. If you are doing a fresh install of DSM 6.1 then carry on with the tutorial and omit references to DSM 5.2. - Win32 Disk Imager to make a bootable USB drive; - A 4GB (or any size really) USB drive (flash drive) to install the loader. Not that this is necessary but use preferably a brand name (Kingston, SanDisk...); - A way to read your USB drive VID/PID. Here is a how-to >>> VID and PID; - A good text editor: Notepad++ I really don't recommend using Windows's Notepad; - DSM 6.1.7 PAT file. Chose the one you need: DS3615sx or DS3617sx or DS916+. Download the ".pat" file not the ".pat.md5" - Jun's official v1.02b loader (mirror). This is a hybrid UEFI/BIOS loader so it should work in most machines which are capable or reading GUID partition table (GPT). For older machines that can only read MBR the above loader will simply not boot. If that is your case then use @Genesys's v1.02b loader rebuilt image which is MBR based. Note: Jun's loader supports Intel CPUs. For AMD CPUs Jun has stated that the loader needs some work but it has been reported by many users using HP machines that it actually works. The C1E function in the bios (in some HP machines) needs to be deactivated. I am unsure for other motherboards brands therefore if you have an AMD machine that is not an HP you might be out of luck. Try looking in the bios configuration and play around. - Custom extra.lzma ramdisk. This ramdisk is optional and should only be used if the default ramdisk included in the loader is not detecting your hardware. I am just providing it for those who are having issues with network detection or unrecognised HDD controllers. This custom ramdisk contains additional and updated modules & firmwares. Credits go to @IG-88 for compiling the modules against the latest DSM 6.1.3 source code. I do not warranty they all work but I think most do. If you chose to use this ramdisk, you will need to replace (or rename, so you can revert) the default extra.lzma ramdisk from Jun's loader with this one. If you a have question specific to the custom ramdisk please post it in the topic of IG-88, not here. - If you are doing a fresh install make sure your drives are plugged in direct succession starting from the 1st SATA port. Usually the first port is described as SATA0 on motherboards. Check with your MoBo manufacturer for exact nomenclature. - OSFMount to modify the grub.cfg file within the loader's image and if necessary to replace the extra.lzma ramdisk with the custom one. This is not strictly necessary as Jun has made it possible to configure what needs to be modified via the Grub Boot Menu. If you prefer using Jun's Grub Boot Menu configuration method, simply skip Point 4, read Note 4 instead and pick up at Point 5. PLEASE READ EVERYTHING PRIOR ATTEMPTING ANYTHING Use this loader at your own risk. I wont be held responsible for any loss of data or black smokes that may result in the use of this loader. Please note that this loader has a limited amount of modules (drivers) included. If it is fundamental for you to have a NAS operating as quick as possible I recommend you look at the included drivers very carefully at the bottom of this tutorial before attempting an upgrade. If they are not there you will have to compile your own modules/firmwares or use the custom ramdisk provided above. Don't ask me to compile modules for you. I wont do it. One last thing: DO NOT UPDATE DSM BEYOND VERSION 6.1.7 with loader v1.02b. IN OTHER WORDS DO NOT UPDATE TO DSM 6.2 You have been warned. Here we go: 1 - BACKUP your data and save your configuration prior any attempts to migrate from DMS 5.2 to DSM 6.1. I can't stress this enough. JUST DO IT, as Nike likes to say. Also, print this tutorial if you can. It will make your life easier. 2 - Turn off your NAS and unplug the USB drive you are currently using with DSM 5.2. I recommend you put this USB drive aside in case migration to DSM 6.1 doesn’t go as expected and you need to revert to DSM 5.2. It will just make your life easier. 3 - Now go to your workstation/PC, plug a new USB drive (or the old one if you really don’t have any spare USB drives). Use the link I provided earlier to check your USB drive VID/PID. Write down the info somewhere as we will need it later. 4 - Now launch OSFMount. Select Mount New, then select the image file you downloaded earlier (i.e. .img extension file) to open. Now select partition 0 (the one that is 15 MB). Click Ok. Then at the bottom of the window make sure to un-tick the "Read only drive". Click Ok. The partition should now be mounted in file explorer. At this point you can navigate to the /grub directory and edit the grub.cfg file. If you need to replace the extra.lzma ramdisk with the custom ramdisk provided above then you will also need to mount partition 1 (the one that is 30 MB). Below is what you will see in the grub.cfg file. I am only showing below the portion of the code that is relevant for the purpose of this tutorial [...] set extra_initrd="extra.lzma" set info="info.txt" set vid=0x058f set pid=0x6387 set sn=C7LWN09761 set mac1=0011322CA785 set rootdev=/dev/md0 set netif_num=1 set extra_args_3615='' set common_args_3615='syno_hdd_powerup_seq=0 HddHotplug=0 syno_hw_version=DS3615xs vender_format_version=2 console=ttyS0,115200n8 withefi elevator=elevator quiet' set sata_args='sata_uid=1 sata_pcislot=5 synoboot_satadom=1 DiskIdxMap=0C SataPortMap=1 SasIdxMap=0' set default='0' set timeout='1' set fallback='1' [...] You want to modify the following: Change vid=0x090C to vid=0x[your usb drive vid] Change pid=0x1000 to pid=0x[your usb drive pid] Change sn=C7LWN09761 to sn=generate your sn here with DS3615xs or DS 3617xs or DS916+ model (this will depend on which loader you chose) Change mac1=0011322CA785 to mac1=[your NIC MAC address #1]. You can also add set mac2=[your NIC MAC address #2] and so on until mac4 if you have multiple NICs. However, this is not necessary. Recommended: Change set timeout='1' to set timeout='4' - This will allow you more time to make a selection in the Grub Boot Menu when it appears on screen. Once you are done editing the grub.cfg file, save it and close your text editor. Now in OSFMount click on Dismount all & Exit. You are now ready to burn the image to your USB drive. 5 - Now use Win32 Disk Imager to burn the image file onto the USB drive. This will also make the USB drive bootable. 6 - Eject and unplug the USB drive from your workstation. Plug it in your NAS (avoid USB 3.0 ports. Use USB 2.0 port if available). Boot your NAS and before doing anything fancy, access your BIOS so to make your USB drive the 1st boot drive if it's not the case. The Jun official loader can boot in UEFI or in legacy BIOS, so you chose what suits you best. Also, make sure your HDDs are booting in AHCI mode and not in IDE. Finally, if disabled, also enable the serial port in BIOS. Some BIOS don't have this option so don't get too cranky on this if you can't find it. Save changes to the BIOS and REBOOT the NAS. 7 - Once rebooted, if you have a monitor connected to your NAS you will see the following Grub Boot Menu: ADVICE: even before you see the Grub Boot Menu press the up/down key. This will stop the countdown so you will be able to select the desired line. You won’t see much other than the following after you press enter: If you booted the USB drive in EFI mode then you will see the same text without the last 3 lines but that's ok. 8 - Now go back to your workstation, and launch Synology Assitant or go to http://find.synology.com. Within one minute or so you should normally be able to see your NAS on your local network (it took ~55 seconds on a test I did on a VM). Just follow the instructions and either chose "Install" if you wish to have a clean install or chose “Migration” if you are coming from DMS 5.2 and wish to update while retaining your data. You will be asked to provide the .PAT file you downloaded earlier (DSM_DS3615xs_15217.pat or DSM_DS3617xs_15217.pat or DSM_DS916+_15217.pat). 9 - When the migration is finished you will most probably have to update some of your packages. You can then proceed and update DSM 6.1.7 up to DSM 6.1.7 critical update 3. It is possible you might either need to hard reboot or re-image your usb drive. Make sure to deactivate auto-updates within DSM. Link to individual files (DSM and critical updates) can be found here: https://xpenology.com/forum/topic/7294-links-to-dsm-and-critical-updates/. DO NOT UPDATE TO DSM 6.2. The loader is not compatible. 10 - You are done. If you have questions, first search the forum and/or Google then leave a comment if nothing helps. Please provide your hardware specifications (motherboard model, LAN controller, driver controller etc). Failure to prove such information will lead to the post being deleted or not answered. -------------- Note 1: If after following the tutorial you can’t find your NAS through http://find.synology.com ou Synology Assistant it is highly possible that the drivers of your NIC are not included in the ramdisk of the loader. Make an effort and use Google to know what modules your NIC and HDD controller are using, then check if those modules are included in the custom extra.lzma ramdisk. If yes then use the custom ramdisk. Don't ask me to look for you. If nothing works then ask your question. Note 2: Synology increased security since the introduction of DSM 6. Root access through SSH is no longer possible out of the box. You can however use your admin account and elevate permissions with the following command if you need root permissions: sudo -i Note 3: Please check you have the right VID/PID prior proceeding. If you get the following error ”Failed to install the file. The file is probably corrupted. (13)" it most certainly means your VID and/or PID is/are wrong. If you still have the same error message after verifying the VID/PID then try another USB drive. Note 4: Configuration added to the grub.cfg file can also be done directly during the Grub Boot Menu, so technically you can skip Point 4 and burn the image on the USB drive without editing anything (read Point 5 onward first). If you wish to do the changes from the Grub Boot Menu directly you need to press the letter 'C' when you see the Boot Menu. You will literally only have one second, so be fast. Once you press 'C' you will be in a Grub command line environment. To change your VID enter the following: vid 0xYOUR 4 DIGITS USB DRIVE VID Do the same for pid, sn and mac1. Press enter at each command. The commands are: pid 0xYOUR 4 DIGITS USB DRIVE PID sn YOUR NAS SERIAL NUMBER mac1 YOUR NAS MAC1 ADDRESS If you have multiple NICs you can also issue mac2, mac3 and mac4 as commands. Maximum is mac4. See below: mac2 YOUR NAS MAC2 ADDRESS mac3 YOUR NAS MAC3 ADDRESS mac4 YOUR NAS MAC4 ADDRESS If you think you made a mistake in the numbers simply re-issue the command. When you are done press esc and select the appropriate menu entry. Below is an example (fake numbers) of how it looks under the Grub command line environment : Note 5: If you encounter the error "We've detected errors on your hard drives [drive number] and the SATA ports have also been disabled" during installation, then you have to fallback to adding SataPortMap to the grub environment. Press the letter 'C' at the Grub Boot Menu and then add the following: append SataPortMap=XX where XX is the number of drives. Don’t forget to update this parameter if you add additional drives to your machine. If you use Reinstall, don't forget to re-select the first line of the Boot Menu once the NAS has rebooted after the installation else the Loader will re-select Reinstall and you will be faced with some issues so please beware of this. @@@@@@@@ What does SataPortMap mean? @@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ############## Know issues ##################### - When running on a slow single core machine, there is a race condition that causes the patcher to load too late. The most obvious sign is that console is not working properly. - Some ethernet drivers crash when set MTU above about 4096 (Jumbo frame). ############# Included default modules & firmwares in Jun's Loader ############# ############## Tutorial UPDATES ##################
    26 points
  19. There is a better way^^ Just activate it: In your browser open the following urls one after another: Replace the following: URL, PORT, USER, PASS, SERIALNUMBER (dont replace any other symbols like : oder ") https://URL:PORT/webapi/auth.cgi?api=SYNO.API.Auth&method=Login&version=1&account=USER&passwd=PASS https://URL:PORT/webapi/entry.cgi?api=SYNO.ActiveBackup.Activation&method=set&version=1&activated=true&serial_number="SERIALNUMBER" To get the current activation status call the 1. query above and then https://URL:PORT/webapi/entry.cgi?api=SYNO.ActiveBackup.Activation&method=get&version=1 ------------------------------ Example for url: server, port: 5001, user: admin, pass: admin, serialnumber: 123400 https://server:5001/webapi/auth.cgi?api=SYNO.API.Auth&method=Login&version=1&account=admin&passwd=admin https://server:5001/webapi/entry.cgi?api=SYNO.ActiveBackup.Activation&method=set&version=1&activated=true&serial_number="123400"
    25 points
  20. 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.
    24 points
  21. SS 8.1.2-5469.х86_х64 протестирован и работоспособен. Желающие могут постучать(только не громко) в личку. На заметку - Качаем архив и распаковываем. - Устанавливаем SS 8.1.2-5469!!!(взять можно Тут, но не запускаем(если запустили, останавливаем). - Заходим на свой NAS через web. - Заходим в Панель управления > терминал и SNMP. Ставим галку "включить службу ssh" и нажимаем применить. - Подключаемся к сино с помощью putty или другого ssh клиента под Админом - Вводим свой Админский пароль - Вводим команду: sudo su - - Вводим свой Админский пароль - Видим чудо в виде - root@... - Вводим команду: synouser --setpw root Ваш_Пароль_Для_Root - Далее можно заходить под root используя установленный пароль. - Скидываем файлики из архива на сино и при необходимости меняем владельца и права. Сделать это можно разными способами. p.s.При использовании WinSCP советую в настройках передачи установить тип файлов "двоичный/binary" для исключения возможных проблем. - Запускаем SS из центра пакетов.(если всё сделано правильно, имеем 25 камер) - Класть(или если хотите - ложить) сюда>>> /var/packages/SurveillanceStation/~target/lib/libssshm.so *chmod=644* *owner=SS* *group=SS* /var/packages/SurveillanceStation/~target/lib/libssutils.so *chmod=644* *owner=SS* *group=SS* /var/packages/SurveillanceStation/~target/sbin/ssmessaged *chmod=755* *owner=SS* *group=SS* /var/packages/SurveillanceStation/~target/webapi/Layout/src/SYNO.SurveillanceStation.Layout.so *chmod=644* *owner=SS* *group=SS* Hide
    24 points
  22. List of mirror links to DSM 5.x and DSM 6.x boot loaders. Please drop a comment if you see a broken link or some erroneous information. All other posts will be deleted. Before downloading a loader I suggest you read this topic (for DSM 6.x) or this topic (for DSM 7.x) to know which loader to download. DSM 7.x - Read Flyride topic Tinycore-redpill (TCRP) Releases | Download is straight from Github. Link to code: https://github.com/pocopico/tinycore-redpill OR (the choice is yours) Automated RedPill Loader (ARPL) Releases | Download is straight from Github. Link to code: https://github.com/fbelavenuto/arpl --------
    23 points
  23. 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.
    23 points
  24. Ждать и терпеть больше не смог и пользуясь праздничным выходным таки перешел на семерку. 😂 Для тех кто хочет повторить, настоятельно рекомендую отключить рабочие диски, взять чистые диск и флешку для загрузчика и попробовать перед переводом рабочей хрени. Я ни к чему не призываю, сами решаете делать вам это или нет. Первоисточник тут. Порядок действий (можно делать и по другому, но мне так привычнее): 1. Качаем образ для создания загрузчика по ссылкам в первоисточнике tinycore-redpill.XXXXXXXXX.img.gz 2. Разархивируем и записываем образ на флешку, я предпочитаю Rufus. Размер образа для создания загрузчика чуть больше гигабайта, я использовал флешку на 2 Гб. 3. Вставляем флешку в хрень, устанавливаем в биосе загрузку с нее, загружаемся. 4. Если есть монитор, клавиатура и мышь, то заходим в терминал из GUI, если нет, то ищем устройство в подключениях роутера или другими удобными вам способами, заходим по ssh и вводим: login: tc pass: P@ssw0rd Далее действия производятся в терминале/ssh, при необходимости не забываем подтверждать их. 5. Обновляем загрузчик до последней версии. ./rploader.sh update now ./rploader.sh fullupgrade now п.п.6-8 можно пропустить и самостоятельно поправить все в конфиге п.9. 6. Считываем и подставляем в конфиг VID и PID флешки. ./rploader.sh identifyusb now 7. Считываем и подставляем в конфиг структуру сата контроллеров. ./rploader.sh satamap now 8. Генерируем и подставляем в конфиг случайные sn и mac (если есть предпочтения по ним, то переходим к п.9). ./rploader.sh serialgen DS918+ now 9. Проверяем, что записалось в конфиг, при необходимости правим. vi /home/tc/user_config.json Переход в режим правки Insert, выход из режима правки Esc. Выход из vi без записи. :q! Выход из vi с записью изменений. :wq 10. Запускаем генерацию загрузчика. ./rploader.sh build apollolake-7.0.1-42218 ИЛИ ./rploader.sh build apollolake-7.1.0-42661 Внимательно! смотрим, что пишется в терминале, если скрипты на гите обновятся, то делаем то, что написано в терминале! 11. По желанию бэкапим созданную конфигурацию. ./rploader.sh backup 12. Перезагружаем хрень. exitcheck.sh reboot 13. Для установки/миграции скачиваем на комп pat нужной версии для соответствующей модели DSM отсюда. 14. Отключаем на время установки хрени доступ в интернет!!! Иначе, весьма вероятно, получите ошибку 13 при установке pat. 15. Далее все как и ранее...находим, ВРУЧНУЮ!!! устанавливаем скачанный pat файл для инсталляции/миграции и наслаждаемся семеркой. Если нужны другие версии, то: - в п. 8 вместо DS918+ подставляем DS3615xs или DS3617xs - в п.10 вместо apollolake подставляем bromolow или broadwell соответственно. Вроде все работает, по ощущениям загрузка и выключение происходят в разы быстрее. P.S. Я решил начать все с чистого листа, поэтому при переходе выбрал только сохранение данных, без миграции настроек и приложений. P.P.S. У кого виртуалки, образ VMDK тут. Порядок действий, думаю сами знаете. 😉 Следим за изменениями в первоисточнике, ссылки для скачивания образов могут поменяться. UPD 05.04.2022 В первоисточнике в скрипты добавлена возможность компиляции загрузчика под 7.1.0-42661 Кто хочет перейти на 7.1 нужно будет перекомпилировать загрузчик и подсунуть pat 7.1. UPD 27.06.2022 Для обновления до 7.1. Update2 выполняем по этой ссылке. UPD 29.06.2022 Если кто-то хочет побаловаться с DVA1622, который еще даже не продается, то качаем загрузчик из dev ветки, а далее все как обычно с новыми кодами, которые я добавил в список выше. Ограничения - не более 2х дисков, нет кодеков для HEVC, и видимо необходимо наличие Intel UHD Graphics 600. Из плюсов: AI раборает на GPU, т.е. видеокарта не нужна, 8 лицензий на камеры и SS выводится на подключенный к хрени монитор (пробовал HDMI и VGA).
    21 points
  25. Update time! Support for v4.4 kernel TL;DR: it now works with v4.4 After some of you took a stab at compiling the LKM for Linux v4.4 (presumably for DS918+ support) we did too. We didn't see any PRs besides a small patch from @jumkey (thanks!). However, the reality came to be much MUCH more complex, especially if we want to keep the consistent codebase for all kernels. So, it took 400 lines over 12 commits by 3 people: https://github.com/RedPill-TTG/redpill-lkm/compare/7f85cb2ceff44d6914135bf3841eb3cb2148af11...1abcbe13df39055dc8b925f74a00a75163157d60 However, the story is more complex here. The kernel development velocity is huge, to add to that DSM's kernel has its own peculiarities (more on that below ;)) too. The following things took us the time: Adjusting to build with a new source tree (very easy) Running the actual kernel in an isolated VM (quite challenging). This posed a problem because the first round of patches for v4.4 one of us made weren't stable. Currently, the ramdisk patch works (oh irony, the one generated by the automatic tool we hacked together) but the "boot_params" causes random KPs. Additionally, some of our HVs don't have CPUs with hardware MOVBE support, or they crash/freeze the machine after snapshot restore. This made debugging challenging as you don't know if it's your CPU, hypervisor, configuration, kernel patch, LKM, or a combination of multiple ones causing the problem. Another challenge here is a bug in Synology's v4.4 for apollolake (possibly others too). In essence, they modified ramdisk unpacking routine and broke it in the process. The effect of it is no matter what tools we used the ramdisk wouldn't unpack making the system unbootable. We have no idea how they pack their ramdisks but we failed to recreate that. This took us finally to a flat CPIO archive (more in docs: https://github.com/RedPill-TTG/dsm-research/blob/master/quirks/ramdisk-checksum.md#recreating-ramdisks) Getting cmd sanitization working on v4 (easy): they've changed the format of /proc linklists, so we had to adjust. However, we saw that @jumkey posted a possibly better (muuuch shorter) solution to the problem. We didn't try it yet, but by all means, please make a PR! It should actually work for both v3 & v4 lines. Chasing an annoying bug with preempts: it seems like v3 silently fixes these but v4 traps them and crashes. Refactoring how the re-export of functions work to make it much easier for others to contribute to (and make our life more pleasant). This was part of the fix for set_memory_rw/ro not being officially available anymore. Now you can just use 2 macros and call it a day in 30 seconds. Making vPCI stuff working on v4 (difficulty: 11/10) : this was probably the hardest thing to debug and the easiest things to fix (it took a bloody SINGLE line!). There are many levels of hell in PCI. In around v4.1 they've added a couple more. Now all PCI stuff assumes ACPI compliance and static DSDTs on x86. In the same time they broke dynamic bus scanning for new busses which aren't PC-BIOS based. We're assuming it was accidental as what they did was a refactor only. Here comes the syno kernel too: in v3 they have dynamic debugging enabled (but not the full kdebug). This gives at least a possibility of seeing some more messages On v4 the debugging cycle is: stub a method with some debug prints, override the method in kernel using override_symbol.c, compile the module, reboot/restore the test VM, download the module to a test VM, load the module and see what you wanted. Repeat 500x times Fixing execve() shimming wasn't as hard as vPCI stuff but quite challenging as well. Since v3.18 the call structures of ASM shims changed. In essence they use different function call convention than GCC generates (there's a good article about that:L https://my.oschina.net/macwe/blog/603583). This cannot be achieved (correct us if we're wrong) using C but requires custom ASM. Once we realized what's the problem we decided to make route the call differently by skipping the shim altogether. This is less clean and may be a tad bit slower (nothing noticeable thou). What is an elevator? For long time we were wondering why Jun's loader sets "elevator=elevator" parameter to the kernel. Normally it sets the I/O scheduling, but obviously "elevator" is not a valid value. We think we accidentally found what this is for. Linux automatically loads a custom elevator module with the name specified (with some pattern, we didn't dig into that deeply yet) before ANY other modules are loaded. And viola, that's how the LKM can load as early as possible It will be included in RedPill as well as this is a cool trick and ensures the module loads earlier than with init script. Anybody want the Synobios source code? It's public. It has been for years in fact. The struct posted by Vortex lead us to explore older dumps. While lurking through them we found that Syno (accidentally?) used to publish full Synobios source code. They fixed their mistake but didn't remove these old files. You can find it as a normal kernel driver in all GPL archives till 5004 (e.g. synogpl-3776-bromolow/source/linux-2.6.32/drivers/synobios). After talking with @Vortex we learned that the full headers (but not the code this time) for synobios are present in DSMv7 dev env (more details: https://github.com/RedPill-TTG/dsm-research/blob/master/quirks/mfgbios.md#appendix-official-synobios_ops-structure) Synobios ioctl emulation We found out what the previous author meant in the PMU document. It seems like there are two part of the synobios: shimming the synobios_ops (done) responding to proxy communication It turns out that synobios not only performs its own calls but other system components (e.g. secmd) can use ioctl to ask it to send some arbitrary commands to the PMU. These commands are actually what causes these logged messages which @Vortex explained as beeps etc. We need to respond to them in software (i.e. in LKM). Making the GPL sources more accessible Let us preface this by saying this isn't anything we're prioritizing. However, we're putting this onto the radar. While browsing through the code we realized two things: it's annoying hard to find what you're looking for and/or compare, as they publish a sea of large archives they remove things Because of these we made, currently by hand, a rundown of architectures and formats over the versions. We are also planning to replicate the whole SF archive in a form of GH repos. Full details: https://github.com/RedPill-TTG/dsm-research/blob/master/quirks/gpl.md DSM v7 sources Synology did already publish v7 sources and.... they pulled them quickly: https://sourceforge.net/p/dsgpl/discussion/862835/thread/a519b80124/. They used to be in the "41890branch" as you can see from the project's history: https://sourceforge.net/p/dsgpl/activity/?page=0&limit=100 We weren't lucky enough to get them. Did anyone maybe was able to grab them? ----------------------------------------- Quite doable. Code-wise we need a similar interface for ioctl emulation (see above). Hardware-wise... well, *I* personally don't see the point as I virtualize what I can (and some of my colleagues disagree with me) but it's an easy addition. Currently, we're trying to get the software side of all the things to a non-developer-usable state. However once we do the ioctl interface patches for adding support for submitting events to some external source are welcomed. Then we can start another topic discussing making a small module for that. The cheapest AVR/arduino/PIC will do here. I know you meant to control the LEDs but in case you're not aware: the actual power off via ACPI just lacks a kernel module and doesn't need any custom stuff. Correct us if we're wrong but the architecture here is such that the kernel uses ASCII-based interface over UART to a bridge. Then the bridge/PMU has I2C for controlling other chips for like LEDs, fans etc. So strictly speaking we don't need I2C for anything. As I see the forum doesn't have any Telegram channel nor IRC. We believe the latter is actually better in many ways (we're old I think ;)) but Telegram is more modern. We will join for sure. The DSM consists of a heavily modified kernel, modified userland applications, and a completely custom web UI to manage all that. Since they have to should abide by the GPL they agreed to when modifying the kernel & libs they do should publish the full source with modifications for GPL-licensed part. In practice this means we get kernel, some libs, and some userland apps code. The whole DSM web management is their own custom stuff. So, here's actually the issue. The source code for the kernel is readable-ish but it cannot be compiled. It used to be but it's not anymore. The biggest problem is they replaced a lot of constants with "MY_ABC_HERE". In our view this is a violation of the GPL but good luck pressuring them to do anything about that. It's probably possible to compile the kernel if someone goes through and manually decides which "MY_ABC_HERE" to turn on and off but even we aren't crazy enough to do so. What the kernel sources are good for, besides reading, is compiling modules against them. You cannot use vanilla v4.4 or v3.10 sources for this. DSM kernels are heavily modified (so e.g. structs have new fields added to them, sometimes in the middle). Additionally, their v3.10 is not a v3.10 mainline + their patches but v3.10+DSM patches+a ton of backported changes from newer kernels. Supporting many devices is difficult because of the standard matrix of permutations problem, as in any software project, AND on top of this because Synology releases the same but different "v3.10" for different platform. For example apollolake v4.4 has broken ramdisk support We don't compile the kernel. We use DSMs kernel + binary patches from the dsm-research repo patches. You can load the patched image using kexec or repack it to boot from grub. You CANNOT use Jun's loader for this. Currently, we only published sources for the LKM. This is not because we have some secret one but because the kernel modification process is MUCH easier to do. To give you a glimpse of how we do the development we will just say that it's a manual process. We deliberately did not write a step-by-step instruction because we don't want regular folks making YT videos how to hack this around. It is NOT production safe yet. If you want to play with it as a developer simply compile GRUB (or even just copy one from any Linux distro from /boot). Then get the kernel + rd.gz from 25556 PAT file. Next apply binary patches from dsm-research repo and put redpill ko in the rd.gz. Next modify the init script to include redpill loading at the very top. We are looking here and discussing what you guys bring but we publish updates in batches as we don't want to rush with conclusions or publish FUD. It takes some times as we have full time jobs, families, kids, and socialize sometimes too (despite the rumors developers do sometimes leave their caves ;)). PCI addresses are very easy with RedPill. We can most likely prepare a patch in 5 minutes if someone posts "lspci -tvv" from a real DS/RS (ok, not just right now because we're currently trying to come up with a since runtime-level model-dependent configuration switching. The other things like testing and potentially different hardware requirements are the issue. Once we get a stable-stable version we can play with other ones. Another issue are S/Ns. They need to validate. We saw the validation somewhere in the kernel but the community developed serial generator only supports a handful of models. If someone wants to take a peek / knows how the previous serial generator was developed we're open. However, we think @flyride nailed it. The number of disks is not limited and other features are already present in DS3615/7xs & DS918+. DS1621+ may be worth looking into due to the AMD support.
    20 points
  26. Let us first pull you from the dark - we just added a new repo to the collection. "We think you're gonna love it"[tm] RedPill Load Without further ado: RedPill Loader Builder Repo is live - https://github.com/RedPill-TTG/redpill-load It's a loader image generator which we worked on for quite some time. From the start we have to apologize for using BASH - it was a mistake and if you look into the code you will understand why What it can do for you? However, it works. In short, it automates the following process in "normal" mode: Checks if the OS contains all tools needed to create the image Downloads the correct PAT file (if needed) Verifies checksum of the PAT (in case they pull a switchero on us one day) Unpacks the PAT Verified checksum of a known kernel & ramdisk files Patches the kernel zImage using included patches [direct mode only, see below] Unpacks ramdisk Applies common patches (disable root pw, add RP LKM loading etc) Generates synoinfo replacements based on the platform requirements AND user configuration Patches synoinfo in etc & etc.defaults in the ramdisk image Adds dynamic patching routines to post-init script (so that synoinfo is patched in the booted OS too) Copies missing VirtIO modules (original DSM script supports them but they're not included in non-VDSM builds) Reassembles ramdisk, taking care of broken v4 unpacking routines Generates appropriate GRUB configuration with kernel params appropriate for the platform + overrides specified in the user config Using a template of the loader image (contains compiled GRUB, you can provide your own too) packs everything together to a bootable image What it can do for you, a developer? Of course, continuing tradition of the RedPill LKM the code contains extensive debug mode. However, there's more. The generator isn't meant to just generate loader images. It is also meant to make it easy to add new platforms and patches. The loader generator has two different ways of patching the kernel: direct (default), or repack (set environment var BRP_LINUX_PATCH_METHOD=repack). In the repack mode the kernel is NOT patched using direct binary patches between original and final. In fact this mode assumes such pack doesn't exist. When run in repack mode the code will go as far as possible and exit before kernel patching, while printing patches to the original & patched file. Then it's up to the person running the code to convert unpacked vmlinux image to a patched one (i.e. apply any binary patches). After running the code again: new image will be detected vmlinux will be run through a script which makes a bzImage from it again the build will continue as normal build files will NOT be deleted so a bsdiff can be used to generate a binary patch This second mode is incredibly useful when adding new versions/platforms. We're not keeping our "tribal knowledge" to ourselves. If anything happens, or we pass the project to another group in the future, or someone decides to improve on the patches we did, or even when someone doesn't want to trust our pregenerated kernel patches the code will accommodate that. We don't want to keep any internal tools to ourselves and publish just the "user" stuff. Config-driven architecture The goal of the project was to make things flexible. This is why LKM is NOT specific to the hardware platform (more about that below) but rather compiled against the kernel (as you cannot make the same LKM work across multiple kernel versions). The loader builder code by itself makes very few hardcoded assumptions: synoinfo files location (this didn't change for years) grub.cfg location (this is controlled by us) anything we accidentally hardcoded Everything else is based on the combination of platform and user configs. Platform config is a simple JSON file located in "config/<HW VERSION>/<OS VERSION>/config.json". We will not go over every option as the existing ones in the repo should be self-explanatory. In short, it defines where to get the PATs, checksums for various files, lists of patches for kernel & ramdisk, GRUB options, files copied etc... On top of that some options can (and some must) be overridden by a user config file. This file defines S/N and stuff like that (but can override much more than that, for example SATA mapping). The idea here is to allow creation of customized images as updates are more common than fresh installs. As of now we tested the DS3615xs image generation and booting. It boots and passes the installation & initial configuration. The DS918+ should work too. However, consider both as pre-alpha (due to the LKM). One more thing So, today's update is mostly about RedPill Load. However, we couldn't really do that without implementing multiplatform support in the LKM. As we mentioned above the idea for the code is to be multiplatform and allow adding new models without too much hassle. That's why RedPill LKM contains all definitions in the binary and picks them based on kernel params during boot. We looked at how QEMU does multiple CPUs definition and modeled the architecture similarly: https://github.com/RedPill-TTG/redpill-lkm/commit/14dab9bde12495b1be833e1a1ffb1cf6ee3f00d6 With this release we have defined all devices for DS3615xs and DS918+. Along with the multiplatform support we had to dig into PCI (again...) to make sure multi-function devices work correctly as DS918+ utilizes them. On top of that error reporting is vastly improved now. One of the changes we also made somewhere along the way was to start documenting BIOS shims to prepare architecture for future expansion of external uP handling LEDs etc. https://github.com/RedPill-TTG/redpill-lkm/commit/e4c634e9f56f3b3d07430863e385c98e318b1823 ********************************************************************************************************** We saw your posts guys and we're seriously impressed Let us help a little, even if most of the issues are resolved by using RedPill Loader Generator: To our knowledge the only one available and working script is the one which was published by killer. It is available in his repo: https://github.com/kiler129/recreate-zImage and we use it as a submodule. From what we see now the repo is also public. Unfortunately it lacks docs but its usage is pretty straightforward. However, speaking about the screenshot you posted: you're still using parts of the Jun's loader it seems (patching file etc/passwd part). You cannot mix both. The elevator not found error in the other hand is something you can ignore (that's one of the tricks which are nice-to-have, we wrote about that in the previous post). We saw that one too. Unfortunately this one doesn't work. It only works with old kernels and it's very finicky. In short that code attempts to just monkey-guess offsets which (especially with v4 relocations) can be incredibly difficult to do. The one above actually uses the process from within the KBuild process. It's not so much about the compression but about the place. Kernel is like a matrioshka with multiple things glued around the compressed image. You cannot paste the header as there are some things after the image, there are also offsets generated based on the compressed image etc... it's a mess. It's the x86 mess... That's sadly just the toolkit. Enough to compile some things but it doesn't have full sources. We've got the original sources for a single platform from an anonymous data hoarder We didn't dig into that yet thou. Close, but you should run the whole init script The fact it stops at "booting the kernel" is actually expected (it only prints on serial). The Loader Builder has more about that in the FAQ file. Error 13 can mean anything - idespite the message in the web installer it is a catch-all for "some error happened during installation". We saw it with e.g. damaged HDDs in a real syno. You need to look into /var/log/junior_reason and /var/log/messages for details We wouldn't recommend doing this. Some things in Syno init script assume that the disks are present at boot. Additionally, vid/pid mismatch is just one of the reasons. RedPill LKM logs everything by default and with mentioned above + dmesg it's pretty easy to say what's wrong That is actually expected. The DS3615xs patch works differently than DS918+. The 3615 patches the flag code (so the error will still print but the corruption flag will be 0) while 918 one patches conditional jump to unconditional jump (so no matter what verification produced it will always set the flag to 0). Semantics really. It doesn't matter. The way to test if it's ACTUALLY working is to do: mkdir tmp1 tmp2 mount -t tmpfs tmpfs tmp1 mount --move tmp1 tmp2 If all executed without errors it means that neither header nor ramdisk checks are tripped (as any of them will block mount --move). That is a buffer overflow in strings comparison We believe this one was fixed already - try pulling the newest code and check again.
    19 points
  27. This update of the redpill_tool_chain helper is long overdue. From now on the name will be redpill-helper, as it realy is just a helper for redpill-lkm and redpill-load. You can find the redpill-helper v0.12 attached to this post. It now supports an "ext" action, which delegates the commands to the ext-manager.sh script inside a container. The extensions are cached on the host, thus extensions need to be added only once and will apply for all build profiles! This should put an end to the need to modify the script or to use the run action and add the extensions everytime a bootload image is build. Additionaly a custom_config.json is introduced, which is the place to store your custom configurations - it needs to be created by yourself and won't be overriden by any future updates of the rp-helper. Please read the README.md for usage instructions. Thanks at Pocopico, WiteWulf and Orphée for testing it thoroughly! Special thanks to WiteWulf for helping me to transform the README.md to a usefull document redpill-helper-v0.12.zip
    18 points
  28. @ThorGroup thank you for the update! And indeed, I spoted and incorporated the new make targets into the new toolchain builder version Taken from the README.md: Supports the make target to specify the redpill.ko build configuration. Set <platform version>.redpill_lkm_make_target to `dev-v6`, `dev-v7`, `test-v6`, `test-v7`, `prod-v6` or `prod-v7`. Make sure to use the -v6 ones on DSM6 build and -v7 on DSM7 build. By default the targets `dev-v6` and `dev-v7` are used. I snatched following details from the redpill-lkm Makefile: - dev: all symbols included, debug messages included - test: fully stripped with only warning & above (no debugs or info) - prod: fully stripped with no debug messages See README.md for usage. redpill-tool-chain_x86_64_v0.10.zip
    18 points
  29. For those Linux newbs who need exact instructions on installing the script, follow this here. Please be VERY careful with syntax especially when working as root. If you have not turned on ssh in Control Panel remote access, do it Download putty or other ssh terminal emulator for ssh access Connect to your nas with putty and use your admin credentials. It will give you a command line "$" which means non-privileged In File Station, upload FixSynoboot.sh to a shared folder. If the folder name is "folder" and it's on Volume 1, the path in command line is /volume1/folder From command line, enter "ls /volume1/folder/FixSynoboot.sh" and the filename will be returned if uploaded correctly. Case always matters in Linux. $ ls /volume1/folder/FixSynoboot.sh FixSynoboot.sh Enter "sudo -i" which will elevate your admin to root. Use the admin password again. Now everything you do is destructive, so be careful. The prompt will change to "#" to tell you that you have done this. $ sudo -i Password: # Copy the file from your upload location to the target location. # cp /volume1/folder/FixSynoboot.sh /usr/local/etc/rc.d Make the script executable. # chmod 0755 /usr/local/etc/rc.d/FixSynoboot.sh Now verify the install. The important part is the first -rwx which indicates FixSynoboot.sh can be executed. # ls -la /usr/local/etc/rc.d/FixSynoboot.sh -rwxr-xr-x 1 root root 2184 May 18 17:54 FixSynoboot.sh Ensure the file configuration is correct, reboot the nas and FixSynoboot will be enabled.
    18 points
  30. Решил немного облегчить жизнь новичкам и тем, кто успел подзабыть, где и что лежит. 1. Ссылка на загрузчики от 5.0 до 6.2 2. Как установить на примере загрузчика 1.04b для DSM 6.2 (918+) 3. Совместимость загрузчиков 6.0-6.2 и железа 4. Тестирование и как проверить работает ли транскодинг на примере Asrock J4105-itx, там же сборка extra.lzma с гибернацией дисков 5. Как отредактировать grub.cfg и заменить extra.lzma на работающей хрени 6. Пакет для активации железной кнопки Power off на корпусе хрени (крайняя версия 6.2-0002, на нее и ссылка) 7. Корректное отображение процессора в Информационном центре 8. Librusec на хрени через COPS (скачивание в fb2 и mobi на читалку с wi-fi прямо с хрени) 9. Torrent TV через Ace Stream в docker (актуальные команды в посте ID 273, инструкция в следующем) Просьба ссылки тут не обсуждать, добавляйте свои, если посчитаете полезным.
    18 points
  31. Failure to comply with the below guidelines will result in your topic or post being deleted. ---------------------------IF YOU ARE CREATING A TOPIC SCROLL DOWN TO THE NEXT SECTION--------------------------- ---------------------------IF YOU ARE SIMPLY MAKING A POST READ RIGHT BELOW--------------------------- I remind everyone that the DSM Updates Reporting forum is SOLELY AIMED at REPORTING SUCCESSFUL or UNSUCCESSFUL updates. This forum is NOT meant for asking questions whether they are in direct connection with the update or not. Such posts will be removed. Please follow the template below when making a post in this forum. It makes it easier for others to check the status of an update. - Outcome of the update: (Successful update or not) - DSM version prior update: (DSM 6.1.7-15284 UPDATE 3) - Loader version and model (3615xs or 3617xs or 916+ or 918+) - Using custom extra.lzma: (Yes / No and from who / version) - Installation type: (BAREMETAL / VM / Hardware details (specially NIC)) - Additional comments: (Problems encountered etc. No questions allowed here. Comments should be in direct connection to the upgrade. All other comments will be removed) EXAMPLE: - Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.3 UPDATE 7 - Loader version and model: JUN'S LOADER v1.02b - DS3615xs - Using custom extra.lzma: NO - Installation type: BAREMETAL - Gigabyte H97N - NIC: Intel I217-V & Qualcomm Atheros AR8161 Gigabit Ethernet (rev 10) - Additional comments: HANGED BUT A REBOOT FIXED IT You can copy paste the above and modify the data according to your specific situation. Keep UPPER CASE and use RED color in the first line if the update is UNSUCCESSFUL. Use BOLD as above. If you have specific comments because there is a problem with an update use the Additional Comments line to mention them. If you have a question then use the appropriate sub-forum, not this one. When posting, please DO NOT refer to your hardware in your signature or post links to your configuration from any external website or from your About Me section. If for some reason you modify those (or the link breaks) one day then your post becomes useless to the community. ---------------------------IF YOU ARE CREATING A TOPIC READ BELOW---------------------------------- If you are the one creating a topic because a new update has been released by Synology please stick to the following guideline: 1 - Visit https://xpenology.com/forum/forum/78-critical-updates/ first to check that the topic has not been created. If not, then use the following topic naming convention: If it is a critical update: DSM X.X.X-XXXXX - Update X If it is an intermediate update: DSM X.X.X-XXXXX If it is a major update: DSM X.X-XXXXX 2 - Add the following tags to the topic according to the type of update: If it is a critical update: dsm x.x.x, critical update If it is an intermediate update: dsm x.x.x, intermediate update If it is a major update: dsm x.x.x, major update 3 - Visit this topic and create the OP following the same format: Screenshot of the release note Link to the Release note Copy and paste release note content using the spoiler tag as shown below
    18 points
  32. DSM 7 handles array creation somewhat differently than DSM 6.x. This tutorial will explain the new, less flexible behavior of DSM 7, provide historical context and offer practical solutions should the reader wish to create certain array configurations no longer possible via the DSM 7 UI. The structures described herein may also be useful toward an understanding of the configuration, troubleshooting and repair of DSM arrays. Be advised - over time, Synology has altered/evolved the definitions of the storage terms in its documentation and used in this tutorial. Additionally, many of the terms have overlapping words and meanings. This can't be helped, but you should be aware of the problem. Background: DSM 6 offers many options as to how to set up your arrays. In DSM, arrays are broadly referred to as Storage Pools. Within a Storage Pool, you may configure one or more Volume devices, on which btrfs or ext4 filesystems are created, and within which Shared Folders are provisioned. Here's a simplified history of the different Storage Pool configurations available on the XPe-enabled DSM versions and platforms. If you aren't familiar with lvm (logical volume manager), it refers to a storage meta-container able to hold multiple host arrays (i.e. SHR) and/or multiple target Volumes. Note that the word "volume" in logical volume manager has nothing to do with DSM Volumes. DSM 5 provides multiple Storage Pool configurations, including "Basic" (RAID 1 array with one drive), RAID 1, RAID 5, RAID 6, RAID 10, and SHR/SHR2 (conjoined arrays with lvm overlay). These are known as "Simple" Storage Pools, with a single Volume spanning the entire array. The consumer models (i.e. DS918+/DS920+ platforms) always create Simple Storage Pools, with non-lvm arrays (RAID) designated as "Performance" and lvm-overlayed (SHR/SHR2) as "Flexible." DSM 6 adds enterprise features for DS3615xs/DS3617xs/DS3622xs+, including RAID F1 arrays and "Raid Groups." A Raid Group is a Storage Pool with an lvm overlay regardless of array type, and that permits multiple Volumes to be created within it. For DS3615xs/DS3617xs the "Performance" Storage Pool is the same as the consumer models (non-lvm), while "Flexible" refers to the Raid Group (lvm-overlayed) option. Synology limits the use of SHR/SHR2 with these models by default. However, it can be enabled with a well-known modification to DSM configuration files, such that the UI is then able to create a SHR array within a "Flexible" Raid Group Storage Pool. DSM 6 also offers SSD caching on all platforms. When SSD caching is enabled, the target Volume device is embedded into a "device mapper" that binds it with the physical SSD storage. The device mapper is then mounted to the root filesystem in the place of the Volume device. DSM 7 supports all of the above configurations if they exist prior to upgrade. However, DSM 7 Storage Manager no longer is able to create any type of Simple Storage Pool. On all the XPe supported platforms, new Storage Pools in DSM 7 are always created within Raid Groups (therefore lvm-overlayed) and with a dummy SSD cache, even if the system does not have SSDs to support caching. lvm uses additional processor, memory and disk space (Synology is apparently no longer is concerned with this, assuming that the penalty is minor on modern hardware) and if you don't need SHR or cache, creates unnecessary complexity for array troubleshooting, repair, and data recovery. Look back at the first illustration vs. the last and you can see how much is added for zero benefit if the features are not required. Users might prefer not to have superfluous services involved in their Storage Pools, but DSM 7 no longer offers a choice. From all these configuration options, your Storage Pool type can be determined by observing how the DSM Volume connects to the filesystem, and the presence or absence of lvm "Containers." This table shows various permutations that you may encounter (note that all are describing the first example of a Storage Pool and DSM Volume, multiples will increase the indices accordingly): Storage Pool Type Array Device(s) Container /volume1 Device Simple (DSM 6) "Performance" /dev/md2 (none) /dev/md2 Simple (DSM 6, DS918+/DS920+ SHR) "Flexible" /dev/md2, /dev/md3... /dev/vg1000 /dev/vg1000/lv Raid Group (DSM 6, DS36nnxs SHR) "Flexible" /dev/md2, /dev/md3... /dev/vg1 /dev/vg1/volume_1 Simple with Cache (DSM 6) /dev/md2 (none) /dev/mapper/cachedev_0 Raid Group with Cache /dev/md2, [dev/md3...] /dev/vg1 /dev/mapper/cachedev_0 Example query to determine the type (this illustrates a cache-enabled (with read-only cache), lvm-overlaid Raid Group with one DSM Volume): dsm:/$ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/md0 2385528 1063108 1203636 47% / none 1927032 0 1927032 0% /dev /tmp 1940084 1576 1938508 1% /tmp /run 1940084 3788 1936296 1% /run /dev/shm 1940084 4 1940080 1% /dev/shm none 4 0 4 0% /sys/fs/cgroup cgmfs 100 0 100 0% /run/cgmanager/fs /dev/mapper/cachedev_0 33736779880 19527975964 14208803916 58% /volume1 dsm:/$ sudo dmsetup table | head -2 cachedev_0: 0 1234567 flashcache-syno conf: ssd dev (/dev/md3), disk dev (/dev/vg1/volume_1) cache mode(WRITE_AROUND) dsm:/$ sudo lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert syno_vg_reserved_area vg1 -wi-a----- 12.00m volume_1 vg1 -wi-ao---- 11.00g Solutions: If desired, DSM 7 can be diverted from its complex Storage Pool creation behavior. You will need to edit the /etc/synoinfo.conf and /etc.defaults/synoinfo.conf files from the shell command line. /etc/synoinfo.conf is read by DSM during boot and affects various aspects of DSM's functionality. But just before this during the boot, /etc.defaults/synoinfo.conf is copied over the file in /etc. Generally you can just make changes in /etc.defaults/synoinfo.conf but the copy is algorithmic, and desynchronization can occur. So it is always best to check for the desired change in both files if the results are not as expected. 1. Enable SHR on DS3615xs, DS3617xs and DS3622xs+: Edit synoinfo.conf per above, changing the parameter supportraidgroup from "yes" to "no". It is no longer required to comment out this line, or add "support_syno_hybrid_raid" to the configuration file. Despite the implications of this parameter being set, Raid Groups continue to be supported and DSM will create Raid Group enabled Storage Pools, with the added bonus of the option for SHR available in the UI. 2. Create arrays without dummy caches: Edit synoinfo.conf per above, changing the parameter supportssdcache from "yes" to "no". Arrays created while this option is disabled will not have the dummy cache configured. Further testing is required to determine whether SSD cache can subsequently be added using the UI, but it is likely to work. 3. Create a cacheless, Simple array on DSM 7: DSM 7 no longer can create a Simple Storage Pool via the UI. The only method I've found thus far is with a DSM command line tool. Once Storage Pool creation is complete, Volume creation and subsequent resource management can be accomplished with the UI. Note that you cannot just create an array using mdadm as you would on Linux. Because DSM disks and arrays include special "space" metadata, the mdadm-created array will be rejected by DSM 7. However, using the DSM command-line tool resolves this problem. First, you need to determine the RAID array type (raid1, raid5, raid6, raid10 or raid_f1; raid_f1 is only valid on DS3615xs/DS3617xs/DS3622xs+ and all array members must be SSDs) and the device names of all the disks that should comprise the array. The disks that you want to use should all be visible like the example: dsm:/$ ls /dev/sd? /dev/sda /dev/sdb /dev/sdc /dev/sdd And, the target disks should not be in use by existing arrays (nothing should be returned): dsm:/$ cat /proc/mdstat | egrep "sd[abcd]3" Then, create the array with the following command (example uses the disks from above and creates a RAID 5 array). All data will be erased from the disks specified. dsm:/$ sudo synostgpool --create -t single -l raid5 /dev/sda /dev/sdb /dev/sdc /dev/sdd If successful, the array will be created along with all the appropriate DSM metadata, and you will see the new Storage Pool immediately reflected in the Storage Manager UI. If it fails, there will be no error message, and it's usually because disks are already in use in another array. Deleting the affected Storage Pools should free them up. You can review the events that have occurred by reviewing /var/log/space_operation.log. A DSM Volume can then be added using the Storage Manager UI. Further testing is required to determine whether SSD cache can subsequently be added using the UI, but it is likely to work.
    16 points
  33. Bonjour, [EDIT] @nicoueron21/10/2023 : Changement du mode de configuration du flag directboot [EDIT] @nicoueron16/10/2023 : Factorisation du tuto avec le tuto principal [EDIT] @nicoueron02/10/2023 : Refonte avec le loader arpl-i18n [EDIT] @nicoueron05/05/2023 : révélation de la section BIOS [EDIT] @nicoueron24/11/2022 : ajout section "mise à jour" [EDIT] @nicoueron19/11/2022 : version DSM7.1.1 minimum + adaptations commande suite aux changements du loader >v0.9.2.9 [EDIT] @nicoueron07/10/2022 : fin support <DSM7.1 [EDIT] @nicoueron26/09/2022 : Ajout capture écran paramètre IDE pour avoir les disques 5 et 6 de visible [EDIT] @nicoueron27/06/2022 : support DS3622XS+ et note sur l'incompatibilité de l'USB avec DSM7.1 [EDIT] @nicoueron28/04/2022 : prise en charge de l'USB [EDIT] @nicoueron22/03/2022 : précision sur la pile du bios [EDIT] @nicoueron16/03/2022 : ajout de DSM 7 [EDIT] @nicoueron08/05/2020 : adaptation du tuto pour DSM 6.2.3 sans aucun matos nécessaire en plus. Pré-requis 1 : Service DHCP et Accès internet Un service DHCP doit être actif sur votre réseau. De même, lors de la construction du loader, le serveur doit avoir accès à Internet. Pré-requis 2 : Vérifier la pile du BIOS Avant tout de chose, le serveur HP N54L gen7 étant maintenant très ancien, je conseille fortement de procéder au remplacement de la pile du BIOS, pour info la référence est CR2032. N'hésitez pas à faire des captures d'écrans des options de votre BIOS avant son remplacement, à défaut les options ci-dessous devraient pouvoir vous aider Pré-requis 3 : Flashé le BIOS avec cette version correctement configurée Celui de 2011 (V041 - 2011): TheBay_Microserver_Bios_041.rar Le Bios Mod: o41072911mod.rom Il suffit de supprimer celui présent sur la clé, de copier/coller le fichier mod.rom et de le renommer comme l'ancien. Vous pouvez suivre ce Tuto qui est très explicite : How to flash Bios HP Proliant (c'est le même Bios pour les 3 servers N36L; N40L et N54L). Une fois le BIOS flashé faites les réglages suivants : Onglet Main: Onglet Main > Boot Setting Configuration : Onglet Advanced > CE1 Support = Disabled Onglet Advanced > IDE Configuration > SATA Controller Mode AHCI Onglet Advanced > Advanced ACPI Configurtation > ACPI v2.0 Onglet Advanced > AHCI Settings > ici il faut vous assurer que TOUS les disques sont bien détectés et que le paramètre AHCI BIOS Support est sur Enabled Onglet Boot > Hard Disk Drives > ici positionner la clé USB en premier Onglet Chipset > ici positionner l'option onChip IDE Type sur IDE Loader Arc : ==>Suivre à la lettre le tuto générique : [Tuto] DSM 7 pour tous la seule différence porte sur le point suivant qui doit être réalisé juste avant la construction du loader (point n°11) : Dérouler le menu Boot Options (1) > Sélectionner "Directboot: true" (2) > Build Loader (3) et.... c'est tout ! En effet, le reste est identique au tuto ==> Enjoy
    15 points
  34. This is a simple guide and step by step tutorial on how I got tiny core red pill loader running and working on a proxmox server. This not the only way, just the way I do it and it seems to work. You will need a few things downloaded and ready to access on your local machine. The tiny core red pill image from @pocopico DOWNLOAD Putty for windows (or your mac equivalent) DOWNLOAD WinSCP for windows (or mac equivalent) DOWNLOAD and of course a working server with proxmox installed and running. DOWNLOAD The correct .pat dsm installation file downloaded directly from synology.com (you can handle this one on your own 😉) From proxmox create a VM. Most of the defaults work, change these according to your specific needs and requirements, I personally used: Q35, virtio nic, HDD is your choice, 2 cores and 2gb ram (again your choice). System Q35 is not required either, i440x works too, this is just what I used and it works. HDD is whatever you want, or pass thru complete drives or controllers.. again your choice based on your setup. Same for nic, cpu and ram. Just be sure to Use NO MEDIA in the OS section * REMEMBER THE VM ID # * you will need it later * Remember, do not use any media is selected here. Now, load WinSCP and connect to your proxmox server using your local ip and proxmox credentials. There on the right side, navigate to /var/lib/vz/images/ and create a folder/directory of whatever the vm number was you created, in these pictures its 101 so in this case it should be /var/lib/vz/images/101/ On the left side in WinSCP navigate to where you downloaded and extracted the tcrp image Copy the extracted tcrp img from your local machine to your proxmox vm directory Alternatively, you can enter a couple of command lines in the main pve node shell to download and extract the tcrp image without using winscp at all, but I do it the hard way. Either way works so its up to you. The alternative method is open the main pve node shell in proxmox and enter these commands (use copy and paste for each line) # set vm id to whatever it was at time of creation id=101 # create image directory, download and uncomporess mkdir -p /var/lib/vz/images/${id} curl --location https://github.com/pocopico/tinycore-redpill/raw/main/tinycore-redpill.v0.4.6.img.gz --output /var/lib/vz/images/${id}/tinycore-redpill.v0.4.6.img.gz gzip --decompress /var/lib/vz/images/${id}/tinycore-redpill.v0.4.6.img.gz --keep Now, at this point one way or another you should have a dir of your vm # in the correct location with the tcrp extracted image inside ready to issue the following commands, so now click your main pve node on the left panel and choose shell and paste this command there. (edit the 101 vm # with whatever your vm # is) echo "args: -device 'nec-usb-xhci,id=usb-bus0,multifunction=on' -drive 'file=/var/lib/vz/images/101/tinycore-redpill.v0.4.6.img,media=disk,format=raw,if=none,id=drive-disk-bootloader' -device 'usb-storage,bus=usb-bus0.0,port=1,drive=drive-disk-bootloader,id=usb-disk-bootloader,bootindex=999,removable=on'" >> /etc/pve/qemu-server/101.conf Now type nano and the last part of the above command (the directory part) to verify the entry into your vm .conf file so in this case nano /etc/pve/qemu-server/101.conf You easily verify the entry into the bottom of the .conf file of your vm, now press control x to exit. Now select your vm and choose hardware from the column Here using the Add button you should add a serial 0 console to monitor your dsm loader if needed (helpful for troubleshooting) and if you are adding hdd or using pass thru of hba controllers or sata controllers or any other specific hardware for your build add it here. Now select Options from the list column, and select only ide2 CD-ROM (uncheck all others) and make cd-rom priority #1 by dragging it to the top. Now you are ready to spin up your vm and build your loader. You can watch the process of booting by right clicking on the vm number/name and select >_ console a new window will open and you will see lines of code fly by, but only in this console monitor window. This is an optional step. At this point you should be booting tcrp and ready to build your loader... @Peter Suh has a great tutorial for that linked here. Follow his directions for building your loader. Use putty to SSH into tcrp to build the loader, The main thing when building if you used virtualized nic card, add the v9fs ext to get network port working, use this command before executing the redpill build command in putty. ./rploader.sh ext <build platform> add https://raw.githubusercontent.com/pocopico/rp-ext/master/v9fs/rpext-index.json After you successfully build your loader, and during the reboot, go back to proxmox gui and when you see the booting menu screen, press UP to select BOOT FROM USB, VERBOSE then press enter... that is very important. You only have to do this once, and it will save and retain that selection until you change it again. You do not want to boot from sata! At this point you load your browser, go to find.synology.com or use synology search application on your pc, or simply go to the ip of your new vm dsm and complete the process. If you had your console monitor opened from above, you should see sign in prompt, if you scroll up a little bit you will also see the ip of your dsm vm. If you successfully booted from usb, everything will work. If you did not change that during the first reboot, and you are booting from sata, you will most likely get a failure to install dsm. You will need to power down the vm, re-start the vm, and choose boot from usb verbose. If this guide helped you, please press the thanks button for me. 🖖😀 And remember to thank @pocopico and @Peter Suh Enjoy!
    15 points
  35. 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 )
    15 points
  36. 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.
    15 points
  37. Status Update! Recently we were working hard in the kernel space to bring even more missing things and bring it into a more stable state. That meant we had little time to respond but we're blown away by the number of posts here! mfgBIOS shimming stability As we discussed here before there were moments where some BIOS functions weren't shimmed or there were flaky. This caused the OS to sometimes work correctly but sometimes fail the 24h test. Guess how easy was that to debug and fix However, we did it and now the mfgBIOS shimming should be almost bulletproof! RTC emulation We've added a full RTC proxy layer. This wasn't strictly needed for 3515xs series. However, 918+ and other models use RTC chip which is not natively/fully supported for the Linux kernel. This means that various subsystems rely on mfgBIOS to update the time from RTC on boot. Since that chip does not exist outside of the official hardware we needed to go around that. In short the LKM code plugs into mfgBIOS and serves as a proxy layer between what's a real RTC (or a one from hypervisor) and what mfgBIOS can understand. Currently, the time set/get is implemented. Alarms are mocked to the point that mfgBIOS doesn't complain. In fact the BIOS code can even set these alarms but they will be erased upon reboot. We didn't bother actually writing them to the RTC. The reason being a) we've never seen anybody using it and b) most RTCs [or actually the hw connected to them] is broken to the point that they don't work anyway (or only work from certain sleep states). If the community desires we can add that. Inverting serial ports on 3615xs We hate it. We did it. It's sort of working and it's a big hack. We will most likely disable it by default as this isn't even fully stable. Also this method cannot work on kernel v4 which... well, v7 and 3615xs. Whoever in syno had this brilliant idea should seriously think again before pulling such a stunt again. This breaks a lot of stuff. Fix ttyS0 on 918+ On some platforms first serial port is intentionally disabled. We added a small hack to re-enable it. Virtual Serial Port / UART This is big. In many ways actually. This single commit with over 1300 new lines and the patch taking 70KB was by far the biggest addition. The complexity of this part is really something we grind our teeth on. To make sure the solution works on all kernels without hacks we had to emulate a physical UART chip. So we did. We wrote a whole software-based emulator of National Semiconductors 16550A UART controller, along with support for FIFOs. Additionally, as we wanted the code to perform great we raised the bar and wrote an additional layer of virtual IRQ (as the real ones cannot be used for many reasons here) which actually made the module multithreaded in the kernel. This whole thing took, across all of us, probably close to 150 hours to develop. There were many ideas and failed endeavors. But the full chip emulation should serve us a long way you truly cannot distinguish it from a real thing (as it is not hacking the kernel in any way). If anyone wants to borrow that code for something non-DSM related feel free - it's actually modular and not coupled with the RedPill LKM in any substantial way. Currently, this vUART stuff is not running in the actual LKM. It is meant to be a component to implement PMU emulation. That part requires a two (hopefully) simple functions which react to the data from the DSM and respond like the PMU would. This will also allow us to give a simple hook to anybody who's willing to connect a hardware PMU to get LEDs and what not working ********************************************************************************* v7 testing We're so happy to see the community effort to add v7. As it is now available for 3615xs we will definitelly jump into it and merge PRs if they pass AFTER merging them we will probably reorganize template files a bit as that symlink-hell was a bad idea. Now let us respond to everything: RedPill actually blocks telemetry as well If you want to check that just go the Control Panel and click "What's new" on an update - you will not see a syno page. Currently it SHOULD work on some baremetal configs but it's definitely not tested. It will be plug-and-play when it's stable. We confirmed that ESXi doesn't allow adding virtual USB drives, so we need SATA DOM boot support. Stay tuned. Setting vid/pid or any other options will NOT make the loader work without LKM changes (ok, technically MAYBE if you recreate PCI tree in Proxmox but .... no, that's not the solution and definitelly not for ESXi or baremetal ;)). You didn't provide RedPill LKMs. You need to compile them if you want to play with the current build. You shouldn't try to compile the kernel but the module. Executing make in the kernel dir will try to build the whole kernel (which doesn't make any sense as it will not be usable really). If you're having problems compiling the module the release is not meant for you (yet). We weren't able to access the telegram as they force us to give a valid, physical phone number. For obvious reasons we didn't give them one When we have a moment to arrange that we will arrive for sure. However, as the current stage is still intended for developers (and we're BEGGING normal users to not use it due to missing stuff which causes various trips in the DSM itself). Unless there's some way to use telegram without a phone number which we don't know about? DO NOT USE IT. Seriously, we don't want to sound rude but if we say this is a development release we mean it. The kernel module lacks some functionality required for the DSM to stay stable. In the current state data loss is a possibility. Thanks! We need some smart way for adding kernel extensions outside of the ramdisk (as it's limited in size). Something like Jun's extra.lzma. However, as it uses a different method of loading we cannot simply merge ramdisks automatically hmm... Great job! We love the approach of going docker. We honestly didn't look into the docker toolchain (yet!) you've built but we're excited! What do you think about incorporating it into RedPill-Load repository? We think it will be a great addition so that the whole thing can be run on any dockerized system. Drop us a PM to not pollute the thread. In general it's great - the only thing which we will keep is making sure the user can actually use JSON config and not makefile - we pulled teeth for hours to make it happen in bash as JSON is user-friendly while Makefile... well Onboard network will require a separate kernel extension. This is the same issue as with power button kernel extension - we don't have a good way for not including all extensions in the main ramdisk (which cannot grow too much, especially for 918+). This looks like a broken patch for ramdisk hmm. Is the file even loaded via network? Did you use virtio driver for the ethernet? For any error 13 a full log from /var/log/messages and install_log is needed. However, in general VMWare will not work until we implement SATA DOM as VMWare Workstation/Fusion/ESXi doesn't allow creating virtual USB drives. To add to that EFI boot is problematic in many way as it tries to initialize devices before Linux can touch them. This can end poorly on some hardware when running DSM. That's why we disabled EFI in the GRUB deliberately. You cannot do that. There's no support for SATA DOM in the LKM. This is a known issue: https://github.com/RedPill-TTG/redpill-lkm/issues/3 Telnet access has nothing to do with the loader. It's up to the settings you set in your hypervisor On Proxmox there's a local access through "qm console", on VirtualBox you can set COM1-4 in settings to be a telnet or a raw socket or whatever else. These warning are just really warnings and GCC isn't correct here actually. As 4.8 is old we need some creative way to make it happy. But since this code works as expected and is a weak warning we aren't worried about that. The one regarding unused function is there because we left some skeleton for future shims - that one used to be used before we implemented proper RTC. As for rebuilding kernel: you MUST use the proper GCC for that. It will NOT build with GCC 5.4 properly as v3 only supports up to v4.9 (or something along the lines). Unfortunately Proxmox (or rather QEMU) cannot do a split-brain situation where some instructions are virtualized with hardware KVM acceleration and some are done in software. This means it's not feasible to run emulated haswell when your host CPU doesn't support all the instructions. You CAN do that for testing (disable HW acceleration in VM options) but it's PAINFULLY slow. We use it from time-to-time for testing LKM but it's really like working on a Pentium MMX. That's a good decision in our opinion to move to debian8. It is old... but so is the kernel. We also use Debian 8 VM internally. From what we've heard syno does not use a cross-toolchain for building kernels either. That says something. As for booting on ESXi see above - it will not boot as of now. Isn't unraid using qemu? It should boot no problem (at least to grub) as long as it's a TRUE usb boot and not a sata boot. Can you run the VM and check the output from "ps -a"? Go through it manually and try to find the qemu/kvm process. It will have a VERY long cmdline (like several lines long). This is the ultimate source of truth regarding what's being run. Where precisely does it stop? Can you post a screenshot?
    15 points
  38. Установка и настройка DSM на основе версии 6.2.3 Ну вот, муки поиска позади и вы пришли к эпохальному решению создать сервер на основе Хрени.....)))) Надеюсь, что подошли к этому шагу с долей познаний и оценили свои возможности. Данный мануал является общим, без акцента на частные настройки и особенности применяемого вами железа, такие как настройки БИОС_а и хардово-софтовые нюансы вашего железа. Процедура описана на основе последней возможной (на данный момент) для установки версии DSM. Но она применима и на ранние версии DSM 6 . Более древние уже не помню ))) Итак начнём....... Берём флешку. Определяем vid pid. Редактируем grub.cfg. Записываем загрузчик 1.03b для 3615 - 3617 или 1.04b для 918+ Загрузчики: https://mega.nz/#F!yQpw0YTI!DQqIzUCG2RbBtQ6YieScWg!7AoyySoS Файлы DSM 6.2.3-25426: https://archive.synology.com/download/Os/DSM/6.2.3-25426 Обновление только вручную, предварительно скачав файлы !!!! Не обновляться до версии 6.2.4 Нежно "втыкиваем" наш загрузчик в USB и запускаем процесс установки. Можно подключить монитор и что то там увидеть, но я уже давно делаю это "вслепую". По умолчанию запускается Установка. И если всё же подключили монитор, то он вас обрадует этой надписью:"Happy Hacking" - Счастливый взлом. То есть всё хорошо ))) Далее, запускаем Synology Assistant или идём на find.synology.com для поиска своего сервера. Я пользуюсь Synology Assistant_ом, потому и описание будет с ним. Во избежании недопонимания и подобных трудностей бытия, уточняю..... Поиск сервера посредством Synology Assistant или на find.synology.com, осуществляется с ДРУГОГО Компа. С ДРУГОГО, а не с того, на который ставили Сервер. Synology Assistant - почитать: https://www.synology.com/ru-ru/knowledgebase/DSM/help/Assistant/assistant Synology Assistant - скачать: https://archive.synology.com/download/Utility/Assistant/6.2-24922 Нашли свой сервер, вошли по ip и запускаете дальнейшую установку Установка вручную и только так. Находим ранее скачанный файл DSM и подсовываем его. Ну а далее всё интуитивно понятно Создаём учётную запись Предложение по созданию Synology QuickConnect_а отметаем, так как для его работы необходима Реальная Валидная пара. Эту функцию стоит запустить сразу, а то потом она будет вылезать постоянно. Тоже самое, запустить и забыть. Вся безопасность в наших руках ))) Не успели запустить, а уже устарело .... ))) Идём в Центр пакетов и обновляемся. Идём в Панель управления Видим свою версию DSM и предложение обновиться до 6.2.4. Ни в коем случае не обновляемся. Загрузчика, на момент написания мануала, на эту версии НЕТ. Полезная функция Резервирования настроек. Резервируйте их при каждой манипуляции с обновлениями. Потом восстановить настройки будет проще. Нам необходима Папка общего доступа. Туда мы будем складывать файлы И тут нас посылает система к созданию Раздела. Без него никак. Опять таки, всё интуитивно понятно и просто идёте предложенным путём. Но внимательно читаем Создаём Пул хранения. Руководствуемся предложениями Мастера создания Выбираем необходимое или же идём по пути умолчания. Выбираем диск. Он у меня один, если у вас несколько, можно создать сразу RAID-массив. Просто перетягиваем его слева на право Пул готов, пошла проверка. Теперь необходимо создать Том Процесс проверки запущен, но он не мешает дальнейшим настройкам Создаём раздел Выбор файловой системы на ваше усмотрение. Гуглим и читаем мануалы. Я использую Btrfs Процесс проверки диска. Уже ближе к концу Ну вот мы уже имеем Раздел. В Диспетчере хранения имеются инструменты контроля за дисками Информация о состоянии. Смарт. Тесты Возвращаемся в Файл Стейшен, создаём Папки общего доступа. Выбор значений за вами. Редактирование разрешений за вами. Читайте внимательно. Советую, после первичных настроек, запустить эту утилиту . Она поможет настроить интернет на сервере. Очень полезная утилита Так же советую использовать Довланд Стейшен в качестве качалки торрентов. Простая и достаточно эффективная утилита. Сам её использую Нюанс настройки.... По умолчанию, почему то прописано ограничение на отдачу. Значение "20" заменить на значение"0" После настроек, советую открыть так называемый ROOT доступ: https://www.synology.com/ru-ru/knowledgebase/DSM/tutorial/General_Setup/How_to_login_to_DSM_with_root_permission_via_SSH_Telnet Ну вот вроде и всё.... Основные аспекты первоначальной настройки я охватил, остальное изучите в процессе эксплуатации.
    15 points
  39. Updated powerbutton package to work with dsm 6.2 for ds3615, ds3617 and ds918+ POWERBUTTON_6.2-0002.SPK or https://www39.zippyshare.com/v/R3ftOA3X/file.html
    15 points
  40. So I migrated my xpenology server from DS918+ model to DS3622xs, and the nvme cache no longer works since the model number no longer exist in libsynonvme.so.1. I dig into the libsynonvme.so.1 and found it might check your pcie location to have the nvme drive works properly. After inspect the file, I found it just checks /etc.defaults/.extensionPorts and we just need to modify that. Here are the steps: 1. Check your nvme pci location(in my case it's 0000:00:01.0😞 udevadm info /dev/nvme0n1 P: /devices/pci0000:00/0000:00:01.0/0000:01:00.0/nvme/nvme0/nvme0n1 2. Modify /etc.defaults/.extensionPorts to have the port number match your nvme location. cat /etc.defaults/extensionPorts [pci] pci1="0000:00:01.0" 3. I did not even restart and the nvme cache drive already appears. Hope this helps anyone who is looking to solve this. Update: If you worry a system update will revert this modification, just add a startup script with root: sed -i 's/03.2/[your_pci_last_three_digs]/g' /etc.defaults/extensionPorts In this way, no matter what version you goes, this will always stay.
    14 points
  41. This is RR’s current status as received from a community user. RR seems to be continuously being updated under the name BLACK SYNOLOGY NAS SYSTEM. However, it appears that it has been converted to domestic use for Chinese people with memberships. He is probably considering access for foreigners if membership is allowed. https://www.123pan.com/s/56Sfjv-1d0WH.html PASSWORD : RRRR Rather, I think that switching to a private membership-only Chinese domestic market can free him from Synology. In any way, I'm just happy that RR's development continues without stopping. https://drive.google.com/file/d/12EinJAx6O9hrjYVAqAtJWc6l5S5l4Vi9/view?usp=drive_link
    14 points
  42. 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.
    14 points
  43. Download: 1. synoboot vmdk https://mega.nz/#!fdBWBJYB!P3MbGY2v_X_udUhaSgVBQZ74KNRf7vtjMCO39u1I91Y 2. juns loader for DSM 6.2 https://mega.nz/#F!ZlkHQTTb!keje3RK017OjTp3vuWb-Cw 3. synology DSM.pat for synology 3615xs https://www.synology.com https://archive.synology.com/download/DSM/release/ 4. open vm tools spk http://spk.4sag.ru/?fulllist=true 5. XPEnology Tool for Windows x64 PREPARATIONS unzip synoboot.vmdk from DS3615xs 6.0.2 Jun's Mod V1.01 (synoboot.vmdk works with 3615 and 3617 loaders) unzip synoboot.img from synoboot_3615 mount synoboot.img partition 0 with osf mount Make sure to uncheck Read-only drive Go to the mounted drive, Grub folder and edit grub.cfg with notepad++  If you want change default SN and mac1 comment boot option lines you dont need in esxi #menuentry "DS3615xs 6.2 Baremetal $VERSION" --class os { # set img= # savedefault # loadlinux 3615 usb # loadinitrd # showtips #} # #menuentry "DS3615xs 6.2 Baremetal $VERSION Reinstall" --class os { # set img= # loadlinux 3615 usb mfg # loadinitrd # showtips #} # #menuentry "DS3615xs 6.2 Baremetal AMD $VERSION" --class os { # set img= # set zImage=bzImage # savedefault # loadlinux 3615 usb # loadinitrd # showtips #} menuentry "DS3615xs 6.2 VMWare/ESXI $VERSION" --class os { set img= savedefault loadlinux 3615 sata loadinitrd showtips } save file, dismount all and exit. ESXi part: Upload synoboot.vmdk and synoboot.img to esxi (in one folder) Create new VM name the xpenology vm as you want and select Linux and Other 3.x Linux x64 select your storage and you should see customize settings now remove default disk remove scsi controller remove cd/dvd drive and if you are using 3617 loader you need to remove USB controller or change type to USB 3.0 now set cpu at 2 set memory 2GB change Network Adapter Type to E1000e set network adapter 1 mac addres you have in the grub.cfg for example 00:11:32:2C:A7:85 now add existing hard disk and point to the synoboot.vmdk uploaded before. Make sure its on SATA 0:0 now add another sata device and add vm disks to it (sata 1:0, 1:1 etc) and now, the vm is done and finish now start your VM and wait to see after few minutes open in new tab browser find.synology.com click connect accept EULA Set UP and manual install point to DSM 3615xs.pat file downloaded earlier after you confirm instalation you should see instalation progress after 10 minutes reboot enter username, password and server name for dsm skip configure quickconnect dont share location with synology (find.synology.com will not find virtual dsm) now DSM is ready This type of VM should work with dsm 6.2, 6.2.1, 6.2.2 and 3615xs/3617xs loaders DSM 6.2.3 is showing synoboot drive as eSata in dsm BIG thanks to @flyride and @Balrog for the fix reported by @boghea
    14 points
  44. Update the toolchain builder to 0.6.0 # Inofficial redpill toolchain image builder - Creates a OCI Container (~= Docker) image based tool chain. - Takes care of downloading (and caching) the required sources to compile redpill.ko and the required os packages that the build process depends on. - Caches .pat downloads inside the container on the host. - Configuration is done in the JSON file `global_config.json`; custom <platform_version> entries can be added underneath the `building_configs` block. Make sure the id is unique per block! - Support a `user_config.json` per <platform_version> - Allows to bind a local redpill-load folder into the container (set `"docker.local_rp_load_use": "true"` and set `"docker.local_rp_load_path": "path/to/rp-load"`) ## Changes - removed `user_config.json.template`, as it was orphaned and people started to use it in an unintended way. - new parameters in `global_config.json`: -- `docker.local_rp_load_use`: wether to mount a local folder with redpill-load into the build container (true/false) -- `docker.local_rp_load_path`: path to the local copy of redpill-load to mount into the build container (absolute or relative path) -- `build_configs[].user_config_json`: allows to defina a user_config.json per <platform_version>. ## Usage 1. edit `<platform>_user_config.json` that matches your <platform_version> according https://github.com/RedPill-TTG/redpill-load and place it in the same folder as redpill_tool_chain.sh 2. Build the image for the platform and version you want: `./redpill_tool_chain.sh build <platform_version>` 3. Run the image for the platform and version you want: `./redpill_tool_chain.sh auto <platform_version>` You can always use `./redpill_tool_chain.sh run <platform_version>` to get a bash prompt, modify whatever you want and finaly execute `make -C /opt/build_all` to build the boot loader image. Note1: run `./redpill_tool_chain.sh` to get the list of supported ids for the <platform_version> parameter. Note2: if `docker.use_local_rp_load` is set to `true`, the auto action will not pull latest redpill-load sources. See README.md for examples redpill-tool-chain_x86_64_v0.6.zip
    14 points
  45. Господа, товарищи.. Не пишите мне свою почту. Знать мне её не обязательно, а ответ всё равно прилетит в личку на ресурсе.
    14 points
  46. hello, the api url change try this (it's working for me) https://your-ip:5001/webapi/auth.cgi?api=SYNO.API.Auth&version=3&method=login&account=admin&passwd=your_admin_password&format= cookie the other url (for activation) not change https://URL:PORT/webapi/entry.cgi?api=SYNO.ActiveBackup.Activation&method=set&version=1&activated=true&serial_number="SERIALNUMBER" regards
    13 points
  47. Everytime when I think, there is nothing left to optimize on the toolchain builder someone commes around and finds something that makes sense to be added... Thus said, here is the v0.9 of the toolchain builder. - added sha256 cheksum for kernel and toolkit-dev downloads in `global_config.json`. The item `"download_urls"` is renamed to `"downloads"` and has a new structure. Make sure to allign your custom <platform version> configurations to the new structure when copying them into the `global_config.json` - check checksum of kernel or toolkit-dev when building the image and fail if checksums missmatch. Will not delete the corrupt file! - added`"docker.custom_bind_mounts"` in `global_config.json` to add as many custom bind-mounts as you want, set `"docker.use_custom_bind_mounts":` to `"true"` enable the feature. - fixed: only download kernel or toolkit-dev required to build the image (always downloaded both before, but only used either one of them when building the image) - added simple precondition check to see if required tools are available See README.md for usage. redpill-tool-chain_x86_64_v0.9.zip
    13 points
  48. Горячие пирожки можно найти >>здесь<<. Только stand-alone вариант.
    13 points
×
×
  • Create New...