Jump to content
XPEnology Community

Develop and refine the DS3622xs+ loader


yanjun

Recommended Posts

5 minutes ago, cferra said:

Are there kernel considerations for that img? I ask because those chips have avx-512 instructions and an ai engine. I doubt synology using those features but hr might be something that prevents booting like the 918 and haswell

 

@yanjun used a i9-9900K and was able to boot, so it might be no problem, the i9-9900K does not have avx-512 (specs from ark intel)

here the kernel config (cpu) for purley (fs6400)

 

Quote

#
# Processor type and features
#
CONFIG_ZONE_DMA=y
CONFIG_SMP=y
CONFIG_X86_FEATURE_NAMES=y
# CONFIG_X86_FAST_FEATURE_TESTS is not set
# CONFIG_X86_X2APIC is not set
CONFIG_X86_MPPARSE=y
CONFIG_RETPOLINE=y
# CONFIG_X86_EXTENDED_PLATFORM is not set
# CONFIG_X86_INTEL_LPSS is not set
# CONFIG_X86_AMD_PLATFORM_DEVICE is not set
# CONFIG_IOSF_MBI is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
# CONFIG_HYPERVISOR_GUEST is not set
CONFIG_NO_BOOTMEM=y
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_PROCESSOR_SELECT=y
CONFIG_CPU_SUP_INTEL=y
# CONFIG_CPU_SUP_AMD is not set
# CONFIG_CPU_SUP_CENTAUR is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
# CONFIG_CALGARY_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_MAXSMP is not set
CONFIG_NR_CPUS=64
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
# CONFIG_X86_MCE_AMD is not set
CONFIG_X86_MCE_THRESHOLD=y
CONFIG_X86_MCE_INJECT=m
CONFIG_X86_THERMAL_VECTOR=y
# CONFIG_VM86 is not set
CONFIG_X86_VSYSCALL_EMULATION=y
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_X86_DIRECT_GBPAGES=y
CONFIG_NUMA=y
# CONFIG_AMD_NUMA is not set
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NODES_SPAN_OTHER_NODES=y
CONFIG_NUMA_EMU=y
CONFIG_NODES_SHIFT=6
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
# CONFIG_MOVABLE_NODE is not set
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_MEMORY_FAILURE is not set
# CONFIG_TRANSPARENT_HUGEPAGE is not set
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
# CONFIG_CMA is not set
# CONFIG_ZPOOL is not set
# CONFIG_ZBUD is not set
CONFIG_ZSMALLOC=y
# CONFIG_PGTABLE_MAPPING is not set
# CONFIG_ZSMALLOC_STAT is not set
CONFIG_GENERIC_EARLY_IOREMAP=y
CONFIG_ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT=y
# CONFIG_IDLE_PAGE_TRACKING is not set
CONFIG_FRAME_VECTOR=y
# CONFIG_X86_PMEM_LEGACY is not set
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
# CONFIG_X86_PAT is not set
CONFIG_ARCH_RANDOM=y
CONFIG_X86_SMAP=y
# CONFIG_X86_INTEL_MPX is not set
CONFIG_EFI=y
# CONFIG_EFI_STUB is not set
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
# CONFIG_KEXEC_JUMP is not set
CONFIG_PHYSICAL_START=0x100000
CONFIG_RELOCATABLE=y
# CONFIG_RANDOMIZE_BASE is not set
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
# CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set
# CONFIG_DEBUG_HOTPLUG_CPU0 is not set
# CONFIG_COMPAT_VDSO is not set
# CONFIG_LEGACY_VSYSCALL_NATIVE is not set
CONFIG_LEGACY_VSYSCALL_EMULATE=y
# CONFIG_LEGACY_VSYSCALL_NONE is not set
# CONFIG_CMDLINE_BOOL is not set
# CONFIG_MODIFY_LDT_SYSCALL is not set
CONFIG_HAVE_LIVEPATCH=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_USE_PERCPU_NUMA_NODE_ID=y

 

Link to comment
Share on other sites

12 minutes ago, cferra said:

Ok that’s cool should be work on my Xeon E5 v4s - no dual cpu considerations there either?

