last updated: $Date: 2005/10/24 10:17:09 $
Specifically, I wanted to try upgrading with yum, under a live OS - not from a CD-booted environment - and from a local yum repository. So this document is as much about how to set up and maintain such repositories as it is about the Lifebook. Sorry if that's not what you wanted, but I need to learn things!
The original install can be read about here. This page is organised into the following sections:
Having got them, you need to unpack them to start your local repository.
Make a directory to hold them, with
mkdir -p /path/to/unpackdir
Each ISO image, in turn, should be mounted as a loopback image,
and copied to the
destination unpack directory, with
mkdir /mnt/loop, followed by
mount -o loop-ro -t iso9660 /path/to/FC2-i386-disc1.iso /mnt/loop
(cd /mnt/loop; tar cf - .)|(cd /path/to/unpackdir; tar xfp -)
umount /mnt/loop
done once for each of the four disc images.
Now you have most of what you need, save only the headers. I find the
easiest way to get those (and, incidentally, to keep your updates
directory up to date), is to use mirrordir. Sadly, the home
directory for this package seems to have vanished from the web, but you can
find rpms at rpmfind.net.
The package hasn't been updated for some time, but it still seems to work.
Install and then invoke it with
mirrordir -v --no-chown ftp://your.preferred.server/path/to/fc/core/2/i386/os /path/to/unpackdir
which should pretty much retrieve the headers directory, and set a few
atimes/mtimes. If you don't want the isos, skip the iso getting/unpacking
steps and just do the mirrordir - but it will take a long time!
While we're here, let's create the updates directory, and make
arrangements for it to be kept up to date. Make a destination directory
with
mkdir -p /path/to/updatesdir
and populate it with
mirrordir -v --no-chown
ftp:///your.preferred.server/path/to/fc/core/updates/2/i386
/path/to/updatesdir
You can run this nightly from cron, to keep your repository
automatically up-to-date, if you are so minded. If you do, drop the
-v flag, otherwise you get *very* long emails.
Upgrade with the command
There appears to be a new file, /etc/modprobe.conf, which may
have something to do with this. But I don't yet understand it, so I've put
a stack of modprobe instructions in /etc/rc.d/rc.local.
News as it's made.
At
www.holtmann.org/linux/kernel/ I found a pointer to www.bluez.org/patches.html
with patches to 2.4, as I expected, but also to 2.6.8 (alone amongst 2.6).
Maybe something got backed out of linus' kernel? In any case, i downloaded
the patchfile, gunzip'ed it, and put it in /usr/src. I then cd
/usr/src/linus-2.6.8.1, and do a
If it's any use, my kernel config can be found here.
Rebooting off this patched kernel cured the minicom error noted above,
but I then had a problem with the new PCMCIA loaders not finding the
firmware, which I used to have in /etc/bluetooth/firmware. So,
after doing set -vx on some scripts, and tracing a few things, I
did a
When I want it to go to sleep, I do (as root) a
So far, I have suspended-to-disc about 15 times, of which 14 have been
successful. In the other case, I had so many apps open that it complained
it couldn't find enough spare swap to save the whole of core, then froze
up. Basically, I need more swap. Also, when resuming, USB doesn't seem to
restart; rmmod'ing and modprobe'ing ohci_hcd seems to fix that.
To streamline all these processes, I have made a tiny shellscript called
/usr/local/sbin/snooze.
The gnome battery applet has a hook to
call an external script in order to suspend the computer, so under battery
charge monitor -> preferences -> general, I put a suspend command of
sudo /usr/local/sbin/snooze and used visudo to put the line
Suspend-to-RAM works fine when i unload the ohci_hcd module
Otherwise, I get a Could not suspend device 0000:00:02.0 error, two
beeps and a rapid return to service.
However, despite suspend working fine, wakeup from suspend doesn't work at
all! So I'm not using suspend-to-RAM at the moment.
yum upgrade
You should see an awful lot of headers being downloaded, then an enormous
list of packages to be upgraded. Yum will stop and ask you if you want to
go on. If you're happy with this, say so. Wait for a long time until the
upgrade is completed; mine took a couple of hours. Reboot afterwards, and
check that you're running the latest kernel, and that cat
/etc/redhat-release returns FC2.
Hand-hacked stuff, including the kernel
My biggest complaint about this upgrade is that a lot of modules
that used to load automatically, now have to be manually loaded. This
includes the yenta_socket module, so I have to restart pcmcia card services
on every boot, the soundcard module, the pcspkr module (without which my
keyboard beep didn't work), the usb-ohci module for USB support, the
psmouse module for the clitmouse, and the orinoco_pci module for the
wireless.
Bluetooth
Although buetooth support seems better in FC2, I found that getting it to
work for GPRS purposes still required some kernel work. When I repeated my
earlier work, detailed here, then when
attempting to talk to the 'phone using minicom bluetooth, I got
the error
minicom: cannot open /dev/rfcomm: No such device
patch -p1 < ../patch-2.6.8-mh1
The Makefile hunk failed to apply but that's because i'm using 2.6.8.1 not
2.6.8 (because i don't want NFS to crash wildly), and i don't much care
about having the -mh1 extension on the kernel name (sorry, marcel!). If
patches against 2.6.8.1 are available, you'll use those and won't have the
same problem.
mkdir -p /usr/lib/bluetooth/firmware
cp -p /etc/bluetooth/firmware/BT3CPCC.bin /usr/lib/bluetooth/firmware/
made sure that /etc/rc.d/init.d/bluetooth is running at boot time,
and my GPRS/bluetooth combo is working again with no further changes.
Suspend-to-disc
This has been the big bugbear since I installed FC1. Having just built
2.6.8.1, it seems that most of the ACPI-suspend code is in the mainstream
kernel, which is great news. Moreover, the x.org Xserver in FC2
seems to support this much better than FC1 did.
I had to modify my /boot/grub/grub.conf, to boot from the new
kernel, and to know where to sleep to/from, so the relevant section now reads
title 2.6.8.1
root (hd0,0)
kernel /vmlinuz-2.6.8.1 ro root=/dev/hda5 resume=/dev/hda3
where /dev/hda3 is my normal swap partition.
echo 4 > /proc/acpi/sleep
and it all just snoozes.
myusername ALL = NOPASSWD: /usr/local/sbin/snooze
in my sudoers file. Now, when I right-click the battery applet,
and select "Suspend Computer", the box snoozes peacefully!
notes for later expansion:
(hciconfig hci0 up)
/dev/hci0 doesn't appear, but that doesn't seem to be an issue