Jump to content
XPEnology Community

RedPill - the new loader for 6.2.4 - Discussion


Recommended Posts

3 minutes ago, pocopico said:

 

I think its there ? would someone load tg3 on a system that can run 918 ? 

 

 

https://github.com/pocopico/rp-ext/blob/main/mptsas/rpext-index.json

 

What am I missing?  I only see the 42218 for the 3615.

 

 

"releases": {

"ds3615xs_25556": "https://raw.githubusercontent.com/pocopico/rp-ext/master/mptsas/releases/ds3615xs_25556.json",

"ds3615xs_41222": "https://raw.githubusercontent.com/pocopico/rp-ext/master/mptsas/releases/ds3615xs_41222.json",

"ds3615xs_42218": "https://raw.githubusercontent.com/pocopico/rp-ext/master/mptsas/releases/ds3615xs_42218.json",

"ds918p_41890": "https://raw.githubusercontent.com/pocopico/rp-ext/master/mptsas/releases/ds918p_41890.json",

"ds918p_25556": "https://raw.githubusercontent.com/pocopico/rp-ext/master/mptsas/releases/ds918p_25556.json"

}

}

Link to comment
Share on other sites

3 minutes ago, tcs said:

 

 

https://github.com/pocopico/rp-ext/blob/main/mptsas/rpext-index.json

 

What am I missing?  I only see the 42218 for the 3615.

 

 

"releases": {

"ds3615xs_25556": "https://raw.githubusercontent.com/pocopico/rp-ext/master/mptsas/releases/ds3615xs_25556.json",

"ds3615xs_41222": "https://raw.githubusercontent.com/pocopico/rp-ext/master/mptsas/releases/ds3615xs_41222.json",

"ds3615xs_42218": "https://raw.githubusercontent.com/pocopico/rp-ext/master/mptsas/releases/ds3615xs_42218.json",

"ds918p_41890": "https://raw.githubusercontent.com/pocopico/rp-ext/master/mptsas/releases/ds918p_41890.json",

"ds918p_25556": "https://raw.githubusercontent.com/pocopico/rp-ext/master/mptsas/releases/ds918p_25556.json"

}

}

done ! 

  • Like 1
Link to comment
Share on other sites

I need a help on synoinfo.conf file in /etc/ and /etc.defaults folder.

 

after editing and saving the synoinfo.conf file in both dir and reboot the files were back in originele version does anyone know how that come? i need to change some parts there for testing but got no luck because it restore back to originel file 🙄.

 

with jun loader its works perfect by the way. i dont know if synology checks after reboot the files or somehow they are not letting to edit the file.

 

i am editing them as root and it saves it also even after few hours it shows ok without rebooting but to apply changes i must reboot.

Link to comment
Share on other sites

14 hours ago, psychoboi32 said:

안녕하세요 여러분의 도움으로 @오르페 그리고 @만화창의 리포지토리 , @포코피코드라이버 Redpill 이미지를 제공하는 스크립트를 작성했습니다. VID/PID/Mac/일련 번호를 변경하십시오. 따라서

Linux VM에서 시도했습니다.
 

가이드:-

