This is an official-release of Broadcom's IEEE 802.11a/b/g/n hybrid Linux device driver for use with Broadcom's BCM4311-, BCM4312-, BCM4321-, and BCM4322-based hardware. This driver also supports the incorrectly identified BCM4328 chipset which is actually a BCM4321 or BCM4322 chipset.

Previously I explained how to build the Broadcom STA driver from source but now the installation and updates can all be taken care of using yum and the rpmfusion non-free repository. Just follow these two simple steps:

1) Enable the rpmfusion non-free repository.

The broadcom-wl and wl-kmod RPMs that we need are in the rpmfusion non-free repository. To enable this repo in Fedora simply do this:

su -c 'rpm -ivh http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm'

2) Update and install the driver package

Now that you have the appropriate repository enabled, to install the driver package we first ensure that we have the latest updates and then install the "broadcom-wl" package which will bring with it the required "kmod-wl" package:

su -
yum update
yum install broadcom-wl

That's all there is to it. At this stage you may need to reboot in order to enable the new driver and any new kernel that was installed during the update.

When future kernels are released a simple "yum update" command should install the new kernel and also pull in the updated Broadcom driver for that new kernel.

Update 15 November 2008: Just a note to mention that I've packaged this up into an RPM and so this driver is now available as an RPM in the rpmfusion repos for Fedora 8, 9 and 10.

See this post for instructions of how to install using the RPM version (much easier!).

Happy, happy days! At long last, a Linux Broadcom driver for the BCM4328 chipset that doesn't require ndiswrapper and Windows drivers. For me, this is really, really huge: ndiswrapper has never worked properly with NetworkManager using WPA security but this new Broadcom driver seems bullet-proof. It is even supposed to support 802.11n standard but I can't verify that just yet.

The source packages currently available from Broadcom (version 5.10.27.6) don't build on the current Fedora 9 kernel (2.6.26.5-45) and probably won't compile on any newer kernel either. Digging around a bit I found a patch that makes the driver build successfully.

Great, but that's not the whole story: I then found that with the new driver I was unable to SSH or telnet into any remote servers - bummer. However, some more digging turned up another patch that fixes this problem. With these two patches in place the new driver really rocks. For the first time in 10 months (since I bought my MacBook) I can actually connect to WPA secured networks using NetworkManager - no more fiddling around with wpa_supplicant scripts for me!

Anyhow, here's a little how-to guide to install the new Broadcom driver in Fedora 9. Note: I'm a little unsure of which Broadcom chipsets this driver actually supports but I can confirm that it works beautifully with the BCM4328 which is standard on MacBook 3,1 and 4,1 versions.

1) Preparation

Ensure you have the kernel-headers package installed for your current kernel (I presume you already have make and gcc etc installed):

su -
yum install kernel-headers

2) Patching the source yourself

If you want to patch the driver yourself, download the original driver file from the broadcom website here. Make sure to get the 32 or 64 bit version depending on your installed kernel. I've made the patches available at my Fedora 9 page so go there and grab the patches then patch the source code.

3) Using my pre-patched source (easier)

If you're not sure how to patch the source code or just can't be bothered, then go grab my ready-patched tarballs from my Fedora 9 page and untar them. Here's how:

32bit users:

wget http://www.cenolan.com/fedora9/broadcom-patched-x86_32-5.10.27.6.tar.gz
tar zxvf broadcom-patched-x86_32-5.10.27.6.tar.gz
cd broadcom-patched-x86_32-5.10.27.6/

64bit users:

wget http://www.cenolan.com/fedora9/broadcom-patched-x86_64-5.10.27.6.tar.gz
tar zxvf broadcom-patched-x86_64-5.10.27.6.tar.gz
cd broadcom-patched-x86_64-5.10.27.6/

4) Building the driver

Now we've got our patched source building the driver kernel module is easy:

make -C /lib/modules/`uname -r`/build M=`pwd`

This should create a file called wl.ko - this is the magic driver file.

5) Install the new driver

We need to copy the new kernel module to the correct location, add wlan0 as an alias for this driver so that it loads on boot and resolve the module dependencies:

