Bug 804779 - XFS is not an available installation time file system
Summary: XFS is not an available installation time file system
Alias: None
Product: Fedora
Classification: Fedora
Component: lorax
Version: 17
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Martin Gracik
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedNTH
Depends On:
Blocks: F17Blocker, F17FinalBlocker F17Beta-accepted, F17BetaFreezeExcept
TreeView+ depends on / blocked
Reported: 2012-03-19 18:39 UTC by Chris Murphy
Modified: 2013-07-04 13:01 UTC (History)
11 users (show)

Clone Of:
Last Closed: 2012-04-18 23:06:13 UTC

Attachments (Terms of Use)

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):

How reproducible:

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:

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

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?


Comment 7 Brian Lane 2012-03-27 00:09:52 UTC

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.


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

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

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?)


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.


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 ;)


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.

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



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:
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.

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