Jump to content
XPEnology Community

RedPill - the new loader for 6.2.4 - Discussion


Recommended Posts

I am sure I am doing something wrong.

 

I successfully compiled the img for DS3515xs using the toolkit V11 and Debian (running on vmware on my mac). I then converted it to vmdk using V2V converter. I created a new VM in my ESXI, set the network card to E1000e, set the correct MAC address.

 

When I start it up, I see the message to pick USB or SATA. Once I select SATA, it stops at 'Booting Kernel' message. Nothing happens and I don't see any obvious error message in the log (attached). 

 

I used the instructions from this post: Building Redpill image.

 

Did any of you run into the same problem? Any pointers on what I might be doing wrong?

 

 

log.txt

Link to comment
Share on other sites

2 hours ago, urundai said:

When I start it up, I see the message to pick USB or SATA. Once I select SATA, it stops at 'Booting Kernel' message. Nothing happens and I don't see any obvious error message in the log (attached). 

From what I have read in this thread, this is fine (I believe @WiteWulf requested ThorGroup to put a better message here, as Jun's loader did).

Have you looked for your diskstation on the network (find.synology.com) and started the install process?

  • Like 1
Link to comment
Share on other sites

On 9/13/2021 at 11:57 AM, yanjun said:

Unfortunately, for LSI drivers, such as mptsas3, I have tried many times to use the 25426branch kernel code of 918 to compile, and errors will be reported when the driver is loaded (the specific error content I mentioned in the above post) and the system cannot be correct. Start, and jumkey uses the mpt3sas source code of 4.4.180 released by the Linux open source community to compile the mpt3sas driver, which can be loaded correctly and recognize the hard disk, so if for data security considerations, should we wait until Qunhui releases the 41890 kernel source code? 

 

Finally we've got some time to respond to the questions. We will try to respond to as many as possible so stay tight :)
=======

 

Why there's a problem with compiling drivers when syno didn't publish kernel sources?

 

 

This is going to be a separate post addressing "why you cannot randomly grab drivers and compile them" so we can link to it. Let us explain where's the problem, this applies to many questions really.

There are few major issue with compiling drivers against a different sources. The three major ones are:
1) Versioning of syno kernel's is broken due to backporting
2) Drivers modification
3) Kernel <=> driver modification
4) Data structures missing in toolchains for in-tree drivers

 

Now let us explain each one of them separately and why this is an issue. There's a lot to unpack here. First lets address few terms which are used in kernel development:

  • "in-tree" = code which exists within the source of the kernel; in terms of drivers it means you will find it under "drivers/" (e.g. in drivers/scsi/mpt2sas)
  • "vanilla kernel" = source of the kernel which is the official version from kernel.org
  • "kernel headers" = .h files present in the toolchain. These are NOT all kernel's .h files but only a subset of public API kernel provides. You will find these under "include" or in the syno toolchain. What's important they DO NOT contain private interaction between modules. That's why if e.g. mpt3sas driver wants something from mpt2sas you cannot use toolchain to compile mpt3sas and you NEED full sources.
  • "upstream it" = make your custom patch for the kernel and get it accepted into the normal kernel sources

 

1) Versioning & backporting
Syno, like many other companies, take the kernel and modify it in house. This is something which kernel devs don't really like but since it's an open-source project everyone can. However, after some time these companies realize they want new features from new kernel but cannot get them as their modifications no longer apply to a new version. What they do is "backporting". They grab their e.g. 3.10.108 which was modified to oblivion, then download the e.g. 3.19.0 and check commits which add features they want. They get that commit and apply to their 3.10.108 making it 3.10.109. This is incorrect and broken. But that't not the biggest problem.
In case you don't see it: this poses a HUGE problem for using drivers from the vanilla kernel. Often times if you take a driver from vanilla 3.10 you will realize that suddenly doesn't work at all... as in fact they previously lifted a newer one from 3.20 and stuffed it in 3.10. Good luck loading such driver and using it.
For that reason alone you CANNOT use vanilla kernel code as you don't know which version of the code has to be used. Sure, there are ways to figure this out, but the only sane approach is to use the source provided by syno. In case of small-ish bumps in kernel it's usually safe to get e.g. driver from kernel from 3.10.105 and fake the version compiling for 3.10.108 hoping not much changed.

 

2) Drivers modification
Syno modifies in-tree drivers directly. To be honest they have no way around it as they apply vendor-specific hacks for e.g. timing bugs in certain chips. They should upstream it but... that's a different story and it's not as easy as it seems. Depending on WHAT was changed in the driver sometimes you can use kernel from a different kernel version. How do you know it's safe? Well... it's hard. If you don't have the sources for the new kernel (since if you did you wouldn't bother lifting the driver from an older version) you cannot know if the data structures changed. If they did you're pretty much toasted.
Languages like C or ASM (or hardware in general) doesn't have magical way of discovering sizes of things. Everything is based on static assignment (ok, not everything, but lets make a simplification here). This means if syno decided to add a field to a struct [it's like an object] in mpt3sas driver and that field was added to a struct used ONLY in mpt3sas driver you can probably load the old driver and be fine. However, if they added a new argument to a "public" function (function used outside of the mpt3sas driver) or a new field to a struct used externally from the mpt3sas driver things may APPEAR to work. Every time such function is called or struct is used more and more memory and/or stack gets corrupted. Eventually you will crash something very badly and you will be lucky if that was at least the driver and not something unrelated which was just in the same area. In kernel there's virtually no protections of one piece of code breaking memory of the other. There are small protection for the kernel CODE itself and some sensitive areas but it's not like in the user space where one process trying to write into memory of another process will simply be killed - in the kernel you just corrupt the memory silently.


3) Kernel <=> driver interactions
Scrolling through the questions we saw that some of you load drivers and see missing symbols. Well, this is the effect of 2). When they modify the drivers they often add their own hooks by just placing a f... gSynoFoo() call somewhere in the driver. Honestly we think it's very sloppy but it is how it is. The issue here is two-fold:

  • if you compile a driver from vanilla kernel you will not have these calls so things may look correctly... but these calls were placed there for a reason and other things exepect them to happen. Sometimes the issue may be really small like performance drop or hibernation not working correctly. Sometimes you may step into a data loss with a certain controller which syno fixed in their kernel after getting a possible fix from the manufacturer... you don't know.
  • if you try to add e.g. SAS to a non-SAS model things break badly. This is because it's not as simple as flipping the flag in synoinfo. By doing so you're telling the DSM "this model supports SAS". But the issue here is that models which REALLY support SAS have A LOT of code which is compiled only and only when the kernel config option for SAS was enabled. This config option being disabled literally REMOVED a bunch of code from many places when they compiled the kernel without SAS support. That's also the reason why getting SATA boon on 918+ was so challenging as the SATA-DOM code is literally removed on 918+. Bottom line is don't try to activate functions which depend on the kernel features being present. You can tweak number of disks, supported number of cameras and other user-land features but not re-enable features which are partially kernel and partially userland. It's like trying to pump diesel fuel into gasoline car after drilling a larger hole to fit the bigger diesel nozzle into the tank.

There's no straightforward way to KNOW if the feature you want to activate has a kernel component. However, going through ALL options in synoconfigs/KConfig.* files will give anybody an idea what sort of things can or cannot be activated. In general anything involving in-kernel drivers is a no-no (e.g. iGPU acceleration will not work on 3615xs most likely but NVidia GPU probably will).


4) Data structures missing in toolchains for in-tree drivers
You cannot get the code of a in-tree driver and compile it against the toolchain. This is because in-kernel drivers have access to many more things and link internal kernel files. Should they? Most likely no. However, the kernel is
30 YEARS OLD codebase and only recently they started to encapsulate drivers from using internal things. In most cases it's better to stick to the hardware which is officially supported.


We have v7 sources for geminilake which we took some hints from (e.g. about synobios structures). If there's a particular driver we can look and compare with v6. However, if there's anyone who has experience with drivers (@IG-88?) we can share the archive in a PM as syno pulled it from SF. Why they did pull it? It's possible it contains code from e.g. broadcomm which is under an NDA and should never be published as it's not GPL.

  • Like 3
  • Thanks 2
Link to comment
Share on other sites

This post contains answers up to page 67.

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

 

On 9/13/2021 at 3:38 AM, pocopico said:

Line 285 in your case. /lib/modules is linked to /usr/lib/modules 

.

insmod /lib/modules/xxx

You should use extensions now and NOT modify any files manually.

 

 

On 9/13/2021 at 2:23 PM, shibby said:

1st) connect your drives in the order starting from SATA0 port.

2nd) add SataPortMap=4 to your config grub.cfg file. Set this vaule to corresponding to your number of hard drives

Please, do not modify the grub.cfg file. This isn't a supported method with RP and should not be used. You should add that option as an extra_cmdline in user_conf instead.

 

 

On 9/13/2021 at 2:39 PM, ct85msi said:

 

Only this error in /var/log/messages :

 


2021-09-13T09:34:08+03:00 Apollo kernel: [246979.674416] md_error: sdd2 is being to be set faulty
2021-09-13T09:34:08+03:00 Apollo kernel: [246979.674710] raid1: Disk failure on sdd2, disabling device.
        Operation continuing on 3 devices
2021-09-13T09:37:30+03:00 Apollo synodisklatencyd[10373]: raid_uuid_get.c:81 Disk [/dev/sdd3] in RAID [/dev/md3] has no RAID superblock, ret=0
2021-09-13T09:37:30+03:00 Apollo synodisklatencyd[10373]: raid_uuid_get.c:81 Disk [/dev/sdd3] in RAID [/dev/md3] has no RAID superblock, ret=0
2021-09-13T09:37:37+03:00 Apollo synodisklatencyd[5770]: SYSTEM:        Last message 'raid_uuid_get.c:81 D' repeated 1 times, suppressed by syslog-ng on Apollo

 

and in dmesg:

 


[245399.816502] RTC time set to 2021-09-13  6:07:48 (UTC)
[246979.674416] md_error: sdd2 is being to be set faulty
[246979.674710] raid1: Disk failure on sdd2, disabling device.
                        Operation continuing on 3 devices
[246979.874503] RAID1 conf printout:
[246979.874722]  --- wd:3 rd:4
[246979.874954]  disk 0, wo:0, o:1, dev:sda2
[246979.875301]  disk 1, wo:0, o:1, dev:sdb2
[246979.875625]  disk 2, wo:0, o:1, dev:sdc2
[246979.875956]  disk 3, wo:1, o:0, dev:sdd2
[246979.941246] RAID1 conf printout:
[246979.941435]  --- wd:3 rd:4
[246979.941597]  disk 0, wo:0, o:1, dev:sda2
[246979.941813]  disk 1, wo:0, o:1, dev:sdb2
[246979.942028]  disk 2, wo:0, o:1, dev:sdc2
[246980.681243] md: unbind<sdd2>
[246980.687229] md: export_rdev(sdd2)

 

Meanwhile...the benchmark is stuck in this state, as the image attached.

 

Thank you for all of your work !

 

hdd benchmark faulty.jpg

After I stop the test, the array is resyncing.

hdd benchmark faulty 2.jpg

That is... strange. We're adding it to our internal list as the disk test shouldn't randomly crash the pool :D

 

On 9/13/2021 at 2:50 PM, coint_cho said:

Was testing it on VMWare and now unfortunately it can't even get pass the pat installation screen and is just costantly stuck at 56% and fail with a message of saying file corrupted as usual. Works on Proxmox still but yeah.

This usually happens [on VMWare] when you use USB-boot and not SATA boot. VMWare doens't support USB boot unless you use a physical USB stick connected to a USB-2.0 port [as booting from 3.0 is not exactly working].

 

On 9/13/2021 at 2:57 PM, SachinD said:

@ThorGroup My understanding is that for ESXi the vmdk is split into 2 files the raw data (Diskname-flat.vmdk) and the raw disk descriptor (Diskname.vmdk), whereas other products like VMWare Workstation have the descriptor followed by the disk data in a single vmdk file.. hope that helps.

The issue is actually both ESXi and other VMWare products internally support both. However, newer ESXis don't like just flat VMDKs for some reason. Even generating the descriptor it fails to boot half of the time when the image is not "blessed" by the VMWare's own tool.

 

 

On 9/13/2021 at 4:19 PM, Zardozlv said:

 

Nope,I just tried and now I’m reinstalling my DSM😂.The new img is the same size as the old one.

屏幕截图 2021-09-13 161752.png

屏幕截图 2021-09-13 161834.png

FYI image will always be 128MB (unless we change the base) - you will only see a real change in size when you compress it with e.g. ZIP so it removes all the empty space in it.

 

 

On 9/13/2021 at 4:22 PM, WiteWulf said:

1 - I'm writing with dd to /dev/rdiskX and absolutely do have to mark it as active afterwards. I've created loads of images now and every time there is no partition marked as active. This isn't a problem for most hardware, but the Gen8 (which as you've pointed out elsewhere is quite picky) *needs* to have the first partition marked as active to boot from it

 

2 - DSM 7.0.1-RC1 is running docker 20.10.3. This appears to be from February 2021, and only five patch levels behind current (20.10.8). To be clear: this problem only ever manifested with docker containers running influxdb, but across numerous versions of influxdb tried. Lots of Googling suggests no one else is experiencing problems like this, but I'm curious to know if anyone else here sees it.

Gen 8 is on our list to figure out fully as we have quite a few of them ;)

 

 

On 9/13/2021 at 5:23 PM, blindspot said:

Maybe is not related but this is how DSM is showing drives on the second controller on my bare metal ASRock N3700 and is working fine. 

image.png.337075c7b1ca893ca29f7ed48798875a.png

 

image.png.2062e3d4c28b80e0f9d9b6b7f508f2a5.png

FYI: That is slightly playing with fire. Internally they assume (at leas in v6) that the disk will be 3 characters in a form of "sdX" unless we missed something. The fact it shows up in the GUI doesn't mean it works correctly. There is probably a reason why they don't sell units with >26 internal drive bays :D

 

On 9/13/2021 at 5:31 PM, ct85msi said:

Just asking, this has nothing to do with xpenology/bootloader, right?

 

root@Apollo:~# tail -f /var/log/messages
2021-09-13T11:46:56+03:00 Apollo synosnmpcd[9578]: scemd_connector/scemd_connector.c:118 Fail to lockf() for scemd connector client.
2021-09-13T11:46:56+03:00 Apollo synosnmpcd[9578]: scemd_connector/scemd_connector.c:204 Fail to SYNOScemdConnectorClient() for scemd conncetor client
2021-09-13T11:46:56+03:00 Apollo synosnmpcd[9578]: scemd_connector/scemd_connector.c:118 Fail to lockf() for scemd connector client.
2021-09-13T11:46:56+03:00 Apollo synosnmpcd[9578]: scemd_connector/scemd_connector.c:204 Fail to SYNOScemdConnectorClient() for scemd conncetor client
2021-09-13T11:46:56+03:00 Apollo synosnmpcd[9578]: scemd_connector/scemd_connector.c:118 Fail to lockf() for scemd connector client.
2021-09-13T11:46:56+03:00 Apollo synosnmpcd[9578]: scemd_connector/scemd_connector.c:204 Fail to SYNOScemdConnectorClient() for scemd conncetor client
2021-09-13T12:02:01+03:00 Apollo synosnmpcd[9578]: scemd_connector/scemd_connector.c:118 Fail to lockf() for scemd connector client.
2021-09-13T12:02:01+03:00 Apollo synosnmpcd[9578]: scemd_connector/scemd_connector.c:204 Fail to SYNOScemdConnectorClient() for scemd conncetor client
2021-09-13T12:03:09+03:00 Apollo synosnmpcd[9578]: scemd_connector/scemd_connector.c:150 Fail to recvfrom() for scemd connector client.
2021-09-13T12:03:09+03:00 Apollo synosnmpcd[9578]: scemd_connector/scemd_connector.c:204 Fail to SYNOScemdConnectorClient() for scemd conncetor client
 

