IG-88

karte rein, platten dran, usb mit xpenology loader booten (vid/pid muss angepasst sein) und das war's. wenn es ein marvell 9215 ist dann ist es ahci und funktioniert einfach so da es für die oboard 's keinen treiber gibt sollten die auch nirgends auftauchen

maybe 5x4tb as raid5 and the rest as jbod for backup

delete the old extra.lzma before copying the new the 2nd partition has 30MB, zImage and rd.gz is about 9MB, one extra.lzma is about 4-6MB afaik you can't the part of unpacking and packing it ist just nor mal linux stuff, you can read about it here and for just unpacking, packing you can boot up a live linux in virtualbox on windows and nowdays windows 10 even can have a linux installed (but a vm und a cd image in virtualbox is easier to get rid of after wards https://xpenology.com/forum/topic/7187-how-to-build-and-inject-missing-drivers-in-jun-loader-102a/ https://xpenology.club/compile-drivers-xpenology-with-windows-10-and-build-in-bash/

ok, with the grep we only see the line with the driver and not the info about the pcie device "lspci -k" and then the two sections with e1000e would be something like this (in my case here for tn40xx) 0000:07:00.0 Class 0200: Device 1fc9:4024 Subsystem: Device 1fc9:3015 Kernel driver in use: tn40xx result for dmesg might look like this, e1000e in this case is jaust loaded but no hardware present, if the hardware is present there will be more (like tn40xx in my example) [ 37.134864] e1000e: Intel(R) PRO/1000 Network Driver - 3.3.4-NAPI [ 37.134868] e1000e: Copyright(c) 1999 - 2016 Intel Corporation. ... [ 37.160143] tn40xx low_mem_msg proc entry initialized [ 37.160147] tn40xx low_mem_counter proc entry initialized [ 37.160150] tn40xx debug_msg proc entry initialized [ 37.160151] tn40xx: Tehuti Network Driver, 0.3.6.12.3 [ 37.160247] tn40xx: tn40xx [ 37.160252] tn40xx: srom 0x0 HWver 16 build 0 lane# 4 max_pl 0x0 mrrs 0x2 [ 37.160378] tn40xx 0000:07:00.0: irq 48 for MSI/MSI-X [ 37.681009] tn40xx: PHY detected on port 28 ID=1405896 - MV88X3120 10Gbps 10GBase-T

update package 4, 918+, files inside: "linux-4.4.x-apollolake-bin_4.4.15-24922-s4_all.deb", package with new kernel drivers, does not contain a new e1000e.ko driver and there is only "flashupdate_6.2-24922-s3_all.deb" no "s4", that flashupdate could contain a new rd.gz with a new driver usually a new driver would be in "linux-4.4.x-apollolake-bin_4.4.15-24922*" and "flashupdate*" and there is no e1000e.ko in all updates whatever you did its not coming from the dsm updat4 e1000e.ko inside rd.gz u3, version 3.3.4 e1000e. ko in initial 6.2.2, version 3.3.4 so nothing to support your claim that u4 is the reason i also checked 6.2.0 (v23739), e1000e.ko version 3.3.4 either it worked all the time and you did not noticed it or you introduced a new driver like from my extra.lzma (contains version 3.6.0) please check log on console with "dmesg" to see whats written to the log, when starting the driver, there should be a version number for the driver in use also please check with " lspci -k | grep 'Kernel driver' " what vendor- and product-id your i217-lm nic has, that can usually be checked against a driver (source) to see if a device is supported

maybe, there are a lot of N54L around here and its not a typical problem (like the c2e setting in bios to install xpenology) you can look around here https://xpenology.com/forum/topic/22482-dsm-622-24922-update-4/page/2/?tab=comments#comment-125926 and message one or the other what bios they use and about the settings maybe the hint about acpi 1.0 is enough? - Outcome of the update: SUCCESSFUL - DSM version prior update:DSM 6.2.2-24922-3 - Loader version and model: JUN'S LOADER v1.03b - DS3615xs - Using custom extra.lzma: NO - Installation type: BAREMETAL - HP N54L gen7 + Intel NIC - Additional comment: Reboot required, restart + shutdown OK / Extra Intel NIC, ACPI Bios configured to Version 1.0.