also, her used one i9-9900K and it worked

 

there is a synology specific for multi_cpu but i guess its just for showing something in cpu-info (the context imply's that)

CONFIG_SYNO_DISPLAY_CPUINFO=y
CONFIG_SYNO_MULTI_CPU_NUM=2

Link to comment
Share on other sites

12 hours ago, IG-88 said:

 

might be the same problem as with 918+ and newer mpt2/3 drivers for 3615/17  in 6.2.x

https://xpenology.com/forum/topic/28321-driver-extension-jun-103b104b-for-dsm623-for-918-3615xs-3617xs/
 


"...
edit2 02.06.2020: as @richv31 pointed out here
...
there seems to be a serious problem with 918+ and scsi/sas drivers, at least with mpt2sas/mpt3sas, not just with 6.2.2/6.2.3 it also happens with jun's original loader 1.04b and dsm 6.2.0 (23824), breaking raid sets after not properly waking up from hdd hibernation means potential data loss

i had a two disk raid1 set on a lsi 9211-8i and after disks spinning down only one came up and i saw some really worrying messages on the serial console, i was not able to log in to the system, not on the web gui, even not on the serial console, the whole system was in lock down and only switching off seemed to work
..."

 

jun's  918+ scsi_transport_sas.ko and mpt3sas.ko did work with smart values but seems to be missing synologys proprietary(?) power management and failed when using disk hibernation, same files used from synologys kernel source where working safely with disk hibernation but where missing smart values

presumably because synology mods kernel for smart but as they dont use mpt3 from kernel dont mod kernels own driver and instead mod a external driver accordingly (and that driver source is not available), so when we build a driver from additional source the mods for smart are missing and the driver fails to make use of these things

in my 6.2.3 extra's, for 918+ i was choosing the safe way and only used stuff build from synologys kernel source to avoid trouble with broken raids but loosing smart, for 3615/17 its just the original drivers from synology and as 3617 has newer mpt3sas driver then 3615 its best to use 3617 when using lsi sas controllers

(i stopped using them myself because of theses problems, there odd behavior with handling disk and controller ports  and it looked like the disk where running with only write through cache and  dsm was unable to activate write back for disk cache with mpt2sas, what is working all fine with sata/ahci)

 

imho loosing smart is not the greatest loss, you loose serial number of the disks too and that can make replacing a failed disk kind of dangerous as its hard to get the right position of as disk with the mpt2/3sas driver behavior to always line all found disk one after another, with sata/ahci every port is fix and when there is no disk that its a empty "slot", with the mpt sas driver there is no empty slot and disk will "change positions" so even writing down SN  and cable positions (1-8) does not help as these positions are not line up with what the driver uses

when a disk fails and you cant see SN's you cant determine what disk SN is missing  because you dont see any SN in the GUI and the position is not help because if the disk is not there anymore the "gap" is filled with the next working disk (afair the SN's are still visible in dmesg but that not for everyone, and the easy way of using dsm is lost in some way)

 

 

Thanks to ig-88, I am currently maintaining the extra driver version 0.12.1 due to the SMART issue of H310 within JUN's loader 1.04b and DSM 6.2.3. To this end, hard disk hibernation has been abandoned. I have been using XPENOLOGY well for over a year with extra driver 0.12.1.
I still thank Jun and ig-88 for their hard work.

And, I also mentioned yesterday that there is no detailed S.M.A.R.T in the health information.

https://xpenology.com/forum/topic/56872-develop-and-refine-the-ds3622xs-loader/?do=findComment&comment=266772

Problems of DS918+'s mpt2sas/mpt3sas driver mentioned by ig-88 and
I wanted to talk about the relationship between these two drivers.
@pocopico's answer said that the mpt3sas of 3622xs+ already contains mpt2sas.
In DS3622xxs+, do we need to mention mpt2 anymore and only think about mpt3?
I don't know in detail because I don't have the ability to compile the code myself.
@IG-88, did you happen to have Jun's ds918+ scsi_transport_sas.ko driver
Can it be the key to solving this smart issue?
Or, apart from that, which other driver should be involved?

