John Smith's Blog

I recently upgraded to the 302.17 nVidia Linux drivers, which broke my dual head setup somewhat, and required a bit of manual reconfiguration to get things working properly again. Although all the information is available online, I thought it worthwhile writing a quick post in the event someone else has a similar issue.

Firstly, a quick overview of my setup. I have a GeForce GTS450, although up until a month ago I was using a GeForce 315 with the same config, so I imagine the particular model of nVidia card is largely irrelevant. Out of this card I have two LCD monitors connected via DVI and HDMI:

• on the left, an HP2045w rotated 90 degrees, so that the screen area is 1050 pixels across by 1680 pixels deep
• on the right, a Dell S2209W, resolution is 1920x1080

In Linux/X11, the screens are set up separately, so I can switch between workspaces on just one screen, which I find very useful. The only downside is that it's not possible (AFAIK?) to drag a window from one screen to the other, but this is a hardship I've learnt to live with. (NB: When this machine dual-boots into Windows, I have a more standard "one big desktop", but as I rarely use Windows for "real work", I've never bothered to investigate what other options are available.)

Anyway, after upgrading the drivers, and letting the nVidia installer update my xorg.conf - I was disappointed to find that my portrait monitor was showing Xfce at a 90 degree angle, and on the "wrong side" of the displays. (I don't normally let the nVidia installer alter my xorg.conf, but as this version of the drivers apparently fixes/improves RandR support, I thought it best to let the installer do its own thing.

Now, these issues wouldn't be the end of the world, but it seems that nvidia-settings hasn't been upgraded to align with how this latest driver works. As such, it came down to a bit of manual editing of xorg.conf...

Firstly, fixing the relative positioning of the screens was a fairly straightforward edit to the ServerLayout section: Section "ServerLayout" Identifier "Layout0" Screen 0 "Screen0" 1680 0 Screen 1 "Screen1" LeftOf "Screen0" InputDevice "Keyboard0" "CoreKeyboard" InputDevice "Mouse0" "CorePointer" Option "Xinerama" "0" EndSection Looking at some older versions of the config, I reckon this broke because the enumerations of the two monitors got swapped around. Not quite sure how/why that happened, or how the card/driver is supposed to work out which is screen 0 and which is screen 1, but as it's a simple fix, it's not worth wasting much thought on.

More troublesome was getting my portrait screen displaying correctly. Firstly I verified that portrait display was still possible, via xrandr from the shell prompt: xrandr -d :0.1 -o left (BTW, one minor thing to be wary of when doing this, was that using the configuration I had at the time, it created a "dead space" between the two screens such that it was not possible to move the mouse from one screen to the other.)

With this proven, it was time to work out why my old configuration wasn't working. Previously I'd had this for my portrait screen: Section "Screen" ... Option "RandRRotation" "on" Option "Rotate" "CCW" ... EndSection A look at the Xorg log in /var/log/ gave an indicator as to why this was no longer working: [ 135.480] (WW) NVIDIA(0): Option "RandRRotation" is not used This change in functionality is also mentioned in the release notes, albeit buried a long way down:

Removed the "RandRRotation" X configuration option. This enabled configurability of X screen rotation via RandR 1.1. Its functionality is replaced by the "Rotation" MetaMode attribute and RandR 1.2 rotation support. See the README for details.

Unfortunately, this wasn't the end of the story, as a lot of the text on the portrait display was appearing much smaller than it should have. This appeared to be due to a confusion over the DPI and physical size of the monitor screen: xdpyinfo showed similarly incorrect information for this screen: [john@hamburg X11]$ xdpyinfo | more ... screen #1: dimensions: 1050x1680 pixels (430x270 millimeters) resolution: 62x158 dots per inch ... Now, I'd previously put in a hacked DisplaySize value in the relevant Monitor section, as a means to make a bitmap font appear the way I wanted, but after fiddling with this value, it seems to no longer have any effect.

In the end, I found a reference to a DPI setting in the xorg.conf man page, and adding this to the Screen section fixed things nicely: # Screen 1 = HP Section "Screen" ... Option "DPI" "100 x 100" ... EndSection And now I have things back working as they were before!

Unfortunately, none of the positive changes I'd hoped for have occurred - I'm still getting nasty tearing, even though V-sync appears to be enabled everywhere it can be. Maybe one day I'll get that resolved...

Spent a few hours today playing with Puppet, which I'd been meaning to have a look at for ages.

I followed a beginner's tutorial, which didn't work - Puppet failed to stop or start ntp in the way the tutorial describes. In and of itself, this didn't bother me - in fact, I often find it useful when things screw up, as it forces you to start digging in and investigating, at which point you start learning how things really work.

What was a bit annoying though, was the lack of any obvious warnings or errors, either in the output, or in the log files. (Puppet logs to both /var/log/messages and files in /var/log/puppet/, but the former had nothing useful, and the latter just contained incomprehensible HTTP request URLs.)

Never mind, I thought, I'll just check the man page. This is what I got:

It doesn't look to be an issue specific to my distro either.

I don't give a damn how good any project's online documentation is; something that is going to be interacted with from a *nix command line - especially when aimed at a system admin audience - should have a manpage that at least covers some of the basics in a modicum of detail. I don't care for the GNU stuff that pushes you towards the info command that I've never seen anyone actually use, but compared to Puppet, they're wonderful.

Obviously Unix manpages are far and away from being the new hotness, and the lack of stuff like proper hyperlinks is a bit annoying in this day and age, but the fact that they have survived this long shows how useful they are. If the author(s) of a tool can't be bothered to spend a few hours putting together a half-decent manpage, then I'm not sure I feel inclined on spending any time bothering to research and learn that tool.

EDIT: I've just seen that you can do puppet describe {string} to get something that's roughly comparable to a proper manpage, just inferior in pretty much every respect. (e.g. no nice formatting on a terminal that supports bold or underline, having to pipe into more/less/etc if you want to page it) Too late though, I'm moving on...

EDIT#2: On further investigation, I'm not sure what puppet describe or puppet doc actually do, but it's certainly not providing docs about the subcommands such as "agent", "apply", "cert", etc as mentioned in the manpage.

It's over two months since I first started this series of posts, and to be honest, anything that hasn't already been written up, I've largely forgotten about. Not to mention, Fedora 15 has since come out, so anything specific to version 14 is already out-of-date. However, after writing up so much already, it seems only right to try to come to some sort of conclusion.

First off - although it didn't come into play until later in the process - Fedora 14 initially shipped with a broken version of the pyxf86config package. This caused a failure to set the display refresh rate correctly when I got the proper drivers installed, so before doing anything, yum update that to a fixed version.

This machine uses a "Poulsboro" (aka Poulsborough aka Poulsbo) chipset, which seems notoriously ill-supported on Linux. However, there are (non-free) packages available for this chipset, I ended up installing the following:

• kmod-psb
• kmod-psb-PAE
• limdrm-poulsbo
• livna-config-display
• psb-firmware
• xorg-x11-drv-psb
• xpsb-glx

When all this is in place, Fedora switches to the native resolution of 1366x768, and the machine is pretty much as usable as you might reasonably hope. Because of the way I installed the wifi drivers, every time I've upgraded to a new kernel, the wifi has broken. So far I've just kept with the older kernels - by selecting them via the relevant grub boot option - but I assume it's just a case of recompiling the modules under the new kernel, or hopefully replacing them with a package which will automatically update itself in line with the kernel.

Anyway, hope all this is/was of some use to someone out there...

Netbooks obviously have a bit of a flaw when it comes to installing Linux distros - namely their lack of an optical drive. Many distros now offer easy means of making a USB key, but Fedora's process is a bit of a faff-around.

In particular, I was rather annoyed to find that it wouldn't actually fit on the 4GB USB drive I had earmarked for it - as well as the ~3.5GB ISO image, there's a separate boot image that you have to install, that pushes it over the age. Fortunately, I did have some 16GB drives kicking around, and after clearing out some old files, I had enough space for Fedora 14.

Unfortunately, even though I was able to boot from the Fedora'd USB drive on a regular PC, I was unable to convince the netbook to boot from it, despite fidding around with BIOS settings and the like. (Not that that was necessary for Ubuntu.) I did contemplate trying a network install, but ultimately decided to buy my way out of the problem, and acquired a cheap(-ish) external USB DVD drive. As I've got 3 netbooks, hopefully it might get some long-term use, but I can't actually recall the last time I used optical media on a PC other than for installing operating systems or burning backups...

I then had a minor mis-step - which was nothing to do with Fedora per se - in that I tried to boot from an x86_64 DVD, but the Atom CPU in the netbook seemed to only want to work with 32-bit binaries. Given that I have a Mini-ITX Atom motherboard that quite happily runs a 64-bit OS, I'd naively assumed that all Atom chips were 64-bit, but evidently not.

Luckily I'd already got a 32-bit DVD to hand from some time back, so I was able to get Fedora installed with no further problems. Unlike Ubuntu, it defaulted to having a separate /boot filesystem, so I can be sure that I can easily get rid of Fedora should I ever choose to. The boot installer recognized the Windows XP drive fine, but it seems that - for now at least - the Dell backup stuff is still out of reach :-(

On booting Fedora from the hard-drive, I wasn't in any way surprised to find that it failed to use the proper graphics drivers - defaulting to a non-native resolution - and was also lacking in any sort of working networking drivers. Evidently the USB drives were going to come in useful after all...

I pretty much stick to Fedora/Red Hat/CentOS for my primary Linux machines, and just use VMs when experimenting with other distros. This isn't due to any intrinsic brilliance in the Red Hat way of doing things; it's more a case that I'm familiar with how those distros are organized, and can quickly get them configured in a way that I want.

However, whilst the puritanical approach of not including binary/non-free drivers is to be admired, it's not necessarily ideal when it comes to getting a working OS on a machine which might have some 'unusual' chipsets, and many laptops and netbooks fall into this category. As such, I thought it worth installing Ubuntu, due to its more 'pragmatic' approach - I'd previously installed Ubuntu on an Asus EeePC and had encountered no problems.

Trial-running with Ubuntu running from the USB drive was basically fine, so I took the plunge and installed it on the netbook's hard drive, repartitioning the existing Windows XP installation. N.B. at this point in time, I didn't realize that Dell had things up with separate boot and backup partitions, as documented in the previous post.

The hard drive install was fine, other than the expected caveats of not running in the native resolution, and not having fully functional networking - if memory serves, wired Ethernet worked, but not wifi. However Ubuntu popped up an alert asking if I wanted to download the binary drivers for these, and soon all was running happily.

That release of Ubuntu though was around 5 months old, and so it seemed prudent to upgrade the installed packages to their latest versions - big mistake. On reboot, the login prompt (gdm I guess) wouldn't respond to keyboard or mouse. Attaching an external USB keyboard did get it to respond a bit more, but I was unable to get it allow me to enter a username or password. Trying the Ctrl-Alt-function keys to get a non-X11 prompt wasn't any use either.

Ubuntu had created some 'safe-mode' style booting options in the GRUB menu, but these were no good either - booting would halt with some error message I've forgotten, long before getting anywhere near a loging prompt. After faffing around for a while, and failing to find anything useful on Google, I decided to reinstall. However, the Ubuntu installer seemed to be a bit confused, and only offered me the choice of repartitioning the already-repartitioned WinXP disc, not to overwrite the borked Ubuntu install.

At this point I decided to give up on Ubuntu, and try Fedora instead. Before doing this though, I had the forethought to check beforehand how exactly the disk was partitioned. (If I'd done this before starting on this whole process, it would have probably saved a lot of time and stress...)

The hard drive was split up as follows (this was the first time I'd realized there had been more than just a single Windows filesystem originally):

1. The tiny Dell boot partition
2. The main Windows XP partition
3. The Ubuntu partition I wanted to get rid of
4. The Dell restore partition

Worse, Ubuntu's installer not creating a separate /boot filesystem meant that the whole boot process - even for Windows XP - was dependent on this Ubuntu filesystem I wanted to get rid of. (Fedora does create a separate /boot by default, so it's easy to get rid of the main Fedora installation with no impact on the prior OSes.) Possibly I could have restored an MBR from a different machine, but given the non-vanilla Dell configuration, I had doubts that this would be problem-free.

In the end, I decided that the only real option was to go ahead with installing Fedora, and hope that it wouldn't make any more of a mess than was there already...

Continuing on from the introductory post in this series...

This post is really only of relevance if you intend to retain the original OS and dual-boot - if you're happy to obliterate all traces of Windows, then you can happily skip this one.

I'm not really up on current best-practice for PC vendors, but traditionally I'd expect a new machine to ship with the hard drive fully formatted with a C: drive, whether FAT32 or NTFS. However, this Dell netbook appears to have the disk split into three partitions, as follows:

1. A pretty tiny 'Dell Utility' filesystem
2. The actual Windows NTFS, taking up the bulk of the disk
3. what purports to be a CP/M (!) filesystem, containing (presumably) an image of Windows XP that can be reinstalled. As I haven't used it, I've no idea if this is a vanilla install, or if it has the specific drivers for this machine pre-baked in

The machine isn't currently powered up, so I can't check the exact figures, but I'd made a backup of these files, and the first partition has just 9.7MB of files, the backup partition has 4.1GB - I'd assume the partitions are only slightly bigger. (By the way, both Ubuntu 10 and Fedora 14 seemed quite happy to mount these filesystems, despite their slightly obscure formatting.)

What I'm guessing is the 'Dell Utility' filesystem is like a /boot Linux filesystem with grub or lilo on. It would seem to look for some key being pressed at boot time - F8 judging by various pages on the net - and if so, runs some restore process using the images on the CP/M filesystem. (Note that F8 itself doesn't seem to be picked up by the BIOS, which only mentions and responds to F2 and F12.) Unfortunately, all this is a guess, because neither the Ubuntu 10 nor Fedora 14 installers seem to recognize the true nature of these filesystems! :-(

What happens is that the installers detect the existing XP install, and when they configure the bootloader, give the choice between booting Linux or Windows - and by Windows, I mean the OS on the NTFS filesystem, not the Dell Utility stub. As such, while XP boots up happily, it seems that I've now lost the ability to restore the system to the factory default using the Dell tools. Whilst I don't have any plans to do this, it would be nice to have the option.

In retrospect, what I should have done was to first back up the MBR using a live distro, which in theory would allow me to undo any "damage" inflicted by a Linux installer - or a regular reinstallation of Windows for that matter. As I've never actually restored an MBR, I don't know if various pages on the net are accurate, but the commands seem to be: # create a backup file called sda-mbr.bin in /tmp dd if=/dev/sdX of=/tmp/sda-mbr.bin bs=512 count=1 and # restore the backup file dd if=sda-mbr.bin of=/dev/sdX bs=1 count=64 skip=446 seek=446

At some point I'll do some experiments with the grub configuration to see if it can be coerced into booting either of these extra filesystems - but for the most part, I've given up on any expectation that they ever be usable again.

As a postscript, this information may not be applicable to newer Dell netbooks. Some page I read - this one perhaps? - mentioned that when the restore stuff is running during the boot process, it briefly flashes up some white text on a blue background. I do recall seeing something like this on this netbook, but it doesn't do it now, which makes sense given the mangling of the original boot sequence. However, my 11" Celeron/Win7 Dell doesn't flash this up at all, so whether they're doing something different now, I don't know. I'll probably do some digging with the aid of a live distro on it, but right now I'm still more interested in getting this 10" machine fully up to speed.

In the next exciting installment, I'll bitch about Ubuntu...

Amongst my ever growing, never diminishing, pile of hardware are a couple of 1-2 year old Dell netbooks - an Atom based 10" with Win XP Home, and a Celeron 11" with Windows 7. I never had any special plans for either of these machines, they were mainly bought because they were amazingly cheap - the 10" was £209 in Autumn 2009, the 11" £229 in Summer 2010, both of which were around £50-100 less than the going rate for comparable hardware at the time.

Since getting the 11" machine, the 10" has had pretty minimal use. Even with a supposedly "low-end" OS like XP Home, the crummy CPU coupled with 1GB of RAM means it's a pretty chuggy experience - probably not helped by the mountains of pre-installed crap that Dell shoved on it. (The Win 7 machine was much, much cleaner in this regard.)

Now, I do have an Atom based desktop machine running Fedora 11, and that's perfectly usable for the most part - albeit with a slightly better spec Atom processor, but with the same 1GB of RAM. As such, it seemed to make sense to look at getting Linux on the unused netbook, which might give it a bit more regular workout. Both of the netbooks have had a few distros installed within VMWare, but unsurprisingly they don't run that great, performance-wise, but I'm hopeful that Linux running natively should be a decent experience.

The last time I installed Linux natively on a laptop was around 2004/5, and whilst I was happy with how it run, I never got the wifi working. In all honesty, I don't think I actually spent much - if any - effort trying to fix it; I was quite content to use a wired connection. However, the experience made me wary of expecting too much by way of Linux compatibility on laptop hardware; hence why I've generally stuck to running distros within VMs, and letting the underlying pre-installed OS worry about the hardware.

Also, I'm loathe to ever get rid of the originally installed OS on any machines I buy, so I run them as dual-boot. I don't think I'd ever had much of an issue on this before now, but that was before I encountered the mysterious of Dell's restore functionality...

All this blather is leading up to a series of posts I'm planning, that document the trials and tribulations of doing what in theory should be a fairly straightforward task - getting a modern, well-establish and widely used Linux distro (Fedora 14) running on what would seem to be fairly mundane, well understood and supported mass-market hardware (Dell netbook). Unfortunately, this isn't the case :-( Most or all of the areas I'll cover in this series is documented on the net, but it's all rather disjointed, so hopefully I can collate it all here for any other lost souls who set on this path.

To be continued...

I primarily use Red Hat/Fedora distributions of Linux; more than anything this is for historical/comfort reasons. Whilst omissions like AVI and MP3 playback are annoying - but perfectly understandable to my mind - at least I "know where the bodies are buried", and can get a new system quickly set up the way I want.

However, to avoid missing out, I usually have one of my spare machines running one of the other current major distros. In years gone by, that would have been Mandrake/Mandriva or SuSE, but these days, of course, it's Ubuntu that has the hype and the mindshare.

Looking to install Ubuntu's new 10.10 release onto a netbook, I searched for some online docs about burning the .iso onto a USB drive, as Fedora's livecd-iso-to-disk didn't seem to want to play with an Ubuntu .iso. However, it turned out that Ubuntu's docs don't acknowledge the existence of anything other than Windows, Mac, and Ubuntu. I guess I now know how the BSD people feel...

Anyway, this got me thinking: is Ubuntu trying to cover up the fact that it's based on Linux? I grabbed the list of the current top 10 Linux distributions from DistroWatch, added on a couple of the more corporate/enterprisey ones (Red Hat, CentOS and Novell/SuSE), and ran a very simple script to pull down their homepages and count how many times they mention "Linux". Here are results:

The numbers are distorted of course, especially for those that include "Linux" in their brand-name. Fedora and OpenSuSE don't score well, but at least they do both mention it prominently near the top of the page.

However, I finding it galling that in 30-odd kilobytes of HTML, Ubuntu can't find anywhere to mention the (literal) kernel that underlies their product. It's not mentioned on their "How can it be free?" page either - there's just a mention of open source in general (which also implies it's down to the efforts of corporations, and not individuals). It should also be noted that the two mentions of Linux on Lubuntu's home page are just feed links from external sites/blogs.

Maybe we should follow RMS's example and insist on referring to it as GNU/Linux/Ubuntu?