limetech

Administrators
  • Content count

    6447
  • Joined

  • Last visited

  • Days Won

    9

limetech last won the day on July 27

limetech had the most liked content!

Community Reputation

123 Very Good

About limetech

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed
  1. Also important: it support devices larger than 32GB. As flash devices get larger and cheaper eventually people will try say, a 64GB device. But a problem is that Windows 10 will only let you select NTFS or exFAT for devices larger than 32GB. Our boot loader, syslinux, does support NTFS but linux does not (well it kinda does), and exFAT is patent-encumbered and therefore frowned upon in the linux world (and has no native file system driver unlike FAT). For a user to work around this, they would have to open Disk Manager and partition the device themselves, then install syslinux, then make_bootable. This adds to an already cumbersome procedure. Alternately they could download a 3rd party tool to format the device as FAT32 with larger cluster size, but again, adds more steps. With >32GB devices, but <= 256GB, our Flash Creator tool will create a single partition 1 with FAT32 file system with larger cluster size, and then install bootable unRAID OS in that partition. For devices larger then 256GB, remaining space is simply left unallocated and the user could create a second partition for whatever use they want. The point is, the Flash Creator tool makes the entire process easier. We deliberately put the code on github so that everyone can see that the executable is not doing anything nefarious.
  2. ...and C: drive remained intact I presume (!) Seriously - @eschultz has taken great care in handling of devices.
  3. Edited first post to make this clearer, thanks.
  4. Under Tools/Upgrade OS
  5. Yes give it a try.
  6. Only one now is the Rocket Raid driver.
  7. Also make sure you're running -rc7a (-rc7 had a cache-related bug though I don't see evidence of that in your syslog).
  8. Actually everything looks ok in your syslog, cache is mounted fine. But looking in config/share.cfg there is supposed to be a line: shareCacheEnabled="yes" or shareCacheEnabled="no" This var is completely missing from your share.cfg file. This should not be possible with a "stock" install. I suggest you boot in 'safe mode' to eliminate possibility of one of your plugins being the culprit. Meanwhile you can go to Settings/Global share settings and set that thing back to 'Yes'.
  9. Fixed in 6.4.0-rc7a. Bug was introduced during code refactoring, sorry...
  10. Please try -rc7a, probably will solve these issues for you.
  11. No it's 4.12.3, I messed up the change log.
  12. 6.4.0-rc7a released. Just corrects the change log and fixes a minor bug.
  13. Took it out out originally in -rc1, then others came up with reasons to keep it, so put back in -rc5. We took it out to simplify things and in future it might be banished again. What you're doing obviously works but is error prone if not careful. The rewrite of 'mover' actually permits many kinds of share move operations such as depopulating a disk or rebalancing shares, we just need get around to writing a UI for it...
  14. Yeah same reason the nvme fix wasn't in the log. Someone pushed a last-minute changelog change after I built the actual release - I'm going to blame @eschultz Though prob I neglected a final PR check.
  15. Yeah probably it will.
Copyright © 2005-2017 Lime Technology, Inc. unRAIDĀ® is a registered trademark of Lime Technology, Inc.