gubbgnutten

At least when I bought the two pack the e-mail I got with the first key had pretty clear instructions on how to get the second key. If I recall correctly, it told me to reply to the mail with the GUID of my second USB stick. Didn't you get any instructions? In any case, you are probably better of e-mailing LT for this particular issue rather than relying on community support here. Good luck with your second server. My second one was a major improvement over the first one, practical experience helped a lot.

Your 3 and 4 does not make any sense at all to me for setting up unRAID from the zip file... You should probably instead just follow the regular instructions for "Preparing your USB Flash Device" and only change the part about "Run the make bootable script". Take a look at the invocation of syslinux in the make_bootable.bat file for inspiration about that step.

Updated from 6.1.2 to 6.1.3 via plugin, didn't end too well. Wonder if my flash is getting bad and need replacement or if something in 6.1.x strongly dislikes me. Will be prepared for next update to more closely monitor and log the update, as well as have a fresh backup of the key to see if that update also fails, and if so, fails reproducibly. This update looked perfectly normal at first, until syncing took way longer than expected and then things got weird... syncing - please wait... Update successful - PLEASE REBOOT YOUR SERVER Warning: copy(/boot/config/plugins/unRAIDServer.plg): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin on line 523 plugin: updated Despite the "Update successful", the system wouldn't boot. Not that I really expected everything to be fine given the warning, of course, but it is very unfortunate to get the "Update successful" message when the reboot will fail. All updated files showed up as 0 bytes on another computer, including the contents of the "previous" folder. Filesystem needed repair, obviously, as well as a complete re-install. 6.1.3 up and running now. Yay for 44MB of fresh usable RAM!

To be fair, that does not really sound like the same issue at all if you read past the first point In any case, I don't think you need to be too concerned about upgrading because of some problematic upgrades, just keep backups.

No problems pulling the data disks from unRAID and putting them into another Linux machine if your server blows, standard file systems on the data disks.

Isn't the Store notifications to flash setting just read from the flash drive? Wouldn't that mean that the drive has to already be properly mounted for the value of the setting to differ from the default value (whatever that may be)? And if the drive is already properly mounted, /boot should be perfectly safe to use? Edit: When is /boot/config/ssh created/populated? Don't recall seeing any other files/folders under /boot in my case, but then again, I didn't look for hidden files...

Weird update experience for me, but all sorted now. Might try to replicate on my lab server out of curiosity. Or possibly actually search the forum... Step-by-step recap in case anyone is curious or easily amused: [*]Upgraded to 6.1.2 from 6.0 via the plugin, rebooted as usual, and ... nothing! Trusty old server.local wouldn't respond! No web interface! No ping! Gaah! [*]Plugged in display, greeted by normal Linux console prompt and correct version of unRAID. So far so good. But why can't I reach it over the network? [*]Logged in as root locally. No password required. Unexpected. Got a bad feeling about this... [*]OK, the server had an IP address, but was not using LACP bonding but rather eth0. Driver issue or lost config? [*]Outgoing pings functional. SSH connection to IP address instead of hostname from desktop refused due to changed server keys. Telnet OK. Alright, LAN is there too, just reset? [*]Let's have a look at the config ... hmm, config is completely empty save for ssh. Could explain symptoms so far at least. [*]What!? Rest of /boot hierarchy is completely empty too, how did the system even boot!? [*]Alright, default config means no array, and /boot is weird, so nowhere to store diagnostics or syslog... Maybe use the network? Nah, forget it, I'll just remake the USB stick and restore from backup... Want the server up and running ASAP. [*]Shut down server (long power button press required, not surprising), plugged in USB stick to regular computer. [*]What!? The USB stick looks perfectly fine, and reports no file system errors. Let's eject it without changing a thing and plug it into the server again... [*]Server boots just fine.

As you can see from the picture, the IP address is not 192.168.2.22, but rather 192.168.81.235. Looking at the system log, it seems that you have two DHCP servers responding (192.168.2.1 and 192.168.81.1). In the end, the system decides to go with 192.168.81.235 rather than 192.168.2.22. If your router is 192.168.2.1, figure out what device 192.168.81.1 is and disable the DHCP server on that device (or move it to a separate network).

From a few posts back - the data disk was modified on another system, so the data drive and the parity drive are out of sync. So, the options are to either discard the parity and trust the repaired data drive or to try to repair the emulated drive and rebuild the data drive.

Boot 6.0.1 and generate a diagnostics file for us, as described by RobJ.

To be on the safe side, you could add which browser(s) you experience this on, and if it is something new in this release Sweet! Maxing out 1G writing to the cache is not so though, though. Any decent traditional hard drive in the cache is plenty enough for that with sequential writes... Not so much for concurrent I/O of course, horrible task for spinners

