Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1511334 - enable rd.live.ram for NFS repository by default [NEEDINFO]
Summary: enable rd.live.ram for NFS repository by default
Keywords:
Status: CLOSED DUPLICATE of bug 1487001
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lorax
Version: 7.4
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Brian Lane
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-09 07:44 UTC by Masahiro Matsuya
Modified: 2017-12-20 05:48 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-09 16:50:26 UTC
deepak.prasad: needinfo?


Attachments (Terms of Use)

Description Masahiro Matsuya 2017-11-09 07:44:13 UTC
Description of problem:

When any problem related with NFS connection happens during installation with NFS repository, it's not possible even to enter the background shell with Ctrl-Alt-F2, meaning that it's not possible to debug the problem.

This situation is resolved by rd.live.ram boot parameter.
Without this parameter, the stage2 image in NFS share is used directly for configuring the root device without copying it into local. And, when any network issue happens or network is reconfigured, the whole stage2 environment can get unstable. And, we lose a way to debug it.

We have some customers having this kind of situation. One customer requested to enable it by default for using NFS repository.


Version-Release number of selected component (if applicable):
all of RHEL7 release

How reproducible:
Sometimes when NFS repository is used.

Steps to Reproduce:
No reliable reproducer internally.
But, a customer can reproduce it frequently.

Actual results:
When a problem happens, it cannot enter the background shell for debugging.

Expected results:
It can always enter the background shell with Ctrl-Alt-F2 and debug the problem. 

Additional info:
I requested to add 'rd.live.ram' boot parameter into installation guide in another bug:
  https://bugzilla.redhat.com/show_bug.cgi?id=1487001

Comment 1 Lukáš Nykrýn 2017-11-09 09:13:37 UTC
Shouldn't this be assigned to lorax instead? (Or what is the tool that creates the installation images)

Comment 2 Brian Lane 2017-11-09 16:50:26 UTC
This should not be added for all users. rd.live.ram copies the squashfs.img to RAM increasing the required space for boot which is not appropriate for all users.

Documentation is the correct way to handle this.

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

Comment 5 Deepak Prasad 2017-12-20 05:48:55 UTC
I had reported this issue and have some updates here just in case if it helps someone.

Although the other terminals at (F2, F3..) were becoming unresponsive although I was able to execute ip addr command.
With this in all the failed attempts I noticed the the client node looses the IPv4 address due to which the NFS mount becomes unresponsive

My environment
I have a TFTP + DHCP + NFS (single server) which hosts the kickstart and other files needed for installation.
Initially the IP for PXE is assigned via DHCP and later networks are configured using kickstart.

The setup is on VMware ESXi 5.1
When the issue occurs I notice that the node looses the IPv4 address which I feel is the problem since the NFS mount becomes unresponsive

To fix this I did below changes and everything looks be working fine till now
I add the IP, Netmask and gateway details in the PXE file as below

append initrd=rhel7_64/initrd.img ramdisk_size=65536 vga=no ip=192.169.141.2::192.169.141.254:255.255.255.0:blr105-adm02-b:eth0:none ksdevice=bootif ks=nfs:192.169.140.1://export/home/iserver/kickstart/blr105-adm02-b/kickstart.conf

The problem was seen mostly on ESXi 5.1 and 5.5

Although on ESXi 5.5 after using rd.live.ram in my PXE file the problem never appeared but on ESXi 5.1 environment the rd.live.ram also didn't worked

I would like to understand why this parameter fails on ESXi 5.1 environment


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