Re: [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

On Wed, Aug 29, 2018 at 8:41 AM Dimitri John Ledkov wrote: > > Do we need this in bionic? Yes > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1671951 > > Title: > networkd should allow configuring IPV6 MTU > > To

Re: [Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

https://www.spinics.net/lists/linux-bcache/msg04869.html https://www.spinics.net/lists/linux-bcache/msg05774.html On Tue, Aug 28, 2018 at 2:30 PM Ryan Harper wrote: > > It's always been a locking issue, so either misuse (or missing) locks > in the bcache attach/detach path, or generi

Re: [Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

It's always been a locking issue, so either misuse (or missing) locks in the bcache attach/detach path, or generic locking changes to block layer path I'd think. I'll see if I can find any hits on those oops tracebacks too On Tue, Aug 28, 2018 at 2:29 PM Ryan Harper wrote: > >

Re: [Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

https://patchwork.kernel.org/patch/10094201/ diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts index d4f80786e7c2..3890468678ce 100644 --- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts +++

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

FAILED: Kernel 4.15-rc1 up to bc631943faba6fc3f755748091ada31798fb7d50 Attached is the oops of the failure. ** Attachment added: "rc1-bisect7-oops.txt" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784665/+attachment/5181823/+files/rc1-bisect7-oops.txt -- You received this bug

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

PASS: Kernel 4.15-rc1 (bisect6) up to 87eba0716011e528f7841026f2cc65683219d0ad -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1784665 Title: mkfs.ext4 over /dev/bcache0 hangs To manage

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

PASS: Kernel 4.15-rc1 (bisect5) up to 6b457409169b7686d293b408da0b6446ccb57a76 I've 2600 seconds of uptime with over 800 loops in the test-case. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1784665

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

FAILED: Kernel 4.15-rc1 up to f48f66a962a54c3d26d688c3df5441c9d1ba8730 Attached is the oops of the failure. ** Attachment added: "rc1-bisect4-oops.txt" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784665/+attachment/5181417/+files/rc1-bisect4-oops.txt -- You received this bug

[Bug 1776452] Re: Fail to set DNS server and search domain when customize Ubuntu18.04 to DHCP IP by cloud-init

We're looking to support this use-case in netplan in the near future. I'll update this bug with some details on what changes we'll need to cloud-init to support this use-case. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

FAILED: Kernel 4.15-rc1 up to f17b9e764dfcd838dab51572d620a371c05a8e60 Attached is the oops of the failure. ** Attachment added: "rc1-bisect3-ops.txt" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784665/+attachment/5178807/+files/rc1-bisect3-ops.txt -- You received this bug

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

test kernel 4.15-rc1 up to abb62c46d4949d44979fa647740feff3f7538799 FAILED ** Attachment added: "kernel oops for 4.15-rc1 up to abb62c46d4949d44979fa647740feff3f7538799" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784665/+attachment/5175947/+files/rc1-bisect2-oops.txt -- You

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

test kernel 4.15-rc6 up to d8887f1c7289848e74c92bd4322789a9cd7de699 FAILED ** Attachment added: "kernel oops for 4.15-rc6-up-to-d8887f1c7289848e74c92bd4322789a9cd7de699" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784665/+attachment/5175379/+files/rc6-bisect1-oops.txt -- You

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

test kernel 4.15-rc6 up to d8887f1c7289848e74c92bd4322789a9cd7de699 FAILED Attaching oops. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1784665 Title: mkfs.ext4 over /dev/bcache0 hangs To manage

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

4.14 Final: OK 4.15-rc1:OK I started a further bisect: 4.15-rc9:FAIL 4.15-rc5:OK 4.15-rc7:FAIL 4.15-rc6:OK So, it appears something between rc6 (last known good) and rc7 (FAIL) -- You received this bug notification because you are a member of Ubuntu Bugs, which is

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

4.10: Status: OK Comment: Survived 30 minute loop over recreating with no issues. 4.13: Status: OK Comment: Survived 30 minute loop over recreating with no issues. 4.15: Status: FAIL Comment: triggered within less than a minute of the loop. Kernel Trace: [ 122.500943] Oops:

[Bug 1761573] Re: Network not configured on bionic

Hi Daniel, Thanks for commenting. I don't believe your issue is the same as this bug (kernel issue with e1000e driver in the 4.15 kernel). Rather it appears that you're booting a cloud image outside of a cloud and without any cloud configuration. Cloud-init only runs if it detects that it has

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

I can recreate on upstream: # uname -r; dmesg | tail -n 16 4.18.0-041800rc7-generic [ 967.657492] INFO: task bcache_allocato:14240 blocked for more than 120 seconds. [ 967.664138] Not tainted 4.18.0-041800rc7-generic #201807292230 [ 967.669641] "echo 0 >

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

I'll see if I can reproduce on the mainline kernel. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1784665 Title: mkfs.ext4 over /dev/bcache0 hangs To manage notifications about this bug go to:

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

I think I've got one. It doesn't always hang the mkfs, but it does wedge bcache in a few ways. [ 484.322546] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 484.326230] INFO: task bcache_allocato:32503 blocked for more than 120 seconds. 1) when it occurs, a

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

** Attachment added: "bcache-basic-repro.sh" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784665/+attachment/5170528/+files/bcache-basic-repro.sh -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

We've just had a second occurrence of this, same kernel, but with Xenial. (Xenial HWE Edge kernel 4.15.0-29) with the same scenario, mkfs.ext4 a /dev/bcache0. I'll see if I can recreate by stressing things. -- You received this bug notification because you are a member of Ubuntu Bugs, which is

[Bug 1784665] Re: mkfs.ext4 over /dev/bcache0 hangs

> Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem? We've had plenty of successful runs on this kernel. I suspect io load or something else may trigger this. We've only seen it once out of tens of not

[Bug 1784665] [NEW] mkfs.ext4 over /dev/bcache0 hangs

Public bug reported: $ cat /proc/version_signature Ubuntu 4.15.0-29.31-generic 4.15.18 $ lsb_release -rd Description:Ubuntu Cosmic Cuttlefish (development branch) Release:18.10 $ apt-cache policy linux-image-`uname -r` linux-image-4.15.0-29-generic: Installed: 4.15.0-29.31

[Bug 1781203] Re: Bonding "parameters" not supported

The parameters are supported; but you cannot "try" that configuration out temporarily. The 'try' subcommand attempts to keep the current configuration around, generate and apply the "new" config, and allow you to confirm if things are working and if not, it will restore the original config prior

[Bug 1778704] Re: redeployment of node with bcache fails

> I assume curtin only does the wipefs when the bcache devices are attached, correct? Yes; curtin probes the disks that are present and activates them as needed. Bcache is activated by the kernel itself if the metadata header is present on any block device. If the disk is not attached to the

Re: [Bug 1778704] Re: redeployment of node with bcache fails

On Fri, Jun 29, 2018 at 11:20 AM Gábor Mészáros wrote: > > That I can later, not now. > What I see now though is mds are not clean and resync started: Yes; the updated curtin does a number of things to prevent this from happening. 1) we wipe the first and last 1M of the raid device itself 2)

