Hello Thomas,

And thank you for submitting this patch.

We have had a couple of bug reports about this before and I think I had proposed a similar solution which was never confirmed to work by the person who reported the bug.

I agree that this is a bug, but do we not want to set the tries to something higher than 1? Just in case the network isn’t fully up yet?

I would say that we can decrease the timeout because the service is usually running on the same host and either responds immediately (less than a couple of milliseconds) or not at all. So 3 seconds and three tries is something that would give you the same timeout but hopefully has a better chance to get a response if the network isn’t up, yet.

Does that sound good to you?

-Michael

On 31 Mar 2021, at 23:42, Thomas Cekal admin@cekal.org wrote:

Fix for Bug 12445: There is no proper way to distinguish between MS Azure and a local Hyper-V installation Procedure: try to get the metadata info from the internal MS metadata service at IP 169.254.169.254 If this fails the system is running on an local Hyper-V instance wget takes too long to exit if the IP is not reachable Added --timeout and --tries param to wget to reduce the duation from 8 minutes to 10 seconds 10 seconds at one try should be enough Signed-off-by: Thomas Cekal admin@cekal.org

---

src/initscripts/helper/azure-setup | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/initscripts/helper/azure-setup b/src/initscripts/helper/azure-setup index 5157712fc..a0d547588 100644 --- a/src/initscripts/helper/azure-setup +++ b/src/initscripts/helper/azure-setup @@ -9,7 +9,7 @@ export PATH=/usr/local/sbin:/usr/local/bin:${PATH} get() { local file="${1}"

• wget -qO - --header="Metadata:true" "http://169.254.169.254/metadata/instance/$%7Bfile%7D?api-version=2019-06-01&..."

• wget --timeout=10 --tries=1 -qO - --header="Metadata:true" "http://169.254.169.254/metadata/instance/$%7Bfile%7D?api-version=2019-06-01&..."

}

format_mac() {

2.17.1