|Summary:||f24 installation fails with 1GB ram|
|Product:||[Fedora] Fedora||Reporter:||Paul Whalen <pwhalen>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||24||CC:||ahmer_mansoor, anaconda-maint-list, dennis, dshea, g.kaviyarasu, jonathan, vanmeeuwen+fedora|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|:||1595369 (view as bug list)||Environment:|
|Last Closed:||2016-03-31 14:59:44 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||245418, 1595369|
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: curl: (23) Failed writing body (10176 != 16176) [ 118.551988] dracut-initqueue: mount: wrong fs type, bad option, bad superblock on /dev/loop0, [ 118.553728] dracut-initqueue: missing codepage or helper program, or other error [ 118.557054] dracut-initqueue: In some cases useful info is found in syslog - try [ 118.558610] dracut-initqueue: dmesg | tail or so. [ 118.572160] dracut-initqueue: umount: /run/initramfs/squashfs: not mounted [ 118.607805] dracut-initqueue: /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,