That randomly popsup even on real hardware. Sometimes threads of scemd crash/freeze and it tries for some time to recover them before killing and restarting. Nothing to worry about unless it happens constantly.

 

 

On 9/13/2021 at 5:45 PM, WiteWulf said:

Okay, I figured out why DSM was showing two adapters with the same MAC address: I was declaring/assigning the MAC addresses in the wrong order in user_config.json

 

I originally had:


{
  "extra_cmdline": {
    "pid": "0x1000",
    "vid": "0x090c",
    "sn": "xxxxLWNxxxxxx",
    "mac1": "xxxxxxxxxx75",
    "mac2": "xxxxxxxxxx74"
  },
  "synoinfo": {},
  "ramdisk_copy": {}
}

Which manifested as "mac2=xxxxxxxxxx74 mac1=xxxxxxxxxx75" in my grub.cfg. This resulted in DSM seeing two adapters with the same MAC address of xxxxxxxxxx75

 

Swapping them around to:


{
  "extra_cmdline": {
    "pid": "0x1000",
    "vid": "0x090c",
    "sn": "xxxxLWNxxxxxx",
    "mac1": "xxxxxxxxxx74",
    "mac2": "xxxxxxxxxx75"
  },
  "synoinfo": {},
  "ramdisk_copy": {}
}

Gives me a grub.cfg with  "mac2=xxxxxxxxxx75 mac1=xxxxxxxxxx74" and two NICs with the correct, different, MAC addresses in DSM. This is obviously to do with the order in which the kernel enumerates the NIC interfaces, and the MAC addresses have to be declared in a way that matches that order or linux/DSM gets confused.

Correction: it's not the Linux being confused but the mfgBIOS code. Linux doesn't care - this is why the network may appear to work. But syno services do care. Instead of using the API they went around it so when the MACs aren't in order some things try to use the normal API where others use the syno API... and this is what happens. We usually just boot with one random MAC defined and just "ip a" quickly to see how the kernel sees ethernets in that particular system.

 

On 9/13/2021 at 5:50 PM, Orphée said:

So with latest loader with ESXi Smart patch. I'm not able to install DSM 7.0 anymore. It fails at 55%.

 

My json file :

 

Lot of errors like this in serial console :

 

Any time you see gpioerrors on 918+ it means the module didn't load at all. You should check dmesg. Now the problem shouldn't really exist as if RP fails to load it will deliberately panic the kernel with a detailed log to avoid such "wtf" situations.

 

 

On 9/13/2021 at 9:19 PM, p33ps said:

Can someone paste here their VM Proxmox setup for a DS3615xs boot? I am having huge CPU issues when the Photos app starts their face recognition index process. It blocks the VM completely and I need to stop-start it. It never finishes the recognition process. This is the CPU and network status when it starts:

 

image.thumb.png.7af0e2b3b2153c4356eb0637a4a1b9f8.png

 

Current hardware setup is:

 

HP Proliant Microserver G8

16GB RAM

Xeon E3 1265l v2

1 x 1TB 870 SSD

3 x 12TB Seagate Exos X16

1 x 12TB Seagate IronWolf Pro

DSM 7.0.1 RC.

 

I've tested it with LVM and ZFS storage pool.

 

Thanks!

FYI this seems like the bug reported for the kernel crashing: https://github.com/RedPill-TTG/redpill-lkm/issues/21
That is extremely hard to debug as kernel lockup is essentially "welp, someone tried to take a spinlock but there's another spinlock running". The fact we cannot compile our own kernel, due to broken sources from syno, makes debugging this issue a nightmare. Take a drink for D3x - she's trying to find the issue for some time now. Preliminary testing shows that may not even be the issue with RP but with the kernel mods by syno itself.

 

 

On 9/13/2021 at 10:05 PM, abesus said:

The good information is that according to internet Xeon E3-1265L V4 has support for MOVBE. My problem was connected to intel iommu driver and I've resolved this issue by reconfiguring this driver. From now my DSM is stable and user_config.json looks like this (vid/pid/sn/mac are different of course ;-) )

It will (should) have impact only for virtual machines inside DSM which I don't have ;-) 

Oh yes, iommu... that is sometimes tricky. In general IOMMU should be disabled unless you use VMs as it causes more problems even on standard Linux distros. Intel MMU implementation is very... very.... hacky. They improved a lot since 9th gen but older ones are often unstable. A lot of times installing a microcode update helps.

 

 

On 9/13/2021 at 11:30 PM, jumkey said:

Try to implement loading extended kernel modules like extra.lzma

https://github.com/jumkey/redpill-load/commit/4ff6ffe72a479cbe3ef5a67ecad86441109edd1c


PS D:\redpill-load> tree .\custom\ /f /a
D:\REDPILL-LOAD\CUSTOM
|   .gitkeep
|
\---lib
    +---firmware
    |   \---4.4.180+
    |       \---i915
    |               bxt_dmc_ver1_07.bin
    |               cnl_dmc_ver1_06.bin
    |               glk_dmc_ver1_04.bin
    |               kbl_dmc_ver1_01.bin
    |               kbl_dmc_ver1_04.bin
    |               skl_dmc_ver1_26.bin
    |               skl_dmc_ver1_27.bin
    |
    +---modules
    |   \---4.4.180+
    |           mpt3sas.ko
    |           r8125.ko
    |           raid_class.ko
    |           rng-core.ko
    |           scsi_transport_sas.ko
    |           vmxnet3.ko
    |
    \---modules-load.d
            70-disk-0000-mpt3sas.conf
            70-extra-0000-r8125.conf
            70-extra-0001-vmxnet3.conf
            70-optional-0000-virtio-rng.conf

PS D:\redpill-load> cat .\custom\lib\modules-load.d\70-optional-0000-virtio-rng.conf
rng-core
virtio-rng
PS D:\redpill-load> cat ..\user_config-ds918.json
{
  "extra_cmdline": {
    "vid": "0x46f4",
    "pid": "0x0001",
    "sn": "xxxxPDNxxxxxx",
    "mac1": "001132FFFFFD",
    "mac2": "001132FFFFFE",
    "netif_num": 2
  },
  "synoinfo": {},
  "ramdisk_copy": {
    "lib/modules-load.d": "lib/modules-load.d/",
    "lib/modules/4.4.180+": "lib/modules/",
    "lib/firmware/4.4.180+": "lib/firmware/"
  }
}
PS D:\redpill-load>

...and now we have extensions ;) We hope you like it as we see you play with drivers a lot.

 

 

On 9/14/2021 at 1:56 AM, pocopico said:

 

Hi,

 

i got the same issue as you, it looks like redpill is failing at the time of the boot device shim and then i get no synoboot

 

@ThorGroup

 

[    9.296466] <redpill/boot_device_shim.c:48> Registering boot device router shim
[    9.297930] <redpill/native_sata_boot_shim.c:205> Registering native SATA DOM boot device shim
[    9.298931] BUG: unable to handle kernel NULL pointer dereference at           (null)
[    9.300841] IP: [<ffffffffa0009663>] register_native_sata_boot_shim+0x33/0x1d0 [redpill]
[    9.302811] PGD 137f9c067 PUD 137f9b067 PMD 0
[    9.303770] Oops: 0000 [#1] SMP
[    9.303944] Modules linked in: redpill(OF+)
[    9.304117] CPU: 3 PID: 521 Comm: insmod Tainted: GF          O 3.10.108 #42214
[    9.304291] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019
[    9.304465] task: ffff880137d68820 ti: ffff880135d4c000 task.ti: ffff880135d4c000
[    9.314116] RIP: 0010:[<ffffffffa0009663>]  [<ffffffffa0009663>] register_native_sata_boot_shim+0x33/0x1d0 [redpill]
 

 

That should be fixed now as @pocopico mentioned.

 

 

On 9/14/2021 at 11:31 AM, FiberInternetUser said:

After updating to the latest loader from @ThorGroup for apollolake-7.0.1-42214 on bare metal.  Getting the following continuous output from the serial console port after the login prompt.

 

 

Getting this notification from the USB Boot Thumbdrive.

 

USB_Drive_Error.JPG.968cf149af5e9403a2abb6894b72387c.JPG

 

We dialed down these debug messages. They're actually perfectly fine. That external storage warning is not and there's an issue on GH for this one as we recall correctly. It should be the same as this one: https://github.com/RedPill-TTG/redpill-load/issues/30

 

 

On 9/14/2021 at 2:21 PM, yanjun said:

for example:

clone related driver form https://github.com/torvalds/linux/tree/master/drivers(But this is not a recommended practice. If the source of the group Synology GPL7.0 is released and the drivers you need are in the drivers folder, the best practice is to select the driver from the synology GPL source.)

 

 


cd drivers/net/ethernet/intel/ixgbe
make CONFIG_IXGBE=m CROSS_COMPILE=/usr/local/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu- -C /usr/local/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/sys-root/usr/lib/modules/DSM-7.0/build/ M=`pwd` modules 

notice: CONFIG_IXGBE=m  you need found the CONFIG_IXGBE string form Makefile in /drivers/net/ethernet/intel/ixgbe if you want to compile other drivers

See

 

On 9/14/2021 at 5:08 PM, ct85msi said:

waiting for @chchia to merge redpill-ttg into master and recreate my usb boot stick.

 

 

https://github.com/chchia/redpill-load

 

When will 7.0.1-42214 be officially supported into the master branch ? @ThorGroup

Thank you!

 

L.E. Done, merged . Thank you chchia!

We have a limited set of hands and try to prioritize getting as many things correctly as we can on the current version. Adding v7.0.1 when we have v7.0 is trivial but adds another thing to test and potentially debug the issues if any. As we described in the roadmap we want to merge all new software releases. Going further we will merge them much faster when the major load we have is a new release and not 42 different things to check and patch + new version ;)
We try to make this about quality and thus we don't blindly merge new releases either - we check every single kernel manually to see if nothing actually changed and don't just use autogenerated patches (as you know, any time you code something - like a generator - you will never trust it as an author ;)).

 

 

On 9/14/2021 at 11:14 PM, dodo-dk said:

 

I have the same problem with DSM 7.0.1 RC -> Bug CPU, see log.

With 6.2.x it works.

 


[  260.026023] BUG: soft lockup - CPU#0 stuck for 41s! [synofoto-face-e:12009]
[  260.026023] Modules linked in: fuse 8021q vhost_scsi(O) vhost(O) tcm_loop(O) iscsi_target_mod(O) target_core_ep(O) target_core_multi_file(O) target_core_file(O) target_core_iblock(O) target_core_mod(O) syno_extent_pool(PO) rodsp_ep(O) udf isofs loop synoacl_vfs(PO) btrfs zstd_decompress ecryptfs zstd_compress xxhash xor raid6_pq zram(C) glue_helper lrw gf128mul ablk_helper bromolow_synobios(PO) hid_generic usbhid hid usblp bnx2x(O) mdio mlx5_core(O) mlx4_en(O) mlx4_core(O) mlx_compat(O) qede(O) qed(O) atlantic_v2(O) atlantic(O) tn40xx(O) i40e(O) ixgbe(O) be2net(O) i2c_algo_bit igb(O) dca e1000e(O) sg dm_snapshot crc_itu_t crc_ccitt psnap p8022 llc zlib_deflate libcrc32c hfsplus md4 hmac sit tunnel4 ipv6 flashcache_syno(O) flashcache(O) syno_flashcache_control(O) dm_mod cryptd arc4 sha256_generic sha1_generic ecb aes_x86_64 authenc des_generic ansi_cprng cts md5 cbc cpufreq_powersave cpufreq_performance mperf processor thermal_sys cpufreq_stats freq_table vxlan ip_tunnel virtio_scsi(OF) virtio_net(OF) virtio_blk(OF) virtio_pci(OF) virtio_ring(OF) virtio(OF) etxhci_hcd usb_storage xhci_hcd uhci_hcd ehci_pci ehci_hcd usbcore usb_common redpill(OF) [last unloaded: bromolow_synobios]
[  260.026023] CPU: 0 PID: 12009 Comm: synofoto-face-e Tainted: PF        C O 3.10.108 #42214
[  260.026023] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[  260.026023] task: ffff880048620040 ti: ffff880051fcc000 task.ti: ffff880051fcc000
[  260.026023] RIP: 0010:[<ffffffff81090492>]  [<ffffffff81090492>] smp_call_function_many+0x262/0x290
[  260.026023] RSP: 0000:ffff880051fcfc68  EFLAGS: 00000202
[  260.026023] RAX: ffff88007dd15cc8 RBX: 0000000000000000 RCX: 0000000000000002
[  260.026023] RDX: ffff88007dd15cc8 RSI: 0000000000000008 RDI: 00000000000000ff
[  260.026023] RBP: ffff88007dd95cc8 R08: ffff88007dc139c8 R09: 0000000000000020
[  260.026023] R10: 0000000000004f5c R11: 0000000000000000 R12: 0000000000000000
[  260.026023] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff81893940
[  260.026023] FS:  00007f6a7dffb700(0000) GS:ffff88007dc00000(0000) knlGS:0000000000000000
[  260.026023] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  260.026023] CR2: 00007f6a22001048 CR3: 00000000486c0000 CR4: 00000000000006f0
[  260.026023] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  260.026023] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  260.026023] Stack:
[  260.026023]  ffff88007dc139c8 ffff88007dd93980 0000000181893940 0000000000013980
[  260.026023]  ffff88007a0c0400 ffff880051fcfcf8 ffff88007a0c06d8 00007f6a22001048
[  260.026023]  ffffea0000f97bc0 ffff88004747e008 ffffffff81030372 ffff88007a0c0400
[  260.026023] Call Trace:
[  260.026023]  [<ffffffff81030372>] ? flush_tlb_page+0x72/0x130
[  260.026023]  [<ffffffff81117572>] ? ptep_clear_flush+0x22/0x30
[  260.026023]  [<ffffffff81106a0d>] ? do_wp_page+0x2ad/0x8c0
[  260.026023]  [<ffffffff81107e6d>] ? handle_pte_fault+0x38d/0x9e0
[  260.026023]  [<ffffffff81108775>] ? handle_mm_fault+0x135/0x2e0
[  260.026023]  [<ffffffff814aba0a>] ? __do_page_fault+0x14a/0x500
[  260.026023]  [<ffffffff8128e94c>] ? rwsem_wake+0x3c/0x50
[  260.026023]  [<ffffffff81294ee7>] ? call_rwsem_wake+0x17/0x30
[  260.026023]  [<ffffffff814aff11>] ? system_call_after_swapgs+0xae/0x13f
[  260.026023]  [<ffffffff814a8883>] ? error_swapgs+0xa4/0xba
[  260.026023]  [<ffffffff814a8877>] ? error_swapgs+0x98/0xba
[  260.026023]  [<ffffffff814a8883>] ? error_swapgs+0xa4/0xba
[  260.026023]  [<ffffffff814a8877>] ? error_swapgs+0x98/0xba
[  260.026023]  [<ffffffff814a8883>] ? error_swapgs+0xa4/0xba
[  260.026023]  [<ffffffff814a8877>] ? error_swapgs+0x98/0xba
[  260.026023]  [<ffffffff814a8883>] ? error_swapgs+0xa4/0xba
[  260.026023]  [<ffffffff814a8877>] ? error_swapgs+0x98/0xba
[  260.026023]  [<ffffffff814a8883>] ? error_swapgs+0xa4/0xba
[  260.026023]  [<ffffffff814a8592>] ? page_fault+0x22/0x30
[  260.026023] Code: 8d 81 00 89 c1 0f 8e 1e fe ff ff 48 98 48 8b 13 48 03 14 c5 e0 8d 8a 81 f6 42 20 01 48 89 d0 74 c8 0f 1f 84 00 00 00 00 00 f3 90 <f6> 40 20 01 75 f8 eb b6 66 0f 1f 44 00 00 48 89 ea 4c 89 fe 44 

 

 

