Leaderboard

you can try my branch, I got 3615 7.0.1 working https://github.com/comicchang/redpill-load/tree/7.0.1

i am not sharing image may be i mistyped, i want to say there are people came for just images, they can use script for their own image rather than asking someone. Sent from my iPhone using Tapatalk

Hello guys, with the help of @Orphée and @Comic Chang's repo , @pocopico driver I wrote a script which gives you Redpill image please change VID/PID/Mac/Serial no. accordingly I tried in Linux VM GUIDE:- ```nano takeredpill.sh``` add your PID/VID/MAC/SN in the beginning of the script ```chmod +x takeredpill.sh``` ```sh takeredpill.sh```` output folder have image ** this is early stage may be error happen don't worry please ping me takeredpill.sh takeredpill.sh

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

Redpill devs might want to consider one of the below listed models for support in order to enable this very useful and new feature. FMI: https://kb.synology.com/en-us/DSM/help/DSM/StorageManager/volume_btrfs_dedup?version=7

mpt2sas.ko is already present on the ds3615xs, with the latest redpill there is a patch to fix names so you can use that .ko simply using supportsas=yes (this activates the load of that .ko on boot). sas-activator just loads the same .ko without the need of supportsas=yes, it autodetects the LSI if present and load the correct .ko accordingly. using the latest redpill with the patch probably breaks something in that .ko, so you could use the mpt2sas ext from @pocopico that is compiled in v14 (stock is v20) and does not have that break. from my testing, you should test also and report.

It’s been asked and answered many times see https://github.com/RedPill-TTG/redpill-load/issues/18

@pocopico compiled once again with CROSS_COMPILE make -C /usr/src/module_compile/tn40xx-driver-vendor-drop-v0.3.6.17.2 EXPECTED_KDIR=/usr/src/module_compile/DSM-7.0-toolkit/build CROSS_COMPILE=/usr/src/module_compile/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu- MV88X3310=YES QT=YES TL=YES AQ=YES MUSTANG=YES and now it works!! shibby@nas:~$ dmesg | grep tn40xx [ 27.203540] tn40xx: Tehuti Network Driver, 0.3.6.17.2 [ 27.203541] tn40xx: Supported phys : MV88X3310 QT2025 TLK10232 AQR105 MUSTANG [ 27.203567] tn40xx 0000:01:00.0: enabling device (0000 -> 0002) [ 27.203638] tn40xx: srom 0x0 HWver 16 build 0 lane# 4 max_pl 0x1 mrrs 0x2 [ 27.420101] tn40xx: PHY detected on port 0 ID=2B09AB - MV88X3310 (A1) 10Gbps 10GBase-T [ 27.420102] tn40xx: PHY type by svid 0 found 4 [ 30.530192] tn40xx: MV88X3310 initdata applied [ 30.534741] tn40xx: MV88X3310 I/D version is 0.3.4.0 [ 30.727831] tn40xx: fw 0xe [ 30.730552] tn40xx: eth0, Port A [ 30.733811] tn40xx: 1 1fc9:4027:1432:8104 [ 30.737845] tn40xx: detected 1 cards, 1 loaded [ 170.919776] tn40xx: eth0 Link Up 10G tn40xx.zip

I've already tested, it's working great.

