Bug 468944

Summary: anaconda fails to create logical volume. missing one pv problem.
Product: Red Hat Enterprise Linux 5 Reporter: Hideo AOKI <haoki>
Component: anacondaAssignee: Joel Andres Granados <jgranado>
Status: CLOSED ERRATA QA Contact: Alexander Todorov <atodorov>
Severity: high Docs Contact:
Priority: high    
Version: 5.3CC: atodorov, borgan, ddumas, jgranado, syeghiay, tyasui
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-20 21:34:45 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:
Attachments:
Description Flags
This picture is a part of lvm command log
none
anaconda.log
none
lvmout
none
syslog
none
the first sector of sda
none
script to create the partitions. none

Description Hideo AOKI 2008-10-29 02:08:45 UTC
Description of problem:
 If you install Red Hat Enterprise Linux 5.3 Partner Beta into the same
 partitioning layout changing a physical volume to LVM, anaconda fails
 to create the logical volume.
 
Version-Release number of selected component (if applicable): 
 anaconda-11.1.2.145-1
 lvm2-2.02.40-5.el5

How reproducible:
 Always.

Steps to Reproduce:
 1. Install RHEL 5.2 or RHEL 5.3 Partner Beta using physical volume 
    (ext3) for / file-system.
 2. Boot from install DVD.
 3. Choose "Install Red Hat Enterprise Linux Server".
 4. Choose "Create custom layout.".
 5. Edit the physical volume which was used as / file-system in 
    previous installation, select "format as LVM" and make / 
    file-system on the LVM volume.
 6. Start installation.

Actual results:
 An error window appears.

        --------------------------------
	LVM operation failed
        --------------------------------
	lvcreate failed for LogVol00

	The installer will now exit ...
  	--------------------------------

Expected results:
 anaconda can create logical volume.

Additional info:
 The machine is Intel server system SR9000MK4U. It is in Red Hat 
 Westford Lab.

 This bug doesn't occur on my x86 test machine.

Comment 1 Chris Lumens 2008-11-04 16:06:05 UTC
Please attach the complete exception report to this bug so we can track down what was going on.  Thanks.

Comment 2 Hideo AOKI 2008-11-06 00:46:40 UTC
In anaconda.log, only the following message is logged:
  ERROR  : createLogicalVolume failed with lvcreate failed for LogVol00

By the way, after failing the installation, I can create logical volumes by hand using command console,
although lvm command outputs this error message:
  /dev/hda: open failed: Read-only file system

Comment 3 Hideo AOKI 2008-11-06 01:04:39 UTC
Created attachment 322660 [details]
This picture is a part of lvm command log

Comment 4 Chris Lumens 2008-11-07 18:05:10 UTC
That doesn't really tell me very much about what could be going on.  We still could really use the complete /tmp/anaconda.log (and /tmp/lvmout if it exists too) so we can see what the real problem is.  Seeing /tmp/syslog might be helpful too.

Comment 5 Hideo AOKI 2008-11-08 02:47:31 UTC
Created attachment 322925 [details]
anaconda.log

Comment 6 Hideo AOKI 2008-11-08 02:47:56 UTC
Created attachment 322926 [details]
lvmout

Comment 7 Hideo AOKI 2008-11-08 02:48:17 UTC
Created attachment 322927 [details]
syslog

