[Date Prev][Date Next] [Thread Prev][Thread Next]
my upgrade to FC2-test1
- From: Wes Shull <wes kuoi asui uidaho edu>
- To: fedora-test-list redhat com
- Subject: my upgrade to FC2-test1
- Date: Sun, 15 Feb 2004 00:27:38 -0700
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
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
** 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
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
** 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
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)
** 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
** 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
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
* kernel: atkbd.c: This is an XFree86 bug. It shouldn't access
Also had a
* kernel: atkbd.c: Keyboard on isa0060/serio0 reports too many keys
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?
[Date Prev][Date Next] [Thread Prev][Thread Next]