Bug 853602
| Summary: | Installer high memory usage | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jan ONDREJ <ondrejj> | ||||||||
| Component: | anaconda | Assignee: | Will Woods <wwoods> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 18 | CC: | anaconda-maint-list, g.kaviyarasu, jmontleo, jonathan, pschindl, rtguille, vanmeeuwen+fedora, wwoods | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2014-02-05 12:07:38 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Jan ONDREJ
2012-09-01 06:59:29 UTC
Created attachment 608900 [details]
anaconda.log, the guest has 768mb ram and anaconda request 1gb
It happened after hitting an unknown error, which i tried to auto-report, but a second unknown error happened and the guest became hyper-slow. I do not know if anaconda now requires 1gb or if it was a bug somewhere.
Created attachment 608901 [details]
anaconda out of memory error
Created attachment 608902 [details]
idem, program.log
*** Bug 853794 has been marked as a duplicate of this bug. *** *** Bug 854155 has been marked as a duplicate of this bug. *** Can you attach the boot arguments and/or kickstart used? Most importantly, what method is being used to get the installer runtime image? http/https/ftp has much higher memory usage than nfs/hd/cdrom, so that could be a contributing factor... Also, these logs show anaconda running with 768MB RAM, not 1GB. Does it also fail with 1GB? Can you attach a log showing this? Could you also get 'ps aux' output or some other details about what's actually *using* all the RAM? (In reply to comment #6) > Can you attach the boot arguments and/or kickstart used? > Most importantly, what method is being used to get the installer runtime > image? http/https/ftp has much higher memory usage than nfs/hd/cdrom, so > that could be a contributing factor... I use PXE boot, repo=http://... and an kickstart. My boot options: repo=http://ftp.upjs.sk/pub/fedora /linux/development/18/x86_64/os ksdevice=bootif ks=http://boot.salstar.sk/ks/dev elopment root=live:http://ftp.upjs.sk/pub/fedora/linux/development/18/x86_64/os/ LiveOS/squashfs.img nomodeset nomodeset is required in qemu's default cirrus card (not reported yet, that fails to start X without nomodeset). Similar problems without kickstart too. > Also, these logs show anaconda running with 768MB RAM, not 1GB. Does it also > fail with 1GB? Can you attach a log showing this? Could you also get 'ps > aux' output or some other details about what's actually *using* all the RAM? My logs are from 1 GB system, which don't fail, but on 1 GB system my system is installing very slowly, due to high swapping. On 1.5 GB system swaps is lower and installation if faster. Reartes attached different logs, ask him if you need. (In reply to comment #6) > Also, these logs show anaconda running with 768MB RAM, not 1GB. Does it also > fail with 1GB? Can you attach a log showing this? Could you also get 'ps > aux' output or some other details about what's actually *using* all the RAM? I can't reproduce this today, possibly due to another bug. Installer starts to format partitions, but after some time my install screen is black and on F1 console there is "Pane id dead" message on last row. :-( Another bug: After clear of whole disk I can't assign new disk areas. Instead of starting disk selector it says only: Error checking storage configuration. Switching to F2 and formatting disk using fdisk does not help. Later I was able to start manual partitioning, but clicking on "Click here to create them automatically" killed my system. An unknown error has occured was displayed, but unable to click on "More info..." or "Report bug", so I can't tell more. Well, I can reproduce this with Fedora-18-Alpha-TC5-x86_64-netinst.iso - meaning not using 'repo=http://...'. The crash happens when you try to commit the partitioning. It looks like the traceback is caused by 'modprobe scsi_wait_scan' failing, due to lack of memory. (As a side note, there's no scsi_wait_scan module in the image, because it's not in the kernel RPM anymore - I think it's been removed). Hard to say immediately what's using all the RAM. It's not the http:// repo though, so ignore that. Assigning to Will only because he started looking at it. Want to avoid duplication of work. > Reartes attached different logs, ask him if you need.
In my case (853794) i did not use any kickstart, just he regular dvd iso.
And in my case the system became slow after an "unknown error" in which "report bug" also failed.
I created a VM with 1GB of RAM and the installer died in various places. After 6 or 7 tries I upped it to 2GB and the installer was able to proceed normally. In particular entering the disk partitioning section and performing custom partitioning seemed to be at least the beginning of the slow down, if not the end of any meaningful progress. This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |