[Bug 1990585] Re: cloud-net fails when DHCP slow

Greg Lee 1990585 at bugs.launchpad.net
Thu Sep 29 21:49:16 UTC 2022


Hi Chad,

I reviewed the bug report that you cited.  It appears to be the same or
related.

The bug I encountered began with appending the following command to the
kernel in Grub:

autoinstall ds=nocloud-net\;s=
https://raw.githubusercontent.com/cwru-robotics/cwru_robotics_autoinstall_scripts/focal_install/ros-noetic-desktop-full/


So I believe it is no-cloud based.  (I am not particularly well versed as
to which package does explicitly what at the level of granularity.)

The cloud-init.log showed the attempt to download the meta-data file failed
ten times in rapid succession (no change in the timestamps for each attempt
in the log).  The error message for failing to retrieve meta-data in the
cloud-init.log were from url-helper.py.  The syslog.log file showed that
the network interface received its IP address at a time stamp after the
download failures.  I was able to manually retrieve the meta-data file
using wget as a way to verify the files were accessible from the computer.
The script works fine on a virtual machine that gets its IP address
immediately.

It will likely take me a while to get the logs since the hardware is with
students right now.  (This is part of a senior project.)  I hope this is
adequate, if imperfect, information to proceed fixing the bug.

Thanks,

Greg





On Wed, Sep 28, 2022 at 2:55 PM Chad Smith <1990585 at bugs.launchpad.net>
wrote:

> Thanks for filing this bug Greg and making cloud-init and subiquity
> better. It looks to me reminiscent of LP: #1990149 which is that the
> nocloud-net doesn't wait for the configured nocloud datasource to be
> visible, nor retry if it is not yet there.
>
> Greg, can you confirm that the autoinstall path you are providing to
> your machine is nocloud-based?
>
> It would be helpful to either attach the tar gz from running `cloud-init
> collect-logs` or minimally provide /var/log/cloud-init.log from the
> system on which things failed just so we can confirm it's the same
> failure mode as the other bug linked.
>
> I'm setting the bug status to 'Incomplete' and agree it's probably a
> cloud-init problem, not subiquity but please set this bug status back to
> 'New' for cloud-init when you'd like to have us glance again at this
> issue.
>
> ** Changed in: cloud-init (Ubuntu)
>        Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1990585
>
> Title:
>   cloud-net fails when DHCP slow
>
> Status in cloud-init package in Ubuntu:
>   Incomplete
> Status in subiquity package in Ubuntu:
>   Invalid
>
> Bug description:
>   During a cloud-init autoinstall with Ubunutu Focal Server 20.04, the
>   attempts to retrieve the meta-data file fail immediately with no
>   timeout as indicated in the cloud-init.log.  According to the system
>   logs, the network does not receive an IP address until after the
>   attempt to retrieve the meta-data file.  The DHCP in the facility is
>   known to be a little slow.
>
>   It is possible to retrieve the file by switching to a second virtual
>   terminal and downloading it with wget (after the failure of the cloud-
>   init).  It appears that the url_helper.py function reporting the
>   failure to retrieve the files does not wait for any timeout period
>   when the network is not yet present.
>
>   Possible solution?  Adding a check with a timeout of a few seconds for
>   the network being available before moving to download the meta-data
>   and user-data files.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1990585/+subscriptions
>
>

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to subiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1990585

Title:
  cloud-net fails when DHCP slow

Status in cloud-init package in Ubuntu:
  Incomplete
Status in subiquity package in Ubuntu:
  Invalid

Bug description:
  During a cloud-init autoinstall with Ubunutu Focal Server 20.04, the
  attempts to retrieve the meta-data file fail immediately with no
  timeout as indicated in the cloud-init.log.  According to the system
  logs, the network does not receive an IP address until after the
  attempt to retrieve the meta-data file.  The DHCP in the facility is
  known to be a little slow.

  It is possible to retrieve the file by switching to a second virtual
  terminal and downloading it with wget (after the failure of the cloud-
  init).  It appears that the url_helper.py function reporting the
  failure to retrieve the files does not wait for any timeout period
  when the network is not yet present.

  Possible solution?  Adding a check with a timeout of a few seconds for
  the network being available before moving to download the meta-data
  and user-data files.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1990585/+subscriptions




More information about the foundations-bugs mailing list