Jump to content
XPEnology Community

Diverge

Member
  • Posts

    355
  • Joined

  • Last visited

Posts posted by Diverge

  1. Boot them up in a linux system and see if you can use your array. DSM is a PITA when it thinks it's crashed, and it really hasn't.

     

    edit: check from SSH if the volume is still accessible before trying the above... I've seen DSM say an array was crashed, but yet be working via a terminal session.

  2. Heat can be an issue .. I have overclocked i5 2500k which runs hot, and I was finding occasional network droputs etc. I finally figured out the heat was spreading around and when the motherboard NIC got hot enough it would cut out. fairly randomly. It was solved when I got better case ventilation. Not obvious at all.

    G1610T

     

    The board comes with the CPU under a passive heatsink and I do not overclock the CPU.. Synology report a temp of 40-42°C so I do not think it is heat... I do have the only fan at the motherboard room in a exhaust configuration, so might be worth it to change it to a intake fan...

     

    Thanks for your input :smile:

     

    The temp that DSM reports either isn't accurate, or isn't the CPU temp. It might be another motherboard sensor... mine always reads ~40C. I've got a fancy server motherboard, and I can read the real CPU temp via a web browser, and it doesn't correlate at all.

  3. Hey Trantor, thanks for creating the mirror! Now that 5.2 is out, seems like it's not possible to get the old 5.1 Updates. Do you have or know where we can get DSM 5.1-5022 Update 5?

     

    Thanks!

     

    You should be able to get them directly from DSM. Change the firmware update settings so it only includes minor update, not major ones.

     

    IfdVXZT.png

  4. You don't need a new tutorial, or to redo everything from scatch. Setup ESXI, setup the boot image, create a virtual disk for testing.... get everything working, remove test disk, insert array. It should be seamless if you do everything correctly.

     

    Moving your array from physical hardware to esxi, and vise versa is doesn't require any special steps. It all comes down to the boot image, and your hardware working correctly with esxi. If you're not familiar with esxi, set your array safetly to the side and play with physical test disks, or virtual disks. And read a lot.

  5. Do you have anything to compare it to using the same hardware? Previous versions, bare metal, ect.

     

    I have no experience with virtual disks for real storage (have only done tests with small vdmks). Most of us that use ESXI don't use virtual disks, we passthrough the controllers for our storage using direct I/O (VTd), or RDM.

  6. Seems odd a built in GPU will prevent ESXI from booting; it's pretty much headless.

     

    The aspeed controller isn't a regular GPU, it's for IPMI and remote desktop access. It's used in the Asrock board in my sig, and worked great for me (it's not used by ESXI, the Intel GPU in my CPU is).

  7. It's not gonna work until Vortex finds workarounds to the new protections they add every version. He also usually doesn't release stuff for beta releases, so they don't change it up. It's a cat and mouse game. Pro tip, read the russian forum section (I use google translate in chrome).

     

    by Vortex "20 Mar 2015 13:59

     

    In DSM 5.2:

    1) change the kernel version.

    2) complicate protection (it was covered with ~ 15 files, now ~ 20).

    Take the time to avail hrenobutom 5.1 will not.

    We are already working on the beta to the release was minimal delay.

    I personally have launched a beta of 5.2 and check on their two test machines.

     

    So just sit tight, and wait for the final releases, and read if you want to :razz:

  8. Open a ssh terminal, or via console, and do the following (replace sda with your drives letter):

     

    synodisk --read_temp /dev/sda
    

    synodisk is the util used by DSM to show drive temps.

     

    Then try:

    smartctl -a /dev/sda |grep Temperature

    this is just smartmon tool.

     

    synodisk needs real access to your HD to report temps, only works with baremetal and VTd (passthrough), doesn't work for RDM. Smartctl should report drive temps for all 3 (baremetal, VTd, RDM). If smartctl reports a real drive temp, and synodisk doesn't, then DSM doesn't like the controller you passed through for whatever reason. If smarctl doesn't report a real temp, then I guess it doesn't like your controller either :razz: or it's a driver issue.

     

     

    as far as the wierd drive still showing up, you edited your syslinux.cfg wrong. Plus, you have your bootloader as a SCSI drive, so adding rmmod=piix_ata won't help (I don't think). I use IDE for the bootloader. Here's an example:

     

    UI menu.c32
    PROMPT 0
    TIMEOUT 50
    DEFAULT xpenology
    MENU TITLE XPEnoboot 5.1-5022.1
    
    LABEL xpenology
          MENU LABEL XPEnology DSM 5.1-5022
          KERNEL /zImage
          APPEND root=/dev/md0 rmmod=ata_piix ihd_num=0 netif_num=4 syno_hw_version=DS3615xs sn=B3J4N01003 vid=0x0EA0 pid=0x2168 loglevel=0 vga=0x305
    
    LABEL debug
          MENU LABEL XPEnology DSM 5.1-5022 Debug
          KERNEL /zImage
          APPEND root=/dev/md0 rmmod=ata_piix ihd_num=0 netif_num=4 syno_hw_version=DS3615xs sn=B3J4N01003 vid=0x0EA0 pid=0x2168 loglevel=0 vga=0x305 debug=1 console=ttyS1,115200
    
    LABEL install
          MENU LABEL XPEnology DSM 5.1-5022 Install/Upgrade
          KERNEL /zImage
          APPEND root=/dev/md0 rmmod=ata_piix ihd_num=0 netif_num=4 syno_hw_version=DS3615xs sn=B3J4N01003 vid=0x0EA0 pid=0x2168 loglevel=0 vga=0x305 upgrade=5.1-5022
    

  9. Hibernation upsets can be caused by lots of stuff. Apps you installed in DSM, network shares, ect.

     

    As far as your one weird drive, it's probably the bootloader image for you XPEnology VM. For every ESXI VM of DSM I've had to add rmmod=piix_ata to the kernel line in syslinux.cfg of the bootloader, or it will show the bootloader drive as a disk within DSM. If this is the case, then it's also why it's temp is -1C (because it a virtual disk).

  10. I make a script file; ex; check_link.sh

    chmod 755 check_link.sh

     

    an then schedule a task to run every few hours in DSM.

     

    #!/bin/sh
    
    STATUS=$(ping -q -c 4 192.168.1.1 | grep -o '4 packets transmitted, 4 packets received' )
    
    if test "$STATUS" = "4 packets transmitted, 4 packets received"
    then
    echo "$STATUS"
    else
    /etc/rc.network restart
    fi
    

    Replace the IP address with your routers IP. You could just try running the code from DSM task, and bypass making the script file, but I haven't tested it that way.

     

    I forget what the message says when you lose the network connection and try to ping your router, but it would probably be better to do the 'if else' on that message.

  11. That happened because you basically had 2 sets of disks with synology on it (your original array), and the single disk you were testing on on your other system.. so it probably booted off the DSM on the single, saw all those disk from the array and wanted to migrate them... when you really wanted to boot off the array, and add the single disk.

     

    Next time just delete the partition tables of any disk you want to add into your array, since if it also has an DSM install it will get confused. Or put the disk in after DSM is booted (if you have hotswap), then it can't boot off it :wink:

×
×
  • Create New...