Bug 117968
Summary: | installer hangs when using XFS filesystem and grub | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Lonni J Friedman <netllama> | ||||
Component: | anaconda | Assignee: | Jeremy Katz <katzj> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | barryn, dennis, florin, leonard-rh-bugzilla, stesmi | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | triage|leonardjo|patch|easyfix | ||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2004-04-30 13:12:08 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: | 114963 | ||||||
Attachments: |
|
Description
Lonni J Friedman
2004-03-10 16:42:46 UTC
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 do so. 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 anyway? 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 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 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. |