NeoID

Members
  • Content count

    185
  • Joined

  • Last visited

Community Reputation

5 Neutral

About NeoID

  • Rank
    Advanced Member
  1. DSM 6.1.5-15254

    - Outcome of the update: UNSUCCESSFUL - DSM version prior update: DSM 6.1.4 15217 Update 5 - Loader version and model: Jun's Loader v1.02b - DS3615xs - Installation type: ESXi 6.5 - Additional comments: Took a long time for the NAS to get it's original IP back. Had to use Synology Assistant. DOCKER SEEMS BROKEN! JUST WSOD!
  2. Synology Drive

    Would appreciate it if anyone else could try the app on Android.
  3. Synology Drive

    Anyone managed to get the Android app to work when using a Letsencrypt certificate? All apps work fine except Drive.
  4. Repairing a crashed BTRFS volume

    I've been looking at dmesg and /proc/mdstat for the last couple of days. Today the rebuild did a second pass and now everything seems to be clean and working again! I guess my conclusion is.. make sure all cables are properly inserted and cool your HBA card.
  5. Repairing a crashed BTRFS volume

    I'm afraid you'r right about the rebuild taking only a single pass and something is wrong with my array... -_- Do you use a hypervisor or run baremetal? I have had these issues even on EXT4, so I doubts it's related to the file system.
  6. Repairing a crashed BTRFS volume

    I also use 3TB WD Red drives (10x ) in RAID 6. First of all I powered down my system and tested the drive on another machine. Since it was fine I didn't think that the crash was caused by it. To make sure, I've replaced the drive with another WD Red 3TB I had lying around. Also this drive "crashed" according to DSM after rebuilding for a day. I started noticing a pattern here. Every time I've started from scratch it has been the same disk bay that DSM was complaining about. The reason I didn't notice this sooner is that DSM sometimes changes the order of the disk (I don't remember if it happens on each boot or each install of DSM). However.. it was always the same bay causing issues. I finally removed the drive from the bay and connected it directly by SATA. For now everything seems to rebuild just fine (even though I don't see why it's currently rebuilding for the second time without any errors in between). I have also noticed that the HBA became very hot when rebuilding (and under heavy load), so that may also have something to do with this issue... So I've 3d printed a bracket and mounted a 120mm fan on top of the card. For now everything works smooth, so I just hope it doesn't restart the rebuild a third time or I think there's something wrong with DSM not being able to save the state of the volume somehow...
  7. A bad cable crashed my BTRFS volume the other day. I found the issue after a while and started the rebuild process after replacing the bad SATA cable. The rebuild took a few days to complete, but once it did, it restarted from 0% again. I have not received any other emails or notifications from DSM that anything is abnormal. Is it normal that the rebuild process need multiple passes to complete? I'm on ESXi and the boot drive is mounted as read-only once everything was up and running smoothly. First I thought the the rebuild restarted because the state couldn't be written back to the boot drive (I don't think it does), but it has been read-only since before the crash.. so I don't think it's related to this problem. Anyone who has been in this situation before and knows how many passes the rebuild process needs? I would never believe that it requires more than one, but who knows....
  8. DSM 6.x.x Loader

    I was about to make a video tutorial on how to upgrade to 6.1 with 1.02b after over a month with successful testing when suddenly one drive crashed. SMART values are fine and disk is ok, so it's false positive, upon rebuild another one bites to dust... also a false positive. I still suspect the 9201-16i PCI card to have some issues with XPenology, but the weird thing is that this only happens every 1-2 years. Could also be stress-related since I this time started a scrub hours before it happened. I have plenty of cooling, replaced all wires and drives, still the same thing happen a few month later. Since I'm on ESXi I don't think that anything else apart from the PCI controller, wires, drives and bay should matter but I'm left completely clueless on this one. Anyone else had sudden crashes for no apparent reason?
  9. DSM 6.x.x Loader

    Thanks, but I've figured it out. The problem was that I had to enbale hotplug cpu in esxi. Everything is working great now. I have the 9201-16i myself and it's great once you know about the setting.
  10. DSM 6.x.x Loader

    Awesome! Would love to buy one of those Threadripper CPU's
  11. I know this was required before, but what's the benefit of adding the serial port? Just debugging information and being able to do low-level stuff if SSH is down/disabled?
  12. DSM 6.x.x Loader

    because the loader packs a earlier kernel & ramdisk with it, and they are expected to be upgraded to latest version during install or upgrade process. that is how the loader is able to support multiple dsm version, and allows you to apply latest security fix, if kernel version code does not change. Thanks a lot for the clarification! I've also managed to get around the "general protection fault: 0000 [#1] SMP" issue when enabling SNMP or visiting the system info page. Seems like disabling the LSI cards BIOS and enabling CPU hotplug in ESXi will do the trick. I can't reproduce the bug anymore and everything works a lot better now. I now get a ton of these in dmesg, but it doesn't seem to do any hard (still trying to figure out how to remove them as well): [30377.275744] do_IRQ: 0.218 No irq handler for vector (irq -1)
  13. DSM 6.x.x Loader

    I'm curious.. I know the latest loader isn't compatible with AMD CPU's, but has anyone tried to use a AMD CPU on ESXi and this way get around this limitation? I wonder if that would actually work or if that also would fail. The reason I ask is because I suppose my i7-3770 to cause the "general protection fault" I've posted above. You would think that ESXi completely virtualizes the CPU and by default it does. However, once you enable passthrough the situation seems to change and the CPU is limited to the instructions it actually supports. It's like enabling passthrough punches a hole in the virtualization layer.... I'll investigate/prove this right or wrong when testing this with other PCI devices in passthrough mode instead of the current LSI SATA controller. So if anyone has tried using AMD on ESXi please let me know. My assumption is that it works well, but breaks horrible once you enable passthrough.
  14. DSM 6.x.x Loader

    Strange, I've always had the drive as independent without issues. Thanks a lot for the suggestion, seems to have worked!
  15. DSM 6.x.x Loader

    Another thing I've just noticed.. I've just upgraded from DSM 6.0 to 6.1 and every time the VM boots it's status is set as "Recoverable". It's able to repair it every time, but I have no idea why this should happen. Never encountered this on earlier versions of XPenology.