Jump to content
XPEnology Community

Leaderboard

Popular Content

Showing content with the highest reputation on 06/15/2017 in all areas

  1. kernel modules/drivers are specifically compiled for a kernel (-versions) and even distributions it's not like windows where you can download a driver somewhere and just put it in so don't take any *.ko file, stick it in and expect it to work if you haven't build the *.ko yourself or don't know exactly where it came from, expect it to fail I'm no expert but as there is no how-to here in the forum - lets start one hopefully other will correct and help refine or take over and rewrite it some steps are made in windows (osfmount) but will also possible in the chroot environment on linux basic knowledge about using a linux console and command-line tools (or midnight commander) is needed, if you never used this you should not start with this how-to, choose something easier or invite someone who is able to help (do a workshop) doing all this from scratch will take at least 1-2 hours, in most cases (re-read, google, try, google, try again, ...) much longer, maybe plan a weekend of text-adventure fun edit: i think it also will do for 6.0.2 and loader 1.01 (not tested), kernel sources are available: https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/8451branch/bromolow-source/linux-3.10.x.txz/download, extra.lzma is a little differently placed (boot.img\image\DS3615xs\) but the steps will be the same 1. building the kernel module (driver) 1.1 what driver/module i need you will have to find out (google) what the name of the driver/module is that your hardware needs or you will have to know where to find the rigt option in the menu-system of the kernel when configuring it example: nForce 630 chipset with RTL8211E, you might expect it to be a realtek driver like rtl*.ko but it's not its "forcedeth.ko" because the RTL8211 is not a fully working PCIe Network Chip in some cases you might be forced to find out by booting a linux distribution and look in /var/log/, use lspci or other tools it also helps if the hardware provider has already compiled packages for specific distributions like redhat, you can look inside these packages for *.ko files you also can look in the .config file of the kernel (more below) with a text editor to find a section where the module is mentioned, this will also give you a hint where to find it in the menu-system when configuring the kernel 1.2 you need the kernel source in the case of synology that seemed sometimes difficult but at the moment there is kernel source for dsm 6.1 https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/ 15047 is the synology build version and tells you about what dsm version it is (15057 = dsm 6.1) and what kernel was used to build the modules, it !!!might!!! change in a later version so always check for what version your bootloader from usb stick is made for (jun 1.02 is for 15047) edit: dsm 6.1.1 has a new build number 15101 but seems to use the same kernel 3.10.102 as 6.1 so it should work with 6.1.1 too as i write this for ds3615xs it's bromolow as a platform, for ds3617xs it's broadwell and ds916+ is braswell (you usually see that name on the update files for a synology system like "synology_broadwell_3617xs.pat") so for ds3615xs we use this: https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/15047branch/bromolow-source/linux-3.10.x.txz/download edit: it looks like as for building the modules there is no difference for kernels modules build for 3615 and 3617 even if https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/15047branch/ has extra kernel sources for bromolow and broadwell, there are all intel x86_64, same might go for the 916+ (not testet yet), at least a evdev.ko build from 3615 kernel source did load without problems in a vm with the 3617 image 1.3 setting up a DSM 6.1 ds3615xs test environment with virtualbox (its free) or whatever works with juns loader look in the forum to find something that works, basics for virtualbox are - mac of the nic (intel pro 1000 desktop) in vm and grub.conf need to be the same - boot controller for jun's image (vmdk with reference to img file) is ide, controller for dsm disks is scsi lsi (!!!) - choose esx server option in grub menu 1.4 installing chroot put in http://packages.synocommunity.com for custom packages and change the setting that beside synology packages trusted ones are also to install install debian-chroot plugin (https://synocommunity.com/package/debian-chroot) from community section (some info's about it: https://github.com/SynoCommunity/spksrc/wiki/Debian-Chroot#configure-services) you might also install midnight commander if you are on it, makes things easier if you're not a command-line junky and more used to a graphical environment that give you clues activate ssh in dsm connect with ssh/putty to you dsm, login with user admin (and if you want to be root use "sudo -i") start the chroot with: /var/packages/debian-chroot/scripts/start-stop-status chroot after that you are inside the chroot, check with ls and you won't see "/volume1" or other sysnology specific directory's from the dsm environment, you can leave the chroot environment with "exit" later if you want now we have to update and install tools: apt-get update apt-get upgrade apt-get install locales dpkg-reconfigure locales dpkg-reconfigure tzdata apt-get install mc make gcc build-essential kernel-wedge libncurses5 libncurses5-dev libelf-dev binutils-dev kexec-tools makedumpfile fakeroot linux-kernel-devel lzma bc after that we create a directory (lets say "test") 1.5 copying kernel files and create kernel modules copy the downloaded kernel (linux-3.10.x.txz) to a share on the dsm, open a 2nd putty and copy the linux-3.10.x.txz (/volume1/...) to /volume1/@appstore/debian-chroot/var/chroottarget/test/ (that's where the "test" directory of the chroot environment is located in your real system) change back to your first putty where you are in chroot (the same way can be used to get the created files back to your shared folder on your volume1 which can be accessed from windows) change into "test", extract the linux-3.10.x.txz to a directory named "linux-3.10.x" and change into it the following copy's the kernel config file from synology to the right place for use/build cp synoconfigs/bromolow .config we make a fallback copy make ARCH="x86_64" oldconfig we start the ascii art menu and search for the missing driver to activate cursor/return are your friend in navigating, space selects, we activate the driver to an "M" so its build as module (*.ko file we need) there will be tons of descriptions how to do it, just google if needed make ARCH="x86_64" menuconfig on exit we save the configuration and with the following we make/create the modules (will take a while) make ARCH="x86_64" modules now you have to find your *.ko file (use some nice ls options, to be expanded later) usually you will have to look in /test/linux-3.10.x/drivers/scsi or block copy that file to /test for easy access when we put it in the boot image 2. modify the "synoboot.img" use osfmount (windows) to extract the "extra.lzma" (see dsm 5.2 to 6.0 guide, used there to edit grub.cfg in synoboot.img) in "extra.lzma" are the additional *.ko files and a config file where the files to be loaded on boot are named -> see forum thread "dsm 5.2 to 6.0" with howto to modify jun's loader for usb vid/pid and mac, its basically the same you just open the other partition (30MB) and extract the "extra.lzma" copy the "extra.lzma" to the share of the dsm so we have local access in a putty session on dsm in putty session #2 ("normal" session without chroot) we copy the "extra.lzma" to the "test" directory in the chroot environment go to putty session#1 (in chroot) decompress "extra.lzma" to "extra" ("extra.lzma" is a compressed cpio file) with: lzma -d extra.lzma with ls we can check that "extra.lzma" is now just ""extra" (a cpio file without the extension cpio) create a new directory, copy the "extra" there, change into it and extract it with: cpio -idv < extra delete the remaining file "extra" inside this directory we copy the *.ko file into usr/lib/modules/ and in /etc we edit the file rc.modules (easy with midnight commander, go to file, press F4, internal editor) network drivers seems to be added under EXTRA_MODULES, storage drivers under DISK_MODULES, just go to the end of the line and fill in the name of the *.ko file without the ".ko", what you add is basically a blank and the name rc.modules looks like this: EXTRA_MODULES="mii mdio libphy atl1 atl1e atl1c alx uio ipg jme skge sky2 ptp_pch pch_gbe qla3xxx qlcnic qlge netxen_nic sfc e1000 pcnet32 vmxnet3 bnx2 libcrc32c bnx2x cnic e1000e igb ixgbe r8101 r8168 r8169 tg3 usbnet ax88179_178a button evdev ohci-hcd" DISK_MODULES="BusLogic vmw_pvscsi megaraid_mm megaraid_mbox megaraid scsi_transport_spi mptbase mptscsih mptspi mptsas mptctl ata_piix megaraid_sas mpt2sas mpt3sas" EXTRA_FIRMWARES="bnx2/bnx2-rv2p-09ax-6.0.17.fw bnx2/bnx2-rv2p-09-6.0.17.fw bnx2/bnx2-rv2p-06-6.0.15.fw tigon/tg3_tso5.bin tigon/tg3_tso.bin tigon/tg3.bin" if your controller or nic needs a firmware, you add the file under usr/lib/modules/firmware/ and add the appropriate line in EXTRA_FIRMWARES, if a extra directory inside "firmware" is used it has to be added to the name, see the bnx2 firmware files after everything is in place we recreate the cpio file, re-compress it as lzma and write it in the directory above as "extra.lzma" the command is used inside the directory where we extracted the file "extra" (command line taken from https://github.com/kref/scripts, its what jun uses to create it): (find . -name modprobe && find . \! -name modprobe) | cpio --owner root:root -oH newc | lzma -8 > ../extra.lzma in putty session #2 (without the chroot) we copy "extra.lzma" from the chroot position in filesystem to the location where we can access it from windows if you still have osfmount open to the "synoboot.img" replace the "extra.lzma" with the new one, dismount and close osfmount - our new "synoboot.img" is ready to test it ps: i was asked to make a video - thats much harder to change and i'm to old for this
    1 point
  2. Все получилось! Огромнейшее спасибо!
    1 point
  3. Давеча тут были рекомендации, повторю: превращение "кирпича" в работающий сервер решается в два этапа: 1. Настройка Microserver-а и подключение по SSH к iLo (переводить - увольте): "Reboot your gen8 and enter bios (F9). If I remeber well you must disable BIOS serial console, because if you don’t do it, when you launch VSP you will see gen8’s bios console… Select «BIOS serial console & EMS» >> «BIOS Serial console port» and disable it. Now go to «System Options» >> «Serial Port Options» >> «Virtual Serial Port» >> I have enabled «COM1;IRQ4;3F8h-3FFh» Now exit Bios utility and reboot. Be sure to enable SSH access in iLO (Adrministration >> Access Setting) Now open an SSH session to ilo ip unknown:~ ema$ ssh 10.0.0.100 ema@10.0.0.100's password: User:ema logged-in to ILOXXXXXXXXXX.local(10.0.0.100 / XXXX::XXXX:XXXX:XXXX:XXXX) iLO Advanced 2.50 at Sep 23 2016 Server Name: gen8.lan Server Power: On </>hpiLO-> …and at ilo prompt you must launch VSP. Now restart DSM and you can see serial output and prompt login… </>hpiLO-> VSP Virtual Serial Port Active: COM1 Starting virtual serial port. Press 'ESC (' to return to the CLI Session. gen8 login:" 2. Залогиниться в свой DSM и скопировать модули: root@dsm:~# cp /lib/modules/update/libphy.ko /lib/modules/ root@dsm:~# cp /lib/modules/update/tg3.ko /lib/modules/ root@dsm:~# reboot Ну, а далее, до следующих обновлений системы можно заняться скриптом (у меня он S98DSM-ETH-UP.sh): root@dsm:~# vi /usr/local/etc/rc.d/S98DSM-ETH-UP.sh тело скрипта: #!/bin/sh if ! [ -f /lib/modules/libphy.ko ] || ! [ -f /lib/modules/tg3.ko ] then cp -f /lib/modules/update/libphy.ko /lib/modules/libphy.ko chmod 644 /lib/modules/libphy.ko #запишем успешное копирование в файл-лог echo "$(date) libphy.ko copied successfully!" >> /volume1/homes/user/scripts/S98DSM-ETH-UP.log cp -f /lib/modules/update/tg3.ko /lib/modules/tg3.ko chmod 644 /lib/modules/tg3.ko #запишем успешное копирование в файл-лог echo "$(date) tg3.ko copied successfully!" >> /volume1/homes/user/scripts/S98DSM-ETH-UP.log sleep 300 reboot fi #запишем успешное выполнение скрипта в файл-лог echo "$(date) The script worked!" >> /volume1/homes/user/scripts/S98DSM-ETH-UP.log дадим скрипту прав на запуск: root@dsm:~# chmod +x /usr/local/etc/rc.d/S98DSM-ETH-UP.sh Ну, собственно и все!)
    1 point
  4. Same here, I ran the upgrade twice on a VM running on ESX 6.5 with DSM 6.1.1 U4 and both failed. Will investigate further when I have more time but be careful and don't just hit that update button!
    1 point
  5. Винты очень чувствительны к питанию, попробуйте поменять БП, должно помочь, если конечно он еще не совсем их добил.
    1 point
  6. Сделал видео-инструкцию по установке DSM 6.1.1 Update 4 на HP MicroServer Gen8 с нуля для новичков: Инструкция Всё подробно, по шагам. Админы закрепите в шапке.
    1 point
  7. Jun's loader contains 4 files. I did the following steps: 1) modified ds3615.vmx ( virtualHW.version = "11" ) 2) uploaded all 4 files to a new directory on the ESXi server 3) added ds3615.vmx to the list of Virtual Machines. 4) in the VM settings: deleted the network adapter and added a new one 5) in the VM settings: created and added 8GB virtual drive 6) started the vm an connected to it in the browser 7) installed DSM 6.1.1 on DS3615xs 8) upgraded within DSM to 6.1.1-15101 Update 4 9) configured DS3615xs to my likes and shut it down 10) in the VM settings: created and added 4TB virtual drive 11) started VM 12) on DSM: added new Raid Group (basic, btrfs) 13) on DSM: added a new volume 14) installed Hyper Backup and Hyper Backup Vault from the Package Center 15) tested my backup concept after a few hours all data were restored ...
    1 point
  8. The æ disadvantages you list are the exact reason why a hba/raid controller is a good idea.
    1 point
  9. it is safe thank you all
    1 point
×
×
  • Create New...