Fedora

Clamav installation failing on Fedora Core 18

Someone majorly botched the clamav packages in Fedora 18, where the packages fail to create the appropriate user ID and group ID. The output from the yum install looks like

Running Transaction
  Installing : clamav-data-empty-0.97.8-1.fc18.noarch                       1/5 
  Installing : clamav-lib-0.97.8-1.fc18.x86_64                              2/5 
Usage: groupadd [options] GROUP

Options:
  -f, --force                   exit successfully if the group already exists,
                                and cancel -g if the GID is already used
  -g, --gid GID                 use GID for the new group
  -h, --help                    display this help message and exit
  -K, --key KEY=VALUE           override /etc/login.defs defaults
  -o, --non-unique              allow to create groups with duplicate
                                (non-unique) GID
  -p, --password PASSWORD       use this encrypted password for the new group
  -r, --system                  create a system account
  -R, --root CHROOT_DIR         directory to chroot into

useradd: group 'clamupdate' does not exist
  Installing : clamav-filesystem-0.97.8-1.fc18.noarch                       3/5 

This is reported in RedHat bug 963920. As commented on this bug, the work around is to assure these users are created before installing the clamav packages. E.g.

$ sudo yum remove clamav\*  # Be careful with this, make sure you are not losing anything you wish to keep
$ sudo groupadd -r clamupdate
$ sudo useradd -r -g clamupdate -d /var/lib/clamav -s /sbin/nologin -c "Clamav database update user" clamupdate
$ sudo yum install clamav-data clamav clamav-update clamav-milter

Hacking: 

Missing emacs symlink on Fedora Core

I just finished installing Fedora Core 16 on a new router I'm planinng on installing up in our little cabin. Things went mostly well, except the symlink to Emacs was missing. The horror! The RPM was most certainly install, but no emacs in my path was to be found. Well, it turns out, for some reason (who knows why ...), the installer did not finish creating the Emacs symlink. It's quite possible it missed other links too, but Emacs was obviously the number one priority. Poking around a little, it was easy to restore life as we know it:

sudo alternatives --install /usr/bin/emacs emacs /usr/bin/emacs-23.3 10

Hacking: 

yum failures with missing $releasever

During an upgrade (yum update) on a Fedora VM, something went horribly wrong, and it crashed in the middle of the update. After rebooting, and cleaning up the mess, yum still was very unhappy. Running an update would give me errors like

Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=x86_64 error was 
No repomd file
Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again

Very odd. It turns out, $releasever was not properly set, and I could not figure out why. Poking around, I realized that $reelasever is supposed to come from examining the version number of a particular RPM package, in my case fedora-release. Well, lo and behold, this package was no longer installed on my box, yum must have uninstalled it, but crashed before installing the new update (or something...). I mounted the Fedora Core DVD, and simple reinstalled the missing package, and things are happy joy joy again. Here's the command:

$ sudo rpm -i ./Packages/fedora-release-13-1.noarch.rpm

 

Hacking: 

Fedora Core 15 as a VirtualBox guest OS

Fedora Core 15 was released today! I of course went straight into VirtualBox, after the download finished of course, to create a new couple of VMs. As I usually do, I assigned 512MB of RAM for the new VMs (one 32-bit and one 64-bit). Booting up, the kernel would crash, wth? It turns out, 512MB is not enough to boot up FC15, at least not under VirtualBox. I increased the memory allocated to each VM to 768MB, and things works just fine now.

Now of course to deal with the disaster that is Gnome 3.0. It's probably time to switch over to KDE, the Gnome org is just going crazy removing options and configurations for no apparent reason other than telling people they know best. I mean, come on, not even allowing me to use "Select windows when the mouse moves over them"?? Grrrr...

Update: You can achieve this particular setting ("focus follows mouse") using gconf-edit, setting

/apps/metacity/general/focus_mode

 

to "sloppy" (without the quotes). Sigh. Of course, turning on "fallback" mode is almost a requirement.

Hacking: 

Upgrading Fedora with yum

I've been doing a number of upgrades of Fedora Core recently, and was semi-disappointed with how slow the upgrade process from DVD was. On every upgrade, it had to first install well over 1000 packages from DVD, and to finish it off with a "yum update" after the upgrade, at least another 1000 packages upgraded again. I decided for my next upgrade to do an update on the live system, using yum directly. I decided to follow the excellent upgrade instructions from the Fedora project, and it worked surprisingly well (and much, much faster). On top of that, I also cleaned out some groups that I no longer thought were necessary.

Here's the quick summary of the commands I ran:

# Run an update first, just in case
yum update

# Cleanup/merge config updates
yum install rpmconf
rpmconf -a

# Find and review unused packages
yum install yum-utils
package-cleanup --leaves
# Now yum remove the packages you think should be removed

# Find and review lost packages
package-cleanup --orphans

# Cleanup
yum clean all

# Do the upgrade, preferably in run-level 3 (no GUI)

# For FC13 -> 14 upgrade
rpm --import https://fedoraproject.org/static/97A1071F.txt
# For FC14 -> 15 upgrade
rpm --import https://fedoraproject.org/static/069C8460.txt
# For FC15 -> 16 upgrade
rpm --import https://fedoraproject.org/static/A82BA4B7.txt
# For FC16 -> 17 upgrade
rpm --import https://fedoraproject.org/static/10D90A9E.txt
# For FC17 - > 18 upgrade
rpm --import https://fedoraproject.org/static/DE7F38BD.txt
# For FC18 - > 19 upgrade
rpm --import https://fedoraproject.org/static/FB4B18E6.txt
# For FC19 -> 20 upgrade
rpm --import https://fedoraproject.org/static/246110C1.txt

