• Content Count

  • Joined

  • Last visited

Everything posted by aol

  1. - Outcome of the installation/update: SUCCESSFUL - DSM version prior update: DSM 6.2.1-23824 - Update 3 - Loader version and model: JUN'S LOADER v1.04b - DS918+ - Using custom extra.lzma: NO - Installation type: BAREMETAL - GA170X-UD3 build-a-box w i7-6700K cpu and 4@WD RED 2/3 TB HDD
  2. aol

    DSM 6.2 Loader

    Caught my eye. I have had terrible experience lately with WD Red drives crashing. Phase 1 of my xpenology career: had 4 WD Red 1/2 TB drives in an old Intel SS4200E NAS enclosure, and never had an issue for probably 4 years. Not a single drive crash. Phase 2 of my xpenology career: had 4 WD Red 2/3 TB drives in a GA Z77X-based system, and dropped a drive a month. About every month DSM would complain that a drive had crashed. Third party tests on the drives never seemed to indicate anything was really wrong with the drives but from DSMs perspective they were just bad. I must h
  3. Definitely you want the disks set in AHCI mode. Don't use onboard raid, DSM does that for you. I think you want to use UEFI drivers in the BIOS, not legacy? Don't know about the DVD drive.
  4. I've had many drives go bad on xpenology boxes. In every case my experience was the same, shut down, replace the drive, boot back up, go to the disk management UI, and repair the affected array. The UI will ask which free drive to apply to the task, select your new drive, and it'll do it's thing. Your data is available in the meantime but the system will spend approx 12 hours rebuilding. This will cause it to miss it's next scheduled shutdown if it conflicts with the rebuild, FYI. I've never had an SHR, I've always used RAID 5, but I would expect your experience to be the same.
  5. - Outcome of the update: SUCESSFUL - DSM version prior update: DSM 6.2-23739 - Loader version and model: JUN'S LOADER v1.03a2 - DS918+ - Using custom extra.lzma: NO - Installation type: BAREMETAL - GA-Z170X-UD3 - Additional comments: Had just gone from a DS3615 on Jun's v1.02b loader running DSM 6.1.x to DS918+ on Jun's 1.03a2 loader, chose to install clean rather than migrate, all ok
  6. So where are we? It appears that you: - identified that your network infrastructure was not the issue because WOL worked on other boxes, and works on the NAS if you do a forced shutdown (remove power vs. menu -> shut down) - made sure that eth0_wol_options="g" in root/etc/synoinfo.conf - made sure that support_wol="yes" in same file - made sure WOL was ticked in DSM GUI - added an rc.d startup/shutdown script named root/usr/local/etc/rc.d/ with the contents from that post (this script appears to do two things: on startup, if the /var/packages/shutd
  7. Couple notes as I've gone through the ringer a few times on WOL. First, your root password is just your administrative user's password. If you have ssh enabled (default port 22), then you should be able to use Putty to ssh in with the same credentials as you use to log in administratively to the UI. There used to be a secret password to ssh in with that varied by month and so on, I don't know if that's still true, it was used by Synology support to get into your machine in emergencies. But if you can log in to the UI as administrator, that should work for ssh. IIRC you would `ssh
  8. Thank you @jun and @Polanskiman, and all the folks that keep the site up and the loaders coming.
  9. Alright I resolved the issue with a BIOS firmware update to the motherboard. A huge pain because I don't have Windows, so I had to use a USB pen drive to install Win10 to a spare drive, then use the @BIOS utility. Anyway. Thanks so much @flyride, @Tensol and @sbv3000. Your suggestions and patience were very helpful. Cheers.
  10. I am waiting a long time, several minutes, for SATA detection. I did try the idea of connecting the DS410 drive (one of them) to ANOTHER system and it is detected no problem. The other system is a GA 10-series board, so, newer. At this time I'm assuming there is a firmware issue on the ex58 board that's simply preventing it from seeing the drive, due to some modification to the MBR or something that Synology DSM does to drives it manages. I'm in the process of updating the ex58 firmware, on the off chance that the slightly newer beta bios that's out there may have fixed this issue (fixed may n
  11. Thanks sbv3k. I tried to post a question to Synology but their web form seems to have a javascript bug. I have no idea if my question got in or not, or if they'll respond, for the reason you mentioned. I considered jumpers, I'll double check that. I like the idea of setting the "good" (other) drive on sata channel 1 and seeing what happens if the DS410 drives are connected on 2+. I'll try that. It's possible the motherboard or controller is bad, for sure, hardware breaks eventually. I don't have another controller to try but that's a possibility. I do have another build
  12. Thanks for posting Tensol. I did hand-edit the BIOS (with no drives attached since it won't take me into BIOS settings edit with any DS410 drive connected) to set boot order to USB/disabled/disabled. With any DS410 drive attached it shows the splash screen (showing 'hit DEL to enter BIOS'), goes to SATA detection, hangs. In it's previous incarnation the Xpen box had 4 WD Red 3TB drives, and a USB stick running Jun's latest loader, and DSM was up-to-date. In it's current incarnation it has the 4 WD Red 2TB drives from the DS410, same USB stick, but of course DSM is old since th
  13. Hi flyride, thanks for posting. The issue isn't boot order, it isn't trying to boot to the sata drives, it's doing it's AHCI SATA detection scan, pre-BIOS. For example, if I remove the drives, and hit DEL to enter BIOS, it does the SATA detection scan (of course finding no drives) and takes me into the BIOS to edit settings. If I connect a single DS410 drive, it hangs on SATA detection, and never takes me into the BIOS. (connect any other drive and DEL takes me into BIOS edit as normal) It shows the splash screen, goes to SATA detection, and hangs there. Unless I'm missing something, changing
  14. I put the 4 disks of a Synology DS410 into an Xpenology box running the latest loader via USB stick. This Xpenology box had previously been running the latest Synology DSM using different disks that I migrated to a DS1515+. I expected the Xpenology box to boot up and either report the 4 disks from the DS410 migratable, or not, and deal with it. But it did a third thing I did not anticipate. As the Xpenology machine goes through loading the BIOS and doing the SATA disk scan, it just pauses during the SATA disk detection scan. It does not reach the Xpenology loader on the USB stick.
  15. - Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.4 15217 UPDATE 5 - Loader version and model: JUN'S LOADER v1.02b - DS3615xs - Installation type: baremetal GA-EX58-UD3R - Additional comments: Applied using auto-updater set to run prior to scheduled shutdown, box came up clean
  16. Great news. Curious what you think was the thing that got you going? As far as the next step, I would think if SynoOS says the array is recoverable then you'll be fine, but I would understand you wanting to get a second opinion. Keep in mind the SynoOS files, and the data in the RAID array, are separate. You can migrate the SynoOS (e.g. from a DS3615xs to a 3617xs model) and the data won't change, just the SynoOS will need to know what sort of RAID array it's working with (this is migrating, the same thing as if you physically moved the drives in one NAS box to another NAS box). I
  17. Sounds like you have video output from the box and if I understand you you get the normal BIOS output but you do not see the normal output from booting the stick, e.g., you should see the menu, and after a few seconds, the screen should post a few lines of text indicating it's begun booting and then nothing more will appear there. If you are not getting that output then won't work. Rebuilding the stick may have caused a problem if you were not careful to rebuild the grub.cfg with the correct vid, pid, SN and possibly mac. Building the stick on a mac is
  18. does sudo su work on Synology boxes?
  19. Should be fine. I assume you've verified that 6 disks fit inside the case, and you want to make sure things stay cool so maybe add an internal fan or two if you can. You are mixing and matching drive sizes and that won't cause a problem but optimally they'll all be the same size (3TB or 4TB) AFAIK (maybe there is a use case I didn't consider for doing this). You might also put 2x4GB RAM in there assuming the mobo has dual channel memory support which will make things run a smidge better AFAIK. There's some debate about 4GB RAM or 8GB RAM, I probably lean towards 8GB. Maybe someone has a good r
  20. I'm having trouble getting my Synology to connect to a VPN as a client. The client connection works from other devices so it's not an authentication thing. Bottom line I'm wondering about using ruTorrent or the deluge docker, and protecting yourself by downloading over a VPN. @viper359 are you using a VPN with ruTorrent? @bglf83 does the deluge docker run a VPN client you can configure? And how do you deal with "only download while the VPN is up; if the VPN isn't up, don't download anything until it's up"?
  21. It's not really an issue of why shouldn't the PC see the NAS but more why SHOULD it. There are a bunch of things that have to be set up right for the PC to see the NAS. - they must both have a file sharing protocol enabled (the PC is the client, the NAS is the server). this is typically SMB or CIFS. it's hard to believe it's disabled on the PC, but it is not on by default on the NAS. double check that file sharing protocols are enabled and all sub requirements such as workgroups match up. - they must be able to physically see each other on the network. you must be able to ping back
  22. A discrete video card can be used by Plex for transcoding but there are significant limitations and at this point I would say don't do this. Otherwise, as sbv3000 said, NASes run headless so a video card is only useful to edit BIOS settings and to perhaps make sure that initial boot succeeds so that works. Late gen intel CPUs have a built in GPU which should be sufficient (unless you want to optimize for Plex hardware transcoding). RAM is cheap, no reason to not follow sbv3000's advice there. You could go less but you want to take advantage of your CPU/mobo's arch
  23. XPE+DSM doesn't require RAID hardware. My motherboard has RAID hardware but DSM creates it's own software RAID array I believe. I set my disks in AHCI mode and DSM does the rest. Far as I know you can use any DSM RAID configuration including SHR, although I recall something about the different models (3615xs, 3617xs, 916) having one small issue regarding a RAID config that one or two support but not all three, but I forget the details on that. If you run Windows in a VM or Docker on top of XPE+DSM, you will probably lose FPS in games. I think folks that VM do it the other way, Win
  24. aol

    DSM 6.1.x Loader

    Any DSM will be ok with SynoCommunity packages... but the DS version you are running (3615xs, 3617xs, 916) has a hardcoded architecture regardless of the actual CPU you have inside your xpenology. An xpenology that has been told by nature of the bootloader that it's a 3615xs can only _install_ (through the Package Center GUI) SynoCommunity packages compiled for bromolow architectures or SynoCommunity packages that were compiled with "noarch" (no architecture specified). In reality of course any 64-bit CPU can run almost any 64-bit compiled program; it's a matter of the instruction sets that th
  25. Just found one important difference between ds3615xs and ds3617xs, the former is "bromolow" architecture, while the latter is "broadwell" architecture, which means that since SynoCommunity packages must be recompiled for architecture and many have not yet been recompiled for the broadwell architecture, many SynoCommunity packages are unavailable on DS3617xs. Now hopefully it is just a matter of time but meanwhile, this limits SynoCommunity package access on 3617xs.