[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20051102: Upgrading from FC 1 to FC 4



>From: Gilbert Sebenste <address@hidden>
>Organization: NIU
>Keywords: 200511022216.jA2MGA7s022056 LDM Fedora Core 3/4 syslogd

Hi Gilbert,

>I am about to upgrade weather3.admin.niu.edu from Fedora Core 1 to Fedora 
>Core 4 on Monday.

Sounds good.

>You warned me if I did this, to contact you ahead of 
>time because there are several "gotchas" I need to watch out for, 
>including, if I recall correctly, logging of LDM logs.

Yup.  In order for you to keep using syslogd for LDM logging ** at the
current time ** you will need to disable SELINUX.  This is done by
editing the file /etc/selinux/config and:

change:

SELINUX=enforcing

to:

SELINUX=disabled

and then rebooting.

We are working to understand Selinux better so that we can come up with
needed entries for syslogd.te so that the LDM can keep use syslogd for
logging.  Currently, if SELINUX is set to enforcing in /etc/selinux/config,
a user process is prevented from using syslogd for logging.

>What else do I need 
>to watch for, and how can I help get it right the first time?

I have also noticed that as machines get faster and the versions of
Linux get newer, folks have been having more and more problems building
McIDAS-X.  The cause for the problem is apparently something in the OS
where memory cached information is not being written out to disk.
Explicitly what happens is that object modules that are correctly
created by the C (gcc) or Fortran (g77) compilers do not get added to
one or both McIDAS libraries libmcidas.a and libsdi.a.  The result of
this failure to add the entry point the library is that a link will
fail at some point further in the make process.  The procedure I have
found to work is to look at the end of the make log file (makelog) to
see what object module(s) were not found in which library and then
manually add it/them and continue with the build.  My most recent brush
with exactly this situation was on a FreeBSD 5.4 machine where the
object module nexrutil.o was not added to libmcidas.a.  In that case,
it was the only object module not added to the library.  The manual
sequence in this case was:

<as 'mcidas' doing a build in the ~mcidas/mcidas2005/src directory>
less makelog
ar r libmcidas.a nexrutil.o
ranlib libmcidas.a
make

Just so you know, this failure is not dependent on the version of
McIDAS being built -- it occurs for all versions.

Also, just so you know, I run Fedora Core 4 on a 700 Mhz PIII machine
at home (i.e., a slow machine), and I have NEVER experienced a problem
with object modules not being added to a library.  I have only seen the
problem on newer, _faster_ machines.

That is all I can remember at the momment.

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.