We started as most people would, Googling for numerous combinations of “fedora 14 thinkpad T520″, “sandybridge linux”, “sandybridge fedora”, etc. The results were surprising. Numerous sources report the T520 works with “no special setup needed.” This was not true for us. We Tried installing a newer Kernel from rawhide and the newer xorg-x11-drv-intel driver (2.16). This did not fix the issue.

To compound our confusion, we noticed numerous posts referencing a BIOS option to disable the Nvidia 4200M (Optimus) card. Our system showed no signs of said card or any “internal”/”external” BIOS option.

Next we attempted installing Fedora 15. *ugh* GNOME 3 was not on our list of things to try today. But it was all we could think of.

This also did not work.

I started doing some heavy research. Somehow I ended up researching Kernel Mode Setting (KMS). The Debian Wiki was an especially useful resource for this.

Kernel Mode Setting (KMS) provides faster mode switching for X and console. It also provides native-resolution VTs on some laptops and netbooks which, prior to this, would use some standard mode, e.g. 800×600 on a 1024×600 panel.

This was relevant to my interests. “KMS provides native-resolution virtual terminals” you say? A quick trip to /boot/grub/grub.conf showed that we were booting our kernel with the nomodeset option. We made a new boot entry (protip: never change your boot loader without leaving a known “working” entry) and omitted the nomodeset option. We also set the value of the default variable to our new entry, set timeout to 10, and commented out the hiddenmenu directive.

This almost worked. We removed the xorg config file (/etc/X11/xorg.conf) and restarted the computer for good measure.

voila.

Our Lenovo Thinkpad T520 was booting X using the laptops native resolution.

Just to clarify:

• Not ALL T520s come with the dual Intel Integrated Graphcs + Nvidia combination (ours did not)
• This can really throw you off
• The xorg-x11-drv-nouveau package/driver had nothing to do with this. That package provides an Nvidia driver (which did not affect us)
• The kmod-nvidia package/driver also has nothing to do with this
• This laptop has an integrated Intel HD 3000 Graphics chipset

• Debian/Fedora Package Management comparison. Since switching my Slice to Fedora from Ubuntu I’ve picked up plenty of commands for managing packages. This is just a quick wiki page giving the roughly equivalent commands from Debian/Ubuntu to Fedora/RedHat.
• regexp basics is a brief tutorial on regular expressions. My roommate abutcher put it together for his WVU CS210 (Advanced File and Data Structures) course. The DocBook 5 sources are available in git.
• The biggest doc project I’ve been working on again (finally) is my Virtual Disk Guide aimed at power users and sysadmins. Currently it’s a rough draft and is constantly undergoing major changes and additions. It’s available as a single HTML document, chunked into multiple pages, and in PDF format. You can get the DocBook 5 formatted source to it through my GitHub account.

My Project Templates project has seen some much needed attention recently. The DocBook starter project has been completely redone. Here’s some reasons you might want to use it.

• Includes a basic starter document with most of the available informational tags present but commented out so all you need to do is uncomment the elements you need for your document.
• Inclues a customizable Makefile that can adapt itself to different operating systems (Debian/Ubuntu, Fedora/RedHat, and Mac OS X) by just uncommenting the proper directory paths for the schema and stylesheet files.
• The Makefile has targets for: cleaning up, creating schema locator files for nxml-mode in emacs, publishing PDFs, and publishing chunked or single HTML documents.
• The comments in the Makefile also tell you what packages you need to install to get the schema and stylesheet files.

Using the Makefile for publishing only requires having xsltproc and dblatex installed. Both of which are available through your favorite package manager.

Obviously being a systems administrator it becomes your job to figure out what can go, what needs to stay, et al.

I’ve found that archived logs (logrotate) on a secure server often can be quite large. And on a low-end configuration with a server with only 40G it becomes a nuisance when you have a few Gb of data…
And you all probably know this, but Tim asked when I’d blog. So… I’ll make sure!
Having 40 or 50 files is a pain to manually delete. Sure, you could probably rm -f *.1 *.2 *.3 etc etc etc but that becomes too much of a pain.

On BSD systems there is an awesome counter called ‘jot’; it works exactly the opposite of the GNU command ‘seq’; so for a rudimentary example to remove all files it becomes a simple one liner–

• jot 6 1 |while read i; do rm -f *.${i};done
• seq 1 6|while read i; do rm -f *.${i};done

In Emeril fashion: BAM! You’re now out of the clear.

The problem: Both the first time I built this server, and most recently when I rebuilt it to Jaunty Jackalope, the system locales weren’t configured. I understand why this is done, that it happens doesn’t bother me. That I had a hard time finding out how to properly set my locale frustrated me a little bit.

How do you know if your locales aren’t correctly defined? On my Jaunty Jackalope system I see messages like this:

locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default
locale: No such file or directory

I tried running dpkg-reconfigure locales, but that had no effect. Searching the Internet for the messages above provided a couple of possible solutions, but none of them looked like anything I was interested in. I’m a firm believer that if the Internet tells me to run a command with more than a couple of options, that it may work, but there is probably an easier, less cryptic solution. For example:

localedef -v -c -i en_US -f UTF-8 en_US.UTF-8

No way I’m running that. I instead searched for “slicehost locale” and found this article: Ubuntu Hardy setup. I enjoy this much more:

locale-gen en_US.UTF-8
 
update-locale LANG=en_US.UTF-8

Turns out that update-locale is a Debian/Ubuntu specific command. It update your systems default locale setting file. I had checked for one before running it and found that none existed yet on my system. After running those two commands above I found one had been created with “LANG=en_US.UTF-8″ in it. It’s possible that running update-locale could have been all I needed to do to begin with.

I hope this helps some one else whose had this problem before or for the first time.