Not sure this problem comes from Upstream, but in setting up a Scientific Linux 6.1 workstation today I found myself unable to successfully configure CPAN… among other things. Story follows.
My desktop at work failed recently and the boys in Support were kind enough to ship me a brand new Dell Optiplex 790 to replace it.
The old machine had been running CentOS 5.7 and I thought I’d take the opportunity to upgrade myself to Scientific Linux 6.1, since that’s what I’m now running at home.
The first problem I encountered was due to the evil that is NetworkManager. If there is one piece of software I hate more than every Oracle server application combined, it is NetworkManager.
Basically the thing you need to remember about NetworkManager is this: you can’t live with it, and you can’t live without it.
My advice is to go through your initial install and let NM do its thing. Don’t bother trying to configure your machine for static IP until the install is done. Once it is you can shut down NetworkManager, “/etc/init.d/NetworkManager stop”, and disable it, “chkconfig NetworkManager off” (a word of caution: do not delete or remove NetworkManager from your system).
Once that’s done, you can run “system-config-network” and set up your interface the way you want. Be sure to hit “Save and Quit” at the end. Check /etc/hosts and /etc/resolv.conf to make sure they’re set up correctly. Also be sure to add “NM_CONTROLLED=no” to your /etc/sysconfig/network-scripts/ifcfg-[devicename] scripts (including ifcfg-lo). In my case this was “ifcfg-em1”. Here’s what it looks like:
HWADDR=18:03:43:ce:2b:4e TYPE=Ethernet BOOTPROTO=none DEFROUTE=yes PEERROUTES=yes IPV4_FAILURE_FATAL=yes IPV6INIT=no NAME="em1" UUID=5fe2ec93-5208-4adc-a490-8e206a7a6d5a ONBOOT=yes NM_CONTROLLED=no IPADDR=10.4.100.25 NETMASK=255.255.255.0 GATEWAY=10.4.100.1 DNS1=10.1.1.2 DEVICE=em1 USERCTL=no
The name for my network device, “em”, is actually short for “embedded”, and is part of a new convention that labels devices based on their physical location. This is described in the Red Hat Enterprise Linux 6 Deployment Guide, and in a Dell whitepaper, Consistent Network Device Naming in Linux. It was first introduced as a feature of Fedora 15.
Another thing I ran into was root not being able to set up CPAN (for installing perl modules not available from any reputable yum repositories).
This took a little digging to figure out.
Basically the problem turned out to be twofold. First, Config.pm under /usr/share/perl5/CPAN had to be deleted — probably due to my first ham-handed attempt to configure. This required my re-running the configuration.
To accomplish that I did the following as root:
[root@myhost CPAN]$ perl -MCPAN -e shell cpan> o conf init
The other problem seemed to be with the CPAN configure script itself. Basically it kept prompting me for a CPAN mirror site url and then failing.
Getting around that required deviating from my normal modus operendi by answering two questions differently that I have for over a decade working with perl:
“Would you like me to configure as much as possible automatically?”
“If no urllist has been chosen yet, would you prefer CPAN.pm to connect to the built-in default sites without asking?”
Going through the full list of questions wasn’t painful, of course, just a bit annoying. My guess is the problem was with some change in the ordering of the questions or responses expected, but I’m just too tired now to try proving it.
Finally, when issuing a “reboot” the system would go all the way to “Restarting system…” and then just hang. This turns out to be a fairly common problem that has been attributed to a variety of different causes.
The most common explanation seems to be with how ACPI interacts with some hardware. For example in [SOLVED] RHEL 6 shutdown problem, the author found that setting “acpi=force” and “pci=noacpi” in grub.conf resolved the issue. [RESOLVED] reboot hangs at “Restarting system” console msg – no warm reset! describes a similar problem. In Dell Optiplex 790 Workstations hang while rebooting with CentOS 6, appending “reboot=pci” to the in grub.conf to the kernel init was found to resolve this issue. This, as it turns out, is what worked for me.
Common Kernel Problems, from the Fedora Project, is a good guide to dealing with kernel-related oddities of this kind in Red Hat Linux.
CentOS: Disable Unneeded Services at Boot Time, is a terrific article enumerating the veritable pile of services on most Red Hat/Linux systems that should probably be shut off — and shows how to do it.
For remote desktop access I chose to remove the shipping vino package and installed tigervnc and tigervnc-server. Initially I tried things with the .vnc copied over from my home directory backup. When this failed I removed it and allowed tiger to build its own configuration. That worked fine. The only difference is that tigervnc server defaults to displaying desktop graphics (vncserver on earlier RH versions serves up a bare bones twm session, much better for low-bandwidth situations but not as pretty).