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):
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.
Created attachment 99284 [details]
Workaround for booty-0.34 so that you can have a /boot (or / if no /boot) XFS partition.
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.
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.
*** Bug 122018 has been marked as a duplicate of this bug. ***
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
FC2test3 works fine for me as long as /boot is not XFS.
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.
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
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
But, committed something that will work better (the attached patch
won't work if /boot is a separate filesystem) for booty-0.36-1
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?
No, I put a workaround in.
*** Bug 121748 has been marked as a duplicate of this bug. ***
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
Good work, this should solve it. I'll build a test-disk and verify it
as extensively as I did with my patch.