Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at

Bug 1595369

Summary: rhel 7.5 installation fails with 1GB ram
Product: Red Hat Enterprise Linux 7 Reporter: David Wood <dwood>
Component: loraxAssignee: Brian Lane <bcl>
Status: CLOSED DUPLICATE QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.5CC: anaconda-maint-list, dennis, dshea, extras-qa, g.kaviyarasu, jkonecny, jonathan, lkocman, pwhalen, rfreire, salmy, sbueno, steffen, vanmeeuwen+fedora
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1314092 Environment:
Last Closed: 2018-07-24 07:22:05 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:
Bug Depends On: 1314092    
Bug Blocks: 245418    

Description David Wood 2018-06-26 18:40:22 UTC
+++ This bug was initially created as a clone of Bug #1314092 +++

Description of problem:
The 2gb min was found to effect RHEL 7.5 as well. 
rhel 7.5 network installation needs more than 1GB ram, tested with a VM and bare metal. 

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. Create a VM with 1GB ram, using the latest rhel 7.5
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/ line 110: printf: write error: No space left on device

Expected results:
Successful installation. 

Additional info:
Succeeds when using 1.5+ GB ram.

--- Additional comment from David Shea on 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 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.

--- Additional comment from Dennis Gilmore on 2016-03-22 23:15:27 EDT ---

I hit this with Alpha-1.7 with 1.5GiB ram allocated to the VM

--- Additional comment from Dennis Gilmore on 2016-03-22 23:55:12 EDT ---

Reopenning, I also had failures with 1.5GiB ram on rawhide.

I used as well as

--- Additional comment from David Shea on 2016-03-23 16:37:35 EDT ---

Dennis, can you link/attach the logs from your failure?

--- Additional comment from David Shea on 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.

--- Additional comment from Dennis Gilmore on 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.

--- Additional comment from David Shea on 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.

--- Additional comment from David Shea on 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, is down to 308MB, and since the original failure bombed out at 319, I'm going to close this again.

--- Additional comment from Steffen Scheib on 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!

Comment 2 Jiri Konecny 2018-06-27 08:58:19 UTC
This is not solvable by Anaconda. The problem is that stage2 image must get smaller or documentation requirements must increase.

I'm changing component to releng so they need to decide if and how to make the image smaller by changing lorax templates.

Also please next time file a new bug. The original bug is not related because the package set in RHEL is completely different from Fedora.

Comment 3 Lubos Kocman 2018-07-09 12:20:01 UTC
This would be really a lorax bug. releng typically don't modify templates.


Comment 4 Brian Lane 2018-07-09 17:19:54 UTC
This really isn't a lorax bug. As packages increase in size, gain more dependencies, etc. the image grows. Someone, usually from the Anaconda team, needs to identify what can *safely* be removed to make it smaller.

Or the documentation needs to be updated.

Comment 5 Jiri Konecny 2018-07-20 06:35:37 UTC
*** Bug 1603927 has been marked as a duplicate of this bug. ***

Comment 8 Samantha N. Bueno 2018-07-24 07:22:05 UTC

*** This bug has been marked as a duplicate of bug 1410948 ***