RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 696876 - multipath: Anaconda does not recognize 'mpatha' in the ignoredisk kickstart command
Summary: multipath: Anaconda does not recognize 'mpatha' in the ignoredisk kickstart c...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.1
Hardware: x86_64
OS: All
medium
high
Target Milestone: rc
: ---
Assignee: Ales Kozumplik
QA Contact: Gris Ge
URL:
Whiteboard:
: 675322 712360 728137 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-15 05:50 UTC by IBM Bug Proxy
Modified: 2018-11-26 19:29 UTC (History)
18 users (show)

Fixed In Version: anaconda-13.21.119-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 10:32:22 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Anaconda Log for san boot using /dev/mapper/mpatha (6.78 KB, application/octet-stream)
2011-04-15 05:51 UTC, IBM Bug Proxy 		no flags Details
Anaconda log from may 11 (7.14 KB, application/octet-stream)
2011-05-11 16:30 UTC, IBM Bug Proxy 		no flags Details
kickstart file from may 11 (2.06 KB, application/octet-stream)
2011-05-11 16:30 UTC, IBM Bug Proxy 		no flags Details
Kickstart files and console outputs (7.32 KB, application/x-compressed-tar)
2011-07-06 14:10 UTC, IBM Bug Proxy 		no flags Details
Kickstart files and console outputs - RHEL6.1 Alpha (5.77 KB, application/x-compressed-tar)
2011-07-06 14:10 UTC, IBM Bug Proxy 		no flags Details
Error message (1.40 KB, application/octet-stream)
2011-07-06 14:10 UTC, IBM Bug Proxy 		no flags Details
Kickstart file (1.30 KB, text/plain)
2011-10-03 18:40 UTC, IBM Bug Proxy 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 71296 0 None None None 2019-05-02 15:22:28 UTC
Red Hat Knowledge Base (Legacy) 45051 0 None None None Never
Red Hat Product Errata RHBA-2011:1565 0 normal SHIPPED_LIVE anaconda bug fix and enhancement update 2011-12-06 00:39:12 UTC

Description IBM Bug Proxy 2011-04-15 05:50:54 UTC 
---Problem Description---
Install via kickstart file fails to install on multipath device

---uname output---
Linux iopx3550hgcf0.storage.tucson.ibm.com 2.6.32-125.el6.x86_64 #1 SMP Mon Mar
21 10:06:08 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

Machine Type = x3550 

---Steps to Reproduce---
 pxe boot multipath'd san boot server under test to network install from from a
kickstart file specifying a mapper/<device> and the install will fail to find
the device

****************
pxeboot command line

default install
label install
kernel rhel6u1.x86_64.krn
append x86_serial_nr=1 maxcpus=64 console=tty0 load_ramdisk=1
initrd=rhel6u1.x86_64.initrd netwait=90 ksdevice=eth0 ip=9.11.217.14
netmask=255.255.254.0 gateway=9.11.216.1
ks=nfs:9.11.216.112:/OS_IMAGE/Auto-Install/configurations/iopx3550hgcf0.storage.tucson.ibm.com.cfg
mpath

*****************
kickstart stanza:
ignoredisk --only-use=mapper/mpathb
clearpart --all --drives=mapper/mpathb
part swap --size=4096 --asprimary --ondisk=mapper/mpathb
part / --fstype ext3 --grow --size=100 --asprimary  --ondisk=mapper/mpathb

produces the error
Specified nonexistent disk mapper/mpathb in ignoredisk command

ls of /dev/mapper indicates only the control file is present.

******************
changing the kickstart formating stanza to use /dev/disk/by-id/scsi-<id>
as follows

ignoredisk --only-use=disk/by-id/scsi-3600a0b80001115960000afef4cc96c4b
clearpart --all --drives=disk/by-id/scsi-3600a0b80001115960000afef4cc96c4b
part swap --size=4096 --asprimary
--ondisk=disk/by-id/scsi-3600a0b80001115960000afef4cc96c4b
part / --fstype ext3 --grow --size=100 --asprimary 
--ondisk=disk/by-id/scsi-3600a0b80001115960000afef4cc96c4b

