** Changed in: linux (Ubuntu)
Status: New => Invalid
** Changed in: netplan.io (Ubuntu)
Status: New => Invalid
** Changed in: systemd (Ubuntu)
Status: New => Invalid
** Changed in: ubuntu-z-systems
Status: Incomplete => Fix Released
--
You received this bug
Hi Mario, thanks for coming back to this case.
So it seems that the situation is now good again - now that the
/etc/systemd/network/10-enP53p0s0.link got removed.
We don't know a tool or application offhand that would create such a .link file
in /etc/systemd/network/ alone.
However, there are
@Mario Did you had the chance to get the file stats of 10-enP53p0s0.link
and to try what Lukas suggested in comment #47?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
Before following Lukas' suggestions could you quickly do a:
stat /etc/systemd/network/10-enP53p0s0.link
(before deleting this file)
since this would give us the creation / modification time
and potentially (with some log correlation)
this may provide a hint when and why it was created.
--
You
Thank you! The core problem still is that systemd-networkd does not find
any .link and .network file for the enP53p0s0.171 interface, that's why
it cannot apply any configuration (IP address):
> ? 9: enP53p0s0.171
> Link File: n/a
> Network File: n/a
This might very well be related to the
> Gave some time between netplan apply and check without success, I can leave
> it for
> hours and the IP never gets assigned
Indeed, I cannot see it being assigned an IPv4 address in your latest
"_delay" run. (Well, there is some assignment of an IP to enP53p0s0.171
at 15:05:29 in the journal
After crushing the logs a bit more, I found a few interesting things and
also have a few open questions. Thank you very much for your `date`
timestamps in between the different steps, those are very helpful in
linking the order of events!
Open questions:
1) The "udevadm-monitor.txt" log shows
No, I think we cannot gather much more data and logs than we already did.
(Except the ude rules themselves, but they will not change with a kernel
update.)
I am relatively confident that this is not an netplan issue since I verified
the files in /run/systemd/network/ and the look good and fit
** Tags added: fr-1459
--
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/1929657
Title:
[Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x)
Status in Ubuntu on
** Changed in: systemd (Ubuntu)
Assignee: (unassigned) => Canonical Foundations Team
(canonical-foundations)
--
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/1929657
Thanks Mario the output is helpful, especially in combination with the
time indices.
So udev does not seem to be able to complete the initialization of
enP53p0s0.171:
"
Jun 14 08:12:10 ilabg13.tuc.stglabs.ibm.com systemd-networkd[4102292]:
enP53p0s0.171: link pending udev initialization...
"
** Tags removed: targetmilestone-inin---
** Tags added: targetmilestone-inin2004
--
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/1929657
Title:
[Ubuntu 20.4.2] vLan not
I should have added that it would be best in this case to have the debug mode
enabled for udevd, too:
$ cat /etc/systemd/system/systemd-udevd.service.d/override.conf
[Service]
Environment=SYSTEMD_LOG_LEVEL=debug
$ sudo systemctl daemon-reload && sudo systemctl restart systemd-udevd
$ journalctl
Ok, the line that concerns me is:
"
enP53p0s0.171: link pending udev initialization...
"
It looks like systemd-networkd thinks that udev is not done with
enP53p0s0.171 --> "pending", but configuring it with ip works - so could
be networkd or also udevd.
So lets expand the journal output with the
14 matches
Mail list logo
