sharing a partition betweed FC3 and FC5

[D. Hugh Redelmeier]

[I sent this to fedora-list(a)redhat.com a couple of minutes ago.  I 
apologize for cross-posting.]

I installed 32-bit Fedora Core 5 on an Athlon-64 box.  I intended this
installation to co-exist with a 64-bit Fedora Core 3 installation.
The two installations share a /home ext3 partition and the swap partition.
This is often how I do upgrades: a dual boot system with both old and
new bootable.

The problem is that the FC5 installation did something to
the /home partition that prevents the FC3 from mounting it.

When I manually try a mount of /home from FC3, the useless
mount-failure message is preceded by these messages.  I think that
they are the key:

    inode_doinit_with_dentry:  context_to_sid(system_u:object_r:home_root_t:s0) returned
22 for dev=hda5 ino=2
    inode_doinit_with_dentry:  context_to_sid(system_u:object_r:home_root_t:s0) returned
22 for dev=hda5 ino=2

(In dmesg, these two messages were preceded by these that might be relevant:
    kjournald starting.  Commit interval 5 seconds
    EXT3 FS on hda5, internal journal
    EXT3-fs: mounted filesystem with ordered data mode.
    SELinux: initialized (dev hda5, type ext3), uses xattr
)

(The useless mount failure message is:
  mount: wrong fs type, bad option, bad superblock on /dev/hda5
         or too many mounted file systems
 This message is disgracefully non-specific.)

I think that this is a problem with SELinux.  The following thread
looks relevant but unhelpful:
  http://www.redhat.com/archives/fedora-selinux-list/2006-April/msg00002.html
It provides a solution (I hope) for FC4 but FC3 would not have such an update.

I tried using enforcing=0 on the FC3 kernel command line, but nothing changed.

I thought ext3 was compatible between Fedora releases.  Unfortunately,
SELinux seems to have made things a lot more brittle.

==> Is there something simple that I can do to allow the existing
    /home ext3 partition to be shared between FC3 and FC5?

==> What does the error message mean?
    inode 2 is the root of the filesystem.
    It appears that kernel routine inode_doinit_with_dentry is calling context_to_sid
    and context_to_sid is returning EINVAL (because the context was invalid).
    But even knowing that, I don't know what it actually means or is caused by.

(By the way, if FC5 worked well, it might not matter.  Unfortunately,
there is some regression in xorg that prevents dual-head working
properly on FC5 where it did on FC3.)