Bug 122603

I was just about to file my own bug regarding this. I'll copy and
paste (since mine was more detailed):

Description of problem:
If I install with the "jfs" option, then anaconda is unable to format
JFS partitions and the install aborts.

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

How reproducible:
Always

Steps to Reproduce:
1. Boot installer with "jfs" option.
2. In Disk Druid, format a partition ("/" in my testing) with JFS.
3. Attempt to finish the install as normal.
    

Actual Results:  When it attempts to format the partition, I get this
dialog box:

"                      Error

An error occurred trying to format hda2.  This problem is
serious, and the install cannot continue.

Press <Enter> to reboot your system.

                                          [   OK   ]"


Expected Results:  Install proceeds uneventfully.

Additional info:

On Alt-F3 console, the last line is:
* formatting / as jfs

On Alt-F4 console, there's nothing unusual.

On Alt-F5 console, there's this:
mkfs.jfs version 1.1.4, 30-Oct-2003
The specified disk did not finish formatting.

same happens here.. Tried to install in jfs and didnt work.. Then
installed in ext3 and even after updating all packages , mkfs.jfs
didnt work. It dies with the same output as mentioned in comment #1
(mkfs.jfs version 1.1.4, 30-Oct-2003
The specified disk did not finish formatting.)

A workaround is to run mkfs.jfs in another distribution (e.g. Knoppix)
to format the partition, then install onto the partition without
reformatting. 

(This then revealed another bug, but that's a different bug and I need
to file it separately when I get a chance.)

*** Bug 123838 has been marked as a duplicate of this bug. ***

The bug is still happening in FC2 final:

[root@tirael root]# mkfs.jfs /dev/hdb1
mkfs.jfs version 1.1.4, 30-Oct-2003
Warning!  All data on device /dev/hdb1 will be lost!

Continue? (Y/N) y
The specified disk did not finish formatting.
[root@tirael root]# rpm -qa |grep jfsutils
jfsutils-1.1.4-1
[root@tirael root]# 

Did some extra tests here to find the cause. 
Compiling jfs_utils from source (obtained from the JFS project web
site) , I can format the partition. Both 1.1.4 and 1.1.6 work.

With the version 1.1.4-1 of the jfsutils package (from the core 2
cds), I still get the error . Tried rebuilding the package from the
src.rpm package , but error still happens.

Compiling with the same compiler flags used when building the rpm
package (-O2 -g -march=i386 -mcpu=i686) it breakes. 

After a few tries , I've found out that removing the -mcpu=i686 flag
builds a working jfs_mkfs (the compiler flags used by the package were
-O2 -g -march=i386 -mcpu=i686). Using only -O2 -g -march=i386 works
perfectly.

This also happens to me on Fedora Core 2.

*** Bug 127014 has been marked as a duplicate of this bug. ***

If the problem is in the flags, maybe this should be reported upstream.

Upstream to who? We need to figure out whether jfsutils or gcc is to
blame. And if gcc is to blame, it needs to be distilled to a smaller
testcase if possible.

(I'll see if I can take a closer look at this later today.)

AFAICT (so far) it's a bug in Red Hat's version of gcc 3.3.x. It
doesn't happen with upstream gcc 3.3.3 or 3.3.4, nor with Red Hat's
gcc-3.4.1 or gcc35 packages. (This means there's nothing to report to
upstream) I'm going to keep looking at this and see if I can figure
anything else out...

jfsutils-1.1.6 in rawhide does not have this problem (I guess it's
compiled with gcc 3.4.x).

Never mind, I'm not convinced anymore that it's a gcc bug. I'll have
more information soon (probably later this weekend, but that's not a
100% guarantee) on what's causing this bug, and maybe other people
will be able to figure the whole thing out from there.

I can confirm that the problem is the -mcpu=i686 flag as I have
rebuilt the current srpm from rawhide (jfsutils-1.1.6-1.src.rpm) that
builds by default (at least on the Pentium M laptop I am testing on)
with the following flags "-O2 -g -march=i386 -mcpu=i686" (made up from
${RPM_OPT_FLAGS}) if I edit the .spec and hard set the flags too "-O2
-g -march=i386" then mkfs.jfs works fine

Futher to this it the AMD64 version of the jfsutils rpm works
perfectly so it appears very strongly to be a compile flag problems

It's not a compile flag problem, it's either a compiler problem or a
problem in the JFS code (yes, I know I said I'd post an explanation,
and I didn't get a chance yet but I'm hoping to have a little time
later this weekend).

The gcc release in Fedora Core development fixes this problem even
with -mcpu=i686 (or -mtune=i686).

Can someone confirm this is fixed with -1.1.7 plus current gcc
and fc3 development?

I just installed FC3T3 on a jfs partition (formatted by anaconda) and
the install went fine... booting afterwards didnt succeed.... but
that's a issue for other bug report... 

[This is a mass update sent to many bugs that missed earlier such messages due
to having their version set to a test version.]

This bug was originally filed against a version of Fedora Core which is no
longer supported, even for security updates.  Many changes have occured since
then.  Please retest this bug against a still supported version.  Note that FC3
and FC4 are supported by Fedora Legacy for security fixes only.  If
it still occurs on FC5 or FC6, please assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

This bug will be closed after a few weeks if no information is given indicating
that the bug is still present in a supported release.

Closing per lack of response to previous request for information.
This bug was originally filed against a much earlier version of Fedora
Core, and significant changes have taken place since the last version
for which this bug is confirmed.

Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.