generates error "Specified unpartitioned disk
disk/by-id/scsi-3600a0b80001115960000afef4cc96c4b in partion command"

even though ls /dev/disk/by-id confirms existence of scsi device

additionally ls /dev/mapper shows multipath'd devices which
will not present in the previous scenario 

Probable cause:
first, when anaconda evaluates the kickstart file, using the mpathb device
that while the multipath module is loading, the mappings seem to 
have not been created, and so it fails to find the device.
in the second case it seems that it wont format the by-id device because
it's part of a multipath'd device.(though, this error occurs even when
I do not use the mpath option)


=================================================


1. Server architecture(s) (please list all effected) (x86/POWER6/Z/etc.): x86-64
2. Server type (9117-MMA/HS20/s390/etc.): IBM HS22 Blade Server
3. General component (desktop/kernel/base OS/dev tools/etc.): Anaconda
4. Other components involved (ixgbe/java/emulex/etc.): NA
5. Does the server have the latest GA firmware? Yes
6. What is the latest official distro build on which this bug has been seen? RHEL 6.1
Comment 1 IBM Bug Proxy 2011-04-15 05:51:00 UTC 
Created attachment 492284 [details]
Anaconda Log  for san boot using /dev/mapper/mpatha
Comment 5 Joe Lawrence 2011-04-20 18:17:54 UTC 
Stratus also hit this problem and it is blocking our ability to install RHEL6 for boot from SAN.  This is a regression of functionality that was available in RHEL5.

We found we could work around this by creating /etc/multipath.conf and starting multipath in the kickstart %pre step.
Comment 6 IBM Bug Proxy 2011-05-11 07:40:40 UTC 
------- Comment From ranittal.ibm.com 2011-05-11 03:38 EDT-------
Hi Redhat,

This defect is still present in rc2, what is the chances this will be fixed for ga?

