Some good sources of information are:
yum clean all yum update
Since my auto update thing has been screwed up for some time, this
finds 179 packages to update, 15 to install, 2 to delete.
And it fails because:
kmod-nvidia needs kernel-x86_64 = 2.6.22.9-91.fc7
It turns out the trick is to delete the kernel module -- this shouldn't be necessary, things should just work.
rpm -q kernel yum erase kernel-2.6.22.9-91.fc7 yum updateAnd after this is done:
yum install kmod-nvidiaThere is no telling why this has to be babied by hand like this, maybe somebody botched some dependency specifications, but this last step installs kmod-nvidia and xorg-x11-drv-nvidia. Note that nv is the free nvidia driver that does not support dual head. nvidia is the vendor supplied driver with all the cool features.
cd /media/mirrors/fedora/releases/8/Fedora/x86_64/os/Packages rpm -Uvh fedora-release-notes-8.0.0-3.noarch.rpm rpm -Uvh fedora-release-8-3.noarch.rpmThe second has the real "meat" in it. Doing a rpm -qlp fedora-release-8-3.noarch.rpm is instructive. Now I return to /etc/yum.repo.d where it has deposited several .rpmnew files and tidy up. Then go for broke:
yum update
I hit the same nonsense as mentioned above with regard to kmod-nvidia. I do a yum erase kmod-nvidia and try again, but I wonder if I was doing this outside of a graphical environment if this would just go smoothly, I suppose I should do ctrl + alt + F1 to get to a root login and then do telinit 3 and try it that way ... someday.
I get in trouble as follows:
ERROR with rpm_check_debug vs depsolve: Package compiz needs libwnck-1.so.18, this is not available. Package dbus needs libexpat.so.0, this is not available.both of these are mentioned in the yum upgrade FAQ, but it wasn't clear if the cleanup needed to be done before or after the yum upgrade, apparently it must be done before:
yum erase dbus.i386This takes down 57 packages with it! (yikes, I should have listed them so I could yum install them back in, but oh well!!)
Also, as recommended, I do the following (it turns out I didn't have beryl anyhow):
yum erase beryl\* yum erase compiz\*
yum install kmod-nvidiaI get into some mess where the nvidia module is for a more recent kernel that what has made it into my repository. I've had my belly full of this nonsense, so I go back to the old reliable method, namely to get the driver directly from the Nvidia web site and build it (it takes only a few minutes and has always worked, except when there was some issue with the compiler that required a workaround way back when. So I do this:
get NVIDIA-Linux-x86_64-100.14.19-pkg2.run su ; sh NVIDIA-Linux-x86_64-100.14.19-pkg2.runThen I have to go into /etc/X11/xorg.conf and change the driver name from nv to nvidia since some clever thingie has made that change for me automagically.
if [ -f /root/NVIDIA.run ]; then
/root/NVIDIA.run -s -n
fi
The -s says to accept the license and run silently.
The -n says to not use any precompiled interfaces
(forcing it to recompile each time).
This makes my reboot take a lot longer, but typically I only reboot when a new kernel comes along, and it is a much bigger pain to do this by hand (and takes at least as long anyway).
There is a -update switch that will visit the nvidia site and check for newer driver versions, but I am not yet brave enough for that.
This package (cdrecord aka wodim) now goes berserk when I run my CD burning script and spews out endless messages like so:
Unable to open this SCSI ID. Trying to map to old ATA syntax. This workaround will disappear in the near future. Fix your configuration.It is hard to imagine anything more rude (and it has been doing this for some time, why doesn't the fedora RPM apply a patch to abate this nonsense!) Makes me want to crawl through the network and rip someones throat out, and that is when I am feeling calm about it. Doing a google search reveals amazingly little to help me actually fix my configuration, which I would dearly love to do. I just want to burn CD's, not plumb the depths of whatever petty issues rage amongst those that design the ata kernel interfaces, and bicker with this goof-ball who maintains the CD burning software. Sigh ....
Aha, I have found some useful information, the first tip is to forget all the old weird cdrecord/wodim syntax and just use the regular /dev/cdrw device name as dev=/dev/cdrw that you should have been able to use all along.
One completely reasonable thing to try (especially if you only have one CD
reader/burner on your system (as I do)), is to omit the dev=/dev/gizmo
argument altogether and see if it just works.
In my case it does!
To get a clue of what special file (entry in the /dev/ directory) actually is your CD/DVD burner of choice, you can do this:
dmesg | grep CD scsi 4:0:0:0: CD-ROM SONY DVD RW AW-Q170A 1.73 PQ: 0 ANSI: 5 Uniform CD-ROM driver Revision: 3.20 sr 4:0:0:0: Attached scsi CD-ROM sr0This would indicate in my case that /dev/sr0 just might be the right device. In fact, when I look at /dev I find that /dev/cdrom and /dev/cdrw are links to /dev/sr0 and everything starts to make sense.
You can still (like in the good old days) use cdrecord --scanbus, but it will lead you astray, here is the story on my system:
cdrecord --scanbus
scsibus4:
4,0,0 400) 'SONY ' 'DVD RW AW-Q170A ' '1.73' Removable CD-ROM
4,1,0 401) *
4,2,0 402) *
4,3,0 403) *
4,4,0 404) *
4,5,0 405) *
4,6,0 406) *
4,7,0 407) *
This information is valid and correct, but does NOT clue you in to the
fact that you should be using /dev/sr0, in fact it might lead you
into doing something like dev=SCSI:4,0,0 which would just fetch
you the afore mentioned rude and obnoxious error messages.
Another approach to getting information about your hardware is:
cat /proc/sys/dev/cdrom/info CD-ROM information, Id: cdrom.c 3.20 2003/12/17 drive name: sr0 drive speed: 48 drive # of slots: 1 .....This does indeed clue you in to use /dev/sr0. Hurrah!
yum install gv
tar xzvf AdobeReader_enu-8.1.1-1.i486.tar.gz cd AdobeReader su ./INSTALLAnd that is it! It puts stuff into /opt/Adobe and makes a link from /usr/bin/acroread to /opt/Adobe/Reader8/bin/acroread.
One small wart, it complains about being unable to find libgtkembedmoz which is on my system as /usr/lib64/firefox-2.0.0.10/libgtkembedmoz.so I'll bet this is a 64-bit issue of some kind (maybe I could have gotten a 64 bit acroread?), but acroread runs fine, it just seems to want to display an html manual or something.
I got a wild hair, and decided to let my machine run named as a caching nameserver. It turns out that the /etc/named.conf file is almost good to go out of the box, I just add to the options section, the following:
forwarders {
128.196.100.50;
128.196.100.19;
};
Where the above IP numbers used to be in my resolv.conf file.
resolv.conf then becomes:
search mydomain.org myother.org nameserver 127.0.0.1Then:
service named restart chkconfig named onThis seems to work.
I'll give you the ultimate fix for lots of headaches right up front. Don't run the 64 bit firefox!. You will be eternally annoyed that plugins won't work (websites with flash will seem broken, you won't be able to view PDF documents inline, and much more misery besides). I can't think of a single good reason to want to run the 64 bit version of firefox. Make your life simple and do this:
yum erase firefox.x86_64
It isn't just that the plugins don't work, in some cases 64 bit plugins aren't available and apparently never will be.
The rest of this section documents the nonsense I tried to deal with when for some reason I thought there might be some benefit to having both the 32 and 64 bit firefox side by side.
I have been much happier since I stopped running the 64 bit firefox and switched to the 32 bit (which runs just fine on my 64 bit system). I had fiddled with nspluginwrapper (which you can yum install), but it just seems better to use the 32 bit browser. A couple of interesting twists came up along the way.
I did a yum erase firefox, then tried to yum install it, and found myself in the midst of some bizarre business with avahi RPM's. Apparently this is a "well known issue" that is discussed in the Fedora YumUpgradeFAQ. Since this was once a core 7 system, some odd business left a fedora core 7 avahi laying around, and getting in the way of yum upgrades, the cure is:
rpm -e --noscripts avahi-0.6.17-1.fc7
I have no idea what avahi (which is a multicast DNS gizmo, or so I am told) and firefox have to do with each other in such an intimate way (well, I can kind of imagine, since web browsing does make heavy use of DNS), but I am just carping.
Now, what I do to make 32 bit firefox my default is to go to /usr/bin and copy the firefox script to firefox-32 and change the lib64 lines to lib. Then on my desktop firefox icon, I click on properties and change firefox to firefox-32.
Now both flash and java plugins "just work", which wasn't the case before, and the bizarre page load delays are gone.
There is a problem with this. Namely that whenever a yum update to firefox
comes along, things get out of whack. In particular the firefox-32 and firefox-64 scripts
that I set up end up pointing to
/usr/lib/firefox-2.0.0.13
/usr/lib64/firefox-2.0.0.13
and they need to point to
/usr/lib/firefox-2.0.0.14
/usr/lib64/firefox-2.0.0.14.
Or something like that (you get the idea), so I have to go and hand edit these
scripts each time firefox gets an update ... sigh!
Not to worry, yum to the rescue:
yum install bitstream-vera-fontsVoila! And no more whining.
The broken lighttpd thing came up just about the time when FC9 made its debut. Not that there is any connection, but in late April or early May, a lighttpd update appeared that killed all my rails applications. I fiddled for a while, then gave up, removed 1.4.19 and reinstalled lighttpd-1.4.18 and lighttpd-fastcgi-1.4.18, and I was back on the air. More yum updates are coming along, and yum is still eager to update 1.4.18 to 1.4.19, so also added an exclude line to my file /etc/yum.conf. This is an easy one-line addition that goes in the main section (as the first thing) as follows:
[main] exclude=lighttpd lighttpd-fastcgi cachedir=/var/cache/yum ...
Adventures in Computing / tom@mmto.org