```nano takeredpill.sh```
스크립트 시작 부분에 PID/VID/MAC/SN을 추가하십시오.
```chmod +x takeredpill.sh```
```sh takeredpill.sh````

출력 폴더에 이미지가 있습니다
** 이것은 초기 단계입니다 오류가 발생할 수 있습니다. 걱정하지 마십시오.:)

테이크드필.sh없는

 

테이크드필.sh 2.04KB · 47 다운로드

make[1]: Leaving directory '/root/DS3615xs/bromolow/usr/local/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/sys-root/usr/lib/modules/DSM-7.0/build'
takeredpill.sh: 29: Syntax error: redirection unexpected
 

Hello

The above error occurs when running on ubuntu. Is there a solution?

Link to comment
Share on other sites

12 minutes ago, karius said:

make[1]: Leaving directory '/root/DS3615xs/bromolow/usr/local/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/sys-root/usr/lib/modules/DSM-7.0/build'
takeredpill.sh: 29: Syntax error: redirection unexpected
 

Hello

The above error occurs when running on ubuntu. Is there a solution?

sure how you are executing script? , you should

chmod +x *.sh && ./takeredpill.sh

please don't use sh takeredpill.sh

Edited by psychoboi32
Link to comment
Share on other sites

I have two physical machines, one is G4400 and the other is I3 7100t. Both models are 918 +, and the boot programs are the same. The hardware decoding, transcoding and face recognition of G4400 are normal, but 7100t are not normal (PS: ls / dev / dri can find ' renderd128'). After exchanging two CPUs, the situation is reversed.

Is it related to GPU? The device ID of g4400 GPU is 0x1902, and the device ID of I3 7100t GPU is 0x5912

The following is the error message of i915 when 7100t is started:

Quote

2021-10-07T22:00:11+08:00 DSM7 kernel: [   11.113221] i915 0000:00:02.0: Direct firmware load for i915/kbl_dmc_ver1_04.bin failed with error -2
2021-10-07T22:00:11+08:00 DSM7 kernel: [   11.113222] i915 0000:00:02.0: Falling back to user helper

 

  • Like 1
Link to comment
Share on other sites

So a quick up-not-to-date ;)

 

You guys are writing so many post and we're committed to reading all of them and responding where needed.

We promised to write something more last time but few of us had slightly unpredictable life events - given the fact we usually get together physically we encounter a small delay.

 

So, regarding the SAS issue: the sas-activator may be a flop. We tested it with SSDs and few spare HDDs which obviously weren't >2TB. It seems like the driver syno ships is ancient and while it does work it only runs using SAS2 (limit to 2TB is one of the symptoms). Don't we all love that ancient kernel? ;) Probably on systems with mpt3sas the situation isn't a problem.

 

As to the native SAS support and how it works: in short it's useless. The SAS support in syno is tied to just a few hardcoded models. Most of them support only external ports (via eboxes). Some, like in a few FS* products support internal ports. Unfortunately, this is completely useless as the OS checks for custom firmware, board names, responses etc. Is it possible to emulate that? Yes. Does it make sense? In our opinion not at all. With the community-provided drivers we can all be fully independent of the syno-provided .ko in the image. As the LKM supports SAS-to-SATA emulation for the purpose of syno APIs thinking it's a "SATA" device further investment into true SAS doesn't really make sense. To be clear here: there's no loss of functionality or anything. Many things in the kernel actually use the "SATA" type. It seems like syno intended it to be a true SATA but down the road changed it to really mean "a normal SCSI-based disk".


The reason why syno separates real SAS controllers is to offer .... hmm, a lot of hacks over their firmware and timing issues with LSI controllers. So in short emulating a true SAS type in syno will give us no benefits. Saying this we also, very cautiously, should probably make a recommendation: for anyone using a standard array of disks of 4-8 it's probably a better choice to go with a Marvell-based chip which works natively without drivers (and which syno uses as well). For bigger installations LSIs are still preferred (as they're cheap, work with low-cost used SAS drives, save on cabling etc etc).

 

===============================================

 

And now a massive response stream to all questions :)

 

 

On 10/3/2021 at 7:51 PM, pigr8 said:

 


Running "load-builtin-sas.sh" for thethorgroup.sas-activator->on_boot
Loading SAS controller(s) driver(s)
Loading LSI SAS 6Gb driver from /lib/modules/mpt2sas.ko
[    2.111757] mpt2sas version 20.00.00.00 loaded
[    2.117289] mpt2sas0: 32 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (2022888 kB)
[    2.191254] mpt2sas0: MSI-X vectors supported: 1, no of cores: 2, max_msix_vectors: -1
[    2.193247] mpt2sas 0000:0b:00.0: irq 73 for MSI/MSI-X
[    2.195245] mpt2sas0-msix0: PCI-MSI-X enabled: IRQ 73
[    2.195719] mpt2sas0: iomem(0x00000000fd3f0000), mapped(0xffffc90008180000), size(65536)
[    2.197125] mpt2sas0: ioport(0x0000000000005000), size(256)
[    2.308337] mpt2sas0: Allocated physical memory: size(4964 kB)
[    2.309771] mpt2sas0: Current Controller Queue Depth(3305), Max Controller Queue Depth(3432)
[    2.310989] mpt2sas0: Scatter Gather Elements per IO(128)
[    2.370223] mpt2sas0: LSISAS2008: FWVersion(16.00.00.00), ChipRevision(0x03), BiosVersion(00.00.00.00)
[    2.372036] mpt2sas0: Dell 6Gbps SAS HBA: Vendor(0x1000), Device(0x0072), SSVID(0x1028), SSDID(0x1F1C)
[    2.373611] mpt2sas0: Protocol=(Initiator,Target), Capabilities=(TLR,EEDP,Snapshot Buffer,Diag Trace Buffer,Task Set Full,NCQ)
[    2.376558] mpt2sas0: sending port enable !!
[    2.384638] mpt2sas0: host_add: handle(0x0001), sas_addr(0x590b11c027f7ff00), phys(8)
[    2.387142] mpt2sas0: detecting: handle(0x0009), sas_address(0x4433221100000000), phy(0)
[    2.388790] mpt2sas0: REPORT_LUNS: handle(0x0009), retries(0)
[    2.389874] mpt2sas0: TEST_UNIT_READY: handle(0x0009), lun(0)
[    2.396730] scsi 1:0:0:0: SATA: handle(0x0009), sas_addr(0x4433221100000000), phy(0), device_name(0x50014ee26320545e)
[    2.408946] mpt2sas0: detecting: handle(0x000b), sas_address(0x4433221101000000), phy(1)
[    2.410586] mpt2sas0: REPORT_LUNS: handle(0x000b), retries(0)
[    2.411748] mpt2sas0: TEST_UNIT_READY: handle(0x000b), lun(0)
[    2.422008] scsi 1:0:1:0: SATA: handle(0x000b), sas_addr(0x4433221101000000), phy(1), device_name(0x50014ee26320252f)
[   17.648369] mpt2sas0: detecting: handle(0x000a), sas_address(0x4433221102000000), phy(2)
[   17.651123] mpt2sas0: REPORT_LUNS: handle(0x000a), retries(0)
[   17.652856] mpt2sas0: TEST_UNIT_READY: handle(0x000a), lun(0)
[   17.662223] scsi 1:0:2:0: SATA: handle(0x000a), sas_addr(0x4433221102000000), phy(2), device_name(0x50014ee20ef68994)
[   32.723942] mpt2sas0: detecting: handle(0x000c), sas_address(0x4433221103000000), phy(3)
[   32.726898] mpt2sas0: REPORT_LUNS: handle(0x000c), retries(0)
[   32.728908] mpt2sas0: TEST_UNIT_READY: handle(0x000c), lun(0)
[   32.743439] scsi 1:0:3:0: SATA: handle(0x000c), sas_addr(0x4433221103000000), phy(3), device_name(0x50014ee20dcd759f)
[   47.822440] mpt2sas0: detecting: handle(0x000d), sas_address(0x4433221104000000), phy(4)
[   47.825418] mpt2sas0: REPORT_LUNS: handle(0x000d), retries(0)
[   47.833947] mpt2sas0: TEST_UNIT_READY: handle(0x000d), lun(0)
[   47.847305] scsi 1:0:4:0: SATA: handle(0x000d), sas_addr(0x4433221104000000), phy(4), device_name(0x50014ee2647a1448)
[   62.933161] mpt2sas0: detecting: handle(0x000e), sas_address(0x4433221105000000), phy(5)
[   62.936117] mpt2sas0: REPORT_LUNS: handle(0x000e), retries(0)
[   62.938119] mpt2sas0: TEST_UNIT_READY: handle(0x000e), lun(0)
[   62.947998] scsi 1:0:5:0: SATA: handle(0x000e), sas_addr(0x4433221105000000), phy(5), device_name(0x5000c5008c5e912d)
[   78.018894] mpt2sas0: detecting: handle(0x000f), sas_address(0x4433221106000000), phy(6)
[   78.028297] mpt2sas0: REPORT_LUNS: handle(0x000f), retries(0)
[   78.030129] mpt2sas0: TEST_UNIT_READY: handle(0x000f), lun(0)
[   78.039803] scsi 1:0:6:0: SATA: handle(0x000f), sas_addr(0x4433221106000000), phy(6), device_name(0x5002538e49b3b3ca)
[   93.110287] mpt2sas0: port enable: SUCCESS

 

i can confirm that it works now with the stock v20.0 mpt2sas.ko from DSM v7.0.1, no need for the custom .ko from @pocopico , all drivers (7 in my case) show up as /dev/sd* and DSM wants to install itself (did not try to proceed but i guess it works).

still persist the problem that if the loader is on sata0:0 it reserves /dev/sda, so the first disk connected to the LSI shows up as /dev/sdb.

That pesky /dev/sda may actually be a bug in the syno kernel. According to the IdxMap it should NOT present itself at the first spot grrr... we set it to map controller 1 to like 20 and it still used the first disk (and only the first) at /dev/sda. There may be a way to use remap of ports (another feature which syno uses extensively on their boards) to move it. It would actually explain why syno uses a long string of remaps (comically long, like 30-entries-long) instead of a map on some of their boards... as map seems to not work properly. We will play with it. Can you create an issue in the redpill-lkm repo, so we don't lose track of that?
It may also be a problem with magic index shifting... it looks like Jun's loader may have been fixing a bug in syno's remap code.

 

 

On 10/3/2021 at 7:56 PM, pigr8 said:

another minor issue using the sas-activator and stock v20.0 driver is that on bootup it's slow to load the drivers, for each one the serial spams this (example on the first port detection, seen as /dev/sdb on redpill but as /dev/sda on jun's loader):

 


[    2.339686] scsi 1:0:1:0: Direct-Access     WDC      WD30EFRX-68EUZN0         0A82 PQ: 0 ANSI: 6
[    2.341594] sd 1:0:0:0: [sdb] Write Protect is off
[    2.341789] scsi 1:0:1:0: SATA: handle(0x000b), sas_addr(0x4433221101000000), phy(1), device_name(0x50014ee26320252f)
[    2.341791] scsi 1:0:1:0: SATA: enclosure_logical_id(0x590b11c027f7ff00), slot(2)
[    2.341866] scsi 1:0:1:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[    2.342130] scsi 1:0:1:0: serial_number(     WD-WCC4N0LDREV8)
[    2.342133] scsi 1:0:1:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[    2.347292] want_idx 1 index 2. delay and reget
[    2.351539] sd 1:0:0:0: [sdb] Mode Sense: 7f 00 10 08
[    2.352633] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
[    2.357909]  sdb: sdb1 sdb2 sdb5
[    2.365253] sd 1:0:0:0: [sdb] Attached SCSI disk
[    3.346388] want_idx 1 index 2
[    3.347047] want_idx 1 index 2. delay and reget
[    4.349242] want_idx 1 index 2
[    4.350358] want_idx 1 index 2. delay and reget
[    5.352080] want_idx 1 index 2
[    5.352188] want_idx 1 index 2. delay and reget
[    6.354932] want_idx 1 index 2
[    6.356676] want_idx 1 index 2. delay and reget
[    7.359783] want_idx 1 index 2
[    7.359895] want_idx 1 index 2. delay and reget
[    8.361635] want_idx 1 index 2
[    8.361747] want_idx 1 index 2. delay and reget
[    9.364484] want_idx 1 index 2
[    9.366152] want_idx 1 index 2. delay and reget
[   10.369338] want_idx 1 index 2
[   10.369958] want_idx 1 index 2. delay and reget
[   11.371201] want_idx 1 index 2
[   11.371841] want_idx 1 index 2. delay and reget
[   12.374042] want_idx 1 index 2
[   12.374712] want_idx 1 index 2. delay and reget
[   13.376895] want_idx 1 index 2
[   13.377569] want_idx 1 index 2. delay and reget
[   14.537123] want_idx 1 index 2
[   14.538402] want_idx 1 index 2. delay and reget
[   15.540697] want_idx 1 index 2
[   15.541951] want_idx 1 index 2. delay and reget
[   16.544593] want_idx 1 index 2
[   16.545475] want_idx 1 index 2. delay and reget
[   17.547442] want_idx 1 index 2

 

edit 1: with @pocopico .ko it does not do that.

 

edit 2: another problem could be that with either stock mpt2sas.ko or the compiled one, disks larger than a 2tb wont show up as they should.

 

- disk 1 on lsi port 1, fdisk (/dev/sda with jun's loader)

 


Disk /dev/sda: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 337DF73B-5685-46E1-9DA5-2960BA2BA3C8

Device       Start        End    Sectors  Size Type
/dev/sda1     2048    4982527    4980480  2.4G Linux RAID
/dev/sda2  4982528    9176831    4194304    2G Linux RAID
/dev/sda5  9453280 5860326239 5850872960  2.7T Linux RAID

 

- same disk 1 on lsi port 1, fdisk (/dev/sdb on redpill)

 


Disk /dev/sdb: 2048 GB, 2199023255040 bytes, 4294967295 sectors
267349 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sdb1    0,0,1       1023,254,63          1 4294967295 4294967295 2047G ee EFI GPT
fdisk: device has more than 2^32 sectors, can't use all of them

 

Yup... exactly the problem as described at the beginning of the post. It was too easy to simply load their drivers. This lead us to write that summary on the top - it looks like anyone dependent on the LSI card will need to use a 3rd-party driver as the syno one is ancient and only uses SAS2 (and thus the limit).

 

 

On 10/3/2021 at 8:22 PM, Orphée said:

@ThorGroup Regardiing Surveillance Station licences there is an online registering when you add your bought licence inside the app.

As online Synology services require real SN/Mac pair to work, you must have them real in order to buy/add new camera licence.

If I'm not mistaken, you even can "unregister"/"register" your bought licences from old NAS when you switch to a new one.

 

There is en offline procedure too if I remember correctly.

https://www.synology.com/en-global/products/Device_License_Pack

 

https://kb.synology.com/en-global/Surveillance/tutorial/Can_I_install_or_delete_surveillance_device_licenses_offline

 

Edit : As SS works with its default  2 licences with generated SN on your current loaders.

I bet we would have the 8 default licences on DVA even with generated SN.

Real question is about AI features (like HW transcoding on DS918+ without real SN not working without a patch)

https://github.com/likeadoc/synocodectool-patch

For us, to be honest, the main drive towards DVA are the native nVidia drivers. While they surely can be installed on other DS it would be just simply easier to install them from the pkg manager and call it a day. As for the surveillance station stuff (and photo station and similar) patching binaries isn't that good of an approach. This is because they're checksumed. Maybe not these but others are. In general changing any of the signed syno files in the OS is a slippery slope - it's better to make sure the OS thinks it's a real motherboard rather than modify the system to not check something. The more things we can emulate in the kernel the better as updates are unlikely to break them (as they would break real hardware as well).

 

 

On 10/3/2021 at 9:21 PM, T-REX-XP said:

@ThorGroup, Here is a few things regarding the FAn control with PMU

 

 

I've tested the following way to set speed of the CPU FAN on 6.2.3

 


insmod hwmon-vid.ko
insmod nct6775.ko

optional install sensors(lm-sensors) via ipkg

 

Then the fan speed can be set like this:
 


#default value

echo 5 > /sys/devices/platform/nct6775.656/hwmon/hwmon1/pwm2_enable

 

Here is a few userful commands:


#find all pwm:

find /sys/devices -type f -name "pwm*"

#find beep

/sys/devices/platform/nct6775.656/hwmon/hwmon1/beep_enable

#enable /disable beep

echo 0 > /sys/devices/platform/nct6775.656/hwmon/hwmon1/beep_enable | sensors | grep beep

 

 

So, the vPMU can use it for manipulating the CPU FAN speed.

 

But we need to resolve the following issues:

- build nct6775 for dsm 7.0 (I now that this module is one of the many modules for different IO chips on motherboard), let's start from it, then add an additional one

- build pcspeaker module

- implement vPMU to use software methods for manipulating the FAN speed

 

@pocopico, could you please build nct6775 module for 918 dsm 7.0 ?? Thanks.

 

I will prepare the RP extension for that module

 

Thanks in advance.

 

 

 

 

See, the issue is while we can surely control a fan from PMU it's completely different on every motherboard. Like they never did put any standards in - guys from lm-sensors are pulling their hairs out to handle all that. We don't have a good idea just yet how to make this good so that everyone can just define their way of controlling the fans but this is something we have on the list as "todo" (albeit low priority as usually people just set their CPU and case fans from the bios, with newer motherboards you can even upload/set fan curves in the BIOS/UEFI itself).

 

 

On 10/3/2021 at 9:45 PM, pigr8 said:

 

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

Yes we do (even if slowly!) ;)

GH is much easier to deal with simply because we can split multiple problems into "buckets" and easily ping people with that particular problem. Forum isn't really a good tool for that (but fantastic for a general discussion and support questions!).

 

 

On 10/3/2021 at 10:39 PM, Schyzo said:

Tried to add modules from @pocopico(bnx2x and bnx2) with OSFMount after image was created, but no success, no network 😕

We have to include modules (*.ko) BEFORE image is created ?

.ko can be included using RP extension. You can find examples and documentation in the redpill-load repo. It will simply load .ko you list automatically. Built-in card in gen8 should work with these drivers.

 

On 10/3/2021 at 11:59 PM, luckcolors said:

Hello @ThorGroup

I'm trying to run redpill for 6.2.3-25556 on proxmox.

Thank you for your work so far, the virtio network drivers are working perfectly and i've been able to connect to the DSM. :D

 

I was wondering if it's not yet supported using the virtio block/virtio SCSI drivers for speeding up disk access.

I suppose sata emulation would be fine for normal HDDs but for running an Nvme SSD cache it's going to be a bottleneck.

 

I know it's definetely not a must-be-done-now kinda issue for the beta release but would it be possible to add support for these kind of virtual drives?

There's two different virtio implementation that can be used:

  •  Virtio Block (1 pcie address per device)
  •  Virtio SCSI (1 pcie address per controller, many devices per controller)

The virtio SCSI one seems the most interesting since it claims "Standard device naming". Documentation: https://www.ovirt.org/develop/release-management/features/storage/virtio-scsi.html

 

If you think this is better reported in the virtio git issues. I'll move it there.

 

Edit 1:

Forgot to add:

They are not detected at all during the install wizard, i'm going to do more testing to confirm they aren't detected at all awell in pool creation.

 

Edit 2:

Well i was completely wrong DSM seems to detect them both at setup time and later.

It even updates the disks listing in realtime matching what i add or remove from proxmox.

I'm going to go touch grass now.

Earlier it wasn't doing either so i guess i had the wrong chipset? (current i440fx).

Edit 3:
The chipset wasn't it.
It's working aswell with Q35 now and the diskmap is shifted as others pointed out.

I guess the problem solved itself or i was doing something wrong

I'm pretty sure earlier thought that i did run the VM multiple times with atleast one disk attached via virtio SCSI and the setup page complained that there where no disks available (i'm currently testing with 32GB virtual drives).

On any case. Thanks again for your work. :D

To give you more context for the "SATA" thing: it's stupid. It looks like a huge legacy part in the syno code. As we wrote above "SATA" is used in the syno kernel additions as kind of "anything SCSI-based which is not a USB drive, not iSCSI and not cache-NVMe". There's no performance penalty or anything. In face they themselves treat VirtIO as "SATA". Ultimately, the kernel doesn't care about their types at all. These are only there to guide the OS what to do and not do with these drives (e.g. don't make swap partition or create OS partitions on iSCSI). It's like with VirtIO ethernet driver: DSM will show a warning that the network is 10/100Mb [as it sees it as "unknown"] but will happily push gigabits of traffic through it.

 

As for the general advice if you use QEmu-based systems use Q35 unless you have a good damn reason for older chipset (e.g. Windows 98 VM or something along these lines). They keep the i440fx as the default as it's most compatible but in general Q35 is the one you should use for any modern OSes.

As for NVMe SSD: these are well... PCI-Ex devices. They go through a slightly different pathway. But again: kernel doesn't care really. There are mods for the OS to see non-syno drives as valid SSD cache. However, with some kernel tweaks we can probably get rid of these modifications (hint: if there isn't a GH ticker it will be appreciate in the redpill-lkm repository, so we have this on our radar).

 

 

On 10/4/2021 at 12:18 AM, urundai said:

quick question: Per the loader documentation, one can remove vid and pid if they are using SATA based boot. Unfortunately, when I do that, my build fails with 'unbound parameter extra_cmdline('vid')'. 

 

For now, I am still leaving vid/pid in there for my esxi but not sure why the build fails. Any thoughts?

pinging @haydibe here. The loader itself doesn't care [now] but probably the container config has some assumption somewhere. You can leave them, you can even set them to DEAD and BEEF - it will not cause any problems but a warning message during boot ;) When they're set but not needed they're only validated to the point of "is this a hex number".

 

 

On 10/4/2021 at 2:08 AM, pigr8 said:

 

try not to add either sas-activator nor pocopico extension, add this in user config and rebuild redpill again and report the attempt :)

 


  "synoinfo": {
    "supportsas": "yes"
  },

 

 

[note to ANYONE doing supportsas=yes]

You shouldn't really do that. This activates syno-specific SAS support which will break a lot of things. This flag is horribly misleading and used in aaaaa looot of syno code. This is way more than just loading the driver. This is more of a "activate our hacks for broken LSI firmware we flashed ... and do these totally not-SAS things on this controller ... and when you are at that can you maybe also tell the controller to take over controlling some of the leds ... oh, and load the driver".
So folks, really, don't touch that option with a long pole - it's a trap. It would only be useful if full ebox emulation was present.

 

 

On 10/4/2021 at 5:26 PM, 0ne1astK155 said:

 

Can you apply a Github repo to update your script? Thx!

We're working with haydibe on integrating the container build into the redpill-repo itself :)
It just spun as a very cool project in this thread and it turns out it's actually great.

 

 

On 10/4/2021 at 5:28 PM, Rebutia said:

Hi WiteWulf, just a quick question, is it because of the change in DSM6/7 that we can no longer see console booting message like what we did in the DSM5 xpenology loader? No I am not urging anybody to include this nostalgic function, just curious, and it also seems to be easier for debugging.

Adding to what WiteWulf said here: yes, it's because of the kernel changes in ~v6.

From the Linux perspective it doesn't care where messages are sent - every printk() goes to /dev/console. Something has to actually handle the /dev/console however. This needs a driver. To see messages on the screen you need to have some sort of framebuffer/vga-like driver. By default every desktop distro will obviously include vga driver in the kernel, but in embedded systems it's rare to include it. Syno simply stripped it from the kernel build. GRUB renders the text and passes control to the kernel and kernel decides to not reset the screen nor display anything on it. It's as simple as that, that's why what GRUB leaves never disappears from the screen ;)

We didn't try but probably if you use nV GPU for boot and then load nV drivers for transcoding the screen may turn simply black (or perhaps even disable the connected display?).

 

 

On 10/4/2021 at 9:35 PM, nemesis122 said:

I have try a lot of loaders on my server builds with different loaders here is my experience:

DSM 918+ Pro: has Kernel 4.4 und with the correct config you have hardware decoding. cons: with VMM you cant install/ load other loaders 1.02b 1.03b or 1.04b there is no lan connection i dont know why i tried everyting with linux ubuntu or windows all is ok.

 

DSM 3615+ : pro is the most stable loader VMM works great also with loader 1.02b and 1.03 and 1.04 for virtualmaschines con: with 10Gbit you have only 500 MB read and write

DSM3617+ : pro this loader is very fast in DSM /it has the most read and write 10 gbit 700 - 800 Mb with raid 0 and 5 HDD and 1 SSD and VMM works great the same as 3615 but all is running super fast and smooth .

 

I have tested this loaders on gen8 with CPU 1240v2 1230v2 original Xeon and on a  ASUS87iplus MB i hate this f**** Bios but with the 3617 loader MBR i have now installed my favorite system 3617xs 😍 

 

So in short the best Loader at the moment is for me 1.03b with 3617 DSM 6.2 my config is always volume1 SSD for plex libary/ virtual Maschines / and and all apps / volume2 5x6tb is for the data.

 

 

918+ is out of question for 1240v2 as it doesn't have MOVBE instruction and 4.4 as built by syno requires it. Even if it "boots" things will start randomly crashing. The 3615 speed shouldn't be limited by the platform itself. With such speeds you may need to tweak kernel networking but this is honestly the same on syno as for any other Linux box.
We want to add 3617 but that hotplug issue is that annoying showstopper. As we were busy we didn't debug it much beyond what's said on GH. It's probably something stupidly small...

 

 

On 10/5/2021 at 12:50 AM, Schyzo said:

@OrphéeGod, it's seem more difficult than Proxmox ^^

Once the image created, I had tg3.ko in i386-pc and in x86_64-efi with OSFMount. Edited the grub.cfg with add "insmod tg3.ko" under "insmod gzio"

Save and copy the image.

But same problem, no network on the Proliant. I don't know what to do now. Maybe look Proxmox tutorial ? 😢 :D

 

Edit : Trying with add libphy before t3g, testing in progress :)

Result : Same problem, no network 😢

It's more difficult because you're editing the image and making changes which will explode in the future. There's a reason why we automated that hard stuff into extensions ;)

 

 

On 10/5/2021 at 2:01 AM, Mixpower said:

I am trying to find out what is going wrong, so I'm using VSP on my Gen8 to check the output.

It says at the beginning that com0 can not be found is this a problem?


[    2.256293] <redpill/runtime_config.c:187> Found platform definition for "DS3615xs"
[    2.258820] <redpill/runtime_config.c:198> Validating runtime config...
[    2.261028] <redpill/runtime_config.c:48> Configured boot device type to USB
[    2.263364] <redpill/runtime_config.c:207> Config validation resulted in OK
[    2.265755] <redpill/runtime_config.c:224> Runtime config populated
[    2.267810] <redpill/uart_fixer.c:72> Registering UART fixer shim
[    2.270015] <redpill/uart_swapper.c:410> Swapping ttyS1<=>ttyS0 started
[    2.272211] <redpill/override_symbol.c:257> Overriding uart_match_port() with uart_match_port_collector [redpill]()<ffffffffa0004290>
[    2.273728] <redpill/override_symbol.c:172> Saved uart_match_port() ptr <ffffffff813101d0>
[    2.273730] <redpill/memory_helper.c:18> Disabling memory protection for page(s) at ffffffff813101d0+12/1 (<<ffffffff81310000)
[    2.273859] <redpill/call_protected.c:84> Got addr ffffffff810303e0 for flush_tlb_all
[    2.273874] <redpill/override_sol.c:221> Obtaining lock for <uart_match_port+0x0/0x70/ffffffff813101d0>
[    2.273874] <redpill/override_symbol.c:182> Generating trampoline
[    2.273879] <redpill/override_symbol.c:188> Generated trampoline to uart_match_port_collector+0x0/0x60 [redpill]<ffffffffa0004290> for uart_match_port<ffffffff813101d0>:
[    2.273880] <redpill/override_symbol.c:221> Writing trampoline code to <ffffffff813101d0>
[    2.273880] <redpill/override_symbol.c:221> Released lock for <ffffffff813101d0>
[    2.273881] <redpill/memory_helper.c:34> Enabling memory protection for page(s) at ffffffff813101d0+12/1 (<<ffffffff81310000)
[    2.273893] <redpill/override_symbol.c:269> Successfully overrode uart_match_port() with trampoline to uart_match_port_collector+0x0/0x60 [redpill]<ffffffffa0004290>
[    2.275464] <redpill/call_protected.c:108> Got addr ffffffff813168b0 for serial8250_find_port
[    2.275465] <redpill/uart_swapper.c:113> Found ptr to line=0 iobase=0x2f8 irq=3
[    2.275466] <redpill/uart_swapper.c:113> Found ptr to line=1 iobase=0x3f8 irq=4
[    2.275467] <redpill/uart_swapper.c:113> Found ptr to line=2 iobase=0x3e8 irq=4
[    2.275467] <redpill/uart_swapper.c:113> Found ptr to line=3 iobase=0x2e8 irq=3
[    2.275468] <redpill/override_symbol.c:279> Restoring uart_match_port<ffffffff813101d0> to original code
[    2.275469] <redpill/memory_helper.c:18> Disabling memory protection for page(s) at ffffffff813101d0+12/1 (<<ffffffff81310000)
[    2.275479] <redpill/override_symbol.c:250> Obtaining lock for <uart_match_port+0x0/0x70/ffffffff813101d0>
[    2.275480] <redpill/override_symbol.c:250> Writing original code to <ffffffff813101d0>
[    2.275480] <redpill/override_symbol.c:250> Released lock for <ffffffff813101d0>
[    2.275481] <redpill/memory_helper.c:34> Enabling memory protection for page(s) at ffffffff813101d0+12/1 (<<ffffffff81310000)
[    2.275489] <redpill/override_symbol.c:287> Successfully restored original code of uart_match_port
[    2.275490] <redpill/override_symbol.c:145> FreeingS for uart_match_port
[    2.550824] <redpill/uart_swapper.c:425> Disabling preempt & locking console
[    2.553179] <redpill/uart_swapper.c:427> ======= OUTPUT ON THIS PORT WILL STOP AND CONTINUE ON ANOTHER ONE (swapping ttyS1 & ttyS0) =======
[    2.557453] <redpill/uart_swapper.c:429> ### LAST MESSAGE BEFORE SWAP ON "OLD" PORT ttyS1<=>ttyS0

 

Also the output stops right here is there anything I can change about that?

Any help would be appreciated!

Don't you have COMs inverted in the RBSU? :D
Gen8 is such an amazing server but iLO... iLO was written past the Bellmer's curve (e.g. to enable PCI-passthrough you need RMRR hacks because HP decided to mess with it against the ACPI specs).

 

 

On 10/5/2021 at 3:58 AM, Mixpower said:

Thanks, I used that indeed!

I tried that and put it on com1 but when I ssh into iLO using putty and type VSP it always connects on com2 even when I disable VSP it still does that.

 

EDIT: Just found there is another setting in the BIOS for the port and now it works on com1! Looks like there is something wrong with my vid/pid settings I'll dig into it and report back.

 

EDIT2: It just does this over and over and over, tried different usb ports but it does not matter it keeps doing this, I checked the VID and PID again and there are correct anyone has a clue?

 


:: Mounting procfs ... [  OK  ]
:: Mounting tmpfs ... [  OK  ]
:: Mounting devtmpfs ... [FAILED]
:: Mounting devpts ... [  OK  ]
:: Mounting sysfs ... [  OK  ]
[   10.647880]  sdu: sdu1 sdu2 sdu3
[   10.667520] sd 7:0:0:0: [sdu] No Caching mode page found
:: Loading modul[   10.693251] sd 7:0:0:0: [sdu] Assuming drive cache: write through
e sg[   10.723056] sd 7:0:0:0: [sdu] Attached SCSI disk
[   15.738964] usb 3-1: USB disconnect, device number 2
[   17.968475] usb 3-1: new full-speed USB device number 3 using uhci_hcd
[   18.156068] Got empty serial number. Generate serial number from product.
[   18.195263] <redpill/usb_boot_shim.c:75> Found new device <vid=03f0, pid=7029> - didn't match expected <vid=26bd, pid=9917> (prev_shimmed=1)
[   27.752685] usb 3-1: USB disconnect, device number 3
[   29.982199] usb 3-1: new full-speed USB device number 4 using uhci_hcd
[   30.170009] Got empty serial number. Generate serial number from product.
[   30.209179] <redpill/usb_boot_shim.c:75> Found new device <vid=03f0, pid=7029> - didn't match expected <vid=26bd, pid=9917> (prev_shimmed=1)
[   39.766411] usb 3-1: USB disconnect, device number 4
[   41.995925] usb 3-1: new full-speed USB device number 5 using uhci_hcd
[   42.183925] Got empty serial number. Generate serial number from product.
[   42.223078] <redpill/usb_boot_shim.c:75> Found new device <vid=03f0, pid=7029> - didn't match expected <vid=26bd, pid=9917> (prev_shimmed=1)
[   51.780135] usb 3-1: USB disconnect, device number 5
[   54.009649] usb 3-1: new full-speed USB device number 6 using uhci_hcd
[   54.197887] Got empty serial number. Generate serial number from product.
[   54.236997] <redpill/usb_boot_shim.c:75> Found new device <vid=03f0, pid=7029> - didn't match expected <vid=26bd, pid=9917> (prev_shimmed=1)
[   63.793860] usb 3-1: USB disconnect, device number 6
[   66.023374] usb 3-1: new full-speed USB device number 7 using uhci_hcd
[   66.210735] Got empty serial number. Generate serial number from product.
[   66.250919] <redpill/usb_boot_shim.c:75> Found new device <vid=03f0, pid=7029> - didn't match expected <vid=26bd, pid=9917> (prev_shimmed=1)
[   75.807584] usb 3-1: USB disconnect, device number 7
[   78.037099] usb 3-1: new full-speed USB device number 8 using uhci_hcd
[   78.225662] Got empty serial number. Generate serial number from product.
[   78.264836] <redpill/usb_boot_shim.c:75> Found new device <vid=03f0, pid=7029> - didn't match expected <vid=26bd, pid=9917> (prev_shimmed=1)
[   87.821310] usb 3-1: USB disconnect, device number 8

 

If I unplug the usbdrive and plug it back in it does this but then goes back to the same again.


[  198.784282] usb-storage 1-1.5:1.0: USB Mass Storage device detected
[  198.815397] scsi8 : usb-storage 1-1.5:1.0
[  198.835055] <redpill/usb_boot_shim.c:91> Device <vid=26bd, pid=9917> shimmed to <vid=f400, pid=f400>
[  199.910770] scsi 8:0:0:0: Direct-Access              USB DISK 2.0             PMAP PQ: 0 ANSI: 6
[  199.954664] <redpill/scsi_notifier.c:65> Probing SCSI device using sd_probe_shim
[  199.990468] <redpill/scsi_notifier.c:77> Triggering SCSI_EVT_DEV_PROBING notifications
[  200.028866] <redpill/scsi_notifier.c:87> Calling original sd_probe()
[  200.060103] <redpill/scsi_notifier.c:91> Triggering SCSI_EVT_DEV_PROBED notifications - sd_probe() exit=0
[  200.962090] sd 8:0:0:0: [synoboot] 15654912 512-byte logical blocks: (8.01 GB/7.46 GiB)
[  201.002757] sd 8:0:0:0: [synoboot] Write Protect is off
[  201.028251] sd 8:0:0:0: [synoboot] Mode Sense: 23 00 00 00
[  201.058571] sd 8:0:0:0: [synoboot] No Caching mode page found
[  201.087422] sd 8:0:0:0: [synoboot] Assuming drive cache: write through
[  201.123769] sd 8:0:0:0: [synoboot] No Caching mode page found
[  201.151792] sd 8:0:0:0: [synoboot] Assuming drive cache: write through
[  201.206746]  synoboot: synoboot1 synoboot2 synoboot3
[  201.234149] sd 8:0:0:0: [synoboot] No Caching mode page found
[  201.262376] sd 8:0:0:0: [synoboot] Assuming drive cache: write through
[  201.294711] sd 8:0:0:0: [synoboot] Attached SCSI removable disk
[  207.958562] usb 3-1: USB disconnect, device number 18
[  210.188074] usb 3-1: new full-speed USB device number 19 using uhci_hcd
[  210.376874] Got empty serial number. Generate serial number from product.
[  210.415992] <redpill/usb_boot_shim.c:75> Found new device <vid=03f0, pid=7029> - didn't match expected <vid=26bd, pid=9917> (prev_shimmed=1)

 

If it detects synoboot it's all good and it means it detected the stick properly. In other words your vid/pid combo is correct.

 

 

On 10/5/2021 at 1:32 PM, Tango38317 said:

HI,

this days i have created a test nas V7.0.1-42218 (DS918+)

VM on  Proxmox, V7.0-11

Boot from USB with args.

Machine Q35

CPU: KVM

UEFI Boot

Virtio NW 

Virtio SCSI

Build and boot are successfull with one disk (Disk id 8? with 4 slots?)

i tried to add a second disk and add it to the SHR Volume for testing. But i cannot add this disk, because it does not meet the requirements (screenshot attached).

 

i tried to change from VirtiO SCSI to Virtio SCSI-Single. Does not change the issue, but i observed one thing:

 

When starting Vm with VirtIO SCSI and 2 Disk i see following messages in serial console, but not after changing to VirtIO SCSI Single.


[    5.533294] sd 7:0:0:0: [synoboot] Attached SCSI disk
[    6.271152] want_idx 6 index 7
[    6.271551] want_idx 6 index 7. delay and reget
[    7.272150] want_idx 6 index 7
[    7.272549] want_idx 6 index 7. delay and reget
[    8.273154] want_idx 6 index 7
[    8.273567] want_idx 6 index 7. delay and reget
[    9.274128] want_idx 6 index 7
[    9.274574] want_idx 6 index 7. delay and reget
[   10.275084] want_idx 6 index 7
[   10.275584] want_idx 6 index 7. delay and reget
[   11.276094] want_idx 6 index 7
[   11.276645] want_idx 6 index 7. delay and reget
[   12.277102] want_idx 6 index 7
[   12.277644] want_idx 6 index 7. delay and reget
[   13.278149] want_idx 6 index 7
[   13.278689] want_idx 6 index 7. delay and reget
[   14.279161] want_idx 6 index 7
[   14.279705] want_idx 6 index 7. delay and reget
[   15.280132] want_idx 6 index 7
[   15.280661] want_idx 6 index 7. delay and reget
[   16.281095] want_idx 6 index 7
[   16.281579] want_idx 6 index 7. delay and reget

 

is this a known behavior, or is there maybe some solution for this issue?

br

Chris

 

requirements.PNG

HDD Info.PNG

This is something new with these want_idx. Can you add it as an issue in the redpill-lkm repo? In general you shouldn't use the VirtIO SCSI Single.

 

 

On 10/5/2021 at 7:01 PM, Orphée said:

I'm playing with DS918+ loader 6.2.4 on VMWare Workstation.

 

It works, I installed Moments to check face detection...

 

Do you know what it means ? :

 

 

This is a completely different issue related to security checks in the DSM photo itself. If you google search within xpenology.com you will find many mentions and discussion on patching that in the system. In short: a real S/N is needed to make validation happy without DSM patching.

 

 

On 10/5/2021 at 11:06 PM, Orphée said:

For those who might use VMWare Workstation to do some tests.

 

Serial console from TCPIP is not available from GUI, and not officially supported.

 

But you can edit your .vmx file to add :

 


serial0.present = "TRUE"
serial0.fileType = "network"
serial0.fileName = "0.0.0.0:10021"
serial0.network.endPoint = "server"
serial0.startConnected = "TRUE"

 

10021 or whatever suits you.

 

Then you can telnet to the serial port as usual.

Wait... are you saying this doesn't require the paid license but just a config edit?!
Also: there's a new bash tool in the loader repo called "always-telnet" - you may find it useful with working with VMWare serial ports.
 

 

On 10/6/2021 at 12:03 AM, WiteWulf said:

Oh my word, that was ridiculously quick and easy! That's gonna make testing new images a whole lot simpler. I've now got a virtual 918+ running in VMware Fusion on my iMac :D

 

*edit* Wow, I've got to get my Gen8 migrated to ESXi, it's *so* much quicker to reboot, if nothing else!

Migrate it to Proxmox, it will be way less problematic,join the dark side ;]

ESXi + gen8 is an issue in a lot of places. VMWare dropped support for newer versions, there are weird memory leaks in newer versions etc. It's REALLY not a good platform for ESXi (not that we're biased against ESXi in general but that's another story ;)).

...if only Gen8 had 32GB RAM support. Oh, wait, it can support it but Intel forced HP to disable it.

 

 

On 10/6/2021 at 4:25 AM, DaveD said:

I am currently running an HP Gen8 Microserver 16gb memory and E3-1265L V2 currently running as a baremetal XPenology server with Plex Server as the only app curently installed so is bare metal - ESXi or Proxmox the way I should be looking to go now with the new loader and V7 + versions as I seem to remember someone on here saying Proxmox was the way to go now ?

We use and recommend Proxmox [not just for RP] - open source, not limited in features, fast, supported and doesn't cut out hardware. The only problem on gen8 is PCI-Ex passthru due to RMRR but if you search on GitHub there are patches.

 

 

On 10/6/2021 at 4:27 AM, Orphée said:

Just a tip about proxmox with HP Gen8 :

If you plan to use it with HBA passthrough, forget it, a bug make it impossible.

Whereas it works on ESXi.

 

The current patch does not work with Proxmox 7

https://github.com/kiler129/relax-intel-rmrr

 

Edit : maybe an option here :

https://github.com/crankswagon/relax-intel-rmrr

Exactly that patch - we use this ourselves for long time and it's rock stable. ESXi does essentially the same thing - just ignore bogus RMRR from HP.

 

 

On 10/6/2021 at 4:19 PM, XAXISNL said:

 

As long as there is no powerbutton module, I have used a workaround in Proxmox by using hookscripts.

When shutting down the VM from Proxmox, at the 'pre-stop phase' it SSH's into DSM and issues the 'shutdown now' command.

 


elsif ($phase eq 'pre-stop') {

    # Third phase 'pre-stop' will be executed before stopping the guest
    # via the API. Will not be executed if the guest is stopped from
    # within e.g., with a 'poweroff'

    print "$vmid will be stopped.\n";
    print "Shutting down DSM\n";
    system("ssh -T USERNAME\@xx\.xx\.xx\.xx 'sudo shutdown now'");

 

Works great!

Ok, you surprised us here! Never heard of that before.

However, we need to check how full vmtools do that.

 

 

On 10/6/2021 at 4:39 PM, WiteWulf said:

Yeah, we need to ideally wait for TTG to support 7.0.1, or as a bodge, for Jumkey to update their repo to support extensions.

In the [red hot] queue. At this point, as many people tested it, we can just merge it but we really want to look at the kernel in a disassembler and see if nothing changed and the automatic path is correct. We try to make sure what we publish is well tested ;)

 

 

On 10/6/2021 at 5:53 PM, Orphée said:

If you mean "stuck with DS3615xs loader because of missing CPU feature", yes, it seems ! 😅

Sadly Intel artificially limited that with efuses... like ECC on i5 and i7 and many other things.

 

 

On 10/6/2021 at 6:01 PM, abesus said:

I already have locally updated sources for 918+ v 7.0.1 with support for extensions. The problem is, that TTG's extensions also needs to be updated to support 7.0.1 or someone has to fork them and modify...

 

edit: so I've decided to wait for official support for 7.0.1. Until that I will stay on my current 7.0.1. Good for me that it is stable :)

Extensions itself don't depend on the software version per-se. You can make an extension compatible with yet-unreleased version as during installation we query for the version which is being built and we don't care where the extension or version is coming from. The power of open-source.

 

 

On 10/6/2021 at 8:35 PM, WiteWulf said:

I assume they used threads as opposed to cores in the table to cover hyperthreading CPUs. As I'm provisioning vCPUs in ESXi it makes no difference. I've assigned 8 cores/1 socket and it's making use of all 8 "CPUs" for Plex transcoding.

 

Now I wonder where we're at with hardware transcoding for Plex? I've never bothered looking into it before as my main hardware (HP Gen8) isn't capable...

Really the best HW transcoding with H265 support is an nVidia GPU. Something cheap and easy to get like P400. However, syno doesn't ship drivers for nV on systems other than their "AI" powered boxes for cameras.

 

 

On 10/6/2021 at 9:35 PM, scoobdriver said:

 

LOL not sure what your use case is .. most my devices direct play content, so I very rarely need to transcode (...)

Great usecase for transcoding: watching movies on Oculus Quest in bed :)

Also, cheap streaming sticks often freeze or reboot on higher quality local rips of BRs. Some SDR TVs also reallllllyy don't like HDR content.

 

 

On 10/7/2021 at 12:21 AM, naoki66 said:

#] Creating loader image at /opt/redpill-load/images/redpill-DS918+_7.0.1-42218_b1633537118.img... [ERR]
[!] Failed to copy /opt/redpill-load/build/1633537118/custom.gz to /opt/redpill-load/build/1633537118/img-mnt/part-1/custom.gz

/usr/bin/cp: error writing '/opt/redpill-load/build/1633537118/img-mnt/part-1/custom.gz': No space left on device

It prompts that the disk space is not enough, do I need to modify the size of the boot file?

You probably installed too many drivers or found a bug causing a loop somewhere. You shouldn't really go above the space allocated (~50MB) as this is plenty for drivers you need on a single platform.

 

 

On 10/7/2021 at 5:05 AM, psychoboi32 said:

Thanks, It solved my issue

 

Jun's loader modify the values if we remember correctly. In general, we just pass them to the kernel as-is. There's a validation in the kernel itself but we don't do a validation during image build due to painfuliness of coding such things in bash.
In such cases just look at dmesg output when RP loads - it will say exactly what went wrong.

 

 

21 hours ago, WiteWulf said:

Is it assuming the first disk is synoboot, so not showing it?

The stupid thing is it should NOT be. Synoboot never appear as sda, it just looks like there's a bug in the syno code and despite them taking a different symbol (i.e. synoboot and not sdX) the counter for "used" letters is still incremented and not affected by their mapping. We need to find a good place to plug into that and fix it.

 

 

20 hours ago, pocopico said:

I'm not very sure that DiskIdxMap is taken consideration, i need to further test. But in your case it makes sence to use something like 

 

SataPortMap=<number of disks in controller 1><number of disks in controller 2><number of disks in controller 3>

e.g. 

SataPortMap=188

 

 

It is used but doesn't always work as it should. You guys can also try playing with "sata_remap" or "ahci_remap" options. Their syntax is like: ahci_remap="0>16:16>0:1>17:17>1" and continues. Syno uses this a lot to rearrange ports. Don't forget about the "..." around that map. In JSON you have to escape it like \"

 

 

20 hours ago, pocopico said:

 

Jun used a sata_remap variable to remap the disk numbering which does not exist in RP.

 

Found this : https://gugucomputing.wordpress.com/2018/11/11/experiment-on-sata_args-in-grub-cfg/

 

Yup, exactly what we wrote above :D This isn't really RPs variable. These are remaps in the syno kernel. All of these "magic" options are defined in kernel/syno_bootargs.c and quite easy to understand.

 

 

16 hours ago, psychoboi32 said:

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.shUnavailable

 

takeredpill.sh 2.04 kB · 51 downloads

Sorry to be blunt but what you're doing in this script is very stupid (in a sense of code, not you as the author :)) and dangerous.

You're adding compilation options which we're almost sure you have no idea about. You've got an error with the new GCC about the PIE relocation/ASLR so you just changed the makefile for the LKM to use -fno-pie... sure, go for it! That's definitely why that error was stopping the build process so that -fno-pie can be simply added to the build line (/s).

We're strongly recommending a read of a post we put on page 55 which discusses some of the GCC stuff (which was discussed many times in this thread before). GCC isn't like Python or V8 - the version REALLY matters. Linux v3 will not build with >=5 for example. There are good reasons why kernel developers are extremely careful and have patches applied per GCC version in the code. The fact some code compiles is just at best 50% of the success with GCC.

 

Additionally, you're going against everything we recommended here. Really, this script is a collection of all "what not to do" we warned against in this thread:

  • don't compile LKM or kernel bootstrap with GCC >4.9.2 (yet the script just YOLOs it)
  • don't install random drivers loading 101 unneeded ones (and that's why we developed the extensions at all, but the script just adds a collection of drivers even if most people don't need them)
  • configure user_config for yourself which you gonna keep for long time and which is semantically valid (yet the script just obliterates it with sed, not even a jq which was installed)
  • read the docs & configurable options in commands (yet the script just does a forceful "mv" instead just using an option already provided for that)
  • and as a desert: it will fail if your path has spaces in it.

To not be just grumpy and complain we will make a suggestion: utilize a docker image by @haydibe which works great and does things safely. It soon will be merged into the main repository as well.

Obviously, as the project is open-source and on top of that a full-blown GNU, we cannot stop you from using it. However trust us on that: we collectively wasted long weeks on dealing with pesky bugs where things weren't compiled exactly right and in a proper environment.

 

 

12 hours ago, scoobdriver said:

Just a quick to those that have already got their LSI cards working on either baremetal os ESXi . 

 

Happy to experiment , but if someone can save me the time :) 

 

Do I also need to load mpt2sas extension for my card , if I have already added sas activator ext ? I was under the impression 3615XS already had this .ko that would be loaded ? 

TTG quote "

A quick update (we will write more tomorrow): the native mpt2sas driver works but it's present only on 3615xs platform. To activate it and make it working properly without any hacks just add this small extension: https://github.com/RedPill-TTG/redpill-sas-activator

 

We also updated the kernel module to rewrite SAS => SATA ports so it should work with any off-the-shelf mpt2sas or mpt3sas driver."

 

Should I be adding supportsas="yes" to my synoinfo ? or is this not required as the kernel rewrites SATA -> SATA ? 

 

 

See sad update on the top. Also, you should NOT use supportsas=yes as it does WAY more than just "adding SAS support". There are even more things associated with it (e.g. SASModel kernel boot option, which you shouldn't use either ;)).

 

 

12 hours ago, pigr8 said:

 

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.

 

 

We said that before but as a reminder if someone missed: don't add supportsas=yes. This doesn't do what it says it does sadly.

 

 

6 hours ago, fly said:

I need a help on synoinfo.conf file in /etc/ and /etc.defaults folder.

 

after editing and saving the synoinfo.conf file in both dir and reboot the files were back in originele version does anyone know how that come? i need to change some parts there for testing but got no luck because it restore back to originel file 🙄.

 

with jun loader its works perfect by the way. i dont know if synology checks after reboot the files or somehow they are not letting to edit the file.

 

i am editing them as root and it saves it also even after few hours it shows ok without rebooting but to apply changes i must reboot.

Don't edit these files manually. You can set any options in these files by adding "synoinfo" section to your user_conf. There's an example in the repo. Any options you set will take priority over default ones. The automatic code takes care about figuring out which options to remove/add/modify and to do it in 4 different files across 2 environments.

 

 

57 minutes ago, karius said:

make[1]: Leaving directory '/root/DS3615xs/bromolow/usr/local/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/sys-root/usr/lib/modules/DSM-7.0/build'
takeredpill.sh: 29: Syntax error: redirection unexpected
 

Hello

The above error occurs when running on ubuntu. Is there a solution?

You should not use that script at all. Use the container recipes provided here by haybide.

  • Thanks 5
Link to comment
Share on other sites

1 hour ago, psychoboi32 said:

스크립트를 어떻게 실행하고 있습니까? , 당신은해야


sh takeredpill.sh를 사용하지 마십시오.

 

Thank you.

Previously, it was executed with the sh command./takenfill.It works perfectly with sh.

Link to comment
Share on other sites

1 hour ago, ThorGroup said:

It is used but doesn't always work as it should. You guys can also try playing with "sata_remap" or "ahci_remap" options. Their syntax is like: ahci_remap="0>16:16>0:1>17:17>1" and continues. Syno uses this a lot to rearrange ports. Don't forget about the "..." around that map. In JSON you have to escape it like \"

 

@ThorGroup The missing Kconfig.devices explains a lot :

 

https://raw.githubusercontent.com/cake654326/xpenology/master/synoconfigs/Kconfig.devices

 

Edited by pocopico
  • Like 1
Link to comment
Share on other sites

1 hour ago, ThorGroup said:

This is a completely different issue related to security checks in the DSM photo itself. If you google search within xpenology.com you will find many mentions and discussion on patching that in the system. In short: a real S/N is needed to make validation happy without DSM patching.

I agree and I know...

But I did it with real SN/Mac.

I tried with 2 different pairs, same behavior.

whereas it works fine with my DS3615xs (real SN mac too)

Link to comment
Share on other sites

@jumkey thanks for synking the developer branch with TTG but how can I bypass boot-wait extension, because it isn`t available for 7.0.1 ?

 