[Bug 1778704] Re: redeployment of node with bcache fails

Can you provide the curtin install log? ** Changed in: curtin 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/1778704 Title: redeployment of node with bcache fails

[Bug 1778704] Re: redeployment of node with bcache fails

Hello, I believe this issue is resolved in this commit[1]. There is a new version of curtin for Xenial which contains the fix. Can you update curtin to the latest? curtin | 18.1-17-gae48e86f-0ubuntu1~16.04.1 | xenial-updates/universe | all -- You received this bug notification because you

[Bug 1778704] Re: redeployment of node with bcache fails

The commit: https://git.launchpad.net/curtin/commit/?id=4bf7750b6010f0483b22ff626eab58d6a85bb072 ** Changed in: curtin Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1671951] Re: networkd should allow configuring IPV6 MTU

I've just seen that upstream systemd v239 claims to support IPV6MtuBytes https://lwn.net/Articles/758128/ * networkd's .network files now support a new IPv6MTUBytes= option for setting the MTU used by IPv6 explicitly as well as a new MTUBytes= option in the [Route] section to configure the MTU

Re: [Bug 1777094] Re: dnsmasq started too early, not getting all interfaces

On Tue, Jun 19, 2018 at 9:41 AM Hadmut Danisch wrote: > > dnsmasq _after_ networking? > > Isn't it part of networking and should be running and ready for other > services depending on networking? Yes, but it's complicated; see below. > > > (my guess is that Ubuntu has never defined the targets

Re: [Bug 1777094] Re: dnsmasq started too early, not getting all interfaces

I see, interesting. The dnsmasq.service does not wait for network-online.target; This appears to be a duplicate of: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1531184 In addition to the netplan config to ensure it waits for your bridge to come up, you need to delay dnsmasq.service

[Bug 1767569] Re: Server install on usb device fails

This has been fixed in upstream curtin here: https://git.launchpad.net/curtin/commit/?id=4bf7750b6010f0483b22ff626eab58d6a85bb072 At some point the live installer will pick up the newer curtin release with this fix included. ** Changed in: curtin (Ubuntu) Status: Confirmed => Fix

[Bug 1776452] Re: Fail to set DNS server and search domain when customize Ubuntu18.04 to DHCP IP by cloud-init

There isn't yet a way to allow DNS overrides and DHCP on the same interface. That is, the DHCP response from the server may include DNS entries so the custom nameserver values are not automatically appended to an existing DHCP configuration. Generally adding/overriding DHCP response values isn't

Re: [Bug 1777094] Re: dnsmasq started too early, not getting all interfaces

https://netplan.io/faq#example-for-an-ifupdown-legacy-hook-for-post- uppost-down-states You can use a networkd-dispatcherd to hook on vlan0 becoming routeable and then start/restart the dnsmasq service; On Fri, Jun 15, 2018 at 12:36 PM, Hadmut Danisch wrote: > So it is not possible to have an

[Bug 1777094] Re: dnsmasq started too early, not getting all interfaces

In your netplan example config, keyword 'optional' means that systemd- networkd won't wait until this interface is up before declaring to systemd that the network is online. THis means dnsmasq is starting before the vlan0 interface is created. If you remove the optional value that should ensure

[Bug 1776115] Re: 18.04 Subiquity install crashes w/ "no such device" aganist /dev/sda2

The underlying curtin bug was resolved here: https://git.launchpad.net/curtin/commit/?id=4bf7750b6010f0483b22ff626eab58d6a85bb072 That's been released in Xenial through Cosmic curtin | 18.1-17-gae48e86f-0ubuntu1~16.04.1 | xenial-updates I can't tell what version of curtin gets packaged, the

[Bug 1776696] Re: sensible default NIC for x86? (virtio, not e1000)

I don't think so. >From a hypervisor perspective, general function I think is more important than running as fast as possible. Historically users have always enabled additional speed by swapping out emulated devices for paravirtual ones. For users of the command line, changing the default will

Re: [Bug 1776189] Re: implement a machine type based control of host-phys-bits

RE: bikeshedding on the name; I don't think -large or -big maps well the the feature, which is more like -cpu host; ie, give the host cpu attributes to the guest vcpu. In this case, we're asking to have host physical addressing bits applied to the guest vcpus. So maybe -hpb for HostPhysicalBits?

[Bug 1728742] Re: curtin dname for bcache uses unstable devname instead of UUID

This bug is believed to be fixed in curtin in version18.1-17-gae48e86f- 0ubuntu1. If this is still a problem for you, please make a comment and set the state back to New Thank you. ** Changed in: curtin Status: Fix Committed => Fix Released -- You received this bug notification because

Re: [Bug 1771662] Re: libvirtError: Node device not found: no node device with matching name

I'm not certain we can rule out the charm; the observant behavior is that the compute nodes do not get enrolled. Certainly the lack of a nova-compute node being registered has some touch point to the charms. The follow-up I think comes from the Openstack team to walk through where the charm leaves

Re: [Bug 1770082] Re: systemd-networkd not renaming devices on boot

On Fri, May 25, 2018 at 9:09 AM, Mathieu Trudel-Lapierre wrote: > I'm not completely sure where the code lives in cloud-init; it looks a > bit like what's in: > > cloudinit/net/netplan.py > > But the code does read as though it should not be running 'udevadm test- > builtin

Re: [Bug 1770082] Re: systemd-networkd not renaming devices on boot

On Fri, May 25, 2018 at 8:48 AM, Mathieu Trudel-Lapierre wrote: > My recommended course of action for cosmic: > > - drop udevadm (net_setup_link) call from cloud-init This will still be needed in the case that we have a network config with names. Cloud-init runs after udev

Re: [Bug 1770082] Re: systemd-networkd not renaming devices on boot

"This is why I added cloud-init to affected packages -- cloud-init should not be second- guessing the network layer and attempting to do renames / to run" There is no second guessing. In the case where we have no network config, there is no renaming; we accept whatever name is given. If the

[Bug 1772044] Re: sru curtin 2018-05-18 - 18.1-17-gae48e86f-0ubuntu1

** Description changed: == Begin SRU Template == [Impact] This release sports both bug-fixes and new features and we would like to make sure all of our supported customers have access to these improvements. The notable ones are:   * zfs: implement a supported check to handle i386

[Bug 1770082] Re: systemd-networkd not renaming devices on boot

That's not the final conclusion; the issue is still being discussed upstream; in particular as to why only the interface name cannot be modified at runtime by .link files. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1772044] Re: sru curtin 2018-05-18 - 18.1-17-gae48e86f-0ubuntu1

** Summary changed: - sru curtin 2018-05-18 - 18.1-16-g18835845-0ubuntu1 + sru curtin 2018-05-18 - 18.1-17-gae48e86f-0ubuntu1 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1772044 Title: sru

Re: [Bug 1770082] Re: systemd-networkd not renaming devices on boot

We really only want to be allowed to rename interfaces that have requested it. This means other interfaces which do not have a set-name directive will have the kernel name. On Thu, May 24, 2018 at 6:56 AM, Mike Jonkmans <1770...@bugs.launchpad.net> wrote: > Things seem to work when i change the

Re: [Bug 1771662] Re: libvirtError: Node device not found: no node device with matching name

arch64 GNU/Linux > > On Tue, May 22, 2018 at 7:10 PM, Ryan Harper <1771...@bugs.launchpad.net> > wrote: >> Looks like the ls -aLR contains more data; we can compare bionic. >> >> On Tue, May 22, 2018 at 6:53 PM, Jason Hobbs <jason.ho...@canonical.com>

[Bug 1772044] Re: sru curtin 2018-05-18 - 18.1-16-g18835845-0ubuntu1

** Attachment added: "curtin-vmtest-proposed-b-console.log" https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1772044/+attachment/5143451/+files/curtin-vmtest-proposed-b-console.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

[Bug 1772044] Re: sru curtin 2018-05-18 - 18.1-16-g18835845-0ubuntu1

** Attachment added: "curtin-vmtest-proposed-b-artifacts.tar.xz" https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1772044/+attachment/5143452/+files/curtin-vmtest-proposed-b-artifacts.tar.xz ** Description changed: == Begin SRU Template == [Impact] This release sports both

[Bug 1772044] Re: sru curtin 2018-05-18 - 18.1-16-g18835845-0ubuntu1

** Attachment added: "curtin-vmtest-proposed-a-artifacts.tar.xz" https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1772044/+attachment/5143450/+files/curtin-vmtest-proposed-a-artifacts.tar.xz -- You received this bug notification because you are a member of Ubuntu Bugs, which is

[Bug 1772044] Re: sru curtin 2018-05-18 - 18.1-16-g18835845-0ubuntu1

** Attachment added: "curtin-vmtest-proposed-a-console.log" https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1772044/+attachment/5143448/+files/curtin-vmtest-proposed-a-console.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

[Bug 1772044] Re: sru curtin 2018-05-18 - 18.1-16-g18835845-0ubuntu1

** Attachment added: "curtin-vmtest-proposed-x-artifacts.tar.xz" https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1772044/+attachment/5143446/+files/curtin-vmtest-proposed-x-artifacts.tar.xz -- You received this bug notification because you are a member of Ubuntu Bugs, which is

[Bug 1772044] Re: sru curtin 2018-05-18 - 18.1-16-g18835845-0ubuntu1

** Attachment added: "curtin-vmtest-proposed-x-console.log" https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1772044/+attachment/5143445/+files/curtin-vmtest-proposed-x-console.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

Re: [Bug 1772490] Re: 'Deploying' timed out after 40 minutes / Failedbcache: register_bcache() error

*** This bug is a duplicate of bug 1768893 *** https://bugs.launchpad.net/bugs/1768893 The bcache message is *NOT* a failure in the kernel; That message is emitted when a bcache device is reregistered, the kernel will emit the changed event to ensure that udev will create

Re: [Bug 1771662] Re: libvirtError: Node device not found: no node device with matching name

t; wrote: >>> ok; looks like that 4.15.0-22-generic just released and wasn't what I >>> used in the first reproduction... I doubt that's it. >>> >>> On Tue, May 22, 2018 at 4:58 PM, Ryan Harper <1771...@bugs.launchpad.net> >>> wrote: >>>> Com

Re: [Bug 1771662] Re: libvirtError: Node device not found: no node device with matching name

Comparing the kernel logs, on Xenial, the second nic comes up: May 22 15:00:27 aurorus kernel: [ 24.840500] IPv6: ADDRCONF(NETDEV_UP): enP2p1s0f2: link is not ready May 22 15:00:27 aurorus kernel: [ 25.472391] thunder-nicvf 0002:01:00.2 enP2p1s0f2: Link is Up 1 Mbps Full duplex But on

Re: [Bug 1772490] Re: bcache: register_bcache() error

On Mon, May 21, 2018 at 3:59 PM, Andres Rodriguez wrote: > @Ryan, > > I'm marking this as incomplete for curtin provided that after further > debugging, I can see that the late command that's supposed to send the > "netboot_off" operation is not being sent. > > This could

Re: [Bug 1772490] Re: bcache: register_bcache() error

Thanks for the log. Curtin installed without error, I'll mark invalid. AFAICT, it booted fine and was instructed to power off. May 21 13:18:51 geodude cloud-init[1676]: Powering node off. May 21 13:18:51 geodude ec2: May 21 13:18:51 geodude ec2:

[Bug 1772490] Re: bcache: register_bcache() error

May 21 11:00:42 geodude cloud-init[1643]: curtin: Installation finished. >From the rsyslog, curtin finished the install without error. ** Changed in: curtin Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed

[Bug 1772490] Re: bcache: register_bcache() error

ay 21 10:57:05 geodude kernel: [ 49.126408] bcache: register_bcache() error /dev/sda3: device already registered (emitting change event) These are not curtin or kernel errors but expected output. I looked at the qa link but I didn't find the install.log debug output. ** Changed in: curtin

[Bug 1772044] Re: sru curtin 2018-05-18 - 18.1-16-g18835845-0ubuntu1

** Merge proposal linked: https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/345951 ** Merge proposal linked: https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/345952 ** Merge proposal linked: https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/345953

[Bug 1772044] [NEW] sru curtin 2018-05-18 - 18.1-16-g18835845-0ubuntu1

Public bug reported: == Begin SRU Template == [Impact] This release sports both bug-fixes and new features and we would like to make sure all of our supported customers have access to these improvements. The notable ones are: * zfs: implement a supported check to handle i386 (LP: #1768709) *

[Bug 1771662] Re: libvirtError: Node device not found: no node device with matching name

Thanks for the logs. I generally don't see anything *fatal* to libvirt. In the nova logs, I can see that virsh capabilities returns host information. It certainly is failing to find the VFs on the SRIOV device; it's not clear if that's because the device is misbehaving (we can see the kernel

[Bug 1771662] Re: libvirtError: Node device not found: no node device with matching name

Some package level deltas that may be relevant: ii linux-firmware 1.173 ii linux-firmware 1.157.18 ii pciutils 1:3.3.1-1.1ubuntu1.2 ii pciutils 1:3.5.2-1ubuntu libvirt0:arm644.0.0-1ubuntu7~cloud0 libvirt0:arm644.0.0-1ubuntu8

[Bug 1771662] Re: libvirtError: Node device not found: no node device with matching name

To make it more clear; the hardware SRIOV device is different that normal: TL;DR this special device has VFs that have NO PF associated software doesn't understand this Though per comment #3; it seems odd that a Xenial/Queens with the same kernel (HWE) works OK. So some tracing in libvirt/nova

[Bug 1771662] Re: libvirtError: Node device not found: no node device with matching name

And for the xenial deployment version, can we get what's in /etc/network/interfaces* (including the .d)? I'm generally curious w.r.t what interfaces are managed by the OS, and which ones are being delegated to the guests. -- You received this bug notification because you are a member of Ubuntu

[Bug 1771662] Re: libvirtError: Node device not found: no node device with matching name

Please capture: 1) cloud-init collect-logs (writes cloud-init.tar to $CWD) 2) the journal /var/log/journal 3) /etc/netplan and /run/systemd 4) /etc/udev/rules.d -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

