unMENU 1.5 ... now available for download.

[Joe L.]

Here  you go..

 

-rwxrwxrwx 1 root root 2545 2008-10-13 17:55 /boot/packages/10-unmenu-package.conf*

-rwxrwxrwx 1 root root 1487 2008-10-13 20:41 /boot/packages/100-unmenu-apcupsd-package.conf*

-rwxrwxrwx 1 root root 1699 2008-10-13 17:44 /boot/packages/20-unmenu-package.conf*

-rwxrwxrwx 1 root root 2278 2008-10-13 10:31 /boot/packages/200-unmenu-package.conf*

 

Solved...  fixed version will be downloaded if you  "Check for updates"

 

The issue was the 4 package files I highlighted in RED above.

 

You've been using unMENU's package manager for a long time, haven't you.  The original set of files had leading numbers.  I replaced those a long time ago with ones without leading numbers.  It is not so much the naming convention but that the original files had more than one downloadable-package defined in a single file.   The "save-edits" code was expecting a 1-to-1 correspondence between the  packages and the files, in other words, it expected the Nth file to have the Nth package.  Since you had those old files, the Nth file actually had the N+2th package once you got past the first few files.   The effect was it was trying to edit the wrong file.

 

I did not see the error here since none of my package.conf files are the older ones where multiple packages were defined.  (They became too much  of a problem when only one of the links had to be modified, so I adopted one package per file thereafter as a convention)

 

I fixed the code to not rely on the 1-to-1 correspondence of packages to files, so the fixed version should now work for you, but you should remove the few packages listed below as they are no longer needed (and the download links in them so old as to not work anyway)

 

Delete these files:

/boot/packages/10-unmenu-package.conf

/boot/packages/100-unmenu-apcupsd-package.conf

/boot/packages/20-unmenu-package.conf

/boot/packages/200-unmenu-package.conf

 

If you had not had those files, everything would have worked as it does here.  

Since you did have those files, you helped find a bug in my logic.

 

Thanks.  Let me know how it works once you get the updated version, even before you delete those files.  Then, delete those files with the leading numbers.

 

Joe L.

 

[dertbv]

You Rock!

Yes I have been using it a long time, Mostly hand loaded what I wanted to run.  but really just started playing with the package manager I love the work you have done and look forward to playing with any new additions that you add.

 

Thanks

Here  you go..

 

-rwxrwxrwx 1 root root 2545 2008-10-13 17:55 /boot/packages/10-unmenu-package.conf*

-rwxrwxrwx 1 root root 1487 2008-10-13 20:41 /boot/packages/100-unmenu-apcupsd-package.conf*

-rwxrwxrwx 1 root root 1699 2008-10-13 17:44 /boot/packages/20-unmenu-package.conf*

-rwxrwxrwx 1 root root 2278 2008-10-13 10:31 /boot/packages/200-unmenu-package.conf*

 

Solved...  fixed version will be downloaded if you  "Check for updates"

 

The issue was the 4 package files I highlighted in RED above.

 

You've been using unMENU's package manager for a long time, haven't you.  The original set of files had leading numbers.  I replaced those a long time ago with ones without leading numbers.  It is not so much the naming convention but that the original files had more than one downloadable-package defined in a single file.   The "save-edits" code was expecting a 1-to-1 correspondence between the  packages and the files, in other words, it expected the Nth file to have the Nth package.  Since you had those old files, the Nth file actually had the N+2th package once you got past the first few files.   The effect was it was trying to edit the wrong file.

 

I did not see the error here since none of my package.conf files are the older ones where multiple packages were defined.  (They became too much  of a problem when only one of the links had to be modified, so I adopted one package per file thereafter as a convention)

 

I fixed the code to not rely on the 1-to-1 correspondence of packages to files, so the fixed version should now work for you, but you should remove the few packages listed below as they are no longer needed (and the download links in them so old as to not work anyway)

 

Delete these files:

/boot/packages/10-unmenu-package.conf

/boot/packages/100-unmenu-apcupsd-package.conf

/boot/packages/20-unmenu-package.conf

/boot/packages/200-unmenu-package.conf

 

If you had not had those files, everything would have worked as it does here.  

Since you did have those files, you helped find a bug in my logic.

 

Thanks.  Let me know how it works once you get the updated version, even before you delete those files.  Then, delete those files with the leading numbers.

 

Joe L.

 

[rd_blair]

Hi Joe L.

 

Thanks for all your hard work on a great project. Ran into this on the Ruby install package:

 

PACKAGE_EXTRA_URL http://rubyforge.org/frs/download.php/60718/rubygems-1.3.5.tgz

 

downloads rubygems-1.3.5.gz  (md5sum 6e317335898e73beab15623cdd5f8cff)

 

I have learned a lot reading your code. Still helpless but starting to get it. Any thouhts on guides to learn more. Sorry if this is off topic?

[Joe L.]

Hi Joe L.

 

Thanks for all your hard work on a great project. Ran into this on the Ruby install package:

 

PACKAGE_EXTRA_URL http://rubyforge.org/frs/download.php/60718/rubygems-1.3.5.tgz

 

downloads rubygems-1.3.5.gz   (md5sum 6e317335898e73beab15623cdd5f8cff)

Not too sure why you ended up with a .gz extension, but you did end up showing me where a bug has existed in the package manager from the very beginning involving re-directs of URL's when performing the "GET" of a file.  I'm working on the fix, and have it figured out (I think) but want to improve the error handling when an URL on an Additional-Package is no longer valid. 

 

As soon as I get that in place, I'll have a new version of the package manager available.  Would you believe an entire function was missing causing it to crash if it got to that part of the logic.  It never got there because of the lack of the proper error handling, so I never noticed, and it never crashed that way in all my previous testing.

I have learned a lot reading your code. Still helpless but starting to get it. Any thoughts on guides to learn more. Sorry if this is off topic?

I learn a lot from reading my code too.  ;D  I put the comments there so I can remember what I did years later (sometimes, only days later)

 

Joe L.

[Joe L.]

Hi Joe L.

 

Thanks for all your hard work on a great project. Ran into this on the Ruby install package:

 

PACKAGE_EXTRA_URL http://rubyforge.org/frs/download.php/60718/rubygems-1.3.5.tgz

 

downloads rubygems-1.3.5.gz   (md5sum 6e317335898e73beab15623cdd5f8cff)

I just uploaded to google.code a new version of the package-manager plug-in file 990-unmenu-wget.awk.

The download request for rubygems was getting an http 302 re-direction response.  The code did not handle the re-direction to the alternate URL properly.

 

Use the "Check for Updates" button on the User-scripts page to get the newly fixed version.   It should now be able to handle the download of RubyGems.

 

At the same time, I enhanced the error reporting and improved the logic so it would not download a file if it already existed with the correct md5 checksum as a result of the download of a different package.

 

Joe L.

[starcat]

I would suggest having a "Remove forever" button next to each package in unMenu Package Manager as there are package I don't want to use at all, or bothered with, or are unrelated to the newest version I am using. They may appear on a separate page "Suppressed Package" and re-enabled again for unMenu to display.

 

 

[Joe L.]

I would suggest having a "Remove forever" button next to each package in unMenu Package Manager as there are package I don't want to use at all, or bothered with, or are unrelated to the newest version I am using. They may appear on a separate page "Suppressed Package" and re-enabled again for unMenu to display.

I like the idea. 

 

I've been thinking of how to add a few "buttons" at the top of the package manager.  I was thinking of one for installed packages only, and another to only show packages configured to install-on-reboot.  Your idea of suppressing packages is perhaps the opposite of one I was considering, one to select from a list of un-installed packages to enable one for download/installation.  The big difference is that if we ever get 1000 packages it is a lot easier to enable the handful you desire rather than disable the 995 you wish to suppress.  Of course, by the time we get to 1000 packages it will be nearly impossible to show full descriptions of all of them in a single listing... even one line per would be a huge list, and perhaps not useful at that to someone unfamiliar with what each will offer. It is hard to find the balance.

 

If I were to add a "Remove from Listing" button, how would you prefer this to work if a newer version of a given "suppressed" package is released?  (The newer version might be one you desire, or now compatible with what you are running)

 