Link to comment
Share on other sites

13 hours ago, IG-88 said:

imho loosing smart is not the greatest loss, you loose serial number of the disks too and that can make replacing a failed disk kind of dangerous as its hard to get the right position of as disk with the mpt2/3sas driver behavior to always line all found disk one after another, with sata/ahci every port is fix and when there is no disk that its a empty "slot", with the mpt sas driver there is no empty slot and disk will "change positions" so even writing down SN  and cable positions (1-8) does not help as these positions are not line up with what the driver uses

LSI-9400 16i SN information is still available. In my opinion, the current mpt3sas version (40.0/41.0) comes from Broadcom's release on the official website for the LSI 9400/9500 series, so the compatibility with the previous array cards may be weaker.

 

image.thumb.png.705a1ff2a63e0efe0d736d1a02c84379.png

Link to comment
Share on other sites

12 hours ago, IG-88 said:

not really if it come to me i guess but it looks like its crashing when using the 2nd com port and afair there is a pic based controller that (beside fan und buzzer stuff)  is also used for checking for validity of the system

edit

there was also something about differences in hardware of systems and port swapping

These models who have the following config may be need do more works in lkm.

CONFIG_SYNO_FIX_TTYS_FUNCTIONS=y
CONFIG_SYNO_TTYS_FUN_NUM=2

 

image.thumb.png.95da58cb0f36884d56c358c2428f725d.png

 

Related code indrivers/tty/serial/8250/8250_core.c 

#ifdef MY_ABC_HERE
        for (i = CONFIG_SYNO_TTYS_FUN_NUM; i < nr_uarts; i++)
#else /* MY_ABC_HERE */
        for (i = 0; i < nr_uarts; i++)
#endif /* MY_ABC_HERE */
                if (uart_match_port(&serial8250_ports[i].port, port))
                        return &serial8250_ports[i];

        /* try line number first if still available */
        i = port->line;
        if (i < nr_uarts && serial8250_ports[i].port.type == PORT_UNKNOWN &&
                        serial8250_ports[i].port.iobase == 0
#ifdef MY_ABC_HERE
                        && i > (CONFIG_SYNO_TTYS_FUN_NUM - 1)
#endif /* MY_ABC_HERE */
        )
                return &serial8250_ports[i];
        /*
         * We didn't find a matching entry, so look for the first
         * free entry.  We look for one which hasn't been previously
         * used (indicated by zero iobase).
         */
#ifdef MY_ABC_HERE
        for (i = CONFIG_SYNO_TTYS_FUN_NUM; i < nr_uarts; i++)
#else /* MY_ABC_HERE */
        for (i = 0; i < nr_uarts; i++)
#endif /* MY_ABC_HERE */
                if (serial8250_ports[i].port.type == PORT_UNKNOWN &&
                    serial8250_ports[i].port.iobase == 0)
                        return &serial8250_ports[i];

        /*
         * That also failed.  Last resort is to find any entry which
         * doesn't have a real port associated with it.

 

 

Syno linux kernel file arch/x86/include/asm/serial.h

#ifndef MY_ABC_HERE
#define MY_ABC_HERE
#endif
#ifndef _ASM_X86_SERIAL_H
#define _ASM_X86_SERIAL_H

/*
 * This assumes you have a 1.8432 MHz clock for your UART.
 *
 * It'd be nice if someone built a serial card with a 24.576 MHz
 * clock, since the 16550A is capable of handling a top speed of 1.5
 * megabits/second; but this requires a faster clock.
 */
#define BASE_BAUD (1843200/16)

/* Standard COM flags (except for COM4, because of the 8514 problem) */
#ifdef CONFIG_SERIAL_8250_DETECT_IRQ
# define STD_COMX_FLAGS (UPF_BOOT_AUTOCONF |    UPF_SKIP_TEST   | UPF_AUTO_IRQ)
# define STD_COM4_FLAGS (UPF_BOOT_AUTOCONF |    0               | UPF_AUTO_IRQ)
#else
# define STD_COMX_FLAGS (UPF_BOOT_AUTOCONF |    UPF_SKIP_TEST   | 0             )
# define STD_COM4_FLAGS (UPF_BOOT_AUTOCONF |    0               | 0             )
#endif
#ifdef MY_DEF_HERE
        /* ApolloLake use HSUART, not legacy uart, don't config 0x3F8 serial port */ \
