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

Bryan Call showed me this little nugget: There's a plugin for yum called presto, which lets you use different set of RPMs which only contain a "delta" of the changes. This can save a lot of time both on downloads and installations. It's really easy to install and activate, just:

$ sudo yum install yum-presto

One of my VMs is running Ubuntu with BTRFS on the boot disk. During an Ubuntu upgrade, I noticed a significant increase in disk space usage, and it turns out Ubuntu created a snapshot on my BTRFS volumes. Now, this is pretty neat, but once I verified everything was working fine, I wanted to delete the old snapshot. It turned out to be a bit more trickier than I though, but with some help from Sami Haahtinen, I got it to work. First, to list the sub volumes, I did

ubuntu-server (16:07) 3/0 $ sudo btrfs subvolume list /
ID 256 top level 5 path @
ID 257 top level 5 path @home
ID 258 top level 5 path @apt-snapshot-release-upgrade-oneiric-2011-10-13_12:41:44

The next step, which was crucial, is to "mount" the full disk BTRFS is using, without specifying a sub-volume:

ubuntu-server (16:09) 4/0 $ sudo mount /dev/mapper/ubuntu--server-slash /mnt

Your disk name will obviously differ (most likely), but after this, you can now delete this sub-volume:

ubuntu-server (16:09) 5/0 $ cd /mnt
ubuntu-server (16:10) 6/0 $ sudo btrfs subvolume delete '@apt-snapshot-release-upgrade-oneiric-2011-10-13_12:41:44'

Ubuntu 11.10 was just released, and I eagerly decided to upgrade my "server' VM to "Oneiric Ocelot". My installation has no GUI, so I could not use the normal tools I'd use to do the live upgrade. So instead, I had to figure out the command line tools to use. Now, this is well documented, but is still worthwhile to repeat.

$ sudo apt-get install update-manager-core
$ do-release-upgrade -d

That's pretty much it, just follow the destructions on the screen (oh, and recommended not to do this over an ssh session).

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

I rarely bother to "rate limit" the amount of CPU my Linux processes can do, but since I unfortunately have to share my desktop with some CPU intensive tasks, sometimes it makes sense to do so, for multi-threaded applications at least. Linux has, for some time now, a feature to set CPU affinity for a process. This is btw something that Sun/Solaris have had for almost as long as I can remember. With this feature, you can specify which CPUs (cores) a process is allowed to use.

As an example, lets assume we want the application traffic_server to only consume core 2 and 3, you'd simply start the application with

# taskset -c 2,3 traffic_server

Now, some applications have this built in (unfortuantely traffic_server does not, yet), and there are APIs in linux to control this (see the man page for sched_setaffinity() ). You can of course also "nice" your application accordingly, but the above lets you get a somewhat more controlled behavior (again, for threaded apps that can use more than one core).

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.

To be proactive, I've found that once in a while (perhaps via a cron job) it might be a good idea to force a Linux RAID (mirror or RAID5/6) to be checked for consistency. This can easily be done from command line, with something like

% sudo echo check >  /sys/block/md0/md/sync_action

Also, to repair bad raid device, perhaps something like

% sudo echo repair >/sys/block/md0/md/sync_action

This second command solved a problem for me, where I'd get an email warnings once a week, saying "WARNING: mismatch_cnt is not 0 on /dev/md0". This was verified with

% sudo cat /sys/block/md1/md/mismatch_cnt
256

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

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 -> FC14
yum --releasever=14 distro-sync
# For FC14 -> FC15
yum --releasever=15 distro-sync
yum groupupdate Base
# For FC15 -> FC16
yum --releasever=16 --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.

Update 1: I added the FC15 public key link above, you need to import it for an FC15 upgrade to work.