Bug 804779

Summary: XFS is not an available installation time file system
Product: [Fedora] Fedora Reporter: Chris Murphy <bugzilla>
Component: loraxAssignee: Martin Gracik <mgracik>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: 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
Description of problem:
Cannot create any mountpoint as XFS filesystem with any installation type.

Version-Release number of selected component (if applicable):
Fedora-17-Beta-TC2-x86_64-DVD.iso


How reproducible:
100%

Steps to Reproduce:
1. Installation type = Use All Space
2. Check Review and modify partitioning layout
3. Edit lv-root or lv-home and try to change from ext4 to XFS
  
Actual results:
XFS is not listed.

Expected results:
XFS should be listed.

Additional info:
/sbin/mkfs.xfs is not present.
/sbin/xfs_admin is present.
xfs.ko is present.

Comment 1 Chris Lumens 2012-03-19 18:45:31 UTC
If the tools aren't available, the filesystem will be marked as unavailable.

Comment 2 Chris Murphy 2012-03-20 18:17:19 UTC
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

Comment 3 Eric Sandeen 2012-03-23 15:48:08 UTC
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.

Comment 4 Adam Williamson 2012-03-24 05:29:42 UTC
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

Comment 5 Martin Gracik 2012-03-26 04:57:55 UTC
Eric, I tried to contact you on irc... Why are there some files still in /sbin and not in /usr/sbin ?

Comment 6 Eric Sandeen 2012-03-26 16:59:00 UTC
I'm unaware of a requirement to move files out of /sbin.  Can you fill me in?

Thanks,
-Eric

Comment 7 Brian Lane 2012-03-27 00:09:52 UTC
https://fedoraproject.org/wiki/Features/UsrMove

Comment 8 Eric Sandeen 2012-03-27 16:08:13 UTC
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.

Comment 9 Eric Sandeen 2012-03-27 16:31:07 UTC
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

Comment 10 Adam Williamson 2012-03-30 19:30:24 UTC
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

Comment 11 Adam Williamson 2012-04-04 19:45:36 UTC
Still appears to be broken as of Beta RC3.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 12 Chris Murphy 2012-04-10 07:40:31 UTC
Still broken in Beta RC4.

Comment 13 Martin Gracik 2012-04-10 11:53:30 UTC
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.

Comment 14 Eric Sandeen 2012-04-10 15:25:30 UTC
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

Comment 15 Eric Sandeen 2012-04-10 17:16:32 UTC
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

Comment 16 Chris Murphy 2012-04-10 18:39:18 UTC
So it will, or will not be fixed for F17 Final?

Comment 17 Eric Sandeen 2012-04-10 18:56:54 UTC
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

Comment 18 Martin Gracik 2012-04-11 06:42:33 UTC
Eric, I didn't know you agreed with Will on something.

Comment 19 Fedora Update System 2012-04-11 14:20:25 UTC
lorax-17.14-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/lorax-17.14-1.fc17

Comment 20 Eric Sandeen 2012-04-11 14:47:04 UTC
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

Comment 21 Fedora Update System 2012-04-12 01:08:29 UTC
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).

Comment 22 Fedora Update System 2012-04-18 23:06:13 UTC
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.