Bug 491746 - LVMError: lvcreate failed for vg_ibm505lp1/lv_root
LVMError: lvcreate failed for vg_ibm505lp1/lv_root
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pyparted (Show other bugs)
rawhide
ppc Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
anaconda_trace_hash:82e536bb1b51570c5...
:
: 491505 492127 495144 (view as bug list)
Depends On:
Blocks: F11AnacondaBlocker
  Show dependency treegraph
 
Reported: 2009-03-23 16:03 EDT by James Laska
Modified: 2013-09-02 02:33 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-11 13:41:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Attached traceback automatically from anaconda. (206.37 KB, text/plain)
2009-03-23 16:03 EDT, James Laska
no flags Details

  None (edit)
Description James Laska 2009-03-23 16:03:28 EDT
The following was filed automatically by anaconda:
anaconda 11.5.0.35 exception report
Traceback (most recent call first):
  File "/tmp/updates/storage/devicelibs/lvm.py", line 370, in lvcreate
    raise LVMError("lvcreate failed for %s/%s" % (vg_name, lv_name))
  File "/tmp/updates/storage/devices.py", line 1956, in create
    lvm.lvcreate(self.vg.name, self._name, self.size)
  File "/tmp/updates/storage/deviceaction.py", line 206, in execute
    self.device.create(intf=intf)
  File "/tmp/updates/storage/devicetree.py", line 660, in processActions
    action.execute(intf=self.intf)
  File "/tmp/updates/storage/__init__.py", line 184, in doIt
    self.devicetree.processActions()
  File "/usr/lib/anaconda/packages.py", line 115, in turnOnFilesystems
    anaconda.id.storage.doIt()
  File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 128, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/gui.py", line 1317, in nextClicked
    self.anaconda.dispatch.gotoNext()
LVMError: lvcreate failed for vg_ibm505lp1/lv_root
Comment 1 James Laska 2009-03-23 16:03:32 EDT
Created attachment 336371 [details]
Attached traceback automatically from anaconda.
Comment 2 David Lehman 2009-03-23 17:31:16 EDT
Parted shows the newly created partition layout, while the kernel still reports the old (no longer existing) layout.

sh-4.0# parted /dev/sda print
Model: IBM H0 ST336753LC (scsi)
Disk /dev/sda: 36.4GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  4227kB  4194kB  primary               prep 
 2      4227kB  36.4GB  36.4GB  primary               lvm  

sh-4.0# cat /proc/partitions 
major minor  #blocks  name

   7        0     109168 loop0
   8        0   35548320 sda
   8        1       8001 sda1
   8        2     200812 sda2
   8        3   35334967 sda3
   8       16   35548320 sdb
   8       17     204800 sdb1
   8       18   35338981 sdb2
