RobJ

It would probably have to be manually entered, as there's no easy way to automate it. You can now get the ata number, if the drive has one, by searching the syslog for the first occurrence of the drive's serial number. And you can locate the scsi symbol (both scsi 0:0:0:0 and sd 0:0:0:0) by searching for lines with the drive symbol (sdX), or using the lsscsi command. The SATA ports are associated with the scsi symbol. You can get the SATA controllers from the lspci command (usually as 'SATA controller' but sometimes as 'Serial ATA' and 'controller'). But I don't know an easy way to reliably associate the scsi symbols with the PCI ID's of the SATA controllers.

I've seen a fair number of invalid values from various sensors, 2 of yours appear to be invalid which is fairly common. Some sensor chipsets even produce warnings in the syslog that readings may be unreliable. The idea is to examine the readings and pick sensors that are working correctly, producing valid values.

Check out JustinChase's method, multiple questions, found here. I thought that was a great idea, when it's the same problem but manifests in different ways.

There are different caches for different things. The cache for folder entries is in lower memory and as far as I know cannot use the high memory, like caching disk files can. So that only gives you less than 500MB I believe, possibly much less. Moving to the 64 bit v6 would give you access to all of your memory, as Alex said.

I can tell you are almost certainly a long time Windows user! You've a lot to learn about Linux! First thing to learn is Linux is case-sensitive, and by convention prefers lower case, so you don't want to use all caps like you have been. You mentioned PACKAGES and Packages folders, and while you can create those, you absolutely don't want to, as the only one that unRAID uses is packages. You could create all 3 folders, and have them visible simultaneously, but anything you put in the other 2 won't be seen by unRAID. And I'm absolutely sure you did not see .TXZ files in that folder, they had to have been .txz files to be usable. Using all caps is going to create a lot of confusion for yourself. FAQ, unRAID Console section - old but still useful I strongly recommend you spend a little time on the info found in the FAQ, unRAID Console section. I think it will help answer some of your questions, such as the /boot folder. Even in Windows, paths can be different depending on how you map them. You can assign different drive letters and access the same file through a different path. If you were to name your unRAID server MyStuff, then assign a drive letter of U: to the flash drive, then you could access flash root files as \\MyStuff\flash\*.* or as U:\*.* . unRAID maps it as /boot, so you would access the same files on the console as /boot/* . As to the temp monitor, you can blame much of that on the manufacturers, as there hasn't been much call for standardization previously. Tools like SpeedFan on Windows have taken a long time and a lot of code and a built-in database of info in order to analyze and dig temps out of all the mobos out there. The Linux tools are catching up though, and sensors and sensors-detect and the lm-sensor project have been gathering up info to make it easier. The System Temp plugin is a fairly new tool to automate this, and except for a brief hiccup over Perl, has made it a lot smoother than it used to be. (It's almost too bad that you weren't here to see how much harder it used to be!) And I'm quite sure that it's going to be getting even smoother in the near future, great people behind it!

The upgrade plugin does not run make_bootable, so you may have run into what everyone runs into sooner or later, somewhere during the v5 betas to v6 betas to v6 final - the need to update the syslinux boot support. Try taking the flash drive to a desktop station, Windows or Mac, and running the appropriate make_bootable, then try booting again with it. See the Make it bootable section. There is also a Troubleshooting section of the upgrade guide, for a couple of issues with the upgrade, namely that the boot order may have to be fixed, and that networking may have to be changed.

You did not say whether you are running v5 or v6, and whether you are running the plugin or the script from the go file. If you are running this in v5, then you are limited to low memory only, which is considerably less than 1GB. I don't know your layout, but have you tried the depth parameter? It defaults to unlimited, but you can set it to 3 or 5 or whatever, and limit it to only scanning that deep into the folder levels. At the command line, it is "-d 5" (for example). In the plugin, it is the Maximum scan level depth: parameter.

Does this plugin take care of that? is that needed/way to test if its needed? The plugin does not do it for you. In v5.0-rc9, a final permission or owner change was made to the New Permissions tool, so if the last time you ran it was before that, then you need to run it again now. If you have NEVER run it, then certainly you need to run it. Good question! This was added to the guide during earlier beta testing, so it has possibly been resolved. It's my understanding that some felt it was just a reporting issue, not a true problem, but that did not seemed to be confirmed once and for all. Have you tested it for yourself?

