Debian Installation on Synology DS718+

I would like to replace Synology's DSM with Debian on a DS718+ for various reasons. Not much can be found in the internet concerning this topic for this special model (Intel apollolake, x86_64) so I am trying to find a way my myself.

First thing we need is a UART connection to the serial console of the device. When turning down the box so that power button and leds are on the lower sider, on the right side near the opening (near the RAM module) there is a 6 pin header:

back:  4   5   6

front: 1   2   3

The pins on the front side must be connected this way:

1: Rx -> connect to Tx of TTL Adapter
2: Tx -> connect to Rx of TTL Adapter
3: GND: GND of TTL Adapter can be attached to screw of the bottom cover instead of this pin

Pins 4, 5 and 6 are not needed.

When the serial connection is established (e.g. screen /dev/ttyUSB0 115200), power on the device, press ESC immediately and continue up to one minute until the EFI bootmanager opens. There is the possibility to enter BIOS but I did not change anything there. BIOS seems configured fine but highly and hard customized by Synology.

The bootmanager lets you select a different boot device but only USB devices are accepted. The device boots by default from a USB DOM but a USB stick plugged into the front usb port is recognized as well and is selectable. Elsewhere in the internet I found informations that these custom USB sticks must have the very same vendor and product id as the default USB DOM (both f400) but I cannot confirm that. I am using an ADATA C802 without modification of vendorid/productid.

So now we have a serial connection and a recognized USB stick. Next thing to mention is that the usual Debian installer iso images installed on this USB stick are not accepted by the bootloader. There must be an EFI partition containing grub, kernel image and initrd. So next problem is to install grub on the stick. Create an EFI partition and install grub there from a compatible x86_64 computer. I found a script with the important steps here.

Now it is important to rename on this EFI boot partition

mv /EFI/BOOT/grubx64.efi /EFI/BOOT/SynoBootLoader.efi

Otherwise grub is not found. The boot entries are as usual in /EFI/BOOT/grub.cfg

