Hmmm. It could be a bit of a bug..
It is possible that the developers didn't think of this case. I did have
something similar when I migrated from fedora 11 to fedora 13.
The new (upgraded) system had everything working just fine... except
for one SELinux label buried in the user structure.
This bug (sort of) turned out to be due to a rather large update to the
SELinux security definitions (more finely grained isolation), and the new
definitions assigned a different binary number to one definition... When
I did a manual relabel (it was suggested in the log), the problem disappeared.
Until I rebooted Fedora 11.
This type of change doesn't occur very often. I'm pretty sure that a
"touch /.autorelabel" would have fixed it.. But, depending on the
environment, that is not something you want to do.
Doing a relabel on a large filesystem (10,000 files and up) can take
hours and hours for a single processor scanning a 2 TB filesystem.
I used to work with filesystems with up to 50 million files... It could
take days to relabel that way.
I do know a faster way - but implementing it isn't graceful, as the
technique uses a multi-threaded scanner (each thread scans a directory
for files to be labelled, and for each directory found, either adds another
thread, or adds the directory to a work queue) - and that can overload
small systems (under 12GB) rather quickly, and even slow things
down more in small systems. It is rather quick when the resources are
available - scanning 49 million files only took 45 minutes for a backup
Like fsck, the ./autorelabel is not something to do every time, only when
known fixable errors occur. Many SELinux errors are not, or should not,
be fixed this way as it really is up to the administrator to decide about
these fixes. Just as the administrator needs to understand a bit about
filesystems to use fsck, SELinux requires the administrator to understand
a bit about SELinux labels.
I do agree that some more/different documentation on installation would
help. There is a good bit of SELinux documentation at
Though it may not be focused on what to do for "expected" errors
like this one..