See https://github.com/RedPill-TTG/redpill-lkm/issues/21

 

 

On 9/14/2021 at 11:20 PM, ct85msi said:

I too have the same behaviour. It sees the usb boot stick.

 


[  919.179145] Initializing XFRM netlink socket
[  919.208029] Netfilter messages via NETLINK v0.30.
[  919.250782] audit: type=1325 audit(1631632358.130:13): table=nat family=2 entries=7
[  919.263884] audit: type=1325 audit(1631632358.143:14): table=nat family=2 entries=11
[  919.283309] audit: type=1325 audit(1631632358.162:15): table=filter family=2 entries=12
[  919.391771] IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready
[  921.892097] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sda
[  921.892479] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  922.134939] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdb
[  922.135304] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  922.294586] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdc
[  922.294954] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  922.329003] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdd
[  922.329449] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  927.976524] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sda
[  927.976892] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  928.210894] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdb
[  928.211301] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  928.424925] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdc
[  928.425326] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  928.430552] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdd
[  928.430919] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  929.973230] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sda
[  929.973598] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  930.207479] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdb
[  930.207873] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  930.449786] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdc
[  930.450221] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  930.455797] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdd
[  930.456246] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  938.389994] audit_printk_skb: 84 callbacks suppressed
[  938.390268] audit: type=1123 audit(1631632377.270:44): pid=15145 uid=0 auid=4294967295 ses=4294967295 msg='cwd="/" cmd=7069686F6C652D46544C2074657374 terminal=? res=success'
[  945.354303] <redpill/smart_shim.c:794> Handling ioctl(0x128b) for /dev/sdq
[  945.354684] <redpill/smart_shim.c:809> sd_ioctl(0x128b) - not a hooked ioctl, noop
[  945.398283] <redpill/smart_shim.c:794> Handling ioctl(0x128b) for /dev/sdq
[  945.398665] <redpill/smart_shim.c:809> sd_ioctl(0x128b) - not a hooked ioctl, noop
[  945.646231] <redpill/smart_shim.c:794> Handling ioctl(0x128b) for /dev/sdq
[  945.646619] <redpill/smart_shim.c:809> sd_ioctl(0x128b) - not a hooked ioctl, noop
[  945.649615] <redpill/smart_shim.c:794> Handling ioctl(0x128b) for /dev/sdq
[  945.649980] <redpill/smart_shim.c:809> sd_ioctl(0x128b) - not a hooked ioctl, noop
[  945.839342] <redpill/smart_shim.c:794> Handling ioctl(0x5331) for /dev/sdq
[  945.839709] <redpill/smart_shim.c:809> sd_ioctl(0x5331) - not a hooked ioctl, noop
[  945.845348] <redpill/smart_shim.c:794> Handling ioctl(0x5331) for /dev/sdq
[  945.845716] <redpill/smart_shim.c:809> sd_ioctl(0x5331) - not a hooked ioctl, noop
[  946.061469] <redpill/smart_shim.c:794> Handling ioctl(0x5331) for /dev/sdq
[  946.061834] <redpill/smart_shim.c:809> sd_ioctl(0x5331) - not a hooked ioctl, noop
[  952.472659] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sda
[  952.473047] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  952.639016] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdb
[  952.639381] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  952.723082] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdc
[  952.723448] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  952.728590] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdd
[  952.729015] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  953.209624] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sda
[  953.210028] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  953.391592] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdb
[  953.391989] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  953.608714] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdc
[  953.609107] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  953.618258] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdd
[  953.618626] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  962.993685] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sda
[  962.994052] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  962.999312] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdb
[  962.999702] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  963.003186] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdc
[  963.003600] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  963.004214] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdd
[  963.004628] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[  965.265597] <redpill/smart_shim.c:794> Handling ioctl(0x128b) for /dev/sdq
[  965.265963] <redpill/smart_shim.c:809> sd_ioctl(0x128b) - not a hooked ioctl, noop
[  965.289347] <redpill/smart_shim.c:794> Handling ioctl(0x128b) for /dev/sdq
[  965.289730] <redpill/smart_shim.c:809> sd_ioctl(0x128b) - not a hooked ioctl, noop

 

xpeno error.png

We know it's an issue create by you but we're leaving a link to have trace here: https://github.com/RedPill-TTG/redpill-load/issues/30
Thank you for creating this is an issue so we can track it easier ;)

 

 

On 9/14/2021 at 11:22 PM, scoobdriver said:

 

*edit it was @pocopico I was meant to quote not Witewulf. apologies

It was Bromolow , I found them thank you (search not working for tg3, but tg3.ko works :)

 

So I need to insmod libphy.ko and tg3.ko .

do you know can I unpack rd.qz with 7z in windows (after mounting first partition of the .img file) 

then add the modules . 

then add insmod lines (any issue with waiting for libphy.ko to load first )

repack rd.qz with 7z 

Now you can use extensions instead of tinkering with rd.

 

 

On 9/15/2021 at 12:35 AM, pocopico said:

 

Try this and see if it works for you. Its for 3615 v7.0.1. Extract and rename to rd.gz on first partition if you are booting with legacy bios or second if you are booting with EFI.

 

- I have added inetd start by default (telnet will work as soon as you get ip from DHCP for troubleshooting)

- modules tg3, mptsas, mpt3sas, vmxnet3.ko, libphy.ko

 

Of course there is another way to load extra modules but i havent had the time to try yet.

 

rd.gz.microserver.7z 8.08 MB · 59 downloads

Do you feel comfortable publishing these modules as extensions?
Also, there's an issue for the telnet. We think it can be made an extension as well: https://github.com/RedPill-TTG/redpill-load/issues/31=

 

 

On 9/15/2021 at 2:17 AM, matyyy said:

Anyone have idea why when i install mariadb on DSM 7.0.1 my server get freeze? CPU 100% load and timeout 😕 (in docker and in synology package) - newest kernel RedPill and ESXI.

https://github.com/RedPill-TTG/redpill-lkm/issues/21

 

 

On 9/15/2021 at 2:20 AM, ct85msi said:

