Bug 335621
| Summary: | lost+found directories mislabeled | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ulrich Drepper <drepper> |
| Component: | anaconda | Assignee: | Peter Jones <pjones> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 8 | CC: | dwalsh, esandeen, kzak, lz, oliver, rcoker, triage |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | bzcl34nup | ||
| Fixed In Version: | Current | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-04-06 11:44:49 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Ulrich Drepper
2007-10-17 05:14:05 UTC
hmm somewhat related: bug #157833 Ok, what *used* to do this labeling? It wasn't e2fsprogs... What changed? 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 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. 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. Should be fixed in anaconda-11.3.0.43-1 . *** Bug 337581 has been marked as a duplicate of this bug. *** *** Bug 157833 has been marked as a duplicate of this bug. *** 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 rawhide. (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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. A quick check of my F9 box shows /boot/lost+found with the correct label. |