Tuesday, June 07, 2016
FATAL ERROR: Failure (1) launching ......../bin/linux-x86_64/elemLinxMgr
Q: Executed a shutdown of an Element cluster via WebUI. Then did "/etc/init.d/element stop" and verified elemBaseLoader and elemLoader are both stopped. Tried starting up Element again and failed due to LINX error :
(element.log)
FATAL ERROR: Failure (1) launching /usr/local/element/file_cache/elem324sc1616/bin/linux-x86_64/elemLinxMgr
(linx_launch.log)
===> Installed LINX kernel modules
Tue Jun 7 15:49:15 PDT 2016
Jun 07 15:49:15 '/sbin/insmod /lib/modules/2.6.27.25-78.2.56.fc9.x86_64/kernel/net/linx/linx.ko 2> /dev/null linx_max_links=128 linx_max_spids=2048 linx_max_attrefs=8192' FAILED
Tue Jun 7 16:26:56 PDT 2016
===> Uninstall LINX kernel modules
Trying to manually insmod this same module, as root, I get an error that the linx*.ko kernel modules are already there:
-1 File exists
But "lsmod" doesn't show any LINX at all. The loader thinks it is there, but it isn't (??)
A: Some systems can get into an odd state on restarts, whereby one can neither insmod nor rmmod the LINX modules. The linx*.ko files are indeed there; deleting them won't help because they'll reappear on the next attempt. There are two possibilities. 1) LINX is really there 2) LINX tried to get in there, but something else beat Element to the punch and installed something in place of protocol # 29 (which is where LINX wants to be). Most of the time, this ends up being a module called Controller Area Network, aka "can". The telltale sign is this (in dmesg, syslog, messages etc)
kernel: can: controller area network core (rev 20081130 abi 8)
kernel: NET: Registered protocol family 29
The easiest way to get rid of this problem is to blacklist "can" forever. The file is either called "blacklist" or "blacklist.conf" depending on your distro.
cat /etc/modprobe.d/blacklist | grep can
....
blacklist can
If you do this, next "rmmod can" (must be root still), then "element stop" and "element start" again, and you should be able to get LINX past this. Users frequently run into this issue, especially when bringing in a new blade or new piece of hardware, or conducting restart/robustness testing for the first time on an established system.
(element.log)
FATAL ERROR: Failure (1) launching /usr/local/element/file_cache/elem324sc1616/bin/linux-x86_64/elemLinxMgr
(linx_launch.log)
===> Installed LINX kernel modules
Tue Jun 7 15:49:15 PDT 2016
Jun 07 15:49:15 '/sbin/insmod /lib/modules/2.6.27.25-78.2.56.fc9.x86_64/kernel/net/linx/linx.ko 2> /dev/null linx_max_links=128 linx_max_spids=2048 linx_max_attrefs=8192' FAILED
Tue Jun 7 16:26:56 PDT 2016
===> Uninstall LINX kernel modules
Trying to manually insmod this same module, as root, I get an error that the linx*.ko kernel modules are already there:
-1 File exists
But "lsmod" doesn't show any LINX at all. The loader thinks it is there, but it isn't (??)
A: Some systems can get into an odd state on restarts, whereby one can neither insmod nor rmmod the LINX modules. The linx*.ko files are indeed there; deleting them won't help because they'll reappear on the next attempt. There are two possibilities. 1) LINX is really there 2) LINX tried to get in there, but something else beat Element to the punch and installed something in place of protocol # 29 (which is where LINX wants to be). Most of the time, this ends up being a module called Controller Area Network, aka "can". The telltale sign is this (in dmesg, syslog, messages etc)
kernel: can: controller area network core (rev 20081130 abi 8)
kernel: NET: Registered protocol family 29
The easiest way to get rid of this problem is to blacklist "can" forever. The file is either called "blacklist" or "blacklist.conf" depending on your distro.
cat /etc/modprobe.d/blacklist | grep can
....
blacklist can
If you do this, next "rmmod can" (must be root still), then "element stop" and "element start" again, and you should be able to get LINX past this. Users frequently run into this issue, especially when bringing in a new blade or new piece of hardware, or conducting restart/robustness testing for the first time on an established system.
Thursday, May 01, 2014
openssl/evp.h , readline.h : No such file
Q: Building element_3.3.0 on a new system and getting:
make[2]: Entering directory `/home/jmir/Element/3.3.0/element_3.3.0/ref_platforms/generic_cluster_haf/output/callouts'
--- Compiling /home/jmir/Element/3.3.0/element_3.3.0/ref_platforms/generic_cluster_haf/../common/callouts/elem_stage_get_digest.c
/home/jmir/Element/3.3.0/element_3.3.0/ref_platforms/generic_cluster_haf/../common/callouts/elem_stage_get_digest.c:39:25: error: openssl/evp.h: No such file or directory
A: Missing packages for part of SSL. For this one, on Ubuntu 10:
sudo apt-get install libssl-dev
This will usually be followed by
cli.c:24:31: error: readline/readline.h: No such file or directory
sudo apt-get install libreadline-dev
make[2]: Entering directory `/home/jmir/Element/3.3.0/element_3.3.0/ref_platforms/generic_cluster_haf/output/callouts'
--- Compiling /home/jmir/Element/3.3.0/element_3.3.0/ref_platforms/generic_cluster_haf/../common/callouts/elem_stage_get_digest.c
/home/jmir/Element/3.3.0/element_3.3.0/ref_platforms/generic_cluster_haf/../common/callouts/elem_stage_get_digest.c:39:25: error: openssl/evp.h: No such file or directory
A: Missing packages for part of SSL. For this one, on Ubuntu 10:
sudo apt-get install libssl-dev
This will usually be followed by
cli.c:24:31: error: readline/readline.h: No such file or directory
sudo apt-get install libreadline-dev
Labels: Element, installation, Ubuntu
Thursday, April 10, 2014
Ubuntu 12 build error : "cannot find -lexpat"
Q: How do I provision a brand-new Ubuntu 12.04 VM ? It appears to be missing some packages.
A: You will need the following, at a minimum, for Ubuntu 12 VMs:
(sudo apt-get install)
expat
libexpat1
libexpat-dev
elfutils (when missing gelf.h)
libelf-dev
openssl
libssl-dev (when missing evp.h)
openssh-server (updated to 1.0.1g for Heartbleed)
At some point you may run into this :
echo " ERROR: Kernel configuration is invalid."; \
echo " include/linux/autoconf.h or include/config/auto.conf are missing."; \
echo " Run 'make oldconfig && make prepare' on kernel src to fix it."; \
For that you'll have to get kernel source tool libncurses5-dev, followed by "make menuconfig" down in /usr/src/linux-headers-... Then you will need to copy the generated autoconf.h up a few levels. You also need (in older Element versions) an update to linx-2.5 to address the issue.
A: You will need the following, at a minimum, for Ubuntu 12 VMs:
(sudo apt-get install
expat
libexpat1
libexpat-dev
elfutils (when missing gelf.h)
libelf-dev
openssl
libssl-dev (when missing evp.h)
openssh-server (updated to 1.0.1g for Heartbleed)
At some point you may run into this :
echo " ERROR: Kernel configuration is invalid."; \
echo " include/linux/autoconf.h or include/config/auto.conf are missing."; \
echo " Run 'make oldconfig && make prepare' on kernel src to fix it."; \
For that you'll have to get kernel source tool libncurses5-dev, followed by "make menuconfig" down in /usr/src/linux-headers-... Then you will need to copy the generated autoconf.h up a few levels. You also need (in older Element versions) an update to linx-2.5 to address the issue.
Wednesday, November 20, 2013
Issues with launching sfk-linux for OSE5.5.1 on Optima 2.8
Q: Trying to debug launch sfk-linux on Optima 2.8 with Fedora FC9. The sfk-linux does not start within the debugger, complaining about flash.mem. When Optima2.8 was started on the command line earlier, this error is seen in the console:
$ ./eclipse -clean
Gtk-Message: Failed to load module "gnomebreakpad":
libgnomebreakpad.so: cannot open shared object file: No such file or directory
(eclipse:6953): Gtk-WARNING **: Unable to locate theme engine in
module_path: "nodoka",
(eclipse:6953): Gtk-WARNING **: Unable to locate theme engine in
module_path: "nodoka",
Exception occurred in monitor receiver thread: java.io.EOFException java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at com.ose.gateway.Command.readHeader(Command.java:91)
at com.ose.gateway.CommandReceive.readReply(CommandReceive.java:74)
at com.ose.gateway.Gateway.receive(Gateway.java:937)
at com.ose.gateway.Gateway.receive(Gateway.java:830)
at com.ose.system.service.monitor.Monitor$ReceiverThread.run(Monitor.java:4709)
Monitor disconnect request failed.
Error disconnecting sender gateway.
Detaching from monitor failed.
A: If you are using sfk-linux from BSP_SFK_OSE5.5.1 with an OSE5.5.1 delivery, there may be issues debugging it a newer version of Optima e.g. 2.8. This setup will generally work fine on Optima 2.7, but there were some changes to Optima 2.8 that cause problems. Migrate the same BSP to use OSE5.5.3 instead of 5.5.1 (just repointing it within environment.mk), rebuild, and most of these problems will go away.
$ ./eclipse -clean
Gtk-Message: Failed to load module "gnomebreakpad":
libgnomebreakpad.so: cannot open shared object file: No such file or directory
(eclipse:6953): Gtk-WARNING **: Unable to locate theme engine in
module_path: "nodoka",
(eclipse:6953): Gtk-WARNING **: Unable to locate theme engine in
module_path: "nodoka",
Exception occurred in monitor receiver thread: java.io.EOFException java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at com.ose.gateway.Command.readHeader(Command.java:91)
at com.ose.gateway.CommandReceive.readReply(CommandReceive.java:74)
at com.ose.gateway.Gateway.receive(Gateway.java:937)
at com.ose.gateway.Gateway.receive(Gateway.java:830)
at com.ose.system.service.monitor.Monitor$ReceiverThread.run(Monitor.java:4709)
Monitor disconnect request failed.
Error disconnecting sender gateway.
Detaching from monitor failed.
A: If you are using sfk-linux from BSP_SFK_OSE5.5.1 with an OSE5.5.1 delivery, there may be issues debugging it a newer version of Optima e.g. 2.8. This setup will generally work fine on Optima 2.7, but there were some changes to Optima 2.8 that cause problems. Migrate the same BSP to use OSE5.5.3 instead of 5.5.1 (just repointing it within environment.mk), rebuild, and most of these problems will go away.
Labels: Fedora, Optima, OSE5.5.1, sfk-linux
Tuesday, October 15, 2013
Compile error in libwhat.o : "syntax error near unexpected token `(' "
Q: I've got a brand-new Linux host set up and trying to build OSE for the first time. The build fails immediately with this error:
--- Compiling ../../modules/src/libwhat.c for obj/sfk-linux/debug/libwhat.o
/bin/sh: -c: line 0: syntax error near unexpected token `('
A: Some OS hosts install without a hostname or host specified. This is especially true for VMWare hosts that are done using "quick install" for the guest OS (this particular problem was seen on a SUSE Linux Enterprise 11 guest). Instead of a hostname at the prompt, you'll see user@(none) or something similar. There is an OSE build flag for -DHOSTNAME that the shell doesn't handle very well when its "(none)" hence the error. Resolve it temporarily by exporting the HOSTNAME to something, and give the machine a permanent hostname in /etc for later.
--- Compiling ../../modules/src/libwhat.c for obj/sfk-linux/debug/libwhat.o
/bin/sh: -c: line 0: syntax error near unexpected token `('
A: Some OS hosts install without a hostname or host specified. This is especially true for VMWare hosts that are done using "quick install" for the guest OS (this particular problem was seen on a SUSE Linux Enterprise 11 guest). Instead of a hostname at the prompt, you'll see user@(none) or something similar. There is an OSE build flag for -DHOSTNAME that the shell doesn't handle very well when its "(none)" hence the error. Resolve it temporarily by exporting the HOSTNAME to something, and give the machine a permanent hostname in /etc for later.
Friday, September 27, 2013
Optima launch error: "Unable to read workbench state"
Q: I tried launching Optima 2.7 and for some reason it thought my C/C++ source view was stale so it requested a refresh of the C/C++ view. Afterward, I am not able to bring up System Browser or System Profiler, or any other Optima tools due to this error:
A: The metadata needs cleaning up. Find optima_win32/eclipse (or wherever the executable is for your case) and run it from the command line once as "./eclipse -clean" to remove any spoiled caches for eclipse. They may have been disordered after refreshing the source view (sometimes happens if you switch between different versions of eclipse). After Optima comes up, shut it down in orderly fashion and relaunch it (without clean) once more. This should resolve whatever cache or plugin inconsistencies cause Optima to forget where the perspective is. If that doesn't help, find your workspace directory and delete .metadata/.plugins/org.eclipse.ui.workbench/workbench.xml to force Optima to revert to the default perspective on startup.
Labels: eclipse, Optima, workbench
Updating LINX within an Element release
Q: I am on element_3.2.3 and want to upgrade the linx version to linx-2.5.1. I copied the linx tarball to the correct place and updated the LINX build version, but am getting this build error now:
make[5]: Entering directory `/element/3party/linx/linux-ppc_85xx/linx-2.5.1'
make[5]: *** No rule to make target `modules'. Stop.
make[5]: Leaving directory `/element/3party/linx/linux-ppc_85xx/linx-2.5.1'
make[4]: *** [/element/ref_platforms/generic_chassis/kernel/2.6.10_mvlcge401_ppc/linx.ko] Error 2
make[5]: *** No rule to make target `modules'. Stop.
make[5]: Leaving directory `/element/3party/linx/linux-ppc_85xx/linx-2.5.1'
make[4]: *** [/element/ref_platforms/generic_chassis/kernel/2.6.10_mvlcge401_ppc/linx.ko] Error 2
A: You're missing an important change that goes with this LINX upgrade - the top-level Makefile for 3party/linx needs to be updated also, due to some changes in the LINX distribution.
Another change (which should be transparent to you if you only build linx via ref_platform) is that there is no Makefile delivered with the linx tarball itself. If you need access to this Makefile for some reason, in 3party/linx/linx-2.5.1 run the "configure" script to generate it.
The full steps to build with support for the newer-style LINX is:
1) update build/versions.mk VERSION_LINX
2) cp linx-2.5.1.tar.gz, updated Makefile and linx-2.5.1-001.patch into
3party/linx
3) rm –rf 3party/linx/linux_x86-64 (or whatever arch)
objects
4) ref_platform, make clean here also
Wednesday, July 24, 2013
Element ACTA build linker error: "corrupted double-linked list"
Q: I've tried to build a distribution for an ATCA chassis which uses
openHPI. At the end stage of the build, when linking occurs the
following linker error occurs:
*** Linking elemNtfLogger
*** glibc detected *** /usr/bin/ld: corrupted double-linked list: 0x00000000021464e0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x33b0a760e6]
/lib64/libc.so.6[0x33b0a7656d]
/lib64/libc.so.6[0x33b0a79385]
/lib64/libc.so.6(__libc_malloc+0x71)[0x33b0a7a911]
/usr/lib64/libbfd-2.20.51.0.2-5.36.el6.so(objalloc_create+0x1d)[0x33b0eaf72d]
/usr/lib64/libbfd-2.20.51.0.2-5.36.el6.so(_bfd_new_bfd+0x2d)[0x33b0e3447d]
/usr/lib64/libbfd-2.20.51.0.2-5.36.el6.so(bfd_fopen+0x2e)[0x33b0e347ee]
/usr/bin/ld[0x41c7f1]
/usr/bin/ld[0x41ccf6]
/usr/bin/ld[0x41ce71]
export CREF_WORKAROUND=yes
*** Linking elemNtfLogger
*** glibc detected *** /usr/bin/ld: corrupted double-linked list: 0x00000000021464e0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x33b0a760e6]
/lib64/libc.so.6[0x33b0a7656d]
/lib64/libc.so.6[0x33b0a79385]
/lib64/libc.so.6(__libc_malloc+0x71)[0x33b0a7a911]
/usr/lib64/libbfd-2.20.51.0.2-5.36.el6.so(objalloc_create+0x1d)[0x33b0eaf72d]
/usr/lib64/libbfd-2.20.51.0.2-5.36.el6.so(_bfd_new_bfd+0x2d)[0x33b0e3447d]
/usr/lib64/libbfd-2.20.51.0.2-5.36.el6.so(bfd_fopen+0x2e)[0x33b0e347ee]
/usr/bin/ld[0x41c7f1]
/usr/bin/ld[0x41ccf6]
/usr/bin/ld[0x41ce71]
A: This is a known issue that occurs very infrequently, and only with certain GCC toolchains, e.g. it was seen with Red Hat gcc 4.4.7, and MV CGE 5 gcc 4.2.0 for PPC. The non-obvious root cause is that building with --cref causes issues for
some GNU linkers. To work around this issue, in ELEMENT_ROOT/build/targets/ppc.mk (or whichever target applies), add the following:
export CREF_WORKAROUND=yes
This will prevent Element from using the "--cref" switch when linking
the executables.
Labels: ATCA, Element, Element ChassisMgmt install
free invisible web counter