I think 7.0.1 has more under the hood changes than 7.0 or more under the hood bugs. Thinking to revert to 6.2.4-25556 and apply update 2 to mitigate Synology-SA-21:22 DSM but leaves still vulnerable to Synology-SA-21:25. 21:25 isn`t that important, only local users can exploit the vulnerability.

v7 is a huge beta... on 36**xs we will call it an alpha., and we're not talking about RP+v7 but overall v7. In our production environment no [real syno] devices are running v7 as the real gain is minuscule in comparison to alllll the bugs (some potentially causing data loss) which are there. Give it 6-8 months at least.

 

 

On 9/15/2021 at 5:02 AM, haydibe said:

... this kind of makes me wonder if I should release the toolchain loader with just the ttg repos in the global_settings.json, and let everyone add their own repos for everything custom. Afterall the global_settings.json is designed to support that szenario.   

The issue here is that if we recommend to users to use random forks where everyone changes random things it will be really impossible to support in any way from our end. This will end up with "oh, I used this fork mixed with that which changed 10 scripts and it's broken - why?" :D Not that we want to discourage forking in any way but we already see a flow of issue from forks where users are confused and create issue that modules are not being copied where this was hacked around in one of the forks.
Thank you for stripping the custom forks from the image - we think the forks are great for tinkering by developers but when users try to use them without any knowledge of what they really it's a recipe for a fire in a forest. This was nicely shown by the quick supportsystemtemperature hack which breaks more than it fixes. We already see people putting toolchain version in their signatures which shows us they don't understand that the actual toolchain doesn't affect how the loader works and that it's only used to create the build environment.

 

 

On 9/15/2021 at 6:54 AM, psychoboi32 said:

@ThorGroup Is there any way to get S.M.A.R.T data when you hdd passthrough as scsi i passed through hdd which connected on LSI SaS it worked like expected but showing qemu drive and wrong temp because adding LSI sas driver will might work but idk i failed many times

a4d703fd007c2f28194c43f5e2aef21a.jpg

recently switched my main nas to this yes i have backup don’t worry emoji6.png trying what we can archive if we don’t have working drivers in future
dsm 7.0.1

edit :- we can have smart data on proxmox webui ok that is other side

edit :- serial is spamming “generating fake smart”

 


[  269.267949]  sd_ioctl(HDIO_DRIVE_CMD ; ATA_CMD_ID_ATA) failed with error=-22, attempting to emulate something[  269.269528]  Generating completely fake ATA IDENTITY[  269.271472]  Handling ioctl(0x30d) for /dev/sdl[  269.272409]  sd_ioctl(0x30d) - not a hooked ioctl, noop[  269.273462]  Handling ioctl(0x31f) for /dev/sdl[  269.274459]  sd_ioctl(HDIO_DRIVE_CMD ; ATA_CMD_ID_ATA) failed with error=-22, attempting to emulate something[  269.276229]  Generating completely fake ATA IDENTITY[  273.120359]  Handling ioctl(0x31f) for /dev/sdh[  273.121174]  Got SMART *command* - looking for feature=0xd0[  273.122451]  Generating fake SMART values[  275.790673]  Handling ioctl(0x30d) for /dev/sdh[  275.791803]  sd_ioctl(0x30d) - not a hooked ioctl, noop[  275.792771]  Handling ioctl(0x31f) for /dev/sdh[  275.793646]  sd_ioctl(HDIO_DRIVE_CMD ; ATA_CMD_ID_ATA) failed with error=-22, attempting to emulate something[  275.795185]  Generating completely fake ATA IDENTITY[  275.797133]  Handling ioctl(0x30d) for /dev/sdi[  275.797975]  sd_ioctl(0x30d) - not a hooked ioctl, noop[  275.798938]  Handling ioctl(0x31f) for /dev/sdi
 



Sent from my iPhone using Tapatalk

"Generating completely fake SMART" means that DSM asked for SMART data using ATAPI interface and your LSI rejected that request and so that RP stepped in and provided something fake to make the DSM use the disk at all. Theoretically it would be possible for RP to ask the SAS controller for the SMART using the SAS way and translate that information but this isn't a simple project. There are at least 6 different ways of asking for SMART. Three of them (!) are incorporated in parts (!!) into ATA/ATAPI. Of course SAS went a different direction and has way different ways of requesting and reporting SMART. It's a mess. With native syno SAS support their controllers seem to support ATAPI on SAS (probably custom firmware) and this is why on real hardware it "just works".
Feel free to put an issue on GitHub in the redpill-lkm repo so we don't forget. However, we're certain it wouldn't be implemented very soon (but most definitely we would love to have that feature).

 

 

On 9/15/2021 at 6:57 PM, WiteWulf said:

No, it's weird, someone else (@altas?) contacted me with exactly the same problem. Mine "just works" and continues to output to the vsp, it even offers me a login prompt. I'm running with Advanced iLO license on my system (only cost me £10 on eBay) which also allows for virtual boot media.

 

Just to be clear, to access the console, I:

- ssh to the ilo, ie. 'ssh Administrator@diskstation-ilo'

- from the </>hpiLO-> prompt I issue the 'vsp' command to launch the virtual serial port

- I don't login if all I want to see is console output


 % ssh Administrator@diskstation-ilo
Administrator@diskstation-ilo's password: 
User:Administrator logged-in to diskstation-ilo.osx.ninja(192.168.1.11 / FE80::D2BF:9CFF:FE45:F58A)

iLO Advanced 2.78 at  Apr 28 2021
Server Name: diskstation-iLO
Server Power: On




</>hpiLO-> vsp

Virtual Serial Port Active: COM1

Starting virtual serial port.
Press 'ESC (' to return to the CLI Session.


Password: [ 6968.613699] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sda
[ 6968.614727] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdb
[ 6968.614728] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[ 6968.616323] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdc
[ 6968.616324] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[ 6968.617563] <redpill/smart_shim.c:794> Handling ioctl(0x2285) for /dev/sdd
[ 6968.617564] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop
[ 6968.859345] <redpill/smart_shim.c:809> sd_ioctl(0x2285) - not a hooked ioctl, noop

 

As for the iLO 4 Advanced there's a beta key which happens to work on retail version. We don't know how legal is to use it but if you google it you can find it for free. Did they leve it on purpose? Is it some sort of an engineering key? Who knows. Most likely these keys for few bucks on ebay are these resold beta keys.

 

 

On 9/15/2021 at 7:01 PM, WiteWulf said:

@scoobdriver @altas I've just had a grep through /var/log/synobootup.log on my system and can't see any reference to 'redpill/uart_swapper', which seems to be the culprit for you two.

 

Here's the code, see if you can figure out what's going on:

https://github.com/RedPill-TTG/redpill-lkm/blob/master/internal/uart/uart_swapper.c

 

It seems to be a module written to "fix" behaviour in some kernels that erroneously swaps the console output to an alternate tty by swapping it back again. For some reason this is being called unnecessarily on your systems, and swapping the console output away from your active, functioning virtual tty. FYI, I'm running a bromolow 7.0.1-RC1 42214 image.

 

I don't know why this is happening for you, or why it's not happening for me. Closer inspection of the code (or explanation from @ThorGroup) may help.

The swap has to be done 100% of the time on 3615xs. The only time when you would want to leave it swapped is if you did swap them in your BIOS (i.e. set first serial port to 0x2F8 instead of 0x3F8).

 

 

On 9/15/2021 at 7:32 PM, scoobdriver said:

@pocopico

Thank you for your rd.gz with the .ko's for the Gen8 onboard NIC .. 

on bare metal this boots, and I am able to see the machine on the network and reach the Web assistant . 

At this moment it is not seeing my HDD , (on a HBA card flashed IT ) 

not sure if I need to modify the DiskIdxMap values or SataPortMap (I did with Juns) 

 

However I am seeing these and other args / parameters not been recognised and been ignored as per the serial output below (Iv'e removed my real Mac and Serial) 

is anybody else seeing this  ?

 


[    2.150381] Freeing initrd memory: 34164k freed
[    2.156393] redpill: module verification failed: signature and/or required key missing - tainting kernel
[    2.159947] <redpill/redpill_main.c:44> ================================================================================================
[    2.164332] <redpill/redpill_main.c:45> RedPill v0.5-git-021ed51 loading...
[    2.167431] <redpill/call_protected.c:55> Got addr ffffffff8119d370 for cmdline_proc_show
[    2.170194] <redpill/cmdline_delegate.c:322> Cmdline count: 410
[    2.172284] <redpill/cmdline_delegate.c:389> Cmdline: BOOT_IMAGE=/zImage mac2=001122334455 DiskIdxMap=0C00 mac1=001122334456 netif_num=1 earlycon=uart8250,io,0x3f8,115200n8 syno_hdd_powerup_seq=0 vid=0x058f syno_hdd_detect=0 pid=0x6387 console=ttyS0,115200n8 sata_pcislot=5 elevator=elevator sn=1560LWN004120 root=/dev/md0 SataPortMap=8 earlyprintk loglevel=15 log_buf_len=32M syno_port_thaw=1 HddHotplug=0 withefi syno_hw_version=DS3615xs vender_format_version=2
[    2.172284] 
[    2.186333] <redpill/cmdline_delegate.c:401> Param #0: |BOOT_IMAGE=/zImage|
[    2.188639] <redpill/cmdline_delegate.c:296> Option "BOOT_IMAGE=/zImage" not recognized - ignoring
[    2.191645] <redpill/cmdline_delegate.c:401> Param #1: |mac2=001122334455|
[    2.193899] <redpill/cmdline_delegate.c:284> Set MAC #1: 001122334455
[    2.195989] <redpill/cmdline_delegate.c:401> Param #2: |DiskIdxMap=0C00|
[    2.198210] <redpill/cmdline_delegate.c:296> Option "DiskIdxMap=0C00" not recognized - ignoring
[    2.201164] <redpill/cmdline_delegate.c:401> Param #3: |mac1=001122334456|
[    2.203441] <redpill/cmdline_delegate.c:284> Set MAC #2: 001122334456
[    2.205575] <redpill/cmdline_delegate.c:401> Param #4: |netif_num=1|
[    2.207673] <redpill/cmdline_delegate.c:239> Declared network ifaces # as 1
[    2.209984] <redpill/cmdline_delegate.c:401> Param #5: |earlycon=uart8250,io,0x3f8,115200n8|
[    2.212866] <redpill/cmdline_delegate.c:296> Option "earlycon=uart8250,io,0x3f8,115200n8" not recognized - ignoring
[    2.216276] <redpill/cmdline_delegate.c:401> Param #6: |syno_hdd_powerup_seq=0|
[    2.218675] <redpill/cmdlinelegate.c:296> Option "syno_hdd_powerup_seq=0" not recognized - ignoring
[    2.322084] <redpill/cmdline_delegate.c:401> Param #7: |vid=0x058f|
[    2.324158] <redpill/cmdline_delegate.c:108> VID override: 0x058f
[    2.326209] <redpill/cmdline_delegate.c:401> Param #8: |syno_hdd_detect=0|
[    2.328484] <redpill/cmdline_delegate.c:296> Option "syno_hdd_detect=0" not recognized - ignoring
[    2.331519] <redpill/cmdline_delegate.c:401> Param #9: |pid=0x6387|
[    2.333548] <redpill/cmdline_delegate.c:142> PID override: 0x6387
[    2.335521] <redpill/cmdline_delegate.c:401> Param #10: |console=ttyS0,115200n8|
[    2.337920] <redpill/cmdline_delegate.c:296> Option "console=ttyS0,115200n8" not recognized - ignoring
[    2.341013] <redpill/cmdline_delegate.c:401> Param #11: |sata_pcislot=5|
[    2.343186] <redpill/cmdline_delegate.c:296> Option "sata_pcislot=5" not recognized - ignoring
[    2.345976] <redpill/cmdline_delegate.c:401> Param #12: |elevator=elevator|
[    2.348211] <redpill/cmdline_delegate.c:296> Option "elevator=elevator" not recognized - ignoring
[    2.351154] <redpill/cmdline_delegate.c:401> Param #13: |sn=1560LWN004120|
[    2.353394] <redpill/cmdline_delegate.c:45> S/N set to: 1560LWN004120
[    2.355481] <redpill/cmdline_delegate.c:401> Param #14: |root=/dev/md0|

 

You can modify these values in the config if you need to move drives around. Don't modify them blindly - you need to understand it ;)

 

 

On 9/15/2021 at 7:34 PM, scoobdriver said:

 

Wonder if it is this line which seems like it is been ignored along with other parameters 

 

[    2.335521] <redpill/cmdline_delegate.c:401> Param #10: |console=ttyS0,115200n8|

[    2.337920] <redpill/cmdline_delegate.c:296> Option "console=ttyS0,115200n8" not recognized - ignoring

That ignore message means the RP ignored it as it doens't need to do anything with it. The kernel itself interprets that properly and configures the serial port. The issue is on 3615xs syno swapped ttyS0 and ttyS1, so if you type ttyS0 to the kernel it will really start sending data to a physically soldered port ttyS1 on the motherboard.

 

 

On 9/15/2021 at 8:10 PM, Aigor said:

Forgive me if i'm dumb, if i would build loader for 7.01 for HP Gen8 Microserver, how should i do? 
Can i perform direct upgrade in place without lost config and data? 
Should i backup, perform new installation and restore? 
Which process should be better with balance between data integrity and less operation? 

many thanks 
 

You can swap the loader image and boot - then it will prompt you for PAT and just migrate as normal. But as others said: you should always have a backup as RAID is not a backup. Even if you run a ZFS on an official system for iX you should do a backup :D
We are amazed by r/DataHoarders and their backups of 4-digit number of TBs.

...you do have a backup, right.... right?....right?

 

On 9/16/2021 at 1:20 AM, spikexp31 said:

Heya Redpill Community,

 

I am following your progress and this is truly amazing. I am really excited to test DSM 7+ on my Gen8 running ESXI 7.02 for now.

Unfortunately, I don't have enough skills to compile a loader within docker, as I don't clearly understand the entire process (shame for an IT guy), so i will wait when first release will arrive.

There will be a clear instruction with the beta - stay tuned.

 

 

On 9/16/2021 at 2:28 AM, WiteWulf said:

For some reason, since updating to the latest redpill version (Monday 13th of September), I can no longer mount /dev/synoboot1 in my running server. I'm absolutely certain I did this recently to edit the grub.cfg and update the MAC addresses in there, but I get the following now:


bash-4.4# mount /dev/synoboot1 /mnt/synoboot1
mount: /mnt/synoboot1: wrong fs type, bad option, bad superblock on /dev/synoboot1, missing codepage or helper program, or other error.

 

It's not the end of the world, but it was handy being able to edit the bootloader stick when it was still plugged in inside the server and just reboot it for changes, rather than having to take it out and edit it in another machine.

 

Am I doing something wrong?

 

FWIW, disk still thinks the device is valid:


bash-4.4# fdisk /dev/synoboot

Welcome to fdisk (util-linux 2.33.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/synoboot: 14.9 GiB, 16018046976 bytes, 31285248 sectors
Disk model: USB Flash Drive         
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 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

 

This is an annoying "feature" of syno you've discovered few posts after :D The reason why it works from dev is that they implemented that security feature rather poorly. Normally to disable it you need to do "echo 1 >/proc/sys/kernel/syno_install_flag" and then you can mount /dev/synoboot freely. Keep in mind (or rather others reading it as you seem to know what you are doing) you should NOT edit ANY files in the image manually.

 

 

On 9/16/2021 at 5:07 AM, Kouill said:

Works on hp microserver gen8 baremetal with onboard nic

bromolow-7.0.1-42214

 

I used the tg3.ko from

Extract the rd.gz, put the *.ko on \usr\lib\modules

Add insmod in linuxrc.syno.impl like this :

 

    insmod /lib/modules/libphy.ko

    insmod /lib/modules/tg3.ko

Repack rd.gz

And make the first partion active on the sd card

 

Thanks :)

 

Please, use the extension mechanism instead since we have it now.

 

 

On 9/16/2021 at 8:08 AM, Ermite said:

Installed bromolow-7.0.1-42214 to my HP N54L.
I was used Jun's Loader 1.03b (DSM 6.2.3) and all HDD fully migrated with no error. (only keep my data, drop before config)
and it work well, but some part is not work.

1. Info Center - General tab is blank.
2. USB UPS cannot work. I'm using APC UPS, it worked with 6.2.3.
 

Screen Shot 2021-09-16 at 09.03.25.png

Screen Shot 2021-09-16 at 09.03.48.png

General tab is fixed for some time now (hwmon emulation).

 

 

On 9/16/2021 at 10:22 AM, D.S said:

I just compiled the driver but haven't tested yet. You may need to load crc-itu-t.ko first.

AQC107.zip 3.23 MB · 16 downloads

Can you publish the driver as an extension instead?

 

 

On 9/16/2021 at 4:05 PM, WiteWulf said:

Yeah, that'll definitely be it.

 

At this point I'd like to take the opportunity to thank @ThorGroup for the excellent quality of their code commenting, it's really very professional and makes figuring out stuff like this much easier.

We always try - all of us work/worked in development professionally and we realize how hard is to work with "clever" code. YOU know how it works when you wrote it. A week later neither you nor your friends know what's going on and everybody starts avoiding that part of the code like fire... after a year or two you have the same functionality implemented 5x by 10 different people and nobody knows what's going on. With RP we try to avoid that. It's nice that someone sees that effort.

 

 

On 9/16/2021 at 4:29 PM, Orphée said:

Hi guys!

I need some explanation about Proxmox passtrough / SMART vs ESXi...

 

I'm using ESXi and never played with Proxmox.

 

Refering to my current issue with ESXi : https://github.com/RedPill-TTG/redpill-lkm/issues/19

 

I'm using ESXi 7.0 with a LSI 9211-8i IT SAS card.

 

As VMWare dropped this card support with 7.x it can't work on VMWare directly (So can't use RDM unless I revert back to esxi 6.7). But until now, with Jun's loader. I'm able to passtrough PCI the card directly to the Xpenology VM and it works totally fine.

 

But with Redpill loader, until @ThorGroup maybe find a workaround, I would like to know how Proxmox with these type of cards.

 

Is Proxmox able to give the disk with SMART data working in Xpenology without a full passtrough like ESXi ?

 

With ESXi 6.7 I was able to give disks to VM as RDM, but SMART then was KO. The only way to make SMART work always were to passtrough the whole LSI card directly to VM.

 

Thanks for your explanations :)

 

Edit : By the way, did someone try to give disk to redpill loader with RDM on ESXi ? does it work ? (I can't test)

The only way to get SMART working is to pass the whole HBA device. In theory QEmu and others could proxy and filter SMART commands per drive but there's too great surface for attacks and weird behaviors for QEmu/VMWare to do it. You have to remember that "SMART" is really a combination of multiple unofficial ATA commands which were glued together by different manufactures. Then ATAPI tried to codify them and we got a ... huge mess held with several rolls of duct tape. This is why we have to step around a lot of undefined behaviors (like optional log directory SMART command which breaks DSM if it's not supported... but it's officially optional but someone assumed it's always there as modern drives support it).

 

 

On 9/16/2021 at 7:38 PM, WiteWulf said:

So, after doing some googling, it seems Synology have dropped support for ALL USB devices other than storage in DSM 7. This is causing problems for lots of people with USB TV tuners, DACs, WiFi, serial ports, zigbee interfaces, Bluetooth, printers, you name it. 
 

https://mariushosting.com/synology-how-to-add-usb-support-on-dsm-7/

Are they... serious? Sharing a printer is one of the few nice features people actually use on NASes. It seems like a great candidate for an RP extension to run that script on boot :D Maybe you will like to contribute and create such one so it's an easy install?

 

 

On 9/16/2021 at 8:22 PM, pocopico said:

 

Hi, I really doubt that they will fit inside the loader image as the ramdisk at least for MBR cannot exceed certain size. But whats the purpose of nvidia drivers in xpenology ?  

 

There are guides how to install NVidia drivers directly from spk from synology. This is the way to really do it. They offer them for their "AI" survivalence station model.

 

 

On 9/16/2021 at 11:25 PM, Orphée said:

Did someone try Synology Photo on DSM 7 ?

 

is it something expected ? :

image.thumb.png.4bce96139c8d68b846c5b1e2c50e188f.png

 

Edit : It seems to happen when I upload a picture with Firefox browser. does not happen with Chromium...

This is actually a bug in canvas on FF with to strict privacy settings. We saw that somewhere else outside of DSM. We tried to search for that but no luck. All in all that's not a bug in DSM but in FF. There are canvas security settings in FF - if you make them more permissive for DSM address it should work.

 

 

On 9/17/2021 at 12:26 PM, jumkey said:

for inetd create /usr/syno/etc/rc.d/J00inetd.sh

no need patch /etc/rc

 

or open http://IP:5000/webman/start_telnet.cgi

We think now it can be automated by an extension - let us know.

 

 

On 9/17/2021 at 12:58 PM, nemesis122 said:

I can confirm that i have the same Gen8 reboots sometimes and again  randomly so in this case i think htis kernel panic.

for the issue with the blank system info i add this line and is working

 

sed -i 's/supportsystemperature="yes"/supportsystemperature="no"/g' /etc.defaults/synoinfo.conf

sed -i 's/supportsystempwarning="yes"/supportsystempwarning="no"/g' /etc.defaults/synoinfo.conf

 

information for this line are here

https://gist.github.com/Izumiko/26b8f221af16b99ddad0bdffa90d4329

 

 

 

For anyone who finds this: please, don't do it. We explained in the previous update post that a HWMON emulation was needed instead as putting these lines in.

 

 

On 9/17/2021 at 2:49 PM, shibby said:

yesterday i tried upgrade my primary bare metal Xpenology from 6.2.3 to 7.0.1. The problem is that i have two sata controllers:

1st) on board, 2x HDD and 1x SSD M.2 - those drives are detected

2nd) miniPCIE to 2x SATA port, 1x HDD, 1x SATA SSD - those drives are NOT detected

 

H0af3bbef49fd4b5d975fe0be446becdeV.jpg

 

All 3x HDD has been used as SHR.

 

I tried figure out which kernel module is used by second controller. I found this:

sda/sdb/sdc are on first controller:

 

sdd/sde are on a second

 

but i cannot find pcieport module ("lsmod | grep pcie" return empty result)

 

in dmesq i found only:

 

About ASM1061 i found this patch

https://patchwork.kernel.org/project/linux-pci/patch/1315453426-8796-1-git-send-email-kengyu@canonical.com/#2458742

 

and probably this is it:

 

Can someone help me to compile "module?" this this patch? The problem is that ahci is build in kernel (not as module) but ata_generic probably is also required. I don`t know, how is this working on 6.2.3 ( i have added extra drivers by IG-88)

This is a standard AHCI controller. It should work out of the box - you're probably missing a proper Sata config extra_cmdline params and the drives connected to it "land" outside of the zone DSM scans.

 

 

On 9/17/2021 at 3:10 PM, dreamtek said:

Get another error,sad@haydibe

694059994__2021-09-17_15-06-06.thumb.png.38d78c9fd3f976dd21a7f59ff8688494.png

It seems like something wrong with the loop device

But when i use fdisk,it showed that the loopn* is there!

92685670__2021-09-17_15-07-02.png.c74403c9302f22c0af2ee73acae72475.png

This is fixed now - it's was a race condition between partscan in linux and loop attachement.

 

 

On 9/17/2021 at 3:41 PM, WiteWulf said:

Yeah, good point, only had one coffee so far today and hadn't thought of that :D  I'll add it next time I do a boot stick rebuild.

 

Of course it would be nice if the redpill shim could actually allow access to the monitoring hardware in the server and provide the temperature stats. I would have thought DSM was simply calling lm-sensors, but those tools don't appear to be on the system 🤔

There's a plan to support real sensors and "emulate" values by reading them from sensors modules but emulating fake ones was an easier starting point than translating lm-sensors to syno-HWMON. You can still install lm-sensors or any other monitoring tools you like and monitor everything. It's not like syno API is accessible outside of CPU temp and HDD temps.... sadly. At least on non-syno hardware you have an option to use Linux tools - on real ones people are annoyed that they can't. At least we now know /proc entry can be read by a custom script if needed. There are many threads on syno form askim them for some monitoring beyond CPU temp.

 

 

On 9/17/2021 at 4:16 PM, altas said:

it is not asp its vsp to start the Serial output on SSH.

 

