Bug 804779
Summary: | XFS is not an available installation time file system | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chris Murphy <bugzilla> |
Component: | lorax | Assignee: | Martin Gracik <mgracik> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | anaconda-maint-list, awilliam, bcl, dmach, esandeen, g.kaviyarasu, jonathan, mgracik, mishu, robatino, vanmeeuwen+fedora |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | AcceptedNTH | ||
Fixed In Version: | lorax-17.14-1.fc17 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-04-18 23:06:13 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: | |||
Bug Depends On: | |||
Bug Blocks: | 752650, 752652 |
Description
Chris Murphy
2012-03-19 18:39:31 UTC
If the tools aren't available, the filesystem will be marked as unavailable. Proposed blocker, based on Final release criterion 8. "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above." And discussion here: http://lists.fedoraproject.org/pipermail/devel/2012-March/164242.html Yes, please fix this for Fedora, I don't have a formal blocker vote, but this really should work. Lots of people use Fedora just for the good XFS support. https://www.redhat.com/archives/anaconda-devel-list/2012-March/msg00171.html is the anaconda-devel-list discussion on fixing this. there seems to be a question about whether the files will soon move again... proposing as Beta NTH and Final blocker, just so we can discuss at the appropriate meetings. anaconda team, if you feel like sneaking a fix for this into RC2 (assuming we have one), I don't think anyone would hate that. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Eric, I tried to contact you on irc... Why are there some files still in /sbin and not in /usr/sbin ? I'm unaware of a requirement to move files out of /sbin. Can you fill me in? Thanks, -Eric Thanks Brian, I have seen that, but I don't see anything in it which specifies that all packages must be respun to remove files from /sbin. Indeed, a quick check of rawhide RPMs shows around 500 files still in /sbin from the package set, if I did it right. Ok, I guess the packaging guidelines were updated to specify the change, even though the feature page didn't explicitly say it (that I saw, anyway). sorry for the noise. Thanks, -Eric Discussed at 2012-03-30 NTH review meeting. Accepted as NTH as this is a missing installer feature (can't be fixed with an update) and the fix is pretty safe (just make sure some files don't get nuked during installer compose). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Still appears to be broken as of Beta RC3. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Still broken in Beta RC4. I see the F18 build of xfsprogs has the binaries moved to /usr, but the F17 build does not. I don't see a point reverting the changes in the compose tools, and then changing them again in the next release. The files should be moved in F17 too. That's fine, I wasn't aware that the compose tools for f17 was looking for binaries in the new place. I can easily change xfsprogs if that's the problem. BTW where does it look for e2fsprogs binaries? I've also changed that to /usr/* in rawhide... ... and other fileystems? Seems like this needs some coordination (or the compose tools should look in both places for a while to avoid breakage?) Thanks, -Eric I looked at jfsutils, btrfs-utils, e2fsprogs, dosfstools, and xfsprogs. None of these have done the /usr move for f17, and /sbin is still referenced in the template for btrfs-progs, dosfstools, and jfsutils. xfsprogs seems to be the only one adversely affected right now since it's using the --allbut directive, and assuming things have moved. I am wary of respinning xfsprogs this late in the game, just for this reason. I think I reached agreement with wwoods to fix the regexp line for xfsprogs in f17 lorax, and we can try to coordinate this better in F18 - that seems like the least invasive, least risky approach at this stage. If this isn't acceptable please let me know, but it seems like the safest most consistent solution for now. Thanks, -Eric So it will, or will not be fixed for F17 Final? I think it should be fixed by F17 final by changing the regexps in the compose scripts to find the xfsprogs binaries where they are today. If the lorax folks disagree, I will change xfsprogs to match them - under slight duress ;) -Eric Eric, I didn't know you agreed with Will on something. lorax-17.14-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/lorax-17.14-1.fc17 Martin, just for the record (and this was after you had assigned this back to me, just FYI): <sandeen> so, wwoods - for f17 we have at least 4 fs utility packages (btrfs, gfs2, xfs, extN), none of which have moved binaries in f17. The template above seems to assume some have, some haven't. We should probably be consistent one way or another, and I'm game to do whatever. <sandeen> but what is the path forward for f17. Respin those 4 packages post-beta, or change the regexps in lorax? <sandeen> if it's the former we'll need to coordinate with the other 2 maintainers involved ... <sandeen> dosfsutils & jfsutils also reference /sbin in the template, FWIW. <sandeen> I'd really rather admit that none of these packages changed locations and admit "defeat" for f17, and make lorax reflect these packages' reality <sandeen> then do a coordinated fixing effort for f18, with dependent bugs so we can actually get it all right <wwoods> fair 'nuff Thanks, -Eric Package lorax-17.14-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing lorax-17.14-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-5697/lorax-17.14-1.fc17 then log in and leave karma (feedback). lorax-17.14-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. |