#define SERIAL_PORT_DFNS                                                                \
        /* UART         CLK             PORT    IRQ     FLAGS                       */  \
        { .uart = 0,    BASE_BAUD,      0xFFF,  4,      STD_COMX_FLAGS  }, /* ttyS0 */  \
        { .uart = 0,    BASE_BAUD,      0x2F8,  3,      STD_COMX_FLAGS  }, /* ttyS1 */  \
        { .uart = 0,    BASE_BAUD,      0x3E8,  4,      STD_COMX_FLAGS  }, /* ttyS2 */  \
        { .uart = 0,    BASE_BAUD,      0x2E8,  3,      STD_COM4_FLAGS  }, /* ttyS3 */

#else /* MY_DEF_HERE */

#ifdef MY_DEF_HERE
#define SERIAL_PORT_DFNS                                                                \
        /* UART         CLK             PORT    IRQ     FLAGS                       */  \
        { .uart = 0,    BASE_BAUD,      0x2F8,  3,      STD_COMX_FLAGS  }, /* ttyS0 */  \
        { .uart = 0,    BASE_BAUD,      0x3F8,  4,      STD_COMX_FLAGS  }, /* ttyS1 */  \
        { .uart = 0,    BASE_BAUD,      0x3E8,  4,      STD_COMX_FLAGS  }, /* ttyS2 */  \
        { .uart = 0,    BASE_BAUD,      0x2E8,  3,      STD_COM4_FLAGS  }, /* ttyS3 */
#else /* MY_DEF_HERE */
#define SERIAL_PORT_DFNS                                                                \
        /* UART         CLK             PORT    IRQ     FLAGS                       */  \
        { .uart = 0,    BASE_BAUD,      0x3F8,  4,      STD_COMX_FLAGS  }, /* ttyS0 */  \
        { .uart = 0,    BASE_BAUD,      0x2F8,  3,      STD_COMX_FLAGS  }, /* ttyS1 */  \
        { .uart = 0,    BASE_BAUD,      0x3E8,  4,      STD_COMX_FLAGS  }, /* ttyS2 */  \
        { .uart = 0,    BASE_BAUD,      0x2E8,  3,      STD_COM4_FLAGS  }, /* ttyS3 */
#endif /* MY_DEF_HERE */

#endif /* MY_DEF_HERE */

#endif /* _ASM_X86_SERIAL_H */

 

Edited by yanjun
Link to comment
Share on other sites

16 hours ago, IG-88 said:

 

might be the same problem as with 918+ and newer mpt2/3 drivers for 3615/17  in 6.2.x

https://xpenology.com/forum/topic/28321-driver-extension-jun-103b104b-for-dsm623-for-918-3615xs-3617xs/
 


"...
edit2 02.06.2020: as @richv31 pointed out here
...
there seems to be a serious problem with 918+ and scsi/sas drivers, at least with mpt2sas/mpt3sas, not just with 6.2.2/6.2.3 it also happens with jun's original loader 1.04b and dsm 6.2.0 (23824), breaking raid sets after not properly waking up from hdd hibernation means potential data loss

i had a two disk raid1 set on a lsi 9211-8i and after disks spinning down only one came up and i saw some really worrying messages on the serial console, i was not able to log in to the system, not on the web gui, even not on the serial console, the whole system was in lock down and only switching off seemed to work
..."

 

jun's  918+ scsi_transport_sas.ko and mpt3sas.ko did work with smart values but seems to be missing synologys proprietary(?) power management and failed when using disk hibernation, same files used from synologys kernel source where working safely with disk hibernation but where missing smart values

presumably because synology mods kernel for smart but as they dont use mpt3 from kernel dont mod kernels own driver and instead mod a external driver accordingly (and that driver source is not available), so when we build a driver from additional source the mods for smart are missing and the driver fails to make use of these things