there can be cable issues too, you can shutdown unplug and replug the cable in question, maybe replace it as long as you don't touch the good disks there should be no additional risk

write down serial number from dsm storage manager of your failed disk and check on that when replacing the disk

on my two test systems (baremetal install) used for testing new extra.lzma's for 3515/17 with 6.2.2 i dont have problems like this both intel based and extremely old

interesting that a 1.04b loader that needs at least 4th gen haswell cpu's (2013) works with a 5 year older (2008) atom cpu (first x64 atom) i had install trouble like that on a (much newer) atom based system (booted but even with the right vid/pid had install error) i mitigated the install problem be installing on a different system and then transferring the usb and disk to the system with the atom cpu but i'm not sure that it would be a long term solution, if the error on installing comes from missing instructions of the cpu and failing in a few certain tasks then it will be a very unpredictable system, you would never know when anything fails because of this (extreme exaple might be hat repairing a raid error could fail and you don't know if its the disks or the cpu, there would always be a lingering doubt) also good to know is the "exotic" nic, Marvell Yukon 88E8071, the linux kernel driver is sky2, so no native support from DSM, it needs a extra.lzma (jun's default contains this driver) if it has to be dsm 6.2 i'd suggest (as alternative for 1.04b/918+) to try loader 1.03b/3615 and dsm 6.2.0 (v23739), if that works then it also will with my new (work in progress) extra.lzma containing drivers for 6.2.2, and it will be possible to update to the recent 6.2.2 later

when using copy & pate it can happen that you forgot to change 2nd entry to mac2= like this set mac1=001122334455 set mac1=001122334456 should be: set mac1=001122334455 set mac2=001122334456 there is also "netif_num=" but thats checked and corrected it you do the "macX=" correct in grub.cfg if common_add_option mac1; then set netif_num=1; fi if common_add_option mac2; then set netif_num=2; fi if common_add_option mac3; then set netif_num=3; fi if common_add_option mac4; then set netif_num=4; fi common_add_option netif_num

that driver is ancient the driver for this is in the kernel and can be loaded as module, forcedeth.ko have send you a test version

ok i send you a link ata_piix, mptspi, mptsas are not in that package lsi scsi, lsi sas will not work and you have to change to vmw_pvscsi or buslogic (i tested buslogic driver with virtulabox)

just a assumption, as a extra.lzma package for 6.2.2 918+ is already available, the 3615/17 is work in progress and not public yet never mind, i only had a quick glance on a picture and overlooked the two black sata connectors yes that's a 918+ capable cpu because the driver packages are not well tested yet and i haven't seen much feedback its more meant as test install to see if network and storage is working, if its just sata onbard and ahci then there is no problem at all with storage its pretty easy to test with a fresh usb and a old empty disk

no, my driver does not work but 3615 dsm image comes with driver mpt2sas and 3617 with mtp2sas + mpt3sas, so for now the build in drivers will be used at least thats what i'm plannig to do atm as i could not find out why the mpt2sas from 3.10.105 synology kernel with synology kernel config does not work, might be somethin with the kernel config or the now 2 year old kernel (beta) source, synology never published newer source even after developing/changing for 2 years, looks like thy don't care about GPL

i can provide button.ko and evdev.ko for 6.2.2 and all 3 images , my oracle virtualbox vm does shutdown on acpi shutdown with it here are the ones for 3615 you install the POWERBUTTON_6.2-0002.SPK and then copy these 2 files to /usr/lib/modules/update button.ko evdev.ko

i did only test it on my new hardware so i could not test this after receiving word that there is a problem with this on the 3615 extra.lzma i looked for a way to test this myself and found that i have the same virtual hardware as vmware in oracle virtual box (buslogic scsi, lsi scsi, lsi sas) also foud out that the mpt2sas also does not work on kernel 4.4.x (918+) there is only mpt3sas and it contains support for all mpt2 devices, i did test the 918+ with my lsi 9211 so it should work can't test this one, i plan to start from scratch with 918+ after doing 3615/17 so there will be a new version of the driver to test

