• Content count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About aol

  • Rank
    Junior Member

Recent Profile Visitors

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

  1. 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.
  2. aol

    Question on 1 hard drive failure

    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.
  3. aol

    DSM 6.2-23739 Update 2

    - 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
  4. aol

    Wake on Lan, how?

    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/shutdown_script/ file exists, it runs it, hopefully you don't have this file; on shutdown it executes the command `ifconfig eth0 down`, which is the command to turn off your eth0 network adapter, which is typically your first or only ethernet port) - made it executable via `sudo chmod 755 root/usr/local/etc/rc.d/` which makes it executable by owner, assuming you created it as root, it would be owned by root My understanding is that the linux OS DSM is built on is designed to automatically execute scripts in the root/usr/local/etc/rc.d directory on startup passing 'start', and on shutdown passing 'stop', in alphanumeric order, hence that name, which should cause it to be executed last of the rc.d scripts. And now you are at a weird place where the box doesn't come up clean some times and if it comes up your packages aren't running or aren't appearing correctly in the GUI? Do you have a file called /var/packages/shutdown_script/ If you do, it appears to be being called at startup if I understand the script. I don't know that you really want to do that. Searching for that file name, I found indicating to me that it's possible someone reused the script from this post, didn't understand what it did, but since they didn't have /var/packages/shutdown_script/ it didn't have any adverse effect. That post has references to the files mentioned in the script which confuse me about why they are being referenced at all. The whole post seems to be about hijacking a Syno package called shutdown_script which may be a pre-requisite for that other post. The right script as far as I can tell (UNTESTED BY ME) would be #! /bin/sh case $1 in start) # No-op ;; stop) ifconfig eth0 down exit 0 ;; *) echo "Usage: $0 [start|stop]" ;; esac This script assumes that /bin/sh is the right path to the shell interpreter, which it probably is. It doesn't exit with any code during startup, which is probably fine but may result in a log message. It exits successful (0) during shutdown after doing what you want, which is to turn off your eth0. The `*)` means, if run with any other than start or stop, do this, hence usage. So back to your problem, if you have a /var/packages/shutdown_script/ file it could be causing problems, and I don't understand the changing of eth0_wol_options="d" to "g" to know if that could cause problems. EDIT: as far as I can tell, the eth0_wol_options="g" in root/etc/synoinfo.conf attempts to tell the ethernet card to set Wake-On to "g" (rather than "d"). "d" is disabled, "g" is wake on magic packet. Its the same as doing it manually via the ethtool command, e.g., `ethtool -s eth0 wol g`. You could issue the command `ethtool eth0` to see the settings for the ethernet card. If everything is set properly you should see included in the output Supports Wake-on: pumbg Wake-on: g the Supports line should include g (the other values don't matter, it needs to support wake on magic packet which means it needs to include a g). And the actual Wake-on setting needs to stay g.
  5. aol

    Wake on Lan, how?

    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 <admin user id>:<admin password>@<nas IP>` or the equivalent Putty. I believe you can then `su root` with the same password, or just use sudo. Second, in order for magic packet to work for WOL, you need to not only have your hardware set up to acknowledge the magic packet, the box has to actually GET the magic packet. Any network devices between the system you're sending the packet from and the NAS _could_ be blocking the packet, which I believe is typically a UDP packet sent on port 7 or 9 (double check, it may even be 22). It's unlikely your sending system is blocking it, firewall rules don't usually prevent outbound packets. But your router could be blocking it. I had a FIOS router and I had to perform a manual step to add a static route to the ARP cache (that Putty command you're trying to think of) of the router so that the router didn't forget about the NAS when the NAS was turned off. So, consider that the packet may not be making it through any intermediary network device. Good luck. EDIT: Good blog post on this, although his situation involves both an ISP modem/router and an internal router and he can't put his internal router in bridge mode so he has to create a DMZ, which is hopefully more complicated than your setup.
  6. aol

    Progress of 6.2 loader

    Thank you @jun and @Polanskiman, and all the folks that keep the site up and the loaders coming.
  7. 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.
  8. 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 not be the right word, this is a pretty edge-case, um, case). That turns out to be a huge beat down because the native utilities recognize 1MB BIOSes but the beta BIOS is a 2MB BIOS, requiring Windows to run a Windows BIOS flasher, but I don't have Windows. I may have to actually install Windows 10 to a spare drive to upgrade the BIOS. Alternatively, re-initialize the drives. You asked DSM version, it was the latest supported on the system, 5.2 I think. By "unreadable" I mean, when you attach a drive in a GUI-unsupported format to Mac OS it puts up a dialog saying "this disk is unreadable, intialize ignore or eject". So as you say, they're formatted Linux partitions which Mac OS's GUI-native drive mounter doesn't recognize (you can issue terminal commands to mount it). I'm intrigued by the idea of setting up the Xpen on another drive and hot-mounting the DS410 drives. As this is a build-a-box what does that look like: get the GUI running on another drive with the DS410 drives installed but the SATA cables disconnected? Then plug in each SATA cable? Or have each drive connected to SATA bus but not have power, and plug in power? When I hot connect to my DS1515+ I just insert the drive which connects SATA and power at the same time. Not sure it would survive a reboot since SATA detection would presumably fail again, unless, possibly the upgrade to DSM 6 re-modifies the drives such that they BIOS SATA detection firmware routine can now see them (or I hot plug each time, ug). At any rate thanks again for all the responses. Great community and I'm glad to be a part of it.
  9. 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-a-box I could try a drive in. I'll try IDE mode just to see if that does anything different. Thanks for your suggestions. Not really worried about data loss - all the data has been backed up to a 1515+. At this point it's more stubborn curiosity about why this is happening than anything else. You live by certain rules and this situation is breaking my rules. Ha. "known good drives do not hang SATA detection on known good hardware". So something is wrong in that "rule".
  10. 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 the DS410 doesn't support DMS 6. I certainly considered if there would be something funky with the USB stick, but it had 4 drives and still has 4 drives, on the same SATA ports. And, it's not even getting to the boot part of the startup, right. It stops at the SATA detection scan way before even trying to pick something to boot from. I've considered putting the drives back in the DS410. I have no reason to think they wouldn't work. The 410 was a rock for 5 years +. I did put each drive in a USB drive caddy connected to a laptop, and each drive spins up and reports "unreadable" since they are ?linux?DSM proprietary? formatted. I put them back in the Xpen box and they seem (by touch) to be spinning up. Firmware incompatibility? These drives are probably 5-6 years old. Could the BIOS on the mobo simply be unable to read the firmware on the drives? Could the drives be stuck in some sort of low power mode? Technically I could ask Synology this. All I'm doing is taking drives that were in a DS410, and moving them to a build-a-box PC. I may submit a ticket to them on it.
  11. 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 boot order won't help get past SATA detection. Note that in trying to solve the issue I disconnected all drives, went into BIOS, loaded optimized defaults, set the boot order to USB first (and all others disabled), and rebooted. But again, with even a single drive connected, I can't get into the BIOS again to see (since some BIOSes alter boot order when new drives are introduced). For sure if I can get past this issue I'll set the boot order to be USB/disabled/disabled.
  12. 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. I tried: - disconnecting all drives: boots to Xpenology boot loader - reconnecting each drive one at a time: SATA scan hangs - connecting an unrelated spare drive: boots to Xpenology boot loader So I've ruled out stuff like misconnected cables. It's almost like the drives which used to be in the DS410 are confusing the SATA detection routine. For what it's worth this is a Gigabyte 5 series mobo, a GA-EX58-UD3R with a core i7-930 CPU. Again, this same hardware has for months been running Xpenology/DSM with different disks. Anyone have any thoughts on why WD 2TB Red drives that used to be in a working DS410 would fail to be detected cleanly by the BIOS of a GA-EX58-UD3R board? I guess my next step is to use USB drive mounting hardware to mount and reformat each drive from my laptop. I just hate to do that, wouldn't mind migrating the data.
  13. aol

    DSM 6.1.5-15254

    - 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
  14. aol

    How do I recover from a failed update?

    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 would think recoverable is between healthy and migratable, that is, less work will need to be done to get your data back, but I could certainly be wrong. Anyway my vote is to trust SynoOS, if it says your data is recoverable and it will let you click a button to recover it, then that's probably the right thing to do.
  15. aol

    How do I recover from a failed update?

    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 simpler than on a Windows machine, simply sudo dd if=/path/to/102b.img of=/dev/disk3 bs=1m in terminal. determine the correct /dev/disk3 path using diskutil list. Your USB stick will be /dev/diskN. Then you need to mount the EFI folder of the stick, edit grub.cfg, set the vid/pid/SN/mac, unmount and done. So that should be your focus, getting the system to display the right text on boot.