Dell E6410 Fedora 13 32-bit Linux install and mini review

This is a catch up article. More of a documentation piece of (past) success than a current Fedora 13 review.

This Fedora install is a stock 32-bit DVD install (PXE install failed issue with flashing video problem). The target system is a nice Dell E6410 with 4GB RAM, Broadcom BCM4313 802.11b/g, nVidia GT218 [NVS 3100M] rev 162 dedicated video card and Intel I7 CPU. Let me just add the note here and state, for the record, that the Intel I7 ROCKS! The E6410 is a physically solid chassis with precise feel. No cheap feeling plastic on this bad boy. The LCD hinge is firm and smooth with no lateral wiggle or bounce issues. The 14.1 inch screen is bright with no dead pixels. Screen glare is fairly minimal and the function brightness control is handy. I have been a big fan of the Dell Latitude laptops for a long time. The product line continues to excel in many ways. However, please don't mistake this unit for any ultra-portable! Especially with the longer runtime extended battery.

Install with Fedora DVD is best accomplished with the "Basic Video Driver" install selection. Otherwise the screen flashing techni-color screen makes it impossible to install. I choose to install with whole disk encryption as a general rule for any laptop. Let me just say that it is easier to type in a pass-phrase every once in a while than it is to explain why all of the confidential emails or data from a boss is floating around the internet. I will file whole drive encryption under the "CYA" category. Basically, install is click-button-simple. Besides my video issue and encryption desire, there was no real need to not click "next" button when presented. All of the Linux distributions have made HUGE progress in ease of installation over the years. And Fedora is no exception!