@pocopico i finally compile tn40xx myself and it works [ 2273.598415] tn40xx: Tehuti Network Driver, 0.3.6.14.1 [ 2273.603509] tn40xx: Supported phys : MV88X3120 MV88X3310 [ 2273.609313] tn40xx 0000:01:00.0: enabling device (0000 -> 0002) [ 2273.615302] tn40xx: srom 0x0 HWver 16 build 0 lane# 4 max_pl 0x1 mrrs 0x2 [ 2273.834763] tn40xx: PHY detected on port 0 ID=2B09AB - MV88X3310 (A1) 10Gbps 10GBase-T [ 2273.842690] tn40xx: PHY type by svid 0 found 4 [ 2276.955878] tn40xx: MV88X3310 firmware code is running [ 2276.961112] tn40xx: MV88X3310 FW version is 0.2.8.0 [ 2277.154530] tn40xx: fw 0xe [ 2277.157252] tn40xx: eth1, Port A [ 2277.160496] tn40xx: 1 1fc9:4027:1432:8104 [ 2277.164519] tn40xx: detected 1 cards, 1 loaded Main problem was in sources. Only the oldest one (v0.3.6.14.1) supports vendor MV88X3310. All newer doesn`t [ 158.836678] tn40xx: Tehuti Network Driver, 0.3.6.17.2 [ 158.841745] tn40xx: Supported phys : QT2025 TLK10232 AQR105 MUSTANG I will try backport MV88X3310 to the latest sources because on 6.2.3 with extras it`s working 6.2.3 with extras [ 21.455402] tn40xx: Tehuti Network Driver, 0.3.6.17.2 [ 21.460489] tn40xx: Supported phys : MV88X3120 MV88X3310 MV88E2010 QT2025 TLK10232 AQR105 MUSTANG [ 21.469635] tn40xx: srom 0x0 HWver 16 build 0 lane# 4 max_pl 0x0 mrrs 0x2 [ 21.689198] tn40xx: PHY detected on port 0 ID=2B09AB - MV88X3310 (A1) 10Gbps 10GBase-T [ 21.697107] tn40xx: PHY type by svid 0 found 4 [ 24.948258] tn40xx: MV88X3310 initdata applied [ 24.952777] tn40xx: MV88X3310 I/D version is 0.3.4.0 [ 25.145958] tn40xx: fw 0xe [ 25.148678] tn40xx: eth0, Port A [ 25.151911] tn40xx: 1 1fc9:4027:1432:8104 [ 25.155919] tn40xx: detected 1 cards, 1 loaded [ 30.585590] tn40xx: eth0 Link Up 10G

@Orphée I completly missed the fact that the issue only takes place with pass through controllers...

Ok I catched why SataPortMap=1 did not work Actually I'm dumb... When you create a new VM By default the first disk is set as SCSI disk When you switch it to SATA, it automaticalty set it to SATA0:1 and of course if you set SataPortMap=1 with SATA0:1 value, disk is not detected... Setting it back to SATA0:0 make it works again. But still, always at first position disk 1

# fdisk -l Disk /dev/synoboot: 128 MiB, 134217728 bytes, 262144 sectors Disk model: TYPE D 3SE Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xf110ee87 Device Boot Start End Sectors Size Id Type /dev/synoboot1 2048 100351 98304 48M 83 Linux /dev/synoboot2 100352 253951 153600 75M 83 Linux /dev/synoboot3 253952 262143 8192 4M 83 Linux Disk /dev/sde: 232.9 GiB, 250059350016 bytes, 488397168 sectors Disk model: SSD 850 EVO 250GB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x9bcfbffa Device Boot Start End Sectors Size Id Type /dev/sde1 2048 4982527 4980480 2.4G fd Linux raid autodetect /dev/sde2 4982528 9176831 4194304 2G fd Linux raid autodetect /dev/sde3 9437184 488192351 478755168 228.3G fd Linux raid autodetect Same : DiskIdxMap=0F00 / SataPortMap=4 / SasIdxMap=0 I updated the ticket with my experiments : https://github.com/RedPill-TTG/redpill-lkm/issues/19#issuecomment-937615881

Yes, actually when your are telling SataPortMap=48 the system will keep 4 slots for controller 1 and 8 slots for controller 2 thus controller 2 attached drives will start from 5 like in your case. If you change that to SataPortMap=18 it will start from 2 and the first will be occupied by synoboot

Did you do a upgrade, or a build a new boot loader as your previous post shows you building with bromolow-7.0-41222 , yet this shows 7.0.1-42218 ?

@WiteWulf the last news I have for it: https://github.com/NeverEatYellowSwissSnow/synology-dsm-open-vm-tools/issues/3

Если этот диск будет у вас основным в новой Хрени, то лучше Миграция. Миграции не стоит бояться, данные сохранятся, а системный раздел пере пишется. Не забывайте про резерв настроек. Если воткнуть его к уже существующей системе, то запустится процесс инициализации с последующим форматированием. Если у вас два НАС_а, то проще перегнать данные по сети. Или воткнуть диск в Виндовый комп и так же перегнать данные по сети. Тут вам в помощь обычный Total Commander, либо другой, привычный файловый менеджер. Можно сделать полную синхронизацию одноимённых папок, тут вам в помощь GoodSync Enterprise, я использую эту программу

@wnbcТады тут у нашего комрада поищите...