Category: Fedora / Red Hat
11:02:56 pm Fedora 10: No fonts after updateCategories: Linux, Fedora / Red Hat
I setup Fedora 10 on a new (to me) IBM ThinkPad the other day. I've run into a couple of little niggles - the wireless network decided to stop working with NetworkManager, however system-config-services won't currently run so it still starts by default...
However, a much bigger issue occurred after I did an update late last week - the next time I booted up all the text had disappeared. The graphics were working fine, but there it was just blank where the text would be - in menus and dialogues as well as within applications. A quick Google revealed others with the same issue but no solutions. Finally, last night, Carter Weatherly worked out what the problem was (an issue with the latest version of the ATI driver) and posted a workaround in the bug report:
$ wget http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/i386/os/Packages/xorg-x11-drv-ati-6.9.0-54.fc10.i386.rpm $ yum remove xorg-x11-drv-ati $ yum localinstall xorg-x11-drv-ati-6.9.0-54.fc10.i386.rpm $ reboot
I've recently re-installed the file server at home with Fedora Core 6, it all went fairly well apart from some intermittent hardware issues not related to the OS. A few days later, after a
yum update, I started getting an error after logging in to Gnome:
GConf schema installer error, battery_low_percentage cannot be zero
Since this machine is going to spend most of it's life not even plugged into a monitor I didn't consider it a big deal, but as the hardware issues have persisted, and as it therefore continued to use the monitor, power and network connection which are normally plugged in to my main desktop, it's become a bit more of an issue. So this morning I finally got round to researching the solution.
export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
gconftool-2 --makefile-install-rule /etc/gconf/schemas/gnome-power-manager.schemas
killall -HUP gconfd-2
The difference to the steps described on the mailing list is the second step, it seems the default schemas are in a non-standard place in FC6. That got rid of the error message, but there were still some odd visual effects so I installed the
metacity.schemas. Looks like some sort of upgrade error stopped the default schemas being installed, so I'm guessing any similar errors can be resolved by choosing the relevant file from
/etc/gconf/schemas/ and using the above commands.
01:02:46 am Scrobbling with Audacious on Fedora Core 5Categories: Linux, Fedora / Red Hat
I've gotten quite into last.fm in recent weeks. It's a very well put together site, and can provide excellent background music once it's built up some opinion of your tastes.
I'd mostly been using it from my laptop and in my bedroom, both places where I currently have SuSE installed and run KDE, so I use Amarok which has a built in config screen for last.fm and will automatically notify last.fm every time you listen to a song (a process known as 'scrobbling').
Last week I booted up my 'main' PC which currently has FC5 running Gnome and on which I tend to use Audacious. I checked the config screens and discovered that it too had a place for putting in my last.fm details. Unfortunately, on the version which ships with FC5 (1.1) the last.fm plugin doesn't work, none of the tracks I listened to appeared on my last.fm profile A little googling indicated this was a known issue with the 1.1 version of Audacious, though it is fixed in version 1.2. Couldn't find any Audacious 1.2 RPMs for FC5, but I did find that FC6 ships with version 1.2. So I downloaded the SRPMs and, after some fannying around installing a raft of '-dev' libraries with Yum, I was able to successfully
rpmbuild --rebuild audacious-1.2.2-1.fc6.src.rpm and then (after installing the RPMs output from that)
rpmbuild --rebuild audacious-plugins-1.2.5-2.fc6.src.rpm (the plugins require the audacious dev package to already be installed before they'll build - I just installed the first lot with a
--nodeps in the command). Now I can scrobble from Audacious in FC5 too
I've been upgrading the intranet server at work today, previously it was running Red Hat 9.0 which even the Fedora Legacy Project will be dropping support for at the end of the year. So on Friday I installed Centos 4.4 on a nice new hard drive and I spent today copying across all the files from the old drive.
Mostly everything went without issues, but one of the things we have running on our intranet server is a WackoWiki for developer documentation. I'd done a backup of the pre-upgrade database with phpMyAdmin, which had been running on MySQL 3.23.
In my previous MySQL upgrade experiences I'd encountered some issues with character encoding - basically that the old database didn't have any, and newer versions of MySQL do. Up until now I've always just updated the relevant table definitions by hand, adding in unicode to the SQL and not really thought much about the wider implications. I was delighted to discover that phpMyAdmin 184.108.40.206 has an option on the import page for 'SQL compatibility mode', from which you can select 'MYSQL323', with the result that your old export files will now import without modification. Unfortunately, that's where I ran across the problem in the post title:
Specified key was too long; max key length is 1000 bytes
Some of the indexes in the WackoWiki database schema use a combination of three 250 character
varchar columns. Because a unicode character can be up to three bytes long, MySQL tries to reserve the maximum space that could be required for the index - 3 x 250 x 3 bytes - which exceed the maximum allowed. There is an open defect about the issue on the MySQL website, with many comments from various disgruntled users.
I considered changing the keys so they'd fit, but it looked like a dangerous thing to do as far as the operation of WackoWiki was concerned, and I was worried I'd end up knee deep in PHP trying to fix all the problems. One of the comments on the bug report did guide me to the solution - Scott Lane posted that he set the index columns' collation to be
latin1 so that it would work as it did on MySQL 3.23. Since the Wiki had been operating quite happily for more than three years on a database with no unicode support I figured I probably didn't have anything to lose by setting the whole database to use
latin1_general_ci collation. I recreated the database and tried the import again and everything imported without errors
Which brings me to a D'Oh! moment. After some fannying around because the privileges got a bit mixed up with me dropping and recreating databases, I finally got to view our Wiki home page, and it looked very odd. None of the links were links - they all looked something like '??MyPages ==??'. I (correctly) surmised that I'd messed up somewhere with character encoding. At least it didn't take me too long to figure out my own stupid mistake: On the import page in phpMyAdmin, just below the file selection field, there's a 'Character set of the file:' select box which I'd been ignoring. By default this is set to UTF8, except, of course, the SQL file I'd exported from my non-unicode aware MySQL 3.23 database wasn't UTF8. This doesn't matter much for the common characters, because UTF8 and ASCII are compatible for the first 127 character points, but apparently it does matter very much for some of the characters used in WackoWiki markup. I re-imported with my import character set as
latin1 and everything worked fine.
11:15:29 pm Dual Core IssuesCategories: Linux, Fedora / Red Hat
Everything has not been so peachy in dual core processor land since my last post. Although it seemed to be working fine to start with, after a random amount of time suddenly the mouse pointer and keyboard would become very unresponsive - lagging behind my mousing or typing by a second or even more. The only way I've found to correct the issue is to reboot. After some experimentation (I at first thought the problem was related to having both on-board sound and a sound card) the only (apparently) working solution I've found so far is to turn off APIC altogether with my boot options:
kernel /vmlinuz-2.6.17-1.2157_FC5smp ro root=LABEL=/1 rhgb quiet noapic nmi_watchdog=2 noexec=off
This sends all interrupts to one of the cores, which isn't ideal but not noticeable in normal use. I'm not sure if I still need the nmi_watchdog option now that APIC is off, but it doesn't seem to be doing any harm. One option I didn't get round to trying yet was to change the BIOS setting for 'MPS version' from 1.4 to 1.1, some laptop users reported that they couldn't boot up unless this was set to 1.1 but I could find no specific information for my ABit AV8 motherboard.
01:40:20 am Dual Core Processors Rock!Categories: General, Linux, Fedora / Red Hat
Today I took delivery of a shiny new ABit motherboard and a shiny new dual core AMD64 (and, incidentally, a new power supply and 2Gb of RAM). I got home from work at 9:00pm and now, just over four hours later, I've finally got everything working satisfactorily in both Win2K and FC5. The CPU and motherboard I replaced were nearly four years old so this is a fairly significant upgrade to my processing power!
Most of the process was straightforward, I remembered to reset my IDE interface to the windows default before installing the new motherboard, but since the new board has a similar VIA chipset to the old one it seems like I needn't have bothered. The main difficulty was that the default settings on the motherboard ignore USB keyboards, so I had to find a PS/2 one to get into the BIOS settings. Having got everything installed and turned on with the correct lights flashing the first major obstacle turned out to be that I could only see one CPU instead of two This in itself took me a while to figure out, it used to be
top would tell you how many CPUs you had but it doesn't seem to do that anymore, eventually I realised the obvious place to look:
Part one of the solution was upgrading the BIOS, for some reason ABit are shipping the board with a BIOS from early 2005 which doesn't support the dual core chips. Playing it straight and following through their website support pages led me to a lot of stuff about updating the BIOS from DOS, which is not a procedure I was keen about, not least because it would involve finding a floppy disk. Some further rummaging led me to a tool called 'FlashMenu' which purported to upgrade the BIOS from windows, unfortunately when I downloaded it I find that 'I must use a newer version of FlashMenu'. At this point I went to Google, which I should have done in the first place, and found the latest version of FlashMenu on their US website.
After another brief detour with the PS/2 keyboard, because, of course, flashing the BIOS resets everything to defaults, I was booting into windows and expecting to see two CPUs but was disappointed. The fixes were getting easier though - Win2K doesn't automatically install the second processor but there's an easy fix to install the second CPU yourself.
So that was windows sorted, now onto Fedora Core. I manually downloaded the SMP kernel and installed it:
rpm -ivh kernel-smp-devel-2.6.17-1.2157_FC5.i686.rpm kernel-smp-2.6.17-1.2157_FC5.i686.rpm. Then I had to manually download the fglrx and NTFS modules from livna and install them too. A reboot and everything seemed to be working OK, until I opened up two applications and tried to copy and paste some text between them and suddenly things started to lock up and I had to Alt-Tab to get the windows to accept input again. The solution for this (so far) is to add lapic to the boot options in
/grub/menu.lst - and now I'm happily dual processing
11:48:14 pm UT2004 on FC5Categories: Linux, Fedora / Red Hat
My not very fun experience with Fedora Core 5 took a turn for the worse two weeks ago when I discovered that it also failed to run UT2004. I spent a few hours installing updates and trying to figure out what was wrong while I should have been enjoying myself at a LAN party but didn't figure it out. I've another LAN party tomorrow, so tonight I was determined to get to the bottom of the problem. The error output wasn't too useful (Signal: SIGSEGV [segmentation fault] Aborting.) and there wasn't any extra detail in the log. After a significant amount of Googling and a complete re-install of UT I gave up on the English pages and started trying to decipher the French and German ones and that's when I hit upon the solution, instead of just typing 'ut2004' to start the game you use:
setarch i386 ut2004