Bug 1595369

+++ 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):
anaconda

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/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.

--- 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 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.

--- 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 https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20160322.n.0/compose/Cloud/armhfp/os/ as well as https://kojipkgs.fedoraproject.org/compose/24/Fedora-24-20160322.4/compose/Cloud/armhfp/os/

--- 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, 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.

--- 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!