Date: July 11, 2013

Introduction

This was my second system to upgrade via yum to Fedora 19. See the notes on my first system:

Problems

The upgrade itself went very fast, taking less than an hour to install all the packages from a local mirror over a gigabit LAN. Problems manifested after the reboot. The first of which was:

No network

I can't ping or run a useful browser, ifconfig shows an interface called "eno1" which I have never seen before, but it is not UP. Doing service network restart fails. Trying ifup eth0 or ifup em1 both fail. I grep through dmesg for "eth" and find: 
 systemd-udevd[269]: renamed network interface eth0 to eno1
This is a clue. I go to /etc/sysconfig/network-scripts and copy ifcfg-eth0 to ifcfg-eno1, make a few trivial edits, then do: 
service network restart
service httpd restart
Yeah, I could (should?) be using the systemctl command just to get into new habits, but I fall back to my old ways when the pressure is on. This gets me on the air and I can use google to find out what fool nonsense this new interface name is all about.

The Fedora buzzword for this insane hassle is "Predictable Network Interface Names", which is the best joke I have heard in a long time.

I thought they had got this all out of their system back when they renamed eth0 to em1, but apparently they liked that so much they are doing it yet again.

The fix to turn this off is to create the following link: 

cd /etc/udev/rules.d
ln -s /dev/null 80-net-name-slot.rules
Indeed after creating this link and rebooting, I have eth0 instead of em1 or eno1.

rsh is broken, cannot boot my diskless vxworks machines

After the upgrade I ran find /etc /var -name "?*.rpm?*" to find various rpmnew and rpmsave files left by the upgrade process. The rpmnew files I merged into their proper places and deleted. The rpmsave files I generally deleted, but one caught my eye: 
/etc/xinetd.d/rsh.rpmsave
Being curious, I left this as it was and tried booting my diskless systems that I know rely on rsh, and indeed they fail to boot. I then renamed this back to /etc/xinetd.d/rsh and did a service xinetd restart and now the systems can boot.

Starting my web server after boot

My webserver is not starting after boot like it should. I see the message: 
Jul 11 15:47:58 cholla systemd[1]: matlab-lm.service: control process exited, code=exited status=1
Jul 11 15:47:58 cholla systemd[1]: Failed to start Mathworks License Manager.
Jul 11 15:47:58 cholla systemd[1]: Unit matlab-lm.service entered failed state.
Jul 11 15:47:59 cholla ntpd[577]: Listen normally on 4 eth0 199.104.150.52 UDP 123
Jul 11 15:47:59 cholla ntpd[577]: Listen normally on 5 eth0:mmt 192.168.100.52 UDP 123
Jul 11 15:47:59 cholla ntpd[577]: peers refreshed
Jul 11 15:47:59 cholla httpd[938]: AH00557: httpd: apr_sockaddr_info_get() failed for cholla.mmto.arizona.edu
Jul 11 15:47:59 cholla httpd[938]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
Jul 11 15:48:01 cholla ntpd_intres[639]: host name not found: 0.fedora.pool.ntp.org
Jul 11 15:48:01 cholla ntpd_intres[639]: host name not found: 1.fedora.pool.ntp.org
Jul 11 15:48:01 cholla ntpd_intres[639]: host name not found: 2.fedora.pool.ntp.org
Jul 11 15:48:01 cholla ntpd_intres[639]: host name not found: 3.fedora.pool.ntp.org
Jul 11 15:48:01 cholla systemd[1]: Started MySQL database server.
Jul 11 15:48:02 cholla kernel: [   24.514111] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Jul 11 15:48:02 cholla kernel: [   24.514150] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
I find that if I disable nscd (systemctl disable nscd.service), then httpd will start up. This is some kind of race condition fostered by systemd (and we have seen our share of those).

I add ServerName cholla.mmto.org:80 to httpd.conf, but I still get: 

unable to find IPv4 address of "cholla.mmto.arizona.edu"
It is interesting that it is using the name that it probably got from /etc/hostname, rather than the name I gave it on the ServerName line.

I filed this as a bug:

The issue with ntp is only transitory, it sorts itself out later, most likely this is something related to nscd not yet getting started.

The matlab license manager is not starting

This fails whether nscd is running or not. It looks for eth0, so it is possible that at the moment the license manager is starting up, we are using one of the alternate fedora names.

Rails is broken

There is the ruby - psych thing described HERE in my description of my first upgrade.

But, for some reason this system has worse problems, and when I try to do bundle install or bundle update, I get: 

cannot load such file -- rubygems/format (LoadError)
On a whim I do "gem update", and indeed after this I can run bundle update and bundle install. However, bundle install must be run before bundle update to get the psych thing fixed up. So, to get things patched up: 
gem update
gem uninstall libv8 (all versions)
gem install therubyracer -v '0.10.1'
bundle install
bundle update
bundle install
There was some odd snafu with libv8 and "therubyracer" versions that bundle could not sort out by itself, but the above rain dance worked, and the final bundle install actually didn't install anything. After this, I get: 
SECURITY WARNING: No secret option provided to Rack::Session::Cookie.
This poses a security threat. It is strongly recommended that you
provide a secret to prevent exploits that may be possible from crafted
cookies. This will not be supported in future versions of Rack, and
future versions will even invalidate your existing user cookies.
This application runs Rails 3.2.6, and what I am reading says that I can safely just ignore this warning, ultimately it is a rails bug. Updating to Rails 3.2.11 or 3.2.13 is one fix.

At any rate, this has this old rails project running under Fedora 19.

Have any comments? Questions? Drop me a line!

Adventures in Computing / tom@mmto.org