Debian Installation on Synology DS718+

screw it :), just dump the sources/patches, really.

as long as it is not "integrated", there's not much risk and even then, it will bad PR for Synology to mess with DIY community.

anyway, thank you all for your work, I'm looking forward to do it on my box.

Let me reply to the recent posts here.

First point is that whoever wants to write me a hidden message can do so with a private message using a tool of this forum. There is no need to disclose private email addresses.

Next point license. Source code from kernel.org is published under GPL license. The kernel sources from Synology can be found here. The directory path where this archive is put suggests that it is covered by GPL and furthermore the

COPYING

file of the kernel sources is left unchanged. On the other hand license information is removed on important files like

drivers/ata/libata-core.c

where most modifications have to be done. This file for example has no explicit license information. Can someone explain which license is valid for the kernel?

I am not a lawyer and I would get into trouble at my company if it comes out that I am involved in licensing infringement issues. That's why I am a little bit paranoid. I will check next week if I can get a qualified response from a lawyer and what would be the price.

> file of the kernel sources is left unchanged. On
> the other hand license information is removed on
> important files like
>
>

> drivers/ata/libata-core.c
>

>
> where most modifications have to be done. This
> file for example has no explicit license
> information. Can someone explain which license is
> valid for the kernel?

Then Synology has violated GPL license. So don't host that downloaded tarball yourself as a public service to others.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

debi-718 Wrote:
-------------------------------------------------------
> Let me reply to the recent posts here.
>
> First point is that whoever wants to write me a
> hidden message can do so with a private message
> using a tool of this forum. There is no need to
> disclose private email addresses.
>
> Next point license. Source code from kernel.org is
> published under GPL license. The kernel sources
> from Synology can be found
> here.
> The directory path where this archive is put
> suggests that it is covered by GPL and furthermore
> the
>
>

> COPYING
>

>
> file of the kernel sources is left unchanged. On
> the other hand license information is removed on
> important files like
>
>

> drivers/ata/libata-core.c
>

>
> where most modifications have to be done. This
> file for example has no explicit license
> information. Can someone explain which license is
> valid for the kernel?
>
> I am not a lawyer and I would get into trouble at
> my company if it comes out that I am involved in
> licensing infringement issues. That's why I am a
> little bit paranoid. I will check next week if I
> can get a qualified response from a lawyer and
> what would be the price.

Can't you just publish a script that fetches the sources from synology combined with a patch set of your changes that is applied by the script (+ of course all other files you wrote by yourself)? I can't see how this would violated any licenses. I think it would be valuable to have your work publicly available for many others.

The situation is a little bit different. Original source code from kernel.org is patched with code from Synology. For me it is unclear which copyright applies to this Synology code.

In my opinion if Synology is patching kernel code then their patches must be GPL, otherwise they're in violation of the kernel license.

Ray

Quote
rayknight
In my opinion if Synology is patching kernel code then their patches must be GPL, otherwise they're in violation of the kernel license.

Yes I think you are right. I have found a good page for all this questions about GPL (FAQ gnu.org)

So I will post code later here. Thank you.



Edited 1 time(s). Last edit at 08/10/2024 12:47AM by debi-718.

As a first step please checkout a tar file including my grub bootloader for DS718+ (grub bootloader debian DS718+)

sha256sum: 6d0c8928dfc2cd490b7931d8eb419ab882e8be32922cc78b98917feddcc01be7  grub-ds718p-linux-5.10.158.tgz

Untar it on a fat32-formatted USB stick partition and edit the grub.cfg

./EFI/BOOT/grub.cfg

The root device must be specified. I created a root filesystem for debian with debootstrap (x86_64) but cannot share it here for the moment. Keep the other parameters unchanged, they are in part specific for DS718+ and might not work on other models.

Plug the stick into the front connector of the DS718+ and boot the box using a serial console. This procedure is described for DS718+ at the beginning of this thread. Kernel (5.10.158) and initrd are inside the archive and I will post source code for the kernel later.

Added debian kernel modules (5.10.158)

linux-5.10.158 kernel modules

sha256sum: 3ecd320bf30dd2a233cf3a66552fff758f75f293eceb55017a67b865bebc22f8  modules-5.10.158-rt77+.tar.gz

untar it into /usr/lib/modules of the root filesystem.



Edited 2 time(s). Last edit at 08/10/2024 05:14AM by debi-718.

Here is a rootfs of debian release bullseye for DS718+:

rootfs debian bullseye DS718+

sha256sum: e1905e7d0d1409c2169591e01356a9367412ba9f894360e868ebe16c8ebfa67a  rootfs-bullseye-linux-5.10.158.tar.bz2

If you won't wait for the source code and start immediately with this binaries I would suggest the following procedure:

• Create a GPT partition table on an empty USB-3 stick
• Add a fat-32 partition of size 256 MiB and untar the above linked grub archive there
• Create a 20 GiB ext4 data partition and untar the rootfs linked in this post
• Update the grub.cfg in the grub partition and set the root filesystem to the ext4 partition
• Remove all hard disks from DS718+ and plug the USB stick into the front connector of the box
• Power on the device and boot from USB stick using the serial connection
• Later when the installation is fine add hard disks and check if they are powered on correctly
• The initrd contains a configuration file for mdadm (/etc/mdadm/mdadm.conf). Please check this file if it is fine for you.