Re: [Bug 1770082] Re: systemd-networkd not renaming devices on boot

Note, that uvt-kvm is going to use cloud-init; how are you making sure that cloud-init isn't doing the rename itself? Xenial by default doesn't use netplan; it still uses eni; the network configuration generation in cloud-init using eni does create a 70-persistent-net.rules file that handles

Re: [Bug 1770082] Re: systemd-networkd not renaming devices on boot

Can you provide the journalctl -b output for the boot that does this rename? Is the reproduce the same, can you provide your steps and I'll replicate. Xenial does not enable netplan by default so we have a different path there at least. On Mon, May 14, 2018 at 9:58 PM, Daniel Axtens

Re: [Bug 1770082] Re: systemd-networkd not renaming devices on boot

On Fri, May 11, 2018 at 10:18 AM, Daniel Axtens wrote: > Right. Yes, I can replicate that, thanks heaps! Great! > > So to summarise, you can make the rename take effect on boot if you: > 1) copy the files from /run/systemd/network -> /etc/systemd/network > 2) then

Re: [Bug 1770082] Re: systemd-networkd not renaming devices on boot

-link.rules bin/readlink On Fri, May 11, 2018 at 9:35 AM, Ryan Harper <ryan.har...@canonical.com> wrote: > I'm just verifying that on my end; note that the 99-default.link is > going to be sufficient to trigger a rename from eth0 to ens3; which > then prevents any rename once we mount r