in my 6.2.3 extra's, for 918+ i was choosing the safe way and only used stuff build from synologys kernel source to avoid trouble with broken raids but loosing smart, for 3615/17 its just the original drivers from synology and as 3617 has newer mpt3sas driver then 3615 its best to use 3617 when using lsi sas controllers

(i stopped using them myself because of theses problems, there odd behavior with handling disk and controller ports  and it looked like the disk where running with only write through cache and  dsm was unable to activate write back for disk cache with mpt2sas, what is working all fine with sata/ahci)

 

imho loosing smart is not the greatest loss, you loose serial number of the disks too and that can make replacing a failed disk kind of dangerous as its hard to get the right position of as disk with the mpt2/3sas driver behavior to always line all found disk one after another, with sata/ahci every port is fix and when there is no disk that its a empty "slot", with the mpt sas driver there is no empty slot and disk will "change positions" so even writing down SN  and cable positions (1-8) does not help as these positions are not line up with what the driver uses

when a disk fails and you cant see SN's you cant determine what disk SN is missing  because you dont see any SN in the GUI and the position is not help because if the disk is not there anymore the "gap" is filled with the next working disk (afair the SN's are still visible in dmesg but that not for everyone, and the easy way of using dsm is lost in some way)

 

The synokernel modules are exporting various syno symbols that are used by DSM internal processes for various reasons. For instance MPT3SAS on their kernel export :

 

