Fedora Core 3 on the Iwill DVD266-R system

My main system at work is a dual Pentium-III SMP system based on an Iwill DVD266-R motherboard. This board is based on the VIA Apollo Pro 266 chipset consisting of a VT8633 "Northbridge" that handles the DDR memory and the AGP slot; and a VT8233 "Southbridge" that handles the PCI bus, the ATA100 interface and other odds and ends. This board also has an AMI MG80649 RAID controller (aka CMD-649) which I use for my single ATA disk drive. It also has a C-Media CMI8738 PCI sound chip, which is pretty nice actually, but I have it disabled (via motherboard jumper ?), and I use a PCI Soundblaster Live (emu10k1). The board also has a Winbond W83627HF system monitor chip that I should set up to use lmsensors someday.

On Monday 2-7-2005, I decide to upgrade my system from Fedora Core 1 to Fedora Core 3. Why? Security, plain and simple. I have not been getting updates for FC1 for months and it is one of the first principles of running a secure system to apply system patches in a timely fashion.

NFS install

1) I do an NFS install from mmto.org (actually an upgrade, not an install) after insuring I had about 3G free on my 10G root partition (hda2). This took almost 2 hours.

SMP troubles

2) My system is an Iwill-266 SMP board with a pair of 1 Ghz Pentium III. Booting the SMP kernel failed miserably. It reported lost interrupts on hda, my symbios SCSI controller was completely non-functional. This is with the 2.6.9-1.667 kernel shipped on the install ISO images. The uniprocessor kernel seems just fine. (I resolve this problem later, see below).

Sound fails - alsasound woes

3) The boot hangs trying to start up the ALSA sound system. I have a SoundBlaster Live (emu10k1). I reboot and use the grub 'e' command to edit the second line (with the word kernel), add the word single, and then boot into single user mode. Then using chkconfig to turn off the "alsasound" service gets me past this issue; someday I will sort this out .....

MySQL, ntp, mailman are off

4) MySQL, ntp, and mailman are not starting up, but these are the least of my troubles just now. More on these in their turn as we go along.

X11 driver issues

5) X will not start, no doubt because it is inheriting my old dual head configuration. I had an old copy of the Nvidia linux driver (5336), but was able to get a newer copy (6629) from one of our other machines. The 6629 driver does NOT need the old 'export CC=gcc32" trick that the 5336 driver needed with FC1, in fact this is quite the wrong thing since the 2.6.9 kernel is built using gcc 3.4 and will refuse to load a module built using gcc 3.2; the 6629 driver is smart enough to do the right thing if left alone.

6) I go to /etc/X11 and delete a broken link (this is of no consequence, but hey, lets tidy up ... X --> /usr/X11R6/bin/XFree86 I also rename xorg.conf to xorg.conf_ORIG and try copying an old file XF86Config.1head to xorg.conf. This fails with a complaint about no GLX extension Nvidia driver and being unable to find /dev/mouse. I edit the mouse device to be /dev/input/mouse0, also edit inittab to be run level 3 for the time being, do telinit 3, and then give startx a try and voila, I have a single head X session!! (and this despite the fuss about the nvidia GLX thing missing).

7) Now you must do a little game of cp -a /dev/nvidia /etc/udev/devices to make sure the new nvidia special files will endure thru a boot. If you don't do this you will have to rebuild the Nvidia driver every time you reboot just to get the entries you need in /dev

NTP

8) OK, now why doesn't NTP work? Well, it is iptables, I need to go to /etc/rc.d/init.d and edit iptables to invoke my /etc/rc.firewall script and this starts to work (not to mention port 25 and 80 come alive). I decide to build an iptables.patch file to make this easier next time along.

yum updates

9) Now, how about a yum update thing?? I edit my /etc/yum.conf to put the yum archive onto /u0/yum (and flush the old FC1 stuff outa here) so it does not fill my root partition as it once did. Then I copy the /etc/yum.repos.d stuff from mmt, and issue the yum update command. Away it goes .... this may take a while. One hangup here is to get the keys into RPM, but tim has a yum repository RPM that does that for you.

10) Now that I have done a yum update of a zillion things I have to rebuild the Nvidia driver (as I will need to each time a new kernel comes along), and I find that MySQL is no longer complaining about a timeout (they must have fixed this in one of the updates.) Gads, they still aren't providing MySQL 4.1 even in FC3!!!

mailman

11) Mailman isn't working because they have moved the files all around. Actually what they have done is a good thing, and the easy fix for me is to just move /var/mailman into /var/lib/mailman. I need to clean out a lot of this stuff since the executables are now much more sensibly over in /usr/lib/mailman. I also need to edit this new path into /etc/httpd/conf.d/mailman.conf

enable SMP via acpi kernel options

12) I can get my board to run the SMP kernel to run by adding "acpi=off pci=usepirqmask" to the kernel line in grub.conf. I will have to check that this gets propogated whenever I get a new kernel. Running this kernel requires that I yet again rebuild the Nvidia driver.

Have any comments? Questions? Drop me a line!

Adventures in Computing / tom@mmto.org