Re: [Bug 1770082] Re: systemd-networkd not renaming devices on boot

I'm just verifying that on my end; note that the 99-default.link is going to be sufficient to trigger a rename from eth0 to ens3; which then prevents any rename once we mount root. Here's the trigger: % /usr/share/initramfs-tools/hooks/udev # copy .link files containing interface naming

Re: [Bug 1770082] Re: systemd-networkd not renaming devices on boot

On Fri, May 11, 2018 at 3:25 AM, Daniel Axtens wrote: > Ryan, I can't get that to work on my systems. What is it that update- > initramfs is supposed to change? I don't see any files in my initramfs > that are generated or read by netplan. Neither do I see netplan

[Bug 1770082] Re: systemd-networkd not renaming devices on boot

Investigating, it appears that the interfaces are getting renamed by udev in the initramfs, which pushes their name_assign_type value to 4, and udev refuses to rename an interface if the name_assign_type value is 4. So, I can make this scenario work if I do: 4. sudo update-initramfs -u 5. reboot

Re: [Bug 1770082] Re: systemd-networkd not renaming devices on boot

On Wed, May 9, 2018 at 9:13 AM, Daniel Axtens wrote: > Ryan: I removed /etc/netplan/50-cloud-init.yaml and rebooted repeatedly and > I've never seen it regenerated. Ah, right, it doesn't regenerate unless you change instance-ids. > > I also don't see anything in