in the grub file i set  console=ttyS1,115200n8 or ttyS0,115200n8

 

 

You should NOT change console parameter. This will break many things (DSM has secuyrity features checking for that parameter; RP assumes that it's at the platform-correct value etc.).

 

 

On 9/17/2021 at 5:00 PM, mcdull said:

I guess we should open another thread for helping others to use the loader and to leave this thread for development needs. 

now this thread is flooding with operational issue.

We think the ship has sailed :D We will open a new thread with the beta release (which only really misses SAS and container support if we remember our own roadmap correctly). This topic will be probably closed and we will get a new one strictly for dev with maybe some moderators help to keep the stuff seprated ;)

 

 

On 9/17/2021 at 5:15 PM, spv4u1975 said:

Hey all

 

I've can build fine thanks to the info on here but can someone advise how I build a 918 build it is always the 3615xs that gets created.

 

I know I would love a DVA version build to get AI CCTV running with the 6 licences and Nvidia, Is this on the roadmap/possible?

 

Thanks for al the hard work

DVA is on our roadmap for another reason - official NVidia drivers. The "AI" survivalence station is something which we personally have no interest in, but it will be there anyway if DVA is emulated.

 

 

On 9/17/2021 at 8:09 PM, WiteWulf said:

@Orphée I'm not seeing excessive CPU usage on my baremetal install, fwiw. Can you have a look at the output of 'top' and see what process(es) are responsible?

That excessive usage of CPU is actually a missed spinlock somewhere. The kernel doesn't monitor them in any way when debugging is disabled - it will "spin" [i.e. use all CPU cycles on a given core] forever if not unlocked. It's done that way in kernel as spinlocks usually last microseconds (so using other locks would waste even more CPU). When the lock is forgotten/lost somewhere a "deadlock" scenario arises. It will be detected only after some timeout and ideally when another lock tries to execute on the same CPU. It's very hard to debug that over all.

 

 

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

Answers will continue in a separate post, as this post cites maximum number of 50 posts ;)

  • Like 3
  • Thanks 4
Link to comment
Share on other sites

1 hour ago, ThorGroup said:

You should add that option as an extra_cmdline in user_conf instead.

that`s true, but when we don`t know what is correct value for our bare metal, then this is the easiest way for testing. And another thing, we can compile RP for other users (who cannot compile RP himself) and they have to only modify grub.cfg for his configuration (vid, pid, mac, sataportmap). We did this in previous loader by Jun, so community know how to do this without any broke :)

Link to comment
Share on other sites

1 hour ago, ThorGroup said:

This is a standard AHCI controller. It should work out of the box - you're probably missing a proper Sata config extra_cmdline

