** Tags removed: foundations-todo
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2008952
Title:
DNS failure while trying to fetch user-data
Status in cloud-init:
Fix Re
** Changed in: subiquity
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2008952
Title:
DNS failure while trying to fetch user-data
Status in
My understanding from a quick read is that there is nothing to do in
systemd. Please re-open if I am mistaken.
** Changed in: systemd (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to syst
Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/4085
** Bug watch added: github.com/canonical/cloud-init/issues #4085
https://github.com/canonical/cloud-init/issues/4085
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
Closing the cloud-init task here as invalid because we have livecd-
rootfs overlay config files allow for cloud-init.service to get ordered
After=NetworkManager.service which solves the immediate DNS issues in
early boot. Long-term cloud-init will need to spec out options to prefer
ordering after N
I can confirm success manually launching images via kvm in virt-manager
that live desktop image builds as of 20230403 images in
`/cdrom/.disk/info` have the proper systemd service ordering which
places cloud-init.service `After=NetworkManager.service NetworkManager-
wait-online.service`. Which allo
I can now confirm successful autoinstall runs with FQDN in kernel
commandline in Desktop live installer ISOs dated 20230403. This allows
cloud-init.service to be ordered `After=NetworkManager.service
NetworkManager-wait-online.service` which ensures devices and resolved
are both 'up' and active by
This bug was fixed in the package livecd-rootfs - 2.817
---
livecd-rootfs (2.817) lunar; urgency=medium
[ John Chittum ]
* revert ipc change. kernel 6.2 will have the correct setting
-- Steve Langasek Mon, 27 Mar 2023
12:11:06 -0700
** Changed in: livecd-rootfs (Ubuntu)
jsonschema 2.6.0 is now dropped from latest ubuntu-desktop-snap version
0+get.98600e08 in stable channel as of a couple hours ago per this
issue/fix[1]. This resolves issues with curtin Tracebacks on
jsonschema.validate(). Additionally cloud-init has a PR in progress[2]
to avoid registering a stric
What a mess!
I have uploaded the livecd-rootfs change proposed by Chad in #26. Note
that there is another problem around jsonschema exposed by this that is
in progress.
** Also affects: livecd-rootfs (Ubuntu)
Importance: Undecided
Status: New
** Changed in: livecd-rootfs (Ubuntu)
** Changed in: cloud-init
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2008952
Title:
DNS failure while trying to fetch user-data
PR up for discussion on this ordering change in livecd
https://code.launchpad.net/~chad.smith/livecd-rootfs/+git/livecd-
rootfs/+merge/439586
** Changed in: cloud-init
Assignee: (unassigned) => Chad Smith (chad.smith)
--
You received this bug notification because you are a member of Ubuntu
** Merge proposal linked:
https://code.launchpad.net/~chad.smith/livecd-rootfs/+git/livecd-rootfs/+merge/439586
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2008952
Ti
Short-term proposal update:
Looks like we can't get away with suppplemental systemd drop-ins in
/etc/systemd/system/cloud-init.service.d by themselves in livecd-roots because
we need to remove the "Before=sysinit.target" from the default shipped
cloud-init.service config. Systemd drop-ins are
Short-term solution here will likely be for livecd-rootfs to augment
cloud-init.service which drops `Before=sysinit.target` and adds an
`After=NetworkManager-wait-online.service`. This is quite a bit like
what redhat and derivatives have done for a while. Redhat and
derivitatives have an `After=Net
While retries on DNS resolution failures does not work for cloud-
init.service for environments running NetworkManager.service (desktop
live ISOs), I have found that the retries work where systemd-networkd is
bringing up network config (server live ISOs). This is because cloud-
init.service is Afte
This issue with NetworkManager.service and systemd is reminiscent of the
related feature request against systemd-networkd
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636912 that also
points out the ordering issues.
--
You received this bug notification because you are a member of Ubun
TLDR: My earlier suggestion to retry in cloud-init.service while
awaiting DNS is not viable when thinking about NetworkManager.
NetworkManager.service is After=sysinit.target due to After=dbus.service
and cloud-init.service is Before=sysinit.target. NetworkManager is the
only service bringing up th
I can confirm Dan's validation that After=systemd-resolved.service doesn't buy
us anything here because, although systemd-resolved.service is up,
NetworkManager.service && NetworkManager-wait-online.service don't finish
bringing link up for related network devices until After=dbus.service
timef
I'm also going back to the tabular network state printed out by in
cloud-init.service shows: that the primary network interface is still
down at this point in boot, which it shouldn't be. cloud-init should be
waiting on the presence of link up before starting it's cloud-
init.service (network boot
Thank you all for your attention on this bug.
Sorry my earlier comment on this bug was ill-informed and incorrect. I'm able
to reproduce this as well through the server installer qemu/kvm based installs
as well so I can confirm as well that this isn't/wasn't NetworkManager and
systemd-networkd
I played with a two variation of dropping in some after directives, but
obtained similar failing results where the network state was not what
cloud-init wanted at the time it started.
@Chad - what's your thoughts on some service reordering?
--
You received this bug notification because you are a
FWIW you can test this out by adding a drop-in config:
$ cat > /etc/systemd/system/cloud-init.service.d/10-after-systemd-resolved.conf
<< EOF
[Service]
After=systemd-resolved.service
EOF
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is sub
It appears we have the following *ordering* relationship between
systemd-resolved.service, cloud-init.service, network.target, and
network-online.target:
network-online.target
/ \
/.. \
/.\
** Attachment added: "cloud-init.log"
https://bugs.launchpad.net/cloud-init/+bug/2008952/+attachment/5654393/+files/cloud-init.log
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.n
I attached some logs that might be useful. After checking it again I
realized that the syslog timestamps are a little off when compared to
the systemd journal.
As shown in the timeline.txt (attached), cloud-init and systemd-resolved
are starting at the same time.
So the name resolution might not
** Attachment added: "timeline.txt"
https://bugs.launchpad.net/cloud-init/+bug/2008952/+attachment/5654394/+files/timeline.txt
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/b
** Attachment added: "systemd_journal.txt"
https://bugs.launchpad.net/cloud-init/+bug/2008952/+attachment/5654392/+files/systemd_journal.txt
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.l
** Changed in: netplan
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2008952
Title:
DNS failure while trying to fetch user-data
Status in c
Maybe we need some additional systemd service ordering, to make systemd-
resolved start before calling into the DHCP client, so that it can
properly receive the DNS servers.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to syst
As /etc/resolv.conf is a symlink, is it possible that the nameservers
received via DHCP in the early boot stages are never stored in
/etc/resolv.conf?
cloud-init tries to resolve that address before resolved is started and
there is nothing at /etc/resolv.conf.
Does that make sense?
--
You recei
It doesn't seem to be caused by a race between networkd and
NetworkManager.
I reproduced the issue with qemu here and I see the name resolution
failure happening few seconds before NetworkManager started.
>From /var/log/cloud-init.log:
2023-03-09 19:17:58,443 - util.py[DEBUG]: Getting data from
01-network-manager-all.yaml seems to be shipped by livecd-rootfs
** Changed in: netplan
Assignee: (unassigned) => Danilo Egea Gondolfo (danilogondolfo)
** Tags removed: rls-ll-incoming
** Tags added: foundations-todo
--
You received this bug notification because you are a member of Ubuntu
> So I wonder what is the exact sequence of events for running the
Netplan generator (by systemd), installing the 50-cloud-init.yaml file
(by cloud-init), installing the 01-network-manager-all.yaml file (by the
installer?), executing `netplan apply` (by cloud-init).
By the time Subiquity has start
So while this bug talks about netboot, I think it isn't necessary to
involve that for testing purposes. I suggest simply booting the desktop
daily-live with the nocloud kernel command line listed above and seeing
how things go. Are the various network tools doing what we expect?
Note that gnome-
I disagree with comment #1
/etc/netlan/01-network-manager-all.yaml and /etc/netplan/50-cloud-
init.yaml should not be in conflict with each other, but will be merged
by Netplan to produce the following configuration:
```yaml
network:
version: 2
renderer: NetworkManager
ethernets:
enp0s2
** Tags added: rls-ll-incoming
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2008952
Title:
DNS failure while trying to fetch user-data
Status in cloud-init:
Triaged
S
Looking at the desktop ISOs, while the system is configured with Netplan
to use NetworkManager, there seems to be some conflict here where
systemd-networkd is trying to interact with the device. Some feedback
would be appreciated. The practical result is that early boot cloud-
init is not able to
38 matches
Mail list logo
