[Bug 1969365] [NEW] focal: backport kexec fallback patch
Public bug reported: It would be great if focal's systemd could have https://github.com/systemd/systemd/commit/71180f8e57f8fbb55978b00a13990c79093ff7b3 backported to it. [Impact] We have observed that kexec'ing to another kernel will fail as the drive containing the `kexec` binary has been unmounted by the time systemd attempts to do so, indicated in the console: Starting Reboot via kexec... [ 163.960938] shutdown[1]: (sd-kexec) failed with exit status 1. [ 163.963463] reboot: Restarting system [Test Plan] 1) Launch a 20.04 instance 2) `apt-get install kexec-tools` 3) In `/boot`, filling in whatever needed in your environment: kexec -l vmlinuz --initrd initrd.img --append '' 4) `reboot` (I have reproduced this in a single-disk VM, so I assume it reproduces ~everywhere: if not, `apt-get remove kexec-tools` before the `reboot` could be used to emulate the unmounting.) [Where problems could occur] Users could inadvertently be relying on the current behaviour: if they have configured their systems to kexec, they currently will be rebooting normally, and this patch would cause them to start actually kexec'ing. [Other info] We're currently maintaining a systemd tree with only this patch added to focal's tree: this patch has received a bunch of testing from us in focal. This patch landed in v246, so it's already present in supported releases later than focal. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1969365 Title: focal: backport kexec fallback patch To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1969365/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1930914] Re: ubuntu-minimal depends on ubuntu-advantage-tools
I would also like to see this change: * ubuntu-advantage-tools and its dependencies add about 3MB to ubuntu-minimal installations (checked by installing ubuntu-minimal's Depends in a Docker container with and without u-a-t) * it installs a systemd timer which runs (to do nothing, as the service it runs is disabled without ua-auto-attach.service present) * it installs MOTD hooks, which run regularly * it installs an apt hook, which is executed on every update and upgrade, and twice on installs If one is not interested in UA services, these are wasted resources, and provide an incentive to remove ubuntu-minimal from systems. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1930914 Title: ubuntu-minimal depends on ubuntu-advantage-tools To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1930914/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1948713] [NEW] focal: backport patch to allow mk-sbuild within Docker
Public bug reported: Debian bug #968927 is present in the version of debootstrap in focal, which means that mk-sbuild cannot execute successfully within a Docker environment. https://salsa.debian.org/installer- team/debootstrap/-/commit/87cdebbcad6f4e16ba711227cbbbd70039f88752 is the fix for this. It's included in the version of debootstrap in impish+, and we've been using a patched debootstrap (including only this patch on top of focal's debootstrap) for a couple of months without issue. [Impact] Without this patch, using debootstrap via mk-sbuild within a Docker environment produces this error: ln: failed to create symbolic link '/dev/stdin': File exists E: 10mount: E: Failed to open mount file ‘/proc/mounts’: No such file or directory E: focal-amd64-6433640d-7654-4238-b872-e8f1acd4b717: Chroot setup failed: stage=setup-stop This means that Ubuntu users either have to perform their mk-sbuild'ing outside of Docker (which may not be possible in corporate settings), or they have to maintain debootstrap downstream of Ubuntu (which either requires superseding the versions in Ubuntu entirely, or rebasing this patch onto the new version which appears in focal as each new release is opened). [Test Plan] Launch a Docker container (privileged so mk-sbuild can perform overlay mounting) with: docker run --privileged -it --rm ubuntu:focal and then within the container: apt-get update apt-get install ubuntu-dev-tools sbuild # Convince mk-sbuild to run as root touch /root/.sbuildrc usermod -a -G sbuild root newgrp sbuild # Run mk-sbuild mk-sbuild focal After much output, the above-described error will be output. Using a patched debootstrap causes the mk-sbuild to complete successfully. Regression testing of regular use of debootstrap (outside of Docker, as used in Ubuntu's image building) should be performed: the image content should be unchanged. [Where problems could occur] debootstrap is a fundamental piece of the Debian/Ubuntu image building infrastructure, and any change to it could have an impact on how Ubuntu images are built. ** Affects: debootstrap (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1948713 Title: focal: backport patch to allow mk-sbuild within Docker To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1948713/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1948713] Re: focal: backport patch to allow mk-sbuild within Docker
** Patch added: "lp1948713.debdiff" https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1948713/+attachment/5536032/+files/lp1948713.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1948713 Title: focal: backport patch to allow mk-sbuild within Docker To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1948713/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1927005] [NEW] /etc/default/mdadm refers to non-existent /etc/cron.* files
Public bug reported: To quote: # AUTOCHECK: # should mdadm run periodic redundancy checks over your arrays? See # /etc/cron.d/mdadm. AUTOCHECK=true # AUTOSCAN: # should mdadm check once a day for degraded arrays? See # /etc/cron.daily/mdadm. AUTOSCAN=true Neither /etc/cron.d/mdadm nor /etc/cron.daily/mdadm exist (having been converted to systemd timers at some point, I believe). ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: mdadm 4.1-10ubuntu3 ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12 Uname: Linux 5.11.0-16-generic x86_64 ApportVersion: 2.20.11-0ubuntu65 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Mon May 3 20:18:03 2021 MachineType: Gigabyte Technology Co., Ltd. B450M DS3H ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.11.0-16-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off ProcMDstat: Personalities : unused devices: SourcePackage: mdadm UpgradeStatus: No upgrade log present (probably fresh install) acpidump: dmi.bios.date: 01/25/2019 dmi.bios.release: 5.13 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F4 dmi.board.asset.tag: Default string dmi.board.name: B450M DS3H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: B450M DS3H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. etc.blkid.tab: Error: [Errno 2] No such file or directory: '/etc/blkid.tab' initrd.files: Error: [Errno 2] No such file or directory: '/boot/initrd.img-5.11.0-16-generic' ** Affects: mdadm (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug impish uec-images -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1927005 Title: /etc/default/mdadm refers to non-existent /etc/cron.* files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1927005/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922739] Re: AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw'
For hirsute, the bug does not reproduce on upgrade from the release day image. However, it can present when upgrading between releases. To test, I launched a groovy instance with an old cloud-init (the same image as previously for groovy validation). I performed a `do-release-upgrade -d` (-d, as upgrades to hirsute are not yet enabled) and rebooted: I saw the Traceback from this bug, as expected. I then launched another groovy instance, performed another release upgrade but, before rebooting, installed cloud-init from hirsute- proposed. On reboot, I then did not see the Traceback for this bug. ** Tags added: verification-done-hirsute -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1922739 Title: AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw' To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1922739/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1900904] Re: netplan yaml for rpi groovy server prevents usb ethernet
In the cloud-init log, I see:
2021-04-19 06:58:24,455 - stages.py[DEBUG]: applying net config names for
{'version': 2, 'ethernets': {'eth0': {'match': {'driver': 'bcmgenet smsc95xx
lan78xx'}, 'set-name': 'eth0', 'dhcp4': True, 'optional': True}}}
2021-04-19 06:58:24,456 - __init__.py[DEBUG]: no interfaces to rename
"driver" there can't be a space-separated list: netplan expects it to be
a single item (though globs are permitted):
https://github.com/canonical/netplan/blob/master/netplan/cli/utils.py#L215
I think what's happening is that, because there is no longer an "eth0"
interface in the system, cloud-init/netplan are using the match clause
(whereas previously they would just have identified that they already
_had_ eth0). It doesn't find an interface using the driver named
"bcmgenet smsc95xx lan78xx" (of course, as that's three driver names
concatenated together), so it (correctly) concludes that there is no
config that matches NICs in this system and proceeds under that
assumption.
So: I think this is somewhere between a bug in that network
configuration and a feature request in netplan (and therefore cloud-
init), to update the semantics of the driver clause to support matching
on multiple drivers somehow.
Does that sound right? (I'll move this to Incomplete, please do move
this back to New once you've responded!)
** Changed in: cloud-init (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1900904
Title:
netplan yaml for rpi groovy server prevents usb ethernet
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1900904/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1925526] Re: Hirsute/Azure: cloud-init-local sometimes very slow to initialize
An alternative explanation: Azure has a pre-provisioning system, whereby they'll partially boot a machine and then hold it in that state until a user requests a system which corresponds. This is implemented using the netlink socket you see: the fabric will reconnect that socket once it is ready for cloud-init to continue. So: this logging is not unexpected, it indicates a pre-provisioned VM. Are you seeing an actual 3m30 wait happen when you launch instances, or is this report based only this logging? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1925526 Title: Hirsute/Azure: cloud-init-local sometimes very slow to initialize To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1925526/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922739] Re: AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw'
For xenial, I'm performing the same process but with the `ubuntu:bb8e87956495` image, serial of 20201210. UPGRADE does fail: $ CLOUD_INIT_OS_IMAGE=ubuntu:bb8e87956495::ubuntu::xenial CLOUD_INIT_CLOUD_INIT_SOURCE=UPGRADE pytest tests/integration_tests/test_upgrade.py::test_subsequent_boot_of_upgraded_package ... FAILED tests/integration_tests/test_upgrade.py::test_subsequent_boot_of_upgraded_package - assert False $ CLOUD_INIT_OS_IMAGE=ubuntu:bb8e87956495::ubuntu::xenial CLOUD_INIT_CLOUD_INIT_SOURCE=PROPOSED pytest tests/integration_tests/test_upgrade.py::test_subsequent_boot_of_upgraded_package ... PASSED ** Tags removed: verification-needed verification-needed-xenial ** Tags added: verification-done verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1922739 Title: AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw' To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1922739/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922739] Re: AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw'
For bionic, I'm performing the same process but with the `ubuntu:c2bdb694ecc2` image, serial of 20201211.1. UPGRADE does fail: $ CLOUD_INIT_OS_IMAGE=ubuntu:c2bdb694ecc2::ubuntu::bionic CLOUD_INIT_CLOUD_INIT_SOURCE=UPGRADE pytest tests/integration_tests/test_upgrade.py::test_subsequent_boot_of_upgraded_package ... FAILED tests/integration_tests/test_upgrade.py::test_subsequent_boot_of_upgraded_package - assert False $ CLOUD_INIT_OS_IMAGE=ubuntu:c2bdb694ecc2::ubuntu::bionic CLOUD_INIT_CLOUD_INIT_SOURCE=PROPOSED pytest tests/integration_tests/test_upgrade.py::test_subsequent_boot_of_upgraded_package ... PASSED ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1922739 Title: AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw' To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1922739/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922739] Re: AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw'
For focal, I'm performing the same process but with the `ubuntu:b321e3832dbb` image, serial of 20201210. UPGRADE does fail: $ CLOUD_INIT_OS_IMAGE=ubuntu:b321e3832dbb::ubuntu::focal CLOUD_INIT_CLOUD_INIT_SOURCE=UPGRADE pytest tests/integration_tests/test_upgrade.py::test_subsequent_boot_of_upgraded_package ... FAILED tests/integration_tests/test_upgrade.py::test_subsequent_boot_of_upgraded_package - assert False and PROPOSED passes: $ CLOUD_INIT_OS_IMAGE=ubuntu:b321e3832dbb::ubuntu::focal CLOUD_INIT_CLOUD_INIT_SOURCE=PROPOSED pytest tests/integration_tests/test_upgrade.py::test_subsequent_boot_of_upgraded_package ... PASSED -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1922739 Title: AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw' To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1922739/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922739] Re: AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw'
For groovy, I'm testing with the `ubuntu:bac1692e9ec7` image, with a serial of 20201210. First, I confirm that the test does trigger the bug on UPGRADE to the version of cloud-init in the release: $ CLOUD_INIT_OS_IMAGE=ubuntu:bac1692e9ec7::ubuntu::groovy CLOUD_INIT_CLOUD_INIT_SOURCE=UPGRADE pytest tests/integration_tests/test_upgrade.py::test_subsequent_boot_of_upgraded_package ... FAILED tests/integration_tests/test_upgrade.py::test_subsequent_boot_of_upgraded_package - assert False and I then verify that the same test passes with the package in groovy- proposed: $ CLOUD_INIT_OS_IMAGE=ubuntu:bac1692e9ec7::ubuntu::groovy CLOUD_INIT_CLOUD_INIT_SOURCE=PROPOSED pytest tests/integration_tests/test_upgrade.py::test_subsequent_boot_of_upgraded_package ... PASSED ** Tags removed: verification-needed-groovy ** Tags added: verification-done-groovy -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1922739 Title: AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw' To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1922739/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922739] Re: AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw'
I'm performing verification of this locally using the cloud-init
integration testing framework. Specifically, I'm running
test_upgrade_package[0] with the following diff applied (to trigger this
bug):
@@ -104,18 +104,19 @@ def test_upgrade(session_cloud: IntegrationCloud):
@pytest.mark.ci
@pytest.mark.ubuntu
-def test_upgrade_package(session_cloud: IntegrationCloud):
-if get_validated_source(session_cloud) != CloudInitSource.DEB_PACKAGE:
-not_run_message = 'Test only supports upgrading to build deb'
+def test_subsequent_boot_of_upgraded_package(session_cloud: IntegrationCloud):
+source = get_validated_source(session_cloud)
+if not source.installs_new_version():
if os.environ.get('TRAVIS'):
# If this isn't running on CI, we should know
-pytest.fail(not_run_message)
+pytest.fail(UNSUPPORTED_INSTALL_METHOD_MSG.format(source))
else:
-pytest.skip(not_run_message)
+pytest.skip(UNSUPPORTED_INSTALL_METHOD_MSG.format(source))
+return # type checking doesn't understand that skip raises
launch_kwargs = {'image_id': session_cloud.released_image_id}
with session_cloud.launch(launch_kwargs=launch_kwargs) as instance:
-instance.install_deb()
+instance.install_new_cloud_init(source, take_snapshot=False,
clean=False)
instance.restart()
assert instance.execute('cloud-init status --wait --long').ok
The important changes here are that I can run it against both the
release pocket and -proposed, and that it doesn't perform a clean any
longer. I'll propose these changes to cloud-init upstream after
validation is complete.
[0] https://github.com/canonical/cloud-
init/blob/master/tests/integration_tests/test_upgrade.py#L105-L121
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1922739
Title:
AttributeError: 'DataSourceNoCloud' object has no attribute
'vendordata2_raw'
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1922739/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1921515] [NEW] `SyntaxError` when byte-compiling during `do-release-upgrade` to hirsute
Public bug reported: When performing a `do-release-upgrade -d` on my groovy system, I saw: Setting up python3-software-properties (0.99.8) ... Failed to byte-compile /usr/lib/python3/dist-packages/softwareproperties/extendedsourceslist.py: File "/usr/lib/python3/dist-packages/softwareproperties/extendedsourceslist.py", line 436 def __init__(self, sourceslist=None, /, files=None): ^ SyntaxError: invalid syntax (expected ')') ** Affects: software-properties (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1921515 Title: `SyntaxError` when byte-compiling during `do-release-upgrade` to hirsute To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1921515/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1916684] Re: [FFe] OVS fix duplicate mac address failures on bonds
Thanks for the reply, Łukasz: we agree, this is a bugfix so doesn't need an FFe. ** Changed in: cloud-init (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1916684 Title: [FFe] OVS fix duplicate mac address failures on bonds To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1916684/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
On Tue, Mar 23, 2021 at 07:53:59AM -, Alfonso Sanchez-Beato wrote: > Is this going to be backported to focal (see LP: #1919493)? Yep, the SRU process has been started already. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1912844 Title: Bond with OVS bridging RuntimeError: duplicate mac found! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905493] Re: cloud-init status --wait hangs indefinitely in a nested lxd container
Yep, that's what I've found; cloud-init is just waiting for its later stages to run, which are blocked by snapd.seeded.service exiting. ** Changed in: cloud-init Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905493 Title: cloud-init status --wait hangs indefinitely in a nested lxd container To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1905493/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905493] Re: cloud-init status --wait hangs indefinitely in a nested lxd container
Given that the logind issue is an AppArmor issue and, per my previous comment, "the two running jobs are systemd-logind.service and snapd.seeded.service", I suspect that we'll find that snapd is running into similar sorts of issues. I'll take a quick look now. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905493 Title: cloud-init status --wait hangs indefinitely in a nested lxd container To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1905493/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
> Interfaces of type 'internal' may be used for other things than VLANs so depending on what you want to match on it may or may not be precise enough. So the cloud-init code in question is used in a couple of (relevant) ways: (a) to determine the state of any physical interfaces for which we should wait before proceeding to apply network configuration to the system (intended for the case where network devices have not yet been detected by the kernel, for a variety of reasons), and (b) to determine the current system state when renaming any such interfaces to match the specified network configuration. The code in question is iterating through every interface in the system (as determined from /sys/class/net) and determining if it should be included in this set. For reference, the code excludes bridges, VLANs, bonds, any device that has a `/master` symlink that isn't a bridge/bond member, NET_FAILOVER devices, devices without a MAC, devices with a "stolen" MAC, and, on some clouds, interfaces owned by a particular device driver (the one case I recall is for Mellanox interfaces on Azure). We're looking to answer the question of "is this interface one that cloud-init needs to know about", so I think what we want is to exclude any OVS interface that doesn't originate from the system: OVS will handle naming non-system interfaces correctly and we know that, even if currently absent, they will be present once "needed" (because OVS will create them). > Interfaces of type 'dpdk' would probably be invisible from the kernel > sysfs and netlink interfaces pov, interfaces of type 'system' have > their origin in the system and cloud-init would most likely already > know all about them. Interfaces of type 'internal' may be used for > other things than VLANs so depending on what you want to match on it > may or may not be precise enough. This suggests to me that internal interfaces _are_ the right ones exclude. I considered excluding _all_ non-"system" interfaces, but in the example config we've been using here, I see: # ovs-vsctl --columns type find interface name=bond0 type: "" We'd exclude the bond0 interface anyway (for being a bond) but it makes me wonder if there are other interfaces that we _wouldn't_ otherwise exclude that won't have type=system. To avoid having to answer that, I think we can safely limit this to internal interfaces (as addressing this problem, and likely a class of related ones) and if we find cases that this doesn't cover then we can drive the required changes at that point. > In the Ubuntu systemd service Thanks, this is a bunch of useful info! I'll experiment with a few of these options. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1912844 Title: Bond with OVS bridging RuntimeError: duplicate mac found! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
Another question: is there a canonical way to determine if OVS isn't up? Currently I'm trying to execute a command and looking for "database connection failed" in the output, is that appropriate? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1912844 Title: Bond with OVS bridging RuntimeError: duplicate mac found! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
> But I guess it would be reasonable to split the work up in bite sized chunks as long as we allow for supporting this in the design. Having looked a little more, I don't think an incremental approach buys us much here: we'd have to replace the `udevadm` code with `ovs-vsctl` code in the next stage anyway (rather than extending it). We may as well just take the approach that will address both in the first place. The next question is exactly which interfaces we should be excluding from the set of interfaces we consider. At the moment, my POC is excluding interfaces whose name matches an OVS bridge, determined via `ovs-vsctl list-br`. In an instance with an additional VLAN to the above configurations, I see: # ovs-vsctl list-br ovs-br ovs-br.100 ovs-br.200 Does this seems appropriate? I also notice that querying for internal interfaces returns the same set: # ovs-vsctl find interface type=internal | grep ^name name: ovs-br name: ovs-br.200 name: ovs-br.100 I don't think we want to exclude every interface known to OVS, because I believe that would regress bug 1898997. From an instance launched from the integration test for that bug: cb6840fc-f53d-471b-b7e7-aa7398fd4c37 Bridge ovs-br fail_mode: standalone Port enp5s0 Interface enp5s0 Port ovs-br Interface ovs-br type: internal ovs_version: "2.13.1" We _do_ still want to consider enp5s0 in cloud-init's code, because it's a real interface that isn't (entirely?) configured by OVS. Thoughts? (If this isn't a sufficient problem description, let me know!) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1912844 Title: Bond with OVS bridging RuntimeError: duplicate mac found! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
To ensure that we understand the consequences of these changes, I've
spent a bit of time tracking down everywhere this will affect in cloud-
init by looking up the various call chains of `get_interfaces`:
Called by:
* `_get_current_rename_info`
* `_rename_interfaces`
* `apply_network_config_names`
* `Distro.apply_network_config_names`
* `Init._apply_netcfg_names`
* `Init.apply_network_config`
* `get_ib_hwaddrs_by_interface`
* `helpers.openstack.convert_net_json`
* {`ConfigDrive`, `OpenStack`, `IBMCloud`}`.network_config`
* `get_interfaces_by_mac_on_linux`
* `get_interfaces_by_mac`
* `OpenNebulaNetwork` -- used to determine physical NICs for network config
generation
* Oracle -- a couple of ways in network config generation
* EC2 -- network config conversion (theirs to ours)
* `helpers.openstack.convert_net_json`
* `helpers.digitalocean.convert_network_configuration`
* `helpers.upcloud.convert_to_network_config_v1`
* `net.get_devicelist` (but only on FreeBSD)
* `find_fallback_nic_on_netbsd_or_openbsd`
* `find_fallback_nic_on_freebsd`
* `Networking.wait_for_physdevs`
* `Init.apply_network_config`
Most of these are related to converting a network configuration format
provided by a cloud into our own formats. None of this generation
includes handling for creating OVS config (unsurprisingly!), so those
cases should all be unaffected by changes to `get_interfaces` around OVS
(except for a very minor performance hit for any new checks). Others
are only used on *BSD, so we also don't need to worry about OVS
interfaces there.
Every other call originates from `Init.apply_network_config`: this is
the codepath that we are intending to affect, so we can see that there
shouldn't be any unexpected consequences in other parts of the codebase.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1912844
Title:
Bond with OVS bridging RuntimeError: duplicate mac found!
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
Hey Frode, Now moving on from the "does this system have any OVS-managed interfaces?" to "how can I tell if a particular interface is managed by OVS?": We discussed using `udevadm info` to determine if an interface is OVS- managed: > If it is sufficient to know that this is a Open vSwitch managed port I guess > we could get that from udev, for example: > > # udevadm info /sys/class/net/enp6s0.9 > ... > E: ID_NET_DRIVER=openvswitch > ... But later we also discussed that OVS-managed interfaces may not be owned by the `openvswitch` kernel driver: > Open vSwitch supports multiple datapath types, and depending on which one you use the interface may or may not be owned by the openvswitch driver. It looks to me like these two statements are in opposition: if OVS is managing an interface via a different datapath, then it won't have ID_NET_DRIVER=openvswitch in its `udevadm info`. If this is the case, then I think we have a couple of options. Firstly, we could scope this down to only handle system datapath interfaces, so that it _is_ true that all the interfaces we're handling are owned by the openvswitch. I don't know enough about how OVS is used (either by us or more generally) to know if this is a reasonable suggestion, so your guidance would be appreciated. If we can't do that, then I think we need to ask OVS directly, presumably via `ovs-vsctl show` as discussed above. This would require it to be in PATH, of course; avoiding that is a nice-to-have at best, so I think that's fine. Does that sound right to you? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1912844 Title: Bond with OVS bridging RuntimeError: duplicate mac found! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
I've figured out why my LXD reproducer doesn't reproduce exactly: NoCloud runs at both local and net stages, so the code in question is called earlier in boot than the OpenStack data source is. For now, I'll proceed with the synthetic reproducer: calling the Python code which fails directly. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1912844 Title: Bond with OVS bridging RuntimeError: duplicate mac found! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
> The default `datapath_type` is 'system', so if it is not explicitly specified for a bridge it will not be visible in `ovs-vsctl show` output, but 'system' will still be the `datapath_type` used. Great, I figured it wasn't material. > You can query Open vSwitch at runtime for which datapath types it supports with `ovs-vsctl get open_vswitch . datapath_types` which would produce '[netdev, system]' as output. Will `ovs-vsctl` always be available if OVS interfaces might be present on the system? Will it always be in (our systemd units') PATH? (My _guess_ is that we can't be sure, about the latter at least: /opt/openvswitch/bin/ovs-vsctl doesn't seem like a wildly unreasonable path to install to, and cloud-init has no good way of finding that.) > If we want to be opportunistic I guess iterating over the datapath_types list and check for /sys/class/net/ovs-$datapath_type could be a generic approach that may also work for the next datapath_type we currently do not know about. I think this would be ideal, but we can avoid introducing a (runtime- detected, optional) dependency on `ovs-vsctl` if we hardcode the current options: as discussed above, this may even be necessary. Alternatively, we could opt into the more expensive lookup path if we find anything matching /sys/class/net/ovs-*: this may lead to some false positives (e.g. if network configuration specifying non-OVS interfaces named ovs- something is passed to an instance) but (a) such configurations will be extremely rare, and (b) we will only be less performant on such instances, not _incorrect_. What do you think? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1912844 Title: Bond with OVS bridging RuntimeError: duplicate mac found! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1915077] Re: genisoimage may be going away
On Mon, Feb 15, 2021 at 10:18:17PM -, Steve Langasek wrote: > On Mon, Feb 15, 2021 at 02:21:28PM -, James Falcon wrote: > > That said, cloud-image-utils is in main[2] and therefore all of its > > dependencies also need to be in main, so we are not free to choose our > > own replacement unconstrained. We certainly won't be alone in needing > > to choose a replacement, `apt rdepends genisoimage` indicates that, > > amongst others, ubuntu-desktop and livecd-rootfs (which is the package > > used to build not only live CD root filesystems but also ~every other > > Ubuntu image). IMO, it's not really our place to determine the correct > > replacement here: this is a tool used across different parts of Ubuntu, > > so Foundations are likely better placed than we. > > We use xorriso in place of genisoimage for Ubuntu ISO generation. OK, that's clearly what we should be moving to; thanks! > I'm actually not sure why genisoimage is a dependency of > livecd-rootfs, since I don't believe we have any ISOs as output of > livecd-rootfs itself. It's used by the CPC Vagrant build scripts to... generate a cloud-init seed ISO. (= (Who could have introduced that? *innocent whistling*) > The ubuntu-meta dependency is being dropped; the seed change has already > been merged, and a new ubuntu-desktop is waiting in hirsute-proposed. OK, cool; are we looking to drop it (from main) this cycle? (i.e. Do we need to work on this ~now?) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1915077 Title: genisoimage may be going away To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1915077/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
Thanks Frode, that's really helpful! I don't see the `datapath_type` in my output: e2d9c9b4-739c-4333-a372-4d46585fcfb9 Bridge ovs-br fail_mode: standalone Port ovs-br Interface ovs-br type: internal Port bond0 Interface bond0 Port ovs-br.100 tag: 100 Interface ovs-br.100 type: internal ovs_version: "2.13.1" but I _do_ see /sys/class/net/ovs-system in the system: # ls /sys/class/net/ -lah total 0 drwxr-xr-x 2 root root0 Feb 9 22:07 . drwxr-xr-x 31 root root0 Feb 9 22:07 .. lrwxrwxrwx 1 root root0 Feb 9 22:07 bond0 -> ../../devices/virtual/net/bond0 -rw-r--r-- 1 root root 4.0K Feb 9 22:07 bonding_masters lrwxrwxrwx 1 root root0 Feb 9 22:07 enp5s0 -> ../../devices/pci:00/:00:01.4/:05:00.0/virtio10/net/enp5s0 lrwxrwxrwx 1 root root0 Feb 9 22:07 lo -> ../../devices/virtual/net/lo lrwxrwxrwx 1 root root0 Feb 9 22:07 ovs-br -> ../../devices/virtual/net/ovs-br lrwxrwxrwx 1 root root0 Feb 9 22:07 ovs-br.100 -> ../../devices/virtual/net/ovs-br.100 lrwxrwxrwx 1 root root0 Feb 9 22:07 ovs-system -> ../../devices/virtual/net/ovs-system If I launch a separate system, and install openvswitch-switch, /sys/class/net/ovs-system does _not_ appear, which appears to confirm that it will only be present in systems with OVS configuration. This leads me to some questions: Will /sys/class/net/ovs-system always be present? Or might we encounter systems where only ovs-netdev (or another) is present? If so, is there a defined set we can match on, or do we need to glob match? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1912844 Title: Bond with OVS bridging RuntimeError: duplicate mac found! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1915077] Re: genisoimage may be going away
** Also affects: cloud-utils (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1915077 Title: genisoimage may be going away To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1915077/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1377308] Re: booting cloud image without initramfs broken
Drive-by mark as Incomplete, as the way initramfses and cloud images interact has changed substantially since 2014. ** Changed in: cloud-init (Ubuntu Trusty) Status: Triaged => Won't Fix ** Changed in: cloud-init (Ubuntu) Status: Triaged => Incomplete ** Changed in: cloud-init Status: Triaged => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1377308 Title: booting cloud image without initramfs broken To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1377308/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
I can confirm that udev does report the VLAN as OVS-managed: # udevadm info /sys/class/net/ovs-br.100 P: /devices/virtual/net/ovs-br.100 L: 0 E: DEVPATH=/devices/virtual/net/ovs-br.100 E: INTERFACE=ovs-br.100 E: IFINDEX=5 E: SUBSYSTEM=net E: USEC_INITIALIZED=4703175 E: ID_MM_CANDIDATE=1 E: ID_NET_NAMING_SCHEME=v245 E: ID_NET_DRIVER=openvswitch E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/ovs-br.100 E: TAGS=:systemd: so this is a feasible approach, at least. I have reservations about introducing a call to an external program in this codepath; I believe we'd have to call it for every interface (that wasn't excluded via some earlier check), and subprocess calls are much more expensive than reading files. Via local testing with timeit: is_vlan takes ~48.3 usec per loop, a subp of `udevadm info ...` takes ~2.48 msec per loop. This isn't too substantial in most systems, but in systems with more interfaces (or slower `udevadm`?), it could become something of an issue. I suspect, however, that we can find a way of gating this check on the presence of OVS somehow: if openvswitch-switch is not installed, for example, then there's no reason to check `udevadm info`: the given interface will never be OVS-managed. What's a reliable, cross-distro way of checking if a system might have OVS-managed interfaces? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1912844 Title: Bond with OVS bridging RuntimeError: duplicate mac found! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
On Fri, Jan 22, 2021 at 10:51:25PM -, Ryan Harper wrote: > Thanks for doing most of the digging here @Oddbloke; I suspect as with > bond and bridges for ovs, we'll need a special case to check if a vlan > entry is also OVS, much like we did for bonds/bridges: > > https://github.com/canonical/cloud-init/pull/608/files > > So our is_vlan change will need to see if link device is OVS and if so > then say it's a vlan as well (since the DEVTYPE doesn't match) or > something to that effect. Unless I'm missing something, we don't have a network configuration to reference in these codepaths: get_interfaces only takes a blacklist_drivers parameter, and is_vlan only takes a devname. So for the code to work as-architected, I believe we need to be able to determine that this is a VLAN from examining the system (via /sys/class/net, most likely) to be able to exclude it in get_interfaces. As far as I (with my limited networking knowledge) can tell, we can neither determine that this is a VLAN, nor that this is related to the ovs-br interface by examining /sys/class/net: while the non-OVS VLAN has a lower_ link to the bridge interface, the OVS VLAN does not. Looking at everything in /sys/class/net/ (with `for f in *; do echo $f: $(cat $f); done 2>/dev/null`), here's the diff between the two systems: --- not-ovs 2021-01-25 13:15:34.560602978 -0500 +++ ovs 2021-01-25 13:15:23.400407103 -0500 @@ -1,26 +1,25 @@ -addr_assign_type: 2 +addr_assign_type: 3 addr_len: 6 -address: de:ad:be:ef:12:34 +address: 56:1d:35:09:77:47 broadcast: ff:ff:ff:ff:ff:ff carrier: 1 -carrier_changes: 1 +carrier_changes: 0 carrier_down_count: 0 -carrier_up_count: 1 +carrier_up_count: 0 dev_id: 0x0 dev_port: 0 dormant: 0 duplex: -flags: 0x1003 +flags: 0x1103 gro_flush_timeout: 0 ifalias: -ifindex: 5 -iflink: 4 +ifindex: 6 +iflink: 6 link_mode: 0 -lower_br: mtu: 1500 name_assign_type: 3 netdev_group: 0 -operstate: up +operstate: unknown phys_port_id: phys_port_name: phys_switch_id: @@ -31,4 +30,4 @@ subsystem: tx_queue_len: 1000 type: 1 -uevent: DEVTYPE=vlan INTERFACE=br.100 IFINDEX=5 +uevent: INTERFACE=ovs-br.100 IFINDEX=6 With addr_assign_type set to 3, and no DEVTYPE=vlan, and no lower_* link, I don't see how we can tell that this is a VLAN. (I've checked and the difference in flags is, if I did my bitmasking correctly, whether the interface is in promiscuous mode or not.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1912844 Title: Bond with OVS bridging RuntimeError: duplicate mac found! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
On Fri, Jan 22, 2021 at 10:48:56PM -, David Ames wrote: > I am not sure I have any definitivie answers but here are my thoughts. > > Compare a VLAN device created with `ip link add` > > ip link add link enp6s0 name enp6s0.100 type vlan id 100 > > cat /sys/class/net/enp6s0.100/uevent > DEVTYPE=vlan > INTERFACE=enp6s0.100 > IFINDEX=3 > > > To an OVS VLAN interface created with ovs-vsctl: > > ovs-vsctl add-port br-ex vlan100 tag=200 -- set Interface vlan100 > type=internal > > cat /sys/class/net/br-ex.100/uevent > INTERFACE=br-ex.100 > IFINDEX=7 Thanks for isolating how these devices are created! > I suspect this is down to the tooling. OVS is creating virtual devices > so it may not be what `ip link` would create. I don't believe that cloud-init has changed anything in this area, so I would still like confirmation that this is a case that cloud-init definitely needs to workaround. (Rather than it being the case that there's an underlying bug which, being involved in networking early in boot, we are the first to encounter.) > Could the `is_vlan` function check for the '.' followed by an integer > which is the indication of a VLAN in all cases? Using device names is generally not reliable. In this specific case, with this config passed to a LXD VM: bridges: br.100: dhcp4: true interfaces: - enp5s0 macaddress: 52:54:00:d9:08:1c mtu: 1500 ethernets: enp5s0: mtu: 1500 version: 2 it comes up with working networking and I see: # cat /sys/class/net/br.100/uevent DEVTYPE=bridge INTERFACE=br.100 IFINDEX=3 (While you (and I) can certainly question the wisdom of naming a non-VLAN like this, cloud-init's code cannot assume that there aren't users out there doing this, for whatever reason.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1912844 Title: Bond with OVS bridging RuntimeError: duplicate mac found! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
OK, I have a suspicion of what's going on here. I've compared two
systems: one launched with the network config above (and
updated/rebooted), and one launched with that config minus the
"openvswitch: {{}}" line.
When I compare /sys/class/net/ovs-br.100/addr_assign_type in the two
systems, I see that on the OpenVSwitch-enabled system, it is 3 ("set
using dev_set_mac_address") whereas in the non-OVS system, it is 2
("stolen from another device"). (Descriptions of those values come from
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net.)
The function which raises the exception
(get_interfaces_by_mac_on_linux[0]) calls get_interfaces[1] to get the
list of interfaces it should consider. get_interfaces will exclude all
interfaces with an addr_assign_type of 2 (via interface_has_own_mac[2]).
It will also explicitly exclude VLANs (via is_vlan[3], which checks for
DEVTYPE=vlan in /sys/class/net//uevent): this check is also not
triggered because the /uevent on the OVS system does not have
DEVTYPE=vlan in it.
I'm not particularly familiar with OVS: is it somehow expected that this
VLAN will not be presented via /sys/class/net as other VLANs are? Or
does this suggest that there's a bug in something below cloud-init which
isn't correctly configuring this VLAN (which cloud-init then cannot
detect as a VLAN, and so fails)?
[0]
https://github.com/canonical/cloud-init/blob/master/cloudinit/net/__init__.py#L831
[1]
https://github.com/canonical/cloud-init/blob/master/cloudinit/net/__init__.py#L855
[2]
https://github.com/canonical/cloud-init/blob/master/cloudinit/net/__init__.py#L523
[3]
https://github.com/canonical/cloud-init/blob/master/cloudinit/net/__init__.py#L268
(As an aside: both my understanding of the problem and a test of a
revert suggest that this isn't a regression caused by
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1912844
Title:
Bond with OVS bridging RuntimeError: duplicate mac found!
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
Also of note: the MAC address being reported as duplicated in both the reported log and in the exception I see is not present in the specified configuration. It's presumably being generated by OVS and applied to ovs-br (and therefore inherited by ovs-br.100?). I'm going to see if a more minimal vlans configuration reproduces. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1912844 Title: Bond with OVS bridging RuntimeError: duplicate mac found! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
The network config below closely reproduces the issue when a LXD VM is
launched with it, has openvswitch-switch installed on it (e.g. via a
manual DHCP on enp5s0), and is `cloud-init clean --logs --reboot`ed.
The log does not contain the error message, but calling
`cloudinit.net.get_interfaces_by_mac()` from a Python console does
trigger it.
If the vlans definition is removed, the instance comes up with
networking (after the same reboot process).
MAC_ADDRESS = "de:ad:be:ef:12:34"
NETWORK_CONFIG = """\
bonds:
bond0:
interfaces:
- enp5s0
macaddress: {0}
mtu: 1500
bridges:
ovs-br:
interfaces:
- bond0
macaddress: {0}
mtu: 1500
openvswitch: {{}}
ethernets:
enp5s0:
mtu: 1500
set-name: enp5s0
match:
macaddress: {0}
version: 2
vlans:
ovs-br.100:
dhcp4: true
id: 100
link: ovs-br
mtu: 1500
""".format(MAC_ADDRESS)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1912844
Title:
Bond with OVS bridging RuntimeError: duplicate mac found!
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1912844] Re: Bond with OVS bridging RuntimeError: duplicate mac found!
This is the network config, pulled out of the log file:
bonds:
bond0:
interfaces:
- enp1s0
- enp7s0
macaddress: 52:54:00:28:fd:fd
mtu: 1500
parameters:
down-delay: 0
gratuitious-arp: 1
mii-monitor-interval: 0
mode: active-backup
transmit-hash-policy: layer2
up-delay: 0
bridges:
br-ex:
addresses:
- 192.168.151.18/24
gateway4: 192.168.151.1
interfaces:
- bond0
macaddress: 52:54:00:28:fd:fd
mtu: 1500
nameservers:
addresses:
- 192.168.151.5
search:
- maas
openvswitch: {}
parameters:
forward-delay: 15
stp: false
ethernets:
enp1s0:
match:
macaddress: 52:54:00:28:fd:fd
mtu: 1500
set-name: enp1s0
enp7s0:
match:
macaddress: 52:54:00:7c:4e:85
mtu: 1500
set-name: enp7s0
version: 2
vlans:
br-ex.100:
dhcp4: true
id: 100
link: br-ex
mtu: 1500
** Changed in: cloud-init (Ubuntu)
Assignee: (unassigned) => Dan Watkins (oddbloke)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1912844
Title:
Bond with OVS bridging RuntimeError: duplicate mac found!
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1910835] Re: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
** Changed in: cloud-init Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910835 Title: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1910835/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1910835] Re: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
I've just attached the output of our verification testing runs for each series. Each series exhibits two test failures, neither of which is material to the change in question (and both of which reproduce against the cloud- init currently in the archive). `test_datasource_rbx_no_stacktrace` is testing a non-Azure datasource but doesn't include the appropriate marks to exclude it from an Azure test run. As such, it's an expected failure (which we will fix upstream: https://bugs.launchpad.net/cloud-init/+bug/1911230). `TestSeedRandomData.test_seed_random_data` is implemented incorrectly for Azure. `cc_seed_random` behaves differently on platforms which provide random data to cloud-init (such as Azure), and that is not taken into account in the test code (or described in the documentation). https://bugs.launchpad.net/cloud-init/+bug/1911227 captures addressing the documentation and test issue. Given that all other tests pass, including the one for this bug, I consider verification of these cloud-init SRUs to be complete. ** Tags removed: verification-needed verification-needed-bionic verification-needed-focal verification-needed-groovy verification-needed-xenial ** Tags added: verification-done verification-done-bionic verification-done-focal verification-done-groovy verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910835 Title: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1910835/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1910835] Re: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
** Attachment added: "groovy verification log" https://bugs.launchpad.net/cloud-init/+bug/1910835/+attachment/5452348/+files/groovy.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910835 Title: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1910835/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1910835] Re: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
** Attachment added: "focal verification log" https://bugs.launchpad.net/cloud-init/+bug/1910835/+attachment/5452347/+files/focal.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910835 Title: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1910835/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1910835] Re: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
** Attachment added: "bionic verification log" https://bugs.launchpad.net/cloud-init/+bug/1910835/+attachment/5452346/+files/bionic.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910835 Title: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1910835/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1910835] Re: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
** Description changed:
== Begin SRU Template ==
[Impact]
- The previous version of cloud-init used OpenSSL to process the SSH keys
provided by the Azure platform. cloud-init 20.4 replaced that code with a more
efficient implementation, but one which did not use OpenSSL: this meant that
users passing certificates to instances, or users generating SSH keys in
Azure's web UI (which inserts \r\n sequences into the public key content), were
regressed: their certificates and misformed SSH keys were no longer handled, so
they could fail to gain access to newly-launched instances.
+ The previous version of cloud-init used OpenSSL to process the SSH keys
provided by the Azure platform. cloud-init 20.4 replaced that code with a more
efficient implementation, but one which did not use OpenSSL: this meant that
users passing certificates to instances, or users generating SSH keys in
Azure's web UI (which inserts \r\n sequences into the public key content), were
regressed: their certificates and malformed SSH keys were no longer handled, so
they could fail to gain access to newly-launched instances.
This release is only a single functional cherry-pick which solely
affects Azure platform. It is a critical bug we wish to release as soon
as possible
* Azure: cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
The functional changeset here introduces a raise KeyError exception
which forces cloud-init to revert to previous released logic of the
previous cloud-init public release 20.3.
[Test Case]
As this is a single commit backport, the cloud-init SRU exception need
not apply. An upstream integration test has been written for this issue
(https://github.com/canonical/cloud-
init/blob/master/tests/integration_tests/bugs/test_lp1910835.py).
A full run of the upstream test suite on Azure will therefore regression
test the update generally and test this issue specifically: a log of a
test run for each suite will be attached.
[Regression Potential]
The proposed change only modifies code paths used on Azure, specifically
to revert to a previous behaviour: users unaffected by the bug should
see no change (their keys will get to their instance via a different
route), and users affected by the bug would have been unable to access
their instances before (so cannot be relying on this behaviour in a way
which we could break by fixing it).
[Discussion]
This should only affect public Azure VM launched which use Azure to
--generate-ssh-keys either from the dashboard or from the `az cli`
Any other cloud-platform is not affected by this change.
== End SRU Template ==
* cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
== Original Description ==
cloud-init 20.4 or later will incorrectly add Azure publicKeys to
.ssh/authorized_keys preventing ssh access for cloud-generated keys.
To reproduce: launch an ubuntu VM from the portal.azure.com choosing to
generate new ssh key.
When the instance is launched you can see that the ssh-rsa content
provided in the metadata publicKeys value contains CRLF characters
(\r\n) thus splitting the content of the pubkey onto multiple lines when
it is rendered into .ssh/authorized_keys.
the solution is either for IMDS to stop adding the CRLF characters or
cloud-init to strip them out.
Here is the IMDS value provided to cloud-init
cloud-init query --format '{{ds.meta_data.imds.compute.publicKeys}}'
[{'keyData': 'ssh-rsa
B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d\r\nk/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R\r\n9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW\r\nlkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq\r\n4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7\r\n6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu\r\niKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht\r\n6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9\r\nS2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU=
generated-by-azure\r\n', 'path': '/home/ubuntu/.ssh/authorized_keys'}]
cloud-init renders this directly to .ssh/authorized_keys without
processing the string, resulting in an invalid keyline:
ssh-rsa B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d
k/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R^M
9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW^M
lkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq^M
4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7^M
6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu^M
iKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht^M
6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9^M
[Bug 1910835] Re: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
** Description changed:
== Begin SRU Template ==
[Impact]
- This release is only a single functional cherry-pick which solely affects
Azure platform. It is a critical bug we wish to release as soon as possible
+ The previous version of cloud-init used OpenSSL to process the SSH keys
provided by the Azure platform. cloud-init 20.4 replaced that code with a more
efficient implementation, but one which did not use OpenSSL: this meant that
users passing certificates to instances, or users generating SSH keys in
Azure's web UI (which inserts \r\n sequences into the public key content), were
regressed: their certificates and misformed SSH keys were no longer handled, so
they could fail to gain access to newly-launched instances.
+
+ This release is only a single functional cherry-pick which solely
+ affects Azure platform. It is a critical bug we wish to release as soon
+ as possible
* Azure: cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
The functional changeset here introduces a raise KeyError exception
which forces cloud-init to revert to previous released logic of the
previous cloud-init public release 20.3.
+ [Test Case]
- [Test Case]
- The following development and SRU process was followed:
- https://wiki.ubuntu.com/CloudinitUpdates
+ As this is a single commit backport, the cloud-init SRU exception need
+ not apply. An upstream integration test has been written for this issue
+ (https://github.com/canonical/cloud-
+ init/blob/master/tests/integration_tests/bugs/test_lp1910835.py).
- The cloud-init team will be in charge of attaching the artifacts and
- console output of the appropriate run to the bug. cloud-init team
- members will not mark ‘verification-done’ until this has happened.
-
- * Automated Test Results
-
-
-
-
-
- * Manual Test Results
-
-
-
+ A full run of the upstream test suite on Azure will therefore regression
+ test the update generally and test this issue specifically: a log of a
+ test run for each suite will be attached.
[Regression Potential]
- In order to mitigate the regression potential, the results of the
- aforementioned integration tests are attached to this bug.
+
+ The proposed change only modifies code paths used on Azure, specifically
+ to revert to a previous behaviour: users unaffected by the bug should
+ see no change (their keys will get to their instance via a different
+ route), and users affected by the bug would have been unable to access
+ their instances before (so cannot be relying on this behaviour in a way
+ which we could break by fixing it).
[Discussion]
This should only affect public Azure VM launched which use Azure to
--generate-ssh-keys either from the dashboard or from the `az cli`
Any other cloud-platform is not affected by this change.
== End SRU Template ==
* cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
== Original Description ==
cloud-init 20.4 or later will incorrectly add Azure publicKeys to
.ssh/authorized_keys preventing ssh access for cloud-generated keys.
To reproduce: launch an ubuntu VM from the portal.azure.com choosing to
generate new ssh key.
When the instance is launched you can see that the ssh-rsa content
provided in the metadata publicKeys value contains CRLF characters
(\r\n) thus splitting the content of the pubkey onto multiple lines when
it is rendered into .ssh/authorized_keys.
the solution is either for IMDS to stop adding the CRLF characters or
cloud-init to strip them out.
Here is the IMDS value provided to cloud-init
cloud-init query --format '{{ds.meta_data.imds.compute.publicKeys}}'
[{'keyData': 'ssh-rsa
B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d\r\nk/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R\r\n9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW\r\nlkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq\r\n4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7\r\n6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu\r\niKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht\r\n6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9\r\nS2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU=
generated-by-azure\r\n', 'path': '/home/ubuntu/.ssh/authorized_keys'}]
cloud-init renders this directly to .ssh/authorized_keys without
processing the string, resulting in an invalid keyline:
ssh-rsa B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d
k/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R^M
9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW^M
lkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq^M
4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7^M
6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu^M
[Bug 1910252] Re: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation"
So I've done a little more testing. On boot, with /sys/power/resume unset (i.e. 0:0), I see this in the logind debug logs: Jan 08 09:47:11 surprise systemd-logind[1887]: Sleep mode "disk" is supported by the kernel. Jan 08 09:47:11 surprise systemd-logind[1887]: /dev/dm-2: is a candidate device. Jan 08 09:47:11 surprise systemd-logind[1887]: /dev/sda2: ignoring device with lower priority Jan 08 09:47:11 surprise systemd-logind[1887]: /sys/power/resume is not configured; attempting to hibernate with path: /dev/dm-2, device: 253:2, offset: 0, priority: -2 Jan 08 09:47:11 surprise systemd-logind[1887]: Not enough swap for hibernation, Active(anon)=1134696 kB, size=1003516 kB, used=0 kB, threshold=98% If I set /sys/power/resume correctly, then I see: Jan 08 09:48:10 surprise systemd-logind[1887]: Sleep mode "disk" is supported by the kernel. Jan 08 09:48:10 surprise systemd-logind[1887]: /dev/dm-2: is a candidate device. Jan 08 09:48:10 surprise systemd-logind[1887]: /dev/sda2: ignoring device with lower priority Jan 08 09:48:10 surprise systemd-logind[1887]: No swap partitions or files matching resume config were found in /proc/swaps. (I haven't been able to test what happens if I restart logind because I hit https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1910769 if I try; my plan is add an ExecStartPre which sets the resume device to logind's unit file, to see if that does the trick.) Does anyone know what in the system is _meant_ to be setting /sys/power/resume? Is it possible I'm missing some configuration somewhere to have that setting happen? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910252 Title: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1910252/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1910769] [NEW] systemd-logind: loss of input devices when logging in after restart
Public bug reported: # Steps to reproduce 1) Login as a regular user. 2) `sudo systemctl restart systemd-logind` This boots you back to GDM, as you would expect. 3) Login as a user. 4) Wait a few seconds. # Expected behaviour I can continue to use my system normally. # Actual behaviour My keyboard and mouse stop working; unplugging/replugging has no effect. Everything on screen continues to behave normally. # Debugging Notes I noticed, when Ctrl-Alt-F'ing around trying to figure out what was going on, that there are _two_ GDM sessions apparently running after the logind restart. Furthermore, I logged in on a console (Ctrl-Alt-F2) before performing the restart of logind, and when my keyboard stopped working in my graphical session, typing commands still worked! (I couldn't see this console, obviously, but I tested it by typing `mplayer Music/*/*` and observing music start playing.) ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.6-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-36.40-generic 5.8.18 Uname: Linux 5.8.0-36-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu50.3 Architecture: amd64 CasperMD5CheckResult: skip Date: Fri Jan 8 10:06:56 2021 InstallationDate: Installed on 2019-05-07 (611 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: Gigabyte Technology Co., Ltd. B450M DS3H ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-36-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/systemd-logind.service → /etc/systemd/system/systemd-logind.service.d/override.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 3 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: Upgraded to groovy on 2020-06-22 (199 days ago) dmi.bios.date: 01/25/2019 dmi.bios.release: 5.13 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F4 dmi.board.asset.tag: Default string dmi.board.name: B450M DS3H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: B450M DS3H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug groovy -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910769 Title: systemd-logind: loss of input devices when logging in after restart To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1910769/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1910252] Re: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation"
And, for clarity, when systemd does hibernate, I haven't had issues restoring: it's just getting systemd to find the correct swap space to use that's been the issue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910252 Title: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1910252/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1910252] Re: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation"
On Thu, Jan 07, 2021 at 03:23:36PM -, Dimitri John Ledkov wrote: > Also, you do disable secureboot as well right? Because with secureboot > on, even though hybernation image is created, it will be ignored and > not used upon resume. Yep, Secure Boot is disabled on this system. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910252 Title: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1910252/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1910252] Re: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation"
> So, looking at the systemd code at https://github.com/systemd/systemd/blob/c5b6b4b6d08cf4c16a871401358faeb5a186c02a/src/shared /sleep-config.c#L422-L426, perhaps setting /sys/power/resume to the correct device actually was the workaround/fix? The confusing part about this is that I don't believe I set /sys/power/resume when I first booted, so I guess that was set correctly for some reason this time around? (Or maybe something else is going on entirely, of course.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910252 Title: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1910252/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1910252] Re: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation"
I enabled systemd-logind debug logging, and I saw: Jan 06 17:45:18 surprise systemd-logind[73027]: Got message type=method_call sender=:1.264 destination=:1.220 path=/org/freedesktop/login1 interface=org.freedesktop.login1.Manager member=CanHibernate cookie=6 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a Jan 06 17:45:18 surprise systemd-logind[73027]: Sleep mode "disk" is supported by the kernel. Jan 06 17:45:18 surprise systemd-logind[73027]: /dev/dm-2: is a candidate device. Jan 06 17:45:18 surprise systemd-logind[73027]: /dev/sda2: ignoring device with lower priority Jan 06 17:45:18 surprise systemd-logind[73027]: No swap partitions or files matching resume config were found in /proc/swaps. Jan 06 17:45:18 surprise systemd-logind[73027]: Sent message type=method_return sender=n/a destination=:1.264 path=n/a interface=n/a member=n/a cookie=185 reply_cookie=6 signature=s error-name=n/a error-message=n/a Jan 06 17:45:18 surprise systemd-logind[73027]: Got message type=method_call sender=:1.264 destination=:1.220 path=/org/freedesktop/login1 interface=org.freedesktop.login1.Manager member=CanHybridSleep cookie=7 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a Jan 06 17:45:18 surprise systemd-logind[73027]: Sleep mode "disk" is supported by the kernel. Jan 06 17:45:18 surprise systemd-logind[73027]: /dev/dm-2: is a candidate device. Jan 06 17:45:18 surprise systemd-logind[73027]: /dev/sda2: ignoring device with lower priority Jan 06 17:45:18 surprise systemd-logind[73027]: No swap partitions or files matching resume config were found in /proc/swaps. However, after a reboot this morning, hibernation does seem to be working, and I instead see: Jan 07 09:29:37 surprise systemd-logind[1798]: Got message type=method_call sender=:1.125 destination=org.freedesktop.login1 path=/org/freedesktop/login1 interface=org.freedesktop.login1.Manager member=Hibernate cookie=3 reply_cookie=0 signature=b error-name=n/a error-message=n/a Jan 07 09:29:37 surprise systemd-logind[1798]: Sleep mode "disk" is supported by the kernel. Jan 07 09:29:37 surprise systemd-logind[1798]: /dev/sda2: device matches configured resume settings. Jan 07 09:29:37 surprise systemd-logind[1798]: Hibernation will attempt to use swap entry with path: /dev/sda2, device: 8:2, offset: 0, priority: -3 Jan 07 09:29:37 surprise systemd-logind[1798]: Enough swap for hibernation, Active(anon)=3080788 kB, size=102401108 kB, used=0 kB, threshold=98% So it looks like the issue is that my resume device was not being detected correctly previously, meaning that priority was being used (which resulted in the wrong device being selected). So, looking at the systemd code at https://github.com/systemd/systemd/blob/c5b6b4b6d08cf4c16a871401358faeb5a186c02a/src/shared /sleep-config.c#L422-L426, perhaps setting /sys/power/resume to the correct device actually was the workaround/fix? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910252 Title: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1910252/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1910252] Re: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation"
> $ cat /sys/power/resume > 0:0 This was a red herring. What I have found consistently fixes this is: $ sudo swapoff /dev/sda2 $ sudo swapon -p 1 /dev/sda2 Hibernate then succeeds. However, this is not how I want my system configured: I have a small swap partition on my SSD, which I would like to be used for swap under normal operation; changing the priority to address my hibernation issues means that I'm using my slow HDD as regular swap. For reference, after the above changes: $ swapon NAME TYPE SIZE USED PRIO /dev/dm-2 partition 980M 0B -2 /dev/sda2 partition 97.7G 0B1 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910252 Title: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1910252/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1910252] Re: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation"
Oh, and `free -h`: totalusedfree shared buff/cache available Mem: 15Gi 6.0Gi 667Mi 567Mi 9.0Gi 8.8Gi Swap: 98Gi13Mi98Gi -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910252 Title: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1910252/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1910252] Re: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation"
/sys/power/image_size represents the required amount of space for the image; that said, the machine has 16G RAM total, so even if that were maxed out, it would fit into 97.7G comfortably. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910252 Title: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1910252/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases
It sounds to me like there's no cloud-init aspect here, so I'm going to move our tasks to Incomplete (so they'll expire out eventually). Please do set them back if I've missed something! ** Changed in: cloud-init (Ubuntu) Status: Confirmed => Incomplete ** Changed in: cloud-init (Ubuntu Focal) Status: New => Incomplete ** Changed in: cloud-init (Ubuntu Groovy) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902960 Title: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1902960/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1910252] Re: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation"
One thing I have noticed, is that on boot: $ cat /sys/power/resume 0:0 I can't test right now, but I _think_ that before the holiday break setting that to 8:2[0] and restarting systemd-logind meant that hibernate did then work. [0] $ ls -l /sys/dev/block/8:2 lrwxrwxrwx 1 root root 0 Jan 5 09:08 /sys/dev/block/8:2 -> ../../devices/pci:00/:00:01.3/:02:00.1/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda2 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910252 Title: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1910252/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1910252] [NEW] `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation"
Public bug reported: I have plenty of swap space configured in my system: $ cat /sys/power/image_size 6642229248 # ~ 6.2GiB $ swapon NAME TYPE SIZE USED PRIO /dev/dm-2 partition 980M 0B -2 /dev/sda2 partition 97.7G 0B -3 But when I attempt to hibernate: $ sudo systemctl hibernate Failed to hibernate system via logind: Not enough swap space for hibernation I have the swap partition configured as my resume device in my kernel commandline: $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-5.8.0-33-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7 $ ls -l /dev/disk/by-uuid/73909634-a75d-42c9-8f66-a69138690756 lrwxrwxrwx 1 root root 10 Jan 5 09:08 /dev/disk/by-uuid/73909634-a75d-42c9-8f66-a69138690756 -> ../../sda2 (I'm not really sure how to further debug my issue, any assistance would be appreciated!) ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.6-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-33.36-generic 5.8.17 Uname: Linux 5.8.0-33-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu50.3 Architecture: amd64 CasperMD5CheckResult: skip Date: Tue Jan 5 09:33:04 2021 InstallationDate: Installed on 2019-05-07 (608 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: Gigabyte Technology Co., Ltd. B450M DS3H ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-33-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: Upgraded to groovy on 2020-06-22 (196 days ago) dmi.bios.date: 01/25/2019 dmi.bios.release: 5.13 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F4 dmi.board.asset.tag: Default string dmi.board.name: B450M DS3H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: B450M DS3H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug groovy -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1910252 Title: `systemctl hibernate` incorrectly reports "Not enough swap space for hibernation" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1910252/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905599] Re: sru cloud-init (20.3-2 to 20.4-0ubuntu1) Xenial, Bionic, Focal, and Groovy
Verification was completed before the holiday break; tags updated. ** Tags removed: verification-needed verification-needed-bionic verification-needed-focal verification-needed-groovy verification-needed-xenial ** Tags added: verification-done verification-done-bionic verification-done-focal verification-done-groovy verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905599 Title: sru cloud-init (20.3-2 to 20.4-0ubuntu1) Xenial, Bionic, Focal, and Groovy To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1905599/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1908548] Re: Add manpages to packaging branches
https://github.com/canonical/cloud-init/pull/748 will add them to our devel packaging for hirsute. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1908548 Title: Add manpages to packaging branches To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1908548/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1907107] Re: cloud-init runs too late at first startup after ubuntu autoinstall
Marking this as Incomplete as Ryan has provided next debugging steps. Please do move it back to New once you've responded! ** Changed in: cloud-init (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1907107 Title: cloud-init runs too late at first startup after ubuntu autoinstall To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1907107/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1908548] Re: Add manpages to packaging branches
** Also affects: cloud-init (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu Xenial) Status: New => Triaged ** Changed in: cloud-init (Ubuntu Bionic) Status: New => Triaged ** Changed in: cloud-init (Ubuntu Focal) Status: New => Triaged ** Changed in: cloud-init (Ubuntu Groovy) Status: New => Triaged ** Changed in: cloud-init (Ubuntu Hirsute) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1908548 Title: Add manpages to packaging branches To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1908548/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1691489] Re: fstab entries written by cloud-config may not be mounted
** Changed in: cloud-init Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1691489 Title: fstab entries written by cloud-config may not be mounted To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1691489/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905599] Re: sru cloud-init (20.3-2 to 20.4-0ubuntu1) Xenial, Bionic, Focal, and Groovy
** Attachment added: "Verification logs for KVM" https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1905599/+attachment/5444544/+files/nocloud-nocloud-kvm-sru-20.4.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905599 Title: sru cloud-init (20.3-2 to 20.4-0ubuntu1) Xenial, Bionic, Focal, and Groovy To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1905599/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905599] Re: sru cloud-init (20.3-2 to 20.4-0ubuntu1) Xenial, Bionic, Focal, and Groovy
** Attachment added: "Verification logs for LXD" https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1905599/+attachment/5444543/+files/nocloud-lxd-sru-20.4.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905599 Title: sru cloud-init (20.3-2 to 20.4-0ubuntu1) Xenial, Bionic, Focal, and Groovy To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1905599/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905599] Re: sru cloud-init (20.3-2 to 20.4-0ubuntu1) Xenial, Bionic, Focal, and Groovy
The attached are the logs of a curtin run with the -proposed cloud-init. The only "failures", indicate that expected-to-fail tests instead passed (because the underlying issues have since been addressed in Ubuntu). ** Attachment added: "curtin verification testing logs" https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1905599/+attachment/5444216/+files/curtin-cloudinit-sru.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905599 Title: sru cloud-init (20.3-2 to 20.4-0ubuntu1) Xenial, Bionic, Focal, and Groovy To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1905599/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905493] Re: cloud-init status --wait hangs indefinitely in a nested lxd container
Hi Ian, I've just launched such a container and I see a bunch of non-cloud-init errors in the log and when I examine `systemctl list-jobs`, I see that the two running jobs are systemd-logind.service and snapd.seeded.service: root@certain-cod:~# systemctl list-jobs JOB UNIT TYPE STATE 114 cloud-final.service start waiting 125 snapd.autoimport.service start waiting 143 systemd-update-utmp-runlevel.service start waiting 116 cloud-config.service start waiting 1 graphical.target start waiting 691 systemd-logind.service start running 99 unattended-upgrades.service start waiting 110 cloud-init.targetstart waiting 115 snapd.seeded.service start running 2 multi-user.targetstart waiting 10 jobs listed. Examining the journal, I see that systemd-logind.service is in a restart loop: root@certain-cod:~# journalctl -u systemd-logind.service | grep Failed\ w Dec 01 22:37:43 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:39:13 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:40:44 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:42:14 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:43:44 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:45:14 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:46:45 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:48:15 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. Dec 01 22:49:45 certain-cod systemd[1]: systemd-logind.service: Failed with result 'timeout'. This is blocking boot before cloud-init's later stages run, so as it is correctly indicating that it hasn't yet completed, I'm marking this Invalid for cloud-init. I'll add a systemd task instead, as that looks to be the source of the issue. Cheers, Dan ** Changed in: cloud-init Status: New => Invalid ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905493 Title: cloud-init status --wait hangs indefinitely in a nested lxd container To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1905493/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1906187] Re: Version tag is not respected when put last
** Changed in: cloud-init (Ubuntu) Status: New => Triaged ** Changed in: cloud-init (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1906187 Title: Version tag is not respected when put last To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1906187/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905984] Re: Hard lockup with "watchdog: BUG: soft lockup - CPU#10 stuck for 22s! [Xorg:13615]" in the journal
Looking through the journal further, I do see non-NVidia call traces such as: Nov 27 09:43:52 surprise kernel: INFO: task qemu-system-x86:16736 blocked for more than 120 seconds. Nov 27 09:43:52 surprise kernel: Tainted: P OEL 5.8.0-29-generic #31-Ubuntu Nov 27 09:43:52 surprise kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 27 09:43:52 surprise kernel: qemu-system-x86 D0 16736 1 0x0320 Nov 27 09:43:52 surprise kernel: Call Trace: Nov 27 09:43:52 surprise kernel: __schedule+0x212/0x5d0 Nov 27 09:43:52 surprise kernel: ? usleep_range+0x90/0x90 Nov 27 09:43:52 surprise kernel: schedule+0x55/0xc0 Nov 27 09:43:52 surprise kernel: schedule_timeout+0x10f/0x160 Nov 27 09:43:52 surprise kernel: ? do_sync_core+0x1d/0x20 Nov 27 09:43:52 surprise kernel: __wait_for_common+0xa8/0x150 Nov 27 09:43:52 surprise kernel: wait_for_completion+0x24/0x30 Nov 27 09:43:52 surprise kernel: __wait_rcu_gp+0x11b/0x120 Nov 27 09:43:52 surprise kernel: synchronize_rcu+0x67/0x70 Nov 27 09:43:52 surprise kernel: ? __call_rcu+0x250/0x250 Nov 27 09:43:52 surprise kernel: ? __bpf_trace_rcu_utilization+0x10/0x10 Nov 27 09:43:52 surprise kernel: account_event+0x1e8/0x1f0 Nov 27 09:43:52 surprise kernel: perf_event_alloc+0x77e/0x920 Nov 27 09:43:52 surprise kernel: ? kvm_perf_overflow+0x40/0x40 [kvm] Nov 27 09:43:52 surprise kernel: perf_event_create_kernel_counter.part.0+0x21/0x160 Nov 27 09:43:52 surprise kernel: perf_event_create_kernel_counter+0xf/0x20 Nov 27 09:43:52 surprise kernel: pmc_reprogram_counter+0x105/0x190 [kvm] Nov 27 09:43:52 surprise kernel: reprogram_gp_counter+0x194/0x210 [kvm] Nov 27 09:43:52 surprise kernel: amd_pmu_set_msr+0x17d/0x190 [kvm_amd] Nov 27 09:43:52 surprise kernel: kvm_pmu_set_msr+0x4e/0x60 [kvm] Nov 27 09:43:52 surprise kernel: kvm_set_msr_common+0x4cc/0xf00 [kvm] Nov 27 09:43:52 surprise kernel: svm_set_msr+0x39d/0x6e0 [kvm_amd] Nov 27 09:43:52 surprise kernel: __kvm_set_msr+0x8a/0x150 [kvm] Nov 27 09:43:52 surprise kernel: kvm_emulate_wrmsr+0x3c/0x120 [kvm] Nov 27 09:43:52 surprise kernel: handle_exit+0x39a/0x420 [kvm_amd] Nov 27 09:43:52 surprise kernel: ? kvm_set_cr8+0x22/0x40 [kvm] Nov 27 09:43:52 surprise kernel: vcpu_enter_guest+0x862/0xd90 [kvm] Nov 27 09:43:52 surprise kernel: ? kvm_apic_has_interrupt+0x41/0x80 [kvm] Nov 27 09:43:52 surprise kernel: ? kvm_cpu_has_interrupt+0x7a/0x90 [kvm] Nov 27 09:43:52 surprise kernel: ? kvm_vcpu_has_events+0x134/0x190 [kvm] Nov 27 09:43:52 surprise kernel: vcpu_run+0x76/0x240 [kvm] Nov 27 09:43:52 surprise kernel: kvm_arch_vcpu_ioctl_run+0x9f/0x2b0 [kvm] Nov 27 09:43:52 surprise kernel: kvm_vcpu_ioctl+0x247/0x600 [kvm] Nov 27 09:43:52 surprise kernel: ksys_ioctl+0x8e/0xc0 Nov 27 09:43:52 surprise kernel: __x64_sys_ioctl+0x1a/0x20 Nov 27 09:43:52 surprise kernel: do_syscall_64+0x49/0xc0 Nov 27 09:43:52 surprise kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Nov 27 09:43:52 surprise kernel: RIP: 0033:0x7fc2853b16d7 Nov 27 09:43:52 surprise kernel: Code: Bad RIP value. Nov 27 09:43:52 surprise kernel: RSP: 002b:7fc276220068 EFLAGS: 0246 ORIG_RAX: 0010 Nov 27 09:43:52 surprise kernel: RAX: ffda RBX: ae80 RCX: 7fc2853b16d7 Nov 27 09:43:52 surprise kernel: RDX: RSI: ae80 RDI: 0023 Nov 27 09:43:52 surprise kernel: RBP: R08: 564557831eb0 R09: ffe1 Nov 27 09:43:52 surprise kernel: R10: 0001 R11: 0246 R12: 564557ba8ad0 Nov 27 09:43:52 surprise kernel: R13: 564556b5c040 R14: 7fc28901 R15: -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905984 Title: Hard lockup with "watchdog: BUG: soft lockup - CPU#10 stuck for 22s! [Xorg:13615]" in the journal To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-450/+bug/1905984/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905984] [NEW] Hard lockup with "watchdog: BUG: soft lockup - CPU#10 stuck for 22s! [Xorg:13615]" in the journal
Public bug reported: The system was restored from hibernation this morning, but the issue did not exhibit for ~30 minutes after "boot". I have also seen hard locks without hibernation (but they have never produced any journal output, so may be a different issue). Examining `journalctl -k`, I see something like the below repeated every few seconds. I've attached `journalctl -k`s output (truncated from unhibernate this morning). Nov 27 09:42:09 surprise kernel: watchdog: BUG: soft lockup - CPU#10 stuck for 22s! [Xorg:13615] Nov 27 09:42:09 surprise kernel: Modules linked in: hid_logitech unix_diag vhost_net tap vhost_vsock vmw_vsock_virtio_transport_common vhost vsock vhost_iotlb binfmt_misc veth nft_masq zfs(PO) zunicode(PO) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) zlua(PO) xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc aufs rdma_ucm ib_uverbs rdma_cm iw_cm ib_cm ib_core overlay nls_iso8859_1 snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_usb_audio snd_hda_codec uvcvideo snd_hda_core snd_usbmidi_lib videobuf2_vmalloc videobuf2_memops snd_hwdep videobuf2_v4l2 snd_seq_midi videobuf2_common snd_seq_midi_event snd_rawmidi edac_mce_amd videodev snd_pcm kvm_amd snd_seq mc input_leds kvm snd_seq_device joydev snd_timer ucsi_ccg typec_ucsi snd typec soundcore ccp rapl wmi_bmof k10temp efi_pstore mac_hid nvidia_uvm(OE) Nov 27 09:42:09 surprise kernel: sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs blake2b_generic xor raid6_pq libcrc32c dm_crypt hid_logitech_hidpp hid_microsoft hid_logitech_dj ff_memless hid_generic usbhid hid nvidia_drm(POE) nvidia_modeset(POE) nvidia(POE) crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drm_kms_helper aesni_intel syscopyarea sysfillrect sysimgblt fb_sys_fops crypto_simd cec cryptd glue_helper rc_core drm i2c_piix4 i2c_nvidia_gpu nvme r8169 ahci xhci_pci nvme_core realtek xhci_pci_renesas libahci wmi gpio_amdpt gpio_generic Nov 27 09:42:09 surprise kernel: CPU: 10 PID: 13615 Comm: Xorg Tainted: P OE 5.8.0-29-generic #31-Ubuntu Nov 27 09:42:09 surprise kernel: Hardware name: Gigabyte Technology Co., Ltd. B450M DS3H/B450M DS3H-CF, BIOS F4 01/25/2019 Nov 27 09:42:09 surprise kernel: RIP: 0010:_nv001550kms+0x16/0x70 [nvidia_modeset] Nov 27 09:42:09 surprise kernel: Code: 53 28 e9 0e fe ff ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 41 54 55 49 89 fc 53 48 8d 5f 38 48 89 f5 48 89 df e8 9a 48 00 00 <84> c0 75 46 49 8b 54 24 40 48 39 d3 48 8b 42 18 74 17 48 39 c5 75 Nov 27 09:42:09 surprise kernel: RSP: 0018:b479cf577910 EFLAGS: 0287 Nov 27 09:42:09 surprise kernel: RAX: c1a15800 RBX: 9c30b2233640 RCX: 001f1623 Nov 27 09:42:09 surprise kernel: RDX: 9c2fd6186ac8 RSI: 9c2d33ef4008 RDI: 9c30b2233640 Nov 27 09:42:09 surprise kernel: RBP: 9c2d33ef4008 R08: b479cf577830 R09: 0001 Nov 27 09:42:09 surprise kernel: R10: 9c2cd20fbbc0 R11: 001a R12: 9c30b2233608 Nov 27 09:42:09 surprise kernel: R13: R14: 9c2d33ef4008 R15: 0002 Nov 27 09:42:09 surprise kernel: FS: 7f82d95e4a40() GS:9c30cf08() knlGS: Nov 27 09:42:09 surprise kernel: CS: 0010 DS: ES: CR0: 80050033 Nov 27 09:42:09 surprise kernel: CR2: 55683e860ff8 CR3: 00037893c000 CR4: 003406e0 Nov 27 09:42:09 surprise kernel: Call Trace: Nov 27 09:42:09 surprise kernel: ? _nv001123kms+0xb2/0x400 [nvidia_modeset] Nov 27 09:42:09 surprise kernel: ? _nv000732kms+0x1e/0x80 [nvidia_modeset] Nov 27 09:42:09 surprise kernel: ? _nv002395kms+0x112/0x130 [nvidia_modeset] Nov 27 09:42:09 surprise kernel: ? _nv000515kms+0xd1/0xe1 [nvidia_modeset] Nov 27 09:42:09 surprise kernel: ? _nv19kms+0x230/0x6fc [nvidia_modeset] Nov 27 09:42:09 surprise kernel: ? kfree+0xb8/0x220 Nov 27 09:42:09 surprise kernel: ? os_free_mem+0x22/0x30 [nvidia] Nov 27 09:42:09 surprise kernel: ? _nv008503rm+0xbe/0x100 [nvidia] Nov 27 09:42:09 surprise kernel: ? _nv035038rm+0x2a/0x60 [nvidia] Nov 27 09:42:09 surprise kernel: ? _nv030385rm+0x23/0x40 [nvidia] Nov 27 09:42:09 surprise kernel: ? _nv033621rm+0x58/0xf0 [nvidia] Nov 27 09:42:09 surprise kernel: ? _nv008135rm+0x33c/0x3f0 [nvidia] Nov 27 09:42:09 surprise kernel: ? os_acquire_spinlock+0x12/0x30 [nvidia] Nov 27 09:42:09 surprise kernel: ? os_release_spinlock+0x1a/0x20 [nvidia] Nov 27 09:42:09 surprise kernel: ? _nv037019rm+0xa1/0x190 [nvidia] Nov 27 09:42:09 surprise kernel: ? nvidia_modeset_rm_ops_free_stack+0x1d/0x20 [nvidia] Nov 27 09:42:09 surprise kernel: ? _nv002759kms+0x12a0/0x1470 [nvidia_modeset] Nov 27 09:42:09 surprise kernel: ? mpol_rebind_preferred+0x1c0/0x1c0 Nov 27 09:42:09 surprise kernel: ? _nv000531kms+0x50/0x50
[Bug 1905281] Re: /etc/hosts data is not properly mapped
Hi Aman, Thanks for the bug report! Configuring the FQDN to point at the loopback address has been cloud-init's behaviour since 2011 on Ubuntu (https://github.com/canonical/cloud- init/commit/6d25c040ee566f6ef85352d7b52eb5947230f78a) and 2012 on Red Hat (https://github.com/canonical/cloud- init/commit/09f6384ac5694be18bef4872c9f19b9601b48f8b). This suggests to me that this is a reasonable default. Given this, and that people are likely relying on this default behaviour, I don't think we want to change the default behaviour here. cloud-init does have some ways of modifying this behaviour already. If you can give a few more details about the problem you're trying to solve, we can see if any of those fit, or if we need to dig into perhaps making this behaviour more configurable. (Once you've responded, please move this back to New. :) Thanks! Dan ** Changed in: cloud-init (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905281 Title: /etc/hosts data is not properly mapped To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1905281/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1874464] Re: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out
Trace from that mainline kernel: kernel: [ cut here ] kernel: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out kernel: WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:442 dev_watchdog+0x24c/0x250 kernel: Modules linked in: scsi_transport_iscsi binfmt_misc veth nft_masq xt_comment iptable_mangle iptable_nat bpfilter dummy xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink rdma_ucm ib_uverbs rdma_cm iw_cm ib_cm ib_core overlay snd_hda_codec_realtek nls_iso8859_1 snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_usb_audio snd_hda_core snd_usbmidi_lib snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event uvcvideo snd_raw> kernel: autofs4 btrfs blake2b_generic xor raid6_pq libcrc32c dm_crypt hid_logitech_hidpp hid_microsoft ff_memless hid_logitech_dj hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper i2c_piix4 r8169 nvme ahci i2c_nvidia_gpu xhci_pci realtek nvme_core libahci xhci_pci_renesas wmi gpio_amdpt gpio_generic kernel: CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.10.0-051000rc2-generic #202011012330 kernel: Hardware name: Gigabyte Technology Co., Ltd. B450M DS3H/B450M DS3H-CF, BIOS F4 01/25/2019 kernel: RIP: 0010:dev_watchdog+0x24c/0x250 kernel: Code: 5a 94 fd ff eb ab 4c 89 ff c6 05 e2 58 4d 01 01 e8 99 4c fa ff 44 89 e9 4c 89 fe 48 c7 c7 48 35 48 97 48 89 c2 e8 2a 69 16 00 <0f> 0b eb 8c 0f 1f 44 00 00 55 48 89 e5 41 57 49 89 ff 41 56 41 55 kernel: RSP: 0018:a5e700210e90 EFLAGS: 00010286 kernel: RAX: RBX: 9a1800d12e00 RCX: kernel: RDX: 9a1b0eea8ca0 RSI: 9a1b0ee98980 RDI: 0300 kernel: RBP: a5e700210ec0 R08: R09: a5e700210c70 kernel: R10: a5e700210c68 R11: 97b52ca8 R12: 9a1800d12e80 kernel: R13: R14: 9a18008164c0 R15: 9a1800816000 kernel: FS: () GS:9a1b0ee8() knlGS: kernel: CS: 0010 DS: ES: CR0: 80050033 kernel: CR2: 55cfd3d2d008 CR3: 000107f48000 CR4: 003506e0 kernel: Call Trace: kernel: kernel: ? pfifo_fast_enqueue+0x150/0x150 kernel: call_timer_fn+0x2e/0x100 kernel: __run_timers.part.0+0x1d8/0x250 kernel: ? ktime_get+0x3e/0xa0 kernel: ? lapic_next_event+0x21/0x30 kernel: ? clockevents_program_event+0x8f/0xe0 kernel: run_timer_softirq+0x2a/0x50 kernel: __do_softirq+0xce/0x281 kernel: asm_call_irq_on_stack+0x12/0x20 kernel: kernel: do_softirq_own_stack+0x3d/0x50 kernel: irq_exit_rcu+0x95/0xd0 kernel: sysvec_apic_timer_interrupt+0x3d/0x90 kernel: asm_sysvec_apic_timer_interrupt+0x12/0x20 kernel: RIP: 0010:cpuidle_enter_state+0xcc/0x360 kernel: Code: 3d e9 64 88 69 e8 64 31 75 ff 49 89 c6 0f 1f 44 00 00 31 ff e8 f5 3c 75 ff 80 7d d7 00 0f 85 01 01 00 00 fb 66 0f 1f 44 00 00 <45> 85 ff 0f 88 0d 01 00 00 49 63 cf 4c 2b 75 c8 48 8d 04 49 48 89 kernel: RSP: 0018:a5e700137e60 EFLAGS: 0246 kernel: RAX: 9a1b0eeac480 RBX: 0002 RCX: 001f kernel: RDX: RSI: 239f5376 RDI: kernel: RBP: a5e700137e98 R08: 0009851dc34e R09: 0400 kernel: R10: 000321ae R11: R12: 9a1801249800 kernel: R13: 97c6c6a0 R14: 0009851dc34e R15: 0002 kernel: cpuidle_enter+0x2e/0x40 kernel: cpuidle_idle_call+0x132/0x1d0 kernel: do_idle+0x7a/0xe0 kernel: cpu_startup_entry+0x20/0x30 kernel: start_secondary+0x90/0xa0 kernel: secondary_startup_64_no_verify+0xb8/0xbb kernel: CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.10.0-051000rc2-generic #202011012330 kernel: Hardware name: Gigabyte Technology Co., Ltd. B450M DS3H/B450M DS3H-CF, BIOS F4 01/25/2019 kernel: Call Trace: kernel: kernel: show_stack+0x52/0x58 kernel: dump_stack+0x70/0x8b kernel: ? dev_watchdog+0x24c/0x250 kernel: __warn.cold+0x24/0x77 kernel: ? dev_watchdog+0x24c/0x250 kernel: report_bug+0xa1/0xc0 kernel: ? __irq_work_queue_local+0x48/0x60 kernel: handle_bug+0x3e/0xa0 kernel: exc_invalid_op+0x19/0x70 kernel: asm_exc_invalid_op+0x12/0x20 kernel: RIP: 0010:dev_watchdog+0x24c/0x250 kernel: Code: 5a 94 fd ff eb ab 4c 89 ff c6 05 e2 58 4d 01 01 e8 99 4c fa ff 44 89 e9 4c 89 fe 48 c7 c7 48 35 48 97 48 89 c2 e8 2a 69 16 00 <0f> 0b eb 8c 0f 1f 44 00 00 55 48 89 e5 41 57 49 89 ff 41 56 41 55 kernel: RSP: 0018:a5e700210e90 EFLAGS: 00010286 kernel: RAX: RBX: 9a1800d12e00 RCX: kernel: RDX: 9a1b0eea8ca0 RSI: 9a1b0ee98980 RDI: 0300 kernel: RBP: a5e700210ec0 R08: R09: a5e700210c70 kernel: R10: a5e700210c68 R11: 97b52ca8 R12: 9a1800d12e80 kernel: R13: R14: 9a18008164c0 R15: 9a1800816000
[Bug 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases
I've just tested, and this doesn't seem to reproduce when launching from a captured image (with 90-hotplug-azure.yaml restored and `cloud-init clean` executed). So I think I've exhausted the ways in which I can attempt to gain more insight into what's happening during the part of boot where this reproduces. I think we're going to need an image published with some debugging built into it (which, hopefully, will continue to reproduce the issue). If https://paste.ubuntu.com/p/qkwmDvRRrB/ is installed and enabled, we should get a whole bunch of udev information, which may shed some light onto what's going on from an ordering POV. I'm not sure if there's any more networking/networkd-specific debugging we should also add. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902960 Title: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1902960/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases
(Added cloud-images for visibility.) ** Also affects: cloud-images Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902960 Title: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1902960/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases
Thanks for the explanation, Dan! I was off down a wrong path, I
appreciate the correction.
I've just downloaded the Azure image from cloud-images.u.c and it
includes this in `/etc/netplan/90-hotplug-azure.yaml`:
# This netplan yaml is delivered in Azure cloud images to support
# attaching and detaching nics after the instance first boot.
# Cloud-init otherwise handles initial boot network configuration in
# /etc/netplan/50-cloud-init.yaml
network:
version: 2
ethernets:
ephemeral:
dhcp4: true
match:
driver: hv_netvsc
name: '!eth0'
optional: true
hotpluggedeth0:
dhcp4: true
match:
driver: hv_netvsc
name: 'eth0'
This file is not present in a booted system, because cloud-init removes
it during boot:
2020-11-09 18:12:09,306 - handlers.py[DEBUG]: start:
azure-ds/maybe_remove_ubuntu_network_config_scripts:
maybe_remove_ubuntu_network_config_scripts
2020-11-09 18:12:09,307 - DataSourceAzure.py[INFO]: Removing Ubuntu extended
network scripts because cloud-init updates Azure network configuration on the
following event: System boot.
2020-11-09 18:12:09,307 - util.py[DEBUG]: Attempting to remove
/etc/netplan/90-hotplug-azure.yaml
2020-11-09 18:12:09,307 - handlers.py[DEBUG]: finish:
azure-ds/maybe_remove_ubuntu_network_config_scripts: SUCCESS:
maybe_remove_ubuntu_network_config_scripts
It does this before the regular cloud-init network configuration is
written, or `netplan generate` is called:
2020-11-09 18:12:09,465 - util.py[DEBUG]: Writing to
/etc/netplan/50-cloud-init.yaml - wb: [644] 603 bytes
2020-11-09 18:12:09,466 - subp.py[DEBUG]: Running command ['netplan',
'generate'] with allowed return codes [0] (shell=False, capture=True)
cloud-init also runs a couple of udevadm commands right after `netplan
generate`:
2020-11-09 18:12:09,813 - subp.py[DEBUG]: Running command ['udevadm',
'test-builtin', 'net_setup_link', '/sys/class/net/eth0'] with allowed return
codes [0] (shell=False, capture=True)
2020-11-09 18:12:09,828 - subp.py[DEBUG]: Running command ['udevadm',
'test-builtin', 'net_setup_link', '/sys/class/net/lo'] with allowed return
codes [0] (shell=False, capture=True)
This all happens before systemd-networkd starts:
Nov 09 18:12:09.956027 focal-1604945439 systemd[1]: Starting Network
Service...
So: I'm not really sure what's going on here. I've tried restoring `90
-hotplug-azure.yaml` and removing `50-cloud-init.yaml`; that doesn't
cause the issue to reproduce on a subsequent boot.
One thing worth noting, that could lead to unexpected state: cloud-init
performs a DHCP on this interface (in order to be able to fetch the
network configuration it is going to apply). It does this in a sandbox
(i.e. it doesn't use system configuration for it), but potentially that
could mean that there's (kernel?) state for that interface which
{udev,network}d interpret in a way that leads to this issue?
** Changed in: cloud-init (Ubuntu)
Status: Incomplete => New
** Changed in: systemd (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1902960
Title:
Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS
resolution in some cases
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1902960/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1903610] Re: the password for default user "ubuntu" in cloud image (with suffix .ova) is random
Hi yhzou, Thanks for using (and testing!) Ubuntu, and for filing this bug. Setting a default password in the cloud-images.ubuntu.com images would make them insecure: any Ubuntu instance launched from them would have a backdoor installed, essentially. There are a couple of options: you could specify user-data to cloud-init which will set the password of the user (see https://cloudinit.readthedocs.io/en/latest/topics/modules.html#users- and-groups for details) or, if you aren't able to specify user-data, then you could look into modifying the image locally to add a backdoor for your testing. As there is no bug in cloud-init, I'm going to mark this as Invalid, but if you have any questions please do feel free to ask. Thanks! Dan ** Changed in: cloud-init (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1903610 Title: the password for default user "ubuntu" in cloud image (with suffix .ova) is random To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1903610/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases
** Changed in: cloud-init (Ubuntu) Status: New => Incomplete ** Changed in: systemd (Ubuntu) Status: Invalid => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902960 Title: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1902960/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases
OK, I've managed to reproduce this (in a non-Juju launched VM). The ordering of these journal lines look suspicious to me: Nov 09 17:41:51.091033 ubuntu systemd[1]: Starting udev Coldplug all Devices... Nov 09 17:41:51.236309 ubuntu systemd[1]: Finished Load Kernel Modules. Nov 09 17:41:51.363482 ubuntu systemd[1]: Finished udev Coldplug all Devices. Because, you guessed it, hv_netvsc is shipped as a kernel module: $ lsmod | grep hv_netvsc hv_netvsc 81920 0 So my assumption is that udev coldplugging of the network device is happening before the driver is loaded, and so (unsurprisingly :) it doesn't find the driver. I suspect that adding an `After=systemd-modules-load.service` to systemd-udev-trigger-service addresses the issue, but as this only reproduces on first boot this is difficult to test. Given the above (and the fact that cloud-init doesn't run for another ~5s after these lines), I _think_ this is a systemd/kernel interface issue, not a cloud-init issue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902960 Title: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1902960/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
When investigating another issue, I found this line in my journal, repeated a few times: nm-dispatcher[3938]: /etc/network/if-up.d/resolved: 12: mystatedir: not found Not sure if that's related, but it seems suspicious at least. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases
Hey folks, Thanks for the report! If someone could run `cloud-init collect-logs` on an affected instance, and upload the produced tarball to this bug, we can dig into it further. The contents of /etc/netplan would also be very handy. (Once attached, please move this back to New.) Cheers, Dan ** Changed in: cloud-init (Ubuntu) Status: Confirmed => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902960 Title: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1902960/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1874464] Re: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out
Hi Kai-Heng, Here is the (much longer) trace from that kernel. Thanks! kernel: [ cut here ] kernel: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out kernel: WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:442 dev_watchdog+0x24c/0x250 kernel: Modules linked in: scsi_transport_iscsi binfmt_misc veth nft_masq xt_comment iptable_mangle iptable_nat bpfilter dummy xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink rdma_ucm ib_uverbs rdma_cm iw_cm ib_cm ib_core overlay snd_hda_codec_realtek nls_iso8859> kernel: autofs4 btrfs blake2b_generic xor raid6_pq libcrc32c dm_crypt hid_logitech_hidpp hid_microsoft ff_memless hid_logitech_dj hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper i2c_piix4 r8169 nvme ahci i2c_nvidia_gpu xhci_pci realtek nvme_core libahci xhci_pci_renesas wmi gpio_amdpt gpio_generic kernel: CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.10.0-051000rc2-generic #202011012330 kernel: Hardware name: Gigabyte Technology Co., Ltd. B450M DS3H/B450M DS3H-CF, BIOS F4 01/25/2019 kernel: RIP: 0010:dev_watchdog+0x24c/0x250 kernel: Code: 5a 94 fd ff eb ab 4c 89 ff c6 05 e2 58 4d 01 01 e8 99 4c fa ff 44 89 e9 4c 89 fe 48 c7 c7 48 35 48 97 48 89 c2 e8 2a 69 16 00 <0f> 0b eb 8c 0f 1f 44 00 00 55 48 89 e5 41 57 49 89 ff 41 56 41 55 kernel: RSP: 0018:a5e700210e90 EFLAGS: 00010286 kernel: RAX: RBX: 9a1800d12e00 RCX: kernel: RDX: 9a1b0eea8ca0 RSI: 9a1b0ee98980 RDI: 0300 kernel: RBP: a5e700210ec0 R08: R09: a5e700210c70 kernel: R10: a5e700210c68 R11: 97b52ca8 R12: 9a1800d12e80 kernel: R13: R14: 9a18008164c0 R15: 9a1800816000 kernel: FS: () GS:9a1b0ee8() knlGS: kernel: CS: 0010 DS: ES: CR0: 80050033 kernel: CR2: 55cfd3d2d008 CR3: 000107f48000 CR4: 003506e0 kernel: Call Trace: kernel: kernel: ? pfifo_fast_enqueue+0x150/0x150 kernel: call_timer_fn+0x2e/0x100 kernel: __run_timers.part.0+0x1d8/0x250 kernel: ? ktime_get+0x3e/0xa0 kernel: ? lapic_next_event+0x21/0x30 kernel: ? clockevents_program_event+0x8f/0xe0 kernel: run_timer_softirq+0x2a/0x50 kernel: __do_softirq+0xce/0x281 kernel: asm_call_irq_on_stack+0x12/0x20 kernel: kernel: do_softirq_own_stack+0x3d/0x50 kernel: irq_exit_rcu+0x95/0xd0 kernel: sysvec_apic_timer_interrupt+0x3d/0x90 kernel: asm_sysvec_apic_timer_interrupt+0x12/0x20 kernel: RIP: 0010:cpuidle_enter_state+0xcc/0x360 kernel: Code: 3d e9 64 88 69 e8 64 31 75 ff 49 89 c6 0f 1f 44 00 00 31 ff e8 f5 3c 75 ff 80 7d d7 00 0f 85 01 01 00 00 fb 66 0f 1f 44 00 00 <45> 85 ff 0f 88 0d 01 00 00 49 63 cf 4c 2b 75 c8 48 8d 04 49 48 89 kernel: RSP: 0018:a5e700137e60 EFLAGS: 0246 kernel: RAX: 9a1b0eeac480 RBX: 0002 RCX: 001f kernel: RDX: RSI: 239f5376 RDI: kernel: RBP: a5e700137e98 R08: 0009851dc34e R09: 0400 kernel: R10: 000321ae R11: R12: 9a1801249800 kernel: R13: 97c6c6a0 R14: 0009851dc34e R15: 0002 kernel: cpuidle_enter+0x2e/0x40 kernel: cpuidle_idle_call+0x132/0x1d0 kernel: do_idle+0x7a/0xe0 kernel: cpu_startup_entry+0x20/0x30 kernel: start_secondary+0x90/0xa0 kernel: secondary_startup_64_no_verify+0xb8/0xbb kernel: CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.10.0-051000rc2-generic #202011012330 kernel: Hardware name: Gigabyte Technology Co., Ltd. B450M DS3H/B450M DS3H-CF, BIOS F4 01/25/2019 kernel: Call Trace: kernel: kernel: show_stack+0x52/0x58 kernel: dump_stack+0x70/0x8b kernel: ? dev_watchdog+0x24c/0x250 kernel: __warn.cold+0x24/0x77 kernel: ? dev_watchdog+0x24c/0x250 kernel: report_bug+0xa1/0xc0 kernel: ? __irq_work_queue_local+0x48/0x60 kernel: handle_bug+0x3e/0xa0 kernel: exc_invalid_op+0x19/0x70 kernel: asm_exc_invalid_op+0x12/0x20 kernel: RIP: 0010:dev_watchdog+0x24c/0x250 kernel: Code: 5a 94 fd ff eb ab 4c 89 ff c6 05 e2 58 4d 01 01 e8 99 4c fa ff 44 89 e9 4c 89 fe 48 c7 c7 48 35 48 97 48 89 c2 e8 2a 69 16 00 <0f> 0b eb 8c 0f 1f 44 00 00 55 48 89 e5 41 57 49 89 ff 41 56 41 55 kernel: RSP: 0018:a5e700210e90 EFLAGS: 00010286 kernel: RAX: RBX: 9a1800d12e00 RCX: kernel: RDX: 9a1b0eea8ca0 RSI: 9a1b0ee98980 RDI: 0300 kernel: RBP: a5e700210ec0 R08: R09: a5e700210c70 kernel: R10: a5e700210c68 R11: 97b52ca8 R12: 9a1800d12e80 kernel: R13: R14: 9a18008164c0 R15: 9a1800816000 kernel: ? pfifo_fast_enqueue+0x150/0x150 kernel: call_timer_fn+0x2e/0x100 kernel: __run_timers.part.0+0x1d8/0x250 kernel: ? ktime_get+0x3e/0xa0 kernel: ?
[Bug 1902356] Re: package grub-legacy-ec2 20.3-2-g371b392c-0ubuntu1~16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
Hi Alex,
Thanks for filing this bug report! I just launched a trusty instance,
and both of the entries in menu.lst look like they should not trigger
this bug ("root\t(hd0)"). I then successfully upgraded the instance to
xenial without seeing this issue, and I still see "root\t(hd0)" in all
the menu.lst entries.
Can you give us some more details about how we might be able to
reproduce this? In particular, instance type and original AMI would be
very helpful. Once you've done so, please move this bug back to New.
Thanks!
Dan
** Changed in: cloud-init (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1902356
Title:
package grub-legacy-ec2 20.3-2-g371b392c-0ubuntu1~16.04.1 failed to
install/upgrade: subprocess installed post-installation script
returned error exit status 1
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1902356/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1473527] Re: module ssh-authkey-fingerprints fails Input/output error: /dev/console
The code causing the failure (which Paride linked to) does specifically know that the output is destined for /dev/console: if console: conpath = "/dev/console" if os.path.exists(conpath): with open(conpath, 'w') as wfh: wfh.write(text) wfh.flush() I agree that we should not generically ignore issues with writing, but this would be a targetted fix for specifically this case. The general issue here, AIUI, is that the kernel command line and the cloud have to be in agreement about how /dev/console is configured: if the kernel command line specifies a console then the kernel will configure one, even if there is no corresponding console provided by the cloud. On first boot, users have no way of aligning the kernel's default configured console with the console that the cloud provides (or, rather, the lack thereof), so cannot do anything to avoid this traceback. (Cloud-specific Ubuntu images generally have this configured correctly, but if you're bringing a generic cloud image to $platform, then there's no guarantee that they will be aligned.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1473527 Title: module ssh-authkey-fingerprints fails Input/output error: /dev/console To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1473527/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1874464] Re: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out
Still seeing this with that kernel: kernel: [ cut here ] kernel: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out kernel: WARNING: CPU: 8 PID: 0 at net/sched/sch_generic.c:442 dev_watchdog+0x25b/0x270 kernel: Modules linked in: xt_comment iptable_mangle iptable_nat bpfilter xt_CHECKSUM xt_MASQUERADE dummy xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfne> kernel: xor raid6_pq libcrc32c dm_crypt hid_logitech_hidpp hid_microsoft hid_logitech_dj ff_memless hid_generic usbhid hid nvidia_drm(POE) nvidia_modeset(POE) nvidia(POE) drm_kms_helper crct10dif_pclmul syscopyarea crc32_pclmul sysfillrect ghash_clmulni_i> kernel: CPU: 8 PID: 0 Comm: swapper/8 Tainted: P OE 5.8.0-24-generic #25~lp1874464 kernel: Hardware name: Gigabyte Technology Co., Ltd. B450M DS3H/B450M DS3H-CF, BIOS F4 01/25/2019 kernel: RIP: 0010:dev_watchdog+0x25b/0x270 kernel: Code: 85 c0 75 e5 eb 9c 4c 89 ff c6 05 36 85 1c 01 01 e8 2a 93 fa ff 44 89 e9 4c 89 fe 48 c7 c7 50 7c e8 8c 48 89 c2 e8 ca 30 64 ff <0f> 0b e9 7a ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f kernel: RSP: 0018:bd1800348e78 EFLAGS: 00010286 kernel: RAX: RBX: 95808d02dc00 RCX: 95808ee18cd8 kernel: RDX: ffd8 RSI: 0027 RDI: 95808ee18cd0 kernel: RBP: bd1800348ea8 R08: 0004 R09: 0554 kernel: R10: R11: 0001 R12: 95808d02dc80 kernel: R13: R14: 95808c9be480 R15: 95808c9be000 kernel: FS: () GS:95808ee0() knlGS: kernel: CS: 0010 DS: ES: CR0: 80050033 kernel: CR2: 7ffd799aee88 CR3: 0003ac6d8000 CR4: 003406e0 kernel: Call Trace: kernel: kernel: ? pfifo_fast_enqueue+0x150/0x150 kernel: call_timer_fn+0x32/0x130 kernel: __run_timers.part.0+0x184/0x280 kernel: ? lapic_next_event+0x21/0x30 kernel: ? clockevents_program_event+0x8f/0xe0 kernel: run_timer_softirq+0x2a/0x50 kernel: __do_softirq+0xd0/0x2a1 kernel: asm_call_irq_on_stack+0x12/0x20 kernel: kernel: do_softirq_own_stack+0x3d/0x50 kernel: irq_exit_rcu+0x95/0xd0 kernel: sysvec_apic_timer_interrupt+0x3b/0x90 kernel: asm_sysvec_apic_timer_interrupt+0x12/0x20 kernel: RIP: 0010:cpuidle_enter_state+0xb7/0x3f0 kernel: Code: 4f fb c6 73 e8 5a 5d 74 ff 48 89 45 d0 0f 1f 44 00 00 31 ff e8 0a 69 74 ff 80 7d c7 00 0f 85 d3 01 00 00 fb 66 0f 1f 44 00 00 <45> 85 e4 0f 88 df 01 00 00 49 63 d4 48 8d 04 52 48 8d 0c d5 00 00 kernel: RSP: 0018:bd1800167e48 EFLAGS: 0246 kernel: RAX: 95808ee2c6c0 RBX: 958079782400 RCX: 001f kernel: RDX: RSI: 239f5376 RDI: kernel: RBP: bd1800167e88 R08: 000853f09bec R09: kernel: R10: 0a06 R11: 95808ee2b364 R12: 0002 kernel: R13: 8d577ba0 R14: 0002 R15: kernel: ? cpuidle_enter_state+0xa6/0x3f0 kernel: cpuidle_enter+0x2e/0x40 kernel: cpuidle_idle_call+0x145/0x200 kernel: do_idle+0x7a/0xe0 kernel: cpu_startup_entry+0x20/0x30 kernel: start_secondary+0xe6/0x100 kernel: secondary_startup_64+0xb6/0xc0 kernel: ---[ end trace 7dcae081a07b21ec ]--- -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1874464 Title: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1874464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1885527] Re: cloud-init regenerating ssh-keys
** Changed in: cloud-init (Ubuntu) Status: Confirmed => In Progress ** Changed in: cloud-init (Ubuntu) Assignee: (unassigned) => Markus Schade (lp-markusschade) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1885527 Title: cloud-init regenerating ssh-keys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1885527/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1892447] Re: Why ignore new name server if 3 name servers exists
** Changed in: cloud-init (Ubuntu) Status: New => Triaged ** Changed in: cloud-init (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1892447 Title: Why ignore new name server if 3 name servers exists To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1892447/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1900904] Re: netplan yaml for rpi groovy server prevents usb ethernet
(Oh, and I should say: please move this back to New once you've attached the tarball!) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1900904 Title: netplan yaml for rpi groovy server prevents usb ethernet To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1900904/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1900904] Re: netplan yaml for rpi groovy server prevents usb ethernet
Hey Paul, Thanks for the bug report! If you could run `cloud-init collect-logs` on an affected machine and attach the tarball here, we can dig into this more based on that info. Cheers, Dan ** Changed in: cloud-init (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1900904 Title: netplan yaml for rpi groovy server prevents usb ethernet To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1900904/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1874464] Re: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out
On Fri, Oct 16, 2020 at 03:05:09AM -, Kai-Heng Feng wrote: > Can you please test this kernel: > https://people.canonical.com/~khfeng/lp1896576/ Thanks for the kernel! Still seeing this, unfortunately: kernel: [ cut here ] kernel: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out kernel: WARNING: CPU: 8 PID: 0 at net/sched/sch_generic.c:442 dev_watchdog+0x25e/0x270 kernel: Modules linked in: nft_compat nft_counter nft_chain_nat nf_tables nfnetlink ipt_REJECT nf_reject_ipv4 xt_conntrack xt_MASQUERADE xt_CHECKSUM xt_comment xt_tcpudp iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bpfilter > kernel: bridge stp llc arp_tables parport_pc ppdev lp parport drm ip_tables x_tables autofs4 btrfs blake2b_generic xor zstd_compress raid6_pq libcrc32c dm_crypt hid_logitech_hidpp hid_microsoft hid_logitech_dj ff_memless hid_generic usbhid hid crct10dif_p> kernel: CPU: 8 PID: 0 Comm: swapper/8 Tainted: P OE 5.6.0-2030-oem #30~lp1896576 kernel: Hardware name: Gigabyte Technology Co., Ltd. B450M DS3H/B450M DS3H-CF, BIOS F4 01/25/2019 kernel: RIP: 0010:dev_watchdog+0x25e/0x270 kernel: Code: 85 c0 75 e5 eb 9c 4c 89 ff c6 05 1f a5 e7 00 01 e8 a7 00 fb ff 44 89 e9 4c 89 fe 48 c7 c7 f0 3b 07 9e 48 89 c2 e8 57 95 6e ff <0f> 0b e9 7a ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 kernel: RSP: 0018:b0eb40344e30 EFLAGS: 00010286 kernel: RAX: RBX: 89ae4bd0f200 RCX: 0007 kernel: RDX: 0007 RSI: 0096 RDI: 89ae4f019800 kernel: RBP: b0eb40344e60 R08: 0545 R09: 0004 kernel: R10: R11: 0001 R12: 0001 kernel: R13: R14: 89ae4a660480 R15: 89ae4a66 kernel: FS: () GS:89ae4f00() knlGS: kernel: CS: 0010 DS: ES: CR0: 80050033 kernel: CR2: 562e21d43b88 CR3: 00023960a000 CR4: 003406e0 kernel: Call Trace: kernel: kernel: ? pfifo_fast_enqueue+0x150/0x150 kernel: call_timer_fn+0x32/0x130 kernel: __run_timers.part.0+0x180/0x280 kernel: ? timerqueue_add+0x9b/0xb0 kernel: ? enqueue_hrtimer+0x3d/0x90 kernel: ? ktime_get+0x3e/0xa0 kernel: run_timer_softirq+0x2a/0x50 kernel: __do_softirq+0xe1/0x2d6 kernel: ? hrtimer_interrupt+0x13b/0x220 kernel: irq_exit+0xae/0xb0 kernel: smp_apic_timer_interrupt+0x7b/0x140 kernel: apic_timer_interrupt+0xf/0x20 kernel: kernel: RIP: 0010:cpuidle_enter_state+0xca/0x3e0 kernel: Code: ff e8 fa 69 7e ff 80 7d c7 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 ea 02 00 00 31 ff e8 7d ed 84 ff fb 66 0f 1f 44 00 00 <45> 85 e4 0f 88 3f 02 00 00 49 63 d4 4c 8b 7d d0 4c 2b 7d c8 48 8d kernel: RSP: 0018:b0eb40167e38 EFLAGS: 0246 ORIG_RAX: ff13 kernel: RAX: 89ae4f02ce00 RBX: 89ae3b54f800 RCX: 001f kernel: RDX: RSI: 239f541c RDI: kernel: RBP: b0eb40167e78 R08: 00090b4aca5a R09: 0e17 kernel: R10: 89ae4f02bac4 R11: 89ae4f02baa4 R12: 0002 kernel: R13: 9e378700 R14: 0002 R15: 89ae3b54f800 kernel: ? cpuidle_enter_state+0xa6/0x3e0 kernel: cpuidle_enter+0x2e/0x40 kernel: call_cpuidle+0x23/0x40 kernel: do_idle+0x1e7/0x280 kernel: cpu_startup_entry+0x20/0x30 kernel: start_secondary+0x167/0x1c0 kernel: secondary_startup_64+0xa4/0xb0 kernel: ---[ end trace aa1f3700fccaa705 ]--- -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1874464 Title: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1874464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1874464] Re: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out
Actually, looks like I spoke too soon. I just upgraded to 5.8.0-22-generic and I'm seeing the issue still: Oct 13 10:43:37 surprise kernel: [ cut here ] Oct 13 10:43:37 surprise kernel: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out Oct 13 10:43:37 surprise kernel: WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:442 dev_watchdog+0x25b/0x270 Oct 13 10:43:37 surprise kernel: Modules linked in: nft_compat ipt_REJECT nf_reject_ipv4 xt_conntrack nft_counter xt_MASQUERADE xt_CHECKSUM xt_comment xt_tcpudp iptable_mangle iptable_nat bpfilter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink > Oct 13 10:43:37 surprise kernel: xor raid6_pq libcrc32c dm_crypt hid_logitech_hidpp hid_microsoft hid_logitech_dj ff_memless hid_generic usbhid hid nvidia_drm(POE) nvidia_modeset(POE) nvidia(POE) drm_kms_helper syscopyarea sysfillrect sysimgblt crct10dif_pclmul crc32_pclmul ghash> Oct 13 10:43:37 surprise kernel: CPU: 1 PID: 0 Comm: swapper/1 Tainted: P OE 5.8.0-22-generic #23-Ubuntu Oct 13 10:43:37 surprise kernel: Hardware name: Gigabyte Technology Co., Ltd. B450M DS3H/B450M DS3H-CF, BIOS F4 01/25/2019 Oct 13 10:43:37 surprise kernel: RIP: 0010:dev_watchdog+0x25b/0x270 Oct 13 10:43:37 surprise kernel: Code: 85 c0 75 e5 eb 9c 4c 89 ff c6 05 46 85 1c 01 01 e8 2a 93 fa ff 44 89 e9 4c 89 fe 48 c7 c7 48 7a e8 84 48 89 c2 e8 da 30 64 ff <0f> 0b e9 7a ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f Oct 13 10:43:37 surprise kernel: RSP: 0018:b770401dce78 EFLAGS: 00010286 Oct 13 10:43:37 surprise kernel: RAX: RBX: 8ed4b848a000 RCX: 8ed4cee58cd8 Oct 13 10:43:37 surprise kernel: RDX: ffd8 RSI: 0027 RDI: 8ed4cee58cd0 Oct 13 10:43:37 surprise kernel: RBP: b770401dcea8 R08: 0004 R09: 0551 Oct 13 10:43:37 surprise kernel: R10: R11: 0001 R12: 8ed4b848a080 Oct 13 10:43:37 surprise kernel: R13: R14: 8ed4b8952480 R15: 8ed4b8952000 Oct 13 10:43:37 surprise kernel: FS: () GS:8ed4cee4() knlGS: Oct 13 10:43:37 surprise kernel: CS: 0010 DS: ES: CR0: 80050033 Oct 13 10:43:37 surprise kernel: CR2: 7f738e845d90 CR3: 00010960a000 CR4: 003406e0 Oct 13 10:43:37 surprise kernel: Call Trace: Oct 13 10:43:37 surprise kernel: Oct 13 10:43:37 surprise kernel: ? pfifo_fast_enqueue+0x150/0x150 Oct 13 10:43:37 surprise kernel: call_timer_fn+0x32/0x130 Oct 13 10:43:37 surprise kernel: __run_timers.part.0+0x184/0x280 Oct 13 10:43:37 surprise kernel: ? lapic_next_event+0x21/0x30 Oct 13 10:43:37 surprise kernel: ? clockevents_program_event+0x8f/0xe0 Oct 13 10:43:37 surprise kernel: run_timer_softirq+0x2a/0x50 Oct 13 10:43:37 surprise kernel: __do_softirq+0xd0/0x2a1 Oct 13 10:43:37 surprise kernel: asm_call_irq_on_stack+0x12/0x20 Oct 13 10:43:37 surprise kernel: Oct 13 10:43:37 surprise kernel: do_softirq_own_stack+0x3d/0x50 Oct 13 10:43:37 surprise kernel: irq_exit_rcu+0x95/0xd0 Oct 13 10:43:37 surprise kernel: sysvec_apic_timer_interrupt+0x3b/0x90 Oct 13 10:43:37 surprise kernel: asm_sysvec_apic_timer_interrupt+0x12/0x20 Oct 13 10:43:37 surprise kernel: RIP: 0010:cpuidle_enter_state+0xb7/0x3f0 Oct 13 10:43:37 surprise kernel: Code: 5f fb c6 7b e8 6a 5d 74 ff 48 89 45 d0 0f 1f 44 00 00 31 ff e8 1a 69 74 ff 80 7d c7 00 0f 85 d3 01 00 00 fb 66 0f 1f 44 00 00 <45> 85 e4 0f 88 df 01 00 00 49 63 d4 48 8d 04 52 48 8d 0c d5 00 00 Oct 13 10:43:37 surprise kernel: RSP: 0018:b7704012fe48 EFLAGS: 0246 Oct 13 10:43:37 surprise kernel: RAX: 8ed4cee6c6c0 RBX: 8ed4cc7cf800 RCX: 001f Oct 13 10:43:37 surprise kernel: RDX: RSI: 239f52d0 RDI: Oct 13 10:43:37 surprise kernel: RBP: b7704012fe88 R08: 00073205d070 R09: Oct 13 10:43:37 surprise kernel: R10: 3cd7 R11: 8ed4cee6b364 R12: 0002 Oct 13 10:43:37 surprise kernel: R13: 85577ba0 R14: 0002 R15: Oct 13 10:43:37 surprise kernel: ? cpuidle_enter_state+0xa6/0x3f0 Oct 13 10:43:37 surprise kernel: cpuidle_enter+0x2e/0x40 Oct 13 10:43:37 surprise kernel: cpuidle_idle_call+0x145/0x200 Oct 13 10:43:37 surprise kernel: do_idle+0x7a/0xe0 Oct 13 10:43:37 surprise kernel: cpu_startup_entry+0x20/0x30 Oct 13 10:43:37 surprise kernel: start_secondary+0xe6/0x100 Oct 13 10:43:37 surprise kernel: secondary_startup_64+0xb6/0xc0 Oct 13 10:43:37 surprise kernel: ---[ end trace fb1d7fe519360584 ]--- -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1874464 Title: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out To manage notifications about this bug go to:
Re: [Bug 1874464] Re: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out
On Sat, Oct 10, 2020 at 09:01:15PM -, Kai-Heng Feng wrote: > Dan, it will be great if you can revert workaround [1] and apply > possible fix [2] to see if it helps. > > I guess you no longer see the issue because of the workaround. > > [1] > https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable/commit/?id=759bc16ddfd4d7f3e195a9662d9d067625b805b6 > [2] > https://patchwork.ozlabs.org/project/linux-pci/patch/20201007132808.647589-1-ian.kuml...@gmail.com/ I'm happy to help, but I haven't compiled a kernel before; what's the process for going about it? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1874464 Title: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1874464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1874464] Re: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out
Thanks for the test kernel! I can no longer reproduce this on the most recent two kernels in groovy (5.8.0-19-generic, 5.8.0-20-generic) nor with that test kernel. I think we can mark this Incomplete for groovy too, and I'll respond if I see this again. Thanks to you and Kai-Heng for all your help throughout this process! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1874464 Title: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1874464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
On Thu, Oct 01, 2020 at 01:41:46PM -, Dan Watkins wrote: > > How did resolve/netif get owned by root? > > I don't believe I've ever touched it before, so I'm not sure. I haven't > rebooted since that last comment, I'll do that at some point today to > check if ownership reverts to root. Ownership is `root` on boot; whatever is responsible for creating this in /run is presumably to blame? > If it does, what debugging can I perform to determine what's doing it? Let me know! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1874464] Re: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out
I'm still seeing this issue, and it now sometimes appears on boot without me having done anything. What can I do to help move this forward? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1874464 Title: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1874464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
> How did resolve/netif get owned by root? I don't believe I've ever touched it before, so I'm not sure. I haven't rebooted since that last comment, I'll do that at some point today to check if ownership reverts to root. If it does, what debugging can I perform to determine what's doing it? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
I've just tested: changing the ownership of /run/systemd/resolve/netif to systemd-resolve:systemd-resolve resolves (haha) this issue. The first restart of systemd-resolved after the change did not address it (because the permissions issue means that the state was not persisted); on a network interface reconnect, the state _is_ persisted, so future systemd-resolved restarts do not lose DNS resolution. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
On Thu, Sep 24, 2020 at 09:42:28PM -, Balint Reczey wrote: > The latest upload (246.6-1ubuntu1) may have fixed this as well. This happened again just now when I upgraded my system to the new systemd, so I assume not. Here's a log snippet of restarting: Sep 29 09:28:14 surprise systemd[1]: Starting Network Name Resolution... Sep 29 09:28:15 surprise systemd-resolved[31479]: Positive Trust Anchors: Sep 29 09:28:15 surprise systemd-resolved[31479]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Sep 29 09:28:15 surprise systemd-resolved[31479]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test Sep 29 09:28:15 surprise systemd-resolved[31479]: Using system hostname 'surprise'. Sep 29 09:28:15 surprise systemd[1]: Started Network Name Resolution. At this point, I do not have working DNS resolution. If I reconnect my network interface, then I do get it, but I see this line in the log, repeated multiple times: Sep 29 09:28:23 surprise systemd-resolved[31479]: Failed to save link data /run/systemd/resolve/netif/2: Permission denied /run/systemd/resolve is owned by systemd-resolve, but /run/systemd/resolve/netif is owned by root. Could this be related to the issue I'm observing? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896772] [NEW] systemd-resolved configures no Current Scopes on start
Public bug reported: Running groovy on the desktop, with the systemd packages that migrated today(/overnight EDT). # Steps to reproduce: 1) `systemctl restart systemd-resolved.service` (This is a minimal reproducer, but I first saw this after an apt upgrade of systemd.) # Expected behaviour: DNS continues to work, status looks like this: Link 2 (enp5s0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 DNS Domain: ~. lan # Actual behaviour: DNS is unconfigured: Link 2 (enp5s0) Current Scopes: none DefaultRoute setting: no LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no # Workaround Disconnecting and reconnecting my network connection restored DNS functionality. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.5-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4 Uname: Linux 5.8.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu45 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: i3 CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Wed Sep 23 09:05:42 2020 InstallationDate: Installed on 2019-05-07 (504 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: Gigabyte Technology Co., Ltd. B450M DS3H ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7 RebootRequiredPkgs: gnome-shell SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago) dmi.bios.date: 01/25/2019 dmi.bios.release: 5.13 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F4 dmi.board.asset.tag: Default string dmi.board.name: B450M DS3H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: B450M DS3H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug groovy -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
I haven't been able to reproduce in a lxd container or an EC2 instance; I don't have a convenient way of testing a different NetworkManager system, unfortunately. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1888858] Re: document manual_cache_clean better
** Changed in: cloud-init (Ubuntu) Status: Triaged => In Progress ** Changed in: cloud-init (Ubuntu) Assignee: (unassigned) => Dan Watkins (oddbloke) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/158 Title: document manual_cache_clean better To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/158/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1874464] Re: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out
On Sat, Sep 05, 2020 at 08:46:51PM -, Kreisch István András wrote: > I'm using a really old kernel with this same error: v3.13.170 with > Ubuntu 14.04.6. I could circumvent the issue by reduce the speed of the > ethernet interface from 1Gb to 100Mb using ethtool. > > ethtool –s eth3 speed 100 duplex full autoneg on > > Maybe it helps to operate until the fix is implemented and released. Unfortunately, this did not address the issue I was seeing. (Thanks for the suggestion!) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1874464 Title: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1874464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1893661] Re: Support for Intel VROC (Virtual RAID On CPU)
** Changed in: curtin (Ubuntu) Assignee: (unassigned) => György Szombathelyi (gyurco) ** Changed in: curtin (Ubuntu) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1893661 Title: Support for Intel VROC (Virtual RAID On CPU) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1893661/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1894217] Re: 2.8.2 deploy and commission fails corrupted bootorder variable detected
** Changed in: curtin (Ubuntu) Status: Confirmed => Triaged -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1894217 Title: 2.8.2 deploy and commission fails corrupted bootorder variable detected To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1894217/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
