July 8, 201114 yr Author Thanks Tom, DL right now ;-) any strange in my log file ? //Peter Yes, indication of bug fixed in -beta8b.
July 8, 201114 yr Sorry Tom Beta 8b Jul 8 09:14:55 Tower unmenu[3589]: unmenu.awk unable to open port. It may already be running Jul 8 09:14:58 Tower init: Re-reading inittab Jul 8 09:15:05 Tower unmenu-status: Starting unmenu web-server Jul 8 09:15:09 Tower unmenu[3589]: awk: ./unmenu.awk:1722: fatal: division by zero attempted Jul 8 09:15:09 Tower unmenu-status: Exiting unmenu web-server, exit status code = 2 Jul 8 09:15:09 Tower unmenu[3589]: unmenu.awk unable to open port. It may already be running Jul 8 09:15:15 Tower usermod[8932]: change user 'nobody' shell from '/bin/false' to '/bin/bash' Jul 8 09:15:15 Tower su[8937]: Successful su for nobody by root Jul 8 09:15:15 Tower su[8937]: + /dev/console root:nobody Jul 8 09:15:19 Tower unmenu-status: Starting unmenu web-server Jul 8 09:16:04 Tower unmenu[3589]: awk: ./unmenu.awk:1722: fatal: division by zero attempted Jul 8 09:16:04 Tower unmenu-status: Exiting unmenu web-server, exit status code = 2 Jul 8 09:16:04 Tower unmenu-error: Fatal error:Exiting uu, unmenu may already be running, exit status=2
July 8, 201114 yr Author Sorry Tom Beta 8b Jul 8 09:14:55 Tower unmenu[3589]: unmenu.awk unable to open port. It may already be running Jul 8 09:14:58 Tower init: Re-reading inittab Jul 8 09:15:05 Tower unmenu-status: Starting unmenu web-server Jul 8 09:15:09 Tower unmenu[3589]: awk: ./unmenu.awk:1722: fatal: division by zero attempted Jul 8 09:15:09 Tower unmenu-status: Exiting unmenu web-server, exit status code = 2 Jul 8 09:15:09 Tower unmenu[3589]: unmenu.awk unable to open port. It may already be running Jul 8 09:15:15 Tower usermod[8932]: change user 'nobody' shell from '/bin/false' to '/bin/bash' Jul 8 09:15:15 Tower su[8937]: Successful su for nobody by root Jul 8 09:15:15 Tower su[8937]: + /dev/console root:nobody Jul 8 09:15:19 Tower unmenu-status: Starting unmenu web-server Jul 8 09:16:04 Tower unmenu[3589]: awk: ./unmenu.awk:1722: fatal: division by zero attempted Jul 8 09:16:04 Tower unmenu-status: Exiting unmenu web-server, exit status code = 2 Jul 8 09:16:04 Tower unmenu-error: Fatal error:Exiting uu, unmenu may already be running, exit status=2 Joe L. will have to look at that to say what's wrong.
July 8, 201114 yr Hi! Here unmenu is not working with the latest beta too. I upgraded my current installation of unmenu with "unmenu_install -u". After the update I startet the addon with "uu". When I try to reach unmenu via the browser I get a blank screen (xxx.xxx.x.x:8080). I don't see an error in the syslog. Bye.
July 8, 201114 yr Just went from beta7 to beta8. Works fine except... now the temps don't show for the drives hooked to the motherboard. The temps show fine on the 2 BR10i cards with both betas. Motherboard is a GIGABYTE GA-790XT-USB3. Syslogs from both versions attached. Pick one of your drives hooked to the motherboard and note the device identifier, say it's (sdb). Please type this command, capture output and post: smartctl -A /dev/sdb <--- instead of 'sdb' use whatever one corresponds to drive on motherboard port Tower2 login: root Linux 2.6.37.6-unRAID. root@Tower2:~# smartctl -A /dev/sdb smartctl 5.40 2010-10-16 r3189 [i486-slackware-linux-gnu] (local build) Copyright © 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net SMART Disabled. Use option -s with argument 'on' to enable it. root@Tower2:~# Done what it said.... showing fine now.
July 8, 201114 yr Sorry Tom Beta 8b Jul 8 09:14:55 Tower unmenu[3589]: unmenu.awk unable to open port. It may already be running Jul 8 09:14:58 Tower init: Re-reading inittab Jul 8 09:15:05 Tower unmenu-status: Starting unmenu web-server Jul 8 09:15:09 Tower unmenu[3589]: awk: ./unmenu.awk:1722: fatal: division by zero attempted Jul 8 09:15:09 Tower unmenu-status: Exiting unmenu web-server, exit status code = 2 Jul 8 09:15:09 Tower unmenu[3589]: unmenu.awk unable to open port. It may already be running Jul 8 09:15:15 Tower usermod[8932]: change user 'nobody' shell from '/bin/false' to '/bin/bash' Jul 8 09:15:15 Tower su[8937]: Successful su for nobody by root Jul 8 09:15:15 Tower su[8937]: + /dev/console root:nobody Jul 8 09:15:19 Tower unmenu-status: Starting unmenu web-server Jul 8 09:16:04 Tower unmenu[3589]: awk: ./unmenu.awk:1722: fatal: division by zero attempted Jul 8 09:16:04 Tower unmenu-status: Exiting unmenu web-server, exit status code = 2 Jul 8 09:16:04 Tower unmenu-error: Fatal error:Exiting uu, unmenu may already be running, exit status=2 Joe L. will have to look at that to say what's wrong. The patched version of unmenu is available for install. The basic issue was a line added by bjp999. I modified it very slightly to get past the error, but it will probably need a more correct fix. Odds are it was using a variable from /proc/mdcmd available in the older versions of unRAID, but no longer present. #resync_speed = sprintf("%d", (resync_db+0) / (resync_dt+0)); #bjp999 3/7/11 Change for 5.0b6 resync_speed = sprintf("%d", (resync_db+0) / (resync_dt+0.1)); #Joe L. temp fix for divide by 0 To get the new version, log in via telnet and type: cd /boot/unmenu unmenu_install -u then, you'll probably need to type: killall awk ./uu to start it. The changes in this patched version are backwards compatible with prior 5.X and 4.X versions of unRAID. Joe L.
July 8, 201114 yr I already created a new topic for this, but maybe I'll get the answer more quickly here: -------------------------- Hi all, I just updated my unRAID build from 5b4 to 5b8b, but stupidly forgot to make a screendump of the array/disk configuration, and now it's lost. I know the parity and cache disk, and unRAID seems to recognize one disk. But all other disks show up as new (blue bubble). Is it safe to assign those data disks to new slots and starting the array, without loss of data? Thanks!
July 8, 201114 yr NFS isn't starting correctly at boot. If you check the attached syslog at around 10:00:41, you'll see what I think is where it is going wrong. If you go into the web interface and click Apply, it restarts NFS correctly. syslog.txt
July 8, 201114 yr I already created a new topic for this, but maybe I'll get the answer more quickly here: -------------------------- Hi all, I just updated my unRAID build from 5b4 to 5b8b, but stupidly forgot to make a screendump of the array/disk configuration, and now it's lost. I know the parity and cache disk, and unRAID seems to recognize one disk. But all other disks show up as new (blue bubble). Is it safe to assign those data disks to new slots and starting the array, without loss of data? Thanks! Hmmm ... Normally unRAID will be displaying the disks it expects to be in the slot in italics and expecting you to assign that disk to that slot. Is that what you are seeing? It won't let you just assign disks to blank slots, unless you did an initconfig, in which case you'll be defining a new array and rebuilding parity. You shouldn't have to do that to update. A screenshot of what you are seeing might be helpful to answer your question.
July 8, 201114 yr I already created a new topic for this, but maybe I'll get the answer more quickly here: -------------------------- Hi all, I just updated my unRAID build from 5b4 to 5b8b, but stupidly forgot to make a screendump of the array/disk configuration, and now it's lost. I know the parity and cache disk, and unRAID seems to recognize one disk. But all other disks show up as new (blue bubble). Is it safe to assign those data disks to new slots and starting the array, without loss of data? Thanks! Hmmm ... Normally unRAID will be displaying the disks it expects to be in the slot in italics and expecting you to assign that disk to that slot. Is that what you are seeing? It won't let you just assign disks to blank slots, unless you did an initconfig, in which case you'll be defining a new array and rebuilding parity. You shouldn't have to do that to update. A screenshot of what you are seeing might be helpful to answer your question. This was the case for just one data disk (+ parity and cache), the others are shown as new.
July 8, 201114 yr This was the case for just one data disk (+ parity and cache), the others are shown as new. Be very careful. If they are considered "new", unRAID may want to zero them out!
July 8, 201114 yr This was the case for just one data disk (+ parity and cache), the others are shown as new. Be very careful. If they are considered "new", unRAID may want to zero them out! It's like this: And after I assigned the italic slot:
July 8, 201114 yr Have updated from beta7 to beta8b and now cannot access any of my nfs shares (from an Ubuntu client, using autofs). I can post the whole unRAID syslog, but I can see significant differences between beta7 and beta8. In beta7, it appears that SMB and NFS were started, stopped and started again. In beta8, SMB and NFS are started and restarted without a stop. On the restart in beta8, I see the following in the syslog: Jul 8 21:18:39 Tower exportfs[8016]: /proc/fs/nfs/exports:1: unknown keyword "test-client-(rw" Jul 8 21:18:39 Tower logger: exportfs: /proc/fs/nfs/exports:1: unknown keyword "test-client-(rw" Jul 8 21:18:39 Tower logger: I'm not sure whether the unknown keyword is significant.
July 8, 201114 yr You should definitely capture and post a syslog. That is first step. Describe any steps you took doing the upgrade (did you delete any files on the config directory?) Did you make a backup of your flash config directory before updating? If so, you might want to restore it and downgrade to your prior version and see if the array is "whole" there. If you can, don't start the array and wait for Tom to respond. He may have some commands or information he needs from you. If you add your other disks to the array as new disks and start the array, unRAID will go into a long "zero them out" process and array will be offline. You definitely don't want to do that. You could try the "trust" procedure to put the array back together. Look it up in the Wiki. It is supposedly fixed in this version, but not 100% sure. It is not showing in the release notes. The other option, if you can't wait, it to run initconfig and redefine the array. You will be without parity protection until parity is rebuilt.
July 8, 201114 yr NFS isn't starting correctly at boot. If you check the attached syslog at around 10:00:41, you'll see what I think is where it is going wrong. If you go into the web interface and click Apply, it restarts NFS correctly. Ah, it appear that the nfs startup processing used at boot time has been altered, while the processing following configuration change remains as before.
July 8, 201114 yr You should definitely capture and post a syslog. That is first step. Describe any steps you took doing the upgrade (did you delete any files on the config directory?) Did you make a backup of your flash config directory before updating? If so, you might want to restore it and downgrade to your prior version and see if the array is "whole" there. If you can, don't start the array and wait for Tom to respond. He may have some commands or information he needs from you. If you add your other disks to the array as new disks and start the array, unRAID will go into a long "zero them out" process and array will be offline. You definitely don't want to do that. You could try the "trust" procedure to put the array back together. Look it up in the Wiki. It is supposedly fixed in this version, but not 100% sure. It is not showing in the release notes. The other option, if you can't wait, it to run initconfig and redefine the array. You will be without parity protection until parity is rebuilt. All I did was replace the bzroot and bzimage files. If only I shoulda... I don't mind rebuilding parity, but this is a good reminder to not be so quick and stupid with upgrading. I'll try and downgrade first to b4, see if the config is valid again.
July 8, 201114 yr All I did was replace the bzroot and bzimage files. If only I shoulda... I don't mind rebuilding parity, but this is a good reminder to not be so quick and stupid with upgrading. I'll try and downgrade first to b4, see if the config is valid again POST SYSLOG FIRST! Let me know if you need directions.
July 8, 201114 yr All I did was replace the bzroot and bzimage files. If only I shoulda... I don't mind rebuilding parity, but this is a good reminder to not be so quick and stupid with upgrading. I'll try and downgrade first to b4, see if the config is valid again POST SYSLOG FIRST! Let me know if you need directions. There you go!
July 8, 201114 yr Author The patched version of unmenu is available for install. The basic issue was a line added by bjp999. I modified it very slightly to get past the error, but it will probably need a more correct fix. Odds are it was using a variable from /proc/mdcmd available in the older versions of unRAID, but no longer present. #resync_speed = sprintf("%d", (resync_db+0) / (resync_dt+0)); #bjp999 3/7/11 Change for 5.0b6 resync_speed = sprintf("%d", (resync_db+0) / (resync_dt+0.1)); #Joe L. temp fix for divide by 0 Here are the vars having to do with "re-sync" (ie, parity check/reconstruct) available from driver: mdResync - 0 if no resync in process, else size of resync (in 1024-byte blocks) mdResyncCorr - 0 if not correcting, 1 if correcting (applies only to parity check) mdResyncPos - current resync block position mdResyncDt - "delta time" in seconds mdResyncDB - "delta blocks", ie, number of blocks re-sync'ed during last "delta time" seconds Prior to -beta8, the bolded vars above were not output if there was no resync in process. Now they are always output, but set to 0 if resync is not in process. Must be this new behavior causing unmenu crash?
July 8, 201114 yr Upgraded from 5b7 to 5b8b - no issues - everything up and running fine so far. Shawn
July 8, 201114 yr Must be this new behavior causing unmenu crash? ... in which case, the appropriate modification would be to change the line: if(resync_dt != "") { to: if(resync_dt+0 > 0) { This should work for both old and new circumstances.
July 8, 201114 yr The patched version of unmenu is available for install. The basic issue was a line added by bjp999. I modified it very slightly to get past the error, but it will probably need a more correct fix. Odds are it was using a variable from /proc/mdcmd available in the older versions of unRAID, but no longer present. #resync_speed = sprintf("%d", (resync_db+0) / (resync_dt+0)); #bjp999 3/7/11 Change for 5.0b6 resync_speed = sprintf("%d", (resync_db+0) / (resync_dt+0.1)); #Joe L. temp fix for divide by 0 Here are the vars having to do with "re-sync" (ie, parity check/reconstruct) available from driver: mdResync - 0 if no resync in process, else size of resync (in 1024-byte blocks) mdResyncCorr - 0 if not correcting, 1 if correcting (applies only to parity check) mdResyncPos - current resync block position mdResyncDt - "delta time" in seconds mdResyncDB - "delta blocks", ie, number of blocks re-sync'ed during last "delta time" seconds Prior to -beta8, the bolded vars above were not output if there was no resync in process. Now they are always output, but set to 0 if resync is not in process. Must be this new behavior causing unmenu crash? Yep, that was it. The fix Joe L. made should have a very negligible affect on the speed calculation. But a slightly better fix would be to change the if statement a few lines up from ... if(mdResyncDt != "") { to if((mdResyncDt+0) > 0) { This same change needs to be made to the unmenu.base.lib.awk around line 95. Update: Ha Ha! Just see PeterB making same suggestion.
July 8, 201114 yr Author All I did was replace the bzroot and bzimage files. If only I shoulda... I don't mind rebuilding parity, but this is a good reminder to not be so quick and stupid with upgrading. I'll try and downgrade first to b4, see if the config is valid again POST SYSLOG FIRST! Let me know if you need directions. There you go! If you've lost your disk configuration, safest way to proceed is as follows: 1. Go to Utils and click 'New config'. Check the 'Yes I want to do this' box, then click Apply. 2. Go to Main and start assigning your drives. Do not assign Parity. Whichever drive you think is Parity, just don't assign. 3. Now you have all your data disks and cache disk assigned, and they all have a blue dot - that's ok (and Parity is set to "unassigned"). Click Start and array will start and attempt to mount all the data drives. 4. If any disk did not mount (that is, appears 'unformatted'), well you have a problem: perhaps that is the actual parity disk? 5. You can spot check the files on the disks to assure yourself everything looks good. 6. Now Stop array and assign your Parity disk. 7. Click Start and you should see a parity sync start up. Variations on the theme: a) Suppose you don't know which physical disk is Parity? In this case assign all your hard drives to data disk slots (do NOT assign a Parity disk). Click Start and the one that comes up 'unformatted' is your parity disk (now you know which one it is). Repeat steps above except at step 3 now you know which is Parity so go ahead and assign it. b) Suppose you lost the config, but you know that Parity is valid, so you want to skip the lengthy re-sync. In this case, once you know which disk is Parity, and you have it and all other disks assigned, just prior to clicking the 'Start' button you can type this command in a telnet window: mdcmd set invalidslot 99 Now click Start (don't do a refresh between typing this command clicking Start or else command will have no effect). What this does is tell the driver that none of the array drives are invalid, and hence won't start a sync (normally Parity is marked invalid when there's been a "New Config"). Make sense?
July 8, 201114 yr But a slightly better fix would be to change the if statement a few lines up from ... if(mdResyncDt != "") { to if((mdResyncDt+0) > 0) { This same change needs to be made to the unmenu.base.lib.awk around line 95. As a matter of interest, is the extra pair of braces necessary, or have you used them simply for clarity? Update: Ha Ha! Just see PeterB making same suggestion. Great minds .....!
Archived
This topic is now archived and is closed to further replies.