Bug 72974

Summary: Anaconda bails while trying to format disk with pre-existing lvm partitions.
Product: [Retired] Red Hat Linux Reporter: Mike McLean <mikem>
Component: anacondaAssignee: Jeremy Katz <katzj>
Status: CLOSED RAWHIDE QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-01-22 16:39:44 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:
Bug Depends On:    
Bug Blocks: 67218, 79579    
Attachments:
Description Flags
anaconda-ks.cfg from the *PREVIOUS* install
none
/tmp/syslog from this install
none
/tmp/anaconda.log from this install
none
/tmp/lvmout from this install
none
full traceback none

Description Mike McLean 2002-08-29 16:35:01 UTC
* Milan-re0826.0
* English / NFS (tree) / Minimal / GUI Install

I get the following error from anaconda:

"An error occured trying to format hde1.  This problem is serious, and the
install cannot continue."

Side note:  I wonder if these "pop-ups of death" should give the option of
making a traceback dump.

Anyway, the install was pretty normal (auto-partition) and I've been using this
machine for tons of installs.  The difference is that the *previous* install had
a pretty wild partitioning scheme.  In particular, /boot was on a raid 1 device
composed of hde1 and hde2.  The console shows an error about accessing beyond
end of device.

/me prepares to make a ton of attachments

Comment 1 Mike McLean 2002-08-29 16:36:20 UTC
Created attachment 73751 [details]
anaconda-ks.cfg from the *PREVIOUS* install

Comment 2 Mike McLean 2002-08-29 16:37:24 UTC
Created attachment 73754 [details]
/tmp/syslog from this install

Comment 3 Mike McLean 2002-08-29 16:38:24 UTC
Created attachment 73755 [details]
/tmp/anaconda.log from this install

Comment 4 Mike McLean 2002-08-29 16:40:47 UTC
Created attachment 73756 [details]
/tmp/lvmout from this install

Comment 5 Mike McLean 2002-09-06 10:11:35 UTC
Ok, got a traceback for you (installing -re0906.1).

Comment 6 Mike McLean 2002-09-06 10:12:24 UTC
Traceback (most recent call last):
  File "/usr/bin/anaconda", line 694, in ?
    intf.run(id, dispatch, configFileData)
  File "/usr/src/build/148651-i386/install//usr/lib/anaconda/text.py", line 402,
in run
  File "/usr/src/build/148651-i386/install//usr/lib/anaconda/dispatch.py", line
251, in currentStep
  File "/usr/src/build/148651-i386/install//usr/lib/anaconda/dispatch.py", line
150, in gotoNext
  File "/usr/src/build/148651-i386/install//usr/lib/anaconda/dispatch.py", line
215, in moveStep
  File "/usr/src/build/148651-i386/install//usr/lib/anaconda/autopart.py", line
1084, in doAutoPartition
  File "/usr/src/build/148651-i386/install//usr/lib/anaconda/autopart.py", line
1033, in doClearPartAction
  File "/usr/src/build/148651-i386/install//usr/lib/anaconda/autopart.py", line
950, in doPartitioning
PartitioningError: Adding this partition would not leave enough disk space for
already allocated logical volumes in vg01.

Local variables in innermost frame:
doRefresh: 1
vg: 6
request: VG Request -- name: vg01  uniqueID: 6
  format: 0 pesize: 4096  
  physvols: []
newParts: 
ret: 0
vgused: {6: 2048}
msg: success
requests: <partitions.Partitions instance at 0x8382314>
size: 2048
diskset: <partedUtils.DiskSet instance at 0x83dc5bc>
delete: drive: cciss/c0d3  start: 32  end: 142253279


Comment 7 Mike McLean 2002-09-06 10:13:21 UTC
Created attachment 75204 [details]
full traceback

Comment 8 Mike McLean 2002-09-06 10:16:17 UTC
I should clarify that this traceback comes from a slightly different scenario. 
In this case I simply had one lvm partition with no raid on the previous install.

Comment 9 Jeremy Katz 2003-01-03 05:35:49 UTC
Have you seen this with GinGin trees?

Comment 10 Mike McLean 2003-01-21 18:48:27 UTC
Ok, managed to get a testcase that replicates this with 8.0.  It seems to be
specific to machines with ide drives, or perhaps a single ide drive.   Will try
same case with Phoebe shortly.

Comment 11 Mike McLean 2003-01-21 19:46:28 UTC
Ok this testcase fails on an ide machine when I try it with 8.0, but passes with
Phoebe-beta4 (on the same machine).  Seems to be fixed.


Comment 13 Jeremy Katz 2003-01-22 05:37:16 UTC
Since I haven't seen this, would you say it's fixed in gingin or just lying dormant?

Comment 14 Mike McLean 2003-01-22 16:03:27 UTC
Since this testcase fails consistently when I run it on 8.0 and has passed with
flying colors on Phoebe-beta4, I would say it is probably fixed in the
underlying lvm/filesystem tools.

BTW, the traceback in one of the later comments isn't really the same bug (but
rather bug#77872).  

Comment 15 Jeremy Katz 2003-01-22 16:39:44 UTC
Okay, closing out