[-] The extension thethorgroup.boot-wait was found. However, the extension index has no recipe for ds918p_42218 platform. It may not be
[-] supported on that platform, or author didn't updated it for that platform yet. You can try running
[-] "ext-manager.sh update" to refresh indexes for all extensions manually. Below are the currently known information about
[-] the extension stored locally:
[#] ========================================== thethorgroup.boot-wait ==========================================
[#] Extension name: RedPill Bootwait
[#] Description: Simple extension which stops the execution early waiting for the boot device to appear
[#] To get help visit: https://github.com/RedPill-TTG/redpill-boot-wait
[#] Extension preparer/packer: https://github.com/RedPill-TTG/redpill-boot-wait
[#] Update URL: https://raw.githubusercontent.com/RedPill-TTG/redpill-boot-wait/master/rpext-index.json
[#] Platforms supported: ds918p_41890 ds3615xs_25556 ds3615xs_41222 ds918p_25556 
[#] =======================================================================================


[-] Failed to update recipe for thethorgroup.boot-wait extension for platform ds918p_42218. The script will terminate as you do not
[-] have previously downloaded recipe which can be used if download fails. Try again later. If problem
[-] persists contact the extension packer for support (displayed below)
[#] ========================================== thethorgroup.boot-wait ==========================================
[#] Extension name: RedPill Bootwait
[#] Description: Simple extension which stops the execution early waiting for the boot device to appear
[#] To get help visit: https://github.com/RedPill-TTG/redpill-boot-wait
[#] Extension preparer/packer: https://github.com/RedPill-TTG/redpill-boot-wait
[#] Update URL: https://raw.githubusercontent.com/RedPill-TTG/redpill-boot-wait/master/rpext-index.json
[#] Platforms supported: ds918p_41890 ds3615xs_25556 ds3615xs_41222 ds918p_25556 
[#] =======================================================================================

[!] Cannot continue due to previous errors (see above)

*** Process will exit ***
[!] Failed to update all extensions for ds918p_42218 platform - see errors above

*** Process will exit ***
make: *** [Makefile:33: build_redpill_load] Error 1

 

Link to comment
Share on other sites

2 hours ago, ThorGroup said:

Wait... are you saying this doesn't require the paid license but just a config edit?!
Also: there's a new bash tool in the loader repo called "always-telnet" - you may find it useful with working with VMWare serial ports.

Sorry, I should have written "Workstation Pro"

 

With Workstation pro (and Fusion) you can't set it to use network.

 

ESXi (enterprise plus) :

image.thumb.png.44544c9154661e8ea4872034e71d2820.png

 

Workstation Pro :

image.png.9342445f9856cec3931452e3cf686734.png

 

Manually editing the Workstation Pro/Fusion's VMX file with the following values make serial port using network available :

serial0.present = "TRUE"
serial0.fileType = "network"
serial0.fileName = "0.0.0.0:10021"
serial0.network.endPoint = "server"
serial0.startConnected = "TRUE"

 

Once manually added, you see it as "Unrecognized type" in GUI, but it works :

image.thumb.png.4638d175d528907952414671d2d374ff.png

Edited by Orphée
  • Like 1
Link to comment
Share on other sites

1 hour ago, ThorGroup said:

So, regarding the SAS issue: the sas-activator may be a flop. We tested it with SSDs and few spare HDDs which obviously weren't >2TB. It seems like the driver syno ships is ancient and while it does work it only runs using SAS2 (limit to 2TB is one of the symptoms). Don't we all love that ancient kernel? ;) Probably on systems with mpt3sas the situation isn't a problem.

 

oh wow 😮 the ancient kernel could explain why >2tb not working but in jun's loader with 3.10.105 everything works 😮 so not sure what to guess.

 

1 hour ago, ThorGroup said:

That pesky /dev/sda may actually be a bug in the syno kernel. According to the IdxMap it should NOT present itself at the first spot grrr... we set it to map controller 1 to like 20 and it still used the first disk (and only the first) at /dev/sda. There may be a way to use remap of ports (another feature which syno uses extensively on their boards) to move it. It would actually explain why syno uses a long string of remaps (comically long, like 30-entries-long) instead of a map on some of their boards... as map seems to not work properly. We will play with it. Can you create an issue in the redpill-lkm repo, so we don't lose track of that?
It may also be a problem with magic index shifting... it looks like Jun's loader may have been fixing a bug in syno's remap code.

 

 

1 hour ago, ThorGroup said:

The stupid thing is it should NOT be. Synoboot never appear as sda, it just looks like there's a bug in the syno code and despite them taking a different symbol (i.e. synoboot and not sdX) the counter for "used" letters is still incremented and not affected by their mapping. We need to find a good place to plug into that and fix it.

 

yeah i banged my head around this a lot trying understanding why it does that (reserving /dev/sdA), a bug could explain this and jun's loader fixes that, will add an issue on gh as requested.

 

1 hour ago, ThorGroup said:

Yup... exactly the problem as described at the beginning of the post. It was too easy to simply load their drivers. This lead us to write that summary on the top - it looks like anyone dependent on the LSI card will need to use a 3rd-party driver as the syno one is ancient and only uses SAS2 (and thus the limit).

 

that sata_shim patch just gives that error on the stock mpt2sas.ko, it does not affect @pocopico compiled driver even if it's older (again guessing here).

 

1 hour ago, ThorGroup said:

[note to ANYONE doing supportsas=yes]

You shouldn't really do that. This activates syno-specific SAS support which will break a lot of things. This flag is horribly misleading and used in aaaaa looot of syno code. This is way more than just loading the driver. This is more of a "activate our hacks for broken LSI firmware we flashed ... and do these totally not-SAS things on this controller ... and when you are at that can you maybe also tell the controller to take over controlling some of the leds ... oh, and load the driver".
So folks, really, don't touch that option with a long pole - it's a trap. It would only be useful if full ebox emulation was present.

 

again, that explains a lot, gonna ditch this method immediately.

 

1 hour ago, ThorGroup said:

//

 

Gen8 is such an amazing server but iLO... iLO was written past the Bellmer's curve (e.g. to enable PCI-passthrough you need RMRR hacks because HP decided to mess with it against the ACPI specs).

//

 

...if only Gen8 had 32GB RAM support. Oh, wait, it can support it but Intel forced HP to disable it.

 

//

 

yeah -_- thanks hp, noticed this long time ago.. like the missing pcie bifurcation option that could really improve the microserver -_-

 

1 hour ago, ThorGroup said:

It is used but doesn't always work as it should. You guys can also try playing with "sata_remap" or "ahci_remap" options. Their syntax is like: ahci_remap="0>16:16>0:1>17:17>1" and continues. Syno uses this a lot to rearrange ports. Don't forget about the "..." around that map. In JSON you have to escape it like \"

 

oh have to check this out.

Link to comment
Share on other sites

6 minutes ago, pigr8 said:

that sata_shim patch just gives that error on the stock mpt2sas.ko, it does not affect @pocopico compiled driver even if it's older (again guessing here).

 

The version of the driver used by syno does not actually mean its newer but i would say it just means they touched it somehow to satisfy some of their symbols. The way that syno touches the vanilla kernel was explained by @ThorGroup on a previous post on this thread. Having that in mind i can suspect they modified lets say version < 14.0 and changed the version to 20.0 

 

You can verify yourself by reading the driver sources inside the syno released kernel sources.

Edited by pocopico
Link to comment
Share on other sites

35 minutes ago, ct85msi said:

@jumkey thanks for synking the developer branch with TTG but how can I bypass boot-wait extension, because it isn`t available for 7.0.1 ?

 



[-] The extension thethorgroup.boot-wait was found. However, the extension index has no recipe for ds918p_42218 platform. It may not be
[-] supported on that platform, or author didn't updated it for that platform yet. You can try running
[-] "ext-manager.sh update" to refresh indexes for all extensions manually. Below are the currently known information about
[-] the extension stored locally:
[#] ========================================== thethorgroup.boot-wait ==========================================
[#] Extension name: RedPill Bootwait
[#] Description: Simple extension which stops the execution early waiting for the boot device to appear
[#] To get help visit: https://github.com/RedPill-TTG/redpill-boot-wait
[#] Extension preparer/packer: https://github.com/RedPill-TTG/redpill-boot-wait
[#] Update URL: https://raw.githubusercontent.com/RedPill-TTG/redpill-boot-wait/master/rpext-index.json
[#] Platforms supported: ds918p_41890 ds3615xs_25556 ds3615xs_41222 ds918p_25556 
[#] =======================================================================================


[-] Failed to update recipe for thethorgroup.boot-wait extension for platform ds918p_42218. The script will terminate as you do not
[-] have previously downloaded recipe which can be used if download fails. Try again later. If problem
[-] persists contact the extension packer for support (displayed below)
[#] ========================================== thethorgroup.boot-wait ==========================================
[#] Extension name: RedPill Bootwait
[#] Description: Simple extension which stops the execution early waiting for the boot device to appear
[#] To get help visit: https://github.com/RedPill-TTG/redpill-boot-wait
[#] Extension preparer/packer: https://github.com/RedPill-TTG/redpill-boot-wait
[#] Update URL: https://raw.githubusercontent.com/RedPill-TTG/redpill-boot-wait/master/rpext-index.json
[#] Platforms supported: ds918p_41890 ds3615xs_25556 ds3615xs_41222 ds918p_25556 
[#] =======================================================================================

[!] Cannot continue due to previous errors (see above)

*** Process will exit ***
[!] Failed to update all extensions for ds918p_42218 platform - see errors above

*** Process will exit ***
make: *** [Makefile:33: build_redpill_load] Error 1

 

 

@jumkey fork does does not have Bootwait in the bundled-exts.json so why your building fails integrating it is probably your side problem..

 

Edited by pigr8
  • Thanks 1
Link to comment
Share on other sites

4 minutes ago, pocopico said:

 

The version of the driver used by syno does not actually mean its newer but i would say it just means they touched it somehow to satisfy some of their symbols. The way that syno touches the vanilla kernel was explained by @ThorGroup on a previous post on this thread.

 

yeah but still not clear why the .105 .ko works fine on jun's loader (i assume he didn't touch that .ko and it's synologys untouched) and the synologys .108 does not.

Link to comment
Share on other sites

34 minutes ago, ct85msi said:

@jumkey thanks for synking the developer branch with TTG but how can I bypass boot-wait extension, because it isn`t available for 7.0.1 ?

 


[-] The extension thethorgroup.boot-wait was found. However, the extension index has no recipe for ds918p_42218 platform. It may not be
[-] supported on that platform, or author didn't updated it for that platform yet. You can try running
[-] "ext-manager.sh update" to refresh indexes for all extensions manually. Below are the currently known information about
[-] the extension stored locally:
[#] ========================================== thethorgroup.boot-wait ==========================================
[#] Extension name: RedPill Bootwait
[#] Description: Simple extension which stops the execution early waiting for the boot device to appear
[#] To get help visit: https://github.com/RedPill-TTG/redpill-boot-wait
[#] Extension preparer/packer: https://github.com/RedPill-TTG/redpill-boot-wait
[#] Update URL: https://raw.githubusercontent.com/RedPill-TTG/redpill-boot-wait/master/rpext-index.json
[#] Platforms supported: ds918p_41890 ds3615xs_25556 ds3615xs_41222 ds918p_25556 
[#] =======================================================================================


[-] Failed to update recipe for thethorgroup.boot-wait extension for platform ds918p_42218. The script will terminate as you do not
[-] have previously downloaded recipe which can be used if download fails. Try again later. If problem
[-] persists contact the extension packer for support (displayed below)
[#] ========================================== thethorgroup.boot-wait ==========================================
[#] Extension name: RedPill Bootwait
[#] Description: Simple extension which stops the execution early waiting for the boot device to appear
[#] To get help visit: https://github.com/RedPill-TTG/redpill-boot-wait
[#] Extension preparer/packer: https://github.com/RedPill-TTG/redpill-boot-wait
[#] Update URL: https://raw.githubusercontent.com/RedPill-TTG/redpill-boot-wait/master/rpext-index.json
[#] Platforms supported: ds918p_41890 ds3615xs_25556 ds3615xs_41222 ds918p_25556 
[#] =======================================================================================

[!] Cannot continue due to previous errors (see above)

*** Process will exit ***
[!] Failed to update all extensions for ds918p_42218 platform - see errors above

*** Process will exit ***
make: *** [Makefile:33: build_redpill_load] Error 1

 

merged pr and messed up your branch @Orphée😅.

  • Thanks 1
Link to comment
Share on other sites

2 hours ago, ThorGroup said:
On 10/3/2021 at 6:18 PM, urundai said:

quick question: Per the loader documentation, one can remove vid and pid if they are using SATA based boot. Unfortunately, when I do that, my build fails with 'unbound parameter extra_cmdline('vid')'. 

 

For now, I am still leaving vid/pid in there for my esxi but not sure why the build fails. Any thoughts?

pinging @haydibe here. The loader itself doesn't care [now] but probably the container config has some assumption somewhere. You can leave them, you can even set them to DEAD and BEEF - it will not cause any problems but a warning message during boot ;) When they're set but not needed they're only validated to the point of "is this a hex number".

 

When the container is created, the file is mounted into rp-load folder, without any validation.

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...