Bug 1314092 - f24 installation fails with 1GB ram
Summary: f24 installation fails with 1GB ram
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 24
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: ARMTracker 1595369
TreeView+ depends on / blocked
Reported: 2016-03-02 22:08 UTC by Paul Whalen
Modified: 2018-10-22 18:00 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1595369 (view as bug list)
Last Closed: 2016-03-31 14:59:44 UTC
Type: Bug

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

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1329613 'unspecified' 'CLOSED' 'bananapi: unable to pxe boot' 2019-11-11 05:18:15 UTC

Internal Links: 1329613

Description Paul Whalen 2016-03-02 22:08:54 UTC
Created attachment 1132553 [details]

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

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.


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