mpt3sas_base.h: u8              syno_ids;
mpt3sas_ctl.c:  if (0 != ioc->syno_ids) {
mpt3sas_ctl.c:          return snprintf(buf, 16, "%s_%d\n", ioc->manu_pg0.BoardName, ioc->syno_ids);
mpt3sas_scsih.c:static int syno_mpt_ids;
mpt3sas_scsih.c: * syno_handle_lsi3008_set_led - control SAS handle LED
mpt3sas_scsih.c:syno_handle_lsi3008_set_led(struct MPT3SAS_ADAPTER *ioc, u16 handle, int status)
mpt3sas_scsih.c: * syno_scsih_lsi3008_set_led - control SAS HOST LED
mpt3sas_scsih.c:syno_scsih_lsi3008_set_led(struct scsi_device *sdev, int status)
mpt3sas_scsih.c:        iRet = syno_handle_lsi3008_set_led(ioc, handle, status);
mpt3sas_scsih.c:#if defined(MY_ABC_HERE) || defined(CONFIG_SYNO_PORT_MAPPING_V2)
mpt3sas_scsih.c:        .syno_port_type                 = SYNO_PORT_TYPE_SAS,
mpt3sas_scsih.c:        shost->hostt->syno_set_sashost_disk_led = syno_scsih_lsi3008_set_led;
mpt3sas_scsih.c:        ioc->syno_ids = syno_mpt_ids++;
mpt3sas_scsih.c:        syno_mpt_ids = 1;

 

We dont know what other kernel/module symbols we are missing as we dont have all the bits. So the more you are drifting away from the standard synology HW, the more you end up in situations that DSM will not automatically handle. SMART might be that case. 

 

 

 

 

Link to comment
Share on other sites

I tried to upgrade DS918 7.0.1 42218 U2 to DS3622 7.0.1 42218 U2 at the booth. The migration was successful, but there are a number of issues.
1. Now it says in the notification manager that my RAM is not compatible, how can I remove it?
2. I wrote the serial number and the mac from DS3617, the serial number was registered, but the mac is different from what is in the bootloader, apparently because of this I can't log in to synology and quickconnect. How can this be fixed? I saw in tynycore the ability to generate serial numbers, are they working? Can I take it from there?

Link to comment
Share on other sites

20 minutes ago, aportnov said:

I tried to upgrade DS918 7.0.1 42218 U2 to DS3622 7.0.1 42218 U2 at the booth. The migration was successful, but there are a number of issues.
1. Now it says in the notification manager that my RAM is not compatible, how can I remove it?
2. I wrote the serial number and the mac from DS3617, the serial number was registered, but the mac is different from what is in the bootloader, apparently because of this I can't log in to synology and quickconnect. How can this be fixed? I saw in tynycore the ability to generate serial numbers, are they working? Can I take it from there?

You will NEVER be able to login to Synology account & quick connect without a REAL synology SN matching the current loaded DSM.

The serials only match the form factor or real SN but are totally random and will NEVER work for Synology online services.

 

In other words : if you run DS3622xs+ loader, you NEED a real SN and MAC address from a REAL DS3622xs+, it won't work with any other real SN (DS918+, DS3617xs, etc...)

 

Edit : and no need to duplicate your post in other topics.. Once is enough.

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

31 минуту назад, Orphée сказал:

You will NEVER be able to login to Synology account & quick connect without a REAL synology SN matching the current loaded DSM.

The serials only match the form factor or real SN but are totally random and will NEVER work for Synology online services.

 

In other words : if you run DS3622xs+ loader, you NEED a real SN and MAC address from a REAL DS3622xs+, it won't work with any other real SN (DS918+, DS3617xs, etc...)

 

Edit : and no need to duplicate your post in other topics.. Once is enough.

You're wrong. On 918 I use real ones from 1019 and everything works.

Link to comment
Share on other sites

34 минуты назад, altas сказал:

i noticed the same with the MAC's.. the tinyloader does not reconize my correct mac adresses, i had to manualy adjust it befor start the build.

 

 

I also wrote my own everything before assembling. I don't use automatic substitutions, but I am experiencing a problem

Link to comment
Share on other sites

59 minutes ago, aportnov said:

What is this parameter "support_bde_internal_10g": "no" responsible for? migration did not take place without it


On ds3622xs+ that has onboard 10g interfaces the loading sequence tries to enable those interfaces and loops several time before it times out to the bring up other 1G  network interfaces. It’s just to not try to load ixgbe 10G module. 

Link to comment
Share on other sites

@pocopico

 

I have ask it several times?

 

Is it possible to change the download path dor the .pat files to https://global.download.synology.com/download/DSM/release/7.0.1/42218/DSM_DS3622xs+_42218.pat

I am trying to install DS3622xs+, but it will not download from https://cndl.synology.cn/download/DSM/release/7.0.1/42218/DSM_DS3622xs+_42218.pat

 

Thank you very much!!

 

ps: I know I have ask several times in this threath, but still no answer.

 

Link to comment
Share on other sites

Just now, MSXGames said:

@pocopico

 

I have ask it several times?

 

Is it possible to change the download path dor the .pat files to https://global.download.synology.com/download/DSM/release/7.0.1/42218/DSM_DS3622xs+_42218.pat

I am trying to install DS3622xs+, but it will not download from https://cndl.synology.cn/download/DSM/release/7.0.1/42218/DSM_DS3622xs+_42218.pat

 

Thank you very much!!

 

ps: I know I have ask several times in this threath, but still no answer.

 


I have no answer to that my friend. I think synology does all the redirection to the closest mirror. I happen to also end in chinas mirror that is SLooowwww 

Link to comment
Share on other sites

25 minutes ago, altas said:

@MSXGameswhy not pre-download tha pat file befor start the building and put it in the Cache Folder ??
 

@pocopico and @altas

 

Well, I have checkt with a vpn connection to an other country, and the the site is working and redpill is working.

Now checkt it with vpn on and installing thru the app and it is working, slow yes, but it is downloading it.

Sorry for the inconvience and thank you for the help.

Still I do not know what the problem is, but he, it worked now.

Link to comment
Share on other sites

1 hour ago, aportnov said:

I took a new real bundle of mac sn 3622, but again I have one mac registered in grub.cfg and another in dhcp. What am I doing wrong?

@aportnov Do you mind sending me SN and MAC address privately, I won't reveal him, just try to find it's pattern.

Link to comment
Share on other sites

1 hour ago, ryancc said:

Will 3622 support nvme cache? I did not see the model under libsynonvme.so.1

synology sells a pcie card for nvme and since 7.0.1 even 3617 does support nvme (it also got kernel 4.4) and 3622 for sure supports nvme, just look into the *.pat file, we will see if and when someone will doing it

Edited by IG-88
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...