Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix for issue#574 onie-discovery-stop does not kill the entire discov… #829

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

sharma-lakesh
Copy link

…ery process immediately

Addition of pkill in discovery stop function is as per the email thread listed in jira.

In function config_ethmgmt_fallback, added code to prevent onie from over-riding the user assigned IP
address with default one after discovery-stop, as pkill usually takes some time.
With these changes, the recommend sequence is:

  1. onie-discovery-stop
  2. assign manual IP address to management i/f.

…ery process immediately

Addition of pkill in discovery stop function is as per the email thread listed in jira.

In function config_ethmgmt_fallback, added code to prevent onie from over-riding the user assigned IP
address with default one after discovery-stop, as pkill usually takes some time.
With these changes, the recommend sequence is:

1. onie-discovery-stop
2. assign manual IP address to management i/f.
@ehdoyle
Copy link
Collaborator

ehdoyle commented May 10, 2019

Hi
Can you supply a description of how you were able to replicate the problem before fixing it? I'm having trouble replicating the behavior.

I tried it using the kvm image build (make MACHINE=kvm_x86_64 all recovery.iso ), set up with the instructions described here:
https://github.com/opencomputeproject/onie/blob/master/machine/kvm_x86_64/INSTALL

I :
booted from the iso image,
embedded ONIE on the virtual disk,
rebooted off of the virtual disk,
and ran the Image install option in ONIE
...and it looked like the existing stop worked, as follows:

Running a 'ps -w' when it is looking for an image to install, shows:
423 root 3560 S {discover} /bin/sh /bin/discover
698 root 3456 S ping6 -I eth0 -c 3 ff02::1

and after onie-discovery-stop, both are gone.

However:
I'm not seeing the following running, which were reported in the original ticket:
1738 root 7536 S {networking.sh} /bin/sh /etc/init.d/networking.sh
di
1778 root 7476 S udhcpc -q -S -V onie_vendor:x86_64-kvm_x86_64-r0-x
... which makes me think I'm not replicating the circumstances correctly ( although apparently Curt had some difficulty with this too.)

And just to get all the related information in one place:
The ticket being addressed ( and thank you for this ) is 574
#574
and it references the discussion here:
http://lists.opencompute.org/pipermail/opencompute-onie/2017-August/001497.html

Thanks!

@sharma-lakesh
Copy link
Author

One of essential step to recreate the issue listed here, is to have a system in a network , where DHCP is not enabled. Here are the steps, which matches the logs/sequence listed mail discussion of http://lists.opencompute.org/pipermail/opencompute-onie/2017-August/001497.html

  1. Make sure that the DHCP is not enabled in n/w.
  2. Boot into install or update mode, so that discovery process starts.
  3. After message "Info: Trying DHCPv4 on interface: eth0" is displayed, and onie drops to prompt, then
    stop discovery and try to assign manual IP.

ONIE:/ # onie-discovery-stop

ONIE:/ # ifconfig eth0 192.168.1.1

  1. After few seconds, you will notice following messages.
    ONIE:/ # Warning: Unable to configure interface using DHCPv4: eth0
    ONIE: Using link-local IPv4 addr: eth0: 169.254.143.76/16

At this point, the manual IP you assigned in step 3 is over-written by default link-local assigned by ONIE discovery process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants