my upgrade to FC2-test1

[Wes Shull]

(long)

It seems like most people are testing clean installs...  I run Fedora 
to be reasonably close to the edge, so I figured I'd inch a little 
closer and do an upgrade instead, and it worked mostly OK.  Had a few 
issues though, and I'm not sure if I should file bug reports or if my 
setup/actions are too oddball to be an issue.  Hence this message:

First, my system.  It's been upgraded over the years from 
7.x->8->9->fc1, always by hand with rpm (fun!), so there's no doubt a 
bit of cruft here and there that I missed.  Ran fine, though.

Non-stock rpms I had installed before the upgrade:
* Planet CCRMA audio/video packages + kernel instead of an official 
FC1 kernel (actually had a few different kernels installed for 
testing) Note this means I already had ALSA 1.0.
* KDE 3.2 from FC1 rpms at kde.org
* mozilla 2.6
* python 2.3 from python.org
* xchat 2.0.7 from xchat.org
* of course plenty of other stuff in /usr/local compiled straight from 
source, but nothing duplicating stuff in the FC rpms, so not an 
issue.

Another fun thing about my system is I have no bootable partition...  
my /boot lives on /dev/md0 (linux software RAID 5) and is just there 
to make kernel installs happy; I make and use boot CDs instead.

Ok, so I got a wild hair and decided to try booting off the install CD 
to upgrade.

** Potential bug report 0:  This is a hyper-belated report, may not be 
true anymore.  At the time I upgraded to FC1 from RH9, I also tried 
to use the install CD to upgrade, but it couldn't find my /dev/md0.  
After much head-scratching and poking around in the rescue shell, I 
discovered that raidstart on the install CD refuses to start up an 
array that is in degraded mode (I had a drive out for replacement.)  
While I may be the only one crazy enough to do an OS upgrade on a 
degraded array (have I mentioned I don't have a UPS?), it certainly 
does render the whole "linux rescue" useless in a situation where 
normal people might use it...

Anyway, this time the install found my /dev/md0, and it went fine... 
until the end, when it prompted to make a boot floppy, which of 
course is a no-go; in fact I don't think a full redhat kernel has fit 
on a floppy in years.

** Potential bug report 1:  Why isn't there an option to burn a boot 
CD?

So I threw one of my 2.4 boot CDs and rebooted, intending to 
mkbootdisk --iso and burn a 2.6 boot CD.  But I discovered that the 
installer had, in a very Microsoftfully helpful manner, removed all 
my prior kernel installs, so I had no modules to load to drive my 
burner.

** Potential bug report 2:  Why did it remove all my old kernels?  Are 
the changes to modutils etc for 2.6 so significant that the 2.4 
versions can't coexist?

So, back to install disc 1, linux rescue, chroot, make and burn a 2.6 
boot CD.  While I was trying to get cdrecord to work, I noticed that 
in translating modules.conf to the new modprobe.conf, it had kept in 
all my pre-loading of ide-scsi before sg.  Anyway I eventually 
remembered from the various 2.6 kernel announcements that ide-scsi is 
gone I can just use dev=/dev/hdc with *record now.  

** Potential bug report 3:  Since ide-scsi is gone now, maybe it 
should filter it out during the modules.conf->modprobe.conf 
conversion?

ide-scsi being gone and the new dev spec for *record should definitely 
be mentioned in the final release notes.

Ok, getting closer.  Boot off my 2.6 boot CD, linux single.  
rc.sysinit fails to remount root rw:
	mount: can't find / in /etc/fstab or /etc/mtab
I fixed it by changing the first field in the line for / in /etc/fstab 
from "LABEL=/" (which e2label assures me is still the label on md0) 
to "/dev/md0"...

** Potential bug report 4:  That ^

As usual had to chkconfig off stuff from kernel-utils that isn't 
relevant to my athlon-xp:  cpuspeed and microcode_ctl.  Ok didn't 
*have* to, they don't hurt anything, but it's annoying to see the 
fail messages at boot.

** Potential bug report 5:  we really should turn these off for cpus 
we *know* don't use them...  leave them on for unknowns

I check out what has and hasn't been installed; as expected it didn't 
touch my updated mozilla or kde.  Ripped those out and replaced them 
with the FC2-test1 versions for a more consistent testing 
environment.  Uninstalled the now-redundant pydotorg python 2.3.  I 
noticed that there's still a whole bunch of stuff left 
in /usr/lib/python2.2/site-packages/, some of which rpm -qf says are 
orphans, some of which belong to old-installed or newly-installed 
packages.

** Potential bug report 6:  Shouldn't stuff 
in /usr/lib/python2.2/site-packages/ be removed or 
in /usr/lib/python2.3/site-packages/ instead?  (Or if they don't work 
under 2.3, 2.2 needs to stay)

I tried bringing up my interface to the world "ifup eth0"  No go, it 
was trying to load the driver that eth1 uses.  Ripped all the 
ethernet stuff out 
of /etc/sysconfig/hwconf, /etc/sysconfig/network-scripts/ifcfg-eth*, /etc/modules.conf, 
and /etc/modprobe.conf, reran kudzu, then things were proper again.

** Potential bug report 7:  eth* detection confusion.  I'm really 
hesitant to file this though, because I was running a very different 
kernel before, and have had eth0 and eth1 switch because of it.

telinit 3, log in, startx.  Had no sound, but running alsamixer fixed 
that (I use spdif output, which is not on by default on my card, so 
it must not have picked up wherever the Planet CCRMA alsa saved the 
settings).

I noticed that my xchat 2.0.7 and Perl and Python plugins have been 
replaced by redhat's, but it didn't remove the xchat-perl and 
xchat-python packages that provided the old plugins.  Also, it 
doesn't provide the Tcl plugin; does it not compile against Tcl 8.4?

Warts that others have reported that I'm corroborating:
* various obsolete numerical sysctls
* spurious 8259A interrupt: IRQ7 (actually I've been seeing that one 
for a long time, maybe even on redhat 9 or 8)

This one I've seen reported against Rawhide, but not FC2-T1:
* kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a 
on isa0060/serio0).
* kernel: atkbd.c: This is an XFree86 bug. It shouldn't access 
hardware directly.

Also had a
* kernel: atkbd.c: Keyboard on isa0060/serio0 reports too many keys 
pressed.

That's about it.  System's been up and working fine for 32 hours now.  
I can't really comment on improved performance, as I was running 
2.4.24 + low latency patches + kernel preempt patches + more before; 
forgot how the factory FC1 kernels felt.  If anything, I'd say this 
kernel (2.6.1-1.65) may feel slightly *less* responsive than what I 
had.  Did I hear correctly, that it does not include the low latency 
patches because rh thinks they're not stable enough?

--wes