su -c "cp wl.ko /lib/modules/`uname -r`/kernel/net/wireless/
su -
echo "alias wlan0 wl" >> /etc/modprobe.conf
depmod -a

6) Blacklist conflicting drivers

This new driver suffers the same conflicts as the ndiswrapper driver so we need to blacklist the b43, ssb, and bcm43xx drivers, as well as the ndiswrapper driver:

su -
echo "blacklist bcm43xx" >> /etc/modprobe.d/blacklist
echo "blacklist ssb" >> /etc/modprobe.d/blacklist
echo "blacklist b43" >> /etc/modprobe.d/blacklist
echo "blacklist ndiswrapper" >> /etc/modprobe.d/blacklist

7) Remove the old module and activate the new one

su -
rmmod bcm43xx; rmmod b43; rmmod b43legacy; rmmod ndiswrapper
modprobe ieee80211_crypt_tkip; modprobe wl

8) All done!

Reboot, or restart NetworkManager and you've hopefully got the new driver installed.

Say hello to faster and more robust connections, and say goodbye to ndiswrapper and crappy badly supported Windows drivers!

References

Broadcom 802.11 Linux STA driver at FedoraForum.org

Broadcom 802.11 Linux STA driver at broadcom.com

*OFFICIAL* Broadcom Linux driver BCM4312 at jomcode.com

Broadcom driver for 4328 b/g/n wireless device at ubuntuforums.com

Bug #259816 wl: telnet/ssh connections blocked when going through NAT to external sites at launchpad.net

Fedora 9 fixes and files for MacBook 3,1 and 4,1 (Santa Rosa)

As the original author notes, this makes it more enjoyable to use the touchpad while using the MacBook. It does two things:

1. Adds the option "MultiFingerButton" to synaptics. This allows us to configure the touchpad to right-click and middle-click by placing two or three fingers on the pad and then clicking the button. In my experience this is far more reliable than the "two finger tap" method of right-clicking.
2. It makes the mouse arrow more stable - I have found this to be a HUGE improvement in usability over the stock synaptics driver. With the original driver, if you put two fingers on the mousepad and release only one, the mouse arrow moves. This is the default behaviour in Linux and Windows, but in MacOSX, the mouse arrow stays put, and in my personal opinion, this is a much better behaviour. This patch makes it behave just like MacOSX. This may not sound much, but you'll find it makes a huge difference to the stability and usability of the touchpad.

Install the RPM from my Fedora 8 page and add this option to the InputDevice Section in your xorg.conf, just like this:

	Option		"MultiFingerButton"	"1"

	Option		"MultiFingerButton"	"2"

With the value 1, you get middle-clicking if you click the button while resting two fingers on the mousepad, and right-clicking while resting three fingers.

With the value 2, it reverses, and you get right-clicking if you click while resting two fingers on the mousepad, and middle-clicking while resting three fingers. This is the behaviour in MacOSX.

Try it out, and give your opinion. If you don't like it, you can always revert to the default Fedora package.

I have only seen this reported on some specific x86_64 machines but it may affect other architectures too.

The problem has been reported (and fixed) in many other distros and the patch to fix it has been in circulation since January. The patch was even created by someone at RedHat so it's slightly annoying that it hasn't made it yet into the Fedora versions of HAL. I can only assume it is an oversight by the HAL development team or the package maintainers. However, at the very least, a response to the bug report would have been welcome.

