Thank you @wsapplegate for the contribution. Please test with the next rolling release.

Thank you @wsapplegate for the contribution. Please test with the next rolling release.

We should not emit any warning at all - this was caused by a bug in the remote-port implementation.

The above patch should fix the issue.

The above patch should fix the issue.

This patch should fix the issue.

Build Docker container two times on different machines (Linux host and macOS host) ... no problems detected. closing this.

Can't reproduce the issue using commit 217aa6afaeb of vyos-build repo

Hi yun, please open a new ticket with your issue, and make a reference to this case :)

Sorry comment on a resolved ticket, but i'm having the issue that is described in this issue. And i'm not sure how to fix it.

Also, there appear to be some leftovers from before 1.2 in dhclient-script@Line45, where vyatta-dns-forwarding.pl was removed in favour of dns_forwarding.py.

PR has been created.

@joshua Can you please create a PR in github for this please, then you can post the reference here. thanks.

This is resolvable via the following two fixes. Once they are implemented GCP should work as expected.

In order to fully fix cloud-init issues this patch needs to be applied so that /etc/resolv.conf can be updated by cloud-init before host_name.py generates final resolv.conf. Since cloud-init fires before VyOS scripts this is required so that GCE metadata can be retried by cloud-init on 1st boot.

Sorry I can't merge it, no write access for me.

@hagbard @UnicronNL, please make a new one PR. This is correct patch:

diff -Naur origin/dhclient-script pull2/dhclient-script
--- origin/dhclient-script	2019-05-15 19:32:59.001598203 +0300
+++ pull2/dhclient-script	2019-05-15 19:33:47.533181873 +0300
@@ -39,7 +39,6 @@
         echo " " > $new_resolv_conf
     fi

I don't have write access, I created a PR and assign the task to @UnicronNL to review and either merge or reject.

It's causing a few cloudinit log errors on GCP during 1st boot. We speculate that might be the cause of some of the issues getting an image running correctly on the 1st boot.

Does it cause issues? I'm about to remove it from the code, juts want to find out if it is something urgent.

Hi, @rob
It works! Thanks a lot. This case can be closed now.

We are closer to a resolution here, however, some legacy code references are causing issues with the 1st boot before our dhcp patches are effective. This code reference is in the dhclient-script being called by cloud-init on the 1st boot. With this failure cloud-init cannot hit the GCE data-source on the 1st boot causing some issues. This will require more work tomorrow, however, I feel a resolution is rather close.

can you describe your problem a little bit more.
I do something like this in some cases maybe it match on your use case:

Made some more progress, however, well either need to use the workaround for GCE images or come up with something more elegant that resolves the cloud-init behavior.

I made some progress here using the debug image, however, it looks like cloud-init is still starting a dhclient process that doesn't need to exist as part of it's fallback networking.

Changing squid_ldap_auth to basic_ldap_auth should be enough to fix the ldap part.

So you used /usr/lib/squid3/basic_ldap_auth? Then I‘m going to correct the scripts

this config worked as expected with Microsoft AD.

Once you verify if the module works I‘m happy to fix it.

yesterday i give up with it, i will try it again later and report it here.

Does it work as expected?

Will be in the next rolling available.

As a work around do either:

So is it considered a bug or works as intented?

Already fixed by @hagbard and deployed into current rolling release.

As per request from dmbaturin on slack:

Only when you create an address, can be via dhcp or manually.

If that is the only point, race conditions can occur. I assume this is only called when comitting or loading the config.

https://github.com/vyos/vyatta-cfg-system/blob/current/templates/interfaces/ethernet/node.tag/address/node.def#L10

When is host_name.py called? Maybe my dhcp server just responds slow and host_name.py is called before dhcp server responds? Is that possible?

I can't reproduce, tested live and installed.