Joe L.

[starcat]

I've been thinking of how to add a few "buttons" at the top of the package manager.  I was thinking of one for installed packages only, and another to only show packages configured to install-on-reboot.  Your idea of suppressing packages is perhaps the opposite of one I was considering, one to select from a list of un-installed packages to enable one for download/installation.  The big difference is that if we ever get 1000 packages it is a lot easier to enable the handful you desire rather than disable the 995 you wish to suppress.  Of course, by the time we get to 1000 packages it will be nearly impossible to show full descriptions of all of them in a single listing... even one line per would be a huge list, and perhaps not useful at that to someone unfamiliar with what each will offer. It is hard to find the balance.

 

I like your idea more, especially with 1000 packages :-)

 

If I were to add a "Remove from Listing" button, how would you prefer this to work if a newer version of a given "suppressed" package is released?  (The newer version might be one you desire, or now compatible with what you are running)

 

Don't show it as it is Suppressed. It would be displayed on the Page containing Suppressed Packages, one may go anytime there and see what's all available there and install it (then it gets automatically the suppressed flag removed).

 

 

[aiden]

Is anyone else having a problem with unraid-overtemp-shutdown causing stuttering during media streams?  Every 5 minutes during playback, I am getting a stutter that didn't exist prior to installing the script.  I uninstalled it, rebooted, and everything returned to normal, no stutter.  My throughput from the data disk is 3 - 4 Mb/s, so I can't imagine it's a bandwidth issue.  Any thoughts?

[starcat]

What command is unMenu using to spindown a disk, in the Disk Management section? Thanks!

[Joe L.]

What command is unMenu using to spindown a disk, in the Disk Management section? Thanks!

That would depend on which disk you are referring to, and which version of the disk-management utility.

 

In the older versions of unMENU, the spin-up of any disk was done with

dd if=/dev/DDD of=/dev/null count=1 bs=1k skip=NNN

where DDD = the device (sda, sdb, sdc, hda, hdb, hdc)

and    NNN = a random number between 1 and the total number of blocks on the specific disk.  I read a random block from the disk using "dd". 

 

Spin-down was done with

/usr/sbin/hdparm -y /dev/DDD

 

when Tom added spinup groups in one of the latter 4.5-beta series, the spin-up and spin-down of disks assigned to the unRAID array changed to use the new spinup and spindown commands.  The disks not assigned to the array still use the same technique as before. ("dd" for spin-up, "hdparm" for spin-down)

 

Disks that are assigned to the array are spun-up with

/root/mdcmd spinup N

 

 

Disks that are assigned to the array are spun-down with

/root/mdcmd spindown N

(Where N = 0 through 19. 0=parity, 1 = disk1, 2=disk2, 19=disk19)

 

Your question prompted me to verify I was setting the seed to the random number generator in all cases.  I was if you pressed the spin-up all disks button, but not on an individual disk...  The second and subsequent spin-up of a given disk might outside of the array get the same "random" block and read it instead from the buffer cache.  I've now added a call to the srand() function to correct that oversight.  I'll update the release_list in a few minutes and upload the new version.

 

Joe L.

[starcat]

Joe, thanks, as always your input is greatly appreciated!

[starcat]

(Where N = 0 through 19. 0=parity, 1 = disk1, 2=disk2, 19=disk19)

 

Anyone know something more about 24 disk support? Based on that comment by Tom here http://lime-technology.com/forum/index.php?topic=4887.msg44997#msg44997 up from 4.5.1 we should have 24 drives, however I only see assignment for 20 drives in unRaid Main?!

[starcat]

Using the latest unMenu and apc package, all variables configured for serial, it used to work. Now, inspired by another UPS thread checked APC Info on the System Info and there was no comms. Checked the /etc/apcupsd/apcupsd.conf and there were no changes to the respective variables. When I change by hand everything works. Changing the variables in unMenu and re-installing and still no comms?!

 

Edit:

I see two apc packages in unMenu, one is 3.14.8 and the other is 3.14.3, configured 3.14.3 and everything works again. Looks strange to me...

 

Edit2:

Moved those files away from /boot/packages:

 

apcupsd-3.14.8-i486-1_rlw.tgz*              

apcupsd-3.14.8-i486-1_rlw.tgz.manual_install*  

apcupsd-3.14.8-i486-1_rlw.tgz.auto_install*  

apcupsd3-unmenu-package.conf-2010-06-04-155040.bak*

apcupsd3-unmenu-package.conf*                  

apcupsd3-unmenu-package.conf-2010-06-07-020734.bak*

 

and everything seems ok again (both APC packages disappeared from unMenu's Package Manager). Not sure however if they would be downloaded again if I were to autoupdate unMenu again!?

 

 

[Joe L.]

Using the latest unMenu and apc package, all variables configured for serial, it used to work. Now, inspired by another UPS thread checked APC Info on the System Info and there was no comms. Checked the /etc/apcupsd/apcupsd.conf and there were no changes to the respective variables. When I change by hand everything works. Changing the variables in unMenu and re-installing and still no comms?!

I've run into the same problem using the 3.14.8 version, an that is why I do not use it.  (I go to check for status using the button on the "System-Info" page, and it does not respond)

Edit:

I see two apc packages in unMenu, one is 3.14.8 and the other is 3.14.3, configured 3.14.3 and everything works again. Looks strange to me...

 

Edit2:

Moved those files away from /boot/packages:

 

apcupsd-3.14.8-i486-1_rlw.tgz*              

apcupsd-3.14.8-i486-1_rlw.tgz.manual_install*  

apcupsd3-unmenu-package.conf-2010-06-04-155040.bak*

apcupsd-3.14.8-i486-1_rlw.tgz.auto_install*  

apcupsd3-unmenu-package.conf*                  

apcupsd3-unmenu-package.conf-2010-06-07-020734.bak*

 

and everything seems ok again (both APC packages disappeared from unMenu's Package Manager). Not sure however if they would be downloaded again if I were to autoupdate unMenu again!?

Yes, the .conf files will automatically be replaced if you run the Auto-update. 

 

I'd use the older version 3.14.3.  It has been working perfectly for me for quite a long time.

 

The .bak files are there in case you edited something and wanted to go back to the older version.  They are simply a backup of the file before you edited the configuration values.

 

Joe L.

[starcat]

Why we keep the 3.14.8 version in that case? Most people will be confused by the "newer is better" and try install and use it and be surprised when a power outage happens. I will just remove it and use only the 3.14.3 as it perfectly does what it is supposed to do, IMHO.

[Joe L.]

Why we keep the 3.14.8 version in that case? Most people will be confused by the "newer is better" and try install and use it and be surprised when a power outage happens. I will just remove it and use only the 3.14.3.

There was one unRAID user who insisted on using the newest version since it would have the least bugs.  (or so goes the theory)  we did not know of the issue until after using it for a while, and it worked initially for me too... and it might work perfectly for some.  For that reason, both exist.

 

If you remove the .conf file, it will only get added once more when you use the auto_update feature. 

 

You can run the following two commands to make it so it will not be updated, and not show up in the package manager.

 

This first command will put a "# in front of every PACKAGE_* line, so in effect, they are all commented out.

sed -i  "s/^P/#P/" /boot/packages/apcupsd3-unmenu-package.conf

This second command will add a special line that will prevent the new version from being installed over the old.

echo "#AUTO_UPDATE=no" >> /boot/packages/apcupsd3-unmenu-package.conf

 

Joe L.

[Joe L.]

Based on your feedback, I think I'll add a warning to the newer version of apcupsd stating that several reports have been made that it stops working after a while, so the older release 3.14.3 release is probably the better choice.

 

Joe L.

[ClunkClunk]

I think a warning is a good idea. I unknowingly started the newer version yesterday, and just checked my syslog:

Jun 6 04:40:01 Tower apcupsd[1585]: apcupsd error shutdown completed

[Joe L.]

I think a warning is a good idea. I unknowingly started the newer version yesterday, and just checked my syslog:

Jun 6 04:40:01 Tower apcupsd[1585]: apcupsd error shutdown completed

A shut-down message might be normal if you re-installed with edited values at that time, as the currently running version must be stopped to invoke the newer version. (I don't know he exact error message logged, or if one is logged actually, since I've never looked for it in the syslog)

 

Now, if it happened at 4:40 AM, and you were asleep, then it is certainly interesting.

 

The .conf file with the added warning message is now in place on google.code.  You can use the "Check for Updates" button on the user-scripts page to get it.

 

Joe L.

[starcat]

Hi Joe,

 

I am getting the following message via mail and the overtemp shutdown script isn't able to shutdown the server. Any hints as to what may be wrong? Thanks much!

 

/bin/sh: line 1: 15610 Killed                  /usr/local/sbin/overtemp_shutdown.sh >/dev/null 2>&1

[Joe L.]

Hi Joe,

 

I am getting the following message via mail and the overtemp shutdown script isn't able to shutdown the server. Any hints as to what may be wrong? Thanks much!

 

/bin/sh: line 1: 15610 Killed                  /usr/local/sbin/overtemp_shutdown.sh >/dev/null 2>&1

For any script to be "Killed" it usually indicates you've run out of memory and the out-of-memory kernel process  is killing processes it thinks are idle to try to free some RAM.

 

What do you see in the syslog?

 

Joe L.

[yannis]

Hi,

 

First post so please be gentle. I'm very new to unraid and in the process of building a server. I'd like to try unMenu but I'm not getting very far at all. I've downloaded the zip file from the link to google code, but when I try to extract the files, all I end up with is a single file called unmenu_install. It's probably something stupid I'm doing but I'd like to know what. 

[Joe L.]

Hi,

 

First post so please be gentle. I'm very new to unraid and in the process of building a server. I'd like to try unMenu but I'm not getting very far at all. I've downloaded the zip file from the link to google code, but when I try to extract the files, all I end up with is a single file called unmenu_install. It's probably something stupid I'm doing but I'd like to know what. 

You've done perfect so far. 

 

In the zip file is a single file named....

unmenu_install

In past versions there were multiple zip files with multiple files in them.  The current version ONLY has one file,  the installer/updater script named "unmenu_install".

 

Now that you've un-zipped it,  create a new directory on your flash drive named "unmenu"

You can either do that from your PC, since the flash drive is accessible at

\\tower\flash

 

or, you can log onto the system console as "root"  (there is no password, just press enter if prompted)

Once logged on, type:

mkdir /boot/unmenu

 

Now, you need to move the one file you extracted from the zip file on google.code into that directory.  Do that from your PC by copying the file to \\tower\flash\unmenu

or you can move the flash drive to the PC and copy the file to the "unmenu" directory. (then move the flash drive back to the server)

 

Next, you need to invoke it as follows while logged onto the server.  Log on again as "root"

To log off if you are logged on just type:

exit

 

First change directory to the /boot/unmenu directory by typing

cd /boot/unmenu

 

Then type

unmenu_install -i -d /boot/unmenu

 

Assuming you've defined a DNS Server and a Gateway in your "Settings" page on the unRAID web-interface,  it will proceed to download and install itself to the unmenu directory.  (The DNS Server and Gateway are often both set to the IP address of your router)

 

Lastly, once it has downloaded itself, type

/boot/unmenu/uu

to start its web-server

and then browse to

http://tower:8080

with your web-browser.

If you are using a MAC you'll need to add an entry to your hosts file for "tower" or it will not know how to get to "tower"

 

Pretty much these exact instructions are on the google-code page and on the first post in the thread describing unMENU 1.3.

 

Good luck.  (instead of logging in on the system console you can log in via telnet, but I'm guessing the system console will be easier for you.)

 

Joe L.

[yannis]

Many thanks,

 

Still a bit stuck though. I've created the unmenu directory on the flash drive and copied the unzipped file to it (file name is unmenu_install135). Managed to log on to the server and changed to the boot/unmenu directory. When I type the command "unmenu_install -i -d /boot/unmenu" I get an error message "-bash: unmenu_install -i -d: command not found".

 

BTW I'm a 57 year old carpenter with a bit of computer knowledge - not an IT expert by any means.