As part of being used in yum, sqlite open the directory /var/yum/cache/foo/ when creating the cache for a new /etc/yum.repos.d/foo.repo file. It then fsync said directory, which is supposed to reduce possible inconsistencies should the directory be flushed to disk as a consequence. Unfortunately the unionfs file system returns on error when fsync is called on a directory. (check http://www.filesystems.org/project-unionfs.html for more information on unionfs). If you think unionfs is marginaly used, I think you're wrong. My belief is that it's used on most (if not all live CD GNU/Linux distribution) to implement a "copy on write" file system. In order to reproduce the problem in a somewhat minimal environment you can: 1) rrsync --bwlimit=80 -avHz --numeric-ids rsync://dachary.org/packaging-farm/fedora/fc5/ fc5/ 2) mkdir fc5.unionfs fc5.up 3) modprobe unionfs 4) mount -t unionfs -o rw,dirs=$(pwd)/fc5.unionfs=rw:$(pwd)/fc5=ro test-fc5 $(pwd)/fc5.up 5) chroot fc5.up 6) rm -fr /var/cache/yum/something 7) yum update It will fail with a python stack trace. There surely is a more minimal way to reproduce the bug. I can work on it if you are skeptical. The fix is extra simple and, as far as i can tell, absolutely harmless. Compile sqlite with the -DSQLITE_DISABLE_DIRSYNC=1 option. Here is a patch against the sqlite-3.3.3 spec file: --- sqlite.spec~ 2007-04-22 16:32:02.000000000 -0400 +++ sqlite.spec 2007-04-22 16:18:52.000000000 -0400 @@ -50,7 +50,7 @@ %setup -q %build -%configure %{!?with_tcl:--disable-tcl} +%configure CFLAGS='-DSQLITE_DISABLE_DIRSYNC=1' %{!?with_tcl:--disable-tcl} make %{?_smp_mflags} make doc
When I strated tracking down this problem, I thought it was a unionfs bug and filed a bug report at https://bugzilla.filesystems.org/show_bug.cgi?id=564 which will give you more details, including a full execution trace (and strace output) of the commands provided above.