- kernel: change other supported hwmon components to modules instead of built-in

 

Thank you for this... I'll try to put together a plugin to ID the CPU, and test modules, so the Sysstat plugin can be able to get temps, fanspeeds, etc.

 

Perhaps even the fancontol stuff too. 

 

It has always irritated me a bit that the lmsensors folks used perl for their scripting of sensors-detect... so Iook forward to redoing it in php.

This sufficient?

 

Sweet!

 

I completely understand if this makes the kernel too big... if the modules are big, but the kernal is not and you need to shrink the initramfs, perhaps you can post the modules separately for plugin devs to install selectively if needed.

 

Yes, this is an awesome idea, since many modules need kernel hooks and signals to work, but can be loaded via modprobe/insmod. The tun/tap driver can, so the bridge module, but the last one depends some compiled kernel signals.

This is probably not something I can implement in just a couple days, since I think what you want is to be able to specify on a disk-by-disk basis what file system to format each disk as, correct?

 

My request was *not* for unRAID array disks to use ext3/4... just to have support in the kernel since I often mount drives and dd images from other systems to copy their contents to unRAID... and they are often ext3.

 

As was mine. The driver behind this was the ability to add data to unRAID via USB HDD sourced from other systems (which most often as ext3/4 or NTFS)

 

Future support for array disks as ext3/4 is a long requested feature but I dont think anyone expected this to be added at a whim.

Something else to think about, w/r/t moving to Slackware 13.1.  The new package tools, which use .txz file extensions and the xz compression libs.  Scripts (and a package manager) will have to take that into consideration.

 

Yes, this is an awesome idea, since many modules need kernel hooks and signals to work, but can be loaded via modprobe/insmod.

 

That is why I have tried to limit requests for unRAID changes, to things that essentially can't be done in the field.  The /boot/extra and the plugin architecture, makes field modifications a real usable option.  Theoretically, with the right build environment, I can build any needed modules with the correct version magic and include them in a package, but they won't work without the kernel support, and they can't be added if something related that needs to be removes was not added as a module, but was built-into the kernel.

 

FWIW, I added all the packages from 12.1 necessary to rebuild the kernel, with gcc4.2.3 and all necessary libs, and a full install of perl, all on a 512MB system, and it all worked fine.  With /var and the initramfs working as ramdisks that can be swapped out, a swap file, relocation of part of the root fs (such as /usr) to a different storage device ... there are a lot of ways to skin the cat if the kernel or initramfs grows.

 

Suggestion for a change - when an empty cache drive is installed from scratch and formatted, I'd suggest that unRAID to automatically make a swap partition/file on it too.  That way, a cache drive will potentially help a lot of issues, and not just file copying.

Suggestion for a change - when an empty cache drive is installed from scratch and formatted, I'd suggest that unRAID to automatically make a swap partition/file on it too.  That way, a cache drive will potentially help a lot of issues, and not just file copying.

Excellent Idea.

Suggestion for a change - when an empty cache drive is installed from scratch and formatted, I'd suggest that unRAID to automatically make a swap partition/file on it too.  That way, a cache drive will potentially help a lot of issues, and not just file copying.

Excellent Idea.

 

I concur.

By somehow allowing /usr and /var to be remounted (moved, then copied, whatever procedure) to tmpfs.

it allows /var and/or /usr to swap out unused portions to temporary storage.

 

It's not as good as a unionfs, but it's a step to allowing temporary installation of many support programs without crashing the system.

 

I was going to suggest a hook very early in /etc/rc.S to a user provided script(if exists) on /boot/config/rc.S

Same for rc.M

 

I dunno if this is asking too much, but something earily in those scripts may allow us to experiment with moving /var and /usr to tmpfs filesystems.

 

In any case, a new cache, or reformatting cache with adding a small swap space goes a long way.

Somethings funny with events.

 

On initial boot, these are the calls that are made to emhttp_event:

 

driver_loaded
array_started
disks_mounted
svcs_restarted   <== but no "started" event after this

 

When I press the stop button, these are the calls that are made to emhttp_event:

 

stopping_svcs
unmounting_disks
stopping_array
stopped
svcs_started   <== this is odd to see after "stopped"

 

After the "start" button:

 

array_started
disks_mounted
svcs_restarted     <== but no "started" event after this

Somethings funny with events.

 

On initial boot, these are the calls that are made to emhttp_event:

 

driver_loaded
array_started
disks_mounted
svcs_restarted   <== but no "started" event after this

 

When I press the stop button, these are the calls that are made to emhttp_event:

 

stopping_svcs
unmounting_disks
stopping_array
stopped
svcs_started   <== this is odd to see after "stopped"

 

After the "start" button:

 

array_started
disks_mounted
svcs_restarted     <== but no "started" event after this

I think Tom is re-starting SAMBA/NFS so you can get to the flash drive after you stop the array.

 

But, it does seem that the "started" and "restarted" event callouts have the names transposed.

Could we get an event callout after 30 (or some user-configurable number) "Retry unmounting disk share(s)" attempts?

Could we get an event callout after 30 (or some user-configurable number) "Retry unmounting disk share(s)" attempts?

That would be helpful...  We can then react and more forcibly terminate a process holding a disk busy, if that is the desire of the user.