Yeah, you're both correct. What I was trying to do was solve 2 different problems, and it just introduces confusion. I was trying to show which files are valid in v6.0.0, and also trying to show which of the previous files and folders to keep or delete. There's considerable congruence between them, but also some conflict, a source of confusion. What I should probably do is completely forget about what's correct for v6 (or at least completely separate that out), and just concentrate on what to do from an upgrader's standpoint, with their flash full of v4 and v5 files and folders. I think I'll also add color coding, red for "delete", green for "safe to keep", and blue for "it's your choice". Then I can add more help on each, especially to explain when it's their choice and why. As to syslinux, I believe it's mentioned in passing in 2 places, but you're right, it needs its own section. It's a really nice new feature but has had no hype at all. A bit off-topic - I understand why there's no go editor as we don't want to encourage its use any more. But if we had one, then we could also have a Stock button with it, that would rename the current go file ('go.bak'?), and save the stock version in its place. It could be helpful for troubleshooting, an easy way to return it to stock; and it would make it easy for experimenters. They could add something, test with it, then easily return to stock.

I need others to review for accuracy the new Files on flash drive section of the guide. There have been several requests for info on exactly what can be kept and what has to be deleted, so I've tried here, but it's tough, as things have changed over our long history. There are 2 items near the bottom marked with question marks.

Link to upgrade guide -> Upgrading to UnRAID v6 See also this related topic.

My apologies to everyone, but I decided to pull weight a bit, to keep the FAQ clean, and move all other commentary, relevant or not, to this thread. The discussion is good, but this is a better place for it. It's also available for FAQ requests and suggestions. I will move further non-FAQ posts here too. You can still quote posts from there, just use the Quote button, then copy the whole thing over here, create a new post here, and paste it in.

By request, all of the discussion of the Done button has been moved to 'Done' button operation in the Development board.

I do not think it is necessary. As explained, I did it to try to avoid unRAID detecting a very large number of duplicate files in user shares. Creating the "t" directory is painless, and many users have followed the guide, you might just want to do it the same way. But it is up to you. Which reminds me, I've wanted to ask, has *anyone* done it without using the extra T folder, and did you have any problems? Did file duplicates appear, and if they did, were they a serious problem, or just a temporary nuisance?

I think what others are saying though is that they have the same Cache drive they have always had, and have chosen to continue with that, so there is nothing wrong with their setup. The fact that it is now considered 'not fault tolerant' is worthy of a one-time notification, but should not be repeated. They are now fully aware that a Cache Pool would be better, and are choosing to stay with what has always worked, and don't want to be warned about it every day. Perhaps require a one time acknowledgement, a check box, and then it returns to green? Or make it green if that is how user has set it up, no test for only one drive. They usually do know from the education here about the advantages of a Cache pool. The yellow triangle will only be for the presence of un-moved files.

Yeah, I can see that. I guess I don't think of them as bullet points or adding prominence. I don't use them for emphasis, I use them for organization. But I can see I've over-used them. Both are very good ideas. I'll see about moving it down to Other Topics. Haven't done it yet, as it's a little complicated to extricate. I've started the transition to adding a 'clean' install, which unfortunately means the page is a little MORE confusing at the moment, since it's only a partial transition yet. I started with the idea of 2 types of upgrades, "a 'clean' install" and "an 'upgrade' install". I'm closer to understanding the issues now, and it really looks like it may be best for anyone coming from ANY version prior to v5.0 to skip v4.7 and v5.0, and do a 'clean' install. I'm open to better terminology... I was rather surprised by this, by your teacher! It goes against everything I have ever learned about them, or ever seen, so I'm going to have to research it, perhaps I've been wrong all my life! Or perhaps it's a regional thing... Can you rewrite this sentence? It's not clear if you are referring to helping those with customizations, or helping those who help those with customizations, or maybe it's both! But also, do you think this sentence is necessary? I'm not crazy about all the additions to the top, because it feels like it's becoming a preamble. I prefer the absolute minimum, and then get straight into what the user is here for. But that's me, it's good that you and others are involved to balance me. Me, I'd chop out maybe 70% of it. All the extra explanations seem unnecessary, makes the page that much longer. The more we add at the top, the sooner they zone out farther down and stop reading. Just my opinion... The license key stuff was good, and I added to it, reorganized it, then thought that most of it is descriptive, not implementational. So I moved most of it up into the Important Considerations section, and just left the implementation parts. Lots more to do ...

You can read my recommendations for CacheDirs in the Upgrading to UnRAID v6 guide.

