Bug 433024 - Anaconda traceback when trying to resize old LV to create new LV
Summary: Anaconda traceback when trying to resize old LV to create new LV
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 9
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F9Beta
TreeView+ depends on / blocked
 
Reported: 2008-02-15 18:46 UTC by Will Woods
Modified: 2009-02-16 21:25 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-02-16 21:25:12 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
anacdump.txt (378.36 KB, text/plain)
2008-02-15 18:46 UTC, Will Woods
no flags Details
dump from trying to resize LV, anaconda-11.4.0.49 (393.04 KB, text/plain)
2008-03-12 19:15 UTC, Will Woods
no flags Details

Description Will Woods 2008-02-15 18:46:38 UTC
I've got a Fedora 8 system with the default disk layout:
sda: 250GB drive
  sda1: ext3 /boot
  sda2: LVM PV
    VolGroup00/LogVol00 (ext3 /)
    VolGroup00/LogVol01 (swap)

I'm attempting to install F9Alpha onto the machine. With the new resizing
support in anaconda, I decided to shrink the old root (LogVol00) by 100GB
smaller and create a new 100GB volume for F9. 

Anaconda allows me to resize LogVol00 and create the new LogVol02, but when I
hit "OK" to accept the changes to VolGroup00, I get the following error popup:

Error Partitioning
Could not allocate requested partitions: Adding this partition would not leave
enough disk space for already allocated logical volumes in VolGroup00..

Hitting "OK" gives me an anaconda traceback in partition_gui.py:
anaconda 11.4.0.28 exception report
Traceback (most recent call first):
  File "/usr/lib/anaconda/autopart.py", line 1100, in doPartitioning
    lvmLog.info("Used size vs. available for vg %s:  %s %s",
request.volumeGroupName, vgused[vg], request.getActualSize(requests, diskset))
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1013, in refresh
    autopart.doPartitioning(self.diskset, self.partitions)
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1201, in editLVMVolumeGroup
    if self.refresh():
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1071, in editCb
    self.editLVMVolumeGroup(vgrequest)
AttributeError: 'NoneType' object has no attribute 'volumeGroupName'

Full anacdump.txt from a similar attempt is attached.

Comment 1 Will Woods 2008-02-15 18:46:38 UTC
Created attachment 295032 [details]
anacdump.txt

Comment 2 Jeremy Katz 2008-02-24 19:24:58 UTC
Fixed in git, at least with test mode.  Will build a new anaconda so that
hopefully we'll have images tomorrow

Comment 3 Will Woods 2008-03-12 19:15:19 UTC
Created attachment 297827 [details]
dump from trying to resize LV, anaconda-11.4.0.49

Gets further now, but the fs check during the resize operation seems to fail.
It should work - there's plenty of free space.

Maybe something about installing from LiveCD could interfere with the partition
resizing/checking?

anacdump.txt is attached.

Here's the trace:
anaconda 11.4.0.49 exception report
Traceback (most recent call first):
  File "/usr/lib/anaconda/fsset.py", line 552, in resize
    raise RuntimeError, "Check of %s failed" %(devicePath,)
  File "/usr/lib/anaconda/fsset.py", line 1615, in resizeFilesystems
    self.progressWindow, chroot)
  File "/usr/lib/anaconda/fsset.py", line 1624, in shrinkFilesystems
    self.resizeFilesystems(diskset, chroot, shrink = True)
  File "/usr/lib/anaconda/packages.py", line 157, in turnOnFilesystems
    anaconda.id.fsset.shrinkFilesystems(anaconda.id.diskset, anaconda.rootPath)

  File "/usr/lib/anaconda/dispatch.py", line 208, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 131, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/gui.py", line 1246, in nextClicked
    self.anaconda.dispatch.gotoNext()
RuntimeError: Check of /dev/VolGroup00/LogVol00 failed

Comment 4 Jeremy Katz 2008-03-12 21:52:39 UTC
Can you check tty5 to see what the output of e2fsck was?  This is basically that
fsck wasn't happy with the volume, so ...

Comment 5 Will Woods 2008-03-12 21:58:53 UTC
I checked it when this happened and couldn't find any errors.. maybe the return
code is being misinterpreted by anaconda? Doesn't e2fsck return 1 if problems
were fixed successfully (and everything is OK)?

I'll try again just to be sure. 

Comment 6 Will Woods 2008-03-19 21:10:21 UTC
Hey! It works with a system installed with the F9b Live image. So it's very
likely to be something particular to the way the F8 LiveCD creates the root
filesystem.

I'll try that again and see if I can get error messages from tty5. 

Comment 7 Bug Zapper 2008-05-14 05:13:31 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


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