A sample entry in grub.cfg could be (templates can be found on Synology's USB DOM device):

#if set "serial --pci=[bus],[device],[function]", use mmio to implement console uart.
serial --pci=0,24,2 --speed=115200
terminal_input serial
terminal_output serial
set default='1'
set timeout='3'
set fallback='0'

menuentry 'My Debian installer' {
    insmod part_gpt
    insmod ext2
    linux /bzImage root=/dev/md0 earlyprintk=apl console=ttyS2,115200n8 ihd_num=2 netif_num=2 HddHotplug=1 SataPortMap=21 syno_hw_version=DS718+ vender_format_version=2 syno_hdd_detect=18,179,176,175 syno_hdd_enable=21,20,19,9 syno_usb_vbus_gpio="13@0000:00:15.0@3"
    initrd /initrd.gz
}

So now I want to start the debian installer from USB stick. Debian offers a kernel and initrd for the installer as download thought for running the installer from hard disk. This initrd can be used as a base but kernel modules which must be selfcompiled later must be added. The kernel cannot be used at all (at least this was my experience).

So the next big problem is to compile a customized kernel and modules. Synology has toolchains and source code ready for download but the kernel config ("4.4.59+") must be modified. The original version configures a lot of Synology proprietary steps mainly for signing kernel modules and initrd. These parameters must be removed and a kernel recompiled (attached my working kernel config). I found also that the Synology toolchain is really necessary. I've got a running kernel only when compiled with their toolchain. The gcc from a usual debian installation did not produce a runnable kernel.

At this point I have an initrd from the debian installer (enriched by kernel modules from the previous build) and a selfcompiled modified kernel and can configure grub to start the debian installer. When selecting my USB stick as boot device, the grub menu starts and I can select the debian installer. The installer starts fine, I can pass all dialogs and then the base system should get installed. But during this step at a certain point the installation fails with an error. From the installation log files I can see that the problem is that the installer cannot mount the target file system (-> attached syslog file from installer).

I have tried other solutions but until now without success:

• installation of debian with debootstrap (exit from debian installer into terminal and continue with this method)
• recompile util-linux (containing mount, libmount ..) with Synology's toolchain
• finally created my own toolchain using crosstool-ng (Synology used this for creating their toolchain as well)

No way out. Always the step when mounting the target filesystem from initrd fails with one or another error concerning missing mount permissions. Especially bind, slave and move mounts fail ("Are you root?", "Permission denied", ...). Instead mounting the target filesystem onto the initrd file system works as expected. Below the errors when booting debian installed manually with debootstrap and an initrd created there with mkinitrd:

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: M[    9.346825] usb 1-3: new high-speed USB device number 2 using xhci_hcd
ounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Will now check root file system ... fsck from util-linux 2.33.1
[/sbin/fsck.ext4 (1) -- /dev/sda2] fsck.ext4 -a -C0 /dev/sda2 
/dev/sda2: clean, 31847/4890624 files, 628870/19531264 blocks
[    9.447121] random: nonblocking pool is initialized
done.
[    9.483270] EXT4-fs (sda2): barriers disabled
[    9.492247] usb-storage 1-3:1.0: USB Mass Storage device detected
done.
[    9.493852] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[    9.508513] scsi host3: usb-storage 1-3:1.0
[    9.513333] usbcore: registered new interface driver usb-storagele
[    9.612832] usb 1-4: new high-speed USB device number 3 using xhci_hcd
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... mount: Operation not permitted
mount: invalid option --
done.
mount: Operation not permitted
mount: Operation not permitted
[    9.744014] EXT4-fs (sda2):  ext4_find_entry:1465: inode #3407873: comm run-init: checksumming directory block 0
[    9.744014] 
[    9.757334] usb-storage 1-4:1.0: USB Mass Storage device detected
[    9.764291] scsi host4: usb-storage 1-4:1.0
[    9.814884] EXT4-fs (sda2):  ext4_find_entry:1465: inode #4456451: comm run-init: checksumming directory block 0
[    9.814884] 
mount: Operation not permitted
mount: Operation not permitted
run-init: overmounting root: Operation not permitted
[    9.997939] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100

Currently out of ideas how to resolve this problem.

Any hint what could be the problem? Could it be the kernel where something is still misconfigured? The kernel is in fact the same for all these attempts.



Edited 4 time(s). Last edit at 08/14/2021 10:40AM by debi-718.

debi-718,

> an initrd created there with mkinitrd:

> Any hint what could be the problem? Could it be
> the kernel where something is still misconfigured?
> The kernel is in fact the same for all these
> attempts.

The above could be the problem. You ran debootstrap and now have a rootfs. When you install the kernel, should just let dpkg create the initrd for you. That way all the hooks are set up properly without you doing any thing extra. For example, running dpkg -i to install my Kirkwood kernel release will result in these 2 files (among others):

Quote

vmlinuz-5.13.6-kirkwood-tld-1
initrd.img-5.13.6-kirkwood-tld-1

To make this happens automatically, the kernel build must produce a Linux image the vmlinuz and the initrd packages in it. And to have such kernel package, the kernel must be configured to have those options.

So yes, I think probably the kernel configuration is not yet complete as you would want to.

-bodhi
===========================
Forum Wiki
bodhi's corner

> So yes, I think probably the kernel configuration
> is not yet complete as you would want to.

Or you missed a step somewhere. Perhaps this:

After creating the rootfs with debootstrap, chroot in and install kernel.

-bodhi
===========================
Forum Wiki
bodhi's corner

Thank you very much for your help, bodhi.

I have tried once again to install debian with debootstrap and used vmlinuz and initrd from this installation. The problem is that none of these default debian kernels run on the DS718+. The only usable kernel I've got so far comes from Syno's 4.4.59+ kernel sources compiled with their toolchain. I agree that the problems with my current setup derive most probably from incompatible versions of kernel, initrd and/or binaries inside of initrd. This suggests that I must compile everything inside the initrd with this toolchain as well. And so far I could not find documentation how to do this for debian.

Years ago I compiled everything with gentoo from scratch, but such a distribution is very difficult and time consuming to manage in the long run and not the best choice for a nas.



Edited 1 time(s). Last edit at 08/15/2021 08:13AM by debi-718.

debi-718,

What makes this difficult is this kernel is quite old. Even it is 4.4.59+, it does not use device tree.

So to do it right, the board files in this kernel need to be converted to device tree DTS. And then you can use it with a Debian mainline kernel for x86_64.

Perhaps you can find some works in progress for this box's device tree at Synology website?

-bodhi
===========================
Forum Wiki
bodhi's corner

Synology recently released DSM 7. The sources are not yet published and I didn't try this new version. Other people say that Synology never upgrade the kernel for a specific model. It remains the same for the whole lifetime of the model. No upgrade, no security patches. This is another important reason to leave DSM.

So far I could not find anything regarding device tree files for Synology models. I think it is pretty difficult to setup a dts from scratch. Up to now I have used such files provided by others for arm devices.

I have not yet made up my mind how to proceed. This stuff is rather time consuming.

Today I checked out DSM 7 for DS718+. The kernel remains in the long-term line 4.4 and was upgraded from 4.4.59 (26-Mar-2017) to 4.4.180 (16-May-2019).

The most recent published kernel for this line is however 4.4.282 from 27-Aug-2021.

Perhaps I find a bit more time to work on this problem in September.

@debi-718 did you give it another shot? It would be awesome if we could get a mainline kernel to boot on synology x86_64 devices.

No, I gave up. Writing device tree files from scratch is very complicated and time consuming for me.

Sorry I have basically no knowledge of embedded systems so please forgive me if I mixup things, I'm just trying to understand.

I was reading a bit into device trees and I don't get why we need to write our own. I though on x86 machines with a Bios that initialises the RAM we could just scan the busses, and discover things like storage and network that are connected via USB / PCI-E.
I always thought that this is what a generic x86_64 installer does, scanning/probing busses. So we would only miss stuff like fan controllers, LED's, buttons, and other GPIO, I2C and SPI stuff.
What is so different between the Synology x86 Hardware and a normal x86 PC?

Looks like a generic target that you can build a Debian kernel.

./arch/x86/configs/x86_64_defconfig

-bodhi
===========================
Forum Wiki
bodhi's corner

Hello,

I currently have a DS415+ laying around (x86_64, Intel Atom C2538) and was asking myself the same question. Would be quite useful running debian on it and adding functionality, to use it for example as a "better" backup server (and mainly for full disk encryption, which is not yet supported by DSM).

Is the missing device tree still a reason for the project to be abandoned or are there other things that could be tried? I'd be willing to test thing around and get serial logs if needed (But I too have only few knowledge in the field of embedded systems)

Radm,

I think for x86_64 it is generally not needed ot have device tree. You could just boot the kernel. But I'm not familiar with the x86 kernel, so will let others chime in.

-bodhi
===========================
Forum Wiki
bodhi's corner