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 bugzilla.redhat.com.
Bug 1314092 - f24 installation fails with 1GB ram
Summary: f24 installation fails with 1GB ram
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 24
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
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)
Environment:
Last Closed: 2016-03-31 14:59:44 UTC
Type: Bug
Embargoed:

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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1329613 0 unspecified CLOSED bananapi: unable to pxe boot 2022-05-16 11:32:56 UTC

Internal Links: 1329613

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 3 Dennis Gilmore 2016-03-23 03:55:12 UTC 
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/
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,
Note You need to log in before you can comment on or make changes to this bug.