The rootfs is from release 'bullseye', labeled now 'oldstable'. You should update this rootfs to release 'bookworm' soon like you update any debian system. The kernel 5.10.158 is compatible with 'bookworm'.

The login for the root user has password 'root'. I don't remember how comfortable this rootfs is. It should be sufficient to install a complete systemd based os and then update to bookworm.

Here comes the source code:

syno-linux-5.10.158

sha256sum: 58ff98ee1a3aa83f4a6251f95c8b315567934bb365fc4a9c395de158fdd0966d  syno-linux-5.10.158-doozan.zip

I have built it tomorrow morning successfully on a Debian GNU/Linux 12 (bookworm) installation:

mkdir ../syno-linux-5.10.158-modules
mkdir ../syno-linux-5.10.158-kernel

make menuconfig
make -j1
make -j1 modules
make -j1 INSTALL_MOD_PATH=../syno-linux-5.10.158-modules modules_install
make -j1 bzImage
make -j1 INSTALL_PATH=../syno-linux-5.10.158-kernel install
make -j1 bindeb-pkg

I intend to create a patch file with only the essential changes as soon as I can find the time (this task seems more complicated than I believed). That patch would be helpful to update the kernel.

Here is the collection of essential patches: patches-syno-linux-5.10.158.zip

sha256: 6d9bcda1efdb988c393ff95e8d674b3e4fd3fc57fa8242d7b31f641898360bba  patches-syno-linux-5.10.158.zip

These patches can be used to update the kernel or to port Debian to a different Synology model.

One remark concerning the kernel config. The section for the Synology kernel configuration should not be changed. This section is only added to get the kernel patches compiled. They refer to some of these kernel configurations.

Thank you so much debi-718!

I'll try this out in the coming weeks.

Did you get to publishing the patches?

Regarding the license: the kernel is published under GPLv2, Synology is legally obliged to publish their modifications under GPLv2 as well, and we absolutely can take their code, modify it, and publish again under GPLv2.

EDIT: only just now noticed that there's a second page of discussion :)



Edited 1 time(s). Last edit at 10/19/2024 09:10AM by imax.

Hi, Maybe a little off-topic but is it possible to change the Serial Number / Mac1 / Mac2 addresses? As XPEnology clearly uses bootloader kernel pararmeters like:

title SYNOLOGY
       root (hd0,1)
#       cksum /grub_cksum.syno
#       vender /vender show
#       hw_model
       kernel /zImage root=/dev/md0 ihd_num=0 netif_num=2 syno_hw_version=DS3612xs mac1=00113208d68a mac2=00113208d68b mac3=004d9469c492 mac4=004d9469c493 sn=B3J4N00001
       initrd /rd.gz

I have a banned DS1520+ and I was wondering where the kernel parameter command line is stored? Possibly somewhere on the USB DOM media and would it be possible to change it? I do have an old serial number of an old Synology NAS witch I ditched a long time ago (so nobody uses it anymore). When I use the old serial in an XPEnology VM I discovered that Synology corp. flags this Virtual Synology as an original Synology NAS device so I like to add this serial as sn parameter to the kernel parameters and un-ban my DS1520+ this way.

First thing to mention is that this is not the right forum for your questions. Anyway, to help you:

• yes, the grub bootloader is on a partition of the USB-DOM (at least on my Snology device 718+)
• yes, you can change the grub configuration. If you have only DSM as an operating system (could Debian be an option for you?) you probably must remove the device and attach it to a computer in order to modify files there. DSM makes this device readonly (-> use dd to copy it's content).
• serial number or mac adresses are part of the hardware and usually read only. I am not aware that Synology offers kernel parameters to configure these values.

debi-718 Wrote:
-------------------------------------------------------

> [*] yes, you can change the grub configuration. If
> you have only DSM as an operating system (could
> Debian be an option for you?) you probably must
> remove the device and attach it to a computer in
> order to modify files there. DSM makes this device
> readonly (-> use dd to copy it's content).

No need, the code that prevents mounting it looks like this:

long do_mount(const char *dev_name, const char __user *dir_name,
		const char *type_page, unsigned long flags, void *data_page)
{
	struct path path;
	int retval = 0;
	int mnt_flags = 0;

#ifdef MY_ABC_HERE
	extern int gSynoInstallFlag;
	if ( 0 == gSynoInstallFlag &&
#ifdef MY_ABC_HERE
			gSynoHasDynModule &&
#endif /* MY_ABC_HERE */
			NULL != dev_name &&
			strstr(dev_name, CONFIG_SYNO_USB_FLASH_DEVICE_PATH)) {
		return -EINVAL;
	}
#endif /*MY_ABC_HERE*/

So as long as the device path you pass to the `mount` command does not contain a substring "/dev/synoboot". The simplest way to achieve that is probably this:

cd /dev; sudo mount ./synoboot1 /mnt

(And yes, don't forget to do your modifications to both synoboot1 and synoboot2)