if you still use jun's extra.lzma then thats kind to expect, after update you usb contains the 6.2.2 kernel and the extra.lzma for the old kernel 6.2.0 i'm looking for someone who can test my new drivers for the native vm-hardware vmxnet3, vmw_pvscsi on 6.2.2 atm mptspi, mptsas so lsi sas and lsi scsi from vmware will not work but hem native vm-hardware drivers should be able to replace them, that would be what you should test (added bonus that you can monitor serial to get console output)

yes, discovered that lsi 9211 controller do not worked, only mpt2sas driver from dsm itself (6.2.2) does work atm (had to organize a new test computer to get the lsi 9211 with 3615/17 running), still looking whats the cause of the crash, driver loads when controller has no disks connected but crashes when disks are connected also ata_piix, mptspi and mptsas driver do not work (mostly used for vmware and kvm i guess) , have removed them for now but network drivers are mostly latest and working

https://xpenology.com/forum/topic/13011-generate-an-original-synology-usb-key/ with the right usb flash drive and the right tool you can do what manufacturer in china do and enter your own vid/pid i did this last year but had not much use for it and gave it to someone here in the forum i was using DynaMassStorageProductionTool, maybe even wrote about it here in the forum (can't remember) that was the initiator article https://xpenology.com/forum/topic/9897-flash-transplant/?tab=comments#comment-85621 edit: still have one for testing Device Type: Mass Storage Device Protocal Version: USB 2.00 Current Speed: High Speed Max Current: 500mA USB Device ID: VID = F400 PID = F400 Device Vendor: Synology Device Name: Diskstation Device Revision: 0100 Manufacturer: Synology Product Model: Diskstation Product Revision: 0100 Controller Vendor: SMI Controller Part-Number: SM3259AA1 - ISP 161122-DG1 Flash ID code: 45DE9493 - SanDisk SDTNRGAMA-008G - 1CE/Single Channel [MLC-16K] -> Total Capacity = 8GB

no, if you updated to 6.2.2 the only thing that helps is a working extra.lzma (that can be copied to usb after the update and failed boot) or a propper downgrade just as a example to access your data you can also boot up open media vault from a different media and it will detect the raid with your data (its just a normal linux mdadm and lvm) - that's my plan B when dsm fails and and i'd need access to my data hopefully i will be out of test hardware soon an will stop finding new problems in the 3615/17 extra.lzma, still need to write a lot of text as its not so simple as just using a new extra.lzma with 3615/17 and loader 1.03b, the loader needs to updated too i have a good amount of ideas what a want to test and do for a new 918+ extra.lzma

you dont loose your data when a update goes wrong, you just loose access to your data, the update only changes the system partitions on the disks and does not touch you data raid, in such a semi brick it can be enough to add a new extra.lzma to the usb and on next boot it finishes, had that last week with someone accidentally updating to 6.2.2 with a 3615, test version of a new extra.lzma fixed it so your date are even more safe in a semi brick state of a dsm installtion, no trojan or ransomeware will be able to harm your data :-))) if my extra.lzma 918+ 6.2.2 loader 1.04b does not work then you cant update for now, you can try if a different nic solves your problem atm i'm doing 3615/3617 extra.lzma, after this i will revisit the 918+ and look more closely into it

if you want to stay with 3615/17 and willing to test (you want to try a clean install on your new hardware) i can provide with a driver set for dsm 6.2.2 containing the latest intel nic drivers so your nic should work, but there are some limitations about storage your new board has onyl 4 sata ports but you old system has 8 bays, so i guess i want to use a storage controller in the pci-e slot, what controller and also what you cpu are you using

how? if you remove it from the loader?

no, i never looked deeper into this, was just for documentation, i dont have this 7800 anymore, such sff was just to limited by hardware even for testing