Thanks,
Ravi
Comment 7 Ales Kozumplik 2011-05-11 07:48:13 UTC 
(In reply to comment #6)
> ------- Comment From ranittal.ibm.com 2011-05-11 03:38 EDT-------
> Hi Redhat,
> 
> This defect is still present in rc2, what is the chances this will be fixed for
> ga?
> 
> Thanks,
> Ravi

Hello,

this is not scheduled for 6.1 GA.

Ales Kozumplik
Comment 8 IBM Bug Proxy 2011-05-11 16:30:30 UTC 
------- Comment From jkenefic.com 2011-05-11 12:21 EDT-------
> Stratus also hit this problem and it is blocking our ability to install RHEL6
> for boot from SAN.  This is a regression of functionality that was available in
> RHEL5.
> We found we could work around this by creating /etc/multipath.conf and starting
> multipath in the kickstart %pre step.

I've attempted this workaround, and while I am able to see the multipath device from tty2, the installer is reporting "no usable disks found" this is going to make kickstart installation on san boot unworkable

I will attach the anaconda log and kickstart file
Comment 9 IBM Bug Proxy 2011-05-11 16:30:35 UTC 
Created attachment 498333 [details]
Anaconda log from may 11


------- Comment (attachment only) From jkenefic.com 2011-05-11 12:27 EDT-------
Comment 10 IBM Bug Proxy 2011-05-11 16:30:39 UTC 
Created attachment 498334 [details]
kickstart file from may 11


------- Comment (attachment only) From jkenefic.com 2011-05-11 12:28 EDT-------
Comment 11 Joe Lawrence 2011-05-16 15:38:22 UTC 
I tried a modified kickstart partitioning scheme like the one found in attachment from IBM and got the same "no usable disks found" error.  Changing the "ignoredisk" line from  "--only-use" to "--drives=mapper/mpathx,..." moved the installer past the error message and the install continued.
Comment 12 Ales Kozumplik 2011-06-07 10:31:35 UTC 
> changing the kickstart formating stanza to use /dev/disk/by-id/scsi-<id>
> as follows
> 
> ignoredisk --only-use=disk/by-id/scsi-3600a0b80001115960000afef4cc96c4b
> clearpart --all --drives=disk/by-id/scsi-3600a0b80001115960000afef4cc96c4b
> part swap --size=4096 --asprimary
> --ondisk=disk/by-id/scsi-3600a0b80001115960000afef4cc96c4b
> part / --fstype ext3 --grow --size=100 --asprimary 
> --ondisk=disk/by-id/scsi-3600a0b80001115960000afef4cc96c4b

This particular kickstart notation doesn't work with multipath because /dev/disk/by-id/scsi-3600a0b80001115960000afef4cc96c4b in fact points to an arbitrary mpath member with the given id, so it equals to writing e.g.

ignoredisk --only-use=sda

where sda is an mpath member. 

Nonetheless, your request to be able to identify mpaths by their ids is valid and will be dealt with in the bug 677263.

In this bug I will try to make anaconda recognize the "mapper/mpath<x>" notation.
Comment 13 Ales Kozumplik 2011-06-07 11:10:08 UTC 
Patch is waiting for a review: https://www.redhat.com/archives/anaconda-devel-list/2011-June/msg00051.html
Comment 14 John Ruemker 2011-06-07 13:58:47 UTC 
*** Bug 675322 has been marked as a duplicate of this bug. ***
Comment 15 John Ruemker 2011-06-07 18:53:22 UTC 
I just tested the patch from

   https://www.redhat.com/archives/anaconda-devel-list/2011-June/msg00056.html

Using this partitioning section:

ignoredisk --drives=sda,sdc,sde,sdg,sdi
bootloader --location=mbr --append=crashkernel=auto rhgb quiet
clearpart --all --drives=mpatha,sdb,sdd,sdf,sdh
part /boot --fstype ext4 --size=100 --ondisk=mapper/mpatha
part pv.10 --size=1 --grow --ondisk=mapper/mpatha
volgroup jrummy pv.10
logvol swap --fstype swap --name=LogVol01 --vgname=jrummy --size=100
logvol / --fstype ext4 --name=LogVol00 --vgname=jrummy --size=1 --grow

With the above, it works.  However, notice that I use mpatha in clearpart and mapper/mpatha in part.  This is the only way it would work for me.  With mapper/mpatha in clearpart, it fails with 'Specified nonexistent disk mapper/mpatha in clearpart command'. With mpatha in the part command, it fails with 'Specified nonexistent disk mpatha in partition command'.  

Let me know if I can help with further testing, or you need access to my test environment

-John
Comment 16 Ales Kozumplik 2011-06-08 09:05:55 UTC 
(In reply to comment #15)
> With the above, it works.  However, notice that I use mpatha in clearpart and
> mapper/mpatha in part.  This is the only way it would work for me.  With
> mapper/mpatha in clearpart, it fails with 'Specified nonexistent disk
> mapper/mpatha in clearpart command'. With mpatha in the part command, it fails
> with 'Specified nonexistent disk mpatha in partition command'.  
> 
> Let me know if I can help with further testing, or you need access to my test
> environment
> 

Very strange. I have this passing allright:

clearpart --all --drives=mpatha,mpathb
ignoredisk --only-use=mpatha,mpathb
part prepboot --fstype=prepboot --asprimary --size=4 --ondisk=mpathb
part swap --asprimary --size=4096 --ondisk=mpatha
part / --fstype=ext3 --grow --asprimary --size=100 --ondisk=mpathb


One thing is clear, we should stick to one naming convention in all commands and that should be without 'mapper/' (because that's how anaconda memorizes device names internally). 

Still, I don't see how your error can happen, so I'd like to take a look. Can you please append updates=http://cobra02.englab.brq.redhat.com/ks/ak/updates/updates.img to the bootline and give me access to the machine?

Ales
Comment 18 Ales Kozumplik 2011-06-13 06:56:20 UTC 
*** Bug 712360 has been marked as a duplicate of this bug. ***
Comment 26 Ales Kozumplik 2011-06-17 08:10:58 UTC 
Fixed on the rhel6 branch by commit 01697c1e13550f44eab2333704df9ca7c51b52dd.
Comment 29 IBM Bug Proxy 2011-07-06 14:10:41 UTC 
Created attachment 511504 [details]
Kickstart files and console outputs
Comment 30 IBM Bug Proxy 2011-07-06 14:10:47 UTC 
Created attachment 511505 [details]
Kickstart files and console outputs - RHEL6.1 Alpha
Comment 31 IBM Bug Proxy 2011-07-06 14:10:53 UTC 
Created attachment 511506 [details]
Error message
Comment 34 Ales Kozumplik 2011-08-04 14:08:38 UTC 
*** Bug 728137 has been marked as a duplicate of this bug. ***
Comment 36 Gris Ge 2011-08-15 02:19:24 UTC 
Ales,

It seems we still have something more to fix.

Repo: RHEL6.2-20110814.n.0
Beaker job: https://beaker.engineering.redhat.com/jobs/119783
(You can check log in this page.)

storageqe-05.rhts.eng.bos.redhat.com have 2 LUN via 4 paths each.
mpatha (20090ef1270000000) is the boot LUN.

Kickstart options: ignoredisk --only-use=mpatha

The problems are:

 0. In anaconda-ks.cfg, it show this line:
    ===
    #ignoredisk --only-use=mpatha,sda,sdc,sde,sdg
    ===
    It should not contain sdX which is the member of mpatha.

 1. OS boot into recovery mode after installation. Reason: Incorrect /etc/fstab for /boot partition.
    It got this line in /etc/fstab:
    ===
    UUID=7598c6b0-d93e-44d1-92dc-81a8291013e4 /boot ext4 defaults 1 2
    ===
    UUID is pointing to /dev/sdc1 which is incorrect. It should point to /dev/mapper/mpathap1
    I cannot find /dev/mapper/mpathap1 in /dev/disk/by-uuid/, check this output:
    ===
    (Repair filesystem) 29 # ls -l /dev/disk/by-uuid/
    total 0
    lrwxrwxrwx. 1 root root 10 Aug 14 21:50 7598c6b0-d93e-44d1-92dc-81a8291013e4 -> ../../sdc1
    lrwxrwxrwx. 1 root root 10 Aug 14 21:50 c8811b1b-a01f-4efe-ad07-98dcb95ed7f3 -> ../../dm-3
    lrwxrwxrwx. 1 root root 10 Aug 14 21:50 e2d5d8b2-9325-433d-803c-31c855a8cd5a -> ../../dm-4
    (Repair filesystem) 30 # ls -l /dev/mapper/
    total 0
    lrwxrwxrwx. 1 root root      7 Aug 14 21:50 20090ef1270000000 -> ../dm-0
    lrwxrwxrwx. 1 root root      7 Aug 14 21:50 20090ef1270000000p1 -> ../dm-1
    lrwxrwxrwx. 1 root root      7 Aug 14 21:50 20090ef1270000000p2 -> ../dm-2
    crw-rw----. 1 root root 10, 58 Aug 14 17:50 control
    lrwxrwxrwx. 1 root root      7 Aug 14 21:50 vg_storageqe05-lv_root -> ../dm-3
    lrwxrwxrwx. 1 root root      7 Aug 14 21:50 vg_storageqe05-lv_swap -> ../dm-4
    ===
    As multipath is using O_EXCL which take /dev/sdc exclusively, OS cannot mount /dev/sdc1 as /boot, hence it goes intto recovery mode.

 2. multipath doesn't create '/etc/multipath/wwids' during installation.
    This will cause OS don't have /dev/mapper/mpatha, instead of that we got /dev/mapper/20090ef1270000000
    By default, anaconda should set "user_friendly_names yes" in /etc/multipath.conf.
    OS got correct option in /etc/multipath.conf after installation.

You can got detailed information in http://lab2.rhts.eng.bos.redhat.com/beaker/logs/recipes/246492//console.log
That's how I debug these things above.
Comment 37 Gris Ge 2011-08-15 02:19:47 UTC 
Ales,

It seems we still have something more to fix.

Repo: RHEL6.2-20110814.n.0
Beaker job: https://beaker.engineering.redhat.com/jobs/119783
(You can check log in this page.)

storageqe-05.rhts.eng.bos.redhat.com have 2 LUN via 4 paths each.
mpatha (20090ef1270000000) is the boot LUN.

Kickstart options: ignoredisk --only-use=mpatha

The problems are:

 0. In anaconda-ks.cfg, it show this line:
    ===
    #ignoredisk --only-use=mpatha,sda,sdc,sde,sdg
    ===
    It should not contain sdX which is the member of mpatha.

 1. OS boot into recovery mode after installation. Reason: Incorrect /etc/fstab for /boot partition.
    It got this line in /etc/fstab:
    ===
    UUID=7598c6b0-d93e-44d1-92dc-81a8291013e4 /boot ext4 defaults 1 2
    ===
    UUID is pointing to /dev/sdc1 which is incorrect. It should point to /dev/mapper/mpathap1
    I cannot find /dev/mapper/mpathap1 in /dev/disk/by-uuid/, check this output:
    ===
    (Repair filesystem) 29 # ls -l /dev/disk/by-uuid/
    total 0
    lrwxrwxrwx. 1 root root 10 Aug 14 21:50 7598c6b0-d93e-44d1-92dc-81a8291013e4 -> ../../sdc1
    lrwxrwxrwx. 1 root root 10 Aug 14 21:50 c8811b1b-a01f-4efe-ad07-98dcb95ed7f3 -> ../../dm-3
    lrwxrwxrwx. 1 root root 10 Aug 14 21:50 e2d5d8b2-9325-433d-803c-31c855a8cd5a -> ../../dm-4
    (Repair filesystem) 30 # ls -l /dev/mapper/
    total 0
    lrwxrwxrwx. 1 root root      7 Aug 14 21:50 20090ef1270000000 -> ../dm-0
    lrwxrwxrwx. 1 root root      7 Aug 14 21:50 20090ef1270000000p1 -> ../dm-1
    lrwxrwxrwx. 1 root root      7 Aug 14 21:50 20090ef1270000000p2 -> ../dm-2
    crw-rw----. 1 root root 10, 58 Aug 14 17:50 control
    lrwxrwxrwx. 1 root root      7 Aug 14 21:50 vg_storageqe05-lv_root -> ../dm-3
    lrwxrwxrwx. 1 root root      7 Aug 14 21:50 vg_storageqe05-lv_swap -> ../dm-4
    ===
    As multipath is using O_EXCL which take /dev/sdc exclusively, OS cannot mount /dev/sdc1 as /boot, hence it goes intto recovery mode.

 2. multipath doesn't create '/etc/multipath/wwids' during installation.
    This will cause OS don't have /dev/mapper/mpatha, instead of that we got /dev/mapper/20090ef1270000000
    By default, anaconda should set "user_friendly_names yes" in /etc/multipath.conf.
    OS got correct option in /etc/multipath.conf after installation.

You can got detailed information in http://lab2.rhts.eng.bos.redhat.com/beaker/logs/recipes/246492//console.log
That's how I debug these things above.
Comment 38 Gris Ge 2011-08-15 06:09:56 UTC 
Should be assigned rather new.
Comment 39 Ales Kozumplik 2011-08-15 08:18:04 UTC 
> The problems are:
> 
>  0. In anaconda-ks.cfg, it show this line:
>     ===
>     #ignoredisk --only-use=mpatha,sda,sdc,sde,sdg
>     ===
>     It should not contain sdX which is the member of mpatha.

Nope, there is no problem with explicitly naming all of the member paths to be used. It might not be necessary but it is not a bug and it is much easier to implement it this way.

>  1. OS boot into recovery mode after installation. Reason: Incorrect /etc/fstab
> for /boot partition.
>     It got this line in /etc/fstab:
>     ===
>     UUID=7598c6b0-d93e-44d1-92dc-81a8291013e4 /boot ext4 defaults 1 2
>     ===
>     UUID is pointing to /dev/sdc1 which is incorrect. It should point to
> /dev/mapper/mpathap1

As far as I know, a UUID is a property of a filesystem so it points to the filesystem on /dev/sdc1 as well as the (same) filesystem on /dev/mapper/mpathap1.

I am not sure why you are seeing the recovery mode but it can be related to the new issues there are with multipath installations, see bug 701371. If you don't use the new ignoredisk with multipaths syntax, does that happen too?
 
>  2. multipath doesn't create '/etc/multipath/wwids' during installation.
>     This will cause OS don't have /dev/mapper/mpatha, instead of that we got
> /dev/mapper/20090ef1270000000

Please bug 701371.
Comment 40 Ales Kozumplik 2011-08-16 14:38:02 UTC 
Moving to modified. I think we are only hitting other multipath problems here, especially bug 701371.
Comment 42 Gris Ge 2011-08-23 07:43:19 UTC 
works well with repo RHEL6.2-20110822.5

Beaker job: https://beaker.engineering.redhat.com/jobs/122949
Comment 43 IBM Bug Proxy 2011-10-03 18:40:54 UTC 
Created attachment 526110 [details]
Kickstart file


------- Comment (attachment only) From anibalca.ibm.com 2011-10-03 14:32 EDT-------
Comment 44 IBM Bug Proxy 2011-10-04 06:50:47 UTC 
------- Comment From ranittal.ibm.com 2011-10-04 02:46 EDT-------
Externalising the comment.

Tested on RHEL6.2 beta:

The following error was found while parsing the kickstart configuration file:
???                                                                  ???
??? The following problem occurred on line 21 of the kickstart file: ???
???                                                                  ???
??? Specified nonexistent disk mpathe in partition command

It seems it still doesn't work.
Comment 45 Joseph Kachuck 2011-10-07 13:31:34 UTC 
Hello IBM,
Please confirm the version you tested was anaconda-13.21.119-1 or above.

Thank You
Joe Kachuck
Comment 46 IBM Bug Proxy 2011-10-10 05:20:48 UTC 
------- Comment From vahegde1.ibm.com 2011-10-10 01:13 EDT-------
We have verified on RHEL6.1 Beta ( anaconda-13.21.140-1.el6)

Thanks
Vasant
Comment 47 IBM Bug Proxy 2011-10-11 12:31:04 UTC 
------- Comment From vahegde1.ibm.com 2011-10-11 08:27 EDT-------
(In reply to comment #31)
> We have verified on RHEL6.1 Beta ( anaconda-13.21.140-1.el6)

Sorry for the typo .. We have verified on RHEL6.2 Beta.
Comment 48 Timothy Noonan 2011-10-19 20:39:29 UTC 
(In reply to comment #47)
> ------- Comment From vahegde1.ibm.com 2011-10-11 08:27 EDT-------
> (In reply to comment #31)
> > We have verified on RHEL6.1 Beta ( anaconda-13.21.140-1.el6)
> Sorry for the typo .. We have verified on RHEL6.2 Beta.

Hi Red Hat, To be clear IBM has verified that the defect is still reproducing on the 6.2 beta at anaconda-13.21.140-1.el6
Comment 49 Ales Kozumplik 2011-10-20 08:07:39 UTC 
(In reply to comment #48)
> (In reply to comment #47)
> > ------- Comment From vahegde1.ibm.com 2011-10-11 08:27 EDT-------
> > (In reply to comment #31)
> > > We have verified on RHEL6.1 Beta ( anaconda-13.21.140-1.el6)
> > Sorry for the typo .. We have verified on RHEL6.2 Beta.
> 
> Hi Red Hat, To be clear IBM has verified that the defect is still reproducing
> on the 6.2 beta at anaconda-13.21.140-1.el6

If that's so please open a new bug, attaching the kickstart and all files from /tmp/*log.
Comment 50 errata-xmlrpc 2011-12-06 10:32:22 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1565.html
Note You need to log in before you can comment on or make changes to this bug.