Problems with Fedora 10

By Rebecca Sobol
December 10, 2008

LWN has received several emails regarding bugs in Fedora. These are serious bugs that can prevent you from installing new updates, or new packages of any kind. Fedora users may want to be aware of the following and, perhaps, wait until things settle down a bit.

The start things off, bug #475068 was reported for Fedora 9 with x86_64. This bug is present in Fedora 10 and also affects x86 systems. There was a workaround for this bug, for Fedora 10 users, involving using yumdownloader to install an older version of dbus. Unfortunately the older packages won't show up on all mirrors. It is still possible to recover from this bug by manually editing /etc/dbus-1/system.conf and rebooting the system. Fedora 9 users will need this version of PackageKit. For Fedora 10 you'll want this version of PackageKit.

Bug #475069 covers a dbus access problem with bluez. If you are seeing the error message: "Agent registration failed: A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.bluez.Adapter" member "RegisterAgent" error name "(unset)" destination "org.bluez").", this may help. Fedora 9 users will want bluez-utils-3.36-3.fc9. Fedora 10 users should grab bluez-4.22-2.fc10. If you are still running Fedora 8 the proper package to get is bluez-utils-3.35-5.fc8.

Another bug that may be troubling you is bug #469434, in which subnetmask settings are not saved. For some people this has been fixed. That fix did not seem to work for everyone though. The system-config-network-1.5.94-2.fc10 update does seem to work.

If you run into the error "PackageKit failed to get a TID" you will want to see this forum thread which affected several people on December 7, 2008. So far, no fix seems to be forthcoming.

Bugs in PackageKit are especially troubling for some, since you can't install an update using the GUI tools. Your editor completed a fresh install of Fedora 10 last weekend on an aging Thinkpad laptop. After the usual update she could no longer find or update any packages. A manual yum update did not help. It would appear that bug #475656 addresses the error "failed to get a TID: A security policy in place prevents this sender from sending this message to this recipient...". No doubt a SELinux expert could edit the offending policy. The rest of us will have to wait for a fix.

Editors note: as noted in the comment below, this is a DBus security problem and has nothing to do with SELinux. This last bug was reported December 9, and by December 10 a fix was already being tested.

Problems with Fedora 10

Posted Dec 11, 2008 1:55 UTC (Thu) by walters (subscriber, #7396) [Link] (3 responses)

It's not SELinux policy, it's fallout from http://lists.freedesktop.org/archives/dbus/2008-December/... which is DBus security. And a completely mistaken push of a partial known-to-break things into stable by accident.

Problems with Fedora 10

Posted Dec 11, 2008 13:02 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

The proposed fix seems not to be 'back this out, it breaks the world' but rather 'change every policy in N different packages'. This seems... unwise: everyone shipping those packages will need to track this. (Does it break KDE4 as well? I hope not!)

Problems with Fedora 10

Posted Dec 15, 2008 6:10 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Eventually, reverting back to the previous version of dbus is what happened.

Problems with Fedora 10

Posted Dec 15, 2008 7:53 UTC (Mon) by nix (subscriber, #2304) [Link]

Ah. Sensible. I suspect the dbus upstream will probably have to do
something similar, and declare 1.4.x or whatever a de-facto major release,
even though it's API and ABI-compatible :/

Problems with Fedora 10

Posted Dec 11, 2008 3:32 UTC (Thu) by jhs (guest, #12429) [Link]

This will remind people how difficult it is to release quality community distributions on a regular basis. It's the other side of the coin where Debian releases slower than death but with great stability and coherence.

(At any rate, I've heard that F10 is very nice overall and I'll still upgrade to it in lieu of Ibex.)

SCSI unbootable

Posted Dec 11, 2008 12:36 UTC (Thu) by epa (subscriber, #39769) [Link] (3 responses)

I was bitten by <http://article.gmane.org/gmane.linux.redhat.fedora.tester...> or something very like it where the 2.6.27 kernel and initrd could not mount the root filesystem. The suggested workarounds didn't fix it for me so I am currently running Fedora 10 but still with the 2.6.26 kernel from the previous release.

It was quite a lot of hassle to fix, but that's the price you pay for running your server on a distribution that is kept up to date with the latest releases. I am sure RHEL, SLES or CentOS running on officially supported hardware would be much smoother than Fedora on a leftover old workstation, but you get what you pay for. I'm still happy to run Fedora on the server.

SCSI unbootable

Posted Dec 11, 2008 13:21 UTC (Thu) by pizza (subscriber, #46) [Link] (2 responses)

I was bitten by this too -- there doesn't seem to be concensus as to what the actual root cause is just yet, but the net result is that the rootfs probe happens before the SCSI busses are done enumerating. At least on 3ware and sym53c8xx adapters.

I worked around it by modifying the initrd script to force 'wait_for_scsi="yes"'.

SCSI unbootable

Posted Dec 11, 2008 22:47 UTC (Thu) by nix (subscriber, #2304) [Link]

FWIW, I've run both 2.6.26 and 2.6.27 with a homebrewed uClibc-based
initramfs that mounts an LVM LV-atop-md-atop-sym53c8xx as the root
filesystem. SCSI bus enumeration happens *before* the kernel passes
control to the initramfs, and everything works just fine.

I have non-modular SCSI, and SCSI_SCAN_ASYNC=y.

If you're building SCSI as a module and have SCSI_SCAN_ASYNC set, you have
to pass scsi_mod.scan=sync on the kernel commandline, or 'modprobe
scsi_wait_scan'.

(This is explained in the help for SCSI_SCAN_ASYNC.)

SCSI unbootable

Posted Dec 12, 2008 3:48 UTC (Fri) by jwb (guest, #15467) [Link]

I had the same problem on Debian Etch-and-a-half *stable* update. My Sun v20z servers suddenly could not boot, because the root mount was not waiting for SCSI to settle. I had to add rootdelay=xyz to my kernel command line, if I recall correctly.