Bug 1314092 - f24 installation fails with 1GB ram
f24 installation fails with 1GB ram
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
24
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: ARMTracker
  Show dependency treegraph
 
Reported: 2016-03-02 17:08 EST by Paul Whalen
Modified: 2016-04-22 09:31 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-31 10:59:44 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
rdsosreport.txt (67.01 KB, text/plain)
2016-03-02 17:08 EST, Paul Whalen
no flags Details

  None (edit)
Description Paul Whalen 2016-03-02 17:08:54 EST
Created attachment 1132553 [details]
rdsosreport.txt

Description of problem:
f24 network installation needs more than 1GB ram, tested with a VM and bare metal. 

Version-Release number of selected component (if applicable):
anaconda-24.13-1.fc24

How reproducible:
Every time

Steps to Reproduce:
1. Create a VM with 1GB ram, using the latest f24
2. Fails when grabbing stage2


Actual results:
 93  342M   93  319M    0     0  4955k      0  0:01:10  0:01:06  0:00:04 3326k
[  117.030748] dracut-initqueue[629]: curl: (23) Failed writing body (10176 != 16176)
[  118.551988] dracut-initqueue[629]: mount: wrong fs type, bad option, bad superblock on /dev/loop0,
[  118.553728] dracut-initqueue[629]:        missing codepage or helper program, or other error
[  118.557054] dracut-initqueue[629]:        In some cases useful info is found in syslog - try
[  118.558610] dracut-initqueue[629]:        dmesg | tail or so.
[  118.572160] dracut-initqueue[629]: umount: /run/initramfs/squashfs: not mounted
[  118.607805] dracut-initqueue[629]: /lib/anaconda-lib.sh: line 110: printf: write error: No space left on device


Expected results:
Successful installation. 

Additional info:
Succeeds when using 1.5+ GB ram.
Comment 1 David Shea 2016-03-17 14:16:31 EDT
The bad news: you probably just need to use more RAM. Loading the stage2 from the network requires more memory than installation using a local stage2, since the squashfs has to be downloaded to the initramfs.

The good news: This may already be fixed in rawhide, and may be fixed in post-alpha F24. There a couple of changes in the pipeline that should reduce the size of the stage2 by a fair chunk: bug 1318408 drops the last python2 dependency, and bug 1317692 drops the gtk2 dependency and a 40MB binary in /usr/libexec. There's also pending changes in https://github.com/rhinstaller/lorax/pull/99 which shaves another 30MB or so off the compressed stage2 size.

The policycoreutils+python2 change (1318408) should hit f24 after the alpha freeze is lifted, so if that doesn't do it, I suggest you re-open the webkitgtk4 bug (1317692) to have that updated to f24, and if that still isn't enough, please open a bug against lorax for *those* changes.
Comment 2 Dennis Gilmore 2016-03-22 23:15:27 EDT
I hit this with Alpha-1.7 with 1.5GiB ram allocated to the VM
Comment 4 David Shea 2016-03-23 16:37:35 EDT
Dennis, can you link/attach the logs from your failure?
Comment 5 David Shea 2016-03-23 16:47:00 EDT
Could've sworn I set needinfo. Anyway: the logs from the 1.5 GB failure may be helpful, if you could include those.
Comment 6 Dennis Gilmore 2016-03-23 17:37:34 EDT
I will reproduce and grab them. I did find one piece interesting. after some extra testing I was able to install in 11.5GiB ram if I used the Everything tree, I had been using the Cloud tree, the difference is that there is a product.img for cloud. maybe its pushing it over in memory or maybe it is corrupt.
Comment 7 David Shea 2016-03-23 17:42:19 EDT
Interesting. product.img does also need to be downloaded which will consume space in the initramfs, but the ones in comment 3 are 12 bytes, and, as you suspect, corrupt. I'd be curious to see where things wrong.
Comment 8 David Shea 2016-03-31 10:59:44 EDT
The issues in comment 3 were a problem with xz blowing out the address space on 32-bit systems, and has been fixed in lorax. Now that everything is in the new lorax, http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/armhfp/os/images/install.img is down to 308MB, and since the original failure bombed out at 319, I'm going to close this again.

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