April 6, 201115 yr pras1011, you've poked at limetech multiple times throughout this thread. He'll respond/update when he's ready. Indeed. AIUI, he is waiting for some more evidence from people who encounter the problem, and have enough intelligence to read, and understand, the instructions. Beta6a is intended to provide some diagnostics but most people who were going to update have done so - before b6a, and there are now so many cautions about upgrading to the beta that it has probably put most people off. The project hasn't been abandoned or anything like that please have some patience. 4.7 is working fine, 5.0 is a beta, there's no time line on it whatsoever. For many of us, 5.0 beta is working fine too, and has many improvements. I would be loathe to return to 4.x now.
April 6, 201115 yr For me, having something "workable" vrs having something "UnRaid stable" is well worth the wait, I'm amazed at what Tom inc has done with 4.7 and 5.x beta's. I can only imagine that bugs at the level he's checking code isn't easy to track down or solve without repercussions, so just have some patience and help the noobs (like me) along in the meantime.
April 6, 201115 yr I can only imagine that bugs at the level he's checking code isn't easy to track down or solve without repercussions ... Again, AIUI, the problem which is holding things up is not a bug in the unRAID code, but is due to something unexpected having happened to the MBR of some drives. Whether this unexpected happening resulted from an earlier version of unRAID, or is due to some history of HPA activity, or is due to to the drive having been used with another operating system/bootloader ... any or all of these ... is still not confirmed - this is what the current investigative mode is intended to discover. My view is that we have probably reached a stalemate - there are no more willing guinea pigs and there is no further new functionality to entice people to upgrade. I would, tentatively, suggest that when Tom next has some time to devote to this project he should make changes to prevent the array from starting in the case of an MBR unknown (there are still the options of using mkmbr for corrupted MBRs, or preclear for those who truly believe their drives to be unRAID virgins) and/or dump the entire MBR to a file on the flash drive, for subsequent analysis, and then continue with further developments.
April 6, 201115 yr As has been said, Tom is still working on the issue but the hard part for him right now is that he can not reliably reproduce this on his systems. That makes it incredibly hard to troubleshoot the issues. If I get some free time next week I will mess around with 5.0b6 on my production array and see if I encounter any of the issues.
April 6, 201115 yr pras1011, you've poked at limetech multiple times throughout this thread. He'll respond/update when he's ready. The project hasn't been abandoned or anything like that please have some patience. 4.7 is working fine, 5.0 is a beta, there's no time line on it whatsoever. How do we know he hasn't abandoned the project (I doubt it as its a great revenue stream)? He appears on the thread for a little while and then disappears for ages. This beta is over a month old. But I do take the point that others have raised and I will now shut up!
April 6, 201115 yr How do we know he hasn't abandoned the project (I doubt it as its a great revenue stream)? Actually, I'm not so sure about that . I suspect that it's very much a labour of love rather than a 'great revenue stream'! I'm sure that I read somewhere that Tom initially created unRAID to meet his own needs for a media file server - I've had projects that started like that and they definitely don't become big earners. For instance, an lpr protocol driver for a minority ARM processor O/S, written entirely in ARM assembler - another company handled sales and marketing, but I believe that total sales are counted in the low hundreds. He appears on the thread for a little while and then disappears for ages. I understand that this is a regular pattern for this project - I take it to mean that there are times when Tom has to devote his time to commercially viable projects in order to support himself (and family?).
April 6, 201115 yr I understand that this is a regular pattern for this project - I take it to mean that there are times when Tom has to devote his time to commercially viable projects in order to support himself (and family?). A message sent privately to the moderators on the 20th stated he was dealing with some family matters and his activity on the forums would resume shortly. He stated email-support and sales were proceeding as normal. He monitors the forum, and was active in dealing with a bit of spam posted to a few threads over the past few days. I'm sure in his idle moments he is working on the next beta release. Joe L.
April 6, 201115 yr So I got an MBR:Unknown today I'm running version 5b4 on my server. (config attached) I needed to find the GUID for a new USB drive so I downloaded 5b6a from limetech and booted my system. All drives were fine showing up a 4K aligned except for the SAMSUNG_HD501LJ_S0MUJ1FQ114794 which is my cache drive. It reported MBR: unknown. I retrieved the GUID I needed, shut down and restarted with my b4 drive. All was well (except for having to reassign the drives as per the know issue with this version). I have the b6a drive sitting on my desk. I haven't plugged it in to any other system since. IF any files are needed off it, I can supply. I don't know the precise history of this drive but I do recall manually formatting it as reiserfs via linux command line at one stage as unRAID didn't seem to want to use / did not offer to format it when assigned to cache position it but I can't remember the exact details Peter
April 6, 201115 yr Please post the output of the two commands as listed in this post: http://lime-technology.com/forum/index.php?topic=11540.msg109913#msg109913 (substituting your correct device name for "sdb") You do not need to assign the disk to the array, you only need to connect it to a disk controller to run the two commands. Joe L.
April 6, 201115 yr do it under 5.0b4 and then again under 5.0b6 PLEASE!!!! It will help in trying to narrow down what is going on.
April 6, 201115 yr Commands run under each system. Well, it is a Linux partition, of approx 500GB. However, there are a lot of non-zero values where I (and unRAID?) would expect to see zeroes. From the ascii strings in the middle of the block, I would guess that it's the remnants of a boot loader. Null-terminated (asciiz) strings such as 'Invalid partition table', 'Error loading operating system' and 'Missing operating system' would seem to indicate this. I'm guessing that the values preceding the ascii, is binary machine code - probably x86, but I'm not familiar enough with the x86 instruction set to recognise it. I wonder whether there is a clue in the data starting at 437? Perhaps relating to another partition? The question is: When was this data written (before, or after the disk was formatted for unRAID) to the sector and who put it there? I'm guessing that it must have been put there before the unRAID format, else the 0x83 and partition size would have been obliterated. This would then lead to a supplementary questions: Would any version of unRAID/preclear have created the MBR without zeroing out the unused bytes? and, if not, How was the linux partition created (if not by unRAID or preclear)? Ah, perhaps the unexpected data was not written prior to the unRAID formatting .... the boot loader code seems to finish at around 378/379. Perhaps when that was written, the rest of the sector was left untouched? This might then attach more importance to what is at 437?
April 6, 201115 yr meep - can you give a history of the usage of that disk? Would any version of unRAID/preclear have created the MBR without zeroing out the unused bytes? I'd like to see the answer to this question as well. Peter
April 6, 201115 yr meep - can you give a history of the usage of that disk? Would any version of unRAID/preclear have created the MBR without zeroing out the unused bytes? I'd like to see the answer to this question as well. Peter Theoretically, no, but who knows if it was originally configured as a cache drive and before a parity drive was defined. Since it looks like a boot loader, could you have a RAID based disk controller that might have added it? (making the assumption it was originally zeroed) Joe L.
April 6, 201115 yr While I don't particularly keep track of disks, now that I think about it really hard, the disk came out of a Freecom External Network Drive. As such, it might have had some NAS specific partitions? I know I would have formatted it with ReiserFS either before or in the UnRaid server. It's also VERY likely that this disk did not go through any unRaid formatting OR the preclear script - I've discovered the joys of that particular process only recently. That's all I know. Maybe as such it's not much help in debugging the unRAID issue? Peter
April 6, 201115 yr Well, there is no reason unRAID would write those extra things to the disk. So, I would have to believe that unRAID does not always clear the unused parts of the first 62 or 63 sectors. Now, these new unRAID versions are looking for those parts to be clear and when finding these remenants from other systems unRAID is failing to recognize a valid unRAID disk as being valid. Peter
April 6, 201115 yr While I don't particularly keep track of disks, now that I think about it really hard, the disk came out of a Freecom External Network Drive. As such, it might have had some NAS specific partitions? That could well explain why all that code is in the MBR. I know I would have formatted it with ReiserFS either before or in the UnRaid server. It's also VERY likely that this disk did not go through any unRaid formatting OR the preclear script - I've discovered the joys of that particular process only recently. Which could explain why the MBR was not zeroed out - 'formatting with ReiserFS' would only modify the partition, not the MBR. That's all I know. Maybe as such it's not much help in debugging the unRAID issue? I say again - I don't believe that this is an 'unRAID issue'. I think that the health check on the MBR has been made more rigorous as part of the 63/64 alignment changes and this is causing it to complain about some 'dirty' discs. I think that Tom is trying to determine why some disks are 'dirty' and how widespread the problem may be. Perhaps there is some correlation between early beta adopters and those who are likely to have 'dirty' disks? I will make a further suggestion to Tom on how to resolve this problem: If all disks pass the 'new' test, then just start the array and proceed as normal. If any disks fail the 'new' MBR test and also fail the 'old' MBR test, then treat them as disks which are new to unRAID, and go ahead and format them before starting the array. However, if any disk fails the 'new' test, but passes the 'old' test, then treat it as a 'dirty' unRAID disk, flag it as such, and do not allow the array to start. The user would then have to intervene and decide whether to use preclear or mkmbr. There - solved! In most cases all would be business as usual but, if one of these 'dirty' disks is detected, it will not be modified (formatted) automatically, but left for the user to decide how to resolve. If the user is unsure about what to do they will, hopefully, seek help here in the forum. Of course, it may be simpler, if not so aesthetically pleasing, just to revert to the 'old' test.
April 6, 201115 yr Well, there is no reason unRAID would write those extra things to the disk. So, I would have to believe that unRAID does not always clear the unused parts of the first 62 or 63 sectors. Now, these new unRAID versions are looking for those parts to be clear and when finding these remenants from other systems unRAID is failing to recognize a valid unRAID disk as being valid. Peter unRAID clears data disks, but I'm not so sure it writes the MBR for the cache disk the same way. Perhaps it just partitioned it and ran mkreiserfs on it. Joe L.
April 6, 201115 yr But does unRAID clear a whole data disk or does it create the partition and then just clear the partition? It seems to me that a few cases of disks with leftover bits have appeared which indicates unRAID doesn't clear the whole disk or doesn't always clear the whole disk (by whole disk, I mean also clearing the unused sectors before the partition) if a certain usage was done. What about a parity drive, is it completely cleared before the partition is created? I can see the upgrade and subsequent use of an ex-parity drive as a data drive as being fairly common. Peter
April 6, 201115 yr But does unRAID clear a whole data disk or does it create the partition and then just clear the partition? Peter only lime-tech will know the answer to that one.
April 6, 201115 yr Hmmm, I'm running 5 Beta5, haven't really been following this latest issue. This MBR alignment detection issue, what are the pre-requisites that cause Beta 6 to have issues? 4 out of my 5 data disks are Partition: unknown. Only the latest drive is 4k-aligned. HPA was enabled on my motherboard when I first started off, I'm not sure if it's even turned off now (scoured settings, doesn't appear to have a setting to stop it anyway). i've had no issues in the past with upgrading/replacing drives... Wondering what I should do..
April 6, 201115 yr 4 out of my 5 data disks are Partition: unknown. Only the latest drive is 4k-aligned. Try running the commands on the unknown drives from here and posting the results; http://lime-technology.com/forum/index.php?topic=11540.msg109913#msg109913 Peter
April 6, 201115 yr Cheers - here are the results: SDD - ST31000340AS: 1953523055 1+0 records in 1+0 records out 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000432 00 00 00 00 00 00 00 00 81 db 81 db 00 00 00 00 0000448 00 00 83 00 00 00 3f 00 00 00 30 65 70 74 00 00 0000464 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000496 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa 0000512 SDA - ST31000340AS: 1953525168 1+0 records in 1+0 records out 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000432 00 00 00 00 00 00 00 00 a8 2f 52 92 00 00 00 00 0000448 00 00 83 00 00 00 3f 00 00 00 71 6d 70 74 00 00 0000464 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000496 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa 0000512 SDC - ST31000333AS: 1953525168 1+0 records in 1+0 records out 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000432 00 00 00 00 00 00 00 00 3f 80 47 2e 00 00 00 00 0000448 00 00 83 00 00 00 3f 00 00 00 71 6d 70 74 00 00 0000464 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000496 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa 0000512 SDE - ST31500341AS: 2930275055 1+0 records in 1+0 records out 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000432 00 00 00 00 00 00 00 00 22 80 47 2e 00 00 00 00 0000448 00 00 83 00 00 00 3f 00 00 00 b0 72 a8 ae 00 00 0000464 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000496 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa 0000512
Archived
This topic is now archived and is closed to further replies.