Some more tinkering last night. The problem certainly seems related to how the machine is shutdown - it seems the NIC needs to be left in a state that allows WOL to work. This can be forcecd by physically removing power from the machine but obviously I don't want to do that every time... I may as well power it on manually.

The "halt"  (/etc/init.d/halt) script which is the last that is called in the shutdown sequence, as I understand it, has a setting at the beginning "NETDOWN=yes" which then, if "yes" passes a "-i" parameter the /sbin/halt executable to, presumably, shut down the network device.

Now there doesn't seem to be clarity as to whether the NIC must be shutdown (similar to

Code:

ifconfig eth0 down

) or not for WOL to work but regardless of this, halt doesn't seem to do the right thing. I have tried "NETDOWN=no" as well as yes.

Some of the bugfixes/workarounds out there advise shutting down the NIC explicitly by creating a script that is executed right at the end of the shutdown process that does a

Code:

ifconfig eth0 down

immediately before powering off.

I tried hacking the halt script to include this code prior to the /sbin/halt command but the system then moaned about something being active. I presume this is to do with the NFS being mounted. Of course that is going to be a problem. It makes sense that you can't bring down a network card that is still being used for the filesystem....

Here's what I'm thinking at the moment. The problem is either due to
a) My NIC driver which is not allowing the NIC to be moved to a state that will accept WOL when the /sbin/halt command is executed with the "-i" parameter.
OR
b) Some other problem in the shutdown of this particular MD that is causing other things (NFS, NBD?) not to be stopped properly which is preventing the network being brought down properly.

I'll start with b) because there are definitely a few "faileds" being thrown on shoutdown of this MD. I'll compare to the working ones and see if I'm having a problem somewhere that doesn't exist on the others and try to fix. Otherwise I'll tinker wtih the NIC driver. Maybe.

Just to add to this... I haven't got to the bottom of it yet but I have certainly tried many things - confirmed bios is enabled, confirmed via ethtool that WOL is setup for NIC. Where I am at the moment is possibly at a bug in ubuntu somewhere.... because here's what is possible-

If mains power is removed for a few seconds after shutdown and then re-connected, after *that* I can wake on lan the MD. I got that from a bug report somewhere... I think some people had some success removing networkmanager or some similar package but I made a mess of my MD trying some stuff and had to rebuild the image.

Will keep digging.

Carrying on the gamepad discussion in the following thread.

http://forum.linuxmce.org/index.php/topic,12645.0.html

Have gone around in circles a few times but I think I'm getting there.... at least detecting the problem. Fixing is another issue ;-)

Here's an interesting one... I've had some issues with a USB Gamepad device appearing on my MD (HP 6710b Compaq notebook).

I didn't even notice the device being added until it caused problems - It got into a loop at one stage and just kept adding devices and, then when I wanted to configure a Wiimote it caused havoc with that - they don't like to co-exist, it seems.

Anyway, the issue seems to be the following-

The detect scripts for the USB Gamepad device check for, among other things, a joystick device- ie the existence of a file /dev/input/js0.

Well, in my case, that file is created by the X configuration because the configuration detects an internal accelerometer in the notebook (apparently it is there to protect the harddrive or something... not sure how, maybe it yells "CATCH MEEEEEE" over the PC speaker if it thinks it's falling or something) and sets it up as a joystick device. Jeepers, so I suppose you could play games by flinging the notebook around. Anyway, the point is, that sets up the /dev/input/js0 device which then triggers the USB Gamepad device creation.

At the moment I'm testing a bazooka-hack to stop this but we'll probably have to look at a cleaner method. Will report back...

Xorg.0.log entry:

Code:

(II) config/udev: Adding input device ST LIS3LV02DL Accelerometer (/dev/input/js0)

Do you use the motion wrapper to detect motion?

I do, indeed. It is wrapped by motion wrapper. And I must say that is working nicely at the moment. Haven't tinkered too much with the motion settings themselves but I do have my camera popping up for 30s on the TV every time motion is detected and I'm quite keen to refine that a bit with some enhancements and possibly have slightly different behaviour depending on security mode and various other factors. Will wikify when I get it a bit more stable because there doesn't seem to be too much in the howtos on "respond to events" and "cameras".

My camera is a cheap type with a manual badly translated from Mandarin or something-
http://wiki.linuxmce.org/index.php/EasyN_FS-603A-M106_IP_Camera

It supposedly has all the built in features- motion detection, e-mail you on motion detection etc etc but I haven't bothered with any of that because I planned to wrap it with LMCE software.

How are you getting on with the more advanced template? My concern would be that with cheap and poorly supported cameras like mine one might battle to get the specs/communication working so I would prefer to do all that stuff in the wrapper myself and then I don't have to buy the more expensive devices.... just plug in the cheap-o, set it up with username password and get the videostream and then use LMCE/wrappers to do all the advanced stuff.

* It must be enabled in the BIOS [TICK]
* The network card must have been enabled (by ethtool) [TICK]
* The system must have wake-up enabled
   - This is done in /proc/acpi/wakeup iirc, see if there is some entries there that match your network card, or a generic PCI entry. Some googling may be required to figure this one out (I don't recall the exact command at the moment)
* The driver must support wake-on-lan. What LMCE version are you using 810 or 1004? In 810 there was some network drivers that did not set the wake-up flag correctly, and wouldn't wake-on-lan. I think it is fixed in the kernel used in 1004 but still...

Ta, that sounds right. I think the first two are OK. I will have a look at the third (/proc/acpi/wakeup iirc or whatever) and then the fact that the driver supports it...
I'm using 1004.
My one thought is that I have deleted and recreated this media director device out of webadmin and, obviously, the same MAC address would be used as the previous (now deleted) device so I thought there might have been some config somewhere that wasn't properly purged and the system is still trying to wake the "old" device or something...

My IP camera on my gate is working nicely. When I use the security Scenario from the orbiter to pop up the camera viewer, it works well....

But, on occasion, the camera view disappears- The "wrapper" with all the command buttons like "speak" and the pan and zoom buttons etc is there but no camera stream in the middle. Now the camera stream is still working (can confirm by going directly to the camera's IP and it's built in view) and, I think, even the motion clips are all being recorded and the events fired on motion during this time.

Rebooting the core sorts it out and, I may be wrong, but I think occasionally a reload of the core sorts it out.

Any ideas where to troubleshoot?

After sorting out the shutdown on my other two MDs, I'm now trying to sort out the wake-on-lan for my HP compaq 6710b notebook. It has definitely worked before and definitely has the capability (hardware) but at the moment is not working.

What I've done so far-

* Tried the "power on"  from other orbiters and that doesn't work.
* Tried running /sbin/WakeMD.sh (or something similar) with --dev and --mac options, no dice.
* Tried using ethtool -g to check that wake-on-lan is configured when the MD is up and that looks correct.

Hmmm... will probably have to do a bit more digging to find how wake-on-lan works at a lower level and see if I can do it with a crescent wrench... then if that works I will try to figure out how/why that is not happening via the normal channels! Any suggsetions/troubleshooting tips welcome.

It is a bit of a pain not being able to start this puppy remotely.

The USB Game Pad driver needs work for certain cases. I would love for somebody to take a look at the code, to see what they can fix, given their unique installs.

-Thom

I'll try and have a look at the detection side.... since DragonK and I have both had issues and we both use wiimotes I think it's likely that is where the confusion is being introduced. I'll open a trac ticket for it.

Edit: Oh, I see you have a trac ticket already for the gamepade device http://svn.linuxmce.org/trac.cgi/ticket/1228
I'm thinking the issues are in the AVWizard_Gamepad_Detect.sh and AVWizard_Remote_Detect.sh that are picking up stuff from the wiimote install. If I find anything I'll chat directly to you and/or put a comment on the ticket.

I also just had a problem with the USB-gamepad install. I recently updated my system and reran DisklessCreate_TBZ.sh and then re-installed all my media directors. My Compaq HP6710b notebook got into a USB-gamepad device install loop where it just kept adding the device and incremmenting the device number. Sarah in the background asking if I can see and hear her while in the top-left I keep getting "detected gamepad device number 3283", "downloading software...", "detected gamepad device number 3284", "downloading software...", etc etc until I manually powered off the MD. I had to then go into web admin, delete gamepad device (there was only one) in device tree and then remove the reference on the media director wizard to the gamepad as remote. Then, before booting the MD again, I did the fix mentioned below in the detect gamepad script on the /usr/pluto/diskless/xxx/usr/pluto/bin script.

Then booted up the media director again and all worked swimmingly.

As mentioned by Karel, the gamepad detect script is clearly returning false positives in some instances. Should I open a trac ticket for this?

Incidentally, if it is installed, it also plays havoc with trying to use a wiimote.

Something is triggering the gamepad install script.
In my case it was my logitech universal receiver.

Got this from another thread...
http://forum.linuxmce.org/index.php/topic,12297.0.html

Karel

At last.
Started with the globalupdate script which updated all my MDs nicely but didn't solve my shutdown problem.

So, I took out the bazooka-

Ran Diskless_CreateTBZ.sh to get the latest stuff for creating new MDs and deleted my existing MDs (the problematic ones) from webadmin and then recreated them- ie booted them up and let the scripts etc do their thang. And I have to say it all went *very* smoothly. My two old radeon cards that previously required many handsprings were now correctly identified and configured "out the box" and the MDs are running super smoothly. UI2 on one AND UI1 on the other, both running very smoothly and shutting down properly! Yay.

My conclusion is that somewhere in the messing about installing/re-installing/removing packages to try to get the video cards to work I must have messed something up in the base ubuntu packages which was causing the problem. It was impossible to shut them down properly from command line using any combination of /sbin/shutdown, /sbin/reboot or /sbin/poweroff commands and various parameters - they would reboot instead of shutting down and would do so immediately rather than going through a process....  however they could do it no problem when booted from a live 10.04 cd so I presumed it was something to do with the install/configuration. Anyway the clean install sorted them out.

In case someone hits a similar wall- take out the bazooka!

That depends on whether they really are the same. Meaning,... One of the shutdown command line switches is deprecated,... either -h or -P, I don't know which one,... but they're supposed to do the same thing now... but they don't (not always, anyway).
If you're shutting down your system with shutdown -h now, but LinuxMCE does it with shutdown -P now, they may yield different behavior. Unless you are specifically looking at the scripts, you might assume one is used, when it is really the other,... That's what I mean...

I hear you, but if you look further back in the thread you will see I've tried every combination of command line switches in the known universe.... and I've done that on the direct binary executables (bypassing the commands that are just shellscripts) directly from command line as root. Now if I can't shut it down from there I presume LMCE can't, but I know that under standard (live) 10.04 I can...
also, there's been a lot of hacking going on on both these machines so I'll go for a clean build of the images to eliminate any issues there and then try again. Thanks for the pointers, though... will try all combinations again when I get the clean machines up.

excellent.

everything else is embedded.

Don't forget pastebinit ;-) L3, you could save yourself a lot of time and a lot of IRC swearing by your testers by embedding that as well ;-)

It might not be the image. It might just be the way the hardware reacts to the scripts. ACPI is one of those voodoo areas in Linux.

Even given the fact that when I boot the same hardware with a 10.04 live cd, the command shuts the machine down properly?