Howdy itimpi, I saw your terrific work, great additions to the wiki! And I'm especially happy it's not just me to 'blame' now, it's more truly a community effort! I'm sure you saw my tweaks of your work earlier, and I wondered if they were acceptable or just annoying. I know I'm not as creative as others, not as good a writer, but do like making good things better. That unfortunately is almost by definition annoying to others, and has often gotten me into trouble. I'm a perfectionist, and they are by nature hard to live with, but I have long tried hard not to be. So if you don't care for any change I make, feel free to change it back! I tend to prefer less words whenever possible. I've long noticed that whatever I start writing soon gets very long! Plus, and this may only be me, if it doesn't get to the point quickly, my mind is far away. The fewer the words the better for me, but that may not be best for others. I will probably try to reword things as succinctly as possible, then others can expand it if they feel it necessary. Almost all of your changes, I fully agreed with, often wished I had thought of it! I did notice a few things, so just for discussion - * Nice additions at the top. I'm still planning to expand the opening to cover alternate methods depending on which version they came from. But I got sidetracked, multiple times, thought I would have had it done by now. * You added the 3 words "most users can" (into sentence beginning with "Once the backup is complete"). It feels like it's opening the door to more users using the No-format section, and we REALLY REALLY want users to format and start fresh. I don't want to remove that section, because there will always be experienced users that want it (and you know who you are!), but we don't want anyone else using it. However I am hoping to add more specific info to it, about the specific files to be copied over or deleted, but it's still dangerous for the less experienced to use. * You moved the make_bootable stuff into the middle of the Copy Files section, and reorganized it all, added some good info. For me, it seemed to make more sense in the Final Prep section, but I don't yet know your reasoning. (Now there's nothing left to prep in Final Prep.) The headers don't seem right, so I'm thinking of changing them to - Copy unRAID files Make it bootable Install license key Copy saved configuration files Done! You may have better ideas. * Concerning multiple .key files, I had put that you should only put the correct one in the config folder. You have added that they could all be put in the config folder, and unRAID would find and match the correct one. If you are correct, then my statement should be removed. I'm not sure it's best to keep the keys all there, on all your flash drives, but I haven't thought this out yet (first I had heard of it). * In 'Meet the new GUI', you commented how different it looks compared with v5, and I had noted how similar it looked, probably because I had been using v5 Dynamix (but many others used it too). But even the stock one seemed similar to me, same content and general layout. Perhaps we should drop any comment on how different or similar it looks, as either way it may not agree with a given users' perspective. It's good you did it, because it gives me another perspective, that would not have occurred to me. For me, content is king, the graphical stuff tends to be almost inconsequential in comparison. You see products with 'major' improvements and a hefty upgrade fee, but all they have done is move a few things around, add prettier buttons, change colors and fonts, ... I don't see a single change in their product, but they are trumpeting major improvements (probably to justify a ridiculous upgrade fee). But I've digressed, far away... *Our* new GUI is enormously enhanced, a worthy upgrade! And free! * In the next sentence, you changed commas to semi-colons. Grammatically, I think they should be commas? (I don't feel comfortable reversing someone else's work without asking!) * About the Done button, we really should press for a behavior change. I can't see how it can be justified to leave a page without saving changes, and it constantly causes confusion, seems non-standard. Using 'OK' and 'Cancel' might seem like copying Windows, but would make it intuitive to more users. It's good you expanded on how it works now. We might even want to make it stronger, with a leading 'Warning!' in red. * You added a line ("Plugins are ideally..."), but many plugins are not from LimeTech, so perhaps we should drop the "provided by Limetech". * Limiting 'Research & Decision making' to virtualization - doesn't seem right to me. Plugins are still the most common addon, and probably will be for a long time. The decisions to make are all about what should be a plugin, what should be a container, and what should be a VM. And plugins are how we add functionality to the NAS part, the basic unRAID server part. The NAS wants attention too! And there are very nice plugins to add, such as Community Applications, Server Layout, Unassigned Devices, etc, all improving constantly. We're not totally deprecating plugins, we're trying to educate users about their changed role in the new architecture. * In CacheDirs, you changed "**:" to "***", making the notes equal, but they aren't. There are only 2 notes, each with 2 or 3 paragraphs. I think I'll rework that whole section a bit. * You added Docker recommendations within some of the plugin carry-overs, from PhAzE and overbyrn. Maybe it's just me, but with all the strong recommendations we made earlier, about Dockers over plugins, it almost seems disrespectful to add it again here. They have worked hard on them, done great work, fully converted them to v6, *and* there are users who still prefer the plugins, which is their right. My feeling is that I'm not here to tell people what to do, but to provide the best info and recommendations I can, so they can make the best decisions. Then I should stand back and fully respect their choices. I do understand why you added them though, could probably have added more about the risks. But it seems too much to me, possibly becoming irritating, and it's all been said and repeated above. I hope you don't feel I'm being critical, I'm not, these were just items to discuss. There were so many other changes you made (not mentioned above) that were very nice additions!

