Bug 433024 - Anaconda traceback when trying to resize old LV to create new LV
Anaconda traceback when trying to resize old LV to create new LV
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Jeremy Katz
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F9Beta
  Show dependency treegraph
 
Reported: 2008-02-15 13:46 EST by Will Woods
Modified: 2009-02-16 16:25 EST (History)
0 users

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


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

  None (edit)
Description Will Woods 2008-02-15 13:46:38 EST
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 13:46:38 EST
Created attachment 295032 [details]
anacdump.txt
Comment 2 Jeremy Katz 2008-02-24 14:24:58 EST
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 15:15:19 EDT
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 17:52:39 EDT
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 17:58:53 EDT
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 17:10:21 EDT
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 01:13:31 EDT
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.