** Changed in: grub2 (Ubuntu)
Status: Incomplete => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1822007
Title:
Grub fails to request the /grub/grub.cfg over HTTP when booting with
Public bug reported:
>From Seth's security review:
TL;dr: please see if we could replace the use of chown -R with something
else.
"""
I reviewed heat-dashboard version 1.4.0-0ubuntu1 as checked into cosmic.
This shouldn't be considered a full audit but rather a quick gauge of
maintainability.
Thanks. MIR approved.
** Changed in: heat-dashboard (Ubuntu)
Status: Incomplete => 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/1750576
Title:
[MIR] heat-dashboard
To manage
Sounds like what you want is b). If all we need is the font, then also
why is a font bundled with an OAUTH server?
For all intents and purposes, it should be more or less easy to split
out.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Setting mailman to Triaged; let's get this off the "New MIRs" list --
it's not new, just not completed yet. mailman3's status nicely captures
this.
** Changed in: mailman (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1821867
Title:
network interface is down after post-install reboot of a default disco
installation
To manage notifications about this bug go
Given the options shown in firmware and switching to AHCI fixes things
as per xnox's comments; this is squarely a "kernel" issue -- one we
can't really fix in ubiquity in any case.
The kernel side, to support this new RAID or "Intel RST" mode comes with
its own set of problems, but I'll let the
Julian verified this as not reproducing on disco now, with the livecd-
rootfs change. Closing the ubiquity task as invalid.
** Changed in: ubiquity (Ubuntu Disco)
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Could you please run:
sudo debconf-show grub-pc
sudo debconf-show grub-efi-amd64
I've attempted to reproduce this; by first downgrading to a previous version,
changing settings in /etc/default/grub, and proceeding with the upgrade, but no
matter what I do, the changes do remain in
Verification-done for cosmic:
With a netplan config setting up only wireless:
network:
version: 2
renderer: networkd
wifis:
wlan0:
dhcp4: yes
dhcp6: yes
access-points:
cyphermox.net:
password: [redacted]
Verification-done on cosmic:
ubuntu@ubuntu:~$ dpkg -l netplan.io | grep ii
ii netplan.io 0.96-0ubuntu0.18.10.2 arm64YAML network
configuration abstraction for various backends
ubuntu@ubuntu:~$ grep -A 20 wifis /etc/netplan/50-cloud-init.yaml
wifis:
wlan0:
Verification-done on bionic:
ubuntu@ubuntu-XPS-13-9350:/etc/netplan$ dpkg -l netplan.io | cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name
Verification done for cosmic:
ubuntu@test-netplan-cosmic:~$ cat /etc/netplan/50-cloud-init.yaml | grep -A 10
'tunnels'
tunnels:
he-ipv6:
mode: sit
remote: xxx.xxx.xxx.xxx
local: xxx.xxx.xxx.xxx
addresses:
-
Verification-done on bionic for netplan.io:
netplan.io:
Installed: 0.96-0ubuntu0.18.04.2
Candidate: 0.96-0ubuntu0.18.04.2
Version table:
*** 0.96-0ubuntu0.18.04.2 500
-1 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages
100 /var/lib/dpkg/status
Verification-done on cosmic for netplan.io:
ubuntu@civil-eft:~$ apt-cache policy netplan.io
netplan.io:
Installed: 0.96-0ubuntu0.18.10.2
Candidate: 0.96-0ubuntu0.18.10.2
Version table:
*** 0.96-0ubuntu0.18.10.2 500
-1 http://archive.ubuntu.com/ubuntu cosmic-proposed/main amd64
Verification-done for bionic:
Changing the renderer to NetworkManager still leads to a working system
with live connections, even with the NetworkManager files now having a
.nmconnection extension:
ubuntu@just-boa:~$ dpkg -l netplan.io | grep ii
ii netplan.io 0.96-0ubuntu0.18.04.2 amd64
Verification-done for cosmic:
With the changes and NetworkManager connection files now having a
.nmconnection, the network still comes up and the system is still
reachable, with the renderer value in netplan yaml changed to
'NetworkManager'.
ubuntu@civil-eft:~$ dpkg -l netplan.io | grep ii
ii
Setting back to verification-done: Alfonso already verified this same
SRU; no changes with the new revision in -proposed.
** Tags removed: verification-needed verification-needed-bionic
verification-needed-cosmic
** Tags added: verification-done-bionic verification-done-cosmic
--
You received
Resetting to verification-done since these are for documentation changes
with no difference in the new revision in -proposed.
** Tags removed: verification-needed verification-needed-bionic
verification-needed-cosmic
** Tags added: verification-done-bionic verification-done-cosmic
--
You
This hasn't changed with the new revision in -proposed; re-setting to
verification-done.
** Tags removed: verification-needed verification-needed-bionic
verification-needed-cosmic
** Tags added: verification-done-bionic verification-done-cosmic
--
You received this bug notification because you
Setting back to verification-done; this is still verified for bionic and
cosmic (no change with new revision in -proposed).
** Tags removed: verification-needed verification-needed-bionic
verification-needed-cosmic
** Tags added: verification-done-bionic verification-done-cosmic
--
You
This hasn't changed in bionic and cosmic; previously released SRU which
is again included in the changelog for this backport.
** Tags removed: verification-needed verification-needed-bionic
verification-needed-cosmic
** Tags added: verification-done-bionic verification-done-cosmic
--
You
Setting verification-done tags for bionic and cosmic missing after
verification in comment #27.
** Tags removed: verification-needed verification-needed-bionic
verification-needed-cosmic
** Tags added: verification-done-bionic verification-done-cosmic
--
You received this bug notification
No need to re-test these; it's already been included in bionic/cosmic
and bug comments are a side-effect of the changelogs for the upload with
this backport.
** Tags removed: verification-needed verification-needed-bionic
verification-needed-cosmic
** Tags added: verification-done-bionic
Still verification-done on bionic; this hasn't changed with the new
revision in -proposed.
** 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.
Verification-done for cosmic:
ubuntu@noted-fish:~$ dpkg -l grub\* | grep ii
ii grub-common 2.02+dfsg1-5ubuntu8.3 amd64GRand
Unified Bootloader (common files)
ii grub-efi-amd642.02+dfsg1-5ubuntu8.3 amd64GRand
Unified Bootloader, version 2
Thanks Blake!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1787630
Title:
[FFe] Include HTTP support in pre-build GRUB module
To manage notifications about this bug go to:
Verification-done on bionic:
ubuntu@brave-elf:~$ dpkg -l grub\* | grep ii
ii grub-common 2.02-2ubuntu8.13 amd64GRand Unified
Bootloader (common files)
ii grub-gfxpayload-lists 0.7 amd64GRUB gfxpayload
blacklist
ii grub-pc 2.02-2ubuntu8.13
Verification-done on xenial:
ubuntu@profound-donkey:~$ snap download pc-kernel --channel 18
Fetching snap "pc-kernel"
Fetching assertions for "pc-kernel"
Install the snap with:
snap ack pc-kernel_192.assert
snap install pc-kernel_192.snap
ubuntu@profound-donkey:~$ grub-fstest
Verification-done on trusty:
ubuntu@dashing-moccasin:~$ apt-cache policy grub-efi-amd64-signed
grub-efi-amd64-signed:
Installed: 1.34.20+2.02~beta2-9ubuntu1.17
Candidate: 1.34.20+2.02~beta2-9ubuntu1.17
Package pin: 1.34.20+2.02~beta2-9ubuntu1.17
Version table:
***
Verification-done on trusty:
ubuntu@dashing-moccasin:~$ apt-cache policy grub-efi-amd64-signed
grub-efi-amd64-signed:
Installed: 1.34.20+2.02~beta2-9ubuntu1.17
Candidate: 1.34.20+2.02~beta2-9ubuntu1.17
Package pin: 1.34.20+2.02~beta2-9ubuntu1.17
Version table:
***
** Description changed:
+ [Impact]
+ Upgrades with shim-signed when only partial upgrades are done.
+
+ [Test case]
+ 1) Install new system, with no updates
+ 2) Run 'sudo apt-get update'
+ 3) Run 'sudo apt-get install shim-signed'
+ 4) Verify that sbsigntool is also updated to the new version.
Verification-failed on trusty:
ii grub-common 2.02~beta2-9ubuntu1.17
amd64GRand Unified Bootloader (common files)
ii grub-efi-amd64 2.02~beta2-9ubuntu1.17
amd64
Verification-done on trusty:
ii grub-common 2.02~beta2-9ubuntu1.17 amd64 GRand Unified Bootloader (common
files)
ii grub-efi-amd64 2.02~beta2-9ubuntu1.17 amd64 GRand Unified Bootloader,
version 2 (EFI-AMD64 version)
ii grub-efi-amd64-bin 2.02~beta2-9ubuntu1.17 amd64 GRand Unified Bootloader,
As a first step I'd look into whether grub is able to correctly get an
IP from DHCP. I wonder if the client class string confuses it.
Could you please take packet captures of the boot attempt? We could then
have a look at the whole thing and compare with grub code to see what
happens?
** Changed
Verification-done for cosmic, using netplan.io 0.96-0ubuntu0.18.10.2:
As for the above test, I set up a new AWS instance (t2.micro); and
applied the configuration (first trying to just set mtu: 1500; then
using dhcp4-overrides: { use-mtu: false }).
ubuntu@ip-172-30-0-81:~$ dpkg -l netplan.io |
Verification-done on bionic with netplan.io 0.96-0ubuntu0.18.04.2:
I set up a new AWS instance (t2.micro in this case); and applied a
similar setup (attempting to just set mtu: 1500, that doesn't work, then
using the new dhcp4-overrides feature). Forcing UseMTU=false makes the
MTU apply to the
Verification done with bionic and cosmic; using the following config:
network:
version: 2
ethernets:
ens4:
match:
macaddress: 52:54:00:ea:e6:7a
mtu: 9000
ens7:
match:
macaddress: 52:54:00:d7:62:4c
Verification done for both bionic and cosmic:
ubuntu@test-netplan-bionic:~$ dpkg -l netplan.io | grep ii
ii netplan.io 0.96-0ubuntu0.18.04.2 amd64YAML network
configuration abstraction for various backends
ubuntu@test-netplan-bionic:~$ sudo sysctl -a | grep tempaddr
sysctl: reading
Yes, that does explain it.
/run/netplan/.yaml is written automatically by initramfs-
tools when booting with a remote root (ie. iscsi); so this does check
out: for example, 'critical' is required in that case, otherwise as soon
as someone runs 'netplan apply' the network will go down and you
une clé Ubuntu fonctionnerait également pour commencer
l'installation.
Pour ce qui est de "legacy inherited", je n'ai jamais vu ce genre
d'option dans le micrologiciel de Lenovo. D'où ca vient?
Mathieu Trudel-Lapierre
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/65B58
** Description changed:
+ [Impact]
+ Minimal installs using netplan to configure the network.
+
+ [Test case]
+ 1) Install Ubuntu minimal server / cloud image
+ 2) Edit /etc/netplan/01-netcfg.yaml to configure the network as necessary.
+ 3) Run 'sudo netplan apply'. Verify that the network comes
I also forgot to mention another entry I see in some of the configs:
set-name: ens3
If you do not need to explicitly rename the interfaces yourself to a
different name, I would avoid setting this at all. It *may* be being set
automatically by cloud-init (if that's in use, but the configs
All of these values should be coming directly from the netplan YAML. Are
all of these options required?
I see:
match:
macaddress: # Do you need to match the interface in this case? Is it
sufficient to match by name if only ens3 is being configured?
Also:
dhcp-identifier: mac #
hanged in: netplan.io (Ubuntu)
Assignee: (unassigned) => 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/1821867
Title:
network interface is down after post-insta
I see no obvious issues with the package, but it's huge and would
benefit the Security Team reviewing it as well.
** Changed in: containerd (Ubuntu)
Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)
--
You received this bug notification because you are a member of Ubuntu
There currently are no plans to that effect.
For now; shipping in the devel series, and the installer does not set up
any partitioning automatically that would make use of this. It's "only"
a convenience for people who do their own partitioning, which requires
some prior knowledge to set this up
** Changed in: cryptsetup
Assignee: TJ (tj) => (unassigned)
** Changed in: cryptsetup (Ubuntu)
Assignee: TJ (tj) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1767527
Verification-done for both bionic and cosmic:
ubuntu@humble-cod:~$ dpkg -l netplan.io | grep ii
ii netplan.io 0.96-0ubuntu0.18.04.1 amd64 YAML network configuration
abstraction for various backends
ubuntu@superb-ram:~$ dpkg -l netplan.io | grep ii
ii netplan.io 0.96-0ubuntu0.18.10.1 amd64 YAML
Verification-done for both bionic and cosmic:
ubuntu@humble-cod:~$ dpkg -l netplan.io | grep ii
ii netplan.io 0.96-0ubuntu0.18.04.1 amd64YAML network
configuration abstraction for various backends
ubuntu@superb-ram:~$ dpkg -l netplan.io | grep ii
ii netplan.io
Verification-done for both bionic and cosmic:
ubuntu@humble-cod:~$ dpkg -l netplan.io | grep ii
ii netplan.io 0.96-0ubuntu0.18.04.1 amd64 YAML network configuration
abstraction for various backends
ubuntu@superb-ram:~$ dpkg -l netplan.io | grep ii
ii netplan.io 0.96-0ubuntu0.18.10.1 amd64 YAML
Verification done on bionic with netplan.io:
mtrudel@daikoku:~$ dpkg -l netplan.io | more
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
This means we'll need to identify what patches need to be applied on top
of v237 to make this work.
Is this crippling? Are we able to verify that dhcp customization work
despite anything missing in systemd? I think it's the case; but I'd like
a second opinion. To be clear: I think we can verify
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1776228
Title:
Duplicate default routes on VMs with multiple NICs
To manage notifications about this bug go to:
That is up to the Ubuntu Core team to do; but before they can do it it
needs to be landed in the archive for classic :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1739578
Title:
Missing support
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1811868
Title:
networkd/NetworkManager are not re-started on netplan apply when
config files are removed
To manage notifications about this
There is no dependency on v239 for netplan backports. Bionic ships with
v237 (and some patches); the dependency on systemd is for >=
235-3ubuntu3 in netplan.io. I do not believe a newer version than that
is required.
Alexey, I really appreciate the work done to make such a backport
available, but
** Changed in: grub2 (Ubuntu Trusty)
Status: Triaged => In Progress
** Changed in: grub2-signed (Ubuntu Trusty)
Status: Triaged => In Progress
** Changed in: grub2 (Ubuntu Trusty)
Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox)
** Changed in: gru
** Description changed:
[Impact]
All users of Ubuntu, especially on updates of the grub packages. (Grub is
used nearly everywhere to boot)
[Test case]
+ == Upgrade prompting ==
+ 0) Install Ubuntu
+ 1) Modify /etc/default/grub.cfg options
+ 2) Copy /etc/default/grub.cfg to
netplan is currently writing about as much as we can for the
networkd/udev configs; some values we don't know how to handle at all.
Looking at this, it feels to me like there will indeed be a need to find
a different data point to differentiate the interfaces, and MAC and
driver are not
** Also affects: netplan.io (Ubuntu)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** Changed in: netplan
Status: New => Triaged
** Changed in: netplan.io (Ubuntu)
Status: New => Triaged
** Changed in:
Triaged / Wishlist
While the example shows "channel", that feature doesn't currently exist.
** Changed in: netplan
Status: New => Triaged
** Changed in: netplan
Importance: Undecided => Wishlist
** Also affects: netplan.io (Ubuntu)
Importance: Undecided
Status: New
**
s: New
** Changed in: netplan.io (Ubuntu)
Status: New => Triaged
** Changed in: netplan.io (Ubuntu)
Importance: Undecided => High
** Summary changed:
- Parsing error
+ Parsing error / silent fail on unmatched brackets
** Changed in: netplan
Assignee: (unassigned) => Mathieu
That's odd. Let's dig in deeper, as it quite likely might be a systemd
bug, but I rather be certain it's not us doing something wrong.
Could you please attach the config files generated in
/run/systemd/network/ so we can confirm that the routes are created for
the right devices?
Thanks!
**
That's not quite the device, but a driver value though. I wonder if it
wouldn't be best to either always set -Dnl80211 on wireless (and -Dwired
for 802.1x on ethernet...), or to make it possible to use an alternative
value if matching by driver.
For example:
wifis:
wlan1:
match:
Triaged; we will need some input from Steve though to figure out how to
addess this in the netplan schema.
It's Triaged High as it actually does potentially impact many devices.
There are sadly still lots of devices that either don't do wext, or
don't do nl80211, and maybe it wouldn't hurt to be
** Also affects: netplan.io (Ubuntu)
Importance: Undecided
Status: New
** Changed in: netplan.io (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
*** This bug is a duplicate of bug 1817660 ***
https://bugs.launchpad.net/bugs/1817660
** Changed in: netplan
Status: New => Fix Released
** Also affects: netplan.io (Ubuntu)
Importance: Undecided
Status: New
** This bug has been marked a duplicate of bug 1817660
Sure. This seems like a simple fix / enhancement.
** Changed in: netplan
Status: New => Triaged
** Changed in: netplan
Importance: Undecided => Wishlist
** Also affects: netplan.io (Ubuntu)
Importance: Undecided
Status: New
** Changed in: netplan.io (Ubuntu)
Status:
What are the exact contents of /etc/netplan/50-cloud-init.yaml and
/etc/netplan/60-puppet-netplan.yaml? Do both define bond0?
I have used the config provided (after setting dummy IPs and MAC that
pass validation) and made sure indentation was correct, and it seems to
parse and generate config
This is a red herring. The debug message does not mean that there isn't
configuration.
Is it possible that the MAC address changes across reboots? Could you
enable debugging on systemd-networkd; then reboot so we can see if the
interfaces are available at the time netwrokd will try to apply the
** Changed in: netplan
Status: New => Triaged
** Changed in: netplan
Importance: Undecided => High
** Also affects: netplan.io (Ubuntu)
Importance: Undecided
Status: New
** Changed in: netplan.io (Ubuntu)
Status: New => Triaged
** Changed in: netplan.io (Ubuntu)
Sound simple and straightforward. I was not aware that such shorthand
was possible (in fact, it doesn't seem to be documented in the manpage?)
Marking Triaged / Medium; this should really be quite the simple fix to
special-case when the password starts with "hash:".
** Changed in: netplan
Evgeniy Yablokov:
Could you also please send me configs (after sanitizing them for IPs you
don't want to share, etc.)? I'd be quite curious to see how you did your
setup, how it works, etc.
There are some known issues, especially in running 'netplan apply' which
might cause netwrokd to blast
Reassigning to systemd -- netplan isn't limited, but if systemd-networkd
crashes that's a bug in systemd-networkd.
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** No longer affects: netplan
--
You received this bug notification because you are a member of
** 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.
https://bugs.launchpad.net/bugs/1798171
Title:
System fails to boot with \EFI\BOOT\mmx64.efi -
Mar 8 01:55:10 ubuntu /install.py: keeping language packs for: en_CA.UTF-8
en_US.UTF-8
Mar 8 01:55:11 ubuntu ubiquity: W: --force-yes is deprecated, use one of the
options starting with --allow instead.
Mar 8 01:55:11 ubuntu ubiquity: E: Could not get lock
/target/var/cache/apt/archives/lock
Disabling Secure Boot temporarily in order to finish the installation
(mmx64.efi is supposed to be installed on disk at the end of the
install), or editing an installation image on USB to copy
grubx64.efi in a new file called mmx64.efi
Should be good workarounds for this.
Please don't run a
** Changed in: grub2 (Ubuntu)
Assignee: Miguel Alcaide (migalc) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1798171
Title:
System fails to boot with \EFI\BOOT\mmx64.efi - Not
This appears likely to have been a transient network issue. Are you able
to reproduce the same crash again if you try the install again?
** Changed in: ubiquity (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
\EFI\BOOT\mmx64.efi should be on all the images; we should investigate
this in case it was somehow dropped.
The issue seems to be that we immediately go apply the changes when
people configure Secure Boot in the installer, but this requires
MokManager to run at the very next boot -- if it's not
There are some odd errors in UbiquitySyslog.txt I haven't seen before:
Mar 19 04:38:51 ubuntu user-setup: adduser: Only one or two names allowed.
Mar 19 04:38:51 ubuntu ubiquity: chpasswd: (user ) pam_chauthtok() failed,
error:
Mar 19 04:38:51 ubuntu ubiquity: Authentication token manipulation
** Description changed:
+ [Impact]
+ All users of Ubuntu, especially on updates of the grub packages. (Grub is
used nearly everywhere to boot)
+
+ [Test case]
+
+ == User-specified changes ==
+ 0) Install Ubuntu
+ 1) Modify /etc/default/grub.cfg options
+ 2) Update grub to the new package
+
+
** Description changed:
- {Description]
+ [Impact]
+ Required for MAAS to use HTTP transport to provide files for grub2.
+
+ [Test case]
+ 0) Provide kernel and initrd on an HTTP server on the network.
+ 1) Boot from the network in UEFI mode using grub's grubnet.efi binary.
+ 2) Run the
Looks generally good to me, but this is a very large and complex
project. I've tried to review the code as much as I could, but I would
feel better if there were more eyes on it. Assigning to ~ubuntu-security
... I'm not requesting a full security code review, but leaving it to
the Security Team
** Summary changed:
- netplan removes keepalived configuration
+ Restarting systemd-networkd breaks keepalived clusters
** Summary changed:
- Restarting systemd-networkd breaks keepalived clusters
+ [master] Restarting systemd-networkd breaks keepalived clusters
--
You received this bug
*** This bug is a duplicate of bug 1815101 ***
https://bugs.launchpad.net/bugs/1815101
** This bug has been marked a duplicate of bug 1815101
Restarting systemd-networkd breaks keepalived clusters
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Summary changed:
- netplan, keepalived, netplan-apply
+ Restarting systemd-networkd breaks keepalived clusters
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** Also affects: keepalived (Ubuntu)
Importance: Undecided
Status: New
** Changed in:
to Ubuntu Security for review.
** Changed in: runc (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/1
** Changed in: runc (Ubuntu)
Assignee: (unassigned) => 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/1817336
Title:
[MIR] runc
To manage notificati
Closing as Fix Released for upstream and for disco (netplan.io 0.95
contained the fix):
netplan.io (0.95) disco; urgency=medium
.
* New upstream release:
- Added support for WPA Enterprise / 802.1x authentication (LP: #1739578)
- Added support for setting up IP tunnels; supporting
This has been fixed upstream as
https://github.com/CanonicalLtd/netplan/commit/ffda192123b4de0c1f270767c3334d75ef2ebcc1
** Description changed:
+ [Impact]
+ Devices which depend on a wireless network connection at boot.
+
+ [Test case]
+ 1) Configure netplan with a single wireless network to be
** Also affects: netplan
Importance: Undecided
Status: New
** Changed in: netplan
Importance: Undecided => Critical
** Changed in: netplan
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
renderer: NetworkManager
+ ethernets:
+ eno1:
+ addresses: [10.48.134.22/25]
+ gateway4: 10.48.134.1
+ nameservers:
+ addresses: [10.48.134.6]
** Changed in: netplan
Status: In Progress => Fix Released
** Changed in: netplan
Assignee: Mathieu Tr
** Description changed:
+ [Impact]
+ Limited to automatic testing run for netplan.
+
+ [Test cases]
+ 1) Run 'make check' on netplan source twice.
+ 2) Verify the tests pass both times.
+
+ [Regression potential]
+ None.
+
+ ---
+
Several tests related setting terminal flags in
** Description changed:
+ [Impact]
+ All users of netplan when changing configuration and removing devices.
+
+ [Test case]
+ 1) Set up a configuration with additiona devices:
+ network:
+ version: 2
+ ethernets:
+ eno1:
+ match:
+ macaddress:
** Description changed:
+ [Impact]
+ Users of netplan with complex bridge or bond configurations, where setting
MTU or renaming is required and matching is done by MAC address.
+
+ [Test case]
+ 1) Configure netplan with a bond, and device members that use different MTU
values:
+
+ network:
+
** Description changed:
+ [Impact]
+ Documentation for netplan.
+
+ [Test case]
+ Run 'man netplan':
+
+ - validate that the documentation clearly states that setting MTU requires
matching by MAC address; under the 'mtu' section.
+ - validate that documentation is in place for the new
Closing as Fix Released upstream (since it obviously was given there was
an upload to distro)
** Changed in: netplan
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Description changed:
+ [Impact]
+ All users of netplan.
+
+ [Test case]
+ 1) Write an invalid netplan yaml (for each of the examples below)
+ 2) Validate the error is as expected.
+ 3) Verify that the error matches refers to a meaningful place in file (check
line and column values).
+
+ ==
301 - 400 of 8586 matches
Mail list logo
