Marking bionic Fix Released; Steve uploaded a debian-installer, which
was built against the new grub.
** Changed in: debian-installer (Ubuntu Bionic)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Verification-done:
xenial: 0.32~16.04.3
zesty: 0.32~17.04.1
artful: 0.32~17.10.1
In all cases the autopkgtests are successful (remaining failures appear
to be limitations of the test infrastructure: s390x and arm64 missing
modules / installed packages for wireless (iw, cfg80211) which should be
** Tags removed: verification-needed verification-needed-artful
verification-needed-xenial verification-needed-zesty
** Tags added: verification-done-artful verification-done-xenial
verification-done-zesty
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Verification-done:
xenial: 0.32~16.04.3
zesty: 0.32~17.04.1
artful: 0.32~17.10.1
I tested all these backports of 0.32; and in all cases the autopkgtests
are successful (remaining failures appear to be limitations of the test
infrastructure: s390x and arm64 missing modules / installed packages
Verification-done:
xenial: 0.32~16.04.3
zesty: 0.32~17.04.1
artful: 0.32~17.10.1
netplan running at boot-time no longer appears to block on missing
entropy; does not appear to be calling to uuid_generate() while setting
this up for the networkd generator (uuid generation is still required
for
Verification-done zesty with 0.32~17.04.01:
Tested bond in balance-tlb mode and active-backup mode, both correctly
set the primary for the bond.
** Tags removed: verification-needed-zesty
** Tags added: verification-done-zesty
--
You received this bug notification because you are a member of
Verification-done for xenial 0.32~16.04.3, and zesty 0.32~17.04.1:
Both are now skipping brcmfmac drivers ('if brcmfmac in driver_name').
** Tags removed: patch verification-needed verification-needed-xenial
verification-needed-zesty
** Tags added: verification-done-xenial
verification-done for xenial 0.32~16.04.3, and zesty 0.32~17.04.1:
IPv6 addresses are handled correctly through the lxd bridge; AcceptRA is
not longer set by default but the option is available to users.
** Tags removed: verification-needed verification-needed-xenial
verification-needed-zesty
Verification-done for xenial 0.32~16.04.3, and zesty 0.32~17.04.1:
UseMTU=yes is set on the interfaces for which a MTU is set, and the MTU
coming from DHCP is applied correctly when running 'netplan apply'.
** Tags removed: verification-needed-xenial verification-needed-zesty
** Tags added:
Verification-done xenial with 0.32~16.04.3:
Testing bonding in active-backup and balance-tlb mode; in both cases
when primary: is set, that device it correctly set to be used as the
primary slave, as shown in both /proc/net/bonding/bond0 and
/sys/class/net/bond0/bonding/primary.
** Tags removed:
** Tags removed: verification-needed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1714267
Title:
segfault on bad usage of generator
To manage notifications about this bug go to:
Verification-done-artful with 0.32~17.10.1:
Bonding in active-backup mode with primary: set to a suitable device
shows the bond with that device set as primary slave.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
verification-done for artful with 0.32~17.10.1:
As above, MTU changes are applied correctly.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1669564
Title:
udevadm trigger subsystem-match=net
verification-done for xenial 0.32~16.04.3, and zesty 0.32~17.04.1:
netplan appears to behave correctly w.r.t setting MTU, using the example
from Ryan the MTU appears to be correctly applied every time.
** Tags removed: verification-needed verification-needed-artful
verification-needed-xenial
verification-done for xenial 0.32~16.04.3, and zesty 0.32~17.04.1:
I verified that the 'optional' keyword is correctly recognized and
accepted as valid syntax by netplan.
** Tags removed: verification-needed verification-needed-xenial
verification-needed-zesty
** Tags added:
Verification-done on xenial for nplan 0.32~16.04.3:
Verification-done on zesty for nplan 0.32~17.04.1:
With accept-ra: no; RAs are no longer used to configure an IPv6 address.
Network and kernel behave normally when accept-ra: is not set.
** Tags removed: verification-needed
Public bug reported:
If I try to apply vlans directly:
network:
version: 2
renderer: networkd
ethernets:
eth0: {}
vlans:
vlan1:
id: 1
link: eth0
addresses: [ 192.168.0.10/23 ]
vlan10:
id: 10
link: eth0
addresses: [ 10.0.0.5/24 ]
The vlan
That's not going to change anything -- grub is doing exactly what it
should: ask shim to validate the image it tries to chainload; and the
image *does* validate successfully. The chain of trust is technically
preserved, but shim doesn't manage to make sense of things, and refuses
to continue
a bug in chainloader's validation of
images, it used to work, but only because it wasn't actually verifying
much of it in the first place.
** Changed in: grub2 (Ubuntu)
Status: New => In Progress
** Changed in: grub2 (Ubuntu)
Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyp
This looks a bit like a hardware (or kernel driver) issue, the problem
happens much earlier than where the system appears to stop, you're just
getting that because the install fails in general, so it throws you back
to the main menu.
You got dpkg-divert failing to be found, apt-get failing, etc.:
** Description changed:
+ [Impact]
+ Some Intel SoC-based systems.
+
+ [Test cases]
+ 1) Boot an affected system.
+
+ [Regression potential]
+ Some systems may rely on the current state of the timer selection in order to
be able to boot successfully, or to catch key presses before the end of a
That will need a d-i upload as well then, after grub is released.
** Also affects: debian-installer (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Autopktests still failing for xenial; the test is still not being
skipped (we know it won't work on Xenial due to the version of NM
shipped there). Marking verification-failed-xenial.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received this bug
Autopktests still failing for xenial; the test is still not being
skipped (we know it won't work on Xenial due to the version of NM
shipped there). Marking verification-failed-xenial.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received this bug
Autopktests still failing for xenial; the test is still not being
skipped (we know it won't work on Xenial due to the version of NM
shipped there). Marking verification-failed-xenial.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received this bug
Autopktests still failing for xenial; the test is still not being
skipped (we know it won't work on Xenial due to the version of NM
shipped there). Marking verification-failed-xenial.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received this bug
Autopktests still failing for xenial; the test is still not being
skipped (we know it won't work on Xenial due to the version of NM
shipped there). Marking verification-failed-xenial.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received this bug
Autopktests still failing for xenial; the test is still not being
skipped (we know it won't work on Xenial due to the version of NM
shipped there). Marking verification-failed-xenial.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received this bug
Autopktests still failing for xenial; the test is still not being
skipped (we know it won't work on Xenial due to the version of NM
shipped there). Marking verification-failed-xenial.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received this bug
Autopktests still failing for xenial; the test is still not being
skipped (we know it won't work on Xenial due to the version of NM
shipped there). Marking verification-failed-xenial.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received this bug
Autopktests still failing for xenial; the test is still not being
skipped (we know it won't work on Xenial due to the version of NM
shipped there). Marking verification-failed-xenial.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received this bug
Autopktests still failing for xenial; the test is still not being
skipped (we know it won't work on Xenial due to the version of NM
shipped there). Marking verification-failed-xenial.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received this bug
There's also a fwupdate-signed waiting in the zesty queue; that should
fix the current failed-to-upload.
Xenial indeed needs to be updated; perhaps the simplest in this case is
to bring it to the same version as in zesty?
Mario, what do you think?
--
You received this bug notification because
Setting the ubiquity task to Triaged. I don't think I have the time to
do this right now, but I think I've captured by idea here and given
sufficient background that someone else could easily attempt to
implement this in ubiquity -- that would be a pretty interesting way to
get to know ubiquity,
FWIW, the unsafe_swap check is done in partman-crypto -- that's a
debian-installer component, so another reason to avoid making flavour-
specific / security-sensitive changes there.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Indeed, for now the solution will have to be to disable zram before
installing for LVM2 with crypto.
So; for zram, I think the solution will be "involved". Not overly
complex, but I think it needs a small rework of seeds. zram is
compressed, not encrypted. It would be downright wrong to ignore
This one needs to be re-checked by the Security Team after their last
code review; and a look by someone from the MIR team. I shouldn't review
it, I filed the MIR myself.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Tags removed: verification-failed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1729573
Title:
netplan breaks Xen VIF driver
To manage notifications about this bug go to:
nplan 0.32~16.04.2 fails to build because I mismerged 0.32 and broke the
code skipping the test_routes_v6 test in the NetworkManager case.
Therefore, it can't possibly pass SRU verification.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received
nplan 0.32~16.04.2 fails to build because I mismerged 0.32 and broke the
code skipping the test_routes_v6 test in the NetworkManager case.
Therefore, it can't possibly pass SRU verification.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
nplan 0.32~16.04.2 fails to build because I mismerged 0.32 and broke the
code skipping the test_routes_v6 test in the NetworkManager case.
Therefore, it can't possibly pass SRU verification.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received
nplan 0.32~16.04.2 fails to build because I mismerged 0.32 and broke the
code skipping the test_routes_v6 test in the NetworkManager case.
Therefore, it can't possibly pass SRU verification.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received
nplan 0.32~16.04.2 fails to build because I mismerged 0.32 and broke the
code skipping the test_routes_v6 test in the NetworkManager case.
Therefore, it can't possibly pass SRU verification.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
nplan 0.32~16.04.2 fails to build because I mismerged 0.32 and broke the
code skipping the test_routes_v6 test in the NetworkManager case.
Therefore, it can't possibly pass SRU verification.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received
nplan 0.32~16.04.2 fails to build because I mismerged 0.32 and broke the
code skipping the test_routes_v6 test in the NetworkManager case.
Therefore, it can't possibly pass SRU verification.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received
nplan 0.32~16.04.2 fails to build because I mismerged 0.32 and broke the
code skipping the test_routes_v6 test in the NetworkManager case.
Therefore, it can't possibly pass SRU verification.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received
nplan 0.32~16.04.2 fails to build because I mismerged 0.32 and broke the
code skipping the test_routes_v6 test in the NetworkManager case.
Therefore, it can't possibly pass SRU verification.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received
nplan 0.32~16.04.2 fails to build because I mismerged 0.32 and broke the
code skipping the test_routes_v6 test in the NetworkManager case.
Therefore, it can't possibly pass SRU verification.
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1664844
Title:
No distinction between link-up and link-down
** Tags removed: verification-needed-xenial
** Tags added: verification-failed-xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1655440
Title:
"unconfigured" NIC can still get IPv6 addresses
@tobia; contact Lenovo support. If USB does not show up, it's not an
Ubuntu issue. Your USB system may be failing, or the USB key is not
recognized (which would make it not show up as a boot option). You might
want to try with a different USB key. Was 'ubuntu' listed before under
UEFI? You should
To this point, I am not yet convinced that there is a bug in Ubuntu that
causes this.
For one thing, the issue is far too confused here on this report for me
to make sense of what is going on. The included links to Lenovo forums
do not appear to me as bugs in Ubuntu.
What exactly is the problem?
Maybe you don't want to MIR the -doc package here, since it Depends on
lynx | www-browser. There are www-browser's in main, but not typically
installed on a server (w3m is in main but not part of the default
install).
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I quickly re-reviewed nghttp2; it's fine to MIR (and has security team
approval). MIR ACKed.
Let's try to fix the missing bindnow though in a future upload...
I: libnghttp2-14: hardening-no-bindnow
usr/lib/x86_64-linux-gnu/libnghttp2.so.14.14.0
** Changed in: nghttp2 (Ubuntu)
Status: New
So I managed to reproduce this in a way that looks correct (Starbucks
WiFi here uses Datavalet but fails in a way that looks the same: it
thinks you're logged in once you clicked the "Login" button on the
captive portal page once, but then updates DNS, but still attempts to
look up
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1727237
Title:
systemd-resolved is not finding a domain
To manage notifications about this bug go to:
Checking for the state of the domain from outside a captive portal won't
get much; "securelogin.arubanetworks.com" only exists while you're
behind the captive portal, in unauthenticated mode.
I think the next steps will be to do some testing with various captive
portals and see why
** Description changed:
+ [Impact]
+ Proper udev trigger behavior following a 'netplan apply' is essential to
having all the configuration applied for an interface.
+
+ [Test case]
+ 1- Write a netplan configuration file that sets MTU for a device, or renames
a device.
+ 2- Run 'netplan apply'
** Description changed:
+ [Impact]
+ Users need to write valid configuration, especially for new features that are
approved by not yet implemented, such as marking a link "optional".
+
+ [Test case]
+ Write a netplan configuration:
+
+ network:
+ version: 2
+ renderer: networkd
+
On Thu, Nov 23, 2017 at 4:55 AM, Christian Ehrhardt
<christian.ehrha...@canonical.com> wrote:
> On Thu, Nov 23, 2017 at 1:02 AM, Mathieu Trudel-Lapierre
> <mathieu.trudel-lapie...@canonical.com> wrote:
>> Hi,
>>
>> I'm revising some of the bootloader log
the timeout early and select a different option.
If there are no objections, I'd go and apply this change on Tuesday,
November 28.
Kindly,
Mathieu Trudel-Lapierre <cypher...@ubuntu.com <mathieu...@gmail.com>>
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/65B58DA1 818A D123 09
Verification done for isc-dhcp 4.3.5-3ubuntu1.1 as well:
If you manually enable using dhclient for ipv4 networking in the
initramfs, the system behaves as expected and correctly writes
DOMAINSEARCH in the /run/net-*.conf files. Ipv4 is not handled by
dhclient by default (but uses klibc instead)
Verification-done for xenial with klibc 2.0.4-8ubuntu1.16.04.4:
I verified that updating klibc-utils to the new version yields a /run
/net-ens3.conf file that contains the proper value at DOMAINSEARCH=.
As for the above test on zesty, this involved modifying
scripts/functions to allow breaking
Public bug reported:
I am trying to update all packagesets according to the current contents
of flavour seeds.
By now, we should add a new packageset for Ubuntu Budgie. I do not have
permissions to do this. I believe the command would be:
./edit-acl create -P ubuntu-budgie -S bionic -p
Verification-done for zesty, with klibc-utils 2.0.4-8ubuntu4.1:
I updated klibc-utils and libklic; then modified the initramfs
scripts/functions to add "maybe-break networking" to the end of
configure_networking(); and rebooted with 'ip=dhcp break=networking'. I
could then verify the contents of
Public bug reported:
At some point after boot, the USB3 system stops working. Anything
plugged on it is unresponsive, my system however keeps responding to
everything else. If I move keyboard/mouse to USB2 ports, it works again,
but nothing replugged to USB3 ports works.
There are kernel error
MIR approved. I had already reviewed the code for MIR before it was
uploaded.
** Changed in: hibagent (Ubuntu)
Status: New => Fix Committed
** Changed in: hibagent (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Ubuntu)
Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox)
** No longer affects: netplan
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1731600
Title:
[bionic] Installing desktop from mini.is
** Description changed:
[Impact]
Systems booted off the network where the DHCP server provides a domain name
but no search domains may wish to rely on the domain name as a search value (as
is done in isc-dhcp in userland, outside the initramfs), to be able to use
short names for resolving
Eric,
Please make sure there is a team subscriber for pcp bugs, this is a
requirement for inclusion in main. This may be the Server Team, but they
should know about it and agree to sign up for the extra work (however
small it may be).
** Changed in: pcp (Ubuntu)
Assignee: Mathieu Trudel
Using compat 5 isn't wrong per se, but I did notice the need to
modernize the packaging, and discussed this with Eric already. Using
newer packaging makes it easier to maintain the package in the long run,
as new developers may not know of or understand older tricks. A promise
to keep improving
in: papi (Ubuntu)
Assignee: Mathieu Trudel-Lapierre (cyphermox) => Ubuntu Security Team
(ubuntu-security)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1704130
Title:
[MIR] papi
To man
Whether ubiquity is installable is a different issue than console-setup
breaking on upgrade though. The ubiquity change is being reverted, but
we still need to figure out why the console-setup upgrade fails.
I've attempted to set up a virtual machine with Ubuntu Server, where I
can approximate
While I understand the impact of having console-setup potentially "hang"
the system on upgrade, this isn't something that happens systematically,
it's also not a regression introduced in 1.108ubuntu15.4, so what is the
net benefit in not releasing this SRU? Certainly people might still
upgrade to
I'm doing this review.
** Changed in: papi (Ubuntu)
Assignee: Eric Desrochers (slashd) => Mathieu Trudel-Lapierre (cyphermox)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1704130
Title:
[
compat 5, and old-format rules file. I think given its
complexity it would really benefit (from a maintainability point-of-view) if
the packaging was modernized -- compat level 9, using simpler dh-style rules,
etc.
** Changed in: pcp (Ubuntu)
Assignee: (unassigned) => Mathieu Trudel-Lapie
** Description changed:
+ [Impact]
+ Booting systems have a limited amount of entropy, especially in some of the
cloud cases. We should avoid using it up unnecessarily.
+
+ [Test cases]
+
+ == netplan ==
+ 1) Boot system with netplan config; using networkd renderer
+ 2) Validate that it starts
** Description changed:
[Impact]
- Backport features in upstream netplan / netplan in artful to zesty, xenial.
+ Backport features in upstream netplan / netplan in bionic to zesty, xenial.
[Test cases]
== Autopkgtests ==
Run autopkgtests, they should all pass.
== MTU settings
** Summary changed:
- Backport netplan 0.29
+ Backport netplan 0.31
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1713142
Title:
Backport netplan 0.31
To manage notifications about this bug go
Verification-done-xenial, with 4.4.0-1010.15:
I spun an openstack instance with a newly-built image built to include
the kernel package from proposed; the system boots correctly and is
reachable from the network, as shown in the attached log.
** Attachment added: "console-log (1)"
** Also affects: linux (Ubuntu Zesty)
Importance: Undecided
Status: New
** Also affects: nplan (Ubuntu Zesty)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: nplan (Ubuntu Xenial)
Assignee: Mathieu Trudel-Lapierre (cyphermox)
Status: In Progress
** Also affects: openssh (Ubuntu Zesty)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Zesty)
Importance: Undecided
Status: New
** Also affects: nplan (Ubuntu Zesty)
Importance: Undecided
Verification-done for zesty with nplan 0.29~17.04.1:
As for xenial, this is a fix for a regression introduced in a package
that never actually made it to zesty. The regression does not appear in
netplan 0.29~17.04.1 at all, I verified that the container with nplan
upgraded properly gets both IPv4
Verification-done for zesty with nplan 0.29~17.04.1:
I verified that the generated networkd config in the .network file
contains "UseMTP=true" in the [DHCP] section; and the container gets the
right MTU from the DHCP server.
** Tags removed: nplanfail verification-needed
Verification-done-zesty for nplan 0.29~17.04.1.
MTU is correctly applied for an interface, as part of the configuration
in both NetworkManager and systemd-networkd .link file.
** Tags removed: verification-needed verification-needed-zesty
** Tags added: verification-done-zesty
--
You received
Verification-done on zesty for nplan 0.29~17.04.1:
With accept-ra: no; RAs are no longer used to configure an IPv6 address.
Network and kernel behave normally when accept-ra: is not set.
** Tags removed: verification-needed verification-needed-zesty
** Tags added: verification-done-zesty
--
Public bug reported:
The linux-kvm is missing a random source; there's a distinct lack of
entropy on the system as discovered by finding out bugs in netplan,
cloud-init, etc.
Please enable at least CONFIG_HW_RANDOM, CONFIG_HW_RANDOM_VIRTIO.
** Affects: linux-kvm (Ubuntu)
Importance:
Public bug reported:
I started a system with cloud-init disabled, etc. and a single real
network interface (ens3) that could be configured.
That VM has no configuration whatsoever for systemd-networkd, as that
would have to have been written by netplan, and cloud-init did not
generate netplan
I think this is simply because in Openstack, cloud-init-generator (well,
ds-identify from cloud-init) looks at dmi, doesn't find the make/model
data there since there isn't (because no CONFIG_DMI), and gives up doing
anything else.
Please enable CONFIG_DMI on the linux-kvm kernel.
--
You
It really is *defaults* though, because you don't want to have any extra
devices included that could throw off the boot (such as a RNG, which
should not be added by default). In any case, I'll attach the xml I use
as well, but I reproduce the build on a typical artful install.
The only important
Libvirt XML for the VM.
** Attachment added: "vm.xml"
https://bugs.launchpad.net/cloud-init/+bug/1727358/+attachment/4996984/+files/vm.xml
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1727358
You'll want to add an additional disk to provide the metadata for cloud-
init too. The exact iso file I have used is attached.
** Attachment added: "seed.iso"
https://bugs.launchpad.net/cloud-init/+bug/1727358/+attachment/4996928/+files/seed.iso
--
You received this bug notification because
You can easily reproduce this by running the following image in virt-
manager with a default setup (and optionally add a RNG device if
necessary):
https://launchpad.net/~cyphermox/+livefs/ubuntu/artful/ubuntu-
cpc/+build/113428/+files/livecd.ubuntu-cpc.img
--
You received this bug notification
** Attachment added: "cloud-init.tar.gz"
https://bugs.launchpad.net/cloud-init/+bug/1727358/+attachment/4995724/+files/cloud-init.tar.gz
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1727358
This is running on *minimized* images, with linux-kvm kernel; so there
might well not be CONFIG_DMI. This is however not the issue (or most
likely not). Tests are done in qemu, to simulate running the images in
openstack for now (but they are meant to start in openstack without
issues). It's
Sounds like maybe that kernel defaults to noarp and we'd want systemd to
retain previous behavior?
Do you have any sysctl configuration that forces arp state?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Attachment added: "cloud-init.log"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1727358/+attachment/4994544/+files/cloud-init.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
http://paste.ubuntu.com/25816789/ for the full logs.
cloud-init is very slow to complete its initialization steps.
Specifically, the 'init' takes over 150 seconds.
Cloud-init v. 17.1 running 'init-local' at Wed, 25 Oct 2017 13:22:07 +. Up
2.39 seconds.
2017-10-25
Public bug reported:
Use dummy UUIDs:
----0001
^ would do just fine; since that's unlikely to end in a collision and a
generated UUID would never be the same across reboot.
** Affects: nplan (Ubuntu)
Importance: Undecided
Status: New
--
You received
Verification-done for xenial with nplan 0.29~16.04.1:
The bug this is fixing is a regression in 0.26~16.04.1, which is a
version that only landed in -proposed. 0.23~16.04.1 (the previous
released nplan) does not show this bug, and 0.29~16.04.1 does not show
IPv6 issues.
I set up a container with
1201 - 1300 of 8586 matches
Mail list logo
