• Content Count

  • Joined

  • Last visited

  • Days Won


IG-88 last won the day on April 9

IG-88 had the most liked content!

Community Reputation

758 Excellent

About IG-88

  • Rank
    Guru Master

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. thats probably a driver problem, check if the new 0.13.3 extra/extra2 is an the loader, if you use jun's default its preventing the use of the new i915 driver that comes with 6.2.3 https://xpenology.com/forum/topic/28321-driver-extension-jun-103b104b-for-dsm623-for-918-3615xs-3617xs/ you can check /var/log/dmesg for messages about i915 and you should at least see the pci device id 8086:191D in dmesg
  2. ant that is working without any added drivers? the spec for that board is realtek 8105 (100Mbit nic)and there is no driver for that in jun's base set (no r8101.ko) but maybe you used a pci nic already because with just 10 megabyte per second its not going to be very useful as a NAS what dsm version did you try to install? it would need to use 6.2.0 (23739) or 6.2.3 (25426) to match the drivers in the loader yes, serial port (you board at least has one), null-modem cable and serial console like putty maybe your monitor is to slow when switching reso
  3. 6.2.2 is a terrible choice as its drivers are incompatible to the initial 6.2(.0) and the last working 6.2.3 i guess i did miss the part where i wrote about the 2 nic limit in 1.04b 918+ https://xpenology.com/forum/topic/21663-driver-extension-jun-103b104b-for-dsm622-for-3615xs-3617xs-918/ "... !!! still network limit in 1.04b loader for 918+ !!! atm 918+ has a limit of 2 nic's (as the original hardware) If there are more than 2 nic's present and you can't find your system in network then you will have to try after boot witch nic is "active" (not necessarily the onbo
  4. 04:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS-3 3008 [Fury] (rev 02) Subsystem: Dell PERC H330 Adapter Kernel driver in use: megaraid_sas Kernel modules: megaraid_sas 1000:005F MegaRAID SAS-3 3008 [Fury] that driver is for raid mode so it still has the IR firmware and you use a hardware raid raid mode is only supported by additional drivers and not that good with that not to old cpu you would be able to use 1.04b 918+ and the megaraid driver from the newer 4.4 kernel would support the 1000:005F but the
  5. "Sudo before 1.9.5p2 has a Heap-based Buffer Overflow, allowing privilege escalation to root via "sudoedit -s" and a command-line argument that ends with a single backslash character." take sudo binarys from 6.2.4 and copy them to 6.2.3 or compile new version from source (https://www.sudo.ws/stable.html) in the build enviroment used for packages and driver if you figure out what cve it is you could help yourself too (cisco talos has a lists, you would need to compare with already mentioned and fixed stuff, or just wait for synology to be more precise or
  6. cpu is haswell or better so even 918+ would be possible H300? - not found H310/H330 maybe? or H7xx (the H7xx models are mentioned in dell's specs for the T430) the important thing would be the lsi sas chip its based on not sure what list you checked but its usually about the original lsi models or the chips used, there is a good amount of oem types from ever server vendor so its really combersome to have a complete list if you have 5.2 running you can list the devices with driver and pci id "lspci -k" in general its suggested an
  7. if you have omv up and running you can also do the same as with a recovery linux, you can login by ssh in background, mount the dsm system's raid1 volume and check if it was a 6.2.4 update - only difference is you have more time as you already have a nas running to access your files (you still need to mount the file system and crate a smb/cifs share but thats pretty self explanatory in omv) https://xpenology.com/forum/topic/42765-how-to-undo-a-unfinished-update-623-to-624-no-boot-after-1st-step-of-update/ you would just look for the update files and check the two "VERSION" fil
  8. that one is a compile parameter of the kernel and the kernel cant be changed as we don't have all source (it was easier to circumvent the protections and make it look like its running on a legit hardware then reverse engineering all the missing parts) even if you ask more often, the answer is still the same https://xpenology.com/forum/topic/42407-only-16-threads-on-ds3617xs-with-e5-2678v3/?do=findComment&comment=198992
  9. https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/
  10. the intention here is to have a running omv installation on a media (can be a separate disk, or a usb flash drive), add the dsm disks and boot that omv up as tested over 2 years ago it still works that way dsm usb boot drive and the dsm disks disconnected installed the recent omv5 (usul, kernel 5.x) to a usb (had one usb containing the iso transferred with rufus and a 2nd as destination), using a ssd or even hdd might be much faster but the usb is easier to handle and cheaper (updating took ages, i guess the iops of the usb is just to low, so if it has to be fast to setup
  11. das ist 6.2.4 und da wird (in englisch) doch recht auffälig gewarnt wenn man sich im forum anmeldet 6.2.3 + update3 ist der stand den du nutzen kannst (aka v25426) https://archive.synology.com/download/Os/DSM/6.2.3-25426 https://archive.synology.com/download/Os/DSM/6.2.3-25426-3
  12. no does not work at all as there are no drivers for using the gpu, there not even amd support in synology's kernel
  13. any activity i the russian section of the forum in this regard? more people used this way successful and more interesting people having problems with it? i could integrate it here as possible way (maybe with a warning), but would prefer to have seen more feedback if people already tried it
  14. does dsm make updates before emptying the cache? afair from last year when i had a write cache on a test system it demanded to empty the cache before updating (read cache should be no problem as it contain only redundant information)
  15. what about applying write-mostly after array creation, any experience with that one? (it would still be normal raid1 with all members active, so no degradation of the raid1 to a single drive)