Bug 468944
Summary: | anaconda fails to create logical volume. missing one pv problem. | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Hideo AOKI <haoki> | ||||||||||||||
Component: | anaconda | Assignee: | Joel Andres Granados <jgranado> | ||||||||||||||
Status: | CLOSED ERRATA | QA Contact: | Alexander Todorov <atodorov> | ||||||||||||||
Severity: | high | Docs Contact: | |||||||||||||||
Priority: | high | ||||||||||||||||
Version: | 5.3 | CC: | 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
Hideo AOKI
2008-10-29 02:08:45 UTC
Please attach the complete exception report to this bug so we can track down what was going on. Thanks. 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 Created attachment 322660 [details]
This picture is a part of lvm command log
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. Created attachment 322925 [details]
anaconda.log
Created attachment 322926 [details]
lvmout
Created attachment 322927 [details]
syslog
(In reply to comment #4) Thank you for the comment. I attached the files. 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. (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. 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. (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 ~]# 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. 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. (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. (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. Created attachment 323979 [details]
the first sector of sda
I attach the first sector of sda
(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. 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. (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. 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.
I tested with snapshot 5 and found that this issue was resolved. Thank you. 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 |