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: 2018-06-01 12:57 EDT (History)
7 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.
Comment 9 Steffen Scheib 2018-06-01 12:57:48 EDT
This issue is still persistent. However I tried kickstarting a CentOS 7 not a Fedora, but I guess its based on the same issue.

How to reproduce:
Simply use 1024M as available memory and kickstart your installation
dracut-initqueue bugs out with the message "mount wrong fs type /dev/loop0"
Change the available memory to 2048 and kickstart your installation again - works perfectly!

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