Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - PeteK

Pages: 1 [2] 3 4 ... 28
16
Developers / Re: Getting IP address from Device in GSD
« on: March 16, 2009, 05:18:48 am »
Guys--

Thanks for the help!  Darrenmason, you were right.  Changing the Port Device Data field to TCP Port fixed the connection issue.  I've got the commands working, but I've run into another issue.  After booting the device (having it recognized by LMCE), it responds just fine to commands from GSD.  However, after a router reload, it fails to respond to commands until a power cycle.  I'm wondering if this is due to the way that the connection is closed during a router reload.  However, I'm not by any means certain.  I know that i can telnet to it from the command line, quit via 'quit' and re-connect to it time after time (until a router reboot).  Can anyone offer any more advice?

Thanks a lot!
-Peter

17
Users / Re: Insteon security question
« on: March 14, 2009, 01:21:25 am »
If you're looking for an insteon controller that's compatible with LMCE, I suggest the Insteon PowerLinc Modem.  DDamron has a GSD-based driver for the serial-port version, and I'm currently (slowly) working on porting and expanding a driver I originally wrote for the USB-based PowerLinc Controller.

18
Developers / Getting IP address from Device in GSD
« on: March 10, 2009, 07:00:31 am »
Hi everyone--

I'm trying to modify the template for the Roku Netflix player.  Right now it's set to be controlled via an IR interface.  However, I've gotten a quasi-official ICD from Roku to control it via telnet.  The template is of type AV/Cable Box (which seemed to be the closest match when I created it).  Per TSCHAK's advice, I added a PORT (#171) device data field.  However, when I add code to the Command fields, I get an error about not finding a port.  I believe this is due to the case that there is a Com Port on PC data field defined for the device (I'm not sure exactly how, as it's not in the template.  i think it's inherited from the device type).  This field is set to empty and I think GSD defaults to using this field and it's trying to create a serial connection.   TSCHAK suggested using a Ruby  TCPSocket to communicate.  That socket requires the IP address of the target in its constructor.

Now, to make a long plead short, I haven't been able to find the documentation for how to extract a device's IP address from it's devicedata fields inside GSD so I can feed it to the constructor.  Does anyone know how to do it?

Thanks for the help.
-PeteK

19
Users / Re: Need help with rs232 tv
« on: February 27, 2009, 06:58:16 am »
tschak--

got ya. 

Afkpuz, for the script, it's set up to support operation in LMCE.  $3 is the third argument when the script is run.

To run it by hand, run

Code: [Select]
20_Olevia2XX_5XXT_TV.sh 1 1 /dev/ttyS0
replacing /devttyS0 with your serial port.

If you still can't get it to work, I can post a windows executable that I wrote to test the interface.


20
Users / Re: Need help with rs232 tv
« on: February 27, 2009, 05:45:23 am »
I checked in my Olevia template a few days ago.  Try doing a sqlCVS update and let me know if that template works for you.


21
Users / Re: USB UIRT in 0810? [Solved]
« on: February 25, 2009, 04:51:57 pm »
I know this is a moot point since krys is on it ;), but for future information, it turned out that the USB_UIRT_038 executable wasn't being started from a router reload.  Starting it from the command line got the USB UIRT functioning.  As for capturing the codes, there were a few more steps involved that weren't exactly clear to me for doing so.  I haven't found clear wiki information on learning codes, so I'll add in the steps that TSCHAK guided me through.

22
Users / USB UIRT in 0810? [Solved]
« on: February 24, 2009, 05:41:37 pm »
Has anyone had luck getting the USB UIRT to work in 0810?

I added it manually, due to the fact that USB PNP is still having some issues in 0810.  However, when I create a template for a new AV device and set 'Controlled by' to IR, when I try to add a code and select the 'learn code' radio box in the web admin, it automatically sets it back to 'enter code.'

My guess this is due to problems with the USBUIRT interface.  I'm not entirely certain I have the port set correctly.  The drop-down box for the port lists the two system serial ports, the virtual serial port mapped for the GC100, and a PCI address.  I selected the PCI address, thinking it's the only remaining one (I believe it was new after pluggin in the USB UIRT).  But I may be wrong about that.

Any advice would be definitely appreciated.

Thanks,
-Pete

23
So to work around this issue, should I recompile the modules in the MD for the new kernel?  The other option is to add the kernel headers for one of the older kernels (-7 or -9) and copy one of those kernels over.  I need the headers to properly compile the nvidia driver package.

Thanks!
-Pete

24
To follow up, looking at /usr/pluto/install/PlutoMD-i386.tar.bz2, it has kernel files and modules for 2.6.27-7 and 2.6.27-9, but kernel headers for 2.6.27-11.  Is this an oversight in building the tarball?

In any case, I think my original question about how to handle MD image creation in light of updatable kernels is still a valid one.

Thanks for reading,
-PeteK

25
Developers / Re: 0810 Upgraded 2.6.27-11 kernel cannot boot MD
« on: February 14, 2009, 07:37:40 am »
Posde--

I was a little hasty yesterday in identifying this as a size issue.   
Following the steps in the wiki, I ran /usr/pluto/bin/Diskless_BuildDefaultImage.sh which looks to correctly set up the /tftpboot/default directory correctly, as the MD boots initially.

I think the problem occurs when the file system is generated using the current 0810 method of changing architecture and selecting 'Rebuild Image'
In /tftboot/<device num>  initrd.img and vmlinuz are correctly set up as symlinks to /usr/pluto/diskless/<device num>/boot

and here are the contents of /usr/pluto/diskless/<device num>/boot

Code: [Select]
linuxmce@dcerouter:/usr/pluto/diskless/75/boot$ ls -l
total 22964
-rw-r--r-- 1 root root  507665 2008-11-04 13:00 abi-2.6.27-7-generic
-rw-r--r-- 1 root root   91364 2008-11-04 13:00 config-2.6.27-7-generic
lrwxrwxrwx 1 root root      56 2009-02-13 22:03 initrd.img -> /usr/pluto/diskless/75/boot/initrd.img-2.6.27-11-generic
-rw-r--r-- 1 root root 8514033 2009-02-08 14:17 initrd.img-2.6.27-7-generic
-rw-r--r-- 1 root root 7785478 2009-01-26 16:35 initrd.img-2.6.27-9-generic
-rw-r--r-- 1 root root 1029585 2008-11-04 13:00 System.map-2.6.27-7-generic
-rw-r--r-- 1 root root 1029585 2009-01-26 16:34 System.map-2.6.27-9-generic
-rw-r--r-- 1 root root    1073 2008-11-04 13:02 vmcoreinfo-2.6.27-7-generic
lrwxrwxrwx 1 root root      53 2009-02-13 22:03 vmlinuz -> /usr/pluto/diskless/75/boot/vmlinuz-2.6.27-11-generic
-rw-r--r-- 1 root root 2244464 2008-11-04 13:00 vmlinuz-2.6.27-7-generic
-rw-r--r-- 1 root root 2244304 2009-01-26 16:34 vmlinuz-2.6.27-9-generic


Note that vmlinux and initrd.img point to what should be the 'correct' files (based on the core's running kernel version).  However, those files aren't installed in the diskless image's file system.  Looking at Diskless_InstallKernel, it looks like it tries to point to the correct files based on 'uaname -r.' However, Diskless_CreateFS.sh, which is run right before Diskless_InstallKernel, unpacks the "/usr/pluto/install/PlutoMD-$Moon_Architecture.tar.bz2" archive to create the file system, which doesn't contain the new kernel.

I guess a solution to this would be for Diskless_InstallKernel.sh to copy the 'correct' kernel (that being the result of 'uname -r') into the diskless MD directory before creating the symbolic link.  However, I'm not sure how to handle kernel moduels and mixed architecture environments with this solution.

What do you think?

26
Devs--

I'm not 100% certain, but the target for 0810 seems to be to allow LMCE to be integrated into the standard aptitude-based package management system (unlike previous versions of pluto/LMCE).  If this is the case, I've noticed a potential issue.  Though the normal software upgrade process, a new kernel (version 2.6.27-11) was installed on the core.  This kernel appears to be too big to tftp to the MDs.  I'm not sure what the config is of the kernels automatically upgraded through aptitude, but it looks like this one has debugging info enabled.

According to http://wiki.linuxmce.org/index.php/Upgrading_the_Kernel

Quote
Your initrd-img file should be about 10MB. If it is around the 40MB mark you compiled your kernel with debugging support. The tftp server will refuse to transfer files this large. As a result, all MDs will fail to boot. If you absolutely must use a debugging kernel then there are options you can pass to tftp to make it ignore this limit.

I haven't been able to find a flag to pass to tftpd yet to disable this.

This brings to mind another question.  If upgrading the kernel on the core is allowed, what is the expectation for the MDs?  Should their file systems be rebuilt (with new kernel, headers, etc)?




27
Installation issues / Re: DISKLESS SETUP FAILED
« on: February 08, 2009, 07:15:28 pm »
Are you running 0710 or 0810?

28
Users / Re: New install advice please - rack mounted, telephony & orbiters
« on: February 03, 2009, 03:14:54 pm »
How about the new fiire system:

http://www.fiire.com/fiire-engine.php

I'm not sure of the current state of fiire, but others can answer that question.

29
Users / Re: Frustrating new Network issue
« on: February 02, 2009, 07:50:51 am »
Guys--

I'm definitely getting this MTU setting from the ISP through DHCP.  Calling dhclient -r; dhclient gets the new MTU.  For now I've set it to 1492 manually by adding the line:
Code: [Select]
pre-up /sbin/ifconfig $IFACE mtu 1492to /etc/network/interfaces

and removing mtu from the list of requested items in /etc/dhcp3/dhclient.conf

I can't explain what was different under 0710 but I definitely did not see this issue then.

30
Users / Re: Frustrating new Network issue
« on: January 31, 2009, 09:55:52 am »
Hari, Colinjones--

Apparently, setting the MTU on windows machines (especially vista) is rather a pain to do.  Instead I followed your previous advice and upped the eth0 (external) MTU to 1500.  Things seem to be working after that.  I'm not sure why the initial settings were different, as both adapters are onboard devices on the core, but this is a new phenomenon on 0810.  The tx queue length is also different, inexplicably.

Thanks a lot for the help guys, it's truly appreciated and I think I can get back to real work now.

Thanks a million

Pages: 1 [2] 3 4 ... 28