Are you interested? There have been complaints from the very beginning about the wiki, and everyone *wants* the wiki to be better, but in the end almost no one actually has time to work on it. It reminds me of the trash can or tree branch that falls into the road. Most everyone slows and with difficulty gets around it, muttering that *someone* needs to move it off the road. It's a rare person that will actually stop and remove it though.

There's one other option, do a New Config when you are all done converting, and re-assign all drives to their original slots, then you can either rebuild parity (optionally without the empty drive), or mark it as already valid (but good to run a parity check anyway). The actual data will be on physically different drives, but the same disk numbers, so share configuration will still be correct. Your choice, but the quickest would be what you added by your edit.

When you have time to work on this, you may want to look into the Areca Controller thread. bjp999 and bubbaQ did quite a bit of work identifying the parameters and options needed. It would be hard to implement all of their work, but does seem worthwhile to add user-configurable fields for the options necessary to obtaining temps and SMART info, and whether they are available when spun down, maybe other things too. I'd love to see bjp999 working with you, as he had to do a lot of this kind of thing as the author of MyMain, the customizable Main screen face of UnMENU. As much as I liked UnMenu with its extras and versatility and customizability, there's no way but to consider it the past, and Dynamix the future. It served its generation, and served it well. It still has some life left, but is beginning to fade away. It would be great to see the best of UnMenu migrated to the new webGui.

Is this drive a lost cause or could it also be the SATA port its snapped into? It was a tough snap in so I am wondering if I damaged something maybe? The 'media error' with 'UNC' (UNCorrectable) indicates a bad sector, so the port would not matter. If sdh is the drive you are Preclearing, then you should probably Preclear it one more time, after this session completes, and make sure that Current Pending Sectors is zero on the final SMART report.

I think everyone likes the blue ball for a new drive. And for the User Shares state, we don't want a red ball for Cache-only shares, especially a red ball with X. Need a 4th color. A color blind user needing support could describe what he sees as the check ball (green with check), the X ball, (red with X), and the bang ball (yellow with '!') (or the exclamation ball). can't remember what discipline calls it the bang

I like them. I'm unsure about all of the 'offs' being undecorated squares though. Could there be red/green confusion, or are those never used in the same context? Could you link these with their meanings/purposes from Tom's first post - 3 Array States, 9 Array Disk States (5 and 4), 4 Cache Disk States, and 3 User Share States. I'd prefer separate columns for spin status and drive status, but it would require a little more coding, so I don't think we want that for v6.0 final. So I'm happy with the above, once their purposes are sorted out.

Some issues and thoughts - * A very nice idea, and a very good start for it! * It looks like you are keying on the Path in order to locate each drive after a reboot. Once I rebooted, most of the drives I 'installed' on the layout disappeared, only 3 were showing. The 3 that were still there happened to have the same SCSI path as the previous session. One drive had the same device symbol but a different path, and did not reappear. Both SCSI paths and device symbols can change with every boot. The ONLY thing you can rely on is the drive serial numbers. * After selecting slots for 5 of my drives, I could not get any more to stick. I'd select a slot for them, then click the Save Data button, and when the screen re-displayed, they would be gone, no matter how I tried it. Since I had recently turned off a number of columns, I turned the dates and manufacturer columns back on (for the Installed screen), and then found that the changes would stick. I haven't tested further yet, to see if it's a specific column that has to be on (like manufacturer), or a current column count issue. * I assume there will be ways to edit the install dates? They are rather useless right now. What might be useful to some of us is the Power_On_Hours, attribute 9 from the SMART report. * I too have drives in enclosures outside of the system case, so could use a mechanism for 2 layouts, but it's a low priority for now. I set up 2 columns, 10 rows each, and consider the right column to be inside the case, and the left column to be outside. I ignore the slot numbers, and mentally 'number' the drives from the bottom up, just leave various ones blank, and it works OK for me. * Many would probably like to see the array drive number with the drive. (That's a second column request, the first being power_on_hours. Neither are high priorities.) * The UnMENU MyMain screen had some similar capabilities. One thing I remember was a Notes field, and I expect you will be hearing from users wanting that, for each drive. I know there were a few other columns too, but don't remember them now.