Comment 8 Hideo AOKI 2008-11-08 02:49:07 UTC
(In reply to comment #4)
Thank you for the comment. I attached the files.

Comment 9 Joel Andres Granados 2008-11-11 11:06:12 UTC
With respect to this comment:
"
 This bug doesn't occur on my x86 test machine.
"

Did you test with the exact same initial partition?
I'm looking for the reproducer here so I have a couple of questions:

1. What do you mean by "changing a physical volume to LVM"?  a physical volume (pv) is the lowest element in the lvm stack.  and LVM  (logical volume manager) is just the name that encompasses all the LVM stack (pv, vg, lv, the commands...)  I'm assuming that you had a physical *partition* and you wanted to make it a pv.

2. Can you plese give more details for the reproducer:
   a: what was the original partition table `parted print free` and `pvdisplay ; lvdisplay ; vgdisplay` for the lvm stuff.
   b:What change did you want to do.  (I think this is pretty much in your original comment, but any other information that you want to add will be appreciated.)

I think that this is related to the "missing physical extent" bug.  Which I thought was already solved.  You might be experiencing a corner case.

Comment 10 Hideo AOKI 2008-11-11 16:55:49 UTC
(In reply to comment #9)
> With respect to this comment:
> "
>  This bug doesn't occur on my x86 test machine.
> "
> 
> Did you test with the exact same initial partition?
> I'm looking for the reproducer here so I have a couple of questions:

Yes. I didn't change any partition size.

> 1. What do you mean by "changing a physical volume to LVM"?  a physical volume
> (pv) is the lowest element in the lvm stack.  and LVM  (logical volume manager)
> is just the name that encompasses all the LVM stack (pv, vg, lv, the
> commands...)  I'm assuming that you had a physical *partition* and you wanted
> to make it a pv.

You are right. I changed a physical *partition* to a physical volume.
I apologize, if it was unclear.  

> 2. Can you plese give more details for the reproducer:
>    a: what was the original partition table `parted print free` and `pvdisplay
> ; lvdisplay ; vgdisplay` for the lvm stuff.
>    b:What change did you want to do.  (I think this is pretty much in your
> original comment, but any other information that you want to add will be
> appreciated.)

The original partition was formatted as ext3. To test LVM installation, 
I changed the partition to LVM physical volume, and assigned the whole volume
to a logical volume as root (/).  
 
> I think that this is related to the "missing physical extent" bug.  Which I
> thought was already solved.  You might be experiencing a corner case.

Will the bug be fixed in RHEL 5.3 Beta snapshot 2? If so, I'll re-test by using snapshot 2.

Comment 11 Joel Andres Granados 2008-11-14 10:43:14 UTC
I just tested this on my test machine.  The bug does not show itself when I replace a physical partition with a LVM setup.  As I stated previously, we would need the exact setup of the previous partition table to reproduce and analyze this issue.  Without this I do not have enough info for addressing this.

Comment 12 Hideo AOKI 2008-11-15 02:38:27 UTC
(In reply to comment #11)
> I just tested this on my test machine.  The bug does not show itself when I
> replace a physical partition with a LVM setup.  As I stated previously, we
> would need the exact setup of the previous partition table to reproduce and
> analyze this issue.  Without this I do not have enough info for addressing
> this.

The following is the partition before the installation
(step 2 in the reproducing procedure).
I use only sda, although the machine has 2 disks. 
When I change partition no 2 of sda from ext3 to LVM, 
the problem occurs.

[root@hit ~]# parted /dev/sda print

Model: FUJITSU MAX3073RC (scsi)
Disk /dev/sda: 73.4GB          
Sector size (logical/physical): 512B/512B
Partition Table: gpt                     

Number  Start   End     Size    File system  Name  Flags
 1      17.4kB  537MB   537MB   fat16              boot
 2      537MB   22.0GB  21.5GB  ext3
 3      22.0GB  26.3GB  4295MB  linux-swap
 4      26.3GB  73.4GB  47.1GB  ext3

Information: Don't forget to update /etc/fstab, if necessary.

[root@hit ~]# parted /dev/sdb print

Model: FUJITSU MAX3073RC (scsi)
Disk /dev/sdb: 73.4GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name       Flags
 1      17.4kB  512MB   512MB                full-vfat
 2      512MB   10.2GB  9728MB               full-root
 3      10.2GB  11.0GB  760MB                para-vfat
 4      11.0GB  20.0GB  9000MB               para-root
 5      20.0GB  30.0GB  10.0GB  ext3         tmp
 6      30.0GB  30.5GB  535MB   fat16                   boot
 7      30.5GB  52.0GB  21.5GB  ext3
 8      52.0GB  73.4GB  21.4GB  ext3

Information: Don't forget to update /etc/fstab, if necessary.

[root@hit ~]#

Comment 13 Joel Andres Granados 2008-11-18 07:49:10 UTC
Hideo:
Thank you very much for the information.  I will give the same test a try with this new information.

Since parted does round up some information when printing in in Mb, the tests that I do with the info that you posted might still give me a negative result (as in the bug not showing itself).  To address this, can you please run `parted /dev/sda unit s print free`  This will give me more detailed information (sector numbers) on what your table looks like :).

Moreover, can you please attach the first 512 bytes of your device, this contains the partition table.  It will be most helpful if the test with the sector numbers comes out negative as well.

Comment 14 Joel Andres Granados 2008-11-18 15:25:22 UTC
Tried to test using the exact same setup in a sda and hda device  The bug did no show show itself.  Are you sure that this is present in snap3 or later.

Can you please retest with snap3 and confirm that the bug is still present.  If so, please post the sector output and the first 512bytes of your device (hda)

thx.

Comment 15 Hideo AOKI 2008-11-18 16:30:31 UTC
(In reply to comment #13)
> Since parted does round up some information when printing in in Mb, the tests
> that I do with the info that you posted might still give me a negative result
> (as in the bug not showing itself).  To address this, can you please run
> `parted /dev/sda unit s print free`  This will give me more detailed
> information (sector numbers) on what your table looks like :).

[root@hit ~]# parted /dev/sda unit s print free

Model: FUJITSU MAX3073RC (scsi)
Disk /dev/sda: 143374743s
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start      End         Size       File system  Name  Flags
 1      34s        1048609s    1048576s   fat16              boot
 2      1048610s   42991649s   41943040s  ext3
 3      42991650s  51380257s   8388608s   linux-swap
 4      51380258s  143374710s  91994453s  ext3

Information: Don't forget to update /etc/fstab, if necessary.

[root@hit ~]#

(In reply to comment #14)
> Tried to test using the exact same setup in a sda and hda device  The bug did
> no show show itself.  Are you sure that this is present in snap3 or later.

No. Since snapshot 3 is not released to partners, I don't test in the latest 
snapshot yet.

> Can you please retest with snap3 and confirm that the bug is still present.  If
> so, please post the sector output and the first 512bytes of your device (hda)

Sure. I'll re-test after snapshot 3 is released. If the bug occurs, I'll post the 
first sector of the disk.

Thanks.

Comment 16 Hideo AOKI 2008-11-18 22:39:27 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > Tried to test using the exact same setup in a sda and hda device  The bug did
> > no show show itself.  Are you sure that this is present in snap3 or later.
> 
> No. Since snapshot 3 is not released to partners, I don't test in the latest 
> snapshot yet.
> 
> > Can you please retest with snap3 and confirm that the bug is still present.  If
> > so, please post the sector output and the first 512bytes of your device (hda)
> 
> Sure. I'll re-test after snapshot 3 is released. If the bug occurs, I'll post
> the 
> first sector of the disk.

Snapshot 3 still has the bug.

It seems that maximum volume size is miscalculated in editing lvm step.
Anaconda recognizes sda2 as 20480MB. The LVM editing window of anaconda
shows that maximum volume is 20480MB, too. If I create new logical volume
for root as maximum size in the window, installation fails. After rebooting 
anaconda, anaconda recognizes the logical volume as 20448MB.

By the way, in the lvm editing window, if I create the logical volume as
a little bit smaller size, for example 20440MB, I can install 5.3 snapshot 3 
using LVM.

Comment 17 Hideo AOKI 2008-11-18 23:01:08 UTC
Created attachment 323979 [details]
the first sector of sda

I attach the first sector of sda

Comment 18 Joel Andres Granados 2008-11-21 15:37:09 UTC
(In reply to comment #17)
> Created an attachment (id=323979) [details]
> the first sector of sda

I would need the first sector of the partition table that you began with.  The attachment contains no recognizable partition table.

Comment 19 Joel Andres Granados 2008-11-21 16:27:27 UTC
don't worry about the first sector image.  I have already reproduced this issue.  It is not arch dependent.  You have found a corner case that only happens with this specific sector layout.

Comment 20 Hideo AOKI 2008-11-22 00:30:17 UTC
(In reply to comment #19)
> don't worry about the first sector image.  I have already reproduced this
> issue.  It is not arch dependent.  You have found a corner case that only
> happens with this specific sector layout.

It's good news. Thank you for investigating.

Comment 27 Joel Andres Granados 2008-12-02 17:05:59 UTC
Created attachment 325393 [details]
script to create the partitions.

For QE:
To test this you must create an exact replica of what the user had before the install.  This means creating the partitions by specifying the sectors.  Attached is a script.
You might have to change the script a little as the device name will change.

Comment 28 Takahiro Yasui 2008-12-18 01:01:55 UTC
I tested with snapshot 5 and found that this issue was resolved. Thank you.

Comment 31 errata-xmlrpc 2009-01-20 21:34:45 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0164.html