sh-4.0#
Comment 3 David Lehman 2009-03-23 17:33:31 EDT
So the basic problem is that lvm finds a 192MB partition when it goes to create a pv on sda2. This means that instead of a 36GB pv, the volgroup gets a 192MB pv, which causes allocation of lvs to fail since the volgroup is half the size it is supposed to be.
Comment 4 Joel Andres Granados 2009-03-24 04:58:31 EDT
*** Bug 491505 has been marked as a duplicate of this bug. ***
Comment 5 Radek Vykydal 2009-03-24 07:06:09 EDT
It seems like we fail to destroy lvm metadata due to volume group name
containing '-' character (which is said to be illegal when entered in UI)
Comment 6 Radek Vykydal 2009-03-24 08:48:51 EDT
(In reply to comment #5)
> It seems like we fail to destroy lvm metadata due to volume group name
> containing '-' character (which is said to be illegal when entered in UI)  

well, it is probably not significant for the error we are getting,
and it is *not* happening in bug #491505
Comment 7 Radek Vykydal 2009-03-24 11:44:48 EDT
Are we hitting here what Hans describes in:
https://bugzilla.redhat.com/show_bug.cgi?id=491529#c9 ?
Comment 8 David Lehman 2009-03-24 12:07:24 EDT
I don't think so. The system was still in this state even 30 minutes later. This is not question of the kernel or udev catching up on events in the system, but rather the kernel is not at all aware that anything has changed.
Comment 9 James Laska 2009-03-25 10:05:14 EDT
*** Bug 492127 has been marked as a duplicate of this bug. ***
Comment 10 James Laska 2009-03-25 16:23:00 EDT
After debugging with dlehman, reassigning this to pyparted.

In the install environment, on tty2 we tested the following:

= Setup =

Clear out the disks by doing.

sh-4.0# parted /dev/sda
> mklabel msdos

sh-4.0# parted /dev/sdb
> mklabel msdos

sh-4.0# cat /proc/partitions 
major minor  #blocks  name

   7        0     109160 loop0
   8        0   35548320 sda
   8       16   35548320 sdb


= Test parted and /proc/partitions =

Create partitions using parted and confirm that the kernel sees the changes.

# parted /dev/sda
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mkpart                                                           
Partition type?  primary/extended? primary                                
File system type?  [ext2]? prep                                           
parted: invalid token: prep
File system type?  [ext2]? ?                                              
parted: invalid token: ?
File system type?  [ext2]?                                                
Start? 0                                                                  
End? 4M                                                                   
(parted) p                                                                
Model: IBM H0 ST336753LC (scsi)
Disk /dev/sda: 36.4GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start  End     Size    Type     File system  Flags
 1      512B   4000kB  4000kB  primary                    

(parted) toggle 1 boot                                                    
(parted) mkpart                                                           
Partition type?  primary/extended? primary                                
File system type?  [ext2]? ext3                                           
Start? 4000kB                                                             
End? 204M                                                                 
(parted) p                                                                
Model: IBM H0 ST336753LC (scsi)
Disk /dev/sda: 36.4GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      512B    4000kB  4000kB  primary               boot 
 2      4000kB  204MB   200MB   primary                    

(parted) quit                                                             

sh-4.0# cat /proc/partitions
major minor  #blocks  name

   7        0     109160 loop0
   8        0   35548320 sda
   8        1       3906 sda1
   8        2     195312 sda2
   8       16   35548320 sdb

= Test pyparted and /proc/partitions =

Create partitions using pyparted and confirm that the kernel sees the changes.

sh-4.0# cat /proc/partitions
major minor  #blocks  name

   7        0     109160 loop0
   8        0   35548320 sda
   8        1       3906 sda1
   8        2     195312 sda2
   8       16   35548320 sdb

sh-4.0# python
import parted
device = parted.Device(path="/dev/sda")
disk = parted.Disk(device=device)
k
disk.removePartition(disk.partitions[1])
True
disk.commit()
<ctrl-d>


sh-4.0# cat /proc/partitions
major minor  #blocks  name

   7        0     109160 loop0
   8        0   35548320 sda
   8        1       3906 sda1
   8        2     195312 sda2
   8       16   35548320 sdb
Comment 11 David Lehman 2009-03-26 19:15:53 EDT
I have just hit the same scenario on x86. Parted doesn't issue any errors, but /proc/partitions still shows the old layout. This leads to an "Insufficient free extents" lvm error since the kernel is telling lvm that the pv is smaller than it actually is.
Comment 12 Joel Andres Granados 2009-03-27 05:59:00 EDT
A ped_disk_commit, should do the job.  or a ped_disk_commit_to_dev followed by a ped_disk_commit_to_os.
Comment 13 Chris Lumens 2009-03-27 17:39:39 EDT
I used jlaska's instructions above to create a partition table with parted, then start up python and delete a partition with pyparted.  At the end of his instructions (disk.commit()), I check /proc/partitions and it still lists both partitions.

However, if I then do disk.commitToOS(), /proc/partitions reflects the fact that I deleted the second partition.  commit should just call ped_commit_to_dev followed by ped_commit_to_disk so I'm not sure what's going on here.  But at least this is something more to go on.
Comment 14 David Cantrell 2009-04-03 22:14:40 EDT
I have been working on this one for the better part of today and I don't know what's happening, only that when you call commitToDevice() and then commitToOS(), /proc/partitions is updated correctly.  If I just call commit(), /proc/partitions does not update.

I added many fprintf() statements in libparted to trace the calls.  There is no difference in what lines are reached between calling commit() or calling commitToDevice() followed by commitToOS().  I really just don't get it.

So, I'm changing pyparted's commit() method to call commitToDevice() then commitToOS().

Weird.

Will be fixed in pyparted-2.0.10
Comment 15 Chris Lumens 2009-04-15 16:08:39 EDT
*** Bug 495144 has been marked as a duplicate of this bug. ***
Comment 16 James Laska 2009-05-11 13:41:02 EDT
Thanks David and Chris, I can confirm this issue is no longer present in current rawhide (anaconda-11.5.0.51-1.fc11, pyparted-2.0.12-1.fc11).

Marking CLOSED RAWHIDE

Note You need to log in before you can comment on or make changes to this bug.