December 18, 200916 yr The rebuild completed successfully. No errors at all. The drive now shows that the total size of the drive is the same as the other 1 TB drives so the HPA bios area must have been removed. As you upgrade in the future, keep aware that some future kernel might be released where the HPA is not unlocked. You'll know... that's for sure, for all of a sudden the drive will look smaller once more. (It is nice that the kernel is unlocking the HPA, but on some servers (other than unRAID) it might make for some interesting breakage. You'll know for sure if it is gone when you power cycle the server and the BIOS get to attempt to put an HPA in place once more.
December 18, 200916 yr I upgraded my Unraid to the 4.5 final. I was on 4.5 beta6. When I restarted the machine, the array did not restart automatically. So I went to the web page and it said upgraded disk. I started the array and it is rebuilding my disk1 drive in the array. I did not make any hardware changes. Can someone tell me why it would do this? A very interesting action took place here, that caused a resize of your Disk 1, which resulted in the disk being inconsistent with the disk config in unRAID, caused a rewrite of the MBR, then a rebuild of the disk, which was perhaps unnecessary. Your Disk 1 had a Gigabyte HPA installed, and is connected to the first SATA port on the motherboard. No other drives have HPA's. Here are the relevant lines: Dec 17 16:36:25 Tower kernel: ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Dec 17 16:36:25 Tower kernel: ata7.00: HPA unlocked: 1953523055 -> 1953525168, native 1953525168 Dec 17 16:36:25 Tower kernel: ata7.00: ATA-8: WDC WD10EADS-00M2B0, 01.00A01, max UDMA/133 Dec 17 16:36:25 Tower kernel: md: import disk1: [8,96] (sdg) WDC WD10EADS-00M2B0 WD-WMAV50195436 offset: 63 size: 976762552 Dec 17 16:36:25 Tower kernel: md: disk1 wrong Dec 17 16:37:16 Tower emhttp: writing mbr on disk 1 (/dev/sdg) Dec 17 16:37:16 Tower emhttp: re-reading /dev/sdg partition table Dec 17 16:37:16 Tower kernel: sdg: sdg1 Dec 17 16:37:17 Tower kernel: mdcmd (31): start UPGRADE_DISK Dec 17 16:37:17 Tower kernel: md: recovery thread rebuilding disk1 ... Dec 17 16:37:19 Tower emhttp: resized: /mnt/disk1 There is some concern here, because we really don't know yet what actually happened, and therefore don't know yet what will happen when this rebuild reaches the last megabyte of this drive. If the size change is artificial, that is, the kernel is saying that this *should* be the true size, but the hard drive firmware has not truly removed the HPA, then there are going to be drive errors at the end of the rebuild, when the drive refuses writes to that area. If this latest kernel now includes logic to actually remove the HPA *AND* make the Gigabyte board turn off this "BIOS backup in an HPA" feature, then this is a great new feature of the kernel, and the rebuild should write zeroes into that area, clearing it. I have to wonder though if this is going to stop the Gigabyte BIOS from trying to create an HPA again on the *next* boot. It will be good to hear from other Gigabyte board owners with HPA's. What is especially interesting here, is what happens at the end of this drive, and what happens on the next boot. There is another possibility, did you perhaps find a BIOS setting that disabled this feature, and just changed it now? Perhaps the new kernel detects that and tries to recover the space. Just to be clear, there is and was nothing wrong with the drive, but the kernel has attempted to remove the HPA, which changes the size of the drive, and that makes unRAID think the drive has changed. I feel I need to caution you here, as to the action you took, especially so quickly. Any time that the Web Management indicates an action or status of a drive that is not in accord with our understanding of that drive, you really should step back and try to find out what happened first, before proceeding. When it said that the drive needed to be rebuilt, this in effect was similar to it saying that the drive needs formatting, and you would not want to proceed very quickly if you unexpectedly saw that message. A request to rebuild is effectively asking to completely overwrite a drive, in effect losing everything that was stored there (although we hope it will overwrite with what is already there). The first step to take is to check the Device assignments, to make sure that the new kernel has not changed the order of drive detection, and now a different drive is assigned there. I don't think we have had a catastrophic case like that yet, rather, device changes have simply resulted in unassigned drives, but still if the parity drive had somehow been assigned now as Disk 1, it could have resulted in the complete loss of Disk 1. I would want to make absolutely sure that the Disk 1 I will overwrite with the contents of Disk 1, is really the correct drive and serial number. After that, I would want some idea of why it is trying to overwrite this disk. It could be valid, or not, and I would very much want to know if it should not be overwritten/rebuilt. In this case, after verifying the drive assignments, all you needed to do was run the Trust My Array procedure. It would have reported a number of parity errors at the very end of the drive, but that is expected. Being a Linux n00b, don't know whether this affects the unRaid kernel: Kernel Bug - Do NOT disable HPA by default -> leads to data loss https://bugs.launchpad.net/ubuntu/+source/linux/+bug/380138
December 18, 200916 yr The rebuild completed successfully. No errors at all. The drive now shows that the total size of the drive is the same as the other 1 TB drives so the HPA bios area must have been removed. It will be interesting to see what happens from here. If the Gigabyte BIOS tries to put it back on the drive or not. Since it does not seem to affect the operation of unRAID in any way (other than causing a parity sync) I vote that this little HPA unlock be left turned on in the unRAID kernel. From reading the comments in the link above there is some work that has been done/might be done to turn this on or off as the user likes. 1.5MB is not a lot of space but frankly I don't want anything at the end of my drive unless I tell it to be put there myself.
December 18, 200916 yr It's not good if the HPA is added to the patity drive ,I have that case when setting up unRID in the first place.
December 18, 200916 yr The rebuild completed successfully. No errors at all. The drive now shows that the total size of the drive is the same as the other 1 TB drives so the HPA bios area must have been removed. It will be interesting to see what happens from here. If the Gigabyte BIOS tries to put it back on the drive or not. Since it does not seem to affect the operation of unRAID in any way (other than causing a parity sync) I vote that this little HPA unlock be left turned on in the unRAID kernel. From reading the comments in the link above there is some work that has been done/might be done to turn this on or off as the user likes. 1.5MB is not a lot of space but frankly I don't want anything at the end of my drive unless I tell it to be put there myself. The real danger is if the BIOS decides to put the HPA on the parity drive now that it does not detect one on the data drive. If it does, then the parity drive will no longer be as big or bigger than than the data drive and the array will not start. Now, by itself it will not clobber any data, but IF the power cycle and reboot was because you were trying to replace a failed drive, then having TWO disks that are not valid (one the wrong size, the other failed) you can lose data if you do not proceed carefully. To be absolutely sure what will happen the next time you power cycle you need to do it NOW, before a failure occurs and the HPA causes you all kinds of headaches in trying to recover. So... Stop the array, power down, power back up, and hope/pray the HPS does not get re-added to any disk. (The array will not start if it does) Please post another syslog, regardless of if it adds an HPA again, or not. Joe L.
December 18, 200916 yr Tom, first of all, thank you very much for your continous and great efforts! I have two questions/comment in regards to logging: 1. Authenticated mount requests for NFS shares geting logged. Is this on purpose? Syslog seems very spammed by this. 2. It seems that folders on the cache drive begining with "." are geting logged during mover operation (they are not moved, but logged). That was an issue with 4.4.2, but I've used the mover script from one of the 4.5 betas, as per Joe.L suggested and it was OK. Is this little bug reintroduced at some point? Anyone please with a feedback on this? I've also tried disabling mover logging on the GUI, but after I choosed disabled and clicked on apply, it went back to enabled.
December 18, 200916 yr I understand this is not an HPA thread, but I wanted to chime in with my experiences. I use a Gigabyte P965-DS3 motherboard and I had HPA on 4 of my 6 disks when I first started with unRAID, one of which was the parity drive. Before I put them into the array, I used a utility Joe L. pointed me to, which removed HPA from all drives one at a time. I have been up and running for over 8 months on unRAID through several different versions, numerous reboots, and even a full reset of all BIOS settings and have never seen HPA reappear on these drives.
December 18, 200916 yr ... Any time that the Web Management indicates an action or status of a drive that is not in accord with your understanding of that drive, you really should step back and try to find out what happened first, before proceeding. When it said that the drive needed to be rebuilt, this in effect was similar to it saying that the drive needs formatting, and you would not want to proceed very quickly if you unexpectedly saw that message. ... The first step to take is to check the Device assignments, to make sure that [something] has not changed the order of drive detection ... had the parity drive somehow been assigned now as Disk 1, it could have resulted in the complete loss of Disk 1. ... Thought this was worth repeating. Anyone that uses unRAID needs to understand this.
December 18, 200916 yr Why have I this line in my syslog, it's the last line after a boot Tower unmenu[1403]: ls: cannot access /boot/custom/etc/rc.d/*: No such file or directory An I also notice the messages : Tower kernel: Hangcheck: hangcheck value past margin! This messages can be found are in the largest syslog file I don't hope there are more strange thing in my syslog, I would be glad if some could look in to this files. Have a nice day Peter
December 18, 200916 yr Why have I this line in my syslog, it's the last line after a boot Tower unmenu[1403]: ls: cannot access /boot/custom/etc/rc.d/*: No such file or directory The second one I can't answer but this one can point you in the right direction. Check out the Third Party Boot Flash Plugin Architecture. Unmenu is looking for that structure and not finding it and therefore telling you about it.
December 18, 200916 yr Why have I this line in my syslog, it's the last line after a boot Tower unmenu[1403]: ls: cannot access /boot/custom/etc/rc.d/*: No such file or directory The second one I can't answer but this one can point you in the right direction. Check out the Third Party Boot Flash Plugin Architecture. Unmenu is looking for that structure and not finding it and therefore telling you about it. Thanks, I have created those directory now
December 18, 200916 yr Why have I this line in my syslog, it's the last line after a boot Tower unmenu[1403]: ls: cannot access /boot/custom/etc/rc.d/*: No such file or directory The second one I can't answer but this one can point you in the right direction. Check out the Third Party Boot Flash Plugin Architecture. Unmenu is looking for that structure and not finding it and therefore telling you about it. Thanks, I have created those directory now Unless you have the files in that directory for the unMENU package manager to use, you will find that you creating the directory will only confuse it. the package manager will add a task there IF it exists instead of appending a line to the "go" script when you request a package be re-installed on re-boot. However, it EXPECTS that the scripts there are being invoked. Since all you have is an empty directory, it will only break things. For your own sake, please remove the directory you just created. (Unless you installed the full set of utilities that process scripts in it) Even if you just installed a full set of files, it will ALL CHANGE in version 5.0 of unRAID. So anything you put there now will need to be changed soon. Just ignore the message from unmenu... and post other questions about it in the unMENU thread, not the 4.5 thread, since it has nothing to do with the new release. As far as the second message, it is a Linux kernel message. I had to google it myself. http://www.lubby.org/stable/index.php?page=Databases.result2&ArticleID=77 About all you can do is look for a BIOS update for your motherboard.
December 18, 200916 yr The rebuild completed successfully. No errors at all. The drive now shows that the total size of the drive is the same as the other 1 TB drives so the HPA bios area must have been removed. Unfortunately, you are not out of the woods yet. What the others have said is VERY important here. I strongly recommend you shut down and reboot, then monitor for errors, and check the syslog (and post it for us as requested above) to see if a new HPA has been unlocked. That is what I'm afraid may happen, that the Gigabyte board will have created a new one (on the same drive or a different one), but you may or may not be aware of it immediately, until you run a parity check that turns up a number of parity errors at the very end of the drive. When it creates an HPA, it is not just reserving space, but it is clobbering it, writing a copy of the BIOS into that space. That means parity will be wrong there, and *any* data drive that has to be rebuilt subsequently, will be corrupted in the last megabyte. The last meg of today's huge drives does not seem very important, but I believe that it is possible for ReiserFS to store file system structures there. At least it seemed that way recently in one case, where a just installed Gigabyte HPA appeared to result in corrupted Reiser file system errors. At this point, I don't think it is safe to allow the kernel to unlock any HPA it finds. It will only be safe when you find a way to 'convince' the Gigabyte board not to create another HPA, ever.
December 18, 200916 yr Tower kernel: Hangcheck: hangcheck value past margin! This messages can be found are in the largest syslog file I don't think this should really be in the v4.5 release announcement thread. It would be better to start new threads in the v4.4 forum, for all general support issues involving the use of v4.4 or v4.5 including all of their betas. I realize it is hard to know sometimes what is the appropriate forum. This hangcheck message seems to be somewhat common in syslogs right after awaking from S3 sleep, as it was in yours. It is one of a number of less-than-reassuring messages I have noticed on awaking. I suppose if the system seems to work fine, then that is the best you can expect, no matter what strange and worrisome messages appear.
December 18, 200916 yr Hi, I found also a strange mentioning about this HPA handling in the syslog - it wastn't there before, although I am not 100% sure if it came after upgrading to 4.5 final or BIOS upgradeing the board. THis is only appearing on one controllerport and not at all on my other machine. So my questions: - Is this something to worry about? - Is there something I can do to make it disappear. After reading about the danger coming from those changes to the disk, I'd like to be on the safe side. Thanks. Dec 18 03:39:10 XMS-GMI-02 kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 0) Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.15: Port Multiplier 1.1, 0x1095:0x3726 r23, 6 ports, feat 0x1/0x9 Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.00: hard resetting link Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.00: SATA link up 3.0 Gbps (SStatus 123 SControl 320) Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.01: hard resetting link Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.02: hard resetting link Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.03: hard resetting link Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.04: hard resetting link Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.04: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.05: hard resetting link Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.05: SATA link up 1.5 Gbps (SStatus 113 SControl 320) Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.00: ATA-8: WDC WD10EACS-00ZJB0, 01.01B01, max UDMA/133 Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 31/32) Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.00: configured for UDMA/100 Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.01: qc timeout (cmd 0x27) Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.01: failed to read native max address (err_mask=0x4) Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.01: HPA support seems broken, skipping HPA handling
December 18, 200916 yr Hi, I found also a strange mentioning about this HPA handling in the syslog - it wastn't there before, although I am not 100% sure if it came after upgrading to 4.5 final or BIOS upgradeing the board. Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.01: failed to read native max address (err_mask=0x4) Dec 18 03:39:10 XMS-GMI-02 kernel: ata2.01: HPA support seems broken, skipping HPA handling I have seen this several times before, in different kernel releases (I think), and it has always appeared harmless. I think certain disk controllers are not passing the low level "read native max address" command along, so the driver cannot detect whether there is an HPA or not, and quits trying to do anything related to an HPA. That is probably a good thing!
December 19, 200916 yr Tom, first of all, thank you very much for your continous and great efforts! I have two questions/comment in regards to logging: 1. Authenticated mount requests for NFS shares geting logged. Is this on purpose? Syslog seems very spammed by this. 2. It seems that folders on the cache drive begining with "." are geting logged during mover operation (they are not moved, but logged). That was an issue with 4.4.2, but I've used the mover script from one of the 4.5 betas, as per Joe.L suggested and it was OK. Is this little bug reintroduced at some point? Anyone please with a feedback on this? I've also tried disabling mover logging on the GUI, but after I choosed disabled and clicked on apply, it went back to enabled. OK, I moved back the old mover script to test. The loging issue has gone, but it seems that older mover script is not 100% compatible with the 4.5 final any more: I get "shfs_setxattr: setxattr: /mnt/disk5/anyfilename (95) Operation not supported" log entry now for all the files moved. So it definitely means that the mover script in 4.5 final is loging the dirs begining with "." and it can't be turned off in the GUI either, because the toggle switch for loging is not working. It doesn't seem a huge issue, but my problem with that is I have vmware installed on the cache drive and all the 100s of files of it gets logged every time the mover runs. This way the syslog gets bloated very quickly.
December 19, 200916 yr Since the LimeTech downloads page is temporarily down, due to bandwidth exceeded, you can still use the Torrent link here, or the MediaFire link below: http://linuxtracker.org/index.php?page=torrent-details&id=b1a968ee3226f902cb1f8d4b2b4fd5e43aa7e26f Here is an alternative link for unRAID v4.5 Final, courtesy of MediaFire. unRAID Server 4.5.zip MD5 : B01396E2249251400E045F0678CF9504 unRAID Server 4.5.zip Edit: As has been advised elsewhere, caution is necessary when using free file sharing sites, such as RapidShare and MediaFire. The MD5 is provided above, so that you can verify that you have received an unaltered copy of unRAID Server 4.5.zip.
December 19, 200916 yr OK I restarted the UNRAID server and everything came up and started fine. Here is my syslog
December 19, 200916 yr OK I restarted the UNRAID server and everything came up and started fine. This is what I was afraid would happen, everything appears to be fine to the user, but the syslog shows that Gigabyte has again carved out that same HPA and probably clobbered that area, and then the kernel has again unlocked it, making it look like the full size that unRAID thinks it should be. Do NOT run a normal parity check, run only the read-only parity check. I'm out of time at the moment, but in the FAQ is a way to run a read-only parity check, and I'm rather sure that you will have a cluster of parity errors at the very end of the drive, proving that the area has been clobbered.
December 19, 200916 yr OK I am really regretting upgrading from 4.5 beta 6. I should have just stayed there. Is there a permanent fix for this? I would like it back the way it was. I hope this can be fixed permanently. Can i just go back to 4.5 beta 6? The way it was before the bios backup was on my disk1 which is my backup disk and I was just fine having it there.
December 20, 200916 yr /Hijack=on For those with HPA woes, you should be addressing these issues to Gigabyte. HPA is a good idea but not being able to disable this feature is what is causing these issues not unraid or the linux kernel. What unraid users really want is a HPA disable option in your bios. So if you have HPA related issues please speak to Gigabyte and let them know it is causing you grief and you want an option to disable it. /Hijack=off
December 20, 200916 yr Hey All, I have a pretty stable 4.3.3 final setup with 14 disks and just upgrade two 2TB parity yesterday, there are a few things I would like from 4.5, Is there anything I should do or be prepared for in advance of upgrading. Thanks, Dave
December 20, 200916 yr /Hijack=on For those with HPA woes, you should be addressing these issues to Gigabyte. HPA is a good idea but not being able to disable this feature is what is causing these issues not unraid or the linux kernel. What unraid users really want is a HPA disable option in your bios. So if you have HPA related issues please speak to Gigabyte and let them know it is causing you grief and you want an option to disable it. /Hijack=off The latest BIOS for my MB have this option now to enable/disable this This function was not on the BIOS that was on the MB when I bought it.
December 20, 200916 yr The problem I have is with 4.5 beta 6 the HPA was there and I could live with it. When I upgraded to 4.5 final then things started messing up. I just want to know if I just go back to 4.5 beta 6 because it worked and existed with the HPA just fine for the past 6 or more months. I would like to have UNRAID just ignore the HPA and leave it as is, or at least have the option to do so.
Archived
This topic is now archived and is closed to further replies.