Bug 1595369 - rhel 7.5 installation fails with 1GB ram
Summary: rhel 7.5 installation fails with 1GB ram
Status: CLOSED DUPLICATE of bug 1410948
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lorax
Version: 7.5
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Brian Lane
QA Contact: Release Test Team
URL:
Whiteboard:
Keywords: Reopened
: 1603927 (view as bug list)
Depends On: 1314092
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2018-06-26 18:40 UTC by David Wood
Modified: 2018-07-24 12:26 UTC (History)
14 users (show)

(edit)
Clone Of: 1314092
(edit)
Last Closed: 2018-07-24 07:22:05 UTC


Attachments (Terms of Use)

Description David Wood 2018-06-26 18:40:22 UTC
+++ 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!

Comment 2 Jiri Konecny 2018-06-27 08:58:19 UTC
This is not solvable by Anaconda. The problem is that stage2 image must get smaller or documentation requirements must increase.

I'm changing component to releng so they need to decide if and how to make the image smaller by changing lorax templates.

Also please next time file a new bug. The original bug is not related because the package set in RHEL is completely different from Fedora.

Comment 3 Lubos Kocman 2018-07-09 12:20:01 UTC
This would be really a lorax bug. releng typically don't modify templates.

Lubos

Comment 4 Brian Lane 2018-07-09 17:19:54 UTC
This really isn't a lorax bug. As packages increase in size, gain more dependencies, etc. the image grows. Someone, usually from the Anaconda team, needs to identify what can *safely* be removed to make it smaller.

Or the documentation needs to be updated.

Comment 5 Jiri Konecny 2018-07-20 06:35:37 UTC
*** Bug 1603927 has been marked as a duplicate of this bug. ***

Comment 8 Samantha N. Bueno 2018-07-24 07:22:05 UTC

*** This bug has been marked as a duplicate of bug 1410948 ***


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