[Bug 1770082] Re: systemd-networkd not renaming devices on boot

Are you providing network config to cloud-init? Otherwise, cloud-init is going to generate a fallback network config like your original, dhcp on one of the interfaces. If you want to persist network changes, you need to add them to a separate netplan yaml config, or provide an updated

[Bug 1724895] Re: MTU not applied on private ethernet interfaces

Can you run cloud-init collect-logs in your instance and attach the tarfile (cloud-init.tar.gz in the current working directory). ** Changed in: cloud-init Importance: Undecided => Medium ** Changed in: cloud-init Status: New => Incomplete -- You received this bug notification

[Bug 1768823] Re: netplan ip leases

** Changed in: netplan.io (Ubuntu) Importance: Undecided => Medium ** Changed in: netplan.io (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1768823 Title:

Re: [Bug 1768777] Re: libnvpair1linux doc contents have busted symlinks

Yes; this was a an upgraded system. On Thu, May 3, 2018 at 5:28 PM, Colin Ian King <1768...@bugs.launchpad.net> wrote: > This seems to only occur with a Xenial -> Artful or Xenial -> Bionic > upgrades and not Artful -> Bionic. > > -- > You received this bug notification because you are subscribed

[Bug 1768777] [NEW] libnvpair1linux doc contents have busted symlinks

Public bug reported: % apt-cache policy libnvpair1linux libnvpair1linux: Installed: 0.7.5-1ubuntu15 Candidate: 0.7.5-1ubuntu15 Version table: *** 0.7.5-1ubuntu15 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages 100 /var/lib/dpkg/status % lsb_release -rd

[Bug 1768118] Re: /etc/netplan/50-cloud-init.yaml fails silently with no dhcp address assigned

What's the process for upgrading from Artful to Bionic? do-release-upgrade -d ? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1768118 Title: /etc/netplan/50-cloud-init.yaml fails silently with no

Re: [Bug 1760173] Re: zfs, zpool commands hangs for 10 seconds without a /dev/zfs

On Mon, Apr 30, 2018 at 12:14 PM, Colin Ian King <1760...@bugs.launchpad.net> wrote: > The code actually polls /dev/zfs until it appears. The issue here is > that it does not appear after 10 seconds, and then it gives up. Yes, you're right. Would it make sense to have zfsutils know it's running

[Bug 1760173] Re: zfs, zpool commands hangs for 10 seconds without a /dev/zfs

If they're going to modprobe and are waiting on udev, then I would like them to do something like udevadm settle --exit-if-exists=/dev/zfs That means they can exit early without paying the 10s by default value. -- You received this bug notification because you are a member of Ubuntu Bugs,

[Bug 1767569] Re: Server install on usb device fails

Thanks for report. I've seen this on drives which use msdos logical/extended partitioning. ** Changed in: curtin (Ubuntu) Importance: Undecided => High ** Changed in: curtin (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu

[Bug 1767166] Re: IBMCloud datasource does not recognize provisioning in debug mode.

An upstream commit landed for this bug. To view that commit see the following URL: https://git.launchpad.net/cloud-init/commit/?id=6ef92c98 ** Changed in: cloud-init Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which

Re: [Bug 1746348] Re: support installation of fsimage via copy

Can you provide the curtin config and install log ? On Thu, Apr 26, 2018 at 1:26 AM, Po-Hsu Lin wrote: > Hi Scott, > > any update for the curtin fix in Xenial? > > (curtin-common 18.1-1-g45564eef-0ubuntu1~16.04.1, still not working) > Thanks > > -- > You received this

[Bug 1766338] Re: package shim-signed 1.34.4+13-0ubuntu2 failed to install/upgrade: installed shim-signed package post-installation script subprocess returned error exit status 1

This last passed our vmtest on April 19th, using shim-signed 1.33.13-0ubuntu2 [ 247.040363] cloud-init[993]: ['install-grub', '--uefi', '--update-nvram', '/tmp/tmpfx83n0fv/target'] [ 247.044415] cloud-init[993]: moved etc/default/grub.d/50-cloudimg-settings.cfg out of the way [ 247.047645]

[Bug 1765833] Re: bond intervals default to seconds; breaks existing configs

https://github.com/CanonicalLtd/netplan/pull/22 has merged now. ** Changed in: netplan.io (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1765833 Title:

[Bug 1765173] Re: networkd waits 10 seconds for ipv6 network discovery by default

I've given this a test in LXD on my system which triggers the RA stall; after upgrading it does not wait for an RA before marking the interface configured and also confirmed that it does not regress the case where there are existing RA's on the network; those are still received. Note that we see

[Bug 1765833] Re: bond intervals default to seconds; breaks existing configs

I've built netplan.io locally with this PR and it resolves the issue. We see we're passing the 100 value through into networkd, and it gets the ms suffix. Then in the journal, after the bond has been started, it is ready right away. root@rharper-b2:~# apt-cache policy netplan.io netplan.io:

[Bug 1765833] Re: bond intervals default to seconds; breaks existing configs

https://github.com/CanonicalLtd/netplan/pull/22 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1765833 Title: bond intervals default to seconds; breaks existing configs To manage notifications

[Bug 1765833] [NEW] bond intervals default to seconds; breaks existing configs

Public bug reported: 1. # lsb_release -r -d Description:Ubuntu Bionic Beaver (development branch) Release:18.04 2. # apt-cache policy netplan.io netplan.io: Installed: 0.34.1 Candidate: 0.34.1 Version table: *** 0.34.1 500 500 http://archive.ubuntu.com/ubuntu

[Bug 1765173] Re: networkd waits 10 seconds for ipv6 network discovery by default

I don't think not blocking for RAs during boot as a decision that prefers ipv4 over ipv6. networkd is just doing something else by default that the kernel doesn't do today, or historically; *and* there is no toggle for the blocking; only do you want RAs or not *and* if you say you don't want RAs

[Bug 1765173] Re: networkd waits 10 seconds for ipv6 network discovery by default

I disagree that SLAAC is something that we should by default block reaching network-online.target. In general we cannot know in advance whether or not another system in the same subnet is providing Router Advertisements to other instances. If one instance in my VPC is running radvd, ec2 has

[Bug 1765173] [NEW] networkd waits 10 seconds for ipv6 network discovery by default

Public bug reported: 1. $ lsb_release -rd Description:Ubuntu Bionic Beaver (development branch) Release:18.04 2. $ apt-cache policy systemd systemd: Installed: 237-3ubuntu8 Candidate: 237-3ubuntu8 Version table: *** 237-3ubuntu8 500 500 http://archive.ubuntu.com/ubuntu

Re: [Bug 1761573] Re: Network not configured on bionic

tools being the issue here and left with a kernel bug in 4.15 and e1000e. > > On Thu, Apr 12, 2018 at 4:01 PM Ryan Harper <1761...@bugs.launchpad.net> > wrote: > >> Hrm, You could install Xenial and then upgrade to bionic's cloud-init >> ramfs; but keep the 4.4 kernel. T

[Bug 1761573] Re: Network not configured on bionic

Hrm, You could install Xenial and then upgrade to bionic's cloud-init ramfs; but keep the 4.4 kernel. This would allow us to test the initramfs code vs. the hardware. If 4.4 + cloud-initramfs-tools 0.40 works, then you likely have an issue with the kernel + the e1000e driver to sort. -- You

[Bug 1761573] Re: Network not configured on bionic

Can you paste the whole log? It still looks like something about the nic isn't working right. Can you boot something non-network on that hardware and just confirm that the nic actually works? On Thu, Apr 12, 2018 at 1:43 PM, Andres Rodriguez wrote: > So it seems that

<    2   3   4   5   6   7   8   9   10   11   >