Reboot after install leads to a rather disappointing 800x600 resolution login screen. At least there is a login screen at all. First a quick key sequence to dump me to console in order to log in as root in order to do a full update and reboot just to see if that will help my screen resolution issue with the *default* install. I do need to note, I have a standard practice that on any NVIDIA installation, I get the kmod-nvidia drivers or the official NVIDIA driver installed as quickly as possible. I want to see about "stock" install at this point ... but no luck... Sadly, in order to get the 1280x800 capable on this 14.1 WXGA (not WXGA+!) LCD panel I install the kmod-nvidia-PAE drivers (I'm running PAE kernel). However, I still end up with the long dreaded invalid pointer problem and need to remove the "InputDevice" lines in the /etc/X11/xorg.conf file. A reboot an all is better now with video.

The Broadcom BCM4313 is not working out of the box. A quick bit of google'n and an install from the rpmfusion-nonfree-updates repository used for the kmod-nvidia above:
yum -y install broadcom-wl kmod-wl-`uname -r`
modprobe wl
makes the wifi issue go away without the need to reboot. Cutting the ethernet cord an goin' mobile now.

The bluetooth functions without issue. I could pair with my Droidx in seconds. Nice.

Helpful links:
E-Family Reimage “How-To” Guide
E6410 Manuals

Fedora 15 beta first impressions - aka mini review

First and foremost please remember THIS IS A BETA. There are going to be issues. However, I find myself more fixated with my issues with the GNOME 3.0 interface than anything else. I know Fedora HAD to move on and stay with the latest and greatest GNOME release. After all that is what is Fedora is known for (and the reason I prefer CentOS/RHEL for servers!). More on GNOME shortly.

My Fedora 15 beta test attempt is happening on real hardware. No virtual container. It's a Dell D630 laptop with 2GB RAM, a dual core Intel T7500 and dedicated nVidia G86M Quadro NVS 135M video card. WIFI is handled by the Broadcom BCM4312 802.11a/b/g chipset. Modest by today's standards.

Normally for laptops, I will do whole disk encryption using a kickstart file. This is just a plain, "select some defaults" and install test. Install worked without issue (as expected). In fact, installs have been very easy for a long to the point of being almost boring. Really just a few clicks and I was done.

Start-up for Fedora 15 beta is very fast. Though not timed, the perceived boot time difference from Fedora 13 to Fedora 15 seemed significant. More specially, Fedora 15 boot time is faster. If I get bored, I may consider actually install Fedora 13 or 14 again just to time the boot-to-login screen time. Many people dig that.

Initially, I was interested in how the nouveau video driver was going to handle my Quadro NVS 135M. Not a real common chipset. The former nv driver has woefully inadequate to say the least. The install and/or nouveau found the LCD SVGA+ 1440x900 without any problems. For any other NVIDIA installation, I would get the kmod-nvidia drivers or the official NVIDIA driver installed as quickly as possible. I'm going to stick it out with nouveau for now. No urgent video need to bail just yet. Not a big compiz fan, however, so that's off.

The install found my wireless card (Broadcom model BCM4312 a/b/g) without any issue. I was able to see AP's in the area. It's nice to see this, "just work". However, wifi passphrase didn't seem to work for some reason. I had to put in the hex key instead in order to connect to the test wifi router. In addition, getting connected to an access point seems to take several seconds longer that with Fedora 13 and GNOME 2.30.

Now for the BIG CHANGE... GNOME 3.0! Not sure if it's Fedora's ruff edges on this beta or my shear newness with GNOME 3.0, but wow it's hard to get used too. Don't get me wrong, a window manager that stays out of your way is good! But one that you can't figure out how to change (yet)?! I was kinda overwhelmed with the Activities and trying to guess under what category a program would be under. Select all and just keep looking. All I wanted to do was fix my touchpad issues. Need to middle click paste with the double mouse button touch pad on the Dell? Can only use the bottom set of buttons... Not sure why yet. I've gotta tell you I use middle mouse/double mouse button paste A LOT as my typing speed and skill is not the best. Also, spent 10 minutes trying to figure out if I could get System Monitor back on my screen or CPU scaling info... and never did...

My solution, at the moment, to GNOME 3.0 is to run LXDE instead! Thank goodness for choice at this time. My frustration rate is high GNOME and back to basics is good. I will likely make more attempts to use the new GNOME, just not tonight.

CentOS 5.x bugzilla 3.2 blank page...

This may be more of a rant... I mean the whole purpose of having a "checksetup.pl" in bugzilla is to, well, check the bugzilla setup... It looks like they should add at least one more check (or I should take better care to read the instructions)...

So, a basic/minimal install of CentOS 5.6 and bugzilla I'm greeted with a non-helpful "failed to connect" page and a /var/log/httpd/error_log message of:

[Tue Apr 19 13:10:15 2011] [error] [client xx.xx.xx.xx] [Tue Apr 19 13:10:15 2011] index.cgi: Use of uninitialized value in substitution (s///) at (eval 42) line 44.
[Tue Apr 19 13:10:15 2011] [error] [client xx.xx.xx.xx] [Tue Apr 19 13:10:15 2011] index.cgi: Use of uninitialized value in concatenation (.) or string at Bugzilla/CGI.pm line 312.

Following google search links proves useless (which is not often the case).

I added all of the interesting perl modules that bugzilla may want. Modules like perl-DateTime, perl-List-MoreUtils, perl-PatchReader, perl-HTML-Scrubber, perl-Template-GD, perl-GD-Graph, perl-Chart and ImageMagick-perl (plus their dependencies). /usr/share/bugzilla/checksetup.pl ran without issue, produced no error, fixed and rebuilt etc... still the error... paying a tiny bit more attention to the area around line 312 in Bugzilla/CGI.pm, I finally notice https redirection code... Wait, bugzilla defaults to requiring https but does not check for https... finally problem solved. The solution is just to install "mod_ssl".

CentOS 5.6 GitCO xen 3.4.3 kernel, libvirt-client and xen-libs update issues

A recent CentOS 5.5 to 5.6 update has caused one of my xen servers to stop functioning... This has happened few times in the past... and I keep forgetting to look before I reboot. Maybe documenting it here will help me remember and help others QUICKLY get past the xend failing to start with the error of:

[2011-04-16 15:34:19 5082] INFO (SrvDaemon:336) Xend changeset: unavailable.
[2011-04-16 15:34:19 5082] ERROR (SrvDaemon:349) Exception starting xend ((13, 'Permission denied'))
Traceback (most recent call last):
File "/usr/lib64/python2.4/site-packages/xen/xend/server/SrvDaemon.py", line 341, in run
servers = SrvServer.create()
File "/usr/lib64/python2.4/site-packages/xen/xend/server/SrvServer.py", line 251, in create
root.putChild('xend', SrvRoot())
File "/usr/lib64/python2.4/site-packages/xen/xend/server/SrvRoot.py", line 40, in __init__
self.get(name)
File "/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py", line 84, in get
val = val.getobj()
File "/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py", line 52, in getobj
self.obj = klassobj()
File "/usr/lib64/python2.4/site-packages/xen/xend/server/SrvNode.py", line 30, in __init__

Here is the deal. We have been using the Xen 3.4.3 repo from Gitco. For some reason yum will not keep the "kernel" line that matches up with the xen install from xen-3.4.3. So, the VERY simple fix (till the next kernel update) is just to make sure that your grub.conf has a line of "kernel /xen.gz-3.4.3" and not whatever gets dumped there by yum. Hope this helps people with this error.

The second issue with the (finally) released CentOS 5.6 update related to using the xen 3.4.3 from GitCO is the inclusion of the libvirt-client-0.7.0-6.el5. This is now an older version with the 5.6 update now out. The error you see from try a yum update is:

Transaction Check Error:
file /usr/bin/virsh from install of libvirt-0.8.2-15.el5.3.x86_64 conflicts with file from package libvirt-client-0.7.0-6.el5.x86_64
file /usr/bin/virt-xml-validate from install of libvirt-0.8.2-15.el5.3.x86_64 conflicts with file from package libvirt-client-0.7.0-6.el5.x86_64
file /usr/lib64/libvirt.so.0 from install of libvirt-0.8.2-15.el5.3.x86_64 conflicts with file from package libvirt-client-0.7.0-6.el5.x86_64
file /usr/share/libvirt/schemas/capability.rng from install of libvirt-0.8.2-15.el5.3.x86_64 conflicts with file from package libvirt-client-0.7.0-6.el5.x86_64

The fix is:

rpm -e --nodeps libvirt-client
yum update

If you accidentally got the old i386 xen-libs, just run:

rpm -e xen-libs.i386
yum update