July 10, 201114 yr Under the "Shares" tab in the GUI, is it normal for a share to have a red light beside it? I'm asking because red is used for a disabled disk in the main tab. I don't know about red, but orange indicates that there is data on the cache drive waiting to be written to the array drive. However, if you write a file to a user share, then delete it, the 'light' stays orange until mover is next run.
July 18, 201114 yr is the trust my parity procedure working on this beta ? and how does it work ? still same as underneath Here is a procedure provided by Tom of Lime Technology. Do this only if you know your configuration is completely valid, no disabled or missing disks, all disks correctly assigned, and you are sure that your parity drive is good. The data drives do NOT have to be assigned to the same slots as they were previously. Boot unRAID, but DO NOT START the array. Stop the array if it has started. Make sure that all of your disks are correctly assigned, not disabled or missing. Note: they do not have to be assigned to the same slots they were originally assigned to, except for the Parity drive(!), but it MUST be the same set of drives. Open a console, either at the unRAID server or in a Telnet or PuTTY window. Make sure you are in the home directory, which is /root. If you are unsure, type cd and press the Enter key, and you will be there. If you are running any version of unRAID that is PRIOR to v4.5.4, then at the unRAID Web Management page, click the Restore button, after first checking the "I'm sure I want to do this" box. If you are running unRAID version v4.5.4 or later, then log in as root at your system console or via telnet and type the following command: initconfig If necessary, refresh your unRAID Web Management Main page in your browser. On the unRAID Web Management Main page, this should result in all disk status symbols/balls turning <Blue>. The server status should indicate "Stopped. Initial Configuration". Now at the unRAID console or Telnet or PuTTY prompt, type this command: mdcmd set invalidslot 99 The output of this command should be this: cmdOper=set cmdResult=ok Now click the Start button. All the disk status indicators should turn <Green>; the system state should be Started; and there should be a parity check in progress. You can let the parity check complete, or you can cancel it. In most cases, you should let it finish. If you were correct and parity was valid, the parity check will not find any errors. If you were wrong, then the parity check will find and correct the errors, and report them. By the time the parity check reports on the parity errors, they will have already been corrected.
July 18, 201114 yr I think it was bugged and possibly fixed in the latest version 5.0beta9. It probably will NOT work as before. He recently mentioned that refreshing the browser would negate the effect of the command. http://lime-technology.com/forum/index.php?topic=13866.msg131378#msg131378 Joe L.
July 18, 201114 yr I think it was bugged and possibly fixed in the latest version 5.0beta9. Actually this is a bug in the 5.0 betas (not sure exactly what version it began) but reported fixed in 5.0b8b. See this post from Tom: http://lime-technology.com/forum/index.php?topic=13866.msg131378#msg131378 (Take special note of the requirement to NOT refresh after running the set invalidslot command. Also, in my last testing, I did not see the cmdOper=set cmdResult=ok results. I am not sure if that has been put back in or not, but it may be working even if you do not see that output.)
September 21, 201114 yr Two new features in this beta: 1. Support of hard drives larger than 2TB. Has the mkmbr utility been updated to support hard drives larger than 2TB?
September 22, 201114 yr Two new features in this beta: 1. Support of hard drives larger than 2TB. Has the mkmbr utility been updated to support hard drives larger than 2TB? I don't think it can. Drives larger than 2.2TB do not use an MBR. (they put a protective MBR in place, starting on block 1 and extending for the entire drive, but it is not used)
December 18, 201213 yr root@The-Vault:~# dd if=/dev/sdc count=1 skip=1 of=junk 1+0 records in 1+0 records out 512 bytes (512 B) copied, 3.9666e-05 s, 12.9 MB/s root@The-Vault:~# hexdump -C junk 00000000 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 |EFI PART....\...| 00000010 b4 37 50 65 00 00 00 00 01 00 00 00 00 00 00 00 |.7Pe............| 00000020 af 88 e0 e8 00 00 00 00 22 00 00 00 00 00 00 00 |........".......| 00000030 8e 88 e0 e8 00 00 00 00 af 2b 46 e6 30 83 e0 11 |.........+F.0...| 00000040 b3 c6 00 e0 81 41 ae ca 02 00 00 00 00 00 00 00 |.....A..........| 00000050 80 00 00 00 80 00 00 00 6a d2 c3 64 00 00 00 00 |........j..d....| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 Spot on. Previously these disks were part of an ZFS array in NexentaStor and I don't know what kind of disk label that would write, but it sure looks like it uses GPT. Maybe I should zap those sectors with zeros, to "clean" them up. Cheers, and Thanks. Ok, mystery solved! In unRaid that remnant GPT is harmless; it's up to you if you want to zap it. Probably I would just leave it be same issue here on new 5.0-rc8a AiO out of nothing I get this in my logs: Dec 18 09:53:28 storageserver unmenu[20830]: Dec 18 09:53:28 storageserver unmenu[20830]: WARNING: GPT (GUID Partition Table) detected on '/dev/sdj'! The util fdisk doesn't support GPT. Use GNU Parted. (Minor Issues) Dec 18 09:53:28 storageserver unmenu[20830]: Dec 18 09:53:28 storageserver unmenu[20830]: Dec 18 09:53:28 storageserver unmenu[20830]: WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted. (Minor Issues) Dec 18 09:53:28 storageserver unmenu[20830]: Dec 18 09:53:28 storageserver unmenu[20830]: Dec 18 09:53:28 storageserver unmenu[20830]: WARNING: GPT (GUID Partition Table) detected on '/dev/sdc'! The util fdisk doesn't support GPT. Use GNU Parted. (Minor Issues) Dec 18 09:53:28 storageserver unmenu[20830]: Dec 18 09:53:28 storageserver unmenu[20830]: Dec 18 09:53:28 storageserver unmenu[20830]: WARNING: GPT (GUID Partition Table) detected on '/dev/sdd'! The util fdisk doesn't support GPT. Use GNU Parted. (Minor Issues) Dec 18 09:53:28 storageserver unmenu[20830]: I am using brand new drives which are not precleared, is it normal to get that warning or should I do something about ? best regards Christoph
Archived
This topic is now archived and is closed to further replies.