This is not a bug but intentional.
See fate #110218 comment #18 for explanation

"You are not authorized to access bug #110218"
Can you give us a short summary of the explanation?

The number 110218 belongs to our feature tracking system (called fate) not to 
our bugzilla.

It should be offered for SUSE Linux.

Since we use the same code for SLES and SL this is not possible.
Coordinate with Ralf what you want.

At the stage where this initialisation is done, no control file has any 
influence. If you want different behavior for SLES and SL, this is a new 
feature and would require considerable changes wich I certainly do not have the
time to do. There is no problem with enabling XFS again, but of course then it 
is anable for both SLES and SL. I suggest the PM coordinate their requirement a
little better. I assume you as PM should know that we use the same code base 
for SLES and SL.

Talk to Ralf if he is fine with enabling XFS again and I can easily do it.
If you two have agreed on a setting for XFS reassigne the bug back to me.

My €0.02.

The one you know:
XFS is absent from the partitioning menu in YAST (10.0.42-BETA1). This is politically incorrect IMO, given that it was once offered.

The one you don't know:
Furthermore, if I do not format a previously (xfs-)formatted partition, yast tries to mount it as reiserfs even though I'm sure it could just load the kernel module for xfs.

  "Error
  failure occurred during following action:
  Mounting /dev/sda2 to /

  System error code was: -3003

  mount -t reiserfs /dev/sda2 /mnt:
  (reason)"

Not good++.

I stumbled across this bug because I wanted to upgrade 10.1 alpha4 to 10.1 beta1.
The root partition had a XFS file system.
I booted from CD, selected the upgrade, resolved all dependencies (at this stage the system was able to read the XFS partitions) and then started the upgrade. After installing the first CD the system reboots. But after the reboot the system did start up any more. It looked like grub was not able to read the xfs partition. 
I did not spent too much time on it and reinstalled the system with a reiser root.
So it looks like the upgrade of a XFS root file system is broken too.

Is this upgrade problem related to the decision not to support XFS on boot? 
Should I open different bug on the update problem? 

Are you serious in not supporting XFS anymore? That would be an absolute showstopper for us. We had already enough data losses with the "reisswolf-fs" and ext3 is so slow that we lost data on our feeds because we couldn't write it fast enough to disk. Without XFS I can't even test beta2 so please reenable it for beta3.

We should fix Bug 145204 first.

Ok, let's enable XFS with SUSE Linux 10.1 Beta4 again.

I enabled it again.

Ad comment #8 this should of course not happen.
Please attach y2log files.

In reply to comment #8:
> XFS is absent from the partitioning menu in YAST (10.0.42-BETA1). This is
> politically incorrect IMO, given that it was once offered.

There is nothing "politically incorrect" about only shipping and supporting
stuff which we feel we can support properly.

If there was a warning that xfs is not supported anymore, that would have been correct. Ok, let's forget it, it was a beta anyhow.

Reply to comment #8:
1-> The bug is only triggered when the user chooses "Base partition setup on this proposol", setting the appropriate mountpoints for the partitions and removing the Format marks. The Installation Overview says
  "Delete partition /dev/sda1"
  "Delete partition /dev/sda2"
  "Create partition /dev/sda1"
  "Create root partition /dev/sda2 with unknown"

2-> Choosing "Create custom partition setup" instead (and, logically, setting mountpoints) goes fine - the ptable is not touched at all as it seems.

Back to 1: This time I get:
  mount -t auto /dev/sda2 /mnt:
  mount: unknown filesystem type 'xfs'
(rather than mount -t reiserfs) - still BETA1.

Plus: Running "guessfstype /dev/sda2" returns no filesystem, therefore I am inclined to believe that the partitioning screws the harddisk's content rather than just modifying the partition table (as it should).

Created attachment 66034 [details]
-

Ok, I see. libstorage did not scan the content of a newly created partition
for a possible fs signature. Without knowledge about fs type it does not know
it needs to load xfs modules, therefore mount fails. This will be fixed in 
beta#4. I never thought about the possibility to not formatting a newly
created partition, therefore this problem.

My tests did not show any clobbering of harddisks content, also parted displays
that newly created partition sda2 still has fs type xfs. 

So please retest you scenario 1 in comment #16 with beta#4.
I could reproduce your scenario here and it work after my fix in libstorage.
The problem is in fact not only with xfs, every other fs which module is not 
loaded by chance would give the same result.

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

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

Thomas, I need to revert your fix for that. It breaks partitioning in some cases.
For example, if you have an old installation where hda1 was reiserfs and now you do a new partitioning where hda1 is the swap partition, then the swap partition will be formated and mounted with reiserfs to mountpoint "swap".

Unfortunately I don't know how to fix that in a clean way but we can't keep it like it is. I'll put a big FIXME in the code so you'll see what I did.

to be more precise, I just reverted the fix for #16, not for #1
XFS is still there and can be used in the propsal dialog.

This should be finally fixed in next release (either beta9 or RC1).