Running preclear on new disks before adding them to the array has multiple benefits, one of them is to help avoid problems like yours by triggering marginal drives before actually trusting them with data. The other great thing is that array expansion later on will be more or less instantaneous with a precleared drive. You appear to be under the impression that the system was under relatively light load. I disagree - If parity was being built, it means that all drives were being used at the same time, data drives constantly read as fast as possible and parity drive written to in corresponding fashion. In addition to this, you added content to Plex. I would assume that this means copying files to the array and then having Plex scan the files and generate index files in the background. Aside from stressing the I/O system even more during parity generation, this also puts the CPU to 100% use by Plex. Maxing out both the hard drives and the CPU would certainly explain rising temperatures… That said, this is not a problem for a healthy drive in a decently cooled system. If your components are overheating, you have a hardware problem of some kind. Since both your cache drive and one of the data drives had temperature warnings, I would first check that the fans are fully functional and that nothing is obstructing the airflow. What was the ambient temperature? Were the drives with temperature warnings located next to each other?

...here I was just looking forward to a stable 6.1, and now you tease me with 6.2 and PQ? Evil! Nah. Thanks for the heads up. Time for me to start investigating my options for controllers, I'm all out of SATA ports... Also time to start looking for a bunch of low-capacity drives for a test server...

No, I get the same. Plenty of people around the web seem to have the same issue as well. Edit: Repository still offline, restoration in progress. Should finish any day now...

Makes sense to me, actually. But hey, I'm weird! The pool comprises two disks, 500GB each, so it has the size of 500GB+500GB=1000GB. How the 1000GB are used doesn't make any difference, there are still 1000GB in total in the pool. Those 1000GB can be used in different ways. Since the pool is set to RAID-1 redundancy in this case, and the pool has two disks of equal size, half of that space is used for redundancy. This leaves 500GB to use for storage, and you use about 16GB of that for dockers and stuff, which leaves a total of 500GB-16GB=484GB free and 500GB+16GB=516GB used.

I presume you know you can already set them as non-exportable by simply clicking on the disk on the main GUI page. Yes, I'm fully aware of that, that's what I do. But thanks for pointing it out just in case! It's just that I tend to forget this when adding new disks... And it is also slightly annoying to do it for every disk when setting up a new server. Did I mention being lazy?

Sounds great. Especially looking forward to the setting for setting disk shares as non-exportable! As for enabling user shares by default, will it only affect new configurations? Or will the vocal group currently running without user shares by choice have to disable them after upgrading? (Sorry for completely ignoring "Watch for the 6.1 release announcement for more information." )

Try the sticky Need help? Read me first!. It has instruction on how to grab diagnostics for posting.

Now that we are on a stable release with 6.0.1, will the update plugin still suggest upgrading to betas/release candidates, or will it stick to stable releases?

Unfortunately, something having "parity" in its name doesn't necessarily make it useful in all parity scenarios...

Now that's a bottom line I like! My main server's array keeps growing, and dual parity should reduce my risk of data loss immensely. Yeah, I know, it is no replacement for backups, redundancy won't protect against deletions, bugs or overwriting the wrong file and so on... I have backups of data I can't lose. Online, offline, offsite, you name it! Most data on the array does not fall into that category, however, but rather the "inconvenient to lose" category. Objectively speaking, the cost of losing everything in that category is less than the cost of having a proper backup of everything. Adding one more hard drive for parity on the other hand would be totally worth it.

The thing is, unRAID is not "a stripe scenario" like traditional RAID. One file goes to one disk, it's not split on block level to multiple disks. That's why we currently can write to the protected array and only have the parity disk and the actual disk(s) written to spinning, and that's the feature many of us cherish. Nobody is expecting to write to the array with all disks spun down. As you can see in the first post, there are solutions for keeping this behaviour even with dual parity, but those pesky software patents are complicating things. I have no clue whatsoever about the licenses/royalties involved, but I can understand if LT in the end decides to steer clear in any case and stick with the safe method.

I am not familiar with the package manager, but as for the package, there is a http://ponce.cc/slackers/repository/bwm-ng/bwm-ng-0.6-x86_64-5cf.txz available. Might be what's needed. 5>4 so I guess it's an update.

It is not a problem with unRAID, so no - do not report it as a defect for unRAID. The message is from the 404 page you get if you try to access the package URL. Open it in a web browser and see.

I’d gladly pay for one disk of extra redundancy. Please don’t dismiss #1/#2 until you at least get a quote for the royalties requested. It would be awesome not to have the entire array spun up. Not a deal breaker for me, though, but it would be really nice. Given my writing pattern I’d rather have dual fault-tolerance and all drives spinning while writing than single fault-tolerance and mostly spun down drives. There's always the cache pool if it bothers me...