Bug 117968 - installer hangs when using XFS filesystem and grub
Summary: installer hangs when using XFS filesystem and grub
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Whiteboard: triage|leonardjo|patch|easyfix
: 121748 122018 (view as bug list)
Depends On:
Blocks: FC2Target
TreeView+ depends on / blocked
Reported: 2004-03-10 16:42 UTC by Lonni J Friedman
Modified: 2007-11-30 22:10 UTC (History)
5 users (show)

Clone Of:
Last Closed: 2004-04-30 13:12:08 UTC

Attachments (Terms of Use)
Workaround for booty-0.34 so that you can have a /boot (or / if no /boot) XFS partition. (1.20 KB, patch)
2004-04-09 21:02 UTC, Stefan Smietanowski
no flags Details | Diff

Description Lonni J Friedman 2004-03-10 16:42:46 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

Description of problem:
Installation of FC2-test1 using XFS for all filesystems and grub as
the bootloader.  At the point where it is "Installing the bootloader"
the installer hangs.  It seems to want to access the bits on disk via
the filesystem and via the block device, almost at the same time. 
This often does not work, because things are not coherent between the two.

A workaround is found here:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install FC2-test1 specifying xfs as the filesystem for all partitions.
2.  Use Grub as the bootloader


Expected Results:  Bootloader should have cleanly installed, and the
installation should have proceeded normally.

Additional info:

Comment 1 Stefan Smietanowski 2004-04-09 21:02:52 UTC
Created attachment 99284 [details]
Workaround for booty-0.34 so that you can have a /boot (or / if no /boot) XFS partition.

Comment 2 Stefan Smietanowski 2004-04-09 21:06:55 UTC
This patch is against booty-0.34 from FC2-test2 and it is tested on
x86-64 but I guess it should work on both x86-64 and i386.

If your bootDev (ie "/boot" if you have one, "/" if you don't) is XFS,
it freezes and unfreezes it after grub --just-copy is run but before
the "real" grub line that installs it. Note that it is a GRUB bug and
not an XFS bug.

With this patch it works as it should.

The patch is above.

Comment 3 Leonard den Ottolander 2004-04-15 21:15:11 UTC
IIuc this is a kind of "sync" for XFS. The patch seems trivial enough
to me. Something like this might also be necessary for ReiserFS.

Comment 4 Jeremy Katz 2004-04-29 22:21:31 UTC
*** Bug 122018 has been marked as a duplicate of this bug. ***

Comment 5 Jeremy Katz 2004-04-29 22:26:32 UTC
And the fact that the kernel is broken enough that you "might" have to
do something different for each file system makes me very reluctant to
do so.

Comment 6 Florin Andrei 2004-04-29 22:30:16 UTC
FC2test3 works fine for me as long as /boot is not XFS.

Comment 7 Stefan Smietanowski 2004-04-29 22:38:17 UTC
But this is not a kernel bug, it's a userland bug. Fixing grub is the
way to go but this late I don't see it happening. A workaround for the
bug would be at least something that makes it work for the time being.
It's alot better than not being able to install an xfs-only system.

Comment 8 Florin Andrei 2004-04-29 22:47:10 UTC
Jeremy, people will format /boot (or / if /boot is not a separate
partition) with XFS, and then the installer _will_fail_.
This is not a cosmetic-only bug like #122017, this is a serious bug.
It, and #122043, will create serious issues for XFS users. If these
bugs are not fixed, what's the point of enabling XFS in the installer

Comment 9 Jeremy Katz 2004-04-30 05:15:01 UTC
Please look in fsset.py where the option is documented with
        # this is totally, 100% unsupported.  Boot with "linux xfs"
        # at the boot: prompt will let you make new xfs filesystems
        # in the installer.  Bugs filed when you use this will be closed
        # WONTFIX.

But, committed something that will work better (the attached patch
won't work if /boot is a separate filesystem) for booty-0.36-1

Comment 10 Lonni J Friedman 2004-04-30 13:01:39 UTC
I'm a bit confused by the current state of this bug.  It looks like
this is only half fixed.  If /boot is not XFS then life is good,  but
that's hardly a real world solution.  Most people use a single
filesystem for all partitions, and certainly wouldn't opt to make
/boot ext3 while everything else is preferably XFS.  

Did i misinerpret things, or is it still not possible to make _all_
linux partitions XFS at install time?

Comment 11 Jeremy Katz 2004-04-30 13:12:08 UTC
No, I put a workaround in.

Comment 12 Dennis Gilmore 2004-05-01 11:32:33 UTC
*** Bug 121748 has been marked as a duplicate of this bug. ***

Comment 13 Stefan Smietanowski 2004-05-03 19:39:01 UTC
The patch I attached before DOES indeed work.

I made an xfs_freeze -f /boot basically.

If /boot is a _dir_ on /, it would freeze "/".
If /boot is it's own filesystem it would freeze "/boot".

I verified all combinations, "/boot" XFS, "/" XFS, no "/boot"
partition, and all combinations of ext3 and XFS as would be possible
to produce and they all worked fine. It's due to the specifics of
xfs_freeze (freezes the partition the directory is on if you specify a
dir and not a device).

But the patch you included looks very nice as well, it's basically the
same thing as I did except that you call syncDataToDisk() differently
if /boot is it's own filesystem or not and of course you made a
syncDataToDisk() function.

Good work, this should solve it. I'll build a test-disk and verify it
as extensively as I did with my patch.

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