Bug 1314092

Summary: f24 installation fails with 1GB ram
Product: [Fedora] Fedora Reporter: Paul Whalen <pwhalen>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 24CC: ahmer_mansoor, anaconda-maint-list, dennis, dshea, g.kaviyarasu, jonathan, vanmeeuwen+fedora
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1595369 (view as bug list) Environment:
Last Closed: 2016-03-31 14:59:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 245418, 1595369    
Attachments:
Description Flags
rdsosreport.txt none

Description Paul Whalen 2016-03-02 22:08:54 UTC
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 18:16:31 UTC
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-23 03:15:27 UTC
I hit this with Alpha-1.7 with 1.5GiB ram allocated to the VM

Comment 4 David Shea 2016-03-23 20:37:35 UTC
Dennis, can you link/attach the logs from your failure?

Comment 5 David Shea 2016-03-23 20:47:00 UTC
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 21:37:34 UTC
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 21:42:19 UTC
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 14:59:44 UTC
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 16:57:48 UTC
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 10 Ahmer Mansoor 2018-10-22 17:16:53 UTC
I  face the same problem in RHEL 7.5, while installing through a PXE boot server and the PXE client has 1 GB memory.

Follow the advice of Paul Whalen to workaround the issue.


Thanks,