IG-88

the kernel paramteres from 3615/17 wont help, it works because its a different kernel (3.10.105 bs 4.4.59) and even some kernel compiling parameteres might be different (not checked), look up for linux kernel shutdown and power management parameters or kernel boot parameters in a search engine if you cant update the bios to fix it (i dent think there will be much in the bios to configure for power management) then your only way seems to be 3615/17 or find kernel boot parameter that helps maybe like this? https://wiki.archlinux.org/index.php/Power_management#Kernel_parameters

yes, synology reverted the change made in 6.2.2 so old drivers work again yes, it should work this way

i kind of expected this, no clue but the only option seem to be to look into kernel parameters you can use within the grub.cfg whats the hardware, there was no info in dmesg, just J1900 , check if there are any updates for your systemboard you could also try 3615/17 if shutdown works (only needed if you are willing to loose hardware transcoding)

its part of juns laoder and you could chek if you want by opening the extra.lzma with 7zip in the "older" thread is also a list of hardware and kernel modules https://xpenology.com/forum/topic/12859-driver-extension-jun-103a2dsm62x-for-ds918/ ahci is part or the kernel synology delivers for each dsm version, so it seem likely that its not related to drivers/kernel modules loaded

i thought you had network problems, i dont see anything what could cause shutdown problems like a crashed driver did it work with dsm 6.2.0 and 6.2.2?

virtio dirver are in my 6.2.2 driver extension but dont get loaded automatically i will do now drivers for 6.2.3 with new released 24922 kernel source how much experiace you have with kvm? as i got not much feedback yout the drivers in 6.2.2 i was planing to do a special version for kvm where virtio is loaded willing to test? the get in contact be PM and i will send you a test version

what image type do you use? i did new drivers for 918+ 6.2.3 with the new 24922 kernel source doing 3615/17 is scheduled for the weekend i guess its best to make a special version for testing with kvm anything that should not be loaded with kvm? anything special needed beside virtio modules? can you see over virtual serial port whats happens? whats the emulated network chip in kvm or what choices you have?

for now you can use the driver that come with 1.03b loader i will recompile the set i had for 6.2.2 with newer intel and some 10G drivers later (maybe next weekend) this thread is about driver problems, if you have devices under /dev/dri then its that's a case closed here please move your problem to the software section, maybe this can help https://xpenology.com/forum/topic/24864-transcoding-without-a-valid-serial-number/ that look ok, driver detects hardware [Tue Apr 21 17:44:27 2020] e1000e: Intel(R) PRO/1000 Network Driver - 3.6.0-NAPI [Tue Apr 21 17:44:27 2020] e1000e: Copyright(c) 1999 - 2019 Intel Corporation. [Tue Apr 21 17:44:27 2020] e1000e 0000:04:00.0: Disabling ASPM L1 [Tue Apr 21 17:44:27 2020] e1000e 0000:04:00.0: can't disable ASPM; OS doesn't have ASPM control [Tue Apr 21 17:44:27 2020] e1000e 0000:04:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode [Tue Apr 21 17:44:27 2020] e1000e 0000:04:00.0 eth0: (PCI Express:2.5GT/s:Width x1) 10:90:28:ea:58:a1 [Tue Apr 21 17:44:27 2020] e1000e 0000:04:00.0 eth0: Intel(R) PRO/1000 Network Connection [Tue Apr 21 17:44:27 2020] e1000e 0000:04:00.0 eth0: MAC: 4, PHY: 8, PBA No: FFFFFF-0FF that looks fishy [Tue Apr 21 17:44:33 2020] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx [Tue Apr 21 17:44:33 2020] e1000e 0000:04:00.0 eth0: 10/100 speed: disabling TSO i doubt you have a 100Mbit switch, check cable and switch

r8168.ko https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-pci-express-software

https://xpenology.com/forum/topic/7973-tutorial-installmigrate-dsm-52-to-61x-juns-loader/

should both work with juns 1.03b extra.lzma when updating from 6.2.2 and replacing the 6.2.2 extra.lzma with the one from the original loader and having reboot/shutdown problems then just empty /usr/lib/module/update/ and reboot the "older" extra.lzma will not overwrite (6.2.2) drivers that where added later (by my extra.lzma) so in same cases they might be loaded an crash on boot

the drivers for 6.2.2 will not work for 6.2.3 but you can (again) use the default drivers from jun that comes with loader 1.03b i already did something for 6.2.3 918+ as it was not possible to get hardware transcoding with juns default drivers and 6.2.3 but for 3615/17 there is not such a big need for a new driver package as juns driver will work with 6.2.3, there might be some special cases of 10G network or newer intel onboard nic's that will not work with jun drivers (because i added some drivers and updates some), i will do the same for 3615/17 as i did for 819+ last weekend, maybe in a few days you did not write about your hardware (storage controller and nics) just try 6.2.3 with jun's default extra.lzma, in most cases it will do the job

thats a pretty common problem, the max disk count for 3615/17 is 12, when having 6 sata and 8 by sas it will be 14 and the last two will not appear with some tweaking of config files it can be extended but you will loose that change with bigger dsm updates like 6.2.2 -> 6.2.3 and you end up without redundancy disks or worth the way to go is the patch in the loader, jun the dsm default of 12 for 3515/17 but as 918+ gad only 4 he inclided a "extension" in his patch (atm 16) and it also made it easy to extend further by just changing some numbers in the patch (it not possible that way for 3615/17 as there are no parts in the patch about disk number) i still plan to do it , i already had to alter the patch slightly to delete the i915 drivers so i guess i might play a little with the patch next weekend (if nothing more interesting comes up)

HBA/Passthrough, dsm is build upon software raid and can't handle hw-raid

sand bridge, so old for 918+, it need 4th gen intel (haswell) as minimum do 3615/17 is your way both are supported with juns default drivers in 1.03b

6.1.2 dates back ~3 year so you kind of soften the blow to your self be thinking its already 5 years ago, no its just 3 years worst case is to loose config and having to reinstall the plugins, the update does not touch your data partition, even if your system does not boot anymore the data are still there and you could boot up a live linux or open media vault from a additional disk/usb to access your data but in most cases it works as update - as always its suggested to have a backup when having important stuff stored like family photos of the last 20 years, at least save th most important data to a usb device i assume you use 3615 now and with a new hardware and wanting to use hardware trancoding you would have to "migrate" to a different version, 918+ that will keep you settings and some plugins or you will have to reinstall the plugins the latest 6.2.3 took out some of the problems lately as 6.2.2 needed new drivers and 6.2.3 reverted that change so you can stilll use the drivers on jun's 1.03b/1.04b loader (only when using hardware transcoding is important it needs some tweaking for 6.2.3 but there is a new driver package takein care of it) the 6.2 loaders for 3615/17 do not run with uefi, it needs bios aka legacy or csm mode https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/ you might read the faq again as a refresh and maybe int the tutorail section the one about installing your dsm version (bare metal?, there are different ones for baremetal, esxi and kvm)

bare metal install? i dont have this on my system with a 9211-8i (IT), there are smart values, i can can run the smart quick test and get a healty the driver used atm is from kernel 4.4.59 i will try to compile a more recent and see it it works, if not i still can put back jun's driver from initial 1,04b loader, should also work

thats the same coffee lake gen as my G5400 did you try to clean/empty /usr/lib/modules/update and reboot? what does dmesg hast to say about drm and i195 dmesg | grep drm dmesg | grep i915

from what you wrote here https://xpenology.com/forum/topic/28131-dsm-623-25423/?do=findComment&comment=141904 i'd say its a driver conflict when using juns original drivers with his i915 drivers and combining this with with 6.2.3 then jun's driver loads first an fail loading with lots of unknown symbols, leaving synology's new i915 driver unused (that is nearly on the same level as jun's) this extra/extra2 is superposed to fix this problem, it deletes jun's driver and let dsm use its own new i915 driver https://xpenology.com/forum/topic/28321-driver-extension-jun-104b-for-dsm623-for-918/

whats the new disk? is it new or used? did you run a s.m.a.r.t. check? maybe a check with the check tool of the manufacturer? there should be more details about why it does not work especially when you broke your raid on purpose and tried to rebuild to the new disk, there would be no operation to the file system, it would be just a sector by sector copy job on the lower level (mdadm raid) - be careful with this new disk and look into it before trying to make it part of you raid

typical behavior for a crashed driver, check /var/log/dmesg

1.03b does not support uefi, check for csm(bios and make sure to use the "non uefi" usb boot drive (there might be shown 2 uefi and one csm/legacy) btw. what you do is called thread hijacking

yes its on my list what to check and to do next

why did it not work for you to create a working loader?

since 4-8 weeks that seems to be gone, 2 years windows could read/write both partitions and it changed to only the 2nd but now it ignores both partitions https://xpenology.com/forum/topic/28321-driver-extension-jun-104b-for-dsm623-for-918/ with latest updates of win10 there is no drive letter anymore, its possible to still do it with the tools already used for creating the usb drive, read the usb to a imgae file with "Win32DiskImager 1.0" (activate "read only activated partitions"), mount that image with osfmount (like in the tutorial section), overwrite old /extra/extra2.lzma and write the image back to usb with Win32DiskImager dsm boots from usb flash driver (kernel) and creates two partitions on EVERY disk in the system (1st dsm system, 2nd swap), the partitions are defined as raid1 (over all disks), when adding a disk to a dsm system its called initialization, the raid1 gets extended and only after this step the dsm system can use this disk the boot loader from usb needs at least one disk to install dsm to it (the *.pat file is istalled to disk)