Jump to content
XPEnology Community

stanza

Member
  • Posts

    288
  • Joined

  • Last visited

Everything posted by stanza

  1. Just as a note for others This way of changing mac address doesn't work for this version of Xpenology (hex edit fails) The way I found for this version was to comment out the "vendor" and chksum" sections and change default to 2 eg ================ #serial --unit=0 --speed=115200 #terminal serial default 2 timeout 3 hiddenmenu fallback 0 title SYNOLOGY_1 root (hd0,0) kernel /zImage root=/dev/md0 ihd_num=5 netif_num=4 syno_hw_version=DS3612xs initrd /rd.gz title SYNOLOGY_2 root (hd0,1) # cksum /grub_cksum.syno # vender /vender show # hw_model kernel /zImage root=/dev/md0 ihd_num=5 netif_num=4 syno_hw_version=DS3612xs mac1=0024811591E2 sn=B3J4N00311 initrd /rd.gz ============= Hope it helps others .
  2. How do we change the mac address or serial number in this release? I have 1 machine up and running HP EX490 Shows up as MAC1 = 00223208d63c Serial B3J4N00310 Trying to get a second box up and running using the edit grub.conf trick to try and set a serial number and mac address has no effect at boot this version shows Booting 'SYNOLOGY_2' root (hd0,1) Filesystem type is ext2fs, partition type 0x83 vendor /vendor show MAC1: 00223208d63c MAC2: 00223208d63d MAC3: 00223208d63e MAC4: 00223208d63f Serial: B3J4N00310 Custom Serial: Empty or Invalid checksum kernel /xImage root=/dev/md0 ihd_num-5 netif_num=4 syno_hw_version=DS3612xs mac1=00113205V7U8 sn=B7J4N00000 [Linux-bzImage, setup=0x3400, size=0x2e63e0] initrd /rd.gz Which seems quite different to other versions any ideas?
  3. Yes the expand feature works fine THO I had several troubles with a couple of installs (different computers.... Due to bad HDD's I would be suspicious of a bad HDD you might have You can try and fix it yourself if you like... I used this guide to fix mine http://www.mauchle.name/blog/?p=235 Tho the expansion worked... it didn't take long for some error messages to appear that a drive was failing and NOT passing smart tests (2TB WD Grean Drive) Once I swapped that drive out for another... everthing went fine But like I said, it sounds like you have a bad HDD to me if it's failing
  4. Another Box Up and running fine HP DC7900 Convertible Mini Tower Onboard Intel E6550 4 Gig Ram 4 SATA ports Plus E-SATA detected fine Intel E1000 5 x 1TB Drives Install detected and installed itself to the 4 x SATA Drives Leaving the E-Sata Drive out of the SHR pool Will try and add that into the SHR once the Volume Check is complete .
  5. I read that one also, and would like to know others thoughts .
  6. I second this, Getting LSI SAS controllers up and going would be great. Then I can build me a 50 drive Xpenology NAS .
  7. The new RS10613+ from Synology has SAS controller ( also can get a SAS expander chassis to connect to it) I suspect if you can find the kernel sources for that model, you would be able to see which SAS controller drivers/modules they use and start from there I am also in the same boat and would like to make a MEGA Synology DSM based NAS. With a bunch of SAS controllers and hardware I have The RS10613+ even has 10Gbe add in controller card available for it. .
  8. Also might be worth checking the usb module is correct post #2 here http://xpenology.com/forum/viewtopic.php?f=2&t=915
  9. Seems to be working fine on a HP Mediasmart EX490 4gb Memory 4 x 2TB Drives .
  10. BTW tried to update the software.... but that failed like yourself. THO I noticed, that when first setting up the system using the synology assistant etc. the first time I performed it, it actuall downloaded and installed the latest version (I think) as I forgot to check the 3rd box and transfer it over from the files downloaded. So maybe thats one way of getting the latest? I will try that out later also, .
  11. ok had a couple of niggling problems but overcame them My Proxmox VE 2.3 install didn't seem to find the drives I gave the virtual as IDE, had to use SATA so in my case I added 2 x fake SATA drives (passed thru) I also thought it best to use disks by ID number and not sdb sdc etc... as they can and do change around sometimes.... so instead of using something like qm set 100 -ide1 /dev/sdb I used qm set 100 -sata0 /dev/disk/by-id/ata-HUA721010KLA330-43W7625_42C0400IBM_GTA60PBHTURHE I also tried out removing a drive and replacing it with a larger one (twice) to simulate a HDD crash/failure etc Started with 2 x 50gig SSD's Shutdown Synology VM Shutdown Proxmox replace 1 x SSD with a 1TB SATA drive rebooted Proxmox (this was tricky bit) had to look at Proxmox to figure out which HDD ID number was which, and then redid the qm set 100 -sata ............. to replace the Passed thru virtual HDD started back up the VM and it detected right away that there was a problem, in which I let it autorepair itself. (eg rebuild the mirror pair of 1x50gigSSD + 1x 1TB SATA) once it had completed, I did the same for the second drive shurdown VM Shutdown Proxmox swap SSD for 1TB SATA drive reboot did the qm set 100 -sata ......trick for the second 1TB drive restarted the VM and did the autorecover in which it once again rebuilt the array.... but ALSO expanded the array from roughly 44.5gb space to 931gb next I will try adding a 3rd 1TB drive to see what happens. .
  12. I am having a go at this at the moment. found some different ways to do a couple of steps For those without Virtuabox.... you can upload and convirt the vdi file from within Proxmox itself (save you downloading and installing Virtuabox just to convirt the image) Rename your synoboot.vdi file to have an ISO ending/extension eg sysnoboot.iso or synoboot.vdi.iso then within the proxmox web interface Upload this image as an ISO file to your Proxmox CDROM Store Click on your Proxmox host on the left hand pane Select the Local Data Store Click on upload Browse to your newly renaimed file Then SSH into proxmox host (or direct console if you have a keyboard / monitor attached) log in change to the ISO store directory cd /var/lib/vz/template/iso from here rename the file back to a vdi extension eg mv synoboot.vdi.iso synoboot.vdi Then we can use the qemu-img tool to convert the vdi file into a raw file eg qemu-img convert -O raw synoboot.vdi synoboot.raw and now rename that to the virtual machines name and move it into the correct directory and away you go. Hope it helps I am off to finish my setup (hopefully) .
×
×
  • Create New...