The RedHat bug report can be found here (Bug #452356) and contains links to various other reports which contain plenty more information.

For anyone suffering from the same problem and impatient for a fix I've created a set of RPMs that include the patch. You can find them over at my Fedora 8 page.

Hope this is useful to someone. Usual disclaimers apply: if it breaks your machine then its not my fault.

For those that don't know, Banshee is a great multimedia player for Linux with support for iPod syncing, podcasts, streaming radio, video and lots more. For iPod owners Banshee is one of few viable Linux alternatives to iTunes.

For Fedora 8 x86_64 users you can install my build of Banshee 1.0 using the following commands:

wget http://www.cenolan.com/fedora8/banshee-1.0.0-1.fc8.x86_64.rpm
yum localinstall banshee-1.0.0-1.fc8.x86_64.rpm --nogpgcheck

Note this a 64 bit build only! If you want to build it for i386 or another architecture then you can do so using the F9 source RPM available from Koji here.

More files, including the debug and devel packages over at my Fedora 8 page.

Usual disclaimers apply: if it breaks your machine then its not my fault.

Recursively find in files...

find . -name \*.php -exec grep -inH discount {} \;

This finds all files ending with .php (-name \*.php) starting in the current path (.) and recurse through all subdirectories, then search (grep) case-insensitive (i) within those files ({}) for the word "discount" and outputs the filename (H), line number (n), and the line for any matches.

Find all files older than 14 days...

find /home/*/Maildir/.Junk/cur -type f -mtime +14 -exec ls {} \;
find /home/*/Maildir/.Trash/cur -type f -mtime +14 -exec ls {} \;

These two commands find files within system users' Maildir .Junk and .Trash folders that are older than 14 days. You could change the "-exec ls" to "-exec rm -rf" to remove the files.

Find top 10 directories using disk space...

du -x --block-size=1024K | sort -nr | head -10

This finds and lists the top 10 directories using disk space in the current path. Useful if you're trying to track down what is filling up your disk.

Create and extracting a tar.gz archive of a directory...

tar -czvf (output filename) (directory to archive)

e.g. tar -czvf myhome.tar.gz /home/myhome/

To extract this archive while preserving permissions, use:

tar --preserve -zxvf (filename)

Change permissions of directories and files...

find . -type d -exec chmod 755 {} \;

This finds all directories (indicated by the -type d) in the current path (.) and then chmods them to 755. If you wanted to recursively chmod files, you could issue this:

find . -type f -exec chmod 644 {} \;

This is really for my own reference, but you may find it useful.

We completed the gruelling 25 mile trek including 1,672 metres ascent in just under 9 hours. The target time is 12 hours so we did pretty well. If you can't be bothered reading then scroll straight to the bottom for a gallery of our photos from the walk.

We set off from Liverpool at 5pm on Friday and arrived in Horton-in-Ribblesdale just before 9pm. The journey was uneventful apart from a mad dash up the platform at Leeds station just as the guard was blowing the whistle for the last train to Horton to depart... yikes! Fortunately we made it, just, otherwise it would have been a weekend in Leeds.

Claire had tomato soup which had come straight from a packet and was accompanied by the cheapest doughiest white bread roll you've ever seen. I ordered chicken and chips and was given a deep-fried hunk of chicken with some grey chips that looked like they had been cooked in fat that was as old as the pub. I wouldn't mind if it had been cheap but the prices made you feel you should be getting at least some half-decent "pub grub".

At least it gave us something to moan about!

We left the hotel just after 9am and wandered to the local shop to grab some water and to get a butty from the cafe down the road. With our provisions taken care of we started the walk at about 9:20am. Our plan was to do the walk "backwards" going clockwise from Horton: up Ingleborough then Whernside then to Ribblehead where we would decide whether to complete the final leg up Pen-y-ghent or take the train back to the hotel.

The ascent up Whernside was direct but gentle except for one short section where the path became steep and difficult. An easy walk up the broad and gentle ridge brought us to the top of Whernside only 2 hours after the previous summit. Still the weather on the tops was very foggy and we couldn't see anything. We stopped here for lunch and then headed down towards Ribblehead. During this descent we met some 200 or so other walkers who were headed upwards - I've never seen so many people on a mountain!

A very steep initial descent from Pen-y-ghent gave way to a gentle footpath and then just a short hop across a few fields and back into Horton-in-Ribblesdale. Feet in absolute agony and aching all over we were glad to be back. A short rest and shower then, figuring that the food couldn't be any worse, we walked to the other pub in the village for some well-deserved dinner. They didn't disappoint providing us with monster portions of top quality grub for a fair price. Yum yum!

You can view all our pictures (with commentary) below. Feel free to leave a comment!

I've done it before and never had a problem, but my luck ran out when I recently tried to flash the BIOS of an Acer TravelMate 6410 using the "WinPhlash" tool downloaded from the Acer website. The tool ran, backed up and erased the old BIOS, then crashed at block 5 of 16 when flashing the new BIOS. Result: a computer that won't even POST, nevermind boot.

If you really want to flash your PC's BIOS then make a bootable floppy disk containing something like minidos, the tools needed to flash the BIOS from DOS and the BIOS file itself. Then flash the BIOS by booting from this disk and running the BIOS flash tools from the command line. Trust me, its worth the extra hassle, because a failed BIOS flash is a nasty thing to recover from, and could even brick your computer.

As an aside, in my case the Acer was covered by a 3 year extended warranty that includes accidental damage. You'd think that, as the BIOS is a hardware chip, then a broken BIOS would be a hardware problem and therefore covered under the warranty. However, a call to Acer revealed that they believe it is a software problem and therefore not covered. I don't wish to get into semantics, but in my opinion a BIOS is not "software" as it is a physical component of the motherboard. Perhaps the BIOS software itself is best referred to as "firmware" rather than software. Moreover, if a BIOS flash fails due to software that they publish on their own website then I would fully expect them to honour the warranty!

Unless otherwise specified, all commands are run as a normal user, NOT root!

1) Install the FUSE userspace tools

wget http://downloads.sourceforge.net/fuse/fuse-2.7.3.tar.gz?modtime=1203456610&big_mirror=0
tar xvzf fuse-2.7.3.tar.gz
cd fuse-2.7.3
./configure
make
su -c "make install"

This should all go smoothly and you should now have the FUSE tools such as "fusermount" installed.

2) Install CurlFtpFs

wget http://downloads.sourceforge.net/curlftpfs/curlftpfs-0.9.1.tar.gz?modtime=1175788159&big_mirror=0
tar zxvf curlftpfs-0.9.1.tar.gz
cd curlftpfs-0.9.1
jm_cv_func_working_malloc=yes
export jm_cv_func_working_malloc
ac_cv_func_malloc_0_nonnull=yes
export ac_cv_func_malloc_0_nonnull
jm_cv_func_working_realloc=yes
export jm_cv_func_working_realloc
ac_cv_func_realloc_0_nonnull=yes
export ac_cv_func_realloc_0_nonnull
./configure
make
su -c "make install"

Again, this should all go smoothly and you should now have the "curlftpfs" program installed.

3) Mounting the FTP server

Mounting procedure is as follows:

mkdir MountPoint (eg: mkdir /backup)
curlftpfs -o user=USERNAME:PASSWORD ftp://FTPHost/ MountPoint/
eg: curlftpfs -o user=testusr:mypass ftp://127.0.0.1/ /backup/

Follow all the commands as a normal user, NOT root!

1) Create an rpm build environment

cd ~
mkdir ~/rpmbuild
mkdir ~/rpmbuild/BUILD
mkdir ~/rpmbuild/RPMS
mkdir ~/rpmbuild/SOURCES
mkdir ~/rpmbuild/SPECS
mkdir ~/rpmbuild/SRPMS

echo "%_topdir /home/`whoami`/rpmbuild" > ~/.rpmmacros

2) Download and install the source rpm of the current kernel.

Note: this is not the kernel-source rpm!

wget http://www.mirrorservice.org/sites/ftp.yellowdoglinux.com/pub/yellowdog/releases/yellowdog-6.0/SRPMS/kernel-2.6.23-9.ydl6.1.src.rpm
rpm -ivh kernel-2.6.23-9.ydl6.1.src.rpm

3) Prepare the kernel source tree

cd ~/rpmbuild/SPECS
rpmbuild -bp --target=`uname -m` kernel.spec

4) Configure the kernel

cd ~/rpmbuild/BUILD/kernel-2.6.23/linux-2.6.23.9/
cp configs/kernel-2.6.23-ppc.config .config
make oldconfig
make menuconfig

Using the down arrow key navigate to "File systems" then press Enter and then scroll down to "Filesystem in Userspace support" and press "M" to select it as a module. Press Tab to select Exit in the bottom bar, then do it again, then press Y when prompted to save the configuration.

Copy the config file to ~/rpmbuild/SOURCES/:

cp .config ~/rpmbuild/SOURCES/kernel-2.6.23-ppc.config

5) Prepare the build files

cd ~/rpmbuild/SPECS

Open up the kernel.spec file for editing and ensure the kernel has a unique name by changing the following line (line 32)

%define release %{subrev}.ydl6.%{rpmrev}

to

%define release %{subrev}.ydl6fuse.%{rpmrev}

6) Build the new kernel

rpmbuild -bb --with baseonly --without debuginfo --target=`uname -m` kernel.spec

The build process takes a long time to complete. A lot of messages will be printed to the screen. These messages can be ignored, unless the build ends with an error. If the build completes successfully, the new kernel packages in the ~/rpmbuild/RPMS directory.

7) Install the new kernel

cd ~/rpmbuild/RPMS/ppc
su -c "rpm -ivh kernel-2.6.23-9.ydl6fuse.1.ppc.rpm kernel-headers-2.6.23-9.ydl6fuse.1.ppc.rpm --oldpackage"

8) Make the new kernel boot by default

As root, open up /boot/etc/yaboot.conf for editing. You should now see two kernel images listed as boot options. Change the label of the ydl6fuse image to something friendly like "linuxfuse". Now change the "default" line to the same.

For example:

default=linuxfuse
image=/vmlinux-2.6.23-9.ydl6fuse.1
label=linuxfuse
read-only
initrd=/initrd-2.6.23-9.ydl6fuse.1.img
append="root=LABEL=/"

image=/vmlinux-2.6.23-9.ydl6.1
label=linux
read-only
initrd=/initrd-2.6.23-9.ydl6.1.img
append="root=LABEL=/"

Important: Ensure you also have a line that says "delay=5" (or a greater number) so if your new kernel won't boot you can still access the yaboot menu to boot your old kernel!

Save and exit the file.

Now run "ybin" (again, as root) to commit the changes. Reboot!

9) Load the fuse module

su -
modprobe fuse

To make the fuse module load on boot. Create the file /etc/sysconfig/modules/my.modules and give it the following contents:

#!/bin/sh
modprobe fuse >/dev/null 2>&1

Save and exit. Now make it executable:

chmod +x /etc/sysconfig/modules/my.modules

10) Finished!

Your kernel now supports FUSE. Now you can use any of the various userspace tools to mount the various filesystems supported by FUSE.

One tool that is very simple to use is s3cmd which is a linux command line tool to upload, retrieve, and manage data in Amazon S3. The tool is written in python so should install and run on pretty much any modern linux distro and I have found it works very nicely and seems to be an ideal tool to use if you want to write a basic backup script.

Once installed you just run "s3cmd --configure" to configure the script with your Amazon S3 access keys. You can then use s3cmd from the command line to manage your S3 buckets and their contents. Full details of the various options can be obtained through running "s3cmd --help".

I have used s3cmd to create automated daily rotated backups of a single directory (e.g. /home) using a simple bash script which I adapted from the automysqlbackup script. The script I have used is shown below, and provides rotated backups of the previous 7 days, each day individually archived in a single tar.gz file. This is a fairly limited solution as it only provides a backup of a single directory, does not do incremental backups, and it will break if your tar.gz file exceeds the S3 individual file storage limit of ~6GB. However, if you just need a simple solution to maintain daily backups of a single folder then its a nice tidy option. It will also email you the results, and can optionally include jobs to run pre- and post- backup.

#!/bin/bash
#
# Backup Script
#
#=====================================================================
#=====================================================================
# Set the following variables to your system needs
#=====================================================================

# Directory to save daily tar.gz backup files to e.g /backups
BACKUPDIR="/backups"

# Directory to backup
BACKUPSRCDIR="/home"

# Maximum size of backup files in MB (larger files will be split into separate archives)
# Note: not implemented yet
MAXTARSIZE="1000"

# S3 Settings
# The name of the S3 bucket to upload to e.g. "my_s3_bucket"
S3BUCKET="my_s3_bucket"

# Mail setup
# What would you like to be mailed to you?
# - log   : send only log file
# - files : send log file and tar.gz files as attachments
# - stdout : will simply output the log to the screen if run manually.
# - quiet : Only send logs if an error occurs to the MAILADDR.
MAILCONTENT="log"

# Set the maximum allowed email size in k. (4000 = approx 5MB email [see docs])
MAXATTSIZE="4000"

# Email Address to send mail to? (user@domain.com)
MAILADDR="user@domain.com"

# Command to run before backups (uncomment to use)
#PREBACKUP="/etc/backup-pre"

# Command run after backups (uncomment to use)
#POSTBACKUP="/etc/backup-post"

#=====================================================================
#=====================================================================
#=====================================================================
#
# Should not need to be modified from here down!!
#
#=====================================================================
#=====================================================================
#=====================================================================
PATH=/usr/local/bin:/usr/bin:/bin:
DATE=`date +%Y-%m-%d_%Hh%Mm`                            # Datestamp e.g 2002-09-21
DOW=`date +%A`                                          # Day of the week e.g. Monday
DNOW=`date +%u`                                         # Day number of the week 1 to 7 where 1 represents Monday
DOM=`date +%d`                                          # Date of the Month e.g. 27
M=`date +%B`                                            # Month e.g January
W=`date +%V`                                            # Week Number e.g 37
VER=0.1                                                 # Version Number
HOST=`hostname`                                         # Hostname for LOG information
LOGFILE=$BACKUPDIR/$HOST-`date +%N`.log                 # Logfile Name
LOGERR=$BACKUPDIR/ERRORS_$HOST-`date +%N`.log           # Error log Name
BACKUPFILES=""

# Create required directories
if [ ! -e "$BACKUPDIR" ]                # Check Backup Directory exists.
then
mkdir -p "$BACKUPDIR"
fi

# IO redirection for logging.
touch $LOGFILE
exec 6>&1           # Link file descriptor #6 with stdout.
# Saves stdout.
exec > $LOGFILE     # stdout replaced with file $LOGFILE.
touch $LOGERR
exec 7>&2           # Link file descriptor #7 with stderr.
# Saves stderr.
exec 2> $LOGERR     # stderr replaced with file $LOGERR.

# Functions

# Backup function: removes last weeks archive from S3, creates new tar.gz and sends to S3
SUFFIX=""
dobackup () {
s3cmd ls s3://"$S3BUCKET" | grep s3 | sed "s/.*s3:\/\/$S3BUCKET\//s3:\/\/$S3BUCKET\//" | grep "$DOW" | xargs s3cmd del
tar cfz "$1" "$2"
echo
echo Backup Information for "$1"
gzip -l "$1"
echo
s3cmd put "$1" s3://"$S3BUCKET"
return 0
}

# Run command before we begin
if [ "$PREBACKUP" ]
then
echo ======================================================================
echo "Prebackup command output."
echo
eval $PREBACKUP
echo
echo ======================================================================
echo
fi

echo ======================================================================
echo BackupScript VER $VER
echo http://www.cenolan.com/
echo
echo Backup of Server - $HOST
echo ======================================================================

echo Backup Start Time: `date`
echo ======================================================================
# Daily Backup
echo Daily Backup of Directory \( $BACKUPSRCDIR \)
echo
echo Rotating last weeks Backup...
eval rm -fv "$BACKUPDIR/*.$DOW.tar.gz"
echo
dobackup "$BACKUPDIR/$DATE.$DOW.tar.gz" "$BACKUPSRCDIR"
BACKUPFILES="$BACKUPFILES $BACKUPDIR/$DATE.$DOW.tar.gz"
echo
echo ----------------------------------------------------------------------
echo Backup End Time: `date`
echo ======================================================================
echo Total disk space used for backup storage..
echo Size - Location
echo `du -hs "$BACKUPDIR"`
echo
echo ======================================================================
echo ======================================================================

# Run command when we're done
if [ "$POSTBACKUP" ]
then
echo ======================================================================
echo "Postbackup command output."
echo
eval $POSTBACKUP
echo
echo ======================================================================
fi

#Clean up IO redirection
exec 1>&6 6>&-      # Restore stdout and close file descriptor #6.
exec 1>&7 7>&-      # Restore stdout and close file descriptor #7.

if [ "$MAILCONTENT" = "files" ]
then
if [ -s "$LOGERR" ]
then
# Include error log if is larger than zero.
BACKUPFILES="$BACKUPFILES $LOGERR"
ERRORNOTE="WARNING: Error Reported - "
fi
#Get backup size
ATTSIZE=`du -c $BACKUPFILES | grep "[[:digit:][:space:]]total$" |sed s/\s*total//`
if [ $MAXATTSIZE -ge $ATTSIZE ]
then
BACKUPFILES=`echo "$BACKUPFILES" | sed -e "s# # -a #g"` #enable multiple attachments
mutt -s "$ERRORNOTE MySQL Backup Log and SQL Files for $HOST - $DATE" $BACKUPFILES $MAILADDR < $LOGFILE       #send via mutt
else
cat "$LOGFILE" | mail -s "WARNING! - Backup exceeds set maximum attachment size on $HOST - $DATE" $MAILADDR
fi
elif [ "$MAILCONTENT" = "log" ]
then
cat "$LOGFILE" | mail -s "Backup Log for $HOST - $DATE" $MAILADDR
if [ -s "$LOGERR" ]
then
cat "$LOGERR" | mail -s "ERRORS REPORTED: MySQL Backup error Log for $HOST - $DATE" $MAILADDR
fi
elif [ "$MAILCONTENT" = "quiet" ]
then
if [ -s "$LOGERR" ]
then
cat "$LOGERR" | mail -s "ERRORS REPORTED: Backup error Log for $HOST - $DATE" $MAILADDR
cat "$LOGFILE" | mail -s "Backup Log for $HOST - $DATE" $MAILADDR
fi
else
if [ -s "$LOGERR" ]
then
cat "$LOGFILE"
echo
echo "###### WARNING ######"
echo "Errors reported during Backup execution.. Backup failed"
echo "Error log below.."
cat "$LOGERR"
else
cat "$LOGFILE"
fi
fi

if [ -s "$LOGERR" ]
then
STATUS=1
else
STATUS=0
fi

# Clean up Logfile
eval rm -f "$LOGFILE"
eval rm -f "$LOGERR"

exit $STATUS

I have posted this largely for my own information but maybe somebody else will find this useful.

Here's what I did:

1) Dump the database into a sql file using mysqldump:

mysqldump --opt --quote-names -u username -p password my_database > my_database.sql

2) Convert the dumped sql data from the current character set to utf-8, for example:

iconv -f ISO_8859-1 -t UTF-8 my_database.sql > my_database-utf-8.sql

3) Change the CHARSET definitions in the sql file to utf8. You could do this by manually editing the file, but this little perl snippet will do it for you (here we're going from latin1 to utf8 - change to fit your needs):

perl -pi -w -e 's/CHARSET=latin1/CHARSET=utf8/g;' my_database-utf-8.sql

4) Import the database back into mysql:

mysql -u username -p password my_database < my_database-utf-8.sql

Voila. Your database and data is now converted to utf-8.

The kernel packages are not needed now since Fedora 8 kernel 2.6.24.3-50 (and newer) already contains the MacBook specific fixes. However, at the time of writing the gstreamer packages are still required if you want to use gstreamer based applications with the MacBook iSight camera.

Before downloading, please take care of my bandwidth. If you don't need the package, please don't download it.

You can download the packages here.

There is also this thread at fedoraforum.org which may be helpful.

If you find any problems or have any suggestions please let me know.

I couldn't find any information on the lazyweb about installing Fedora 8 on a MacBook so I recorded what I did and made a detailed how-to which is posted in the wiki over at mactel-linux.org. The guide shows you step-by-step how to install and configure Fedora 8 x86_64 on the MacBook and works with both MacBook version 3,1 (from late 2007) or version 4,1 (from early 2008).

Big up to the guys at Fedora who gave in to my relentless nagging and integrated some of the mactel-linux patches into the latest Fedora kernels. Without them I'd still be spending my weekends rolling kernels!

If you find the guide useful or have any comments or suggestions then let me know.

So, for the nth time, here goes again. Maybe I'll even think of something interesting to say.