you are correct. I didn`t test it yet but now i know i should use SataPortMap=32 instead of 5 :)

Link to comment
Share on other sites

This post contains answers to questions up to beginning of page 84.

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

 

On 9/17/2021 at 8:55 PM, Orphée said:

What does this container actually ?

appart from freezing my VM and running CPU at 100% ? :D ?

 

 

2 tries, 2nd one with high privileges

image.thumb.png.f9cb49bbb31fb7d37053a0aea12eb821.png

had to reset system

It's a holy grail to catch WHAT is actually causing that 100% spike when it happens. This is the clue of where the spinlock is taken but not released. Kernel points at influxdb and other DBs but we're sure it's not that. It's somewhere in the kernel itself.

 

 

On 9/17/2021 at 10:02 PM, gldl said:

After each restart, the BIOS time is not accurate. 8 hours slower than the system time. What's the reason

This is perfectly correct. Windows uses local time in RTC and Linux uses UTC. The behavior of windows dates back to the MSDOS days. Linux actually follows ACPI specs. This is normal to see when you run any Linux on a PC as ancient RTC spec has no way of setting timezone. Just a small quirk - if you're not dualbooting windows you can just ignore that.

 

 

On 9/17/2021 at 10:11 PM, WiteWulf said:

@Orphée @nemesis122 @pocopico @erkify @dodo-dk

 

You've all said you're seeing docker-related crashes on your systems. Some of you are on baremetal, some using proxmox or ESXi. Can you please confirm whether you are running 3615xs or 918 images?

 

The trend (as spotted by abesus) seems to be that 3615xs setups are crashing while 918 are not.

 

Please confirm and I'll log an issue on the redpill-lkm GitHub repo. It would also be handy to know exactly what CPU you have in your machines.

 

(Some other people also mentioned they're seeing docker-related crashes, but I know they're on either HP Gen8 or Gen7 baremetal, so I know they're using ds3615xs images)

That is a very important clue - it may be something related to vUART driver we wrote as it uses a LOT of spinlocks.

 

 

On 9/17/2021 at 10:15 PM, rdidier75 said:

Hello,

 

I am on DS918+ Apollolake 7.01 (J3455-ITX - ASRock, with 8 drives) thanks to you !

Everything works perfectly expect  poweron :

 

image.thumb.png.35cdd1f3e895480494febf6445c4bcb9.png

 

and no access to this tab :

 

image.png.db77b677a1ae5418f8a62f5c969faf56.png

 

Is it the same for you ?

 

Thanks.

 

Do you mean auto power on? This feature is not supported - we didn't emulate it. Do you rely on it? Do you use it? We can add it - as we explained in one of the updates we didn't bother adding it as it isn't easy and it's broken on many motherboards anyway.
If you will like to see that feature added please open issue on GitHub in the redpill-lkm repository.

 

 

On 9/18/2021 at 1:51 AM, havast said:

https://skynet.zone/loader.7z

 

Here the working loader in VMDK format. I hope the masters will do a 3617xs version, i have a real sn / mac pair for that NAS. (I have a few real 918+ sn / mac pair too, but unfortunatelly my CPU is too old for that 😕

Hope i can find a soultion. I think its impossible to get a real 3615xs sn and mac :(

Please don't share the final image. Especially if the link points to any of your servers - the final image contains copyrighted material and may get you into troubles. We (and @WiteWulf below) explained it few times here already.
As for the 3617xs see the "mysteries.md" file in dsm-research repo on our GH - we aren't actively working on it right now for reasons described there. We probably come back to it when we have some spare time.

 

 

On 9/18/2021 at 9:37 PM, haydibe said:

Ah okay. Forget that I ever mention my observation regarding Ryzen cpus and old kernels :)

Ryzens + v3.10 is usually fixable by injecting newer microcode ;) But running a full ryzen bare metal with 3515xs.... why, just why? :D

 

 

On 9/20/2021 at 3:38 AM, WiteWulf said:

If so it's not hanging, it's just there's no more output to the screen from that point as there's no frame buffer driver in the Synology kernel. Jun's bootloader used to put a message on screen to this effect, something that would be quite helpful in redpill, too, I think.

 

(...)

That's a good addition actually - it's simple to add that in GRUB ;) Can you add an issue in the redpill-load repo maybe?

 

 

On 9/20/2021 at 12:36 PM, datahunter said:

RedPill is a great project !! I love it.

 

I think i hit a bug on the kernel module or dsm

Issure:

I running DS3615xs/6.2.4-25556 on Debian 10 with Qemu

The VM instance 's NIC has abnormal traffic.

Any materials i need to provide for debug ?

 

2.png

1.png

That isn't actually related to RP - you need to see on your router where the traffic is going, or try tcpdump on DSM itself to see where it sends/receives data.

 

 

On 9/20/2021 at 8:45 PM, Buny74 said:

Hi guys,

 

I'm actually on baremetal with my G8 and i plan to update to DSM 7.0.1 but i'm actually on a 3617 base.

If i build for a 3615 will it be possible to update my server from a 3617 ? 

 

Thanks

Yes, when we add 3617xs support you can just upgrade in-place. It will work like moving disks from one DS to another.

 

 

On 9/20/2021 at 9:01 PM, toyanucci said:

The initial boot takes 10 minutes to load the kernel or does every boot take 10 minutes?

Boot shouldn't take that long - it should take under a minute really.

 

 

On 9/21/2021 at 5:15 AM, dodo-dk said:

you can try to switch the cpu setting in Proxmox from kvm64 to haswell or something.

 

kvm64 don‘t work with facedetection on some systems. 

kvm64 has many instructions disabled. Ideally when you can you should use host every time for any VM (no matter what it is in general if you're running something modern).

 

 

On 9/21/2021 at 4:17 PM, Orphée said:

Did someone successfully updated from 6.2.4 to 6.2.4 update 2 ?

when I tried a week or two ago, update failed for me...

 

Edit :

Inside the update 2 PAT file, there is a flashupdate_6.2-25556-s2_all.deb

it contains :

image.thumb.png.c9bea1b5ae667a234170e8d5a09bd25f.png

We didn't look into that update but most likely just the flash updater has to be blocked overall (we blocked it based on other things but we didn't see an actual PAT to test it). Running it may just crash the machine.

 

 

On 9/21/2021 at 7:23 PM, Orphée said:

You then have no SMART support inside DSM.

Whereas HBA passtrough (on 6.2.3) makes SMART work inside DSM. So real DSM monitoring in case a disk dies.

image.thumb.png.e689f62ae3c04050c571e3cca3beeac9.png

This is a great point actually. Even VMWare discourages from passing disks itself (and SMART is just one of many issues with passing a disk). Passing disks is bad on any hypervisor we saw as SMART is not proxied. It could be but there are security issues with that so no hypervisor does that.

 

 

On 9/21/2021 at 8:01 PM, nemesis122 said:

my config looks like this but 

 

{
"extra_cmdline": {
"pid": "0x0001",
"vid": "0x46f4",
"sn": "1330LWNXXXXXX",
"mac1": "001132XXXXXX",
"DiskIdxMap": "1000",
"SataPortMap": "4",
},
"synoinfo": {
"supportsystemperature": "no",
"supportsystempwarning": "no"
},
"ramdisk_copy": {}
}

 

 

i need to add the second Networkdapater 

mac 2 and netif2  are there some other parameters as we have a list ?

 

is this correct like this :

{
"extra_cmdline": {
"pid": "0x0001",
"vid": "0x46f4",
"sn": "1330LWNXXXXXX",
"mac1": "001132XXXXXX",

"mac2": "001133XXXXXX",

"netif_num": "2",
"DiskIdxMap": "1000",
"SataPortMap": "4",
},
"synoinfo": {
"supportsystemperature": "no",
"supportsystempwarning": "no"
},
"ramdisk_copy": {}
}

 

 

thank you

Please, REMOVE supportsystemtemperature & supportsystemwarning. Actually to properly do that (since using that hack you actually damaged your OS) you should change them to "yes", boot once, and then remove them from your config.

 

 

On 9/22/2021 at 1:09 AM, stefauresi said:

My internet connection = 8G
Switch mikrotik SFP+ 10G / with RJ45 ethernet module 

Yes 10G it's necessary for me 😉 

 

We are jealous ^^ Eastern Europe?

 

 

On 9/22/2021 at 1:24 AM, D.S said:

I have experience on Aquantia (Qnap QXG-10G1T), I tried to put different version of driver (included compiled by myself) to the loader, but none of them is working. However, after installed DSM, just create a script and upload to "/usr/lib/modules-load.d/" then copy atlantic.ko to "/usr/lib/modules/", reboot and it will works. I attached the files if needed.

AQC107_0921.zip 3.23 MB · 28 downloads

You can now pack it into an extension. Let us know in case of problems.

 

On 9/22/2021 at 2:31 PM, nemesis122 said:

I have this Networkadapter Intel® Ethernet-Converged-Network-Adapter X520-DA2 please help me to add this driver to DSM 918+ Redpill Loader 

How can i add this driver to the image or to the maschine ?

 

thank you

ixgbe-5.12.5.tar.gz 506 kB · 8 downloads

You can now use an extension and RP will load it automatically on boot.

 

 

On 9/22/2021 at 6:53 PM, pocopico said:

 

while in ssh with root run 

 

# depmod -a 

# modprobe atlantic 

 

verify module is loaded with

 

# lsmod |grep -i atlantic

 

If it didn't load do a 

 

# insmod /usr/lib/modules/atlantic.ko and verify again.

 

If it doesnt load check dmesg output to see whats wrong 

 

Syno doesn't have depmod and use forceful/static insmod rather than intelligent modprobe.

 

 

On 9/22/2021 at 9:21 PM, Lazy775 said:

Hey, just compiled (and tried like, every redist online) RedPill and I'm stuck on 'starting kernel'.

 

This is the full output:

 

 

I get 0 output from serial port (I may have wired them incorrectly because I shoved a male connector to my board (also male)'s serial connector)

 

Is it like, BIOS specific setting in place or smtg?

 

*spec

LSI 9280-8i 

Asrock J4105

Problem persists with and without HDD

Whoever made that.... has no idea about the loader. We're sorry for harsh words but you CANNOT - ABSOLUTELY CANNOT - SAY that a single bootable image supports "6.2.4 to 7.0.1". Each version requires a static kernel patch. You can boot with an incompatible kernel - sure - but this is a disaster and nobody should ever do that. Never ever.

 

 

On 9/22/2021 at 11:05 PM, nemesis122 said:

Hi i have Asus 87iplus with 6 sata ports at the same controller when all hdd are connected i can install DSM 3615 redpill 7 but when not all HDD are connected i have the error message that 6 sata ports are disabled so i need the line in the grub.cfg sataports= 6 and i dont know exactly in which i have to write this line.

could you help me ?

 

menuentry 'RedPill DS3615xs v7.0.1-42214 RC (USB, Verbose)' {
    savedefault
    set root=(hd0,msdos1)
    echo Loading Linux...
    linux /zImage mac1=9C69Bxxxxxx netif_num=1 earlycon=uart8250,io,0x3f8,115200n8 syno_hdd_powerup_seq=0 vid=0x0951 syno_hdd_detect=0 pid=0x1665 console=ttyS0,115200n8 elevator=elevator sn=14Bxxxxxxxxxxxx root=/dev/md0 earlyprintk loglevel=15 log_buf_len=32M syno_port_thaw=1 HddHotplug=0 withefi syno_hw_version=DS3615xs vender_format_version=2 
    echo Loading initramfs...
    initrd /rd.gz
    echo Starting kernel with USB boot
}

You should NOT edit grub.cfg. If you want to change parameters you should use user_conf.json

 

 

On 9/23/2021 at 2:51 PM, jumkey said:

Pseudocode for compression


final int SIGN_LENGTH = 64;
// FIXME 可能是(4倍对齐 补00)的魔法值
final int MAGIC_LENGTH = 4;
long length = filesize("rd.cpio");
cli>lzma -9 rd.cpio
try (RandomAccessFile lzmaFile = new RandomAccessFile("rd.cpio.lzma", "rw")) {
    // add 00 and 64 byte 00 fake sign
    lzmaFile.setLength(((lzmaFile.length() + MAGIC_LENGTH - 1) / MAGIC_LENGTH) * MAGIC_LENGTH + SIGN_LENGTH);
    // rewrite lzma 8 byte uncompressed size from -1 to real size
    lzmaFile.seek(5);
    final ByteBuffer order = ByteBuffer.allocate(8).putLong(length).order(ByteOrder.LITTLE_ENDIAN);
    order.rewind();
    lzmaFile.writeLong(order.getLong());
    order.clear();
}

 

We love that! :D We will definitely look at compressing images on v7 as it's annoying they're not.

 

 

On 9/23/2021 at 3:25 PM, helixzz said:

 

Thanks, Piteball.

Really excited and can't wait to try out the new loader. I thought there is already some way to 'inject' driver file into the loader and DSM installer as well.

Then I will wait and also discover myself to see if I can help.

Now since the extensions are supported you can inject drivers ;) See the details in our last announcment post (scroll up - it should glow green as "popular").

 

 

On 9/23/2021 at 4:07 PM, dolbycat said:

j4105  dsm7.0.1 

 

During the power schedule function, auto power off works fine. But  auto power on doesn't work.

As we wrote in the post above - the auto power on is not supported by design as we got frustrated that out of  6 motherboards we tested it worked only on one and only with max 2 scheduled events. If you rely on it we can add it - please add an issue to redpill-lkm repo. It will come with a disclaimer "it may not work" as auto-poweron on PCs is very finicky and we cannot do more than ask the BIOS (or rather the RTC chip) "pretty please set the schedule".

 

 

On 9/23/2021 at 7:00 PM, pocopico said:

 

The rd.gz that exists on the loader + the zImage have to be the ones that are patched during the loader creation process. If you manually update using a pat file from Syno then you most probably will overwrite the rd.gz and zImage rendering your loader useless. 

 

All the redpill magic happens in these two files. You need to put back the redpill patched ones and not the ones from the update2 pat.

 

 

 

Actually the update shouldn't override files on synoboot1 (as these are treate more like a ROM on real devices and serve as a backup boot in case the synoboot2 fails), but attempting to boot the kernel from version A with OS files from version B will not end well... ever.

 

 

On 9/23/2021 at 9:53 PM, WiteWulf said:

Since moving to the latest redpill code (3474d9b) I'm finding my system less stable than it was before with respect to docker containers. My influxdb container would crash the system every time I started it, but the others I had were typically stable and non-problematic. I'm now seeing immediate kernel panics when starting a mysql container that previously didn't cause any problems.

 

I've gone back to a slightly older build (021ed51), and mysqld (operating as a database backend for librenms) starts and runs without problems.

This is sadly coincidental, as we didn't touch locks there :( We're still debugging that. The most annoying thing is that it actually doesn't crash very reliably on our gen 8s. It does but rarely.

 

 

On 9/23/2021 at 10:33 PM, xPalito93 said:

I started playing around with the redpill on two test rigs i have at work the last couple of days.

 

I have a HP AIO PC with a 6th gen I3 on it and two Sata drives.

I tried installing 918 on it on baremetal and everything works without any issues for now.

 

But today i started playing with ESXI 7.0 for the first time ever and i followed a tutorial posted a couple pages back.

 

It boots and i can find it on find.synology.com and it even detects two drives because it tells me it will erase the two drives connected.

But when i start the installation with the selected PAT file, it always stops at 56% and tells me the file is corrupt.

 

I tried creating the image with 0.9 and 0.10 and i tried DSM 7.0 & 7.0.1. I always get the same error.

 

Am i missing something? I never really worked with ESXI, i'm trying to learn as much as possible

 

The only thing i changed on the image is the Mac Address (i use a random mac adress like 123456abcdef) and i put the same address in the VM settings where you can select the network adapter. If i leave it on auto, it won't show up on the network.

PID and VID shouldn't matter right?

 

The other rig is an old fujitsu server which can only run 3615 but it won't detect any drives at all because of the LSI controller which is a known issue afaik.

 

 

You shouldn't use just any random MAC. There's many octets you can change but some have special meaning - just let ESXi (or whatever you use) generate it for you and put it in the user_conf. If you're just starting with virtualization we recommend Proxmox instead of ESXi for many reasons.

 

 

On 9/24/2021 at 1:04 AM, Aigor said:

A question, when "official release" will be available, we should  to make a new bootloader every time when a update will be available? 

 

TECHNICALLY yes, but in practice we want to make it in-place. So you just run a docker command on the DSM itself which will build everything and instead of spitting out the image it will just update the /dev/synoboot in-place. At which point you can just update from the DSM panel and reboot.
We didn't develop an auto-patching-on-boot as if you use any custom drivers you have to change them anyway and things get complicated quickly. Seeing as syno doesn't release updates very often (ok, maybe except broken v7 releases) it's not that big of a problem. Our priority is on stability (yes, we know how it sounds with the crashing 3615xs now but trust us ;)) rather than having a thread where users cry that they updated, rebooted and now the system is not working at all. That shouldn't be possible. In the hackintosh community it works similarly if you do everything right: you cannot accidentally update to an incompatible release.

 

 

On 9/24/2021 at 4:34 PM, stefauresi said:

Hi,

Question, Intel X520-DA1 driver is include ? (82599ES Chip)

 

If i buy an Synology E10G18-T2 , this card is natively recognize ?

 

Best regard

Check what they did rebrand :D Of course if you use their official NIC it will work but there are many cards which are just supported. The easiest way is to check which chipset their NICs use and find a generic from Intel/HP/Dell/etc. Sometimes Intel one will run you $150 but if you search by chipset you will find the same things branded with HP for $50. Like we have a lot of HP 360T deployed as they're solid Intel 2x1G NICs and are laughably cheap (like $15).

 

 

On 9/24/2021 at 11:49 PM, ghtester said:

Thanks again, this module can be load but leads to crash so I suppose it was compiled with generic kernel 3.10.108 sources. I tried that as well (and none of modules I needed was working) but as already confirmed by @ThorGroup, this is not a proper way (although maybe some drivers can work).

 insmod ata_piix/ata_piix.ko
Killed


[91701.976157] WARNING: module 'ata_piix' built without retpoline-enabled compiler, may affect Spectre v2 mitigation
[91701.987932] ata_piix 0000:00:1f.5: version 2.13
[91701.993164] ata_piix 0000:00:1f.5: MAP [
[91701.997551]  P0 -- P1 -- ]
[91702.151055] BUG: unable to handle kernel NULL pointer dereference at 000000000000001b
[91702.152013] IP: [<ffffffffa0edfdc7>] piix_init_one+0x527/0x8dd [ata_piix]
[91702.152013] PGD 78e74067 PUD 977a2067 PMD 0
[91702.152013] Oops: 0000 [#1] SMP
[91702.152013] Modules linked in: ata_piix(F+) fuse 8021q vhost_scsi(O) vhost(O) tcm_loop(O) iscsi_target_mod(O) target_core_ep(O) target_core_multi_file(O) target_core_file(O) target_core_iblock(O) target_core_mod(O) syno_extent_pool(PO) rodsp_ep(O) evdev(OF) button(OF) udf isofs loop synoacl_vfs(PO) btrfs zstd_decompress ecryptfs zstd_compress xxhash xor raid6_pq zram(C) glue_helper lrw gf128mul ablk_helper bromolow_synobios(PO) hid_generic usbhid hid usblp bnx2x(O) mdio mlx5_core(O) mlx4_en(O) mlx4_core(O) mlx_compat(O) qede(O) qed(O) atlantic_v2(O) atlantic(O) tn40xx(O) i40e(O) ixgbe(O) be2net(O) i2c_algo_bit igb(O) dca e1000e(O) sg dm_snapshot crc_itu_t crc_ccitt psnap p8022 llc zlib_deflate libcrc32c hfsplus md4 hmac sit tunnel4 ipv6 flashcache_syno(O) flashcache(O) syno_flashcache_control(O)
[91702.190422]  dm_mod cryptd arc4 sha256_generic sha1_generic ecb aes_x86_64 authenc des_generic ansi_cprng cts md5 cbc cpufreq_powersave cpufreq_performance acpi_cpufreq mperf processor thermal_sys cpufreq_stats freq_table vxlan ip_tunnel etxhci_hcd usb_storage xhci_hcd uhci_hcd ehci_pci ehci_hcd usbcore usb_common redpill(OF) [last unloaded: bromolow_synobios]
[91702.190422] CPU: 0 PID: 10438 Comm: insmod Tainted: PF        C O 3.10.108 #42214
[91702.190422] Hardware name: HP ProLiant ML110 G5/ProLiant ML110 G5, BIOS O15    10/25/2010
[91702.190422] task: ffff88009b585040 ti: ffff880071020000 task.ti: ffff880071020000
[91702.190422] RIP: 0010:[<ffffffffa0edfdc7>]  [<ffffffffa0edfdc7>] piix_init_one+0x527/0x8dd [ata_piix]
[91702.190422] RSP: 0018:ffff880071023b98  EFLAGS: 00010206
[91702.190422] RAX: ffffffffa0ee26b0 RBX: ffff8800b9793000 RCX: ffff8800a8efea58
[91702.190422] RDX: ffffffffa0ee26b0 RSI: 0000000000000282 RDI: ffffffff819b7080
[91702.190422] RBP: 0000000000000000 R08: ffff880071020000 R09: 0020ee39e1f9050d
[91702.190422] R10: ffffffffffffffff R11: 0000000225c17d03 R12: 0000000030000002
[91702.190422] R13: ffff8800b9793098 R14: 0000000000000000 R15: ffff8800b9793098
[91702.190422] FS:  00007fcfc8b3b540(0000) GS:ffff8800bda00000(0000) knlGS:0000000000000000
[91702.190422] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[91702.190422] CR2: 000000000000001b CR3: 0000000071e50000 CR4: 00000000000007f0
[91702.190422] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[91702.190422] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[91702.190422] Stack:
[91702.190422]  ffff880035e95358 ffffffffa0ee26a0 0000000000000000 00000003000000d0
[91702.190422]  ffff020281121167 ffff8800a8efea58 ffff880071023bd8 ffff880071023c10
[91702.190422]  0000000030000002 0000000000000000 000000000000001f 0000000000000007
[91702.190422] Call Trace:
[91702.190422]  [<ffffffff812b2f11>] ? pci_device_probe+0x71/0xb0
[91702.190422]  [<ffffffff81326431>] ? driver_probe_device+0x81/0x3e0
[91702.190422]  [<ffffffff8132684b>] ? __driver_attach+0x7b/0x80
[91702.190422]  [<ffffffff813267d0>] ? __device_attach+0x40/0x40
[91702.190422]  [<ffffffff8132458d>] ? bus_for_each_dev+0x5d/0x90
[91702.190422]  [<ffffffff81325a68>] ? bus_add_driver+0x208/0x2a0
[91702.190422]  [<ffffffffa0ee6000>] ? 0xffffffffa0ee5fff
[91702.190422]  [<ffffffff81326e49>] ? driver_register+0x69/0x170
[91702.190422]  [<ffffffffa0ee6000>] ? 0xffffffffa0ee5fff
[91702.190422]  [<ffffffffa0ee601a>] ? piix_init+0x1a/0x29 [ata_piix]
[91702.190422]  [<ffffffff810002ea>] ? do_one_initcall+0x2a/0x170
[91702.190422]  [<ffffffff81095149>] ? load_module+0x1b89/0x2540
[91702.190422]  [<ffffffff812a2cb0>] ? ddebug_proc_write+0xf0/0xf0
[91702.190422]  [<ffffffff81095c9d>] ? SYSC_finit_module+0x7d/0xc0
[91702.190422]  [<ffffffff814affbe>] ? system_call_fastpath+0x1c/0x21
[91702.190422]  [<ffffffff814aff11>] ? system_call_after_swapgs+0xae/0x13f
[91702.190422] Code: 4c 8b 71 70 48 89 04 24 48 8b 00 48 8d 50 10 83 38 ff 74 40 48 83 c0 04 48 39 c2 75 f2 41 81 7d a4 86 80 20 29 0f 84 f9 01 00 00 <41> f6 46 1b 20 74 22 49 8b 85 d0 02 00 00 48 85 c0 74 16 49 8b
[91702.190422] RIP  [<ffffffffa0edfdc7>] piix_init_one+0x527/0x8dd [ata_piix]
[91702.190422]  RSP <ffff880071023b98>
[91702.190422] CR2: 000000000000001b
[91702.582086] ---[ end trace a9f85e2570baadf7 ]---

 

 

I'll try to inject this driver to bootloader to see if it crashes there as well...

And also I'll try to run it on a proper hardware (tried on ML110G5 by mistake...)

Did you built it with old GCC? (like 4.9-old) You can't build modules for old kernels using new GCCs.

 

 

On 9/25/2021 at 6:28 AM, toyanucci said:

Can someone recommend a compatible nic?

 

I waited all week for a HP NC360T to be delivered only to realize it's a pcie x4 and my j4105 motherboard only has a pcie x1 slot 😑

 

The onboard realtek nic should be compatible but for some reason it isn't working for me so I want to try using another nic.

Pro tip: NC360T works in x1 slot :D You can either order a raiser from x1 to x4 or use a saw (no, we're not joking).
http://www.invisiblerobot.com/pcie_x1/ - you're trying this at your own risk but it does work and with 2x1Gb it shouldn't bottleneck.

 

 

On 9/25/2021 at 9:50 AM, dateno1 said:

redpill-tool-chain_x86_64_v0.11 Build Tested

 

6.2.4 is no warning or error but 7.0 has warning

 

usb.h warning is seemed easy to fix

 

Can you fix it at next version?

918_7.png

3615_7.png

That warning is [sadly] normal as we don't have sources for the kernel.

 

 

On 9/25/2021 at 5:05 PM, haydibe said:

Affirmative. Everything right on spot!

 

DSM6.2.4 builds use the kernel sources that are publicly available - thus the condition checks for the kernel sources beeing used is met and there is noreason to throw the warning.

 

From my perspective there is nothing wrong with the warning on DSM7 builds, as it's a constant reminder that we need to switch from toolkit-dev to the kernel sources as soon as they are publicly available. This warning is a functional warning, not a technical warning.

 

@dateno1 To "fix" this warning you just need to convince Synology to publish the DSM7 kernel sources 😃

 

 

That warning is there as we're using a struct which is... well... HOPEFULLY correct :D If it's not we may be in trouble. There's a slim chance it's not but who know what they tinkered with? It's working, but we are scared of the SATA boot on 918+ because of that. As we [hope] most of us are adults here there may have been few too many adult beverages when someone said "but guys guys listen... what if we EMULATE USB WITH SATA!" ... and as crazy as it sounds this is how the SATA boot was born on 918+ but the warning is there to scare away anyone from trying something like that with another crazy idea. It's just the toolkit headers don't come with full headers but only public ones (which is EXACTLY to prevent module authors from exploiting private API of the kernel).

 

 

On 9/25/2021 at 5:09 PM, Patt92 said:

Thanks for all the great work of all of you guys.

Got 7.0.1-42214 DS918+ running on KVM Virtualization (Qemu) on a Ryzen 5 Pro 4650G system.

For anyone struggling with it, I just used the toolkit for building the redpill image.

- DiskIdxMap 0C

- Redpill image on Sata 0:0 (Controller 0, Unit 0)

- HDDs on Sata Controller 2 (on 1 you can't find them)

- VID/PID should be irrelevant but I went for V: 0x46f4 and P: 0x0001

 

grafik.thumb.png.26e4e1d41af004b37ba4beffe328d1a5.png

The VID/PID with SATA boot is completely irrelevant. We just flat-out ignore it completely. There's even a warning in dmesg (which can be safely ignored, it's just more for analyzing logs) that these parameters were completely ignored.

 

 

On 9/25/2021 at 10:51 PM, imdgg said:

when i launch a container in Docker, the ds3615xs vm will crash

dsm version is 7.0.1

ds3615xs runs in esxi 6.7

cpu:E3 1265L v2

MB: DQ77KB

message.log:


2021-09-25T22:31:49+08:00 DS3615xs synofinderdb[12022]: synofinderdb.cpp:103 (main) synofinderdb tool desc: update synofinder.db
2021-09-25T22:31:50+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:31:55+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:32:00+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:32:25+08:00 DS3615xs synostgd-cache[5439]: SYSTEM:	Last message 'cache_monitor.c:2074' repeated 6 times, suppressed by syslog-ng on DS3615xs
2021-09-25T22:32:25+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:32:30+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:32:35+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:33:00+08:00 DS3615xs synostgd-cache[5439]: SYSTEM:	Last message 'cache_monitor.c:2074' repeated 6 times, suppressed by syslog-ng on DS3615xs
2021-09-25T22:33:00+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:33:05+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:33:10+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:33:35+08:00 DS3615xs synostgd-cache[5439]: SYSTEM:	Last message 'cache_monitor.c:2074' repeated 6 times, suppressed by syslog-ng on DS3615xs
2021-09-25T22:33:35+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:33:40+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:33:45+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:34:10+08:00 DS3615xs synostgd-cache[5439]: SYSTEM:	Last message 'cache_monitor.c:2074' repeated 6 times, suppressed by syslog-ng on DS3615xs
2021-09-25T22:34:10+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:34:15+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:34:20+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:34:45+08:00 DS3615xs synostgd-cache[5439]: SYSTEM:	Last message 'cache_monitor.c:2074' repeated 6 times, suppressed by syslog-ng on DS3615xs
2021-09-25T22:34:45+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:34:50+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:34:55+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:35:20+08:00 DS3615xs synostgd-cache[5439]: SYSTEM:	Last message 'cache_monitor.c:2074' repeated 6 times, suppressed by syslog-ng on DS3615xs
2021-09-25T22:35:20+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:35:25+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:35:30+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Can't support DS with cpu number (1)
2021-09-25T22:35:50+08:00 DS3615xs synostgd-cache[5439]: SYSTEM:	Last message 'cache_monitor.c:2074' repeated 5 times, suppressed by syslog-ng on DS3615xs
2021-09-25T22:35:50+08:00 DS3615xs synostgd-cache[9725]: cache_monitor.c:2074 [Error] Reach cache monitor error message limit

 

docker.log


2021-09-25T22:31:49+08:00 DS3615xs docker[11656]: time="2021-09-25T22:31:49.988360829+08:00" level=warning msg="Your kernel does not support cgroup blkio throttle.read_bps_device"
2021-09-25T22:31:49+08:00 DS3615xs docker[11656]: time="2021-09-25T22:31:49.988541818+08:00" level=warning msg="Your kernel does not support cgroup blkio throttle.write_bps_device"
2021-09-25T22:31:49+08:00 DS3615xs docker[11656]: time="2021-09-25T22:31:49.988720078+08:00" level=warning msg="Your kernel does not support cgroup blkio throttle.read_iops_device"
2021-09-25T22:31:49+08:00 DS3615xs docker[11656]: time="2021-09-25T22:31:49.988899380+08:00" level=warning msg="Your kernel does not support cgroup blkio throttle.write_iops_device"
2021-09-25T22:31:49+08:00 DS3615xs docker[11656]: time="2021-09-25T22:31:49.989077648+08:00" level=warning msg="Unable to find pids cgroup in mounts"
2021-09-25T22:31:50+08:00 DS3615xs docker[11656]: time="2021-09-25T22:31:50.296260650+08:00" level=error msg="failed to load container mount" container=a6774be8f04dff2e4331042223aa75400a7cbd9844261d6e7556c7d7f0e00df7 error="mount does not exist"
2021-09-25T22:31:52+08:00 DS3615xs docker[11656]: time="2021-09-25T22:31:52.414314874+08:00" level=warning msg="Failed to delete conntrack state for 172.17.0.2: invalid argument"
2021-09-25T22:31:52+08:00 DS3615xs docker[11656]: time="2021-09-25T22:31:52.550692280+08:00" level=warning msg="Error (Unable to complete atomic operation, key modified) deleting object [endpoint 7e3883ed93a23971685b1e68b3b0b933e39822d49c155e8e1b530fbc3ce04e4f dffd96d61caa97732569427dcb32acfd4941374e389cbfde4d7db78b9f7f915f], retrying...."
2021-09-25T22:31:53+08:00 DS3615xs docker[11656]: time="2021-09-25T22:31:53.184749410+08:00" level=warning msg="Could not get operating system name: Error opening /usr/lib/os-release: open /usr/lib/os-release: no such file or directory"
2021-09-25T22:31:53+08:00 DS3615xs docker[11656]: time="2021-09-25T22:31:53.185005296+08:00" level=warning msg="Could not get operating system version: Error opening /usr/lib/os-release: open /usr/lib/os-release: no such file or directory"

 

but ds918 is running stable in qnap Virtualization Station.

 

 

Something went bad... really really REALLY bad. But this is most likely the same annoying bug as with crashing influxdb and CPU soft lockup. See https://github.com/RedPill-TTG/redpill-lkm/issues/21
But also as @WiteWulf suggested DON'T use a single vCPU with one vCORE. Versions of DSM with >1 core assume in many places that the system has at least 2 cores. Don't ask us to comment on that :D Also you need at least 600MB ram (even if it technically runs on 512).

 

 

On 9/25/2021 at 11:21 PM, ilovepancakes said:

 

+1 for this! Would be great to run Surveillance Station with all those deep learning features.

So many people praise Surveillance Station... maybe we should actually try it. Slightly OT but if you're using it (or anyone else): do you recommend it? We mostly use Ubiquity gear for that and it's ... OK, but not really stable.

 

 

On 9/26/2021 at 2:14 AM, WiteWulf said:

Hi there, can you grab the serial console output from a crash before you roll take 7.0.1 off that Gen10? If you're not sure how, have a search of the forum for accessing the virtual serial port via iLO on the HP hardware, it's a common question.

Didn't they remove iLO from Gen10 and added as a separate purchase in Gen10+?

 

 

On 9/26/2021 at 3:08 AM, ct85msi said:

 

 


root@Apollo:~# cat /sys/class/hwmon/hwmon0/device/hwmon/hwmon0/temp1_input
37000

root@Apollo:/sys/class/hwmon/hwmon0# awk '{print $1/1000}' temp1_input
37

 

Before the latest changes, I had the default temperature of 40 C, probably sensors were not working and it showed the default minimum temperature like all the genuine synologys.

 

With the latest changes to redpill, I have CPU temperatures of ~60 degrees C. I think it`s pretty hot for a idle NAS. In bios and other linux distrib it idled around 40-45 C. I don`t think the latest changes to redpill read the sensors temperature ok.

 

I think the 37 degrees C from the terminal is the correct temperature.

 

thermal.png

That temperature isn't real. We wrote about this in a previous post. Currently we sweep-emulate fake temps and voltages inside of the kernel module (to satisfy HWMON subsystem). What we have on our todo list is adding real CPU temp - other params cannot really be read natively as there's no single standard which one is which sensor (you read sensors and which sensor is what depends on mobo/bios/configuration of the bios/boot mode/etc).

 

 

On 9/26/2021 at 3:33 AM, paro44 said:

I made a migration install on baremetal (Intel SS4200) and noticed some improvements to my first attempt some weeks ago.

I used the tool-chain v0.11 and bromolow 7.0 for DS3615xs. Maybe I made a mistake last time and filled vid/pid and not pid/vid (pay attention on that). DSM-install went smooth. This time I have all four internal disks accessable (on ICH7R chipset). Last time I could only see one hdd.

 

And now the Info-Center is filled and not empty anymore. I can see 2 cores and 2,2 GHz cpu speed, which could be the real data (I'm not sure, if I already changed the old celeron cpu to a core2duo 2,2 GHz, but I think I did). The cpu type is shown as i3-4130 which isn't correct (but for DS3615xs I think), but I can live with that 😀

 

Thanks again to all who help to make this working. I'm happy 'til now and will test further.

 

 

Edit: temperature is also shown at 60°C, but atm the storage pool is created. CPU load at 25%. Maybe it goes down when finished.

Temp is fake, cpu frequency is real, cpu model is.... whatever synology thinks it is :D The cpu model is just cosmetics, doesn't really affect anything - just a pretty thing to show on spec sheet (and its not read from the real microcode but guessed by mfgBIOS based on different parameters). We randomize temperature and then hover around it.

 

 

On 9/27/2021 at 10:24 AM, imdgg said:

 

when you see the boot menu,

choose SATA boot and press e to edit boot menu

add ‘DiskIdxMap=0c00 SataPortMap=1’ at the end of the boot args entry.

then press ctrl+x to boot

 

 

Don't edit manually the grub.cfg - add it to the user_conf in the extra_cmdline section.

 

 

On 9/27/2021 at 5:33 PM, Orphée said:

We don't have any /dev/dri/ on DS3615xs and Facedetection works on DSM 6.2.4 and DSM7 on my HP Gen8 running with ESXi.

I just had to set core numbers to 2 (instead of 2vCPU / 1 core, I changed to 2vCPU / 2 cores)

Of course I have real SN/MAC.

 

(It also works with Jun's loader DSM 6.2.3 with same setup)

 

But not listed as compatible by Synology... lol

https://kb.synology.com/en-ca/DSM/tutorial/Which_Synology_NAS_models_support_the_facial_recognition_feature_on_Synology_Photos

Be careful with setting multiple vCPUs - they tinkered with number of CPUs (not cores) in the kernel. It cannot be trusted to work properly on systems which ship with single CPU (i.e. all but some rack stations? do they even ship with 2 CPUs?).

 

 

On 9/27/2021 at 6:12 PM, andreika said:

I found my error.

I put mac address in configuration with ":" symbols. Removing symbols fixed the problem.

Thank you for support!

Now it is working!!!

Yes, that's a quirk of the syno code itself - it doesn't care about lower/upper case but does care about : in the MAC. During boot RP actually errors-out with that on serial console as it verifies the MAC a bit (just length really).

 

 

On 9/27/2021 at 6:18 PM, sebg35 said:

 

Just a quick reminder for myself (and maybe it can help other) for the next try :

 

When i start to upgrade my Gen10 plus (1 internal Sata with 4 disks 1,2,3,4) from 6.2.3 (Jun loader 3617xs) to 7.0.0 (Redpill) 3615xs :

  • Only one disk was shown with id 13 ? 

In order to get all 4 disks working i was needed to modify grub :

 

  • Jun Loader 6.2.3 Grub :

Bold : present by default on Jun loader ?

 

set common_args_3617='syno_hdd_powerup_seq=0 HddHotplug=0 syno_hw_version=DS3617xs vender_format_version=2 console=ttyS0,115200n8 withefi elevator=elevator quiet syno_port_thaw=1'

set sata_args='sata_uid=1 sata_pcislot=5 synoboot_satadom=1 DiskIdxMap=0C SataPortMap=1 SasIdxMap=0'

 

  • Redpill Loader 7.0.0 Grub : 

Bold : Added

 

    linux /zImage mac3=xx mac2=xx DiskIdxMap=00 mac1=xxmac4=xx netif_num=4 earlycon=uart8250,io,0x3f8,115200n8 syno_hdd_powerup_seq=0 vid=xx syno_hdd_detect=0 pid=xx console=ttyS0,115200n8 elevator=elevator sn=xx root=/dev/md0 SataPortMap=1 SasIdxMap=0 sata_uid=1 sata_pcislot=5 earlyprintk loglevel=15 log_buf_len=32M syno_port_thaw=1 HddHotplug=0 withefi syno_hw_version=DS3615xs vender_format_version=2 

Don't add random parameters like that. First of all, you should NOT edit grub.cfg but put your params in user_conf.json instead. Second for the disk parametrs see this great explanation: https://xpenology.com/forum/topic/44285-proxmox-hba-passthrough-second-virtual-controller-not-detected/?do=findComment&comment=204352

Third: do NOT add sata_uid or sata_pcislot - these are Jun's custom parameters which were never implemented but were left there. The difference is Jun's loader was removing them from cmdline so that DSM cannot see them - RP does not as we never used them. Making them visible to DSM shows the DSM clearly it's running on non-official hardware.

 

 

On 9/28/2021 at 3:36 AM, pocopico said:

A few compiled modules for DS918+ (4.4.180+). Most network drivers have been tested and work

 

https://github.com/pocopico/4.4.180plus-modules

 

 

Can you make extensions out of those? :D

 

 

On 9/28/2021 at 5:55 PM, WiteWulf said:

FWIW, this release (7.0.1-42218 with redpill-lkm 3474d9b) is very unstable for me. It's kernel panicking for Plex Media Server (which is essentially a big database) as well as my docker containers. I don't know if that's because of the move to 7.0.1-42218, or because I've also moved to 3474d9b again. I previously tried 3474d9b and found it very unstable on my system, so to went back to 021ed51, which crashed much less often.

 

I've disabled docker on my system now, but it's kernel panicking every few minutes as soon as Plex Media Server starts doing anything. Gonna have to try and build a 7.0.1-42218 image with that older redpill-lkm commit as this is completely unusable now.

So it seems PostgreSQL is the best for triggering that crash (DSM index, plex, music - all use PgSQL). Noted ;)

 

 

On 9/28/2021 at 7:23 PM, D.S said:

The SN & MAC are from real DS918+. I didn't see anything about the SN & MAC in /var/log/synofoto.log, and the information about the SN in /var/log/messages as below. 

 

Message in /var/log/messages:

2021-09-28T18:30:52+08:00 XXXX-NAS kernel: [   16.531414] Got empty serial number.                                                                                                                                                                                                                                              Generate serial number from product.
2021-09-28T18:30:52+08:00 XXXX-NAS kernel: [   16.665292] Got empty serial number.                                                                                                                                                                                                                                              Generate serial number from product.
2021-09-28T18:30:52+08:00 XXXX-NAS kernel: [   16.665295] drivers/usb/core/hub.c (                                                                                                                                                                                                                                             2940) Same device found. Change serial to ffffffccfffffffbffffffcbfffffff0

 

This is unrelated to syno - this is the kernel yelling at the manufacturer of your USB device which has no S/N (any USB device should have it... a lot don't ignore the USB spec). This will not break anything - it's just the kernel being pedantic.

 

 

On 9/28/2021 at 10:24 PM, Orphée said:

Actually, just to "fix" words between SAS card and drives.

On my case, and I think on most of us, drives are SATA.

We have a LSI SAS HBA IT card, but with SAS to SATA cable

https://www.amazon.fr/CableDeconn-SFF-8087-Fanout-Wihout-Latch/dp/B00S7KU0VO/

image.png.2aaea678146c00a88ec8089b65299cb1.png

 

I just want to be clear on this. for @ThorGroup

Disks are detected as SAS whereas there are SATA drives on SAS card.

 

Thanks

It's just semantics - SAS command set uses SCSI like SATA with some differences like how SMART is handled. The situation is similar with PCI and PCI-Express. The physical interface matters to the controller, to the OS it's abstracted under a single SCSI interface (yes, the same ancient SCSI) no matter if the physical disk is a SAS or SATA one. There are even breakout boards for SATA drivers allowing for dual-channel SAS connection (for redudancy).

 

 

 

On 9/28/2021 at 11:03 PM, flybird08 said:

Bad news, neither seems to be included in the DS918+.

 

 

SAS and 918+ isn't something which will ever work natively. However, if we force DSM to see SAS as SATA.... that's a different story.

 

 

On 9/29/2021 at 1:17 AM, svenger87 said:

I´m struggling with installing the PAT file. The Webassistant shows the PAT is corrupted.
System is a Intel NUC RTL 8111H card. Any hints whats wrong?

 

Edit: Ah. I think i need to edit the SATA params in the grub.cfg.

image.thumb.png.4d51abb050395eea66c91f055ef841e8.png

Do NOT edit grub.cfg - edit user_conf.json

 

 

On 9/29/2021 at 1:46 AM, WiteWulf said:

I think this may be on the way to fix that:

https://github.com/RedPill-TTG/redpill-boot-wait

 

(Lots of interesting new bits appeared on GitHub this afternoon)

We knew someone will catch our quick final tests with public repos :D They were public before the post for probably total of 10 minutes.

 

 

On 9/29/2021 at 8:49 AM, flybird08 said:

I don't think it is statically compiled into the DS918+ DSM kernel. When I mount, I can see the corresponding error prompt. This module is missing.

 

 

See


============================================================================
This post reached 50 quotes - we will continue in the next one.

  • Like 3
  • Thanks 3
Link to comment
Share on other sites

Rest of the answers starting from beginning of page 84 and ending on page 86.

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

 

On 9/29/2021 at 9:58 AM, flybird08 said:

 

IG-88 said that the DS918 kernel has the capability of SAS module. But there is no actual measurement on my side. Maybe Jun's loader does extra work?

 

In addition, the SATA/AHCI controller may be a better choice on the DS918 before SAS can run perfectly. If you can compile ahci.ko, I will do more tests on SATA/AHCI controller. I also have a JMB585 controller.

 

We will love to be wrong here but to our knowledge 918+ kernel does not have SAS functionality. These symbols are present in the kernel code but guarded by "ifdef MY_ABC_HERE" which presumably depends on the model/SAS support option.

 

Eh... it is possible to emulate that. We know how technically. We can provide these symbols virtually in RP but it will require some digging to check what they should return. Since we don't care about REAL SAS support (as syno-supplied controllers have a custom firmware anyway) we can just shim them.
However, we see some success from @pocopico and @Orphée here so we will... wait for an extension maybe? ;)

 

 

On 9/29/2021 at 3:48 PM, flybird08 said:

 

 

@pocopicoI compiled the module of Jmicron jmb585 myself and encountered the same problem. Maybe Synology really changed the driver code. But I don't know how to make it work.☹️

 

THAT WE CAN FIX! :) We can add that symbol if needed. We saw Jun replacing that symbol but we had no idea why. Famous last words: that should be easy.

 

 

On 9/29/2021 at 4:06 PM, Orphée said:

Wow, did you guys see the list of "removed" things with DSM 7 ?

https://www.synology.com/en-global/releaseNote/DSM?model=DS3615xs

 

 

 

Be warned and take care of your settings before upgrade to DSM7...

36xx is rocky with v7 overall. We've lost two pools on a real DS - a complete ext4 crash. Surprisingly btrfs is more stable this time, but someone reported here data loss with btrfs as well.
However, there's a shell hack to forcefully just load USB device kernel modules. It's just they're through with supporting that probably.

 

 

On 9/29/2021 at 4:37 PM, Aigor said:

About Drivers, correct me if I'm wrong
There are basically "two types of drivers" one type is mandatory to install into some hardware, and others available after installation to support, for example, 10Gbit card and so on.
To make loader you need ONLY drivers that is suitable for booting and installing, for example, SaS controller, SATA, network card, usb, exotic chipset, so, i think, reduce the amount of them needed to boot and install, these are mandatory to have new system installed and, but i don't know, can be packed into loader for installing only, after, we can use spk via spksrc to pack needed drivers to support exotic hardware for example Fibre Channel cards ( my old project )  exotic network card and so on.
What do you think about it?  
I wrote a pile of bullshit? 


 

Yes, you are correct. We were thinking about that as well but decided against dividing drivers. There's no harm in loading all of them in pre-boot. On some of our servers (unrelated to DSM) we have 10Gb/s networking in initramfs to boot from them. We couldn't find an argument for splitting drivers to core and non-core besides size. Since loading a ramdisk layer seem to work up to ~430MB we don't think we will hit that limit any time soon.
We don't copy modules like Jun did - we just load them from memory to different memory. You don't need to unload and reload them on runtime. On hot-plug systems you may do that but syno doesn't do that themselves either and essentially loads drivers based on configs in preboot.

 

 

On 9/29/2021 at 4:43 PM, pocopico said:

 

If you extract the kernel with the extract script you find inside the redpill-loader you can extract the symbols. These libata symbols do not exist on 918. So in other words if we even get the sources we are out of luck for

some devices. I think that baremetal whitout matcing the official hardware is getting harder.

 

@flybird08

 

So thats what happens when you are mixing synology compiled modules with standard kernel drivers. Modules are reffering to symbols that do not exist. This is what i've tried and seems to get the modules to load succesfully. Download the mpt3sas.ko from the repo again. 

 

insmod scsi_transport_sas.ko
insmod libsas.ko
insmod raid_class.ko
insmod mpt3sas.ko

 

lsmod |grep -i mpt

 

mpt3sas               194218  0
raid_class              3508  1 mpt3sas
scsi_transport_sas     23996  2 mpt3sas,libsas
 

 

If the .ko is shipped within the PAT go for it and load it - at least we know it's compilled properly. It may still have missing symbols but see beginning of this post.

 

 

On 9/29/2021 at 4:43 PM, WiteWulf said:

@Orphée Yeah, I imagine that's going to be a problem for lots of people. You running Domoticz/Home Assistant for IoT?

...and this is exactly why we run a Proxmox. A VM for DSM + a VM for stuff like HA, NUT, or Avahi. Trying to put it on a NAS is already tricky but I'm sure it will piss off a lot of real DS users as for most the NAS is their only server.

 

 

On 9/29/2021 at 6:26 PM, WiteWulf said:

This is a known limitation. Booting from USB3.0 is not possible at this time.

Teeechincaaaaally speaking as long as the NUC is able to BOOT from the USB3.0 the RP shouldn't have a problem interacting with it as it loads all drivers, including USB3. The only issue may be the driver for the controller itself - if it's not supported by the native Linux xHCI driver you will need to add it as an extension.

 

 

On 9/29/2021 at 7:04 PM, Kaneske said:

@ThorGroup

 

@ilovepancakes

 

@jumkey

 

Since it seems to be „quite“ stable and also usable by many, and it’s already on 7.01 on the Syno Side…

 

…is there a way to post a to-do by step, or a summary, what and when to act for getting this incredible cool new loader done?

 

It seems hard for me to get things together.

 

THX

See the roadmap ;) [few posts from this account back]

We want to fix the SAS thing [which as we see guys are already figuring out here] and integrate container build into the load repo - then an instruction will be posted. We also want to solve that annoying crash/lockup issue with 3615xs as we cannot call it stable or even beta if every database crashes it within minutes-hours.

 

 

14 hours ago, WiteWulf said:

@ThorGroup hey guys, sorry to '@' you on this, I know you're busy people, but I wonder if you'd been able to look at the kernel panic problems on DS3615xs? My system is now stable, but only with no docker containers running and Plex Media Server stopped. Starting PMS or a docker container results in a kernel panic anywhere between a few seconds or two to three minutes later. I'm happy to carry out any testing you suggest and feedback diagnostic output.

Yes, we're trying - the biggest issue, which is slightly funny, is that we have hard time reliably crashing it.

 

 

12 hours ago, pigr8 said:

 

what about the 4 letter /dev/sdXXn? didnt thorgroup say that is not supported? i have a LSISAS2008 too, gonna try tomorrow and see if it works.

That isn't a problem - you just need to set SataDisk... params properly to move disks and it will fix itself.
See: https://xpenology.com/forum/topic/44285-proxmox-hba-passthrough-second-virtual-controller-not-detected/?do=findComment&comment=204352

 

 

1 hour ago, shibby said:

that`s true, but when we don`t know what is correct value for our bare metal, then this is the easiest way for testing. And another thing, we can compile RP for other users (who cannot compile RP himself) and they have to only modify grub.cfg for his configuration (vid, pid, mac, sataportmap). We did this in previous loader by Jun, so community know how to do this without any broke :)

With all due respect: looking at this thread we see many people don't know what to edit and what to put (e.g. randomly stuffing sata_pcislot or doing replacements of hwmon configuration parameters). Doing a quick "e" in grub and adding something which YOU know what it does is obviously something we do as well, however advising people to open images and edit grub.cfg isn't wise. A prime example are disk/controllers settings: you can spend days trying random values found all over the forum OR spend 15-20 minutes understanding what these values do and configure them per your system. Many people don't realize some values are specific to their own config.

 

Additional issue, which we repeated multiple times here, is sharing the loader image. It's a VERY bad idea. Read the first post in this thread: we didn't start RP. The original thread is gone, original repos are gone, ... there's a reason for that and it's not one you want to step into. Trust us on that: sharing precompiled images is a very bad idea. The kernel and modules are open source and under GPL - you can do literally whatever you want with them. However, the final image contains proprietary syno modules and their userland tools which are as far from open source as possible. Connect the dots here why we say to not share the full image and went into a huge effort of creating tools to build the image. It would be much easier to drop an .img or .vmdk and call it a day but the times changed.

 


========================================================================
Yay! We're done - it took some time ;) Now we need to think about a great PM from @haydibe ^^

 

  • Like 6
  • Thanks 6
Link to comment
Share on other sites

Do someone have a luck with NVMe drive on DSM7.x? On 6.2.3 i used this "solution"

 

On 7.0.1 it wont work. Any modification of libsynonvme.so.1 file is ending on reinstalation DSM (detect as migratable system). Only M.2 Sata drives works.

 

Or maybe this is too early to talk about NVMe? ;)

Link to comment
Share on other sites

3 minutes ago, shibby said:

Do someone have a luck with NVMe drive on DSM7.x? On 6.2.3 i used this "solution"

 

On 7.0.1 it wont work. Any modification of libsynonvme.so.1 file is ending on reinstalation DSM (detect as migratable system). Only M.2 Sata drives works.

 

Or maybe this is too early to talk about NVMe? ;)

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

  • Like 1
Link to comment
Share on other sites

15 minutes ago, shibby said:

Do someone have a luck with NVMe drive on DSM7.x? On 6.2.3 i used this "solution"

 

On 7.0.1 it wont work. Any modification of libsynonvme.so.1 file is ending on reinstalation DSM (detect as migratable system). Only M.2 Sata drives works.

 

Or maybe this is too early to talk about NVMe? ;)

It works by hardcoded PCI ID,  you can just replace PCI ID 0000:00:13.0 & 0000:00:13:1 with your Nvme PCI ID in file libsynonvme.so.1

NVme1.jpg

  • Like 1
Link to comment
Share on other sites

On 9/18/2021 at 3:34 AM, coint_cho said:

Got a brand new Intel Dual Port NIC and finally I was able to get a web UI with diskstation! Unfortunately same issues still persist with my previous attempts to use other loaders, no disk found unless I'm using loaders specifically modified with MBR partition. Looks like I'll have to wait until the final release and wait for members to tweak the loaders as I have no idea how members like Genysys patched Jun's loader to work with MBR partition. 
Xpe7.0.thumb.jpg.76979dd1e7e5ca10780edeeab74283c0.jpg

Baremetal Intel Core 2 Quad Q6600, 4GB RAM, 3 physical disks hooked up via SATA directly to board, Intel Pro 1000 Dual Gigabit Ethernet NIC (3 interfaces including on board ethernet.)

Was hoping for an answer to whether there’s any workarounds for old hardware, but since no harm in bumping, would like to ask ThorGroup if this is bypassable :D, disks work in 6.1.7 MBR modified by Genysys but not other images sadly. 

Link to comment
Share on other sites

2 hours ago, ThorGroup said:

So many people praise Surveillance Station... maybe we should actually try it. Slightly OT but if you're using it (or anyone else): do you recommend it? We mostly use Ubiquity gear for that and it's ... OK, but not really stable.

You really should give it a try.

It is rock stable, great UI, nice mobile app. nice motion detection features working just fine. can record on disk, send mails / SMS (with 3rd party service) alerts...

But only 2 camera in the free default license.

You must have a real SN/MAC to buy new license(s) on Amazon... There are quite expensive... and I think it is a bit risky, never know if one day Syno detect wrong device even with real SN/MAC... It then may break the licences bought earlier... (there is a Surveillance station c****ed floating around to enable 40 licences... but only for DSM 6.x)

 

With DVA3221 support, you give advanced IA features, 8 camera with default integrated licence... I'm really really waiting you on this 😚

 

image.thumb.png.0d45ba5a8b7e601a387bc88696aeec5c.png

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

2 hours ago, ThorGroup said:
On 9/23/2021 at 2:53 PM, WiteWulf said:

Since moving to the latest redpill code (3474d9b) I'm finding my system less stable than it was before with respect to docker containers. My influxdb container would crash the system every time I started it, but the others I had were typically stable and non-problematic. I'm now seeing immediate kernel panics when starting a mysql container that previously didn't cause any problems.

 

I've gone back to a slightly older build (021ed51), and mysqld (operating as a database backend for librenms) starts and runs without problems.

Expand  

This is sadly coincidental, as we didn't touch locks there :( We're still debugging that. The most annoying thing is that it actually doesn't crash very reliably on our gen 8s. It does but rarely.

FWIW, I had to try much harder to crash my system on a clean install when freshly created containers like influxdb and MySQL had no actual databases. But starting up containers where the databases had a lot of existing data in them crashed much more quickly. I’m happy to share one of my containers+data with you if that would be helpful (the influxdb one has nothing sensitive in it, just my electricity and gas utility use for the last few years 😀). My system crashes 100% of the time within seconds of starting this container. 

Link to comment
Share on other sites

29 minutes ago, Orphée said:

(there is a Surveillance station c****ed floating around to enable 40 licences... but only for DSM 6.x)

Sorry and its offtopic here, but do you tested the old c****** SSS package which the guys used on 6.2.3 with you restart task on DSM7? I think it could be possible to use, because it is a manuel installed package. So you should deinstall the standard SSS on DSM7 and give a try for the c****** one... In the past i tried it up with 6.2.3 it it worked perfectly for my with 9 cams.

I prefere SSS because you have the ability to use livecam, which is a kind of webcam recorder for you ios and ipados devices. So here i have to iPads in my house from which i can use the front cam for recording ;) 

Link to comment
Share on other sites

i wonder if the mpt2sas.ko from the Jun's Loader combo is different from the stock .ko file, and if it uses the /dev/sda nomenclature like popopicos compiled one, i should try it 😮 maybe Jun's fix is just a recompiled .ko instead of fixing the nomenclature somehow in the loader.

 

Link to comment
Share on other sites

2 hours ago, ThorGroup said:
On 9/25/2021 at 7:14 PM, WiteWulf said:

Hi there, can you grab the serial console output from a crash before you roll take 7.0.1 off that Gen10? If you're not sure how, have a search of the forum for accessing the virtual serial port via iLO on the HP hardware, it's a common question.

Didn't they remove iLO from Gen10 and added as a separate purchase in Gen10+?

Yeah, additional hardware required on Gen10. That sucks!

 

https://www.servethehome.com/hpe-proliant-microserver-gen10-plus-review-this-is-super/3/

 

So the iLO is included in the machine, but you need to buy this miniature NIC to enable it and have OOB monitoring and management *and* that only gets you basic functionality. There's no remote media or remote console with the essentials license 🙄

  • Angry 1
Link to comment
Share on other sites

16 minutes ago, WiteWulf said:

Yeah, additional hardware required on Gen10. That sucks!

 

https://www.servethehome.com/hpe-proliant-microserver-gen10-plus-review-this-is-super/3/

 

So the iLO is included in the machine, but you need to buy this miniature NIC to enable it and have OOB monitoring and management *and* that only gets you basic functionality. There's no remote media or remote console with the essentials license 🙄

Yep, on Gen10+ you have to buy the daughter board, and buy the license somewere (Ebay & co...)

Link to comment
Share on other sites

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