yum update yum
# The following steps are a bit different than Fedora recommendations, they
# say to run the updates with --skip-broken. But I don't like it.
yum check
# and then resolve any duplicates. When running the following, you will get
# conflicts, resolve those by uninstalling the offending packages.
# For FC13 -> 14
yum --releasever=14 distro-sync
# For FC14 -> 15
yum --releasever=15 distro-sync
yum groupupdate Base
# For FC15 -> 16
yum --releasever=16 --disableplugin=presto distro-sync
yum groupupdate Base
# For FC16 -> 17
yum --releasever=17 --disableplugin=presto distro-sync
yum groupupdate Base
# For FC17 -> 18
yum --releasever=18 --disableplugin=presto distro-sync
yum groupupdate Base
# For FC18 -> 19
yum --releasever=19 --disableplugin=presto distro-sync
yum groupupdate Base
# For FC19 -> 20
yum --releasever=20 --disableplugin=presto distro-sync
yum groupupdate Base
 

# Examine other groups and update (or remove) as necessary yum grouplist yum groupupdate "Administration Tools" "Server Configuration Tools" ... # Prepare for boot, assuming your boot device is /dev/sda (change as appropriate) /sbin/grub-install /dev/sda # Or, if you are switching to grub (as in FC16) /sbin/grub2-mkconfig -o /boot/grub2/grub.cfg /sbin/grub2-install /dev/sda # Update startup order; This is not for FC16 or later! cd /etc/rc.d/init.d; for f in *; do /sbin/chkconfig $f resetpriorities; done # Find packages that haven't been upgraded package-cleanup --orphans

I made a small shell script available to make it a little easier to manage the update (and additions / removals) of yum groups. It's far from perfect, and does indeed have bugs, but I still find it helpful. Right now, it still runs the necessary yum commands "interactively", to give you some extra safety deciding if you want to proceed with a particular operation. The script supports upgrading, removing and adding yum groups. It is available from github, at https://github.com/zwoop/scripts, it is named yumgroup.sh.

 

Note: I take no responsibilities for failed upgrades, but this process worked nicely for me, upgrading from FC13 to FC14.

Hacking: 

Linux / Fedora Core and nf_conntrack:

While testing and benchmarking some new features in Apache Traffic Server on my dev box, I started having really odd problems with inconsistently lost connections or really slow performance. Upon examing the logs, I found a large number of kernel barf like

Oct 29 11:53:51 loki kernel: nf_conntrack: table full, dropping packet.
Oct 29 11:53:51 loki kernel: nf_conntrack: table full, dropping packet.
Oct 29 11:53:51 loki kernel: nf_conntrack: table full, dropping packet.
Oct 29 11:53:51 loki kernel: nf_conntrack: table full, dropping packet.

Clearly this could not be good. I poked around, and could not find any ways to turn off this kernel module, at least on my Fedora Core 13 it seems compiled straight into the kernel (i.e. no .ko). There are ways to increase the table size (sysctl's) but that seemed like a band aid at best. Bummer. So, I went to the mountain (Noah F.) and asked for advice. After some poking around, we found that forcing iptables to ignore the conntracking helps, a lot. E.g.

iptables -t raw -I OUTPUT -j NOTRACK

 seems to do the trick for my particular case. This turns it off for all protocols, but you could probably limit it further (e.g. for tcp only with a "-p tcp" option). Also, you might want to do this on the input as well, e.g.

iptables -t raw -I PREROUTING -j NOTRACK

We found this old report against Fedora Core 10 as well, which describes the same problem, but no solution.

Hacking: 

yum, rpm and duplicate versions

Apparently, when doing "yum update", and it fails miserably, you can end up with duplicate versions of packages in the RPM database. This seems harmless, but is annoying. yum provides a tool to check for this, but I was not able to find anything that would automatically repair it. So here's a little tip:

$ yum check duplicates | awk '/is a duplicate/ {print $6}' > /tmp/DUPES
$ yum remove `cat /tmp/DUPES`

 Of course, before you remove the dupes, make sure to examine the tmp file (/tmp/DUPES) and make sure it looks ok.

Update:

There seems to be a command to do this, package-cleanup has an option for it. E.g.

$ package-cleanup --cleandupes

However, testing this command on a second box having the same problem gave bad results, it seems to have uninstalled the "real" packages too.

Hacking: 

Fedora Core 12 with nVidia drivers

I fried my old CPU while benchmarking Traffic Server (yeah, it's that fast ...), so I spent most of the day replacing the mother board / CPU. I figured I'd take the opportunity to ugprade to Fedora Core 12 as well. This mostly worked well, with one exception: FC12 now comes with the OpenSource nvidia drivers, and they are slow. Unfortunately, these drivers also conflicts with the nVidia closed source drivers (which I install from source), causing the installation to fail. But, with a few changes in my system configs, I worked around it.

First, change /etc/grub.conf and edit the "kernel" line, to include something like

rdblacklist=nouveau

Secondly, edit /etc/modprobe.d/blacklist.conf and add a line

blacklist nouveau

I'm not sure why both are necessary, maybe I did something wrong and you only need one or the other. Let me know if that is the case, I'm happy with what I got, and not wasting any more time on it.

Hacking: 

Fedora Core 12 and focus follow mouse

For some unknown reasons (I'm guessing someone trying to be overzealous about what the Fedora users should do), FC12 no longer includes the control panel to modify the "Window" behavior. This includes the must-have feature of "Select windows when the mouse moves over them". But wait, no need to switch to Ubuntu quite yet, there's a simple fix to restore this control panel:

$ sudo yum install control-center-extra

 

Hacking: 

Pages

Subscribe to RSS - Fedora