RedPill - the new loader for 6.2.4 - Discussion

UnknownO · July 25, 2021

2 minutes ago, jumkey said:

https://github.com/RedPill-TTG/dsm-research/blob/master/quirks/boot_params-validation.md patch this？

ok, let me try

UnknownO · July 26, 2021

Hello, now I have successfully injected the binary patch into the kernel, and successfully added redpill.ko to the ramdisk. The boot can now be started, but it prompts "File Corruption (13)" during installation

BlaBla1973 · July 26, 2021

8 hours ago, UnknownO said:

Hello, now I have successfully injected the binary patch into the kernel, and successfully added redpill.ko to the ramdisk. The boot can now be started, but it prompts "File Corruption (13)" during installation

Nice,

I found this "solution" for the file corruption (13)

If you get the following error ”Failed to install the file. The file is probably corrupted. (13)” it means your VID and/or PID is wrong. If you are 200% sure that your VID/PID is correct and you still get that error message then try to 'Force Install'

Or this one :

When I had simialr problem, I successfully made this with NO STORED DATA LOSS:

1) Disconnect all the drives
2) Run the jun’s loader as reinstall
3) Find device by find.synology.com or Assistant – there were no drives in the system.
4) Leave browser’s Synology page opened, do not shut down device.
5) Plug disks back in (no matter, if the machine supports hotswap or not)
6) After a few minutes repeatedly refresh Synology’s page (see step 4)
7) After succesfuly loaded installation page reinstall system. Do not forget to check manual upgardes only.

Notes:
a) Stored files will be kept untouched, but apps, settings and other data will be removed.
Settings can be restored via previously saved ones.
b) If reinstallation crashes, reset your device and go through standard “1st time” instalation process.

Edited July 26, 2021 by BlaBla1973

UnknownO · July 26, 2021

16 minutes ago, BlaBla1973 said:

Nice,

I found this "solution" for the file corruption (13)

If you get the following error ”Failed to install the file. The file is probably corrupted. (13)” it means your VID and/or PID is wrong. If you are 200% sure that your VID/PID is correct and you still get that error message then try to 'Force Install'

Or this one :

When I had simialr problem, I successfully made this with NO STORED DATA LOSS:

1) Disconnect all the drives
2) Run the jun’s loader as reinstall
3) Find device by find.synology.com or Assistant – there were no drives in the system.
4) Leave browser’s Synology page opened, do not shut down device.
5) Plug disks back in (no matter, if the machine supports hotswap or not)
6) After a few minutes repeatedly refresh Synology’s page (see step 4)
7) After succesfuly loaded installation page reinstall system. Do not forget to check manual upgardes only.

Notes:
a) Stored files will be kept untouched, but apps, settings and other data will be removed.
Settings can be restored via previously saved ones.
b) If reinstallation crashes, reset your device and go through standard “1st time” instalation process.

Hello, I tried Force Install now, but this problem still occurs. I don’t have any options... I can only wait for ThorGroup to answer.

TSo3 · July 26, 2021

8 hours ago, UnknownO said:

Hello, now I have successfully injected the binary patch into the kernel, and successfully added redpill.ko to the ramdisk. The boot can now be started, but it prompts "File Corruption (13)" during installation

Hello, when I got this error I had downloaded the wrong file (the update file) when I downloaded the full firmware then the installer continued.

Orphée · July 26, 2021

8 hours ago, UnknownO said:

Hello, I tried Force Install now, but this problem still occurs. I don’t have any options... I can only wait for ThorGroup to answer.

Check you are with USB2 and not USB3. I had this issue with 6.2.3 for installation on VM. Once installed you can switch back to USB3.

Edited July 26, 2021 by Orphée

UnknownO · July 27, 2021

8 hours ago, Orphée said:

Check you are with USB2 and not USB3. I had this issue with 6.2.3 for installation on VM. Once installed you can switch back to USB3.

Ok, now I have found the reason, the binary patch seems to be unsuccessful. Although the installation page appears, the ramdisk error is still reported when viewing the kernel log

UnknownO · July 27, 2021

4 hours ago, UnknownO said:

Ok, now I have found the reason, the binary patch seems to be unsuccessful. Although the installation page appears, the ramdisk error is still reported when viewing the kernel log

The current kernel binary patch seems to be completed. But I don’t know if it is redpill.ko compilation error or insmod location error.

ThorGroup · July 28, 2021

Let us first pull you from the dark - we just added a new repo to the collection. "We think you're gonna love it"[tm]

RedPill Load
Without further ado: RedPill Loader Builder Repo is live - https://github.com/RedPill-TTG/redpill-load

It's a loader image generator which we worked on for quite some time. From the start we have to apologize for using
BASH - it was a mistake and if you look into the code you will understand why

What it can do for you?
However, it works. In short, it automates the following process in "normal" mode:

Checks if the OS contains all tools needed to create the image
Downloads the correct PAT file (if needed)
Verifies checksum of the PAT (in case they pull a switchero on us one day)
Unpacks the PAT
Verified checksum of a known kernel & ramdisk files
Patches the kernel zImage using included patches [direct mode only, see below]
Unpacks ramdisk
Applies common patches (disable root pw, add RP LKM loading etc)
Generates synoinfo replacements based on the platform requirements AND user configuration
Patches synoinfo in etc & etc.defaults in the ramdisk image
Adds dynamic patching routines to post-init script (so that synoinfo is patched in the booted OS too)
Copies missing VirtIO modules (original DSM script supports them but they're not included in non-VDSM builds)
Reassembles ramdisk, taking care of broken v4 unpacking routines
Generates appropriate GRUB configuration with kernel params appropriate for the platform + overrides specified in the user config
Using a template of the loader image (contains compiled GRUB, you can provide your own too) packs everything together to a bootable image

What it can do for you, a developer?
Of course, continuing tradition of the RedPill LKM the code contains extensive debug mode. However, there's more. The generator isn't meant to just generate loader images. It is also meant to make it easy to add new platforms and patches.
The loader generator has two different ways of patching the kernel: direct (default), or repack (set environment var BRP_LINUX_PATCH_METHOD=repack). In the repack mode the kernel is NOT patched using direct binary patches between original and final. In fact this mode assumes such pack doesn't exist. When run in repack mode the code will go as far as possible and exit before kernel patching, while printing patches to the original & patched file. Then it's up to the person running the code to convert unpacked vmlinux image to a patched one (i.e. apply any binary patches).

After running the code again:

new image will be detected
vmlinux will be run through a script which makes a bzImage from it again
the build will continue as normal
build files will NOT be deleted so a bsdiff can be used to generate a binary patch

This second mode is incredibly useful when adding new versions/platforms. We're not keeping our "tribal knowledge" to ourselves. If anything happens, or we pass the project to another group in the future, or someone decides to improve on the patches we did, or even when someone doesn't want to trust our pregenerated kernel patches the code will accommodate that. We don't want to keep any internal tools to ourselves and publish just the "user" stuff.

Config-driven architecture
The goal of the project was to make things flexible. This is why LKM is NOT specific to the hardware platform (more about that below) but rather compiled against the kernel (as you cannot make the same LKM work across multiple kernel versions).

The loader builder code by itself makes very few hardcoded assumptions:

synoinfo files location (this didn't change for years)
grub.cfg location (this is controlled by us)
anything we accidentally hardcoded

Everything else is based on the combination of platform and user configs. Platform config is a simple JSON file located in "config/<HW VERSION>/<OS VERSION>/config.json". We will not go over every option as the existing ones in the repo should be self-explanatory. In short, it defines where to get the PATs, checksums for various files, lists of patches for kernel & ramdisk, GRUB options, files copied etc...

On top of that some options can (and some must) be overridden by a user config file. This file defines S/N and stuff like that (but can override much more than that, for example SATA mapping). The idea here is to allow creation of customized images as updates are more common than fresh installs.

As of now we tested the DS3615xs image generation and booting. It boots and passes the installation & initial configuration. The DS918+ should work too. However, consider both as pre-alpha (due to the LKM).

One more thing
So, today's update is mostly about RedPill Load. However, we couldn't really do that without implementing multiplatform support in the LKM. As we mentioned above the idea for the code is to be multiplatform and allow adding new models without too much hassle. That's why RedPill LKM contains all definitions in the binary and picks them based on kernel params during boot. We looked at how QEMU does multiple CPUs definition and modeled the architecture similarly: https://github.com/RedPill-TTG/redpill-lkm/commit/14dab9bde12495b1be833e1a1ffb1cf6ee3f00d6

With this release we have defined all devices for DS3615xs and DS918+. Along with the multiplatform support we had to dig into PCI (again...) to make sure multi-function devices work correctly as DS918+ utilizes them. On top of that error reporting is vastly improved now. One of the changes we also made somewhere along the way was to start documenting BIOS shims to prepare architecture for future expansion of external uP handling LEDs etc.

https://github.com/RedPill-TTG/redpill-lkm/commit/e4c634e9f56f3b3d07430863e385c98e318b1823

**********************************************************************************************************

We saw your posts guys and we're seriously impressed Let us help a little, even if most of the issues are resolved by using RedPill Loader Generator:

On 7/21/2021 at 11:17 AM, UnknownO said:

Hello, I followed your method and successfully added redpill.ko to the ramdisk. However, when adding a binary patch to zImage, I successfully decompressed zImage and obtained vmlinux, and used the php file in the GH repo dsm-research for kernel patching, but I don’t know how to package vmlinux into zImage, So, currently I am stuck ramdisk corrupt

Looking forward for your reply, thank you!

To our knowledge the only one available and working script is the one which was published by killer. It is available in his repo: https://github.com/kiler129/recreate-zImage and we use it as a submodule. From what we see now the repo is also public. Unfortunately it lacks docs but its usage is pretty straightforward.

However, speaking about the screenshot you posted: you're still using parts of the Jun's loader it seems (patching file etc/passwd part). You cannot mix both. The elevator not found error in the other hand is something you can ignore (that's one of the tricks which are nice-to-have, we wrote about that in the previous post).

On 7/21/2021 at 8:57 PM, intrax said:

Try this:

https://forum.xda-developers.com/t/script-repack-zimage-sh-unpack-and-repack-a-zimage-without-kernel-source-v-5.901152/

We saw that one too. Unfortunately this one doesn't work. It only works with old kernels and it's very finicky. In short that code attempts to just monkey-guess offsets which (especially with v4 relocations) can be incredibly difficult to do. The one above actually uses the process from within the KBuild process.

On 7/21/2021 at 9:36 PM, UnknownO said:

I found that this does not seem to be zImage, it seems to be bzImage. Because when I checked the information, I found that zImage seems to be compressed with gzip,but this kernel uses lzma compression. And using the file command also shows that this is bzImage(see the upload image).

I rummaged through the search engine results, but didn't find a useful one. Basically it is about how to compile Linux to get bzImage...

PS:I tried to cut the head of this zImage and merge it with the modified vmlinux compressed by lzma to get a new zImage, but when booted with grub, the virtual machine crashed directly

It's not so much about the compression but about the place. Kernel is like a matrioshka with multiple things glued around the compressed image.

You cannot paste the header as there are some things after the image, there are also offsets generated based on the compressed image etc... it's a mess. It's the x86 mess...

On 7/21/2021 at 10:36 PM, ilovepancakes said:

Not the folder you mention but anything in here help? https://sourceforge.net/projects/dsgpl/files/toolkit/DSM7.0/

That's sadly just the toolkit. Enough to compile some things but it doesn't have full sources.
We've got the original sources for a single platform from an anonymous data hoarder We didn't dig into that yet thou.

On 7/25/2021 at 1:55 AM, jumkey said:

repack bzImage by delete cpu.o then stuck at 'booting the kernel'

init file on rd.cpio

#!/bin/sh
insmod redpill.ko
exec /bin/busybox init

Close, but you should run the whole init script
The fact it stops at "booting the kernel" is actually expected (it only prints on serial). The Loader Builder has more about that in the FAQ file.

On 7/26/2021 at 10:18 AM, UnknownO said:

Hello, now I have successfully injected the binary patch into the kernel, and successfully added redpill.ko to the ramdisk. The boot can now be started, but it prompts "File Corruption (13)" during installation

Error 13 can mean anything - idespite the message in the web installer it is a catch-all for "some error happened during installation". We saw it with e.g. damaged HDDs in a real syno. You need to look into /var/log/junior_reason and /var/log/messages for details

On 7/26/2021 at 6:22 PM, BlaBla1973 said:

Nice,

I found this "solution" for the file corruption (13)

If you get the following error ”Failed to install the file. The file is probably corrupted. (13)” it means your VID and/or PID is wrong. If you are 200% sure that your VID/PID is correct and you still get that error message then try to 'Force Install'

(...)

We wouldn't recommend doing this. Some things in Syno init script assume that the disks are present at boot. Additionally, vid/pid mismatch is just one of the reasons. RedPill LKM logs everything by default and with mentioned above + dmesg it's pretty easy to say what's wrong

23 hours ago, UnknownO said:

Ok, now I have found the reason, the binary patch seems to be unsuccessful. Although the installation page appears, the ramdisk error is still reported when viewing the kernel log

That is actually expected. The DS3615xs patch works differently than DS918+. The 3615 patches the flag code (so the error will still print but the corruption flag will be 0) while 918 one patches conditional jump to unconditional jump (so no matter what verification produced it will always set the flag to 0). Semantics really. It doesn't matter.

The way to test if it's ACTUALLY working is to do:

mkdir tmp1 tmp2
mount -t tmpfs tmpfs tmp1
mount --move tmp1 tmp2

If all executed without errors it means that neither header nor ramdisk checks are tripped (as any of them will block mount --move).

19 hours ago, UnknownO said:

The current kernel binary patch seems to be completed. But I don’t know if it is redpill.ko compilation error or insmod location error.

That is a buffer overflow in strings comparison

We believe this one was fixed already - try pulling the newest code and check again.

Aigor · July 28, 2021

OT Not from the Dark, From Asgard or From the Walhalla 😁

Aigor · July 28, 2021

Great Milestone!
Do this "script" intended only for X86 arch? or, maybe in the future, could be used for arm for example?

yanjun · July 28, 2021

4 hours ago, ThorGroup said:

As of now we tested the DS3615xs image generation and booting. It boots and passes the installation & initial configuration. The DS918+ should work too. However, consider both as pre-alpha (due to the LKM).

After I pulled the latest redpill-lkm, I recompiled it for 918+ and made a loader. On proxmox, it can start normally and enter the installation process, but I still get "Failed to install the file. The file is probably corrupted. (13)". Based on your prompt, I checked junior_reason and /var/log/messages this time,
The screenshot below shows some errors, but I don't know where to start.

here is my user_config.json:

{
  "extra_cmdline": {
    "vid": "0x46f4",
    "pid": "0x0001",
    "sn": "1780PDN123456",
    "mac1": "E2:C4:5C:C9:EE:EE"
  },
  "synoinfo": {},
  "ramdisk_copy": {}
}

/var/log/junior_reason:

/var/log/message:

Edited July 28, 2021 by yanjun

jumkey · July 28, 2021

6 hours ago, yanjun said:

"mac1": "E2:C4:5C:C9:EE:EE"

E2C45CC9EEEE

6 hours ago, yanjun said:

"Failed to install the file. The file is probably corrupted. (13)".

echo "args: -device 'qemu-xhci,addr=0x18' -drive 'id=synoboot,file=/var/lib/vz/images/{VM_ID}/synoboot.img,if=none,format=raw' -device 'usb-storage,id=synoboot,drive=synoboot,bootindex=5'" >> /etc/pve/qemu-server/{VM_ID}.conf

Edited July 28, 2021 by jumkey
add bootindex

use-nas · July 28, 2021

ilovepancakes · July 28, 2021

I am getting the following error when running the redpill-load script. Anyone have any ideas?

EDIT: Running as sudo fixed issue for me. Guess the script couldn't access the folder it was trying to write to.

lab@ubuntu-lab01:~/redpill/redpill-load$ ./build-loader.sh 'DS918+' '6.2.4-25556'
[#] Checking runtime for required tools... [OK]
[#] Verifying /home/lab/redpill/redpill-load/cache/ds918+_25556.pat file... [OK]
[#] Unpacking /home/lab/redpill/redpill-load/cache/ds918+_25556.pat file to /home/lab/redpill/redpill-load/build/1627496982/pat-ds918+_25556-unpacked... [OK]
[#] Verifying /home/lab/redpill/redpill-load/build/1627496982/pat-ds918+_25556-unpacked/zImage file... [OK]
[#] Patching /home/lab/redpill/redpill-load/build/1627496982/pat-ds918+_25556-unpacked/zImage to /home/lab/redpill/redpill-load/build/1627496982/zImage-patched... [OK]
[#] Verifying /home/lab/redpill/redpill-load/build/1627496982/pat-ds918+_25556-unpacked/rd.gz file... [OK]
[#] Unpacking /home/lab/redpill/redpill-load/build/1627496982/pat-ds918+_25556-unpacked/rd.gz file to /home/lab/redpill/redpill-load/build/1627496982/rd-ds918+_25556-unpacked... [OK]
[#] Apply patches to /home/lab/redpill/redpill-load/build/1627496982/rd-ds918+_25556-unpacked... [OK]
[#] Patching config files in ramdisk... [OK]
[#] Adding OS config patching... [OK]
[#] Repacking ramdisk to /home/lab/redpill/redpill-load/build/1627496982/rd-patched-ds918+_25556.gz... 
[!] Failed to repack flat ramdisk



*** Process will exit ***
lab@ubuntu-lab01:~/redpill/redpill-load$

Edited July 28, 2021 by ilovepancakes

blindspot · July 28, 2021

I'm stuck at compiling redpill-lkm. Which sources should I use and from where? Thanks

Aigor · July 28, 2021

1 hour ago, blindspot said:

I'm stuck at compiling redpill-lkm. Which sources should I use and from where? Thanks

https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/
It depends on what arch are you using

smoojay · July 28, 2021

On 7/27/2021 at 10:36 AM, UnknownO said:

The current kernel binary patch seems to be completed. But I don’t know if it is redpill.ko compilation error or insmod location error.

confirmed with latest code, seems to be a problem on vmware platforms .. doesn't occur on virtualbox or proxmox

ThorGroup · July 28, 2021

12 hours ago, Aigor said:

Great Milestone!
Do this "script" intended only for X86 arch? or, maybe in the future, could be used for arm for example?

The script itself should be arch-agnostic and thus it can run on like RPi. The only thing which will not produce expected result is kernel repacking as it involves recompiling parts of the kernel. The repacking script doesn't have any handling for cross-build. It can be done if needed, but repacking and manual patching should be a reasonably rare operation and we all know this comic: https://xkcd.com/1319/

If you're asking if the RP LKM can run on non-x86 platforms the answer is "hm... good question". ARM has no mechanism like PNP and relies on device trees. Running the whole stack on a different ARM platform should theoretically be possible (as Linux is portable) but most likely very difficult. The LKM itself doesn't use any ASM tricks and utilizes kernel interfaces, it also doesn't depend on endianess (except PCI stuff, but this is LE on ARM as well).

12 hours ago, yanjun said:
After I pulled the latest redpill-lkm, I recompiled it for 918+ and made a loader. On proxmox, it can start normally and enter the installation process, but I still get "Failed to install the file. The file is probably corrupted. (13)". Based on your prompt, I checked junior_reason and /var/log/messages this time,
The screenshot below shows some errors, but I don't know where to start.

here is my user_config.json:
{
  "extra_cmdline": {
    "vid": "0x46f4",
    "pid": "0x0001",
    "sn": "1780PDN123456",
    "mac1": "E2:C4:5C:C9:EE:EE"
  },
  "synoinfo": {},
  "ramdisk_copy": {}
}
/var/log/junior_reason:

/var/log/message:

As @jumkey mentioned your MAC format is wrong and RP LKM fails to load. It doesn't bug the kernel (stack trace similar to KP) by default but you can enable it during compilation. Because of this you don't get synoboot patch and the installer cannot access it. Check the early dmesg if the RP actually loaded

4 hours ago, use-nas said:

Install jq 1.5 or newer (they have precompiled binaries on their website). We mentioned this in the https://github.com/RedPill-TTG/redpill-load/blob/master/FAQ.md as the script doesn't parse versions now (hm, it probably should). The reason is jq <1.5 doesn't have any way of reading JSON objects in unsorted manner.

2 hours ago, ilovepancakes said:

I am getting the following error when running the redpill-load script. Anyone have any ideas?

EDIT: Running as sudo fixed issue for me. Guess the script couldn't access the folder it was trying to write to.


lab@ubuntu-lab01:~/redpill/redpill-load$ ./build-loader.sh 'DS918+' '6.2.4-25556'
[#] Checking runtime for required tools... [OK]
[#] Verifying /home/lab/redpill/redpill-load/cache/ds918+_25556.pat file... [OK]
[#] Unpacking /home/lab/redpill/redpill-load/cache/ds918+_25556.pat file to /home/lab/redpill/redpill-load/build/1627496982/pat-ds918+_25556-unpacked... [OK]
[#] Verifying /home/lab/redpill/redpill-load/build/1627496982/pat-ds918+_25556-unpacked/zImage file... [OK]
[#] Patching /home/lab/redpill/redpill-load/build/1627496982/pat-ds918+_25556-unpacked/zImage to /home/lab/redpill/redpill-load/build/1627496982/zImage-patched... [OK]
[#] Verifying /home/lab/redpill/redpill-load/build/1627496982/pat-ds918+_25556-unpacked/rd.gz file... [OK]
[#] Unpacking /home/lab/redpill/redpill-load/build/1627496982/pat-ds918+_25556-unpacked/rd.gz file to /home/lab/redpill/redpill-load/build/1627496982/rd-ds918+_25556-unpacked... [OK]
[#] Apply patches to /home/lab/redpill/redpill-load/build/1627496982/rd-ds918+_25556-unpacked... [OK]
[#] Patching config files in ramdisk... [OK]
[#] Adding OS config patching... [OK]
[#] Repacking ramdisk to /home/lab/redpill/redpill-load/build/1627496982/rd-patched-ds918+_25556.gz... 
[!] Failed to repack flat ramdisk



*** Process will exit ***
lab@ubuntu-lab01:~/redpill/redpill-load$

Can you run the command with debug mode? Simply add BRP_DEBUG=1 before the ./build-loader... command. The log will be long so it's probably better to use pastebin or gist.

9 minutes ago, smoojay said:

confirmed with latest code, seems to be a problem on vmware platforms .. doesn't occur on virtualbox or proxmox

Interesting... do you use ESXi or some desktop platform like Fusion?

smoojay · July 28, 2021

Just now, ThorGroup said:

Interesting... do you use ESXi or some desktop platform like Fusion?

Tested with both, Fusion and ESXi. On ESXi i wasn't able to grab the console output due to the limitation with the free edition. So, im not sure if it is the same with ESXi.

ilovepancakes · July 28, 2021

Can anyone using this on Virtual Box tell me if there are special settings needed for the VM in Virtual Box? I successfully created a loader with redpill-load and it boots in virtual box but I can’t find it with find.synology.com to try installing DSM.

smoojay · July 28, 2021

6 minutes ago, ilovepancakes said:

Can anyone using this on Virtual Box tell me if there are special settings needed for the VM in Virtual Box? I successfully created a loader with redpill-load and it boots in virtual box but I can’t find it with find.synology.com to try installing DSM.

I can confirm that too. It’s a problem with the network interface. Virtualbox doesn’t work with the builtin e1000 driver and virtio_net doesn’t seem to be correctly loaded.

ilovepancakes · July 29, 2021

2 hours ago, smoojay said:

Virtualbox doesn’t work with the builtin e1000 driver

Using e1000e and ESXi I can successfully boot redpill-load now. But when I go to install DSM, it errors out with the file is corrupted (13). Here is my serial output: https://pastebin.com/KcEeaJS1

Hoping @ThorGroupcan provide some insight. Followed the instructions on the GH repo and used the VID/PID there.

jukito · July 29, 2021

12 hours ago, Aigor said:

https://sourceforge.net/projects/dsgpl/files/Synology NAS GPL Source/
It depends on what arch are you using

Hi!

I'm trying to compile redpill-lkm

I already downloaded the syno source (x64 because I want to run on ESXi, is it right?)

Now I'm trying to run the command that de instructions said:

make oldconfig ; make modules_prepare

But:

cc1: error: code model kernel does not support PIC mode
make[1]: *** [/home/david/redpill/redpill-lkm/linux-3.10.x/./Kbuild:36: kernel/bounds.s] Error 1
make: *** [Makefile:840: prepare0] Error 2

Any hint? Thanks a lot!

smoojay · July 29, 2021

Current state on Virtualbox. The message with minissdpd indicates a parameter mismatch. There is no eth interface configured.

..
[   38.551818] <redpill/bios_shim.c:111> apollolake_synobios BIOS shimmed
 ... [  OK  ]
lo        Link e[   38.607768] <redpill/intercept_execve.c:87> Blocked /usr/syno/bin/syno_pstore_collect from running
ncap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

:: Starting syslogd ... [  OK  ]
:: Starting scemd
:: Starting services in backgrou[   45.842834] random: avahi-daemon: uninitialized urandom read (4 bytes read, 27 bits of entropy available)
nd
Starting fin[   46.639133] random: avahi-daemon: uninitialized urandom read (8 bytes read, 29 bits of entropy available)
dhostd in flash_rd...
Starting services in flash_rd...
Running /usr/syno/etc/rc.d/J01httpd.sh...
Starting httpd:80 in flash_rd...
Starting httpd:5000 in flash_rd...
Running /usr/syno/etc/rc.d/J03ssdpd.sh...
/usr/bin/minissdpd
Usage: /usr/bin/minissdpd [-d] [-6] [-s socket] [-p pidfile] -i <interface> [-i <interface2>] ...

  <interface> is either an IPv4 address such as 192.168.1.42, or an
interface name such as eth0.

  By default, socket will be open as /var/run/minissdpd.sock
and pid written to file /var/run/minissdpd.pid
start SSDPD failed
Running /usr/syno/etc/rc.d/J04synoagentregisterd.sh...
Starting synoagentregisterd...
Running /usr/syno/etc/rc.d/J30DisableNCQ.sh...
cat: can't open '/sys/block/sd*/device//model': No such file or directory
Running /usr/syno/etc/rc.d/J80ADTFanControl.sh...
Running /usr/syno/etc/rc.d/J98nbnsd.sh...
Starting nbnsd...
Running /usr/syno/etc/rc.d/J99avahi.sh...
Starting Avahi mDNS/DNS-SD Daemon
cname_load_conf failed:/var/tmp/nginx/avahi-aliases.conf
:: Loading module hid ... [  OK  ]
:: Loading mo[   46.880017] usbcore: registered new interface driver usbhid
dule usbhid[   46.905318] usbhid: USB HID core driver
 ... [  OK  ]
:: Loading module syno_hddmon ... [FAILED]
============ Date ============
Wed Jul 28 15:38
Wed Jul 28 15:38:09 2021

DiskStation login:

RedPill - the new loader for 6.2.4 - Discussion

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites