Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 335621 - lost+found directories mislabeled
Summary: lost+found directories mislabeled
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
Whiteboard: bzcl34nup
: 157833 337581 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-10-17 05:14 UTC by Ulrich Drepper
Modified: 2014-01-18 20:30 UTC (History)
7 users (show)

Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-04-06 11:44:49 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1038146 None None None Never

Internal Links: 1038146

Description Ulrich Drepper 2007-10-17 05:14:05 UTC
Description of problem:
I did a clean install (empty harddrive) using the F8t3 DVD (x86-64, but this
shouldn't matter).  I ran a full yum update afterwards but this shouldn't matter

The state after the install was that none of the lost+found directories had the
appropriate SELinux label (system_u:object_r:lost_found_t).  They usually were
labeled with system_u:object_r:file_t.

This causes all kinds of problems (including tmpwatch to fail).

Version-Release number of selected component (if applicable):
whatever is in F8t3

How reproducible:
I only installed once

Steps to Reproduce:
1.Install from F8t3 DVD yum update
Actual results:
incorrectly labeled lost+found

Expected results:
correctly labeled lost+found

Additional info:
I doubt this is an SELinux issue.  The policy contains the information since a
follow restorecon corrects the problem.

Comment 1 Eric Sandeen 2007-10-17 20:12:09 UTC
hmm somewhat related: bug #157833

Comment 2 Eric Sandeen 2007-10-17 20:39:01 UTC
Ok, what *used* to do this labeling?  It wasn't e2fsprogs...  What changed?

Comment 3 Eric Sandeen 2007-10-17 21:20:01 UTC
I just did a fresh F8T4 install, and:

[root@localhost ~]# ls -Zd /lost+found/
drwx------  root root system_u:object_r:file_t:s0      /lost+found/

[root@localhost ~]# ls -Zd /boot/lost+found/
drwx------  root root system_u:object_r:file_t:s0      /boot/lost+found/

so, I guess it persists in test4

Comment 4 Eric Sandeen 2007-10-17 22:07:33 UTC
Why shouldn't anaconda add each fileystem's lost+found/ dir to the list of files
that it must run restorecon on?  I don't think mkfs is the place to do this; for
one thing, mkfs has no idea where this filesystem will be mounted, and that may
well affect the labels it receives.

Comment 5 Eric Sandeen 2007-10-17 23:35:02 UTC
I'm going to punt this back to anaconda; there are bigger issues around all this
I think, but today, if a system administrator creates & mounts a new filesystem,
they need to run restorecon on the new fs to get the labels set properly.  

IMHO anaconda is acting in this administrator role during install, and therefore
should run restorecon on fresh filesystems as it mounts them (or something like
that... it probably gets more complex if anaconda is using filesystems that it
didn't mkfs...)

At any rate I don't see how this is an e2fsprogs bug; no mkfs has any idea where
the new filesystem will be mounted, and therefore has no way to apply the proper
labels at creation time, in general.

Comment 6 Peter Jones 2007-10-18 20:41:41 UTC
Should be fixed in anaconda- .

Comment 7 Daniel Walsh 2007-10-18 21:30:04 UTC
*** Bug 337581 has been marked as a duplicate of this bug. ***

Comment 8 Eric Sandeen 2007-10-18 21:43:29 UTC
*** Bug 157833 has been marked as a duplicate of this bug. ***

Comment 9 Bug Zapper 2008-04-04 14:09:03 UTC
Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.

If this bug still exists in rawhide, please change the version back to
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)

Thanks for your help and we apologize for the interruption.

The process we're following is outlined here:

We will be following the process here: to ensure this
doesn't happen again.

Comment 10 Eric Sandeen 2008-04-04 16:01:06 UTC
A quick check of my F9 box shows /boot/lost+found with the correct label.

Note You need to log in before you can comment on or make changes to this bug.