Bug 238266

Created attachment 153711 [details]
anacdump.txt

see also BZ 203044

Sorry that should be Bugzilla #232862 "Anaconda exception trying lvchange...."

My bug report looks more or less like a duplicate, but these are on different 
archs, so I'll not mark mine as duplicate for now (maybe stuff has to be fixed 
somehow other on x86_64). Well, finally this bug report has to be fixed until 
F7, because otherwise I'm not able to have F7 on my laptop during LinuxTag ;-)

Chris, please let me know when there's something to test, I'm willing to try.

Did you have anything previously installed?  If possible, could you provide the
partition layout from before attempting installation and also the partition
layout you are attempting to set up in anaconda?  Thanks.

I'm not changing the partition layout during the setup, I'm only selecting
that the already existing ext3 and swap partitions should be formatted using 
ext3 and swap. Partition size of / (hda3) is ~ 9 GB and size of the swap 
partition (hda2) is around 200 MB and the NTFS partition (hda1) is 70 GB. Oh 
and there's a working Windows XP system, yes. Do you need any special values 
from the partition setup or are these information enough?

Well I am unable to reproduce this here.  It looks like we're not doing a very
good job of reporting the underlying error that's occurring.  Could you add the
parameter updates=http://people.redhat.com/clumens/238266.img to your command
line when you boot the install media and when it crashes again, attach the
exception dump to this bug report?  This just adds more useful logging so I can
see why lvm is failing.  Thanks.

Why is LVM involved into this when I would like to do a non-LVM installation? 
Nevertheless, I'll re-start an F7t4 installation using the given parameter from 
above in the next time.

At various times, we invoke the LVM commands to scan for any existing logical
volumes on the system.  We need this to do things like prompt you for which
system you want to upgrade, build the disk graph on the partitioning screen,
know what labels to avoid, etc.  In the case where there is no LVM on the
system, the commands should still just be returning nothing instead of causing
some crash, though.

Created attachment 153889 [details]
anacdump.txt

Here is the file you're expecting. But when reading the log file myself, I'm
guessing that the problem is not enough memory to execute lvm successfully.
Unfortunately anaconda doesn't seem to use the new swap partition?!

Okay, it's a memory problem, because the monster anaconda wastes about 373 MB 
of memory (my laptop has 512 MB RAM some of the RAM is shared with the graphics 
chip, so 373 MB are remaining) for the dependency resolving and partitioning/
formatting at the same time before freeing some of it.

Well, the textbased installation is not much better, it only abuses 369 MB of 
memory for dependency resolving and partitioning/formatting before freeing some 
of it. Next step is where yum (?) is downloading the packages ("Installation is 
starting, this can take some time") or so is displayed and the snake eats 
slowly my memory again and starts swapping of the newly created swap partition. 
So far so good. When having 50 MB swapped and aten another 372 MB of memory, my 
laptop simply rebooted - really nice feature, guys</irony>.

Oh and if you're thinking, this isn't a bug nor a F7 blocker, please adapt the 
release notes at section "6.4.1. Hardware requirements for x86_64" to match at 
least a bit with the reality.

Reassigning this back to anaconda-maint-list for wider consideration.  Do we
want to raise the memory threshold for enabling early swap, or is there
something else we can do before F7?  I've also seen this reported in the office
during vmware installs.

I'm seeing this roo on a kickstart installation on x86_64 with 512MB.

(In reply to comment #14)
> Reassigning this back to anaconda-maint-list for wider consideration.  Do we
> want to raise the memory threshold for enabling early swap, or is there
> something else we can do before F7?  I've also seen this reported in the office
> during vmware installs.

I don't think we want to change the memory threshold I don't think...  need to
actually reproduce and then we can get a better idea of where things have gone.

Chris, Jeremy and all the others, feel free to hit me, if you need some guy
for testing/reproducing or delivering information etc. Personally, this memory 
monster makes me worry when thinking about the install party at LinuxTag 2007. 

IMHO the main memory leak is the dependency resolving itself which eats the 
memory step by steap and frees nothing of it. Memory gets free'd after the lvm/
partitioning stuff was executed as it looks to me.

Ping? IMHO time until F7 release is running away to fast and nothing happens?

Okay, did some investigating and reproduced with mem=384M.  We should probably
be a little bit more explicit about shared video memory really decreasing the
amount of memory that the system has and thus that exists as far as we're
concerned. 

But by bumping early swap up on 64bit platforms, we should at least avoid
problems and it's not too crazy since we do have higher requirements on those
platforms.