Could we get an event callout after 30 (or some user-configurable number) "Retry unmounting disk share(s)" attempts?

That would be helpful...  We can then react and more forcibly terminate a process holding a disk busy, if that is the desire of the user.

 

This can be done within the main event handler by running a shell in the background and trapping the event.

 

Example:

 

#!/bin/bash

 

alarm_handler()

{

  echo "$0[$$]: holy shit guys. I got sigalarmed!"

  exit

}

 

trap "alarm_handler" ALRM

 

( sleep 10; kill -14 $$ ) &

 

echo "$0[$$]: I'm gonna wait it out."

wait

echo "$0[$$]: I'm outta here"

 

 

 

rcotrone@rgclws ~/sh $./bashtrap.sh

./bashtrap.sh[30587]: I'm gonna wait it out.

./bashtrap.sh[30587]: holy shit guys. I got sigalarmed!

 

 

 

This can be done within the main event handler by running a shell in the background and trapping the event.

 

Yes, it can, but the delay long enough to trigger the payload could be from many different reasons... not failure to unmount.  Think a 20+ disk system and all the disks have to first be spun up.

Could we get an event callout after 30 (or some user-configurable number) "Retry unmounting disk share(s)" attempts?

That would be helpful...  We can then react and more forcibly terminate a process holding a disk busy, if that is the desire of the user.

 

I agree with this request.  It would also be extremely helpful to be able to issue additional commands when the stop button is pressed.  For example, I run VMware and need to manually issue a "/etc/rc.d/init.d/vmware stop" command every time I stop the array since VMware is running.

 

Any chance of supporting a simple way of installing vmware or virtualbox to run on top of stock unRAID? 

 

It would be very useful and even 'Green' to be able to consolidate other more-or less 24/7 machines on the unRAID server.

 

Pretty please 

Found another issue with php.... output buffering does not work.

Could we get an event callout after 30 (or some user-configurable number) "Retry unmounting disk share(s)" attempts?

That would be helpful...  We can then react and more forcibly terminate a process holding a disk busy, if that is the desire of the user.

 

I agree with this request.  It would also be extremely helpful to be able to issue additional commands when the stop button is pressed.  For example, I run VMware and need to manually issue a "/etc/rc.d/init.d/vmware stop" command every time I stop the array since VMware is running.

 

We already have the event needed to start and stop applications like "vmware"   If vmware is well behave, you would never see the "Retry un-mounting disk shares" message since it would have been stopped prior to the disks being unmounted.

 

The additional event we are discussing here is for when applications (like vmware) do not stop in a reasonable time after being issue a "stop"

command,  and must be killed in order to cleanly stop the array.  (as in a power failure shutdown as the UPS batteries get near depletion)  

Any chance of supporting a simple way of installing vmware or virtualbox to run on top of stock unRAID? 

 

It would be very useful and even 'Green' to be able to consolidate other more-or less 24/7 machines on the unRAID server.

 

Pretty please 

 

What drivers or hooks need to be compiled in the kernel to support this?

That's the key issue.  That vmware thread is Loooong.

In a summary, what is required that forces a compilation of the kernel?

I agree with this request.  It would also be extremely helpful to be able to issue additional commands when the stop button is pressed.  For example, I run VMware and need to manually issue a "/etc/rc.d/init.d/vmware stop" command every time I stop the array since VMware is running.

 

This is why the directory structure of events would be useful.

Put a link or wrapper in the correct directory location and it will occur.

However, this is a pretty popular example, so someone will probably create a vmware plugin to check the status, stop and start vmware.

What drivers or hooks need to be compiled in the kernel to support this?

That's the key issue.  That vmware thread is Loooong.

Yes - that is why I was hoping this could be a bit simpler if the right stuff was in the core product. I was hoping a Linux-wiz would know what it takes to make it. My assumption being that it's difficult mainly because you also have to rebuild the unRAID part to include xxx, yyy and zzz (but the xyz being known or easily identifiable parts). I'm unfortunately not Linux-savvy - that's why it would help a lot with this precooked...

 

 

The right stuff is there.  SYSVIPC needed to be enabled for VBox, but that was done some time ago.  I've installed VBox and VMWare on unRAID w/o a new kernel.

The right stuff is there.  (...)  I've installed VBox and VMWare on unRAID w/o a new kernel.

So nothing to add to v5 - brilliant!  I better get on it again then - as soon as 5.0 is released...

So nothing to add to v5

 

There has been nothing to add for over a year.  4.5, indeed, 4.4 forward had everything needed IICR.

 

CD support is not there, so you can't mount CDs in the VM, but that's not a big issue since you can install from flash.

Re: memtest update.

Just in case.

 

http://lime-technology.com/forum/index.php?topic=7497.msg72559

The right stuff is there.  SYSVIPC needed to be enabled for VBox, but that was done some time ago.  I've installed VBox and VMWare on unRAID w/o a new kernel.

 

I thought that while the right stuff was there to RUN vmware, the right stuff to INSTALL it was not!  Am I missing something?

The VMWare installation hell is all the doing of VMWare and not the doing of unRAID.

 

From what it seems, VMWare prevents the distribution of prepackaged installations and each installation requires it's own license, even though the software and license is free to obtain.