[Touch-packages] [Bug 1845529] Re: bash completion shows `awk: line 18: function gensub never defined` on `umount /dev/`
** Tags removed: verification-needed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1845529 Title: bash completion shows `awk: line 18: function gensub never defined` on `umount /dev/` Status in bash-completion package in Ubuntu: Invalid Status in ubuntu-meta package in Ubuntu: Invalid Status in util-linux package in Ubuntu: Fix Released Status in bash-completion source package in Eoan: Invalid Status in gawk source package in Eoan: Invalid Status in mawk source package in Eoan: Invalid Status in ubuntu-meta source package in Eoan: Invalid Status in util-linux source package in Eoan: Fix Committed Status in bash-completion source package in Focal: Invalid Status in gawk source package in Focal: Invalid Status in mawk source package in Focal: Invalid Status in ubuntu-meta source package in Focal: Invalid Status in util-linux source package in Focal: Fix Released Status in Debian: Confirmed Bug description: [Impact] Any user attempting to tab-complete from "umount /dev/" when running the bash shell. [Test cases] Steps to reproduce: 1. Install Ubuntu MATE 19.10 using minimal desktop option 2. Open terminal and enter `umount /dev/s` and then hit Expected result: * bash completion works as expected Actual results: * bash completion does not work : $ umount /dev/awk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined $ umount /meawk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined [Regression potential] Since it is limited to a single file (/usr/share/bash-completion/completions/umount) and affects only it, as well as given that it currently does not work, I estimate this as a low risk change. Things to look out for as a regression would be if another previously-working completion would fail to work (ie. what if mount stops completing correctly, and works again if the fix is backed out?). --- ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: bash-completion 1:2.9-1ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8 Uname: Linux 5.3.0-10-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: MATE Date: Thu Sep 26 18:46:59 2019 Dependencies: InstallationDate: Installed on 2019-09-26 (0 days ago) InstallationMedia: Ubuntu-MATE 19.10 "Eoan Ermine" - Beta amd64 (20190926.1) PackageArchitecture: all SourcePackage: bash-completion UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1845529/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1845529] Re: bash completion shows `awk: line 18: function gensub never defined` on `umount /dev/`
** Description changed: + [Impact] + Any user attempting to tab-complete from "umount /dev/" when running the bash shell. + + [Test cases] Steps to reproduce: 1. Install Ubuntu MATE 19.10 using minimal desktop option 2. Open terminal and enter `umount /dev/s` and then hit Expected result: * bash completion works as expected Actual results: * bash completion does not work : $ umount /dev/awk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined - $ umount /meawk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined + + + [Regression potential] + Since it is limited to a single file (/usr/share/bash-completion/completions/umount) and affects only it, as well as given that it currently does not work, I estimate this as a low risk change. Things to look out for as a regression would be if another previously-working completion would fail to work (ie. what if mount stops completing correctly, and works again if the fix is backed out?). + + --- + ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: bash-completion 1:2.9-1ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8 Uname: Linux 5.3.0-10-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: MATE Date: Thu Sep 26 18:46:59 2019 Dependencies: - + InstallationDate: Installed on 2019-09-26 (0 days ago) InstallationMedia: Ubuntu-MATE 19.10 "Eoan Ermine" - Beta amd64 (20190926.1) PackageArchitecture: all SourcePackage: bash-completion UpgradeStatus: No upgrade log present (probably fresh install) ** Changed in: bash-completion (Ubuntu Focal) Status: Incomplete => Invalid ** Also affects: util-linux (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: gawk (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: mawk (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: ubuntu-meta (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: bash-completion (Ubuntu Eoan) Importance: Undecided Status: New ** Changed in: bash-completion (Ubuntu Eoan) Status: New => Invalid ** No longer affects: gawk (Ubuntu) ** No longer affects: mawk (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1845529 Title: bash completion shows `awk: line 18: function gensub never defined` on `umount /dev/` Status in bash-completion package in Ubuntu: Invalid Status in ubuntu-meta package in Ubuntu: Invalid Status in util-linux package in Ubuntu: Fix Released Status in bash-completion source package in Eoan: Invalid Status in gawk source package in Eoan: New Status in mawk source package in Eoan: New Status in ubuntu-meta source package in Eoan: New Status in util-linux source package in Eoan: New Status in bash-completion source package in Focal: Invalid Status in gawk source package in Focal: Invalid Status in mawk source package in Focal: Invalid Status in ubuntu-meta source package in Focal: Invalid Status in util-linux source package in Focal: Fix Released Status in Debian: Confirmed Bug description: [Impact] Any user attempting to tab-complete from "umount /dev/" when running the bash shell. [Test cases] Steps to reproduce: 1. Install Ubuntu MATE 19.10 using minimal desktop option 2. Open terminal and enter `umount /dev/s` and then hit Expected result: * bash completion works as expected Actual results: * bash completion does not work : $ umount /dev/awk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined $ umount /meawk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined [Regression potential] Since it is limited to a single file (/usr/share/bash-completion/completions/umount) and affects only it, as well as given that it currently does not work, I estimate this as a low risk change. Things to look out for as a regression would be if another previously-working completion would fail to work (ie. what if mount stops completing correctly, and works again if the fix is backed out?). --- ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: bash-completion 1:2.9-1ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8 Uname: Linux 5.3.0-10-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: MATE
[Touch-packages] [Bug 1845529] Re: bash completion shows `awk: line 18: function gensub never defined` on `umount /dev/`
** Also affects: util-linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1845529 Title: bash completion shows `awk: line 18: function gensub never defined` on `umount /dev/` Status in bash-completion package in Ubuntu: Triaged Status in gawk package in Ubuntu: Invalid Status in mawk package in Ubuntu: Invalid Status in ubuntu-meta package in Ubuntu: Invalid Status in util-linux package in Ubuntu: New Status in bash-completion source package in Focal: Triaged Status in gawk source package in Focal: Invalid Status in mawk source package in Focal: Invalid Status in ubuntu-meta source package in Focal: Invalid Status in util-linux source package in Focal: New Status in Debian: Confirmed Bug description: Steps to reproduce: 1. Install Ubuntu MATE 19.10 using minimal desktop option 2. Open terminal and enter `umount /dev/s` and then hit Expected result: * bash completion works as expected Actual results: * bash completion does not work : $ umount /dev/awk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined $ umount /meawk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined awk: line 18: function gensub never defined ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: bash-completion 1:2.9-1ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8 Uname: Linux 5.3.0-10-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: MATE Date: Thu Sep 26 18:46:59 2019 Dependencies: InstallationDate: Installed on 2019-09-26 (0 days ago) InstallationMedia: Ubuntu-MATE 19.10 "Eoan Ermine" - Beta amd64 (20190926.1) PackageArchitecture: all SourcePackage: bash-completion UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1845529/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1852772] Re: test_updates_interval fails on focal
** Changed in: software-properties (Ubuntu)
Status: Triaged => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1852772
Title:
test_updates_interval fails on focal
Status in software-properties package in Ubuntu:
Fix Committed
Bug description:
==
FAIL: test_updates_interval (tests.test_dbus.TestDBus)
--
Traceback (most recent call last):
File "/build/software-properties-0.98.6/tests/test_dbus.py", line 332, in
test_updates_interval
self.assertTrue('APT::Periodic::Update-Package-Lists "1";' in config)
AssertionError: False is not true
Looking closer, while in the SetUpdateInterval() method in
softwareproperties/dbus/SoftwarePropertiesDBus.py, days is of
dbus.Int32 type. A simple print output shows:
days=dbus.Int32(1)
D-Bus is statically typed, unlike python. More details at:
https://dbus.freedesktop.org/doc/dbus-python/tutorial.html#data-types
I think once we're in the dbus method (SetUpdateInterval() method in
softwareproperties/dbus/SoftwarePropertiesDBus.py) we can convert the
dbus.Int32 to an int.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1852772/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1854392] Re: Bluetooth headphones won't use A2DP on reconnect
That's not /really/ helpful anyway. You'd have installed an extra application, for a wholly unrelated issue, and still have to set the profile to A2DP yourself. Alistair, there are messages in your logs that seem to point to a firmware issue: Nov 26 16:56:25 albatross bluetoothd[1010]: Unable to get io data for Headset Voice gateway: getpeername: Transport endpoint is not connected (107) Furthermore, I see some slightly unusual messages that point to an issue with the firmware (usually) as well: Nov 26 14:45:14 albatross kernel: Bluetooth: hci0: SCO packet for unknown connection handle 0 Nov 26 14:45:14 albatross kernel: Bluetooth: hci0: SCO packet for unknown connection handle 0 Nov 26 14:45:14 albatross kernel: Bluetooth: hci0: SCO packet for unknown connection handle 0 Nov 26 14:45:14 albatross kernel: Bluetooth: hci0: SCO packet for unknown connection handle 0 Nov 26 14:45:14 albatross kernel: Bluetooth: hci0: SCO packet for unknown connection handle 257 Nov 26 14:45:14 albatross kernel: Bluetooth: hci0: SCO packet for unknown connection handle 257 It's possible the hardware gets confused by losing the connection that was initially there. I realize this might not be /so/ helpful, but have you also tried with another model of bluetooth headphones, assuming you have something available? Please see if you can attach the full contents of /var/log/syslog after reproducing the issue (with a different model or with the usual Sonys); once you've made sure that it doesn't contain sensitive data. I'd need to know when you started each attempt so we can see exactly how the system reacts to it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1854392 Title: Bluetooth headphones won't use A2DP on reconnect Status in bluez package in Ubuntu: Confirmed Bug description: *** This bug is the same as bug 1724919, but is NOT A DUPLICATE because that bug was closed because it was reported for Ubuntu 17.10, which is out of support. This bug is for newer versions, such as 19.10. PLEASE DO NOT MARK THIS BUG AS A DUPLICATE. *** On Ubuntu 19.10 on my Thinkpad T470s, my Sony WH-1000XM3 headphones pair using Bluetooth with no problems, and use A2DP by default. If I then power off the headphones and power them back on, they reconnect but use HSP/HFP and sound terrible. If I manually go into the sound settings, A2DP is offered as an option, but selecting it doesn't take effect. The headphones remain stuck in HSP/HFP mode. Unpairing the headphones and re-pairing them again selects A2DP by default, until the next time I switch the headphones off. Then they're back to stuck in HSP/HFP until I unpair them once again. I therefore need to unpair and re-pair them every time I want to use them, which is a nuisance. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: bluez 5.50-0ubuntu4 ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1 Uname: Linux 5.3.0-19-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu8.2 Architecture: amd64 CurrentDesktop: Unity:Unity7:ubuntu Date: Thu Nov 28 13:28:52 2019 InstallationDate: Installed on 2017-08-16 (833 days ago) InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) InterestingModules: rfcomm bnep btusb bluetooth Lsusb: Bus 002 Device 002: ID 0bda:0316 Realtek Semiconductor Corp. USB3.0-CRW Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 5986:111c Acer, Inc Integrated Camera Bus 001 Device 002: ID 8087:0a2b Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 20HFCTO1WW ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-19-generic root=UUID=c023de63-612b-4367-874e-b3c987874f56 ro quiet splash vt.handoff=7 SourcePackage: bluez UpgradeStatus: Upgraded to eoan on 2019-10-04 (55 days ago) dmi.bios.date: 08/30/2019 dmi.bios.vendor: LENOVO dmi.bios.version: N1WET56W (1.35 ) dmi.board.asset.tag: Not Available dmi.board.name: 20HFCTO1WW dmi.board.vendor: LENOVO dmi.board.version: Not Defined dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN1WET56W(1.35):bd08/30/2019:svnLENOVO:pn20HFCTO1WW:pvrThinkPadT470s:rvnLENOVO:rn20HFCTO1WW:rvrNotDefined:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T470s dmi.product.name: 20HFCTO1WW dmi.product.sku: LENOVO_MT_20HF_BU_Think_FM_ThinkPad T470s dmi.product.version: ThinkPad T470s dmi.sys.vendor: LENOVO hciconfig: hci0:Type: Primary Bus: USB BD Address: F8:59:71:8D:1A:16 ACL MTU: 1021:4 SCO MTU: 96:6 UP RUNNING PSCAN ISCAN RX bytes:3713310 acl:385 sco:2759 events:508913 errors:0 TX bytes:432771109
[Touch-packages] [Bug 1852772] Re: test_updates_interval fails on focal
I see no objection at all; that fix looks obviously correct and does fix
the test.
** Changed in: software-properties (Ubuntu)
Assignee: (unassigned) => Corey Bryant (corey.bryant)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1852772
Title:
test_updates_interval fails on focal
Status in software-properties package in Ubuntu:
Triaged
Bug description:
==
FAIL: test_updates_interval (tests.test_dbus.TestDBus)
--
Traceback (most recent call last):
File "/build/software-properties-0.98.6/tests/test_dbus.py", line 332, in
test_updates_interval
self.assertTrue('APT::Periodic::Update-Package-Lists "1";' in config)
AssertionError: False is not true
Looking closer, while in the SetUpdateInterval() method in
softwareproperties/dbus/SoftwarePropertiesDBus.py, days is of
dbus.Int32 type. A simple print output shows:
days=dbus.Int32(1)
D-Bus is statically typed, unlike python. More details at:
https://dbus.freedesktop.org/doc/dbus-python/tutorial.html#data-types
I think once we're in the dbus method (SetUpdateInterval() method in
softwareproperties/dbus/SoftwarePropertiesDBus.py) we can convert the
dbus.Int32 to an int.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1852772/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
Thanks. Let's put both tasks as Triaged again then, since it's obviously not fixed in disco and bionic. I don't think this qualifies as a regression though, since the feature was never available before. It's just not finished since the systemd side of this isn't complete. ** Changed in: systemd (Ubuntu Bionic) Status: Fix Released => Triaged ** Changed in: systemd (Ubuntu Disco) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1671951 Title: networkd should allow configuring IPV6 MTU Status in cloud-init package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Bionic: Confirmed Status in netplan.io source package in Bionic: Fix Released Status in systemd source package in Bionic: Triaged Status in cloud-init source package in Disco: New Status in netplan.io source package in Disco: Fix Released Status in systemd source package in Disco: Triaged Bug description: = netplan.io = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Apply a netplan configuration that specifices ipv6-mtu: network: version: 2 ethernets: eth0: dhcp4: true dhcp6: true ipv6-mtu: 6000 * Check that MTU bytes, is at least IPv6MTUBytes on the interface: $ sysctl net.ipv6.conf.eth0.mtu net.ipv6.conf.eth0.mtu = 6000 [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of netplan.io = = systemd = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Use IPv6MTUBytes= setting in a .network unit * Restart systemd-network * Check that there no error messages / warnings about not-recognizing this option * Check that MTU bytes, is at least IPv6MTUBytes on the interface [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of systemd = 1) Zesty 2) systemd-232-19 3) I need to configure the IPV6 MTU for tunneling by adding an IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 static address in the [Network] section 4) networkd does not parse or read the value and does not apply this configuration to the interface. Upstream has discussed this issue here: https://github.com/systemd/systemd/pull/1533 But it's been closed in favor of only setting via RA. However, we know of multiple use-case which are currently supported in ifdupdown where we want to retain control over IPV6 MTU values outside of PMTU Discovery configurations. Some context from those discussions >> Client systems that route their ipv6 packets to a 6in4 router also >> have to have their ipv6 mtu lowered. They could lower their link mtu, >> so their ipv6 packets are small enough, but that reduces performance >> of their ipv4 network. Yes. Anything that creates a PMTUD black hole can result in situations where the higher header overhead of IPv6 will cause IPv4 to pass but IPv6 traffic to be dropped. One example here is egress from an ipsec tunnel wherein the next hop MTU is too low for IPv6 datagrams to pass. Another is VM -> whatever -> host bridge -> tunnel ingress. If the datagram cannot enter the tunnel due to size, it is dropped, and an ICMP response uses the tunnel address as a source, which may not be routable back to the origin. This one is an issue with IPv4 as well, and is one case where manually setting the IPv6 MTU lower than the (also manually set) device MTU is of benefit. In essence, any of these sort of cases that require an explicit setting of the device MTU will likely require a setting of the IPv6 mtu as well to account for its larger header overhead. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe :
[Touch-packages] [Bug 1849560] Re: Please revise the files installed in /etc/
** Tags added: writable-etc -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1849560 Title: Please revise the files installed in /etc/ Status in openssh package in Ubuntu: New Bug description: openssh-server and openssh-client install various files under /etc: /etc/ssh/* /etc/systemd/system/sshd.service Please see if these files can be moved elsewhere, in accordance with FHS: /etc should only contain files writable by the system administrator, and in Ubuntu Core 20 we should aim to have no writable files in /etc (as it will be included in images, avoid conflict resolution on upgrades). At a glance, it looks like /etc/systemd/system/sshd.service could be moved to /lib/systemd/system, and many of the files in /etc/ssh do have suitable locations elsewhere on the system, such as /var/lib/ for generated keys, /usr/share/ for default SSH configurations, etc.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1849560/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1849560] [NEW] Please revise the files installed in /etc/
Public bug reported: openssh-server and openssh-client install various files under /etc: /etc/ssh/* /etc/systemd/system/sshd.service Please see if these files can be moved elsewhere, in accordance with FHS: /etc should only contain files writable by the system administrator, and in Ubuntu Core 20 we should aim to have no writable files in /etc (as it will be included in images, avoid conflict resolution on upgrades). At a glance, it looks like /etc/systemd/system/sshd.service could be moved to /lib/systemd/system, and many of the files in /etc/ssh do have suitable locations elsewhere on the system, such as /var/lib/ for generated keys, /usr/share/ for default SSH configurations, etc.) ** Affects: openssh (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1849560 Title: Please revise the files installed in /etc/ Status in openssh package in Ubuntu: New Bug description: openssh-server and openssh-client install various files under /etc: /etc/ssh/* /etc/systemd/system/sshd.service Please see if these files can be moved elsewhere, in accordance with FHS: /etc should only contain files writable by the system administrator, and in Ubuntu Core 20 we should aim to have no writable files in /etc (as it will be included in images, avoid conflict resolution on upgrades). At a glance, it looks like /etc/systemd/system/sshd.service could be moved to /lib/systemd/system, and many of the files in /etc/ssh do have suitable locations elsewhere on the system, such as /var/lib/ for generated keys, /usr/share/ for default SSH configurations, etc.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1849560/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1849554] Re: Please move cache files to a different location
** Tags added: writable-etc -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1849554 Title: Please move cache files to a different location Status in apparmor package in Ubuntu: New Bug description: /etc/apparmor.d/cache is currently used to keep cache files for apparmor. Unfortunately, these files are in a location that is inconsistent with FHS guidelines for cache. Moreover, /etc is not a core path for Ubuntu Core 20, which means it is planned to not be writable; and to come directly from images. According to the FHS, the best location for apparmor cache files should be in a hierarchy under /var/cache. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1849554/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1849559] [NEW] /etc/dbus-1/system.d/wpa_supplicant.conf is in wrong location
Public bug reported: The /etc/dbus-1/system.d/wpa_supplicant.conf is installed in the wrong location. It is a system-wide default config for dbus, and as such probably should be in /usr/share/dbus-1/system.d instead; like most other DBus definitions installed on a typical system. ** Affects: wpa (Ubuntu) Importance: Undecided Status: New ** Tags: writable-etc ** Tags added: writable-etc -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1849559 Title: /etc/dbus-1/system.d/wpa_supplicant.conf is in wrong location Status in wpa package in Ubuntu: New Bug description: The /etc/dbus-1/system.d/wpa_supplicant.conf is installed in the wrong location. It is a system-wide default config for dbus, and as such probably should be in /usr/share/dbus-1/system.d instead; like most other DBus definitions installed on a typical system. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1849559/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1849554] [NEW] Please move cache files to a different location
Public bug reported: /etc/apparmor.d/cache is currently used to keep cache files for apparmor. Unfortunately, these files are in a location that is inconsistent with FHS guidelines for cache. Moreover, /etc is not a core path for Ubuntu Core 20, which means it is planned to not be writable; and to come directly from images. According to the FHS, the best location for apparmor cache files should be in a hierarchy under /var/cache. ** Affects: apparmor (Ubuntu) Importance: Undecided Status: New ** Tags: writable-etc -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1849554 Title: Please move cache files to a different location Status in apparmor package in Ubuntu: New Bug description: /etc/apparmor.d/cache is currently used to keep cache files for apparmor. Unfortunately, these files are in a location that is inconsistent with FHS guidelines for cache. Moreover, /etc is not a core path for Ubuntu Core 20, which means it is planned to not be writable; and to come directly from images. According to the FHS, the best location for apparmor cache files should be in a hierarchy under /var/cache. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1849554/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1846509] Re: networkd doesn't take into account search domain received by DHCP
I could reproduce this trivially; a simple netplan config: network: version: 2 renderer: networkd ethernets: eth0: dhcp: yes Will show that my domain "cyphermox.net" here is not passed from DHCP in networkd to resolved (and does not show in /run/systemd/resolve/stub- resolv.conf or resolv.conf), whereas if I switch the renderer to "NetworkManager", I can then see both ~. and "cyphermox.net" in search domains when running 'systemd-resolve --status'. ** Changed in: systemd (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1846509 Title: networkd doesn't take into account search domain received by DHCP Status in systemd package in Ubuntu: Confirmed Bug description: Hi, When starting a virtual machine with the following command line : qemu-system-x86_64 -k fr -m 1024 -smp 1 -display none \ -rtc base=utc -daemonize \ -drive if=none,file="my.qcow2",id=hd0 \ -device virtio-blk,drive=hd0 \ -netdev user,id=user.0,hostfwd=tcp::32768-:22,dnssearch=dns.companyname.com \ -device virtio-net,netdev=user.0,mac=de:ad:de:01:02:03 \ -vga none The system-network doesn't take into account search domain and then search fail. The same setup does work when using NetworkManager. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1846509/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
Verification-done on disco:
ubuntu@ip-172-30-0-243:~$ lsb_release -cs
disco
ubuntu@ip-172-30-0-243:~$ dpkg -l netplan.io systemd | grep ii
ii netplan.io 0.98-0ubuntu1~19.04.1 amd64YAML network
configuration abstraction for various backends
ii systemd240-6ubuntu5.7amd64system and service manager
ubuntu@ip-172-30-0-243:~$ sudo netplan apply
ubuntu@ip-172-30-0-243:~$ ip link
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: mtu qdisc fq_codel state UP
mode DEFAULT group default qlen 1000
link/ether 06:92:5b:c9:b5:3d brd ff:ff:ff:ff:ff:ff
ubuntu@ip-172-30-0-243:~$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routableconfigured
2 links listed.
ubuntu@ip-172-30-0-243:~$ sysctl net.ipv6.conf.eth0.mtu
net.ipv6.conf.eth0.mtu = 5634
ubuntu@ip-172-30-0-243:~$ cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
eth0:
dhcp4: true
match:
macaddress: 06:92:5b:c9:b5:3d
set-name: eth0
ipv6-mtu: 5634
mtu:
dhcp6: true
dhcp4-overrides:
use-mtu: false
dhcp6-overrides:
use-mtu: false
** Tags added: verification-done-disco
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1671951
Title:
networkd should allow configuring IPV6 MTU
Status in cloud-init package in Ubuntu:
Confirmed
Status in netplan.io package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in cloud-init source package in Bionic:
Confirmed
Status in netplan.io source package in Bionic:
Fix Committed
Status in systemd source package in Bionic:
Fix Committed
Bug description:
= netplan.io =
[Impact]
* IPv6 traffic failing to send/receive due to incompatible/low MTU
setting. Specifically, IPv6 traffic may have higher MTU requirements
than IPv4 traffic and thus may need to be overridden and/or set to a
higher value than IPv6 traffic.
[Test Case]
* Apply a netplan configuration that specifices ipv6-mtu:
network:
version: 2
ethernets:
eth0:
dhcp4: true
dhcp6: true
ipv6-mtu: 6000
* Check that MTU bytes, is at least IPv6MTUBytes on the interface:
$ sysctl net.ipv6.conf.eth0.mtu
net.ipv6.conf.eth0.mtu = 6000
[Regression Potential]
* This is a future compatible backport of an additional keyword not
used by default. It may result in MTU change to a higher value, which
should not cause loss of connectivity.
[Other Info]
* Original bug report below
= end of netplan.io =
= systemd =
[Impact]
* IPv6 traffic failing to send/receive due to incompatible/low MTU
setting. Specifically, IPv6 traffic may have higher MTU requirements
than IPv4 traffic and thus may need to be overridden and/or set to a
higher value than IPv6 traffic.
[Test Case]
* Use IPv6MTUBytes= setting in a .network unit
* Restart systemd-network
* Check that there no error messages / warnings about not-recognizing this
option
* Check that MTU bytes, is at least IPv6MTUBytes on the interface
[Regression Potential]
* This is a future compatible backport of an additional keyword not
used by default. It may result in MTU change to a higher value, which
should not cause loss of connectivity.
[Other Info]
* Original bug report below
= end of systemd =
1) Zesty
2) systemd-232-19
3) I need to configure the IPV6 MTU for tunneling by adding an
IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6
static address in the [Network] section
4) networkd does not parse or read the value and does not apply this
configuration to the interface.
Upstream has discussed this issue here:
https://github.com/systemd/systemd/pull/1533
But it's been closed in favor of only setting via RA.
However, we know of multiple use-case which are currently supported in
ifdupdown where we want to retain control over IPV6 MTU values outside
of PMTU Discovery configurations.
Some context from those discussions
>> Client systems that route their ipv6 packets to a 6in4 router also
>> have to have their ipv6 mtu lowered. They could lower their link mtu,
>> so their ipv6 packets are small enough, but that reduces performance
>>
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
Verification-done on bionic:
ubuntu@ip-172-30-0-140:/run/systemd/network$ lsb_release -cs
bionic
ubuntu@ip-172-30-0-140:/run/systemd/network$ dpkg -l netplan.io | grep ii
ii netplan.io 0.98-0ubuntu1~18.04.1 amd64YAML network
configuration abstraction for various backends
ubuntu@ip-172-30-0-140:/run/systemd/network$ dpkg -l systemd | grep ii
ii systemd237-3ubuntu10.31 amd64system and service manager
ubuntu@ip-172-30-0-140:/run/systemd/network$ cat
/etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
eth0:
dhcp4: true
match:
macaddress: 06:e0:25:2e:08:ef
set-name: eth0
ipv6-mtu: 5634
mtu:
dhcp6: true
dhcp4-overrides:
use-mtu: false
dhcp6-overrides:
use-mtu: false
ubuntu@ip-172-30-0-140:/run/systemd/network$ sudo netplan apply
ubuntu@ip-172-30-0-140:/run/systemd/network$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routableconfigured
2 links listed.
ubuntu@ip-172-30-0-140:/run/systemd/network$ sysctl net.ipv6.conf.eth0.mtu
net.ipv6.conf.eth0.mtu = 5634
ubuntu@ip-172-30-0-140:/run/systemd/network$ ip link
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: mtu qdisc fq_codel state UP
mode DEFAULT group default qlen 1000
link/ether 06:e0:25:2e:08:ef brd ff:ff:ff:ff:ff:ff
ubuntu@ip-172-30-0-140:/run/systemd/network$
** Tags removed: verification-needed verification-needed-bionic zesty
** Tags added: verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1671951
Title:
networkd should allow configuring IPV6 MTU
Status in cloud-init package in Ubuntu:
Confirmed
Status in netplan.io package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in cloud-init source package in Bionic:
Confirmed
Status in netplan.io source package in Bionic:
Fix Committed
Status in systemd source package in Bionic:
Fix Committed
Bug description:
= netplan.io =
[Impact]
* IPv6 traffic failing to send/receive due to incompatible/low MTU
setting. Specifically, IPv6 traffic may have higher MTU requirements
than IPv4 traffic and thus may need to be overridden and/or set to a
higher value than IPv6 traffic.
[Test Case]
* Apply a netplan configuration that specifices ipv6-mtu:
network:
version: 2
ethernets:
eth0:
dhcp4: true
dhcp6: true
ipv6-mtu: 6000
* Check that MTU bytes, is at least IPv6MTUBytes on the interface:
$ sysctl net.ipv6.conf.eth0.mtu
net.ipv6.conf.eth0.mtu = 6000
[Regression Potential]
* This is a future compatible backport of an additional keyword not
used by default. It may result in MTU change to a higher value, which
should not cause loss of connectivity.
[Other Info]
* Original bug report below
= end of netplan.io =
= systemd =
[Impact]
* IPv6 traffic failing to send/receive due to incompatible/low MTU
setting. Specifically, IPv6 traffic may have higher MTU requirements
than IPv4 traffic and thus may need to be overridden and/or set to a
higher value than IPv6 traffic.
[Test Case]
* Use IPv6MTUBytes= setting in a .network unit
* Restart systemd-network
* Check that there no error messages / warnings about not-recognizing this
option
* Check that MTU bytes, is at least IPv6MTUBytes on the interface
[Regression Potential]
* This is a future compatible backport of an additional keyword not
used by default. It may result in MTU change to a higher value, which
should not cause loss of connectivity.
[Other Info]
* Original bug report below
= end of systemd =
1) Zesty
2) systemd-232-19
3) I need to configure the IPV6 MTU for tunneling by adding an
IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6
static address in the [Network] section
4) networkd does not parse or read the value and does not apply this
configuration to the interface.
Upstream has discussed this issue here:
https://github.com/systemd/systemd/pull/1533
But it's been closed in favor of only setting via RA.
However, we know of multiple use-case which are currently supported in
ifdupdown where we want to retain control over IPV6 MTU values
[Touch-packages] [Bug 1723390] Re: lxd containers have become degraded
** Tags removed: rls-aa-incoming ** Tags added: rls-bb-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1723390 Title: lxd containers have become degraded Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Confirmed Status in systemd source package in Eoan: Fix Released Bug description: 20170920 container boots degraded with Oct 13 10:09:28 test20170920 systemd[256]: systemd-hostnamed.service: Failed at step NETWORK spawning /lib/systemd/systemd-hostnamed: Permission denied 20170919 container boots non-degraded. Package list changes are insignificant. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1723390/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1721839] Re: [REGRESSION] Services asked for by UDEV do not get triggered
Is this still an issue on supported releases?
** Changed in: systemd (Ubuntu)
Status: Confirmed => Incomplete
** Tags removed: rls-aa-incoming
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1721839
Title:
[REGRESSION] Services asked for by UDEV do not get triggered
Status in systemd:
New
Status in Release Notes for Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Incomplete
Bug description:
The packages system-config-printer-udev and ippusbxd are installed,
having the following UDEV rule files:
/lib/udev/rules.d/70-printers.rules
--
# Low-level USB device add trigger
ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ENV{ID_USB_INTERFACES}=="*:0701??:*", TAG+="udev-configure-printer",
TAG+="systemd", PROGRAM="/bin/systemd-escape
--template=udev-configure-printer@.service %p", ENV{SYSTEMD_WANTS}+="%c"
# Low-level USB device remove trigger
ACTION=="remove", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
ENV{ID_USB_INTERFACES}=="*:0701*:*", RUN+="udev-configure-printer remove %p"
--
/lib/udev/rules.d/55-ippusbxd.rules
--
# ippusbxd udev rules file
ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device"
ENV{ID_USB_INTERFACES}=="*:070104:*", OWNER="root", GROUP="lp", MODE="0664",
PROGRAM="/bin/systemd-escape --template=ippusbxd@.service
$env{BUSNUM}:$env{DEVNUM}", ENV{SYSTEMD_WANTS}+="%c"
--
If I turn on an appropriate printer (USB, supporting IPP-over-USB,
here the HP DeskJet 2540) I get in the output of "udevadm monitor
--environment"
--
UDEV [17527.514150] add /devices/pci:00/:00:14.0/usb2/2-2 (usb)
ACTION=add
BUSNUM=002
DEVNAME=/dev/bus/usb/002/033
DEVNUM=033
DEVPATH=/devices/pci:00/:00:14.0/usb2/2-2
DEVTYPE=usb_device
DRIVER=usb
ID_BUS=usb
ID_MODEL=Deskjet_2540_series
ID_MODEL_ENC=Deskjet\x202540\x20series
ID_MODEL_ID=c211
ID_REVISION=0100
ID_SERIAL=HP_Deskjet_2540_series_BR54BFB02C05XK
ID_SERIAL_SHORT=BR54BFB02C05XK
ID_USB_INTERFACES=:ffcc00:070104:070102:ff0401:
ID_VENDOR=HP
ID_VENDOR_ENC=HP
ID_VENDOR_FROM_DATABASE=Hewlett-Packard
ID_VENDOR_ID=03f0
MAJOR=189
MINOR=160
PRODUCT=3f0/c211/100
SEQNUM=9891
SUBSYSTEM=usb
SYSTEMD_WANTS=ippusbxd@002:033.service
udev-configure-printer@-devices-pci:00-:00:14.0-usb2-2\x2d2.service
printer.target
TAGS=:udev-configure-printer:systemd:
TYPE=0/0/0
USEC_INITIALIZED=17527513940
UDEV [17527.517724] add
/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0 (usb)
.MM_USBIFNUM=00
ACTION=add
DEVPATH=/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0
DEVTYPE=usb_interface
ID_VENDOR_FROM_DATABASE=Hewlett-Packard
INTERFACE=255/204/0
MODALIAS=usb:v03F0pC211d0100dc00dsc00dp00icFFiscCCip00in00
PRODUCT=3f0/c211/100
SEQNUM=9892
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=17527517478
UDEV [17527.522565] add
/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.2 (usb)
.MM_USBIFNUM=02
ACTION=add
DEVPATH=/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.2
DEVTYPE=usb_interface
ID_VENDOR_FROM_DATABASE=Hewlett-Packard
INTERFACE=255/4/1
MODALIAS=usb:v03F0pC211d0100dc00dsc00dp00icFFisc04ip01in02
PRODUCT=3f0/c211/100
SEQNUM=9895
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=17527522332
UDEV [17527.523761] add
/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1 (usb)
.MM_USBIFNUM=01
ACTION=add
DEVPATH=/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1
DEVTYPE=usb_interface
DRIVER=usblp
ID_VENDOR_FROM_DATABASE=Hewlett-Packard
INTERFACE=7/1/2
MODALIAS=usb:v03F0pC211d0100dc00dsc00dp00ic07isc01ip02in01
PRODUCT=3f0/c211/100
SEQNUM=9893
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=17527523500
UDEV [17527.527275] add
/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/usbmisc/lp1 (usbmisc)
.MM_USBIFNUM=01
ACTION=add
DEVNAME=/dev/usb/lp1
DEVPATH=/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/usbmisc/lp1
MAJOR=180
MINOR=1
SEQNUM=9894
SUBSYSTEM=usbmisc
USEC_INITIALIZED=17527527175
--
Here one can see that the UDEV rules files are correct, leading to the
correct systemd services being requested
SYSTEMD_WANTS=ippusbxd@002:033.service udev-configure-printer
@-devices-pci:00-:00:14.0-usb2-2\x2d2.service printer.target
but neither the service ippusbxd@002:033.service nor the service udev-
configure-printer@-devices-pci:00-:00:14.0-usb2-2\x2d2.service
get started (note that I have put the .service file for ippusbxd in
place by "sudo cp /usr/share/doc/ippusbxd/examples/ippusbxd@.service
/lib/systemd/system/").
I can start each of these services manually though:
sudo systemctl start 'udev-configure-printer@-devices-
pci:00-:00:14.0-usb2-2\x2d2.service'
sudo systemctl start ippusbxd@002:033.service
[Touch-packages] [Bug 1799977] Re: [MIR] gssdp
I can't find who promoted this package to main; but it is there right now, and it seems it also was in previous releases. Closing as Fix Released based on the ack from Seb128 thatit would be subscribed to by desktop-bugs. ** Changed in: gssdp (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gssdp in Ubuntu. https://bugs.launchpad.net/bugs/1799977 Title: [MIR] gssdp Status in gssdp package in Ubuntu: Fix Released Bug description: * Availability Builds on all supported architectures in Ubuntu and on sync from Debian, the package was in main in the past and needs to be re- promoted * Rationale We would like to enable dlna sharing of media files, which is a GNOME upstream feature and relying on gssdp * Security No CVE/known security issue * Quality assurance - the desktop-packages team is subscribed to the package - the bug lists in upstream, the Debian PTS and launchpad are empty - upstream has a testsuit which is being used during build * Dependendies The package dependencies are in main * Standards compliance the package is using standard packaging (dh11), the standards-version is 4.1.1, the package is in sync from Debian * Maintainance Upstream is active and the desktop team is going to look after the package in ubuntu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gssdp/+bug/1799977/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
** Description changed: + = netplan.io = + + [Impact] + + * IPv6 traffic failing to send/receive due to incompatible/low MTU + setting. Specifically, IPv6 traffic may have higher MTU requirements + than IPv4 traffic and thus may need to be overridden and/or set to a + higher value than IPv6 traffic. + + [Test Case] + * Apply a netplan configuration that specifices ipv6-mtu: + + network: + version: 2 + ethernets: + eth0: + dhcp4: true + dhcp6: true + ipv6-mtu: 6000 + + * Check that MTU bytes, is at least IPv6MTUBytes on the interface: + + $ sysctl net.ipv6.conf.eth0.mtu + net.ipv6.conf.eth0.mtu = 6000 + + [Regression Potential] + + * This is a future compatible backport of an additional keyword not + used by default. It may result in MTU change to a higher value, which + should not cause loss of connectivity. + + [Other Info] + + * Original bug report below + + = end of netplan.io = + = systemd = [Impact] - * IPv6 traffic failing to send/receive due to incompatible/low MTU + * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] - * Use IPv6MTUBytes= setting in a .network unit - * Restart systemd-network - * Check that there no error messages / warnings about not-recognizing this option - * Check that MTU bytes, is at least IPv6MTUBytes on the interface + * Use IPv6MTUBytes= setting in a .network unit + * Restart systemd-network + * Check that there no error messages / warnings about not-recognizing this option + * Check that MTU bytes, is at least IPv6MTUBytes on the interface [Regression Potential] - * This is a future compatible backport of an additional keyword not + * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] - - * Original bug report below + + * Original bug report below = end of systemd = 1) Zesty 2) systemd-232-19 3) I need to configure the IPV6 MTU for tunneling by adding an IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 static address in the [Network] section 4) networkd does not parse or read the value and does not apply this configuration to the interface. Upstream has discussed this issue here: https://github.com/systemd/systemd/pull/1533 But it's been closed in favor of only setting via RA. However, we know of multiple use-case which are currently supported in ifdupdown where we want to retain control over IPV6 MTU values outside of PMTU Discovery configurations. Some context from those discussions >> Client systems that route their ipv6 packets to a 6in4 router also >> have to have their ipv6 mtu lowered. They could lower their link mtu, >> so their ipv6 packets are small enough, but that reduces performance >> of their ipv4 network. Yes. Anything that creates a PMTUD black hole can result in situations where the higher header overhead of IPv6 will cause IPv4 to pass but IPv6 traffic to be dropped. One example here is egress from an ipsec tunnel wherein the next hop MTU is too low for IPv6 datagrams to pass. Another is VM -> whatever -> host bridge -> tunnel ingress. If the datagram cannot enter the tunnel due to size, it is dropped, and an ICMP response uses the tunnel address as a source, which may not be routable back to the origin. This one is an issue with IPv4 as well, and is one case where manually setting the IPv6 MTU lower than the (also manually set) device MTU is of benefit. In essence, any of these sort of cases that require an explicit setting of the device MTU will likely require a setting of the IPv6 mtu as well to account for its larger header overhead. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1671951 Title: networkd should allow configuring IPV6 MTU Status in cloud-init package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Bionic: Confirmed Status in netplan.io source package in Bionic: New Status in systemd source package in Bionic: Fix Committed Bug description: = netplan.io = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Apply a netplan configuration that specifices ipv6-mtu: network:
[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU
** Changed in: netplan.io (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1671951 Title: networkd should allow configuring IPV6 MTU Status in cloud-init package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: In Progress Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Bionic: Confirmed Status in netplan.io source package in Bionic: New Status in systemd source package in Bionic: Fix Committed Bug description: = systemd = [Impact] * IPv6 traffic failing to send/receive due to incompatible/low MTU setting. Specifically, IPv6 traffic may have higher MTU requirements than IPv4 traffic and thus may need to be overridden and/or set to a higher value than IPv6 traffic. [Test Case] * Use IPv6MTUBytes= setting in a .network unit * Restart systemd-network * Check that there no error messages / warnings about not-recognizing this option * Check that MTU bytes, is at least IPv6MTUBytes on the interface [Regression Potential] * This is a future compatible backport of an additional keyword not used by default. It may result in MTU change to a higher value, which should not cause loss of connectivity. [Other Info] * Original bug report below = end of systemd = 1) Zesty 2) systemd-232-19 3) I need to configure the IPV6 MTU for tunneling by adding an IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 static address in the [Network] section 4) networkd does not parse or read the value and does not apply this configuration to the interface. Upstream has discussed this issue here: https://github.com/systemd/systemd/pull/1533 But it's been closed in favor of only setting via RA. However, we know of multiple use-case which are currently supported in ifdupdown where we want to retain control over IPV6 MTU values outside of PMTU Discovery configurations. Some context from those discussions >> Client systems that route their ipv6 packets to a 6in4 router also >> have to have their ipv6 mtu lowered. They could lower their link mtu, >> so their ipv6 packets are small enough, but that reduces performance >> of their ipv4 network. Yes. Anything that creates a PMTUD black hole can result in situations where the higher header overhead of IPv6 will cause IPv4 to pass but IPv6 traffic to be dropped. One example here is egress from an ipsec tunnel wherein the next hop MTU is too low for IPv6 datagrams to pass. Another is VM -> whatever -> host bridge -> tunnel ingress. If the datagram cannot enter the tunnel due to size, it is dropped, and an ICMP response uses the tunnel address as a source, which may not be routable back to the origin. This one is an issue with IPv4 as well, and is one case where manually setting the IPv6 MTU lower than the (also manually set) device MTU is of benefit. In essence, any of these sort of cases that require an explicit setting of the device MTU will likely require a setting of the IPv6 mtu as well to account for its larger header overhead. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1836695] Re: Netplan ignores static routes when using DHCP
Since netplan only does writing configuration to be consumed by the backends like systemd, this would actually be a systemd bug; reassigning. I thought that worked though, in some setups, especially with use- routes: false as it was being done in the config above. Nevertheless, it needs investigation. I expect we could see the routes are being installed, then ripped out after systemd-networkd gets an address from DHCP. ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: netplan Status: New => Invalid ** Changed in: systemd (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1836695 Title: Netplan ignores static routes when using DHCP Status in netplan: Invalid Status in systemd package in Ubuntu: New Bug description: Consider the following setup: network: version: 2 renderer: networkd ethernets: ens4: dhcp-identifier: mac dhcp4: yes dhcp4-overrides: use-dns: no use-ntp: no send-hostname: no use-hostname: no use-routes: no routes: - to: 10.0.0.0/8 via: 10.50.0.1 optional: true Thus I only need to get the IP address by DHCP, then add some static routes. This setup doesn't work. Apparently `routes` keyword only works when using static addresses. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1836695/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1838322] Re: Support Japanese new era "令和 (Reiwa)"
** Also affects: icu (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to icu in Ubuntu. https://bugs.launchpad.net/bugs/1838322 Title: Support Japanese new era "令和 (Reiwa)" Status in icu package in Ubuntu: Fix Released Status in icu source package in Xenial: New Status in icu source package in Bionic: New Status in icu source package in Disco: New Bug description: [Background] Many packages are affected by the requirement to support the new era "Reiwa" (令和） This is the meta bug to track packages that need fixes; which packages have already been SRUd to previous releases, how to prioritize the work needed, and general test cases for verifying that things are working as expected. [Impact] Users who run Ubuntu in Japanese. [Test cases] Unicode data embedded into icu should include REIWA like it includes HEISEI. == Date conversion == On applications that support writing dates in long form, or with symbols to denote era (either in X00.00.00 format or in GG1G5G1G format (G- glyph; X- character): 1) Enable date formatting in each of the above formats that are supported (long form or symbols) 2) Type in '2019/05/01' to be formatted, verify that it shows as "令和1年5月1日" or "R1.05.01" 3) Type in '2019/04/30' to be formatted, verify that it shows as "平成31年4月30日" or "H31.4.30" == Character maps / font support == 1) Search for character "SQUARE ERA NAME" 2) Verify that the results include at least "SQUARE ERA NAME HEISEI" and "SQUARE ERA NAME REIWA" (there should also be Syouwa, Taisyou and Meizi), and that the glyphs are readable: - SQUARE ERA NAME HEISEI: ㍻ - SQUARE ERA NAME REIWA: 令和 (in a single glyph) Display of the Reiwa square glyph is font-specific; it may show simply as a empty square or a square with hex characters. If that is the case, the unicode data supports the new character, but the selected font does not include the new glyph. [Regression potential] This is a potentially large change as it impacts font display, character sets as well as date conversions. As such, extreme care should be taken to ensure that regressions are avoided, such that dates previous to May 1, 2019 continue to display as before, and dates onward are displayed with the new era symbols. The included test cases account for verifying the continued behavior or previous dates. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/icu/+bug/1838322/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1828884] Re: [META] Handling Japanese new era "令和 (Reiwa)"
icu split up into bug 1838322. ** Changed in: openjdk-8 (Ubuntu Xenial) Status: New => Fix Released ** Changed in: openjdk-8 (Ubuntu Bionic) Status: New => Fix Released ** Changed in: openjdk-8 (Ubuntu Disco) Status: New => Fix Released ** No longer affects: icu (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to icu in Ubuntu. https://bugs.launchpad.net/bugs/1828884 Title: [META] Handling Japanese new era "令和 (Reiwa)" Status in Poppler: New Status in fonts-noto-cjk package in Ubuntu: Fix Released Status in libreoffice package in Ubuntu: Fix Released Status in libreoffice-l10n package in Ubuntu: Fix Released Status in mozc package in Ubuntu: Fix Released Status in openjdk-8 package in Ubuntu: Fix Released Status in poppler-data package in Ubuntu: New Status in libreoffice source package in Xenial: Fix Released Status in libreoffice-l10n source package in Xenial: Fix Released Status in mozc source package in Xenial: Fix Released Status in openjdk-8 source package in Xenial: Fix Released Status in poppler-data source package in Xenial: New Status in fonts-noto-cjk source package in Bionic: Fix Released Status in libreoffice source package in Bionic: Fix Released Status in libreoffice-l10n source package in Bionic: Fix Released Status in mozc source package in Bionic: Fix Released Status in openjdk-8 source package in Bionic: Fix Released Status in poppler-data source package in Bionic: New Status in libreoffice source package in Cosmic: Fix Released Status in libreoffice-l10n source package in Cosmic: Fix Released Status in mozc source package in Cosmic: Fix Released Status in fonts-noto-cjk source package in Disco: Fix Released Status in libreoffice source package in Disco: Fix Released Status in libreoffice-l10n source package in Disco: Fix Released Status in mozc source package in Disco: Fix Released Status in openjdk-8 source package in Disco: Fix Released Status in poppler-data source package in Disco: New Bug description: [Background] Many packages are affected by the requirement to support the new era "Reiwa" (令和） This is the meta bug to track packages that need fixes; which packages have already been SRUd to previous releases, how to prioritize the work needed, and general test cases for verifying that things are working as expected. [Impact] Users who run Ubuntu in Japanese. [Test cases] == Date conversion == On applications that support writing dates in long form, or with symbols to denote era (either in X00.00.00 format or in GG1G5G1G format (G- glyph; X- character): 1) Enable date formatting in each of the above formats that are supported (long form or symbols) 2) Type in '2019/05/01' to be formatted, verify that it shows as "令和1年5月1日" or "R1.05.01" 3) Type in '2019/04/30' to be formatted, verify that it shows as "平成31年4月30日" or "H31.4.30" == Date output == 1) Set date to 2019/05/01 2) Output date; verify that the year it is displayed as "令和元年" 3) Set date to 2019/04/30 4) Output date; verify that the year is diplayed as "平成31年" === Displaying formatted year for Japanese era with glibc === Run: LC_ALL=ja_JP.utf8 date +%EY -d 20190430 # previous era (should still work as before SRUs) or LC_ALL=ja_JP.utf8 date +%EY -d 20190501 # new era (should now correctly display the new era) == Character maps / font support == 1) Search for character "SQUARE ERA NAME" 2) Verify that the results include at least "SQUARE ERA NAME HEISEI" and "SQUARE ERA NAME REIWA" (there should also be Syouwa, Taisyou and Meizi), and that the glyphs are readable: - SQUARE ERA NAME HEISEI: ㍻ - SQUARE ERA NAME REIWA: 令和 (in a single glyph) Display of the Reiwa square glyph is font-specific; it may show simply as a empty square or a square with hex characters. If that is the case, the unicode data supports the new character, but the selected font does not include the new glyph. == Typing / input methods == 1) Type in 'heisei' 2) Verify that the input method in use gives you an option "平成", and optionally also the square era glyph. 3) Type in 'reiwa' 4) Verify that the input method in use gives you an option that includes "令和", and possibly also the square era glyph (if supported for Heisei) 5) Type in the following strings, and verify that the options are provided in the input method: * "れいわ"(reiwa) => "令和" * "れいわ"(reiwa) => "㋿" * "２０１８ねん"(2018nenn) => "平成三十年" * "２０１９ねん"(2019nenn) => "平成三十一年" * "２０１９ねん"(2019nenn) => "令和元年" * "２０２０ねん"(2020nenn) => "令和二年" /!\ Some fonts, like fonts-noto-cjk, currently have no glyph for U+32FF. [Regression potential] This is a potentially large change as it impacts font display, character sets as well as date conversions. As such, extreme care should be taken to ensure that
[Touch-packages] [Bug 1838322] Re: Support Japanese new era "令和 (Reiwa)"
There are mentions of Reiwa in icu in eoan. I'm not sure if this is a complete fix, since the code appears to have changed somewhat from the version of icu in Bionic and Disco. Bionic certainly looks unfixed. Disco doesn't incldue the mentions of "reiwa" that are present in the eoan code base. ** Also affects: icu (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: icu (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: icu (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to icu in Ubuntu. https://bugs.launchpad.net/bugs/1838322 Title: Support Japanese new era "令和 (Reiwa)" Status in icu package in Ubuntu: Fix Released Status in icu source package in Bionic: New Status in icu source package in Disco: New Bug description: [Background] Many packages are affected by the requirement to support the new era "Reiwa" (令和） This is the meta bug to track packages that need fixes; which packages have already been SRUd to previous releases, how to prioritize the work needed, and general test cases for verifying that things are working as expected. [Impact] Users who run Ubuntu in Japanese. [Test cases] Unicode data embedded into icu should include REIWA like it includes HEISEI. == Date conversion == On applications that support writing dates in long form, or with symbols to denote era (either in X00.00.00 format or in GG1G5G1G format (G- glyph; X- character): 1) Enable date formatting in each of the above formats that are supported (long form or symbols) 2) Type in '2019/05/01' to be formatted, verify that it shows as "令和1年5月1日" or "R1.05.01" 3) Type in '2019/04/30' to be formatted, verify that it shows as "平成31年4月30日" or "H31.4.30" == Character maps / font support == 1) Search for character "SQUARE ERA NAME" 2) Verify that the results include at least "SQUARE ERA NAME HEISEI" and "SQUARE ERA NAME REIWA" (there should also be Syouwa, Taisyou and Meizi), and that the glyphs are readable: - SQUARE ERA NAME HEISEI: ㍻ - SQUARE ERA NAME REIWA: 令和 (in a single glyph) Display of the Reiwa square glyph is font-specific; it may show simply as a empty square or a square with hex characters. If that is the case, the unicode data supports the new character, but the selected font does not include the new glyph. [Regression potential] This is a potentially large change as it impacts font display, character sets as well as date conversions. As such, extreme care should be taken to ensure that regressions are avoided, such that dates previous to May 1, 2019 continue to display as before, and dates onward are displayed with the new era symbols. The included test cases account for verifying the continued behavior or previous dates. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/icu/+bug/1838322/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1838322] [NEW] Support Japanese new era "令和 (Reiwa)"
Public bug reported: [Background] Many packages are affected by the requirement to support the new era "Reiwa" (令和） This is the meta bug to track packages that need fixes; which packages have already been SRUd to previous releases, how to prioritize the work needed, and general test cases for verifying that things are working as expected. [Impact] Users who run Ubuntu in Japanese. [Test cases] Unicode data embedded into icu should include REIWA like it includes HEISEI. == Date conversion == On applications that support writing dates in long form, or with symbols to denote era (either in X00.00.00 format or in GG1G5G1G format (G- glyph; X- character): 1) Enable date formatting in each of the above formats that are supported (long form or symbols) 2) Type in '2019/05/01' to be formatted, verify that it shows as "令和1年5月1日" or "R1.05.01" 3) Type in '2019/04/30' to be formatted, verify that it shows as "平成31年4月30日" or "H31.4.30" == Character maps / font support == 1) Search for character "SQUARE ERA NAME" 2) Verify that the results include at least "SQUARE ERA NAME HEISEI" and "SQUARE ERA NAME REIWA" (there should also be Syouwa, Taisyou and Meizi), and that the glyphs are readable: - SQUARE ERA NAME HEISEI: ㍻ - SQUARE ERA NAME REIWA: 令和 (in a single glyph) Display of the Reiwa square glyph is font-specific; it may show simply as a empty square or a square with hex characters. If that is the case, the unicode data supports the new character, but the selected font does not include the new glyph. [Regression potential] This is a potentially large change as it impacts font display, character sets as well as date conversions. As such, extreme care should be taken to ensure that regressions are avoided, such that dates previous to May 1, 2019 continue to display as before, and dates onward are displayed with the new era symbols. The included test cases account for verifying the continued behavior or previous dates. ** Affects: icu (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: icu (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: icu (Ubuntu Disco) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to icu in Ubuntu. https://bugs.launchpad.net/bugs/1838322 Title: Support Japanese new era "令和 (Reiwa)" Status in icu package in Ubuntu: Fix Released Status in icu source package in Bionic: New Status in icu source package in Disco: New Bug description: [Background] Many packages are affected by the requirement to support the new era "Reiwa" (令和） This is the meta bug to track packages that need fixes; which packages have already been SRUd to previous releases, how to prioritize the work needed, and general test cases for verifying that things are working as expected. [Impact] Users who run Ubuntu in Japanese. [Test cases] Unicode data embedded into icu should include REIWA like it includes HEISEI. == Date conversion == On applications that support writing dates in long form, or with symbols to denote era (either in X00.00.00 format or in GG1G5G1G format (G- glyph; X- character): 1) Enable date formatting in each of the above formats that are supported (long form or symbols) 2) Type in '2019/05/01' to be formatted, verify that it shows as "令和1年5月1日" or "R1.05.01" 3) Type in '2019/04/30' to be formatted, verify that it shows as "平成31年4月30日" or "H31.4.30" == Character maps / font support == 1) Search for character "SQUARE ERA NAME" 2) Verify that the results include at least "SQUARE ERA NAME HEISEI" and "SQUARE ERA NAME REIWA" (there should also be Syouwa, Taisyou and Meizi), and that the glyphs are readable: - SQUARE ERA NAME HEISEI: ㍻ - SQUARE ERA NAME REIWA: 令和 (in a single glyph) Display of the Reiwa square glyph is font-specific; it may show simply as a empty square or a square with hex characters. If that is the case, the unicode data supports the new character, but the selected font does not include the new glyph. [Regression potential] This is a potentially large change as it impacts font display, character sets as well as date conversions. As such, extreme care should be taken to ensure that regressions are avoided, such that dates previous to May 1, 2019 continue to display as before, and dates onward are displayed with the new era symbols. The included test cases account for verifying the continued behavior or previous dates. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/icu/+bug/1838322/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1828884] Re: [META] Handling Japanese new era "令和 (Reiwa)"
gucharmap split up into bug 1838321 ** No longer affects: gucharmap (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to icu in Ubuntu. https://bugs.launchpad.net/bugs/1828884 Title: [META] Handling Japanese new era "令和 (Reiwa)" Status in Poppler: New Status in fonts-noto-cjk package in Ubuntu: Fix Released Status in icu package in Ubuntu: New Status in libreoffice package in Ubuntu: Fix Released Status in libreoffice-l10n package in Ubuntu: Fix Released Status in mozc package in Ubuntu: Fix Released Status in openjdk-8 package in Ubuntu: Fix Released Status in poppler-data package in Ubuntu: New Status in unicode-data package in Ubuntu: Fix Released Status in gnome-characters source package in Xenial: New Status in gucharmap source package in Xenial: New Status in icu source package in Xenial: New Status in libreoffice source package in Xenial: Fix Released Status in libreoffice-l10n source package in Xenial: Fix Released Status in mozc source package in Xenial: Fix Released Status in openjdk-8 source package in Xenial: New Status in poppler-data source package in Xenial: New Status in unicode-data source package in Xenial: New Status in fonts-noto-cjk source package in Bionic: Fix Released Status in gucharmap source package in Bionic: New Status in icu source package in Bionic: New Status in libreoffice source package in Bionic: Fix Released Status in libreoffice-l10n source package in Bionic: Fix Released Status in mozc source package in Bionic: Fix Released Status in openjdk-8 source package in Bionic: New Status in poppler-data source package in Bionic: New Status in unicode-data source package in Bionic: New Status in libreoffice source package in Cosmic: Fix Released Status in libreoffice-l10n source package in Cosmic: Fix Released Status in mozc source package in Cosmic: Fix Released Status in fonts-noto-cjk source package in Disco: Fix Released Status in gnome-characters source package in Disco: New Status in gucharmap source package in Disco: New Status in icu source package in Disco: New Status in libreoffice source package in Disco: Fix Released Status in libreoffice-l10n source package in Disco: Fix Released Status in mozc source package in Disco: Fix Released Status in openjdk-8 source package in Disco: New Status in poppler-data source package in Disco: New Status in unicode-data source package in Disco: New Bug description: [Background] Many packages are affected by the requirement to support the new era "Reiwa" (令和） This is the meta bug to track packages that need fixes; which packages have already been SRUd to previous releases, how to prioritize the work needed, and general test cases for verifying that things are working as expected. [Impact] Users who run Ubuntu in Japanese. [Test cases] == Date conversion == On applications that support writing dates in long form, or with symbols to denote era (either in X00.00.00 format or in GG1G5G1G format (G- glyph; X- character): 1) Enable date formatting in each of the above formats that are supported (long form or symbols) 2) Type in '2019/05/01' to be formatted, verify that it shows as "令和1年5月1日" or "R1.05.01" 3) Type in '2019/04/30' to be formatted, verify that it shows as "平成31年4月30日" or "H31.4.30" == Date output == 1) Set date to 2019/05/01 2) Output date; verify that the year it is displayed as "令和元年" 3) Set date to 2019/04/30 4) Output date; verify that the year is diplayed as "平成31年" === Displaying formatted year for Japanese era with glibc === Run: LC_ALL=ja_JP.utf8 date +%EY -d 20190430 # previous era (should still work as before SRUs) or LC_ALL=ja_JP.utf8 date +%EY -d 20190501 # new era (should now correctly display the new era) == Character maps / font support == 1) Search for character "SQUARE ERA NAME" 2) Verify that the results include at least "SQUARE ERA NAME HEISEI" and "SQUARE ERA NAME REIWA" (there should also be Syouwa, Taisyou and Meizi), and that the glyphs are readable: - SQUARE ERA NAME HEISEI: ㍻ - SQUARE ERA NAME REIWA: 令和 (in a single glyph) Display of the Reiwa square glyph is font-specific; it may show simply as a empty square or a square with hex characters. If that is the case, the unicode data supports the new character, but the selected font does not include the new glyph. == Typing / input methods == 1) Type in 'heisei' 2) Verify that the input method in use gives you an option "平成", and optionally also the square era glyph. 3) Type in 'reiwa' 4) Verify that the input method in use gives you an option that includes "令和", and possibly also the square era glyph (if supported for Heisei) 5) Type in the following strings, and verify that the options are provided in the input method: * "れいわ"(reiwa) => "令和" * "れいわ"(reiwa) =>
[Touch-packages] [Bug 1791820] Re: /usr/share/apport/apport-gtk:http.client.IncompleteRead:/usr/share/apport/apport-gtk@597:run_argv:run_crashes:run_crash:collect_info:exc_raise:run:search_bug_pattern
** Tags removed: rls-cc-incoming ** Tags added: rls-cc-notfixing -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1791820 Title: /usr/share/apport/apport- gtk:http.client.IncompleteRead:/usr/share/apport/apport- gtk@597:run_argv:run_crashes:run_crash:collect_info:exc_raise:run:search_bug_patterns:read:_safe_read Status in apport package in Ubuntu: Triaged Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding apport. This problem was most recently seen with package version 2.20.9-0ubuntu7.3, the problem page at https://errors.ubuntu.com/problem/9178257a55266131973fa3bc7462837640f82d44 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1791820/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1823651] Re: vim ftbfs in cosmic (i386 only)
** Changed in: vim (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to vim in Ubuntu. https://bugs.launchpad.net/bugs/1823651 Title: vim ftbfs in cosmic (i386 only) Status in vim package in Ubuntu: Invalid Bug description: https://launchpadlibrarian.net/418305601/buildlog_ubuntu- cosmic-i386.vim_2%3A8.0.1766-1ubuntu1_BUILDING.txt.gz Executed 354 tests From test_terminal.vim: Found errors in Test_terminal_tmap(): First run: Caught exception in Test_terminal_tmap(): WaitFor() timed out after 5000 msec @ function RunTheTest[38]..Test_terminal_tmap[1]..TerminalTmap[14]..WaitFor, line 25 Second run: Caught exception in Test_terminal_tmap(): WaitFor() timed out after 5000 msec @ function RunTheTest[38]..Test_terminal_tmap[1]..TerminalTmap[14]..WaitFor, line 25 Test results: From test_terminal.vim: Found errors in Test_terminal_tmap(): First run: Caught exception in Test_terminal_tmap(): WaitFor() timed out after 5000 msec @ function RunTheTest[38]..Test_terminal_tmap[1]..TerminalTmap[14]..WaitFor, line 25 Second run: Caught exception in Test_terminal_tmap(): WaitFor() timed out after 5000 msec @ function RunTheTest[38]..Test_terminal_tmap[1]..TerminalTmap[14]..WaitFor, line 25 TEST FAILURE make[2]: *** [Makefile:43: report] Error 1 make[2]: Leaving directory '/<>/src/vim-gtk3/testdir' make[1]: *** [Makefile:2075: scripttests] Error 2 make[1]: Leaving directory '/<>/src/vim-gtk3' make: *** [debian/rules:266: build-stamp-vim-gtk3] Error 2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1823651/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832882] Re: libcurl-gnutls segfaults spotify client
** Tags removed: rls-dd-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/1832882 Title: libcurl-gnutls segfaults spotify client Status in curl package in Ubuntu: Confirmed Status in curl source package in Disco: Confirmed Bug description: The latest release of Spotify client segfaults in libcurl-gnutls as can be read in this thread on spotify support forum: https://community.spotify.com/t5/Desktop-Linux/Ubuntu-19-04-deb-package-segfault/td-p/4761479 According to one participant the work-around is to install debian packages libgnutls30_3.6.8-1_amd64.deb and libcurl3-gnutls_7.64.0-3_amd64.deb Ubuntu 19.04 version of the packages: libgnutls30 3.6.5-2ubuntu1.1 libcurl3-gnutls 7.64.0-2ubuntu1.1 As the bug can be resolved by installing debian packages, I assume Ubuntu's version of the packages is at fault and should be upgraded to match debian's level as soon as possible. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1832882/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1828884] Re: [META] Handling Japanese new era "令和 (Reiwa)"
Looks like noto sources now have the right glyphs (since their April 9 release, actually). It will need an update both in Debian and Ubuntu. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to icu in Ubuntu. https://bugs.launchpad.net/bugs/1828884 Title: [META] Handling Japanese new era "令和 (Reiwa)" Status in Poppler: New Status in fonts-noto-cjk package in Ubuntu: New Status in gucharmap package in Ubuntu: New Status in icu package in Ubuntu: New Status in libreoffice package in Ubuntu: Fix Released Status in libreoffice-l10n package in Ubuntu: Fix Released Status in mozc package in Ubuntu: Fix Released Status in openjdk-8 package in Ubuntu: Fix Released Status in poppler-data package in Ubuntu: New Status in unicode-data package in Ubuntu: Fix Released Status in gnome-characters source package in Xenial: New Status in gucharmap source package in Xenial: New Status in icu source package in Xenial: New Status in libreoffice source package in Xenial: Fix Released Status in libreoffice-l10n source package in Xenial: Fix Released Status in mozc source package in Xenial: Fix Released Status in openjdk-8 source package in Xenial: New Status in poppler-data source package in Xenial: New Status in unicode-data source package in Xenial: New Status in fonts-noto-cjk source package in Bionic: New Status in gucharmap source package in Bionic: New Status in icu source package in Bionic: New Status in libreoffice source package in Bionic: Fix Released Status in libreoffice-l10n source package in Bionic: Fix Released Status in mozc source package in Bionic: Fix Released Status in openjdk-8 source package in Bionic: New Status in poppler-data source package in Bionic: New Status in unicode-data source package in Bionic: New Status in fonts-noto-cjk source package in Cosmic: New Status in gnome-characters source package in Cosmic: New Status in gucharmap source package in Cosmic: New Status in icu source package in Cosmic: New Status in libreoffice source package in Cosmic: Fix Released Status in libreoffice-l10n source package in Cosmic: Fix Released Status in mozc source package in Cosmic: Fix Released Status in openjdk-8 source package in Cosmic: New Status in poppler-data source package in Cosmic: New Status in unicode-data source package in Cosmic: New Status in fonts-noto-cjk source package in Disco: New Status in gnome-characters source package in Disco: New Status in gucharmap source package in Disco: New Status in icu source package in Disco: New Status in libreoffice source package in Disco: Fix Released Status in libreoffice-l10n source package in Disco: Fix Released Status in mozc source package in Disco: Fix Released Status in openjdk-8 source package in Disco: New Status in poppler-data source package in Disco: New Status in unicode-data source package in Disco: New Bug description: [Background] Many packages are affected by the requirement to support the new era "Reiwa" (令和） This is the meta bug to track packages that need fixes; which packages have already been SRUd to previous releases, how to prioritize the work needed, and general test cases for verifying that things are working as expected. [Impact] Users who run Ubuntu in Japanese. [Test cases] == Date conversion == On applications that support writing dates in long form, or with symbols to denote era (either in X00.00.00 format or in GG1G5G1G format (G- glyph; X- character): 1) Enable date formatting in each of the above formats that are supported (long form or symbols) 2) Type in '2019/05/01' to be formatted, verify that it shows as "令和1年5月1日" or "R1.05.01" 3) Type in '2019/04/30' to be formatted, verify that it shows as "平成31年4月30日" or "H31.4.30" == Date output == 1) Set date to 2019/05/01 2) Output date; verify that the year it is displayed as "令和元年" 3) Set date to 2019/04/30 4) Output date; verify that the year is diplayed as "平成31年" === Displaying formatted year for Japanese era with glibc === Run: LC_ALL=ja_JP.utf8 date +%EY -d 20190430 # previous era (should still work as before SRUs) or LC_ALL=ja_JP.utf8 date +%EY -d 20190501 # new era (should now correctly display the new era) == Character maps / font support == 1) Search for character "SQUARE ERA NAME" 2) Verify that the results include at least "SQUARE ERA NAME HEISEI" and "SQUARE ERA NAME REIWA" (there should also be Syouwa, Taisyou and Meizi), and that the glyphs are readable: - SQUARE ERA NAME HEISEI: ㍻ - SQUARE ERA NAME REIWA: 令和 (in a single glyph) Display of the Reiwa square glyph is font-specific; it may show simply as a empty square or a square with hex characters. If that is the case, the unicode data supports the new character, but the selected font does not include the new glyph. == Typing / input methods ==
[Touch-packages] [Bug 1781746] Re: [SRU] Slow startup with zram-config installed (/dev/zram0) or encrypted swap
** Also affects: initramfs-tools (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: initramfs-tools (Ubuntu) Status: Confirmed => Fix Released ** Changed in: initramfs-tools (Ubuntu Bionic) Status: New => Triaged ** Tags removed: rls-ee-incoming ** Tags added: rls-bb-notfixing -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1781746 Title: [SRU] Slow startup with zram-config installed (/dev/zram0) or encrypted swap Status in Default settings and artwork for Baltix OS: Confirmed Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Bionic: Triaged Status in initramfs-tools package in Debian: Fix Released Bug description: [Impact] Ubuntu 18.04 startup slowdowns for 30-120 seconds when zram swap is enabled (for example zram-config installed) or swap is encrypted. Today lots of users have SSD instead of HDD disk drives and use zram swap instead of swap partition or swap file, but if initrd is generated when zram swap is enabled then system can become "unbootable" from the user's perspective (Users with SSD storage doesn't wait 2 or more minutes...) This bug is already fixed in Debian initramfs-tools ver 0.132, please accept this simple 3 lines patch from Debian into Ubuntu 18.04 LTS https://salsa.debian.org/kernel-team/initramfs-tools/commit/312393b0cf1231125eeff3d1a2b6b778a935c21d [Test Case] Install zram-config package and regenerate and initrd, for example with sudo update-initramfs -u When generating initrd I get this message in terminal: I: The initramfs will attempt to resume from /dev/zram0 I: (UUID=e380356c-767e-4265-98da-8be62ad28569) I: Set the RESUME variable to override this.###.] So the local-premount script in initramfs was waiting for a swap device that was not available, until it timed out. The relevant message was gave up waiting for suspend/resume device. [Regression Potential] None, patch simply adds case for /dev/zram*: 60case "$resume_auto" in 61/dev/zram*) 62ephemeral=true 63;; 64esac [Other Info] Manual method to disable this (as resuming from swap is not possible with an encrypted or zram swap): modify file /etc/initramfs-tools/conf.d/resume - add (or change) line RESUME=none (instead of the UUID that was here) will disable waiting for a resume device. and run sudo update-initramfs -u to apply the changes. To manage notifications about this bug go to: https://bugs.launchpad.net/baltix-default-settings/+bug/1781746/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1798369] Re: Reinstall Ubuntu (with preserving existing data) shows error message due to "Could not get lock /target/var/cache/apt/archives/lock"
** Tags removed: rls-ee-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1798369 Title: Reinstall Ubuntu (with preserving existing data) shows error message due to "Could not get lock /target/var/cache/apt/archives/lock" Status in APT: New Status in ubiquity: New Status in apt package in Ubuntu: Invalid Status in ubiquity package in Ubuntu: Confirmed Status in apt source package in Eoan: Invalid Status in ubiquity source package in Eoan: Confirmed Bug description: When trying to reinstall an existing Ubuntu cosmic installation using latest 18.10 desktop images, the install shows an error dialog around the end of the installation with an "Error restoring installed applications". Looking at the syslog such a traceback can be seen: apt_pkg.Error: E:Could not get lock /target/var/cache/apt/archives/lock - open (11: Resource temporarily unavailable), E:Unable to lock directory /target/var/cache/apt/archives/ After reproducing this on a live session, after chrooting into /target indeed any apt-get install operations result in the same lock-file error. The whole syslog of the reinstall attached to the bug. Test case: * Download latest cosmic image * Install cosmic on the whole disk (can be on a VM) * (optional) Boot into the system and leave a file in the home directory (to leave a trace, just in case) * Reboot and install cosmic using the first option in ubiquity: Reinstall Ubuntu * Finish configuration The install itself doesn't fail, but around the end of the installation process the error dialog appears. System is still bootable but left with old packages. To manage notifications about this bug go to: https://bugs.launchpad.net/apt/+bug/1798369/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1756595] Re: disk space info inadvertently provides all installed snaps
** Tags removed: rls-dd-incoming ** Tags added: rls-ee-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1756595 Title: disk space info inadvertently provides all installed snaps Status in apport package in Ubuntu: Invalid Status in apt package in Ubuntu: Triaged Status in apport source package in Bionic: Invalid Status in apt source package in Bionic: Triaged Bug description: When apport is reporting a crash, it includes the output of the "df" utility, to list the free disk space information per mount point. That output nowadays will inadvertently include all snaps that the user may have installed, including their revision numbers. Here is a simple df output: andreas@nsn7:~$ df Filesystem 1K-blocksUsed Available Use% Mounted on udev 8119680 0 8119680 0% /dev tmpfs 16301561828 1628328 1% /run nsn7/ROOT/ubuntu433084288 2500608 430583680 1% / tmpfs 8150776 1 8131888 1% /dev/shm tmpfs5120 4 5116 1% /run/lock tmpfs 8150776 0 8150776 0% /sys/fs/cgroup nsn7/var/log430763136 179456 430583680 1% /var/log nsn7/var/tmp430583808 128 430583680 1% /var/tmp /dev/sda2 1032088 160336871752 16% /boot /dev/sda1 5232482720520528 1% /boot/efi nsn7/home 430651264 67584 430583680 1% /home nsn7/var/cache 430653312 69632 430583680 1% /var/cache nsn7/var/mail 430583808 128 430583680 1% /var/mail nsn7/var/spool 430583808 128 430583680 1% /var/spool tmpfs 1630152 16 1630136 1% /run/user/120 tmpfs 100 0 100 0% /var/lib/lxd/shmounts tmpfs 100 0 100 0% /var/lib/lxd/devlxd tmpfs 1630152 36 1630116 1% /run/user/1000 nsn7/lxd/containers/squid-ds216 431444096 860416 430583680 1% /var/lib/lxd/storage-pools/default/containers/squid-ds216 /dev/loop0 83712 83712 0 100% /snap/core/4206 /dev/loop1 102144 102144 0 100% /snap/git-ubuntu/402 You can see I have the core snap at revision 4206, and git-ubuntu at revision 402. There are already many bug reports in launchpad where one can see this information. Granted, the user can review it, refuse to send this data, etc. This bug is about the unexpectedness of having that information in the disk space data. If the user sees a prompt like "Would you like to include disk free space information in your report?", or "Would you like to include the output of the df(1) command in your report?", that doesn't immediately translate to "Would you like to include disk free space information and a list of all installed snaps and their revision numbers in your report?". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1756595/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1826459] Re: systemd-networkd not installing GatewayOnlink=true
Closing as Invalid for netplan: the config generated is exactly as it should for the netplan YAML that was provided. This isn't a bug in netplan. ** Changed in: netplan Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1826459 Title: systemd-networkd not installing GatewayOnlink=true Status in netplan: Invalid Status in systemd package in Ubuntu: Incomplete Bug description: root@search-3 /run/systemd/network # for i in *; do echo $i; echo; cat $i; done ; sudo service systemd-networkd stop; SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd 10-netplan-enp0s31f6.network [Match] Name=enp0s31f6 [Network] LinkLocalAddressing=ipv6 Address=95.216.96.148/26 Gateway=95.216.96.129 DNS=8.8.8.8 DNS=1.1.1.1 Domains=148.96.216.95.clients.your-server.de VLAN=vlan4000 [Route] Destination=95.216.96.148/26 Gateway=95.216.96.129 GatewayOnlink=true 10-netplan-vlan4000.netdev [NetDev] Name=vlan4000 MTUBytes=1400 Kind=vlan [VLAN] Id=4000 10-netplan-vlan4000.network [Match] Name=vlan4000 [Network] LinkLocalAddressing=ipv6 Address=10.0.2.3/24 ConfigureWithoutCarrier=yes Failed to read $container of PID 1, ignoring: Permission denied Found container virtualization none. Bus n/a: changing state UNSET → OPENING Bus n/a: changing state OPENING → AUTHENTICATING Failed to open configuration file '/etc/systemd/networkd.conf': No such file or directory timestamp of '/etc/systemd/network' changed timestamp of '/run/systemd/network' changed Ignoring /run/systemd/network/10-netplan-enp0s31f6.network, because it's not a regular file with suffix .netdev. Ignoring /run/systemd/network/10-netplan-vlan4000.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-vz.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-ve.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-host0.network, because it's not a regular file with suffix .netdev. vlan4000: loaded vlan Ignoring /run/systemd/network/10-netplan-vlan4000.netdev, because it's not a regular file with suffix .network. Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .network. tun0: MAC address not found for new device, continuing without tun0: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +POINTOPOINT +NOARP tun0: Link 12 added tun0: udev initialized link tun0: Saved original MTU: 1500 veth20a5a67: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST veth20a5a67: Link 8 added veth20a5a67: udev initialized link veth20a5a67: Saved original MTU: 1500 vlan4000: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST vlan4000: Link 6 added vlan4000: udev initialized link vlan4000: netdev has index 6 vlan4000: Saved original MTU: 1400 br-c7cc901345e8: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST br-c7cc901345e8: Link 5 added br-c7cc901345e8: udev initialized link br-c7cc901345e8: Saved original MTU: 1500 docker0: Flags change: +UP +MULTICAST +BROADCAST docker0: Link 3 added docker0: udev initialized link docker0: Saved original MTU: 1500 enp0s31f6: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST enp0s31f6: Link 2 added enp0s31f6: udev initialized link enp0s31f6: Saved original MTU: 1500 lo: Flags change: +LOOPBACK +UP +LOWER_UP +RUNNING lo: Link 1 added lo: udev initialized link lo: Saved original MTU: 0 vlan4000: Adding address: fe80::921b:eff:fe93:5015/64 (valid forever) vlan4000: Gained IPv6LL tun0: Adding address: 10.0.0.13/24 (valid forever) vlan4000: Adding address: 10.0.2.3/24 (valid forever) br-c7cc901345e8: Adding address: 172.18.0.1/16 (valid forever) docker0: Adding address: 172.17.0.1/16 (valid forever) enp0s31f6: Adding address: 95.216.96.148/26 (valid forever) lo: Adding address: 127.0.0.1/8 (valid forever) rtnl: received address with invalid family 129, ignoring Enumeration completed Bus n/a: changing state AUTHENTICATING → HELLO Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=RequestName cookie=2 reply_cookie=0 signature=su error-name=n/a error-message=n/a Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus
[Touch-packages] [Bug 1826459] Re: systemd-networkd not installing GatewayOnlink=true
>From what I can tell, the routing is exactly how it should be: [from the bug description] root@search-3 /run/systemd/network # ip route default via 95.216.96.129 dev enp0s31f6 proto static 10.0.0.0/24 dev tun0 proto kernel scope link src 10.0.0.13 10.0.2.0/24 dev vlan4000 proto kernel scope link src 10.0.2.3 95.216.96.128/26 dev enp0s31f6 proto kernel scope link src 95.216.96.148 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 172.18.0.0/16 dev br-c7cc901345e8 proto kernel scope link src 172.18.0.1 """ its missing to add 95.216.96.128/26 via 95.216.96.129 dev enp0s31f6 """ It's actually not missing a route -- the IP is defined as being 95.216.96.148/26; which means that it's on the same subnet as 95.216.96.129 (your gateway) already (/26 for this address is from 95.216.96.128 (the network address) to 95.216.96.191. The additional route is simply superfluous, it should not be required. networkd or the kernel may be ignoring them since the routes are already existing. Could you please tell us more about what you are trying to achieve? Are you trying to ping something that isn't responding the way you expect? Is some system not reachable? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1826459 Title: systemd-networkd not installing GatewayOnlink=true Status in netplan: Invalid Status in systemd package in Ubuntu: Incomplete Bug description: root@search-3 /run/systemd/network # for i in *; do echo $i; echo; cat $i; done ; sudo service systemd-networkd stop; SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd 10-netplan-enp0s31f6.network [Match] Name=enp0s31f6 [Network] LinkLocalAddressing=ipv6 Address=95.216.96.148/26 Gateway=95.216.96.129 DNS=8.8.8.8 DNS=1.1.1.1 Domains=148.96.216.95.clients.your-server.de VLAN=vlan4000 [Route] Destination=95.216.96.148/26 Gateway=95.216.96.129 GatewayOnlink=true 10-netplan-vlan4000.netdev [NetDev] Name=vlan4000 MTUBytes=1400 Kind=vlan [VLAN] Id=4000 10-netplan-vlan4000.network [Match] Name=vlan4000 [Network] LinkLocalAddressing=ipv6 Address=10.0.2.3/24 ConfigureWithoutCarrier=yes Failed to read $container of PID 1, ignoring: Permission denied Found container virtualization none. Bus n/a: changing state UNSET → OPENING Bus n/a: changing state OPENING → AUTHENTICATING Failed to open configuration file '/etc/systemd/networkd.conf': No such file or directory timestamp of '/etc/systemd/network' changed timestamp of '/run/systemd/network' changed Ignoring /run/systemd/network/10-netplan-enp0s31f6.network, because it's not a regular file with suffix .netdev. Ignoring /run/systemd/network/10-netplan-vlan4000.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-vz.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-ve.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-host0.network, because it's not a regular file with suffix .netdev. vlan4000: loaded vlan Ignoring /run/systemd/network/10-netplan-vlan4000.netdev, because it's not a regular file with suffix .network. Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .network. tun0: MAC address not found for new device, continuing without tun0: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +POINTOPOINT +NOARP tun0: Link 12 added tun0: udev initialized link tun0: Saved original MTU: 1500 veth20a5a67: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST veth20a5a67: Link 8 added veth20a5a67: udev initialized link veth20a5a67: Saved original MTU: 1500 vlan4000: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST vlan4000: Link 6 added vlan4000: udev initialized link vlan4000: netdev has index 6 vlan4000: Saved original MTU: 1400 br-c7cc901345e8: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST br-c7cc901345e8: Link 5 added br-c7cc901345e8: udev initialized link br-c7cc901345e8: Saved original MTU: 1500 docker0: Flags change: +UP +MULTICAST +BROADCAST docker0: Link 3 added docker0: udev initialized link docker0: Saved original MTU: 1500 enp0s31f6: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST enp0s31f6: Link 2 added enp0s31f6: udev initialized link enp0s31f6: Saved original MTU: 1500 lo: Flags change: +LOOPBACK +UP +LOWER_UP +RUNNING lo: Link 1 added lo: udev initialized link lo: Saved original MTU: 0 vlan4000: Adding address: fe80::921b:eff:fe93:5015/64 (valid forever) vlan4000: Gained IPv6LL tun0: Adding address: 10.0.0.13/24 (valid forever) vlan4000: Adding
[Touch-packages] [Bug 1543799] Re: isc-dhcp-server & isc-dhcp-server6 systemd service units use the same RuntimeDirectory leading to loss of pid files
After consideration, we're not going to prioritize fixing this for the EE release (in other words, the Canonical Foundations time isn't going to be actively working on fixing this). It doesn't mean the bug won't be fixed, just that there is no company work assigned to the bug. For now, there's a patch attached, it looks pretty good to me; but I think it would be best to have that added to Debian first (so it lands in both Debian and Ubuntu). Please see https://wiki.ubuntu.com/Debian/Bugs for more info on how you can submit the patch to Debian (it would be nice if you could do it, that way you would get credited for it too). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1543799 Title: isc-dhcp-server & isc-dhcp-server6 systemd service units use the same RuntimeDirectory leading to loss of pid files Status in isc-dhcp package in Ubuntu: Triaged Status in isc-dhcp source package in Xenial: Triaged Status in isc-dhcp source package in Bionic: Triaged Status in isc-dhcp source package in Cosmic: Triaged Status in isc-dhcp source package in Disco: Triaged Bug description: dhcpd reports 'Can't create PID file /run/dhcp-server/dhcpd.pid' (or '/run/dhcp-server/dhcpd6.pid' for isc-dhcp-server6), and no file is found /run/dhcp-server. Additionally, both isc-dhcp-server & isc-dhcp-server6 service unit files specify the RuntimeDirectory 'dhcp-server', which is removed when either unit stops (and thus would wipe out the other unit's pid file, were it being successfully written). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: isc-dhcp-server 4.3.3-5ubuntu4 ProcVersionSignature: Ubuntu 4.4.0-2.16-generic 4.4.0 Uname: Linux 4.4.0-2-generic x86_64 ApportVersion: 2.19.4-0ubuntu2 Architecture: amd64 Date: Tue Feb 9 21:34:08 2016 InstallationDate: Installed on 2016-02-09 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160206) ProcEnviron: LANGUAGE=en_GB:en TERM=linux PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: isc-dhcp UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.dhcp.dhcpd.conf: [modified] mtime.conffile..etc.dhcp.dhcpd.conf: 2016-02-09T21:11:20.104056 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1543799/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1543799] Re: isc-dhcp-server & isc-dhcp-server6 systemd service units use the same RuntimeDirectory leading to loss of pid files
** Tags removed: rls-ee-tracking ** Tags added: rls-ee-notfixing -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1543799 Title: isc-dhcp-server & isc-dhcp-server6 systemd service units use the same RuntimeDirectory leading to loss of pid files Status in isc-dhcp package in Ubuntu: Triaged Status in isc-dhcp source package in Xenial: Triaged Status in isc-dhcp source package in Bionic: Triaged Status in isc-dhcp source package in Cosmic: Triaged Status in isc-dhcp source package in Disco: Triaged Bug description: dhcpd reports 'Can't create PID file /run/dhcp-server/dhcpd.pid' (or '/run/dhcp-server/dhcpd6.pid' for isc-dhcp-server6), and no file is found /run/dhcp-server. Additionally, both isc-dhcp-server & isc-dhcp-server6 service unit files specify the RuntimeDirectory 'dhcp-server', which is removed when either unit stops (and thus would wipe out the other unit's pid file, were it being successfully written). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: isc-dhcp-server 4.3.3-5ubuntu4 ProcVersionSignature: Ubuntu 4.4.0-2.16-generic 4.4.0 Uname: Linux 4.4.0-2-generic x86_64 ApportVersion: 2.19.4-0ubuntu2 Architecture: amd64 Date: Tue Feb 9 21:34:08 2016 InstallationDate: Installed on 2016-02-09 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160206) ProcEnviron: LANGUAGE=en_GB:en TERM=linux PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: isc-dhcp UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.dhcp.dhcpd.conf: [modified] mtime.conffile..etc.dhcp.dhcpd.conf: 2016-02-09T21:11:20.104056 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1543799/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1828884] Re: [META] Handling Japanese new era "令和 (Reiwa)"
unicode-data in eoan does include Reiwa. Reverse-depends probably still need to be rebuilt (I'm testing gucharmap which seemed easy enough to patch to work). ** Changed in: unicode-data (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to icu in Ubuntu. https://bugs.launchpad.net/bugs/1828884 Title: [META] Handling Japanese new era "令和 (Reiwa)" Status in fonts-noto-cjk package in Ubuntu: New Status in gnome-characters package in Ubuntu: New Status in gucharmap package in Ubuntu: New Status in icu package in Ubuntu: New Status in libreoffice package in Ubuntu: Fix Released Status in libreoffice-l10n package in Ubuntu: Fix Released Status in mozc package in Ubuntu: Fix Released Status in openjdk-8 package in Ubuntu: Fix Released Status in poppler-data package in Ubuntu: New Status in unicode-data package in Ubuntu: Fix Released Status in fonts-noto-cjk source package in Xenial: New Status in gnome-characters source package in Xenial: New Status in gucharmap source package in Xenial: New Status in icu source package in Xenial: New Status in libreoffice source package in Xenial: New Status in libreoffice-l10n source package in Xenial: New Status in mozc source package in Xenial: Fix Released Status in openjdk-8 source package in Xenial: New Status in poppler-data source package in Xenial: New Status in unicode-data source package in Xenial: New Status in fonts-noto-cjk source package in Bionic: New Status in gnome-characters source package in Bionic: New Status in gucharmap source package in Bionic: New Status in icu source package in Bionic: New Status in libreoffice source package in Bionic: New Status in libreoffice-l10n source package in Bionic: New Status in mozc source package in Bionic: Fix Released Status in openjdk-8 source package in Bionic: New Status in poppler-data source package in Bionic: New Status in unicode-data source package in Bionic: New Status in fonts-noto-cjk source package in Cosmic: New Status in gnome-characters source package in Cosmic: New Status in gucharmap source package in Cosmic: New Status in icu source package in Cosmic: New Status in libreoffice source package in Cosmic: New Status in libreoffice-l10n source package in Cosmic: New Status in mozc source package in Cosmic: Fix Released Status in openjdk-8 source package in Cosmic: New Status in poppler-data source package in Cosmic: New Status in unicode-data source package in Cosmic: New Status in fonts-noto-cjk source package in Disco: New Status in gnome-characters source package in Disco: New Status in gucharmap source package in Disco: New Status in icu source package in Disco: New Status in libreoffice source package in Disco: New Status in libreoffice-l10n source package in Disco: New Status in mozc source package in Disco: Fix Released Status in openjdk-8 source package in Disco: New Status in poppler-data source package in Disco: New Status in unicode-data source package in Disco: New Bug description: [Background] Many packages are affected by the requirement to support the new era "Reiwa" (令和） This is the meta bug to track packages that need fixes; which packages have already been SRUd to previous releases, how to prioritize the work needed, and general test cases for verifying that things are working as expected. [Impact] Users who run Ubuntu in Japanese. [Test cases] == Date conversion == On applications that support writing dates in long form, or with symbols to denote era (either in X00.00.00 format or in GG1G5G1G format (G- glyph; X- character): 1) Enable date formatting in each of the above formats that are supported (long form or symbols) 2) Type in '2019/05/01' to be formatted, verify that it shows as "令和1年5月1日" or "R1.05.01" 3) Type in '2019/04/30' to be formatted, verify that it shows as "平成31年4月30日" or "H31.4.30" == Date output == 1) Set date to 2019/05/01 2) Output date; verify that the year it is displayed as "令和元年" 3) Set date to 2019/04/30 4) Output date; verify that the year is diplayed as "平成31年" === Displaying formatted year for Japanese era with glibc === Run: LC_ALL=ja_JP.utf8 date +%EY -d 20190430 # previous era (should still work as before SRUs) or LC_ALL=ja_JP.utf8 date +%EY -d 20190501 # new era (should now correctly display the new era) == Character maps / font support == 1) Search for character "SQUARE ERA NAME" 2) Verify that the results include at least "SQUARE ERA NAME HEISEI" and "SQUARE ERA NAME REIWA" (there should also be Syouwa, Taisyou and Meizi), and that the glyphs are readable: - SQUARE ERA NAME HEISEI: ㍻ - SQUARE ERA NAME REIWA: 令和 (in a single glyph) Display of the Reiwa square glyph is font-specific; it may show simply as a empty square or a square with hex
[Touch-packages] [Bug 1828884] Re: [META] Handling Japanese new era "令和 (Reiwa)"
mozc appears to be all done (LP: #1823444) ** Changed in: mozc (Ubuntu Xenial) Status: New => Fix Released ** Changed in: mozc (Ubuntu Bionic) Status: New => Fix Released ** Changed in: mozc (Ubuntu Cosmic) Status: New => Fix Released ** Changed in: mozc (Ubuntu Disco) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to icu in Ubuntu. https://bugs.launchpad.net/bugs/1828884 Title: [META] Handling Japanese new era "令和 (Reiwa)" Status in fonts-noto-cjk package in Ubuntu: New Status in gnome-characters package in Ubuntu: New Status in gucharmap package in Ubuntu: New Status in icu package in Ubuntu: New Status in libreoffice package in Ubuntu: Fix Released Status in libreoffice-l10n package in Ubuntu: Fix Released Status in mozc package in Ubuntu: Fix Released Status in openjdk-8 package in Ubuntu: Fix Released Status in poppler-data package in Ubuntu: New Status in unicode-data package in Ubuntu: Fix Released Status in fonts-noto-cjk source package in Xenial: New Status in gnome-characters source package in Xenial: New Status in gucharmap source package in Xenial: New Status in icu source package in Xenial: New Status in libreoffice source package in Xenial: New Status in libreoffice-l10n source package in Xenial: New Status in mozc source package in Xenial: Fix Released Status in openjdk-8 source package in Xenial: New Status in poppler-data source package in Xenial: New Status in unicode-data source package in Xenial: New Status in fonts-noto-cjk source package in Bionic: New Status in gnome-characters source package in Bionic: New Status in gucharmap source package in Bionic: New Status in icu source package in Bionic: New Status in libreoffice source package in Bionic: New Status in libreoffice-l10n source package in Bionic: New Status in mozc source package in Bionic: Fix Released Status in openjdk-8 source package in Bionic: New Status in poppler-data source package in Bionic: New Status in unicode-data source package in Bionic: New Status in fonts-noto-cjk source package in Cosmic: New Status in gnome-characters source package in Cosmic: New Status in gucharmap source package in Cosmic: New Status in icu source package in Cosmic: New Status in libreoffice source package in Cosmic: New Status in libreoffice-l10n source package in Cosmic: New Status in mozc source package in Cosmic: Fix Released Status in openjdk-8 source package in Cosmic: New Status in poppler-data source package in Cosmic: New Status in unicode-data source package in Cosmic: New Status in fonts-noto-cjk source package in Disco: New Status in gnome-characters source package in Disco: New Status in gucharmap source package in Disco: New Status in icu source package in Disco: New Status in libreoffice source package in Disco: New Status in libreoffice-l10n source package in Disco: New Status in mozc source package in Disco: Fix Released Status in openjdk-8 source package in Disco: New Status in poppler-data source package in Disco: New Status in unicode-data source package in Disco: New Bug description: [Background] Many packages are affected by the requirement to support the new era "Reiwa" (令和） This is the meta bug to track packages that need fixes; which packages have already been SRUd to previous releases, how to prioritize the work needed, and general test cases for verifying that things are working as expected. [Impact] Users who run Ubuntu in Japanese. [Test cases] == Date conversion == On applications that support writing dates in long form, or with symbols to denote era (either in X00.00.00 format or in GG1G5G1G format (G- glyph; X- character): 1) Enable date formatting in each of the above formats that are supported (long form or symbols) 2) Type in '2019/05/01' to be formatted, verify that it shows as "令和1年5月1日" or "R1.05.01" 3) Type in '2019/04/30' to be formatted, verify that it shows as "平成31年4月30日" or "H31.4.30" == Date output == 1) Set date to 2019/05/01 2) Output date; verify that the year it is displayed as "令和元年" 3) Set date to 2019/04/30 4) Output date; verify that the year is diplayed as "平成31年" === Displaying formatted year for Japanese era with glibc === Run: LC_ALL=ja_JP.utf8 date +%EY -d 20190430 # previous era (should still work as before SRUs) or LC_ALL=ja_JP.utf8 date +%EY -d 20190501 # new era (should now correctly display the new era) == Character maps / font support == 1) Search for character "SQUARE ERA NAME" 2) Verify that the results include at least "SQUARE ERA NAME HEISEI" and "SQUARE ERA NAME REIWA" (there should also be Syouwa, Taisyou and Meizi), and that the glyphs are readable: - SQUARE ERA NAME HEISEI: ㍻ - SQUARE ERA NAME REIWA: 令和 (in a single glyph) Display of the
[Touch-packages] [Bug 1828884] Re: [META] Handling Japanese new era "令和 (Reiwa)"
Oops; picked the wrong openjdk... FWIW; according to the email by Mitsuya Shibata, openjdk 8 and 11 at least are affected (so, everything prior to disco if updates are not applied. Openjdk-8 updates appear to already be at 8u212, which should include Reiwa support. Marking as Fix Released so we can see at a glance that it's already been covered. ** Also affects: openjdk-13 (Ubuntu) Importance: Undecided Status: New ** Also affects: icu (Ubuntu) Importance: Undecided Status: New ** Also affects: unicode-data (Ubuntu) Importance: Undecided Status: New ** Also affects: poppler-data (Ubuntu) Importance: Undecided Status: New ** Description changed: [Background] Many packages are affected by the requirement to support the new era "Reiwa" (令和） This is the meta bug to track packages that need fixes; which packages have already been SRUd to previous releases, how to prioritize the work needed, and general test cases for verifying that things are working as expected. [Impact] Users who run Ubuntu in Japanese. [Test cases] == Date conversion == On applications that support writing dates in long form, or with symbols to denote era (either in X00.00.00 format or in GG1G5G1G format (G- glyph; X- character): 1) Enable date formatting in each of the above formats that are supported (long form or symbols) 2) Type in '2019/05/01' to be formatted, verify that it shows as "令和1年5月1日" or "R1.05.01" 3) Type in '2019/04/30' to be formatted, verify that it shows as "平成31年4月30日" or "H31.4.30" == Date output == 1) Set date to 2019/05/01 2) Output date; verify that the year it is displayed as "令和元年" 3) Set date to 2019/04/30 4) Output date; verify that the year is diplayed as "平成31年" === Displaying formatted year for Japanese era with glibc === Run: LC_ALL=ja_JP.utf8 date +%EY -d 20190430 # previous era (should still work as before SRUs) or LC_ALL=ja_JP.utf8 date +%EY -d 20190501 # new era (should now correctly display the new era) == Character maps / font support == 1) Search for character "SQUARE ERA NAME" 2) Verify that the results include at least "SQUARE ERA NAME HEISEI" and "SQUARE ERA NAME REIWA" (there should also be Syouwa, Taisyou and Meizi), and that the glyphs are readable: - SQUARE ERA NAME HEISEI: ㍻ - SQUARE ERA NAME REIWA: 令和 (in a single glyph) Display of the Reiwa square glyph is font-specific; it may show simply as a empty square or a square with hex characters. If that is the case, the unicode data supports the new character, but the selected font does not include the new glyph. == Typing / input methods == 1) Type in 'heisei' 2) Verify that the input method in use gives you an option "平成", and optionally also the square era glyph. 3) Type in 'reiwa' 4) Verify that the input method in use gives you an option that includes "令和", and possibly also the square era glyph (if supported for Heisei) 5) Type in the following strings, and verify that the options are provided in the input method: - * "れいわ"(reiwa) => "令和" - * "れいわ"(reiwa) => "㋿" - * "２０１８ねん"(2018nenn) => "平成三十年" - * "２０１８ねん"(2018nenn) => "平成三十年" - * "２０１９ねん"(2019nenn) => "平成三十一年" - * "２０１９ねん"(2019nenn) => "令和元年" - * "２０２０ねん"(2020nenn) => "令和二年" + * "れいわ"(reiwa) => "令和" + * "れいわ"(reiwa) => "㋿" + * "２０１８ねん"(2018nenn) => "平成三十年" + * "２０１９ねん"(2019nenn) => "平成三十一年" + * "２０１９ねん"(2019nenn) => "令和元年" + * "２０２０ねん"(2020nenn) => "令和二年" /!\ Some fonts, like fonts-noto-cjk, currently have no glyph for U+32FF. [Regression potential] This is a potentially large change as it impacts font display, character sets as well as date conversions. As such, extreme care should be taken to ensure that regressions are avoided, such that dates previous to May 1, 2019 continue to display as before, and dates onward are displayed with the new era symbols. The included test cases account for verifying the continued behavior or previous dates. ** No longer affects: openjdk-13 (Ubuntu) ** Also affects: openjdk-8 (Ubuntu) Importance: Undecided Status: New ** Changed in: openjdk-8 (Ubuntu) Status: New => Fix Released ** Also affects: gucharmap (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: icu (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: unicode-data (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: poppler-data (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: mozc (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: libreoffice (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: libreoffice-l10n (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: openjdk-8 (Ubuntu Disco) Importance: Undecided Status: New **
[Touch-packages] [Bug 1767172] Re: Regression: /etc/modules checked against blacklist or it's really hard to load blacklisted watchdog modules when one really wants one
Kees,
I the fix in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766052 sufficient
to address the situation? Do we still need to do more to systemd (note,
the GH issue was closed upstream following Dimitri's input)?
** Changed in: systemd (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1767172
Title:
Regression: /etc/modules checked against blacklist or it's really hard
to load blacklisted watchdog modules when one really wants one
Status in linux package in Ubuntu:
Incomplete
Status in systemd package in Ubuntu:
Incomplete
Bug description:
Impossible / hard to force the system to load a watchdog module
because it is blacklisted by the kernel auto-generated list of
"watchdog" modules.
/etc/modules used to "just work" before.
e.g. bcm2835_wdt module on arm64
===
Before systemd-modules-load, /etc/init.d/kmod would load modules
directly with "modprobe" (and _not_ "modprobe -b"):
load_module() {
local module args
module="$1"
args="$2"
if [ "$VERBOSE" != no ]; then
log_action_msg "Loading kernel module $module"
modprobe $module $args || true
else
modprobe $module $args > /dev/null 2>&1 || true
fi
}
However, under 18.04, systemd-modules-load will _ignore_ modules that
are manually listed in /etc/modules and process them with the
blacklist (the same as "modprobe -b" would). This means that it is not
possible to manually load modules that are blacklisted (like watchdog
modules):
systemd-238/src/modules-load/modules-load.c:
static int load_module(struct kmod_ctx *ctx, const char *m) {
const int probe_flags = KMOD_PROBE_APPLY_BLACKLIST;
...
default:
err = kmod_module_probe_insert_module(mod,
probe_flags,
NULL, NULL,
NULL, NULL);
if (err == 0)
log_info("Inserted module '%s'",
kmod_module_get_name(mod));
else if (err == KMOD_PROBE_APPLY_BLACKLIST)
log_info("Module '%s' is blacklisted",
kmod_module_get_name(mod));
Blacklists should _not_ be applied by systemd-modules-load.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1767172/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1604737] Re: headless installations are degraded due to failed setvtrgb.service
Assigning Dimitri who last updated this; is it still an issue? ** Changed in: console-setup (Ubuntu Xenial) Assignee: (unassigned) => Dimitri John Ledkov (xnox) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to console-setup in Ubuntu. https://bugs.launchpad.net/bugs/1604737 Title: headless installations are degraded due to failed setvtrgb.service Status in console-setup package in Ubuntu: Fix Released Status in console-setup source package in Xenial: In Progress Bug description: s390x installations are degraded due to failed setvtrgb.service on z/vm, suspecting that it should be limited to just kvm on s390x, somehow. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1604737/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1664844] Re: No distinction between link-up and link-down interfaces
** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags removed: verification-done-artful verification-done-xenial verification-done-zesty ** Changed in: systemd (Ubuntu) Status: New => In Progress ** Changed in: systemd (Ubuntu Zesty) Status: New => Won't Fix ** Package changed: nplan (Ubuntu) => netplan.io (Ubuntu) ** Changed in: systemd (Ubuntu Xenial) Status: New => Won't Fix ** Changed in: netplan.io (Ubuntu Xenial) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1664844 Title: No distinction between link-up and link-down interfaces Status in MAAS: Triaged Status in netplan: In Progress Status in netplan.io package in Ubuntu: In Progress Status in systemd package in Ubuntu: In Progress Status in netplan.io source package in Xenial: Won't Fix Status in systemd source package in Xenial: Won't Fix Status in netplan.io source package in Zesty: Won't Fix Status in systemd source package in Zesty: Won't Fix Status in netplan.io source package in Artful: Won't Fix Bug description: [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 ethernets: eth0: optional: yes dhcp4: yes And run 'netplan apply'. Netplan should write configuration for the link and not error out with a syntax error. [Regression potential] This has a minimal potential for regression: the new keyword was added to be supported already by consumers of netplan (users, cloud-init) so that they could start writing config with the new key and that configuration to be seen as valid by netplan before the backend is implemented. There is no functional change besides allowing for the value to exist in a netplan configuation. --- If I define an interface in netplan (even one which has no DHCP type and no addresses), it's not possible to determine if its adminStatus should be enabled (link up) or disabled (link down). I can completely exclude an interface from the netplan configuration, but I think that implies that not only its adminStatus is "disabled" by default, but also netplan will not be able to do anything "nice" for the interface, such as rename it to what the user specified in MAAS. If I include the interface but don't specify any addresses or DHCP, it isn't clear if it will be link up (my current assumption) or link down. There should be a way to allow an interface to be recognized by netplan (and even partially configured, waiting for the user to run something like 'ifup ' on a manual but not auto-started interface in ifupdown), but marked administratively disabled. (adminStatus down) To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1664844/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1825448] Re: gnupg2 autopkgtest 'simple-tests' should be included in x/b/c
** Tags added: rls-x-notfixing -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnupg in Ubuntu. https://bugs.launchpad.net/bugs/1825448 Title: gnupg2 autopkgtest 'simple-tests' should be included in x/b/c Status in gnupg package in Ubuntu: Invalid Status in gnupg2 package in Ubuntu: Fix Released Status in gnupg source package in Xenial: In Progress Status in gnupg2 source package in Xenial: In Progress Status in gnupg2 source package in Bionic: In Progress Status in gnupg2 source package in Cosmic: In Progress Bug description: [impact] b/c currently only have gpgv-win32 test, which is limited in what it tests and what archs it runs on. additionally, it always fails (see bug 1825186). x currently has no tests at all for gnupg or gnupg2. [test case] run autopkgtests for gnupg2 on b/c. [regession potential] adding a testcase may result in the testcase incorrectly failing in the future. [other info] this test case is cherry-picked from gnupg2 in disco. the test case required slight modification for gnupg v1, as 'Key-Type: default' only works with v2. Note that Xenial is the last release that carries gnupg v1; Bionic and later carry only gnupg v2. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1825448/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1825186] Re: gpgv-win32 autopkgtest always fails
** Tags added: rls-x-notfixing -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnupg in Ubuntu. https://bugs.launchpad.net/bugs/1825186 Title: gpgv-win32 autopkgtest always fails Status in gnupg package in Ubuntu: Invalid Status in gnupg2 package in Ubuntu: Opinion Status in gnupg source package in Xenial: In Progress Status in gnupg2 source package in Bionic: In Progress Status in gnupg2 source package in Cosmic: In Progress Status in gnupg2 source package in Disco: Fix Released Bug description: [impact] gpgv-win32 autopkgtest always fails [test case] check http://autopkgtest.ubuntu.com/packages/g/gnupg2 or run autopkgtest manually note the gpgv-win32 test is skipped on ppc64el and s390x for b/c, and has been removed from d/t/control entirely in d [regression potential] little to none; this affects the test case only [other info] as mentioned, in disco, the gpgv-win32 test has been removed from the tests/control completely. not sure if that is a better approach than fixing the test case. For now, I marked this Fix Released for disco since it doesn't fail there (since the testcase was removed). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1825186/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1828892] Re: systemctl - alias service reports inactive while aliased is active
** Tags added: rls-x-notfixing -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1828892 Title: systemctl - alias service reports inactive while aliased is active Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Bug description: [Impact] 'systemctl is-active' command reports an alias service as inactive even though the aliased service is active. Currently the 'systemctl is-active' command does not load units to minimise its effect on the system (i.e. that a monitoring command does not itself alter the state of the system). However, this behaviour leads to inconsistencies when services are aliased. [Test case] - Test case 1 - libvirtd alias service : libvirtd aliased service : libvirt-bin /etc/systemd/system$ ls -la libvirtd.service lrwxrwxrwx 1 root root 39 May 13 20:49 libvirtd.service -> /lib/systemd/system/libvirt-bin.service $ systemctl is-active libvirtd inactive $ systemctl is-active libvirt-bin active - Test case 2 - sshd alias service : sshd aliased service : ssh /ect/systemd/system$ ls -la sshd.service lrwxrwxrwx 1 root root 31 Mar 19 19:44 sshd.service -> /lib/systemd/system/ssh.service $ systemctl is-active sshd inactive $ systemctl is-active ssh active [Regression Potential] This fix may result into systemctl reporting inconsistent information concerning the status of a service. [Other] Upstream issue : https://github.com/systemd/systemd/issues/7875 Upstream fix : https://github.com/systemd/systemd/pull/7997 Xenial is affected, fix exists on Bionic onward. $ lsb_release -rd Description: Ubuntu 16.04.6 LTS Release: 16.04 $ apt-cache policy systemd systemd: Installed: 229-4ubuntu21.21 Candidate: 229-4ubuntu21.21 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1828892/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1825856] Re: gnupg package 'gpgv-udeb' conflicts with gnupg2 (xenial)
** Tags added: rls-x-notfixing -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnupg in Ubuntu. https://bugs.launchpad.net/bugs/1825856 Title: gnupg package 'gpgv-udeb' conflicts with gnupg2 (xenial) Status in gnupg package in Ubuntu: Fix Released Status in gnupg source package in Xenial: In Progress Bug description: [impact] both the 'gnupg' and 'gnupg2' sources build 'gpgv-udeb' for xenial. therefore, gnupg FTUFS since its version is < gnupg2 version. [test case] attempt to upload 'gnupg' and 'gnupg2' into a PPA. for example see this ppa: https://launchpad.net/~ddstreet/+archive/ubuntu/lp1825186/+packages?field.name_filter=_filter=superseded_filter= version 1.4.20-1ubuntu3.3+bug1825186v20190422b1 shows this problem; all archs failed because: INFO gpgv-udeb_1.4.20-1ubuntu3.3+bug1825186v20190422b1_amd64.udeb: Version older than that in the archive. 1.4.20-1ubuntu3.3+bug1825186v20190422b1 <= 2.1.11-6ubuntu2.1+bug1825186v20190419b3 from: https://launchpadlibrarian.net/420547534/upload_16673848_log.txt [regression potential] low; the gpgv-udeb pkg is provided by gnupg2 in xenial and should not be built by gnupg. [other info] the v1 pkg is not what is reported by rmadison: $ rmadison gpgv-udeb | grep xenial gpgv-udeb | 2.1.11-6ubuntu2| xenial/main/debian-installer | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x gpgv-udeb | 2.1.11-6ubuntu2.1 | xenial-security/main/debian-installer | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x gpgv-udeb | 2.1.11-6ubuntu2.1 | xenial-updates/main/debian-installer | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1825856/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1806012] Re: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server
** Tags added: rls-x-notfixing -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1806012 Title: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: Whilst debugging 'slow instance performance' on a Ubuntu Bionic based cloud, I observed that the default cpu governor configuration was set to 'powersave'; toggling this to 'performance' (while in not anyway a particularly green thing todo) resulted in the instance slowness disappearing and the cloud performance being as expected (based on a prior version of the deploy on Ubuntu Xenial). AFAICT Xenial does the same thing albeit in a slight different way, but we definitely did not see the same performance laggy-ness under a Xenial based cloud. Raising against systemd (as this package sets the governor to 'powersave') - I feel that the switch to 'performance' although appropriate then obscures what might be a performance/behavioural difference in the underlying kernel when a machine is under load. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.9 ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18 Uname: Linux 4.15.0-39-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 Date: Fri Nov 30 10:05:46 2018 Lsusb: Bus 002 Device 002: ID 8087:8002 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 413c:a001 Dell Computer Corp. Hub Bus 001 Device 002: ID 8087:800a Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. PowerEdge R630 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-39-generic root=UUID=a361a524-47eb-46c3-8a04-e5eaa65188c9 ro hugepages=103117 iommu=pt intel_iommu=on SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/08/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 2.3.4 dmi.board.name: 02C2CP dmi.board.vendor: Dell Inc. dmi.board.version: A03 dmi.chassis.type: 23 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr2.3.4:bd11/08/2016:svnDellInc.:pnPowerEdgeR630:pvr:rvnDellInc.:rn02C2CP:rvrA03:cvnDellInc.:ct23:cvr: dmi.product.name: PowerEdge R630 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1806012/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1828901] Re: add PTY support for runuser
** Tags added: rls-x-notfixing -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1828901 Title: add PTY support for runuser Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Xenial: In Progress Status in util-linux package in Debian: Fix Released Bug description: [IMPACT] [TEST CASE] [REGRESSION POTENTIAL] [OTHER INFORMATION] Debbug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815922 This is fixing a CVE vulnerability: https://security-tracker.debian.org/tracker/CVE-2016-2779 Restricting ioctl on the kernel side seems the better approach, patches have been posted to kernel-hardening list http://www.openwall.com/lists/oss-security/2016/02/27/1 https://marc.info/?l=util-linux-ng=145694736107128=2 2.31 introduces a new --pty option to separate privileged and unprivileged shells (not enabled by default and the cli switch is necessary). [ORIGINAL DESCRIPTION] After a discussion with security team on what would be their recommended way to run command as 'juju-user' inside the sosreport juju plugin which is run as root, in order to avoid using 'sudo' or 'su' command. The recommendation was to use 'runuser -P' runuser PTY support is present in Bionic and late, but not in Xenial. I'm opening this bug in the effort to update util-linux/runuser code in Xenial to add the PTY support. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1828901/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1668639] Re: Add a trigger to reload rsyslog when a new configuration file is dropped in /etc/rsyslog.d
** Tags added: rls-x-notfixing -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1668639 Title: Add a trigger to reload rsyslog when a new configuration file is dropped in /etc/rsyslog.d Status in rsyslog package in Ubuntu: Fix Released Status in rsyslog source package in Trusty: In Progress Status in rsyslog source package in Xenial: In Progress Status in rsyslog source package in Zesty: Won't Fix Status in rsyslog source package in Artful: Fix Released Status in rsyslog package in Debian: Fix Released Bug description: [Impact] Servers or cloud instances will not log important messages after initial deployment. Manual reboot or restart of services is necessary to get expected behaviour. [Test Case] 1) Install, enable and start haproxy 2) Observe that /etc/rsyslog.d/49-haproxy.conf is installed 3) Observe that /var/lib/haproxy/dev/log and /var/log/haproxy.log is NOT created 4) Restart rsyslog service 5) Observe that /var/lib/haproxy/dev/log and /var/log/haproxy.log IS created 6) Restart haproxy service and observe that log now is filled with entries With the patched deb steps 3,4 and 6 becomes irrelevant and everything works out of the box. [Regression Potential] Minimal. This patch merges a patch from Debian where a trigger is added to the rsyslog package that fires when other debs drop files into /etc/rsyslog.d. [Original Bug Description] rsyslog should reload its configuration when other packages drop configuration in /etc/rsyslog.d https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791337 https://anonscm.debian.org/cgit/collab- maint/rsyslog.git/commit/?id=8d4074003f8fb19dae07c59dd19f0540a639210f To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1668639/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1572752] Re: improve UTC setting migration on upgrades
This appears to still be unresolved. What are the next steps? Do we still want to add a Pre-Depends? How will d-i and image builds be verified to not regress? ** Changed in: sysvinit (Ubuntu Xenial) Status: In Progress => Triaged ** Changed in: sysvinit (Ubuntu Xenial) Assignee: Steve Langasek (vorlon) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sysvinit in Ubuntu. https://bugs.launchpad.net/bugs/1572752 Title: improve UTC setting migration on upgrades Status in sysvinit package in Ubuntu: Invalid Status in sysvinit source package in Xenial: Triaged Bug description: [SRU Justification] On upgrade, some users who have selected a non-default setting for their clock handling in the installer will see prompts for a conffile they never edited by hand. [Regression potential] Because we are adding a pre-dependency to a package, there is risk of this causing upgrade failures. The upgrade path should be tested aggressively with different profiles from both 14.04 and 15.10 before publishing to -updates. [Test case] 1. On a newly-installed 14.04 system, edit /etc/default/rcS to contain 'UTC=no' instead of 'UTC=yes'. Make no other changes to this file. 2. Enable -proposed in your apt sources. 3. Run do-release-upgrade or update-manager to upgrade to 16.04. 4. Confirm that the upgrade succeeds. 5. Confirm that you are not shown a conffile prompt for /etc/default/rcS on upgrade. 6. Confirm that /etc/adjtime has been created, with 'LOCAL' as the third line of the file. 7. Repeat steps 1-6 for a newly-installed 15.10 system. slangasek | pitti: I see sysvinit Breaks: systemd (<< 228-5ubuntu3), but that doesn't enforce systemd 228-5ubuntu3 being configured before sysvinit, which means the conffile may already be migrated away before systemd postinst runs... I think the right way to do this is with initscripts Pre-Depends: systemd, and for initscripts' preinst script to handle any conffile cleaning so that users are spared conffile prompts on upgrade pitti | slangasek: ah, good point; this needs to be tested thoroughly, pre-depends have some habit of causing trouble See bug 1541532 and http://launchpadlibrarian.net/236311219/systemd_228-5ubuntu2_228-5ubuntu3.diff.gz and http://launchpadlibrarian.net/236367969/sysvinit_2.88dsf-59.3ubuntu1_2.88dsf-59.3ubuntu2.diff.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1572752/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1563026] Re: LXC/LXD installed by default on Ubuntu server
This is a more complex issue; it's not just about LXD, but the general story for installing "minimal" installs. The fact that openssh-server was not installed as part of the ubuntu- server is a separate bug we've covered in a different bug report. Currently, desktops allow picking a "full" install or "minimal" installation. You also somewhat have that option for the d-i mini.iso; but IIRC not really on the new Subiquity installer. I think this needs to be a larger question than just for LXD; and will need addressing elsewhere than in ubuntu-meta in any case. Reassigning to debian-cd (where we have the grub menus and more magic for selecting "minimal" install). ** Package changed: ubuntu-meta (Ubuntu) => debian-cd (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1563026 Title: LXC/LXD installed by default on Ubuntu server Status in debian-cd package in Ubuntu: Confirmed Bug description: When performing a new installation of Ubuntu server 16.04 Beta 2, LXC and LXD are included in the default packages even when "Virtual Server" is not selected as an installation task. This brings in all of the required dependencies as well, obviously, which seems like it is not the best default behavior to have. When installing from a non-UEFI boot, the user may select "minimal install" from the "F4" menu. This menu is not available from the UEFI grub environment, making it apparently impossible to select an installation that does not include the LXC and LXD suite by default. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debian-cd/+bug/1563026/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1162475] Re: [hostnamed] Changing hostname doesn't update /etc/hosts
I don't think it's *-control-center. At the time, that was filed there by pitti, who correctly pointed out that something might need to depend on libnss-myhostname (from systemd) for a fallback to resolving hostname via just /etc/hostname (since /etc/hosts isn't changed). At this point though, it looks like this is no longer required. Now, AFAICT the desktop correctly calls to systemd via dbus to ask for the change. I'll leave to you to make sure this is indeed the case (since you had commented on the bug previously, and I can't see any issues changing hostname as it is now, but maybe I'm not quite doing the same tests you were). unity-control-center is an obvious Won't Fix for Eoan or Disco, but I'll let the Desktop Team decide whether this needs to be fixed in other releases. Finally, this is still assigned to systemd, low priority, because hostnamed *doesn't* change /etc/hosts, and probably should (at the very least for consistency, to avoid keeping a reference to an old name for the system); but I didn't notice ill effects from not changing that file. sudo certainly doesn't hang here trying to resolve the new or old hostname. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1162475 Title: [hostnamed] Changing hostname doesn't update /etc/hosts Status in gnome-control-center package in Ubuntu: Triaged Status in systemd package in Ubuntu: Triaged Status in unity-control-center package in Ubuntu: Won't Fix Status in gnome-control-center source package in Xenial: New Status in systemd source package in Xenial: Triaged Status in unity-control-center source package in Xenial: New Status in gnome-control-center package in Debian: Fix Released Bug description: GUI --- 1a. Run sudo gnome-control-center, or... 1b. Save the gnome-control-center.pkla from https://bazaar.launchpad.net/~ubuntu-desktop/gnome-control-center/ubuntu/revision/556 to /var/lib/polkit-1/localauthority/10-vendor.d/ and then run gnome-control-center as an admin user 2. Enter the Details panel 3. The "Device name" (hostname) text field should be editable; change the text to something else. 4. The hostname is updated instantly which can be verified by looking in /etc/hostname. However /etc/hosts/ is not updated. Command line hostnamectl set-hostname The hostnamed documentation at http://www.freedesktop.org/wiki/Software/systemd/hostnamed says "To properly handle name lookups with changing local hostnames without having to edit /etc/hosts for them we recommend using hostnamed in combination with nss-myhostname: http://0pointer.de/lennart/projects/nss-myhostname/ " Without /etc/hosts being handled correctly, the hostnamed integration is only half-working. ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: gnome-control-center 1:3.6.3-0ubuntu18 ProcVersionSignature: Ubuntu 3.8.0-15.25-generic 3.8.4 Uname: Linux 3.8.0-15-generic x86_64 ApportVersion: 2.9.2-0ubuntu5 Architecture: amd64 Date: Sun Mar 31 08:52:57 2013 MarkForUpload: True SourcePackage: gnome-control-center UpgradeStatus: No upgrade log present (probably fresh install) usr_lib_gnome-control-center: activity-log-manager-control-center 0.9.4-0ubuntu6.1 deja-dup26.0-0ubuntu1 gnome-control-center-signon 0.1.5-0ubuntu1 gnome-control-center-unity 1.2daily13.02.15-0ubuntu1 indicator-datetime 12.10.3daily13.03.26-0ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1162475/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1162475] Re: [hostnamed] Changing hostname doesn't update /etc/hosts
** Tags removed: rls-x-incoming ** Tags added: rls-ee-incoming ** Also affects: gnome-control-center (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: unity-control-center (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Xenial) Status: New => Triaged ** Changed in: systemd (Ubuntu Xenial) Importance: Undecided => Low ** Changed in: unity-control-center (Ubuntu) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1162475 Title: [hostnamed] Changing hostname doesn't update /etc/hosts Status in gnome-control-center package in Ubuntu: Triaged Status in systemd package in Ubuntu: Triaged Status in unity-control-center package in Ubuntu: Won't Fix Status in gnome-control-center source package in Xenial: New Status in systemd source package in Xenial: Triaged Status in unity-control-center source package in Xenial: New Status in gnome-control-center package in Debian: Fix Released Bug description: GUI --- 1a. Run sudo gnome-control-center, or... 1b. Save the gnome-control-center.pkla from https://bazaar.launchpad.net/~ubuntu-desktop/gnome-control-center/ubuntu/revision/556 to /var/lib/polkit-1/localauthority/10-vendor.d/ and then run gnome-control-center as an admin user 2. Enter the Details panel 3. The "Device name" (hostname) text field should be editable; change the text to something else. 4. The hostname is updated instantly which can be verified by looking in /etc/hostname. However /etc/hosts/ is not updated. Command line hostnamectl set-hostname The hostnamed documentation at http://www.freedesktop.org/wiki/Software/systemd/hostnamed says "To properly handle name lookups with changing local hostnames without having to edit /etc/hosts for them we recommend using hostnamed in combination with nss-myhostname: http://0pointer.de/lennart/projects/nss-myhostname/ " Without /etc/hosts being handled correctly, the hostnamed integration is only half-working. ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: gnome-control-center 1:3.6.3-0ubuntu18 ProcVersionSignature: Ubuntu 3.8.0-15.25-generic 3.8.4 Uname: Linux 3.8.0-15-generic x86_64 ApportVersion: 2.9.2-0ubuntu5 Architecture: amd64 Date: Sun Mar 31 08:52:57 2013 MarkForUpload: True SourcePackage: gnome-control-center UpgradeStatus: No upgrade log present (probably fresh install) usr_lib_gnome-control-center: activity-log-manager-control-center 0.9.4-0ubuntu6.1 deja-dup26.0-0ubuntu1 gnome-control-center-signon 0.1.5-0ubuntu1 gnome-control-center-unity 1.2daily13.02.15-0ubuntu1 indicator-datetime 12.10.3daily13.03.26-0ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1162475/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1539966] Re: Cannot login 16.04 server keymap wrong
I believe we've fixed this already, especially since it is a bug that was reported prior to the release of 16.04. We do have developers who routinely use dvorak for keymap and would otherwise not have been able to login to their systems. Reassigning to console-setup, since it is the most likely culprit; but I think it would be best if this was re-tested on recent releases and images, and if someone is still seeing this problem show up, to report it again here. For now, I'm setting this to incomplete. I believe it has been properly addressed (I made substancial changes to keyboard selection myself between this report and the release of 16.04, and in further releases). Please let us know if it isn't the case :) ** Changed in: debian-installer (Ubuntu) Status: Triaged => Incomplete ** Package changed: debian-installer (Ubuntu) => console-setup (Ubuntu) ** Tags removed: rls-x-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to console-setup in Ubuntu. https://bugs.launchpad.net/bugs/1539966 Title: Cannot login 16.04 server keymap wrong Status in console-setup package in Ubuntu: Incomplete Bug description: I just download 16.04 server, the 2016-01-11 build and installed it on Virtual Box 5.0.14. The problem I got was with the keyboard mapping in the password setting dialogue. When characters is not mapped correctly login is blocked. The preferred language was set to English, but I did set the keyboard map as Swedish (from list) during installation. During installation and in the user password setting dialogue, characters are mapped correctly what I can see (enabled with 'show password'). But at login keyboard is still American English. The character I have in the password is '*', which gives '\' with the Swedish key marked '*'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1539966/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1543799] Re: isc-dhcp-server & isc-dhcp-server6 systemd service units use the same RuntimeDirectory leading to loss of pid files
Seems like this would still apply to Eoan, marking rls-ee-tracking ** Tags removed: rls-x-incoming ** Tags added: rls-ee-tracking ** Changed in: isc-dhcp (Ubuntu) Status: Confirmed => Triaged ** Also affects: isc-dhcp (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: isc-dhcp (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: isc-dhcp (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: isc-dhcp (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: isc-dhcp (Ubuntu Xenial) Status: New => Triaged ** Changed in: isc-dhcp (Ubuntu Bionic) Status: New => Triaged ** Changed in: isc-dhcp (Ubuntu Cosmic) Status: New => Triaged ** Changed in: isc-dhcp (Ubuntu Disco) Status: New => Triaged ** Changed in: isc-dhcp (Ubuntu Xenial) Importance: Undecided => High ** Changed in: isc-dhcp (Ubuntu Bionic) Importance: Undecided => High ** Changed in: isc-dhcp (Ubuntu Cosmic) Importance: Undecided => Critical ** Changed in: isc-dhcp (Ubuntu Cosmic) Importance: Critical => High ** Changed in: isc-dhcp (Ubuntu Disco) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1543799 Title: isc-dhcp-server & isc-dhcp-server6 systemd service units use the same RuntimeDirectory leading to loss of pid files Status in isc-dhcp package in Ubuntu: Triaged Status in isc-dhcp source package in Xenial: Triaged Status in isc-dhcp source package in Bionic: Triaged Status in isc-dhcp source package in Cosmic: Triaged Status in isc-dhcp source package in Disco: Triaged Bug description: dhcpd reports 'Can't create PID file /run/dhcp-server/dhcpd.pid' (or '/run/dhcp-server/dhcpd6.pid' for isc-dhcp-server6), and no file is found /run/dhcp-server. Additionally, both isc-dhcp-server & isc-dhcp-server6 service unit files specify the RuntimeDirectory 'dhcp-server', which is removed when either unit stops (and thus would wipe out the other unit's pid file, were it being successfully written). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: isc-dhcp-server 4.3.3-5ubuntu4 ProcVersionSignature: Ubuntu 4.4.0-2.16-generic 4.4.0 Uname: Linux 4.4.0-2-generic x86_64 ApportVersion: 2.19.4-0ubuntu2 Architecture: amd64 Date: Tue Feb 9 21:34:08 2016 InstallationDate: Installed on 2016-02-09 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160206) ProcEnviron: LANGUAGE=en_GB:en TERM=linux PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: isc-dhcp UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.dhcp.dhcpd.conf: [modified] mtime.conffile..etc.dhcp.dhcpd.conf: 2016-02-09T21:11:20.104056 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1543799/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
Still verification-done on bionic and cosmic; this hasn't changed 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 this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Fix Released
Status in cloud-init package in Ubuntu:
Confirmed
Status in netplan.io package in Ubuntu:
Fix Released
Status in nplan package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Confirmed
Status in nplan source package in Xenial:
Fix Released
Status in netplan.io source package in Bionic:
Fix Committed
Status in netplan.io source package in Cosmic:
Fix Committed
Bug description:
[Impact]
Systems relying on renaming network interfaces at boot and when 'netplan
apply' is run.
[Test case]
- Write a new netplan YAML (adjusting for current system as necessary):
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: myif0
- Bring down interface : 'ip link set dev ens3 down'
- Run 'netplan apply'
- Verify that the device is correctly renamed to 'myif0'.
- Reboot.
- Make sure the device is correctly renamed to 'myif0'.
[Regression potential]
Changes in rename logic to add udev rules may otherwise impact applying
different settings to the network interfaces. Changes in settings on network
interfaces, missing parameters (especially on bonds, bridges) should be
investigated as potential regressions. Other failures to apply network settings
might also happen if there's a race between applying renames via the udev
rules, and using the new names to apply configuration changes to the interfaces.
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6
[Touch-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
** Description changed: - * Impact + [Impact] + When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not - When using a VPN the DNS requests might still be sent to a DNS server - outside the VPN when they should not + [Test case] + 1) Set up a VPN with split tunneling: + a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) + b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". + c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". - * Test case + 2) Connect to the VPN. - Configure the system to send all the traffic to a VPN, do a name - resolution, the request should not go to the public DNS server (to be - checked by capturing the traffic by example with wireshark) + 3) Run 'systemd-resolve --status'; note the DNS servers configured: + a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). + b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). + + 4) In a separate terminal, run 'sudo tcpdump -ni + port 53'; let it run. + + 5) In a separate terminal, run 'sudo tcpdump -ni + port 53'; let it run. + + 6) In yet another terminal, issue name resolution requests using dig: + a) For a name known to be reachable via the public network: + 'dig www.yahoo.com' + b) For a name known to be reachable only via the VPN: + 'dig ' + + 7) Check the output of each terminal running tcpdump. When requesting + the public name, traffic can go through either. When requesting the + "private" name (behind the VPN), traffic should only be going through + the interface for the VPN. Additionally, ensure the IP receiving the + requests for the VPN name is indeed the IP address noted above for the + VPN's DNS server. + + If you see no traffic showing in tcpdump output when requesting a name, + it may be because it is cached by systemd-resolved. Use a different name + you have not tried before. - * Regression potential - - The code change the handling of DNS servers when using a VPN, we should - check that name resolution still work whne using a VPN in different - configurations + [Regression potential] + The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Bionic: Fix Committed Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name
[Touch-packages] [Bug 1821609] Re: lightdm login screen briefly appears and then blanks out on Intel(R) Core(TM)2 Duo CPU T5870 (crash in xorg before using "foreign grub") netplan mis-configuration ma
Okay, this bug has absolutely nothing to do with grub or netplan. Changing the renderer couldn't possibly affect the behavior of X, and the grub configuration looks, at a glace, to be run-of-the mill; pretty much default if you disregard that there is any number of different installs on the system. For instance the kernel command-line: BOOT_IMAGE=/boot/vmlinuz-5.0.0-7-generic root=UUID=1d61086d- 275b-4537-bed5-f2d3080670eb ro quiet splash (from various attached output of dmesg) This command-line is pretty much default. The use of kernels 5.0.0-7 or 5.0.0-8 are what I'd expect on disco images; and there are no special kernel parameters being passed. I don't know what partition root= points to; but this is the only possible thing I could see. Grub really doesn't care what you want to start, it will just run the kernel and initrd you tell it to. Unless this is a quite unforeseen and unlikely bad interaction between kernel drivers and the limited gfxmode changes we do in grub... but we'd see this on more than just this system. Could you please attach a video or pictures of what you're seeing on the screen, along with clear details of *any* modifications you do to boot something, how you set up your tests, so that we could potentially reproduce this or see what is happening? I'm cleaning up the title here for clarity; but this seems like either a kernel bug, some missing modules for your particular setup, or bad interactions because of the very complicated multi-boot scenario you're presenting. ** Summary changed: - lightdm login screen briefly appears and then blanks out on Intel(R) Core(TM)2 Duo CPU T5870 (crash in xorg before using "foreign grub") netplan mis-configuration maybe underlying cause. + lightdm login screen briefly appears and then blanks out on Intel(R) Core(TM)2 Duo CPU T5870 ** Changed in: lightdm (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1821609 Title: lightdm login screen briefly appears and then blanks out on Intel(R) Core(TM)2 Duo CPU T5870 Status in lightdm package in Ubuntu: Incomplete Status in linux package in Ubuntu: Incomplete Status in xorg-server package in Ubuntu: Invalid Bug description: Okay the has happened recently at least since march 18, 2019 iso and march 22, 2019 iso are both effected very similar to one of my previously reported bugs .. which was related to xorg not being installed .. back ground .. PC is lenovo sl 500 with evo860 SSD drive 3 partions contain installs of disco sda1 -- main working system -- I usually install grub from here as master .. sda6 and sda7 are test installs of disco daily iso's 03-18-2019, 03-22-2019 repectively on the test installs as long as the iso is using the grub boot loader installed from that install the system will boot normally .. the display manger tends to flicker on and off but does final start and login can proceed. but if another install re-installs grub as master the display manager fails to stay active or even come-up for sda6 or sda7 only if their own grubs are reinstalled will they work normally sda1 display manager/xorg login works always no matter which "grub- source" is in control. if I use rescue boot from any grub as master I can get the displays to work by running dpkg fix which does nothing .. and then resuming the boot .. then things work normally.. if the "non-rescue" boots are used the screen/computer locks and only a power down and reboot gives access. (sometime requiring radical depowering .. unpluging and removing battery) now the is a message that appears that RCs??? level is missing. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: xorg 1:7.7+19ubuntu11 ProcVersionSignature: Ubuntu 5.0.0-7.8-generic 5.0.0 Uname: Linux 5.0.0-7-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: XFCE Date: Mon Mar 25 11:25:58 2019 DistUpgraded: Fresh install DistroCodename: disco DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GpuHangFrequency: Several times a day GpuHangReproducibility: Yes, I can easily reproduce it GpuHangStarted: Immediately after installing this version of Ubuntu GraphicsCard: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] InstallationDate: Installed on 2019-03-23 (1 days ago) InstallationMedia: Xubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190322) MachineType: LENOVO 2746CTO ProcKernelCmdLine:
[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
This does not need re-testing, already in bionic/cosmic, just closed
again due to changelog for this big backport.
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Fix Released
Status in cloud-init package in Ubuntu:
Confirmed
Status in netplan.io package in Ubuntu:
Fix Released
Status in nplan package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Confirmed
Status in nplan source package in Xenial:
Fix Released
Status in netplan.io source package in Bionic:
Fix Committed
Status in netplan.io source package in Cosmic:
Fix Committed
Bug description:
[Impact]
Systems relying on renaming network interfaces at boot and when 'netplan
apply' is run.
[Test case]
- Write a new netplan YAML (adjusting for current system as necessary):
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: myif0
- Bring down interface : 'ip link set dev ens3 down'
- Run 'netplan apply'
- Verify that the device is correctly renamed to 'myif0'.
- Reboot.
- Make sure the device is correctly renamed to 'myif0'.
[Regression potential]
Changes in rename logic to add udev rules may otherwise impact applying
different settings to the network interfaces. Changes in settings on network
interfaces, missing parameters (especially on bonds, bridges) should be
investigated as potential regressions. Other failures to apply network settings
might also happen if there's a race between applying renames via the udev
rules, and using the new names to apply configuration changes to the interfaces.
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
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 verification-done-cosmic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Fix Released
Status in cloud-init package in Ubuntu:
Confirmed
Status in netplan.io package in Ubuntu:
Fix Released
Status in nplan package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Confirmed
Status in nplan source package in Xenial:
Fix Released
Status in netplan.io source package in Bionic:
Fix Committed
Status in netplan.io source package in Cosmic:
Fix Committed
Bug description:
[Impact]
Systems relying on renaming network interfaces at boot and when 'netplan
apply' is run.
[Test case]
- Write a new netplan YAML (adjusting for current system as necessary):
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: myif0
- Bring down interface : 'ip link set dev ens3 down'
- Run 'netplan apply'
- Verify that the device is correctly renamed to 'myif0'.
- Reboot.
- Make sure the device is correctly renamed to 'myif0'.
[Regression potential]
Changes in rename logic to add udev rules may otherwise impact applying
different settings to the network interfaces. Changes in settings on network
interfaces, missing parameters (especially on bonds, bridges) should be
investigated as potential regressions. Other failures to apply network settings
might also happen if there's a race between applying renames via the udev
rules, and using the new names to apply configuration changes to the interfaces.
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
[Touch-packages] [Bug 1820929] Re: netplan should consider adding more udev attribute for exact matching of failover 3-netdev interfaces
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 might
have filesystem errors.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1820929
Title:
netplan should consider adding more udev attribute for exact matching
of failover 3-netdev interfaces
Status in netplan:
Triaged
Status in netplan.io package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Incomplete
Bug description:
This bug is a follow-up to
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
after applying the 0001-net_failover-delay-taking-over-primary-device-
to-acc.patch attached in that bug, the VF interface "eth0" is renamed
to "rename4" instead of "ens4". Log is showing that attempt to rename
"eth0" to "ens3" failed because of conflict with existing name, so
that's why it ends up with rename4.
vsbalakr@ubuntu-18:~$ uname -a
Linux ubuntu-18 4.15.0-1009-oracle #11+lp1815268 SMP Tue Mar 12 15:20:15 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
vsbalakr@ubuntu-18:~$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd
00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noqueue state UP
mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd
ff:ff:ff:ff:ff:ff
3: ens3nsby: mtu 1500 qdisc pfifo_fast
master ens3 state UP mode DEFAULT group default qlen 1000 link/ether
ba:fb:9f:12:2f:02 brd ff:ff:ff:ff:ff:ff
4: rename4: mtu 1500 qdisc mq master ens3
state UP mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd
ff:ff:ff:ff:ff:ff
vsbalakr@ubuntu-18:~$ egrep -i '(rename4|busy)' /var/log/syslog
...
Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]: [1552932112.9591]
device (rename4): carrier: link connected
Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]: [1552932112.9591]
device (rename4): enslaved to non-master-type device ens3; ignoring
Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: error changing net interface
name 'eth0' to 'ens3': Device or resource busy
Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: could not rename interface '4'
from 'eth0' to 'ens3': Device or resource busy
Within VM there's netplan config as below:
vsbalakr@ubuntu-18:~$ cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
ens3:
dhcp4: yes
gateway4: 10.211.8.1
nameservers:
addresses: [10.211.11.1,10.209.76.197]
By running udevadm test, we can see the conflicting ens3 name comes
from netplan's /run/udev/rules.d/99-netplan-ens3.rules
vsbalakr@ubuntu-18:~$ cat /run/udev/rules.d/99-netplan-ens3.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="ba:fb:9f:12:2f:02", NAME="ens3"
vsbalakr@ubuntu-18:/lib/udev/rules.d$ udevadm test --action="add"
/sys/class/net/eth0
calling: test
version 237
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.
Load module index
Parsed configuration file /lib/systemd/network/99-default.link
Parsed configuration file /run/systemd/network/10-netplan-ens3.link
Created link configuration context.
Reading rules file: /lib/udev/rules.d/01-md-raid-creating.rules
..
Reading rules file: /lib/udev/rules.d/99-vmware-scsi-udev.rules
rules contain 393216 bytes tokens (32768 * 12 bytes), 38638 bytes strings
25317 strings (216160 bytes), 21957 de-duplicated (180883 bytes), 3361 trie
nodes used
RUN '/lib/open-iscsi/net-interface-handler start'
/lib/udev/rules.d/70-iscsi-network-interface.rules:2
IMPORT builtin 'net_id' /lib/udev/rules.d/75-net-description.rules:6
IMPORT builtin 'hwdb' /lib/udev/rules.d/75-net-description.rules:12
RUN 'ifupdown-hotplug' /lib/udev/rules.d/80-ifupdown.rules:5
IMPORT builtin 'path_id' /lib/udev/rules.d/80-net-setup-link.rules:5
IMPORT builtin 'net_setup_link' /lib/udev/rules.d/80-net-setup-link.rules:9
Config file /lib/systemd/network/99-default.link applies to device eth0
link_config: autonegotiation is unset or enabled, the speed and duplex are
not writable.
link_config: could not set ethtool features for eth0
Could not set offload features of eth0: Operation not permitted
NAME 'ens4' /lib/udev/rules.d/80-net-setup-link.rules:11
NAME 'ens3' /run/udev/rules.d/99-netplan-ens3.rules:1
RUN '/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name
[Touch-packages] [Bug 1821867] Re: network interface is down after post-install reboot of a default disco installation
** 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 up correctly. + 4) Reboot. + 5) Verify that the network comes up properly. + + [Regression potential] + Minimal; this reverts changes in a package that was never released to -updates, only available as SRU in -proposed and on the devel release. This only applies to the order in which systemd-networkd is enabled when used as a renderer for netplan configuration, to start in multi-user.target instead of the "correct", but inefficient "network-online.target" as the latter may not be depended upon in minimal installs. + + --- + After doing a default disco installation on s390x using the beta ISO image aka daily from March 26th and the post-install reboot the system restarts aka reipls (in z/VM in this case) but the interface is not brought up. Hence no remote connections are possible. The ip cmd shows: - ip a + ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group defaul - t qlen 1000 - link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 - inet 127.0.0.1/8 scope host lo -valid_lft forever preferred_lft forever - inet6 ::1/128 scope host -valid_lft forever preferred_lft forever + t qlen 1000 + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever + inet6 ::1/128 scope host + valid_lft forever preferred_lft forever 2: enc600: mtu 1500 qdisc noop state DOWN group default ql - en 1000 - link/ether 02:28:0b:00:00:15 brd ff:ff:ff:ff:ff:ff + en 1000 + link/ether 02:28:0b:00:00:15 brd ff:ff:ff:ff:ff:ff The netplan yaml file looks fine: - cat /etc/netplan/*.yaml + cat /etc/netplan/*.yaml # This file describes the network interfaces available on your system - # For more information, see netplan(5). - network: - version: 2 - renderer: networkd - ethernets: - enc600: - addresses: ¬ 10.245.236.27/24 | - gateway4: 10.245.236.1 - nameservers: - search: ¬ canonical.com | - addresses: - - "10.245.236.1" + # For more information, see netplan(5). + network: + version: 2 + renderer: networkd + ethernets: + enc600: + addresses: ¬ 10.245.236.27/24 | + gateway4: 10.245.236.1 + nameservers: + search: ¬ canonical.com | + addresses: + - "10.245.236.1" Using ip to bring the interface up doesn't help: buntu§hwe0007:ß$ sudo ip link set enc600 up sudo ip link set enc600 up ubuntu§hwe0007:ß$ ip addr show enc600 - ip addr show enc600 + ip addr show enc600 2: enc600: mtu 1500 qdisc fq_codel state UP gr - oup default qlen 1000 - link/ether 02:28:0b:00:00:15 brd ff:ff:ff:ff:ff:ff - inet6 fe80::28:bff:fe00:15/64 scope link -valid_lft forever preferred_lft forever + oup default qlen 1000 + link/ether 02:28:0b:00:00:15 brd ff:ff:ff:ff:ff:ff + inet6 fe80::28:bff:fe00:15/64 scope link + valid_lft forever preferred_lft forever ubuntu§hwe0007:ß$ But finally executing netplan apply does help: sudo netplan apply --dryrun - sudo netplan apply --dryrun + sudo netplan apply --dryrun ubuntu§hwe0007:ß$ sudo netplan apply - sudo netplan apply + sudo netplan apply ubuntu§hwe0007:ß$ ip addr show enc600 - ip addr show enc600 + ip addr show enc600 2: enc600: mtu 1500 qdisc fq_codel state UP gr - oup default qlen 1000 - link/ether 02:28:0b:00:00:15 brd ff:ff:ff:ff:ff:ff - inet 10.245.236.27/24 brd 10.245.236.255 scope global enc600 -valid_lft forever preferred_lft forever - inet6 fe80::28:bff:fe00:15/64 scope link -valid_lft forever preferred_lft forever - ubuntu§hwe0007:ß$ + oup default qlen 1000 + link/ether 02:28:0b:00:00:15 brd ff:ff:ff:ff:ff:ff + inet 10.245.236.27/24 brd 10.245.236.255 scope global enc600 + valid_lft forever preferred_lft forever + inet6 fe80::28:bff:fe00:15/64 scope link + valid_lft forever preferred_lft forever + ubuntu§hwe0007:ß$ (Sorry for the partly duplicate lines and some strange characters, but this is due to the fact that I copied the output from the console that requires a 3270 terminal emulation) ** Changed in: netplan.io (Ubuntu) Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1821867 Title: network interface is down after post-install reboot of a default disco installation Status in Ubuntu on IBM z Systems: Triaged Status in netplan.io package in Ubuntu: In Progress Status
[Touch-packages] [Bug 1820929] Re: netplan should consider adding more udev attribute for exact matching of failover 3-netdev interfaces
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 provided
do not look like generated configs from cloud-init).
I'm curious to see how this behaves with the most simple netplan
configuration possible; if you still see renaming issues in that case
from the kernel -- as those would be renaming done completely outside of
netplan and further direct our debugging to systemd-network / systemd-
udev instead.
In short; how much of the issues are you seeing when the only netplan
config on the systems is /etc/netplan/01-netcfg.yaml (the one generated
by debian-installer)?
Judging from the original description, I'd say you still get renaming
issues, specifically any new device with the MAC is attempted to be
named "ens3" because of the udev rules:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="ba:fb:9f:12:2f:02", NAME="ens3"
This part should not vary whether there are statically assigned
addresses or not; but it's also questionable whether or not it is useful
to write it in the first place: systemd-udev should already be following
ifnames policy to name the device appropriately (this should be true in
all scenarios, this is only marginally useful for /renaming/ (when set-
name: is specified) or setting MTU and such low-level options).
Finally, could you please also provide us with the output of:
sudo udevadm info /sys/class/net/ens4 (or rename4, depending on how it ends up
being named).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1820929
Title:
netplan should consider adding more udev attribute for exact matching
of failover 3-netdev interfaces
Status in netplan:
Triaged
Status in netplan.io package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Incomplete
Bug description:
This bug is a follow-up to
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
after applying the 0001-net_failover-delay-taking-over-primary-device-
to-acc.patch attached in that bug, the VF interface "eth0" is renamed
to "rename4" instead of "ens4". Log is showing that attempt to rename
"eth0" to "ens3" failed because of conflict with existing name, so
that's why it ends up with rename4.
vsbalakr@ubuntu-18:~$ uname -a
Linux ubuntu-18 4.15.0-1009-oracle #11+lp1815268 SMP Tue Mar 12 15:20:15 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
vsbalakr@ubuntu-18:~$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd
00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noqueue state UP
mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd
ff:ff:ff:ff:ff:ff
3: ens3nsby: mtu 1500 qdisc pfifo_fast
master ens3 state UP mode DEFAULT group default qlen 1000 link/ether
ba:fb:9f:12:2f:02 brd ff:ff:ff:ff:ff:ff
4: rename4: mtu 1500 qdisc mq master ens3
state UP mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd
ff:ff:ff:ff:ff:ff
vsbalakr@ubuntu-18:~$ egrep -i '(rename4|busy)' /var/log/syslog
...
Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]: [1552932112.9591]
device (rename4): carrier: link connected
Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]: [1552932112.9591]
device (rename4): enslaved to non-master-type device ens3; ignoring
Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: error changing net interface
name 'eth0' to 'ens3': Device or resource busy
Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: could not rename interface '4'
from 'eth0' to 'ens3': Device or resource busy
Within VM there's netplan config as below:
vsbalakr@ubuntu-18:~$ cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
ens3:
dhcp4: yes
gateway4: 10.211.8.1
nameservers:
addresses: [10.211.11.1,10.209.76.197]
By running udevadm test, we can see the conflicting ens3 name comes
from netplan's /run/udev/rules.d/99-netplan-ens3.rules
vsbalakr@ubuntu-18:~$ cat /run/udev/rules.d/99-netplan-ens3.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="ba:fb:9f:12:2f:02", NAME="ens3"
vsbalakr@ubuntu-18:/lib/udev/rules.d$ udevadm test --action="add"
/sys/class/net/eth0
calling: test
version 237
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.
Load module index
Parsed configuration file /lib/systemd/network/99-default.link
Parsed
[Touch-packages] [Bug 1820929] Re: netplan should consider adding more udev attribute for exact matching of failover 3-netdev interfaces
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 # This should only be required for clients who do
not have control over their DHCP server, and thus can't use the DUID to
set reservations and instead must use the MAC address to get a "static"
IP from DHCP. I would recommend not setting this if it can be avoided.
Also:
critical: true # This is only required for systems booting off
the network to reach their root filesystem. It will control whether the
DHCP IP is released / regained when systemd-networkd restarts. Again, I
would recommend not setting this if it's not required; DHCP leases
lifetimes should ensure you will get the same address again.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1820929
Title:
netplan should consider adding more udev attribute for exact matching
of failover 3-netdev interfaces
Status in netplan:
Triaged
Status in netplan.io package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Incomplete
Bug description:
This bug is a follow-up to
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
after applying the 0001-net_failover-delay-taking-over-primary-device-
to-acc.patch attached in that bug, the VF interface "eth0" is renamed
to "rename4" instead of "ens4". Log is showing that attempt to rename
"eth0" to "ens3" failed because of conflict with existing name, so
that's why it ends up with rename4.
vsbalakr@ubuntu-18:~$ uname -a
Linux ubuntu-18 4.15.0-1009-oracle #11+lp1815268 SMP Tue Mar 12 15:20:15 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
vsbalakr@ubuntu-18:~$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd
00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noqueue state UP
mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd
ff:ff:ff:ff:ff:ff
3: ens3nsby: mtu 1500 qdisc pfifo_fast
master ens3 state UP mode DEFAULT group default qlen 1000 link/ether
ba:fb:9f:12:2f:02 brd ff:ff:ff:ff:ff:ff
4: rename4: mtu 1500 qdisc mq master ens3
state UP mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd
ff:ff:ff:ff:ff:ff
vsbalakr@ubuntu-18:~$ egrep -i '(rename4|busy)' /var/log/syslog
...
Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]: [1552932112.9591]
device (rename4): carrier: link connected
Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]: [1552932112.9591]
device (rename4): enslaved to non-master-type device ens3; ignoring
Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: error changing net interface
name 'eth0' to 'ens3': Device or resource busy
Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: could not rename interface '4'
from 'eth0' to 'ens3': Device or resource busy
Within VM there's netplan config as below:
vsbalakr@ubuntu-18:~$ cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
ens3:
dhcp4: yes
gateway4: 10.211.8.1
nameservers:
addresses: [10.211.11.1,10.209.76.197]
By running udevadm test, we can see the conflicting ens3 name comes
from netplan's /run/udev/rules.d/99-netplan-ens3.rules
vsbalakr@ubuntu-18:~$ cat /run/udev/rules.d/99-netplan-ens3.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="ba:fb:9f:12:2f:02", NAME="ens3"
vsbalakr@ubuntu-18:/lib/udev/rules.d$ udevadm test --action="add"
/sys/class/net/eth0
calling: test
version 237
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.
Load module index
Parsed configuration file /lib/systemd/network/99-default.link
Parsed configuration file /run/systemd/network/10-netplan-ens3.link
Created link configuration context.
Reading rules file: /lib/udev/rules.d/01-md-raid-creating.rules
..
Reading rules file: /lib/udev/rules.d/99-vmware-scsi-udev.rules
rules contain 393216 bytes tokens (32768 * 12 bytes), 38638 bytes strings
25317 strings (216160 bytes), 21957 de-duplicated (180883 bytes), 3361 trie
nodes used
RUN '/lib/open-iscsi/net-interface-handler start'
/lib/udev/rules.d/70-iscsi-network-interface.rules:2
IMPORT builtin 'net_id' /lib/udev/rules.d/75-net-description.rules:6
IMPORT builtin 'hwdb' /lib/udev/rules.d/75-net-description.rules:12
RUN 'ifupdown-hotplug' /lib/udev/rules.d/80-ifupdown.rules:5
IMPORT builtin 'path_id'
[Touch-packages] [Bug 1821867] Re: network interface is down after post-install reboot of a default disco installation
This seems quite likely to be an issue with netplan; I've had a similar report on UC18; where systemd-networkd isn't started. Turns out netplan moved the enablement of systemd-netwrokd to network- online.target; but unfortunately there may be no service or target depending on that. I'll revert the change to put systemd-networkd back under multi-user.target. ** Also affects: netplan.io (Ubuntu) Importance: Undecided Status: New ** Changed in: netplan.io (Ubuntu) Status: New => Triaged ** Changed in: netplan.io (Ubuntu) Importance: Undecided => Critical ** Changed in: netplan.io (Ubuntu) Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1821867 Title: network interface is down after post-install reboot of a default disco installation Status in Ubuntu on IBM z Systems: New Status in netplan.io package in Ubuntu: Triaged Status in systemd package in Ubuntu: New Bug description: After doing a default disco installation on s390x using the beta ISO image aka daily from March 26th and the post-install reboot the system restarts aka reipls (in z/VM in this case) but the interface is not brought up. Hence no remote connections are possible. The ip cmd shows: ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group defaul t qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enc600: mtu 1500 qdisc noop state DOWN group default ql en 1000 link/ether 02:28:0b:00:00:15 brd ff:ff:ff:ff:ff:ff The netplan yaml file looks fine: cat /etc/netplan/*.yaml # This file describes the network interfaces available on your system # For more information, see netplan(5). network: version: 2 renderer: networkd ethernets: enc600: addresses: ¬ 10.245.236.27/24 | gateway4: 10.245.236.1 nameservers: search: ¬ canonical.com | addresses: - "10.245.236.1" Using ip to bring the interface up doesn't help: buntu§hwe0007:ß$ sudo ip link set enc600 up sudo ip link set enc600 up ubuntu§hwe0007:ß$ ip addr show enc600 ip addr show enc600 2: enc600: mtu 1500 qdisc fq_codel state UP gr oup default qlen 1000 link/ether 02:28:0b:00:00:15 brd ff:ff:ff:ff:ff:ff inet6 fe80::28:bff:fe00:15/64 scope link valid_lft forever preferred_lft forever ubuntu§hwe0007:ß$ But finally executing netplan apply does help: sudo netplan apply --dryrun sudo netplan apply --dryrun ubuntu§hwe0007:ß$ sudo netplan apply sudo netplan apply ubuntu§hwe0007:ß$ ip addr show enc600 ip addr show enc600 2: enc600: mtu 1500 qdisc fq_codel state UP gr oup default qlen 1000 link/ether 02:28:0b:00:00:15 brd ff:ff:ff:ff:ff:ff inet 10.245.236.27/24 brd 10.245.236.255 scope global enc600 valid_lft forever preferred_lft forever inet6 fe80::28:bff:fe00:15/64 scope link valid_lft forever preferred_lft forever ubuntu§hwe0007:ß$ (Sorry for the partly duplicate lines and some strange characters, but this is due to the fact that I copied the output from the console that requires a 3270 terminal emulation) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1821867/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1759014] Re: Netplan has no way to control DHCP client
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 this SRU despite
any additional issues existing in systemd that also might need to be
fixed.
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1759014
Title:
Netplan has no way to control DHCP client
Status in netplan:
Fix Released
Status in netplan.io package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
New
Status in netplan.io source package in Bionic:
Fix Committed
Status in systemd source package in Bionic:
New
Status in netplan.io source package in Cosmic:
Fix Committed
Status in systemd source package in Cosmic:
New
Status in netplan.io source package in Disco:
Fix Released
Status in systemd source package in Disco:
New
Bug description:
[Impact]
DHCP configurations where custom settings (routes, nameservers, etc.) need to
be applied.
[Test case]
1) Configure netplan for the particulars of the network by configuring an
appropriate dhcp{4,6}-override stanza:
network:
version: 2
ethernets:
engreen:
dhcp4: true
dhcp4-overrides:
use-dns: false
use-routes: false
route-metric:
Additionally, if so required, add a custom DNS / routes to the
configuration. e.g.
nameservers:
search: [lab, kitchen]
addresses: [8.8.8.8]
(See https://netplan.io/reference#dhcp-overrides for the available
options)
2) Run 'netplan apply' or reboot to have the configuration applied.
3) Validate that the routes / DNS are properly ignored and/or replaced by the
defined values.
[Regression potential]
Minimal; this adds new values to the configuration generated for networkd or
NetworkManager. Existing configurations will remain unchanged, but new
configurations using the dhcp{4,6}-overrides fields will benefit from
additional flexibility.
---
Currently DHCP appears to be an all or nothing boolean, which is insufficient
for many network configurations.
Ideally all of the DHCP configuration options supported by systemd would also
be supported in netplan:
https://www.freedesktop.org/software/systemd/man/systemd.network.html#%5BDHCP%5D%20Section%20Options
As an example, consider the following netplan configuration:
network:
version: 2
renderer: networkd
ethernets:
enp0s3:
dhcp4: yes
nameservers: [8.8.8.8,8.8.4.4]
After running netplan apply I check the nameservers with systemd-
resolve --status and it shows:
DNS Servers: 8.8.8.8
8.8.4.4
192.168.1.1
Here, "192.168.1.1" was provided by my DHCP server. On this
particular node, I only want the manually configured DNS servers, but
netplan has no way to indicate this.
To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1759014/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1820929] Re: netplan should consider adding more udev attribute for exact matching of failover 3-netdev interfaces
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 sufficient. This might require work in udev, so I've
added a task for systemd.
Could you please provide us with more information on these devices?
Could you please run 'udevadm info' for the slaves as well, so we see if
there are any extra fields we can use?
If we can't find anything usable already in udev, then we might need to
consider modifying the kernel driver itself to expose some information
that will be needed to make the difference between the devices.
This is Triaged/Undecided for netplan, since it's quite obviously a
limitation, it will need work to implement, but we can't really
prioritize it before knowing what data we can work with to match on the
interfaces / work done on systemd/udev.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1820929
Title:
netplan should consider adding more udev attribute for exact matching
of failover 3-netdev interfaces
Status in netplan:
Triaged
Status in netplan.io package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Incomplete
Bug description:
This bug is a follow-up to
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
after applying the 0001-net_failover-delay-taking-over-primary-device-
to-acc.patch attached in that bug, the VF interface "eth0" is renamed
to "rename4" instead of "ens4". Log is showing that attempt to rename
"eth0" to "ens3" failed because of conflict with existing name, so
that's why it ends up with rename4.
vsbalakr@ubuntu-18:~$ uname -a
Linux ubuntu-18 4.15.0-1009-oracle #11+lp1815268 SMP Tue Mar 12 15:20:15 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
vsbalakr@ubuntu-18:~$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd
00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noqueue state UP
mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd
ff:ff:ff:ff:ff:ff
3: ens3nsby: mtu 1500 qdisc pfifo_fast
master ens3 state UP mode DEFAULT group default qlen 1000 link/ether
ba:fb:9f:12:2f:02 brd ff:ff:ff:ff:ff:ff
4: rename4: mtu 1500 qdisc mq master ens3
state UP mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd
ff:ff:ff:ff:ff:ff
vsbalakr@ubuntu-18:~$ egrep -i '(rename4|busy)' /var/log/syslog
...
Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]: [1552932112.9591]
device (rename4): carrier: link connected
Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]: [1552932112.9591]
device (rename4): enslaved to non-master-type device ens3; ignoring
Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: error changing net interface
name 'eth0' to 'ens3': Device or resource busy
Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: could not rename interface '4'
from 'eth0' to 'ens3': Device or resource busy
Within VM there's netplan config as below:
vsbalakr@ubuntu-18:~$ cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
ens3:
dhcp4: yes
gateway4: 10.211.8.1
nameservers:
addresses: [10.211.11.1,10.209.76.197]
By running udevadm test, we can see the conflicting ens3 name comes
from netplan's /run/udev/rules.d/99-netplan-ens3.rules
vsbalakr@ubuntu-18:~$ cat /run/udev/rules.d/99-netplan-ens3.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="ba:fb:9f:12:2f:02", NAME="ens3"
vsbalakr@ubuntu-18:/lib/udev/rules.d$ udevadm test --action="add"
/sys/class/net/eth0
calling: test
version 237
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.
Load module index
Parsed configuration file /lib/systemd/network/99-default.link
Parsed configuration file /run/systemd/network/10-netplan-ens3.link
Created link configuration context.
Reading rules file: /lib/udev/rules.d/01-md-raid-creating.rules
..
Reading rules file: /lib/udev/rules.d/99-vmware-scsi-udev.rules
rules contain 393216 bytes tokens (32768 * 12 bytes), 38638 bytes strings
25317 strings (216160 bytes), 21957 de-duplicated (180883 bytes), 3361 trie
nodes used
RUN '/lib/open-iscsi/net-interface-handler start'
/lib/udev/rules.d/70-iscsi-network-interface.rules:2
IMPORT builtin 'net_id' /lib/udev/rules.d/75-net-description.rules:6
IMPORT builtin 'hwdb' /lib/udev/rules.d/75-net-description.rules:12
RUN 'ifupdown-hotplug'
[Touch-packages] [Bug 1820929] Re: netplan should consider adding more udev attribute for exact matching of failover 3-netdev interfaces
** 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: systemd (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1820929
Title:
netplan should consider adding more udev attribute for exact matching
of failover 3-netdev interfaces
Status in netplan:
Triaged
Status in netplan.io package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Incomplete
Bug description:
This bug is a follow-up to
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
after applying the 0001-net_failover-delay-taking-over-primary-device-
to-acc.patch attached in that bug, the VF interface "eth0" is renamed
to "rename4" instead of "ens4". Log is showing that attempt to rename
"eth0" to "ens3" failed because of conflict with existing name, so
that's why it ends up with rename4.
vsbalakr@ubuntu-18:~$ uname -a
Linux ubuntu-18 4.15.0-1009-oracle #11+lp1815268 SMP Tue Mar 12 15:20:15 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
vsbalakr@ubuntu-18:~$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd
00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noqueue state UP
mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd
ff:ff:ff:ff:ff:ff
3: ens3nsby: mtu 1500 qdisc pfifo_fast
master ens3 state UP mode DEFAULT group default qlen 1000 link/ether
ba:fb:9f:12:2f:02 brd ff:ff:ff:ff:ff:ff
4: rename4: mtu 1500 qdisc mq master ens3
state UP mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd
ff:ff:ff:ff:ff:ff
vsbalakr@ubuntu-18:~$ egrep -i '(rename4|busy)' /var/log/syslog
...
Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]: [1552932112.9591]
device (rename4): carrier: link connected
Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]: [1552932112.9591]
device (rename4): enslaved to non-master-type device ens3; ignoring
Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: error changing net interface
name 'eth0' to 'ens3': Device or resource busy
Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: could not rename interface '4'
from 'eth0' to 'ens3': Device or resource busy
Within VM there's netplan config as below:
vsbalakr@ubuntu-18:~$ cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
ens3:
dhcp4: yes
gateway4: 10.211.8.1
nameservers:
addresses: [10.211.11.1,10.209.76.197]
By running udevadm test, we can see the conflicting ens3 name comes
from netplan's /run/udev/rules.d/99-netplan-ens3.rules
vsbalakr@ubuntu-18:~$ cat /run/udev/rules.d/99-netplan-ens3.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="ba:fb:9f:12:2f:02", NAME="ens3"
vsbalakr@ubuntu-18:/lib/udev/rules.d$ udevadm test --action="add"
/sys/class/net/eth0
calling: test
version 237
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.
Load module index
Parsed configuration file /lib/systemd/network/99-default.link
Parsed configuration file /run/systemd/network/10-netplan-ens3.link
Created link configuration context.
Reading rules file: /lib/udev/rules.d/01-md-raid-creating.rules
..
Reading rules file: /lib/udev/rules.d/99-vmware-scsi-udev.rules
rules contain 393216 bytes tokens (32768 * 12 bytes), 38638 bytes strings
25317 strings (216160 bytes), 21957 de-duplicated (180883 bytes), 3361 trie
nodes used
RUN '/lib/open-iscsi/net-interface-handler start'
/lib/udev/rules.d/70-iscsi-network-interface.rules:2
IMPORT builtin 'net_id' /lib/udev/rules.d/75-net-description.rules:6
IMPORT builtin 'hwdb' /lib/udev/rules.d/75-net-description.rules:12
RUN 'ifupdown-hotplug' /lib/udev/rules.d/80-ifupdown.rules:5
IMPORT builtin 'path_id' /lib/udev/rules.d/80-net-setup-link.rules:5
IMPORT builtin 'net_setup_link' /lib/udev/rules.d/80-net-setup-link.rules:9
Config file /lib/systemd/network/99-default.link applies to device eth0
link_config: autonegotiation is unset or enabled, the speed and duplex are
not writable.
link_config: could not set ethtool features for eth0
Could not set offload features of eth0: Operation not permitted
NAME 'ens4' /lib/udev/rules.d/80-net-setup-link.rules:11
NAME 'ens3' /run/udev/rules.d/99-netplan-ens3.rules:1
RUN '/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name
[Touch-packages] [Bug 1813835] Re: Wrong dev in routing table in case of bridge on vlan
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! ** Changed in: netplan Status: New => Incomplete ** Also affects: netplan.io (Ubuntu) Importance: Undecided Status: New ** Changed in: netplan.io (Ubuntu) Status: New => Incomplete ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1813835 Title: Wrong dev in routing table in case of bridge on vlan Status in netplan: Incomplete Status in netplan.io package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Incomplete Bug description: network: version: 2 renderer: networkd ethernets: eno1: dhcp4: no dhcp6: no accept-ra: false vlans: voffice: id: 10 link: eno1 accept-ra: false bridges: broffice: interfaces: [ voffice ] addresses: [10.200.10.2/24, 10.200.10.3/24 ] gateway4: 10.200.10.1 nameservers: addresses: [ "10.200.10.1" ] routes: - to: 0.0.0.0/0 via: 10.200.10.1 table: 10 routing-policy: - from: 10.200.10.0/24 priority: 10 table: 10 has the following result: # ip route list table 10 default via 10.200.10.1 dev broffice proto static 10.200.10.0/24 dev voffice scope link src 10.200.10.2 The intended result would be: # ip route list table 10 default via 10.200.10.1 dev broffice proto static 10.200.10.0/24 dev broffice scope link src 10.200.10.2 To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1813835/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1820771] Re: systemd-networkd exhibits core dump on greater than 1024 addresses
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 Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1820771 Title: systemd-networkd exhibits core dump on greater than 1024 addresses Status in systemd package in Ubuntu: New Bug description: Attempting to add 2000 IP addresses. However, after the 1024 mark, systemd-networkd reports a core dump and abandons the IP configuration. systemd-networkd status: --- systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled-runtime; vendor preset: enabled) Active: failed (Result: core-dump) since Mon 2019-03-18 19:19:00 EDT; 9s ago Docs: man:systemd-networkd.service(8) Process: 2578 ExecStart=/lib/systemd/systemd-networkd (code=dumped, signal=ABRT) Main PID: 2578 (code=dumped, signal=ABRT) Mar 18 19:19:00 hostname systemd[1]: Failed to start Network Service. Mar 18 19:19:00 hostname systemd[1]: systemd-networkd.service: Service has no hold-off time, scheduling restart. Mar 18 19:19:00 hostname systemd[1]: systemd-networkd.service: Scheduled restart job, restart counter is at 5. Mar 18 19:19:00 hostname systemd[1]: Stopped Network Service. Mar 18 19:19:00 hostname systemd[1]: systemd-networkd.service: Start request repeated too quickly. Mar 18 19:19:00 hostname systemd[1]: systemd-networkd.service: Failed with result 'core-dump'. Mar 18 19:19:00 hostname systemd[1]: Failed to start Network Service. --- Is netplan not expected to support more than 1024 addresses? Is it possible that it could be made to? Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1820771/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1815101] Re: Restarting systemd-networkd breaks keepalived clusters
** 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 notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived clusters
Status in netplan:
Invalid
Status in keepalived package in Ubuntu:
Incomplete
Status in systemd package in Ubuntu:
Triaged
Bug description:
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
group {
wan
lan
phone
}
vrrp_instance wan {
state MASTER
interface eth2
virtual_router_id 77
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass BlahBlah
}
virtual_ipaddress {
12.13.14.20
}
}
vrrp_instance lan {
state MASTER
interface eth3
virtual_router_id 78
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass MoreBlah
}
virtual_ipaddress {
10.22.11.13/24
}
}
vrrp_instance phone {
state MASTER
interface eth4
virtual_router_id 79
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass MostBlah
}
virtual_ipaddress {
10.22.14.3/24
}
}
At boot the affected interfaces have:
5: eth4: mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether ab:cd:ef:90:c0:e3 brd ff:ff:ff:ff:ff:ff
inet 10.22.14.6/24 brd 10.22.14.255 scope global eth4
valid_lft forever preferred_lft forever
inet 10.22.14.3/24 scope global secondary eth4
valid_lft forever preferred_lft forever
inet6 fe80::ae1f:6bff:fe90:c0e3/64 scope link
valid_lft forever preferred_lft forever
7: eth3: mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether ab:cd:ef:b0:26:29 brd ff:ff:ff:ff:ff:ff
inet 10.22.11.6/24 brd 10.22.11.255 scope global eth3
valid_lft forever preferred_lft forever
inet 10.22.11.13/24 scope global secondary eth3
valid_lft forever preferred_lft forever
inet6 fe80::ae1f:6bff:feb0:2629/64 scope link
valid_lft forever preferred_lft forever
9: eth2: mtu 1500 qdisc mq state UP group
default
[Touch-packages] [Bug 1820281] Re: Restarting systemd-networkd breaks keepalived clusters
*** 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 Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1820281 Title: Restarting systemd-networkd breaks keepalived clusters Status in keepalived package in Ubuntu: New Status in netplan.io package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: Hello, Managing a HA floating IP with netplan and keepalived brings trouble. Im managing a two node keepalived cluster with a floating IP. Everything works out except if i run on a the master node (which holds floating ip) "netplan apply". Prob netplan resets the whole interface, leaving keepalived in a broken state. This works without any trouble using the old iproute2 approach. Even setting, net.ipv4.conf.*.promote_secondaries does not help out. We need definitly an non strict reset option for interfaces in thise case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1820281/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1820281] Re: Restarting systemd-networkd breaks keepalived clusters
** 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: systemd (Ubuntu) Importance: Undecided => High ** Changed in: netplan.io (Ubuntu) Importance: Undecided => High ** Changed in: netplan.io (Ubuntu) Status: New => Confirmed ** Changed in: systemd (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1820281 Title: Restarting systemd-networkd breaks keepalived clusters Status in keepalived package in Ubuntu: New Status in netplan.io package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: Hello, Managing a HA floating IP with netplan and keepalived brings trouble. Im managing a two node keepalived cluster with a floating IP. Everything works out except if i run on a the master node (which holds floating ip) "netplan apply". Prob netplan resets the whole interface, leaving keepalived in a broken state. This works without any trouble using the old iproute2 approach. Even setting, net.ipv4.conf.*.promote_secondaries does not help out. We need definitly an non strict reset option for interfaces in thise case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1820281/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1815101] Re: netplan removes keepalived configuration
Kept a task for keepalived (Incomplete) in case it turns out there's
something we can do there.
Also added a task for systemd, since that would definitely require
development work.
Marked Invalid for netplan, as since netplan only translates config from
the YAML to what networkd or NetworkManager require, there isn't really
anything I see we can do in netplan directly. Applying absolutely does
need to 'poke' the renderer somehow for the configuration to be applied;
but if it turns out there's something to change in netplan we can update
the task.
Turns out there isn't really a PR about foreign addresses handling;
though two are somewhat relevant:
https://github.com/systemd/systemd/pull/9956
and
https://github.com/systemd/systemd/pull/7403
But neither will completely address the problem: systemd-networks
expects to be authoritative on the network setup, which is somewhat
counter to its use in conjunction with keepalived.
As a workaround, for now, one can use /etc/network/interfaces (and/or no
configuration in netplan for the interfaces handled by keepalived) to
configure the network.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
netplan removes keepalived configuration
Status in netplan:
Invalid
Status in keepalived package in Ubuntu:
Incomplete
Status in systemd package in Ubuntu:
Triaged
Bug description:
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
group {
wan
lan
phone
}
vrrp_instance wan {
state MASTER
interface eth2
virtual_router_id 77
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass BlahBlah
}
virtual_ipaddress {
12.13.14.20
}
}
vrrp_instance lan {
state MASTER
interface eth3
virtual_router_id 78
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass MoreBlah
}
virtual_ipaddress {
10.22.11.13/24
}
}
vrrp_instance phone {
state MASTER
interface eth4
virtual_router_id 79
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass MostBlah
}
virtual_ipaddress {
10.22.14.3/24
}
}
At boot the affected interfaces have:
5: eth4: mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether ab:cd:ef:90:c0:e3 brd
[Touch-packages] [Bug 1815101] Re: netplan removes keepalived configuration
This isn't netplan, it's systemd-networkd. Netplan only writes
configuration for the chosen renderer (in this case, systemd-networkd).
Either systemd needs to not wipe out foreign addresses (I believe there
is a PR in git for that) or keepalived should somehow interface with
systemd so they can collaborate on setting and keeping up the IP
addresses.
Reassigning.
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** Also affects: keepalived (Ubuntu)
Importance: Undecided
Status: New
** No longer affects: ubuntu
** Changed in: netplan
Status: New => Invalid
** Changed in: keepalived (Ubuntu)
Status: New => Incomplete
** Changed in: systemd (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
netplan removes keepalived configuration
Status in netplan:
Invalid
Status in keepalived package in Ubuntu:
Incomplete
Status in systemd package in Ubuntu:
Triaged
Bug description:
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
group {
wan
lan
phone
}
vrrp_instance wan {
state MASTER
interface eth2
virtual_router_id 77
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass BlahBlah
}
virtual_ipaddress {
12.13.14.20
}
}
vrrp_instance lan {
state MASTER
interface eth3
virtual_router_id 78
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass MoreBlah
}
virtual_ipaddress {
10.22.11.13/24
}
}
vrrp_instance phone {
state MASTER
interface eth4
virtual_router_id 79
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass MostBlah
}
virtual_ipaddress {
10.22.14.3/24
}
}
At boot the affected interfaces have:
5: eth4: mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether ab:cd:ef:90:c0:e3 brd ff:ff:ff:ff:ff:ff
inet 10.22.14.6/24 brd 10.22.14.255 scope global eth4
valid_lft forever preferred_lft forever
inet 10.22.14.3/24 scope global secondary eth4
valid_lft forever preferred_lft forever
inet6 fe80::ae1f:6bff:fe90:c0e3/64 scope link
valid_lft forever preferred_lft forever
7: eth3: mtu 1500 qdisc mq
[Touch-packages] [Bug 1798562] Re: After a side by side installation, resized filesystem is corrupted
:Verification-done for cosmic: ubuntu@superb-ram:~$ qemu-img convert vda1b.qcow2 vda1b.raw ubuntu@superb-ram:~$ e2fsck -f vda1b.raw e2fsck 1.44.4 (18-Aug-2018) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information vda1b.raw: 131875/786432 files (0.1% non-contiguous), 1115854/3145216 blocks ubuntu@superb-ram:~$ resize2fs vda1b.raw 6200M resize2fs 1.44.4 (18-Aug-2018) Resizing the filesystem on vda1b.raw to 1587200 (4k) blocks. The filesystem on vda1b.raw is now 1587200 (4k) blocks long. ubuntu@superb-ram:~$ e2fsck -f vda1b.raw e2fsck 1.44.4 (18-Aug-2018) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information vda1b.raw: 131875/401408 files (0.2% non-contiguous), 1089656/1587200 blocks ubuntu@superb-ram:~$ ubuntu@superb-ram:~$ ubuntu@superb-ram:~$ sudo dpkg -l e2fsprogs libext2fs2 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 Architecture Description +++-=-===-===-=== ii e2fsprogs 1.44.4-2ubuntu0.2 amd64 ext2/ext3/ext4 file system utilities ii libext2fs2:amd64 1.44.4-2ubuntu0.2 amd64 ext2/ext3/ext4 file system libraries -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1798562 Title: After a side by side installation, resized filesystem is corrupted Status in e2fsprogs package in Ubuntu: Fix Released Status in e2fsprogs source package in Bionic: Fix Committed Status in e2fsprogs source package in Cosmic: Fix Released Bug description: [Impact] - Users resizing filesystems using resize2fs. - Resizing an existing Linux filesystem from the Ubuntu installer. [Test cases] Test Case 1: With e2fsprogs 1.44.4-2: Download this file system image: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1798562/+attachment/5203159/+files/vda1b.qcow2.bz Run the following commands: bunzip2 vda1b.qcow2.bz qemu-img convert vda1b.qcow2 vda1b.raw e2fsck -f vda1b.raw resize2fs vda1b.raw 6200M e2fsck -f vda1b.raw e2fsck 1.44.4 (18-Aug-2018) Pass 1: Checking inodes, blocks, and sizes Inode 45746 extent block passes checks, but checksum does not match extent (logical block 1272, physical block 466167, len 776) Fix? Test Case 2 (Use case of the installer): 1. Perform a first installation of Ubuntu 2. Reboot into the freshly installed system and verify everything works as expected 3. Do a second installation and select "Install alonogside". Keep the size proposed by the installer and proceed to the end of installation 4. Reboot 5. On boot, in the list of installed systems, select the first system installed on the machine 6. Verify that it boots, you can login and it works as expected Actual Result The FS is corrupted and depending on the corruption it goes to initramfs, boots but cannot login, ... [Regression potential] This changes behavior in the update logic for extent blocks; as such, care should be taken to make sure that testing takes into account the possibility to introduce filesystem corruption while resizing. This is why the test cases include running e2fsck as last step. --- Attached is the journal of the system installed on the corrupted partition. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: ubiquity (not installed) ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 Uname: Linux 4.18.0-10-generic x86_64 ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Oct 18 10:53:57 2018 InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper only-ubiquity quiet splash --- InstallationDate: Installed on 2018-10-18 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) SourcePackage: ubiquity UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1798562/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1798562] Re: After a side by side installation, resized filesystem is corrupted
Verification-done for bionic using e2fsprogs 1.44.1-1ubuntu1.1: ubuntu@humble-cod:~$ qemu-img convert vda1b.qcow2 vda1b.raw ubuntu@humble-cod:~$ e2fsck -f vda1b.raw e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information vda1b.raw: 131875/786432 files (0.1% non-contiguous), 1115854/3145216 blocks ubuntu@humble-cod:~$ resize2fs vda1b.raw 6200M resize2fs 1.44.1 (24-Mar-2018) Resizing the filesystem on vda1b.raw to 1587200 (4k) blocks. The filesystem on vda1b.raw is now 1587200 (4k) blocks long. ubuntu@humble-cod:~$ e2fsck -f vda1b.raw e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information vda1b.raw: 131875/401408 files (0.2% non-contiguous), 1089656/1587200 blocks ubuntu@humble-cod:~$ dpkg -l e2fsprogs libext2fs2 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 Architecture Description +++-=-===-===-=== ii e2fsprogs 1.44.1-1ubuntu1.1 amd64 ext2/ext3/ext4 file system utilities ii libext2fs2:amd64 1.44.1-1ubuntu1.1 amd64 ext2/ext3/ext4 file system libraries ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1798562 Title: After a side by side installation, resized filesystem is corrupted Status in e2fsprogs package in Ubuntu: Fix Released Status in e2fsprogs source package in Bionic: Fix Committed Status in e2fsprogs source package in Cosmic: Fix Committed Bug description: [Impact] - Users resizing filesystems using resize2fs. - Resizing an existing Linux filesystem from the Ubuntu installer. [Test cases] Test Case 1: With e2fsprogs 1.44.4-2: Download this file system image: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1798562/+attachment/5203159/+files/vda1b.qcow2.bz Run the following commands: bunzip2 vda1b.qcow2.bz qemu-img convert vda1b.qcow2 vda1b.raw e2fsck -f vda1b.raw resize2fs vda1b.raw 6200M e2fsck -f vda1b.raw e2fsck 1.44.4 (18-Aug-2018) Pass 1: Checking inodes, blocks, and sizes Inode 45746 extent block passes checks, but checksum does not match extent (logical block 1272, physical block 466167, len 776) Fix? Test Case 2 (Use case of the installer): 1. Perform a first installation of Ubuntu 2. Reboot into the freshly installed system and verify everything works as expected 3. Do a second installation and select "Install alonogside". Keep the size proposed by the installer and proceed to the end of installation 4. Reboot 5. On boot, in the list of installed systems, select the first system installed on the machine 6. Verify that it boots, you can login and it works as expected Actual Result The FS is corrupted and depending on the corruption it goes to initramfs, boots but cannot login, ... [Regression potential] This changes behavior in the update logic for extent blocks; as such, care should be taken to make sure that testing takes into account the possibility to introduce filesystem corruption while resizing. This is why the test cases include running e2fsck as last step. --- Attached is the journal of the system installed on the corrupted partition. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: ubiquity (not installed) ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 Uname: Linux 4.18.0-10-generic x86_64 ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Oct 18 10:53:57 2018 InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper only-ubiquity quiet splash --- InstallationDate: Installed on 2018-10-18 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) SourcePackage: ubiquity UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1798562/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1798562] Re: After a side by side installation, resized filesystem is corrupted
** Also affects: e2fsprogs (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: e2fsprogs (Ubuntu Cosmic) Importance: Undecided Status: New ** Description changed: + [Impact] + - Users resizing filesystems using resize2fs. + - Resizing an existing Linux filesystem from the Ubuntu installer. + + [Test cases] + Test Case 1: With e2fsprogs 1.44.4-2: Download this file system image: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1798562/+attachment/5203159/+files/vda1b.qcow2.bz Run the following commands: bunzip2 vda1b.qcow2.bz qemu-img convert vda1b.qcow2 vda1b.raw e2fsck -f vda1b.raw resize2fs vda1b.raw 6200M e2fsck -f vda1b.raw e2fsck 1.44.4 (18-Aug-2018) Pass 1: Checking inodes, blocks, and sizes Inode 45746 extent block passes checks, but checksum does not match extent - (logical block 1272, physical block 466167, len 776) + (logical block 1272, physical block 466167, len 776) Fix? - Test Case 2 (Use case of the installer): 1. Perform a first installation of Ubuntu 2. Reboot into the freshly installed system and verify everything works as expected 3. Do a second installation and select "Install alonogside". Keep the size proposed by the installer and proceed to the end of installation 4. Reboot 5. On boot, in the list of installed systems, select the first system installed on the machine 6. Verify that it boots, you can login and it works as expected Actual Result The FS is corrupted and depending on the corruption it goes to initramfs, boots but cannot login, ... + + + [Regression potential] + This changes behavior in the update logic for extent blocks; as such, care should be taken to make sure that testing takes into account the possibility to introduce filesystem corruption while resizing. This is why the test cases include running e2fsck as last step. + + + --- Attached is the journal of the system installed on the corrupted partition. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: ubiquity (not installed) ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 Uname: Linux 4.18.0-10-generic x86_64 ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Oct 18 10:53:57 2018 InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper only-ubiquity quiet splash --- InstallationDate: Installed on 2018-10-18 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) SourcePackage: ubiquity UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1798562 Title: After a side by side installation, resized filesystem is corrupted Status in e2fsprogs package in Ubuntu: Fix Released Status in e2fsprogs source package in Bionic: New Status in e2fsprogs source package in Cosmic: New Bug description: [Impact] - Users resizing filesystems using resize2fs. - Resizing an existing Linux filesystem from the Ubuntu installer. [Test cases] Test Case 1: With e2fsprogs 1.44.4-2: Download this file system image: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1798562/+attachment/5203159/+files/vda1b.qcow2.bz Run the following commands: bunzip2 vda1b.qcow2.bz qemu-img convert vda1b.qcow2 vda1b.raw e2fsck -f vda1b.raw resize2fs vda1b.raw 6200M e2fsck -f vda1b.raw e2fsck 1.44.4 (18-Aug-2018) Pass 1: Checking inodes, blocks, and sizes Inode 45746 extent block passes checks, but checksum does not match extent (logical block 1272, physical block 466167, len 776) Fix? Test Case 2 (Use case of the installer): 1. Perform a first installation of Ubuntu 2. Reboot into the freshly installed system and verify everything works as expected 3. Do a second installation and select "Install alonogside". Keep the size proposed by the installer and proceed to the end of installation 4. Reboot 5. On boot, in the list of installed systems, select the first system installed on the machine 6. Verify that it boots, you can login and it works as expected Actual Result The FS is corrupted and depending on the corruption it goes to initramfs, boots but cannot login, ... [Regression potential] This changes behavior in the update logic for extent blocks; as such, care should be taken to make sure that testing takes into account the possibility to introduce filesystem corruption while resizing. This is why the test cases include running e2fsck as last step. --- Attached is the journal of the system installed on the corrupted partition. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: ubiquity (not installed) ProcVersionSignature: Ubuntu 4.18.0-10.11-generic
[Touch-packages] [Bug 1806272] Re: resize2fs results in ext4 filesystem with warning/errors
*** This bug is a duplicate of bug 1798562 *** https://bugs.launchpad.net/bugs/1798562 ** This bug has been marked a duplicate of bug 1798562 After a side by side installation, resized filesystem is corrupted -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1806272 Title: resize2fs results in ext4 filesystem with warning/errors Status in e2fsprogs package in Ubuntu: New Bug description: Resized (downsized) an offline ext4 filesystem on LVM. Before resizing, I confirmed filesystem was clean with e2fsck. After resizing, several warnings/errors were found. Tried first with version 1.44.1 from Ubuntu 18.04.1 LTS. Then I compiled the 1.44.4 source, but the error was still present. Using ESXi 6.7 and starts with a fresh copy of the filesystem before each run. root@vedlikehold:~# e2fsck -f /dev/skole-vg/root e2fsck 1.44.4 (18-Aug-2018) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/skole-vg/root: 139206/8331264 files (0.2% non-contiguous), 3274416/33294336 blocks root@vedlikehold:~# resize2fs -P /dev/skole-vg/root resize2fs 1.44.4 (18-Aug-2018) Estimated minimum size of the filesystem: 3337578 root@vedlikehold:~# lvresize --resizefs -l 11776 /dev/skole-vg/root fsck from util-linux 2.31.1 /dev/mapper/skole--vg-root: clean, 139206/8331264 files, 3274416/33294336 blocks resize2fs 1.44.4 (18-Aug-2018) Resizing the filesystem on /dev/mapper/skole--vg-root to 12058624 (4k) blocks. The filesystem on /dev/mapper/skole--vg-root is now 12058624 (4k) blocks long. Size of logical volume skole-vg/root changed from <127.01 GiB (32514 extents) to 46.00 GiB (11776 extents). Logical volume skole-vg/root successfully resized. root@vedlikehold:~# e2fsck -f /dev/skole-vg/root e2fsck 1.44.4 (18-Aug-2018) Pass 1: Checking inodes, blocks, and sizes Inode 8 extent tree (at level 1) could be narrower. Fix? yes Inode 44075 extent block passes checks, but checksum does not match extent (logical block 10240, physical block 421888, len 8691) Fix? yes Inode 44083 extent block passes checks, but checksum does not match extent (logical block 51200, physical block 3414016, len 10293) Fix? yes Inode 44087 extent block passes checks, but checksum does not match extent (logical block 34816, physical block 3444736, len 574) Fix? yes Inode 44091 extent block passes checks, but checksum does not match extent (logical block 28672, physical block 4087808, len 7804) Fix? yes Inode 44093 extent block passes checks, but checksum does not match extent (logical block 26624, physical block 4030464, len 351) Fix? yes Inode 44106 extent block passes checks, but checksum does not match extent (logical block 49152, physical block 1308672, len 8370) Fix? yes Inode 44112 extent block passes checks, but checksum does not match extent (logical block 69632, physical block 1607680, len 16969) Fix? yes Inode 44116 extent block passes checks, but checksum does not match extent (logical block 2848, physical block 7861156, len 178) Fix? yes Inode 44117 extent block passes checks, but checksum does not match extent (logical block 1592, physical block 7862368, len 98) Fix? yes Inode 44119 extent block passes checks, but checksum does not match extent (logical block 2150, physical block 15663, len 134) Fix? yes Inode 44120 extent block passes checks, but checksum does not match extent (logical block 24934, physical block 5329460, len 1014) Fix? yes Inode 44122 extent block passes checks, but checksum does not match extent (logical block 734, physical block 3257320, len 44) Fix? yes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/skole-vg/root: 139206/3014656 files (0.2% non-contiguous), 2938632/12058624 blocks root@vedlikehold:~# To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1806272/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1805027] Re: systemd-resolved can't resolve Comcast mail server addresses
Setting to Triaged: it's easily reproduced by developers, and we have all the information we need to debug it -- nothing is secret or hidden, just needs someone to look at the packets and what resolved does with them. ** Changed in: systemd (Ubuntu) Status: Confirmed => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1805027 Title: systemd-resolved can't resolve Comcast mail server addresses Status in systemd package in Ubuntu: Triaged Bug description: 1) Ubuntu release: 18.10 2) systemd-resolved version: (Default latest version that comes with Ubuntu 18.10) 3) Expected behavior: Comcast's POP3 mail server addresses to be resolved to IP addresses 4) Actual behavior: Comcast's POP3 mail server addresses can't be resolved to IP addresses Starting on Monday, November 19, 2018, Comcast made a DNS change related to its POP3 mail servers (mail.comcast.net and pop3.comcast.net) that prevent resolved from being able to resolve those domains into IP addresses. When I try to ping either host (mail.comcast.net or pop2.comcast.net), I get this error: tom@deathstar:~$ ping mail.comcast.net ping: mail.comcast.net: Name or service not known tom@deathstar:~$ When I manually lookup up the domain, I get these results: tom@deathstar:~$ nslookup mail.comcast.net Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: mail.comcast.net canonical name = imap.ge.xfinity.com. Name: imap.ge.xfinity.com Address: 96.118.242.209 Name: imap.ge.xfinity.com Address: 96.118.242.197 Name: imap.ge.xfinity.com Address: 96.118.242.233 Name: imap.ge.xfinity.com Address: 96.118.242.225 Name: imap.ge.xfinity.com Address: 96.118.242.226 Name: imap.ge.xfinity.com Address: 96.118.242.217 Name: imap.ge.xfinity.com Address: 96.118.242.208 Name: imap.ge.xfinity.com Address: 96.118.242.230 Name: imap.ge.xfinity.com Address: 96.118.242.232 Name: imap.ge.xfinity.com Address: 96.118.242.218 Name: imap.ge.xfinity.com Address: 96.118.242.211 Name: imap.ge.xfinity.com Address: 96.118.242.242 Name: imap.ge.xfinity.com Address: 96.118.242.221 Name: imap.ge.xfinity.com Address: 96.118.242.196 Name: imap.ge.xfinity.com Address: 96.118.208.40 Name: imap.ge.xfinity.com Address: 96.118.208.99 Name: imap.ge.xfinity.com Address: 2001:558:fc11:9:f816:3eff:fee8:4f07 Name: imap.ge.xfinity.com Address: 2001:558:fc11:9:f816:3eff:fe7d:1b0c Name: imap.ge.xfinity.com Address: 2001:558:fc11:9:f816:3eff:fe25:5ae5 Name: imap.ge.xfinity.com Address: 2001:558:fc11:9:f816:3eff:fef6:babc Name: imap.ge.xfinity.com Address: 2001:558:fc11:9:f816:3eff:fe87:c172 Name: imap.ge.xfinity.com Address: 2001:558:fc11:9:f816:3eff:fee6:7a57 Name: imap.ge.xfinity.com Address: 2001:558:fc11:9:f816:3eff:fe0f:a4a Name: imap.ge.xfinity.com Address: 2001:558:fc11:2:f816:3eff:fec7:cb93 Name: imap.ge.xfinity.com Address: 2001:558:fee2:1000:f816:3eff:fe42:4f14 Name: imap.ge.xfinity.com Address: 2001:558:fc18:0:f816:3eff:fe33:9aaa Name: imap.ge.xfinity.com Address: 2001:558:fc18:0:f816:3eff:feb2:8c0d Name: imap.ge.xfinity.com Address: 2001:558:fc18:0:f816:3eff:fef1:25a5 Name: imap.ge.xfinity.com Address: 2001:558:fc18:0:f816:3eff:febd:320a Name: imap.ge.xfinity.com Address: 2001:558:fc18:0:f816:3eff:fe36:aba3 Name: imap.ge.xfinity.com Address: 2001:558:fc18:0:f816:3eff:fe3f:76f2 Name: imap.ge.xfinity.com Address: 2001:558:fc18:0:f816:3eff:fe45:1d1e tom@deathstar:~$ dig mail.comcast.net ; <<>> DiG 9.11.4-3ubuntu5-Ubuntu <<>> mail.comcast.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15037 ;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;mail.comcast.net.IN A ;; ANSWER SECTION: mail.comcast.net. 15 IN CNAME imap.ge.xfinity.com. imap.ge.xfinity.com. 12 IN A 96.117.3.119 imap.ge.xfinity.com. 12 IN A 96.117.3.96 imap.ge.xfinity.com. 12 IN A 96.117.3.143 imap.ge.xfinity.com. 12 IN A 96.117.3.145 imap.ge.xfinity.com. 12 IN A 96.117.3.129 imap.ge.xfinity.com. 12 IN A 96.117.3.148 imap.ge.xfinity.com. 12 IN A 96.117.3.201 imap.ge.xfinity.com. 12 IN A 96.117.3.136 imap.ge.xfinity.com. 12 IN A 96.118.133.238 imap.ge.xfinity.com. 12 IN A 96.117.3.128 imap.ge.xfinity.com. 12 IN A 96.117.3.144 imap.ge.xfinity.com. 12 IN A 96.117.2.238 imap.ge.xfinity.com. 12 IN A 96.117.3.110 imap.ge.xfinity.com. 12 IN
[Touch-packages] [Bug 1784347] Re: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath
Please help to validate this SRU. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1784347 Title: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath Status in The Ubuntu-power-systems project: Fix Committed Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Bionic: Incomplete Bug description: [Impact] Any user of Ubuntu on multipath, where the default path separator has been changed to something else. This possibly affects other scenarios where the partition separator can be changed. [Test case] 1) Install Ubuntu on multipath system 2) Change /etc/multipath.conf to set "path_separator" to "" or "p". 3) Reboot 4) Run 'sudo fdisk -l /dev/mapper/mpathX', to display a device's partitions where the path separator would be visible. [Regression potential] Minimal. This only affects display. Default separator on Ubuntu remains "-part". If the separator is not one of "", "p", or "-part", then "-part" would be used, as is already the case. == Comment: #0 - Chanh H. Nguyen - 2018-01-09 11:14:07 == We have the Ubuntu1804 installed on our BostonLC system. Create a SAN via the Emulex adapter to have the mpath disk. Running the fdisk -l and ls -l showing the conflict name for the mpath. :~# uname -a Linux boslcp4 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:03:08 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux root@boslcp4:~# cat /etc/os-release NAME="Ubuntu" VERSION="18.04 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu Bionic Beaver (development branch)" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part1 2048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 1258291199 419428352 200G 83 Linux :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:04 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha3 -> ../dm-3 == Comment: #2 - Chanh H. Nguyen - 2018-01-09 11:35:04 == I just modify the partitions and it is still showing the conflicting name on partitions. :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha3 -> ../dm-3 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha4 -> ../dm-4 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha5 -> ../dm-5 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha6 -> ../dm-6 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha7 -> ../dm-7 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha8 -> ../dm-8 :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part12048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 964691967 125829120 60G 83 Linux /dev/mapper/mpatha-part4 964691968 1258291199 293599232 140G 5 Extended /dev/mapper/mpatha-part5 964694016 1006637055 41943040 20G 83 Linux /dev/mapper/mpatha-part6 1006639104 1048582143 41943040 20G 83 Linux /dev/mapper/mpatha-part7 1048584192 1090527231 41943040 20G 83 Linux /dev/mapper/mpatha-part8 1090529280 1132472319 41943040 20G 83 Linux == Comment: #5 - Kyle Mahlkuch - 2018-06-26 13:50:12 == I have created and submitted a patch that should help with this bug. I will
[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
Resetting the tags to verification-done as per the discussion above.
** 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 are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Fix Released
Status in cloud-init package in Ubuntu:
Confirmed
Status in netplan.io package in Ubuntu:
Fix Released
Status in nplan package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Confirmed
Status in nplan source package in Xenial:
Fix Released
Status in netplan.io source package in Bionic:
Fix Committed
Status in netplan.io source package in Cosmic:
Fix Committed
Bug description:
[Impact]
Systems relying on renaming network interfaces at boot and when 'netplan
apply' is run.
[Test case]
- Write a new netplan YAML (adjusting for current system as necessary):
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: myif0
- Bring down interface : 'ip link set dev ens3 down'
- Run 'netplan apply'
- Verify that the device is correctly renamed to 'myif0'.
- Reboot.
- Make sure the device is correctly renamed to 'myif0'.
[Regression potential]
Changes in rename logic to add udev rules may otherwise impact applying
different settings to the network interfaces. Changes in settings on network
interfaces, missing parameters (especially on bonds, bridges) should be
investigated as potential regressions. Other failures to apply network settings
might also happen if there's a race between applying renames via the udev
rules, and using the new names to apply configuration changes to the interfaces.
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
@Marcos:
Please file a new bug for your own issue; include the output of
'networkctl', and report the bug number here so we can find it.
>From a quick look, I think there's no carrier detected. This could be a
driver bug.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Fix Released
Status in cloud-init package in Ubuntu:
Confirmed
Status in netplan.io package in Ubuntu:
Fix Released
Status in nplan package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Confirmed
Status in nplan source package in Xenial:
Fix Released
Status in netplan.io source package in Bionic:
Fix Committed
Status in netplan.io source package in Cosmic:
Fix Committed
Bug description:
[Impact]
Systems relying on renaming network interfaces at boot and when 'netplan
apply' is run.
[Test case]
- Write a new netplan YAML (adjusting for current system as necessary):
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: myif0
- Bring down interface : 'ip link set dev ens3 down'
- Run 'netplan apply'
- Verify that the device is correctly renamed to 'myif0'.
- Reboot.
- Make sure the device is correctly renamed to 'myif0'.
[Regression potential]
Changes in rename logic to add udev rules may otherwise impact applying
different settings to the network interfaces. Changes in settings on network
interfaces, missing parameters (especially on bonds, bridges) should be
investigated as potential regressions. Other failures to apply network settings
might also happen if there's a race between applying renames via the udev
rules, and using the new names to apply configuration changes to the interfaces.
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
Please use bug 1768827 to track such "no IP at boot" issues; there's
nothing that currently indicates that this is a regression, it needs
further investigation, but not here.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Fix Released
Status in cloud-init package in Ubuntu:
Confirmed
Status in netplan.io package in Ubuntu:
Fix Released
Status in nplan package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Confirmed
Status in nplan source package in Xenial:
Fix Released
Status in netplan.io source package in Bionic:
Fix Committed
Status in netplan.io source package in Cosmic:
Fix Committed
Bug description:
[Impact]
Systems relying on renaming network interfaces at boot and when 'netplan
apply' is run.
[Test case]
- Write a new netplan YAML (adjusting for current system as necessary):
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: myif0
- Bring down interface : 'ip link set dev ens3 down'
- Run 'netplan apply'
- Verify that the device is correctly renamed to 'myif0'.
- Reboot.
- Make sure the device is correctly renamed to 'myif0'.
[Regression potential]
Changes in rename logic to add udev rules may otherwise impact applying
different settings to the network interfaces. Changes in settings on network
interfaces, missing parameters (especially on bonds, bridges) should be
investigated as potential regressions. Other failures to apply network settings
might also happen if there's a race between applying renames via the udev
rules, and using the new names to apply configuration changes to the interfaces.
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
Yes, that's because it doesn't appear like the issues you have are a
regression caused by the updates, and we don't know what's wrong. You
have a bug open for your issue, and we still need to figure out what
doesn't work there.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Fix Released
Status in cloud-init package in Ubuntu:
Confirmed
Status in netplan.io package in Ubuntu:
Fix Released
Status in nplan package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Confirmed
Status in nplan source package in Xenial:
Fix Released
Status in netplan.io source package in Bionic:
Fix Committed
Status in netplan.io source package in Cosmic:
Fix Committed
Bug description:
[Impact]
Systems relying on renaming network interfaces at boot and when 'netplan
apply' is run.
[Test case]
- Write a new netplan YAML (adjusting for current system as necessary):
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: myif0
- Bring down interface : 'ip link set dev ens3 down'
- Run 'netplan apply'
- Verify that the device is correctly renamed to 'myif0'.
- Reboot.
- Make sure the device is correctly renamed to 'myif0'.
[Regression potential]
Changes in rename logic to add udev rules may otherwise impact applying
different settings to the network interfaces. Changes in settings on network
interfaces, missing parameters (especially on bonds, bridges) should be
investigated as potential regressions. Other failures to apply network settings
might also happen if there's a race between applying renames via the udev
rules, and using the new names to apply configuration changes to the interfaces.
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope
[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
Verification-done on bionic with netplan.io 0.40.1~18.04.2: Using the following config: network: version: 2 ethernets: maas0: addresses: - 10.3.21.29/20 gateway4: 10.3.16.1 match: macaddress: 52:54:00:4d:3e:84 mtu: 1500 set-name: maas0 The interface renaming is correctly done at boot time; then changing set-name to 'maas1', bringing down the interface with 'ip link set dev maas0 down', and running 'netplan apply'; the interface is correctly renamed: ubuntu@nice-baboon:~$ sudo vi /etc/netplan/50-cloud-init.yaml ubuntu@nice-baboon:~$ sudo netplan apply ubuntu@nice-baboon:~$ ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: maas0: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:4d:3e:84 brd ff:ff:ff:ff:ff:ff inet 10.3.21.29/20 brd 10.3.31.255 scope global maas0 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe4d:3e84/64 scope link valid_lft forever preferred_lft forever ubuntu@nice-baboon:~$ ubuntu@nice-baboon:~$ sudo vi /etc/netplan/50-cloud-init.yaml ubuntu@nice-baboon:~$ ip link set dev maas0 down RTNETLINK answers: Operation not permitted ubuntu@nice-baboon:~$ sudo !! sudo ip link set dev maas0 down ubuntu@nice-baboon:~$ ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: maas0: mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether 52:54:00:4d:3e:84 brd ff:ff:ff:ff:ff:ff inet 10.3.21.29/20 brd 10.3.31.255 scope global maas0 valid_lft forever preferred_lft forever ubuntu@nice-baboon:~$ sudo netplan apply ubuntu@nice-baboon:~$ ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: maas1: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:4d:3e:84 brd ff:ff:ff:ff:ff:ff inet 10.3.21.29/20 brd 10.3.31.255 scope global maas1 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe4d:3e84/64 scope link valid_lft forever preferred_lft forever ** Tags removed: verification-failed-bionic verification-needed ** Tags added: verification-done-bionic ** Tags removed: verification-done-xenial verification-needed-cosmic ** Tags added: verification-needed-xenial ** Tags removed: verification-needed-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1770082 Title: systemd-networkd not renaming devices on boot Status in netplan: Fix Released Status in cloud-init package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: Fix Released Status in nplan package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in nplan source package in Xenial: Fix Released Status in netplan.io source package in Bionic: Fix Committed Status in netplan.io source package in Cosmic: Fix Committed Bug description: [Impact] Systems relying on renaming network interfaces at boot and when 'netplan apply' is run. [Test case] - Write a new netplan YAML (adjusting for current system as necessary): network: version: 2 ethernets: ens3: dhcp4: true match: macaddress: 52:54:00:de:bd:f6 set-name: myif0 - Bring down interface : 'ip link set dev ens3 down' - Run 'netplan apply' - Verify that the device is correctly renamed to 'myif0'. - Reboot. - Make sure the device is correctly renamed to 'myif0'. [Regression potential] Changes in rename logic to add udev rules may otherwise impact applying different settings to the network interfaces. Changes in settings on network interfaces, missing parameters (especially on bonds, bridges) should be investigated as potential regressions. Other failures to apply network settings might also happen if there's a race between applying renames via the udev rules, and using the new names to apply configuration changes to the interfaces. === systemd issue === Renaming devices doesn't seem to work. If I disable all other network configuration and create /etc/systemd/network/10-network.link with: [Match]
[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
Verification-done for cosmic using netplan.io 0.40.2.1:
I have verified that renames happen correctly with the config provided
in test cases and the config I have shown for the testing on bionic.
In all cases, set-name is applied as the new name for the interface, as
expected. On reboot, this is sufficient for the interface to be renamed.
After boot, the interface must first be brought down before it can be
renamed (this is expected behavior, renaming does not work on a busy
interface).
** Tags added: verification-done-cosmic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Fix Released
Status in cloud-init package in Ubuntu:
Confirmed
Status in netplan.io package in Ubuntu:
Fix Released
Status in nplan package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Confirmed
Status in nplan source package in Xenial:
Fix Released
Status in netplan.io source package in Bionic:
Fix Committed
Status in netplan.io source package in Cosmic:
Fix Committed
Bug description:
[Impact]
Systems relying on renaming network interfaces at boot and when 'netplan
apply' is run.
[Test case]
- Write a new netplan YAML (adjusting for current system as necessary):
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: myif0
- Bring down interface : 'ip link set dev ens3 down'
- Run 'netplan apply'
- Verify that the device is correctly renamed to 'myif0'.
- Reboot.
- Make sure the device is correctly renamed to 'myif0'.
[Regression potential]
Changes in rename logic to add udev rules may otherwise impact applying
different settings to the network interfaces. Changes in settings on network
interfaces, missing parameters (especially on bonds, bridges) should be
investigated as potential regressions. Other failures to apply network settings
might also happen if there's a race between applying renames via the udev
rules, and using the new names to apply configuration changes to the interfaces.
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed
to myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it
also works if I unbind the device and rebind it as netplan apply does.
No setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the
device will be called myiface3 and brought up fine with dhcp. However,
instead I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
** Description changed:
[Impact]
Systems relying on renaming network interfaces at boot and when 'netplan
apply' is run.
[Test case]
- Write a new netplan YAML (adjusting for current system as necessary):
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: myif0
-
+ - Bring down interface : 'ip link set dev ens3 down'
- Run 'netplan apply'
- Verify that the device is correctly renamed to 'myif0'.
- Reboot.
- Make sure the device is correctly renamed to 'myif0'.
[Regression potential]
Changes in rename logic to add udev rules may otherwise impact applying
different settings to the network interfaces. Changes in settings on network
interfaces, missing parameters (especially on bonds, bridges) should be
investigated as potential regressions. Other failures to apply network settings
might also happen if there's a race between applying renames via the udev
rules, and using the new names to apply configuration changes to the interfaces.
=== systemd issue ===
Renaming devices doesn't seem to work.
If I disable all other network configuration and create
/etc/systemd/network/10-network.link with:
[Match]
MACAddress=52:54:00:c1:c9:bb
[Link]
Name=myiface3
I expect this to cause the device with that MAC address to be renamed to
myiface3. However, when I reboot, I instead see:
$ ip l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
The device is not renamed.
This link file is pretty much identical to Example 2 in
https://www.freedesktop.org/software/systemd/man/systemd.link.html.
The renaming does work if I boot with net.ifnames=0, and oddly, it also
works if I unbind the device and rebind it as netplan apply does. No
setting of NamePolicy seems to help.
=== Original Bug ==
'set-name:' doesn't change the name of a network interface on boot, it
only works when you do netplan apply.
Say I take this 50-cloud-init.yaml file:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:de:bd:f6
set-name: ens3
Say I change set-name to 'myiface3' and reboot. I expect that the device
will be called myiface3 and brought up fine with dhcp. However, instead
I see:
$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
The name has not been changed, and the device has not been brought up.
If I run netplan apply however, I see the following:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: myiface3: mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
valid_lft 3575sec preferred_lft 3575sec
inet6 fe80::5054:ff:fede:bdf6/64 scope link
valid_lft forever preferred_lft forever
So names are successfully changed with netplan apply.
This seems to be some udev-related timing or priority issue that I'm
still trying to hunt down.
This breaks some forms of migration in certain cloud environments.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1770082
Title:
systemd-networkd not renaming devices on boot
Status in netplan:
Fix Released
Status in cloud-init package in Ubuntu:
Confirmed
Status in netplan.io package in Ubuntu:
Fix Released
Status in nplan package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Confirmed
Status in nplan source package in Xenial:
Fix Released
Status in
[Touch-packages] [Bug 1778946] Re: No dns resolution after closing a vpn/pptp connection
cp -a is supposed to preserve ownership. -a means "-dR --preserve=all". Could someone look at what happens, by displaying more than just the /run/systemd/resolve/stub-resolv.conf file? All files in /run/systemd/resolve/ are relevant here. This has more smells of being affected my UMASK and probably other settings, otherwise it wouldn't be a perm 600 file. Nevertheless, running usepeerdns is wrong in all cases, especially with NetworkManager. That file probably should go; replaced by something that will use systemd-resolved's interfaces instead if they are available, and definitely never runs when NetworkManager is running. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1778946 Title: No dns resolution after closing a vpn/pptp connection Status in network-manager package in Ubuntu: Confirmed Status in ppp package in Ubuntu: New Status in resolvconf package in Ubuntu: New Bug description: step to reproduce set a VPN connection configured to connect a Microsoft vpn server (pptp) internet acces is ok enable the vpn connection using the applet on the top right corner of the desktop internet still ok ping works disable the vpn connection ping doesn't works with a host but works if i specify an ip address ping: xx.net: Nom ou service inconnu As a workaround, i disable the ethernet link and re-enable it name resolution is now ok ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: network-manager 1.10.6-2ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Jun 27 18:09:30 2018 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2014-06-03 (1484 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) IpRoute: default via 192.168.0.254 dev eth0 proto dhcp metric 20100 169.254.0.0/16 dev eth0 scope link metric 1000 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.47 metric 100 IwConfig: lono wireless extensions. eth0 no wireless extensions. NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true RfKill: SourcePackage: network-manager UpgradeStatus: Upgraded to bionic on 2018-05-10 (48 days ago) nmcli-dev: DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH eth0ethernet connected /org/freedesktop/NetworkManager/Devices/2 Connexion filaire 1 94806bba-1c68-46b6-87f4-a3aff6dd /org/freedesktop/NetworkManager/ActiveConnection/6 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/1 -- ---- nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.10.6 connected (site only) started limited enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1778946/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1800055] Re: iwd does not work with network manager
Oh, I know you didn't. It was a comment about Will's suggestion on his bug (I marked duplicate of this one). FWIW, I'm all for changing the default if testing shows there's a benefit, and my suggestion was that if we're to do it, do it sooner rather than later; but it *does* require concerted, planned testing, and a risk analysis... and probably carrying the patches for TLS EAP methods. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1800055 Title: iwd does not work with network manager Status in network-manager package in Ubuntu: Confirmed Bug description: I configured network manager to use iwd, unfortunately it doesn't work: Oct 25 15:12:23 malefic NetworkManager[17004]: [1540501943.4358] device (wlp4s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external') Oct 25 15:12:23 malefic NetworkManager[17004]: g_variant_get_type: assertion 'value != NULL' failed Oct 25 15:12:23 malefic NetworkManager[17004]: g_variant_type_is_subtype_of: assertion 'g_variant_type_check (type)' failed Oct 25 15:12:23 malefic NetworkManager[17004]: g_variant_get_boolean: assertion 'g_variant_is_of_type (value, G_VARIANT_TYPE_BOOLEAN)' failed Oct 25 15:12:23 malefic NetworkManager[17004]: g_variant_unref: assertion 'value != NULL' failed Oct 25 15:12:23 malefic NetworkManager[17004]: g_variant_get_string: assertion 'value != NULL' failed Oct 25 15:12:23 malefic NetworkManager[17004]: [1540501943.7492] device (wlp4s0): new IWD device state is (null) Oct 25 15:12:23 malefic NetworkManager[17004]: [1540501943.7492] device (wlp4s0): State (null) unknown Oct 25 15:12:23 malefic NetworkManager[17004]: g_variant_unref: assertion 'value != NULL' failed Oct 25 15:12:23 malefic NetworkManager[17004]: g_dbus_proxy_call_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed Oct 25 15:12:23 malefic NetworkManager[17004]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1800055/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1800055] Re: iwd does not work with network manager
AFAIK at the moment there isn't proper WPA Enterprise support (well, most TLS methods appears to be missing kernel patches). Let's please be careful about changing the default wireless daemon to iwd, there's a couple of moving parts there, it's not just about changing the software. For instance, iwd's design makes me expect that some hardware will no longer be supported unless it is fully ported to using netlink rather than ioctls (hopefully I am wrong about this). That's not a problem for Intel-based wireless, but AIUI there are still lots of other drivers in the wild. My 0.02$: if we want to change from wpasupplicant to iwd, let's make sure we have everything in place as early as possible (kernel patches), and let's do some careful regression testing on a variety of hardware so we can try to catch issues before they happen. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1800055 Title: iwd does not work with network manager Status in network-manager package in Ubuntu: Confirmed Bug description: I configured network manager to use iwd, unfortunately it doesn't work: Oct 25 15:12:23 malefic NetworkManager[17004]: [1540501943.4358] device (wlp4s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external') Oct 25 15:12:23 malefic NetworkManager[17004]: g_variant_get_type: assertion 'value != NULL' failed Oct 25 15:12:23 malefic NetworkManager[17004]: g_variant_type_is_subtype_of: assertion 'g_variant_type_check (type)' failed Oct 25 15:12:23 malefic NetworkManager[17004]: g_variant_get_boolean: assertion 'g_variant_is_of_type (value, G_VARIANT_TYPE_BOOLEAN)' failed Oct 25 15:12:23 malefic NetworkManager[17004]: g_variant_unref: assertion 'value != NULL' failed Oct 25 15:12:23 malefic NetworkManager[17004]: g_variant_get_string: assertion 'value != NULL' failed Oct 25 15:12:23 malefic NetworkManager[17004]: [1540501943.7492] device (wlp4s0): new IWD device state is (null) Oct 25 15:12:23 malefic NetworkManager[17004]: [1540501943.7492] device (wlp4s0): State (null) unknown Oct 25 15:12:23 malefic NetworkManager[17004]: g_variant_unref: assertion 'value != NULL' failed Oct 25 15:12:23 malefic NetworkManager[17004]: g_dbus_proxy_call_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed Oct 25 15:12:23 malefic NetworkManager[17004]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1800055/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1800171] Re: n-m doesn't support iwd as a backend
*** This bug is a duplicate of bug 1800055 *** https://bugs.launchpad.net/bugs/1800055 Marking as a duplicate to bug 1800055 ** This bug has been marked a duplicate of bug 1800055 iwd does not work with network manager -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1800171 Title: n-m doesn't support iwd as a backend Status in network-manager package in Ubuntu: New Bug description: iwd is an alternative to wpa_supplicant. It can be enabled as backend for n-m at run time, but n-m needs to be built with support for it. iwd is in universe in Cosmic. It would be good to get this switched on for DD so that we can test and think about making it the default for EE before the next LTS. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1800171/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1784347] Re: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath
Hi Kyle, Can you help with verifying the that patch works as expected on 18.04? Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1784347 Title: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath Status in The Ubuntu-power-systems project: Fix Committed Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Bionic: Fix Committed Bug description: [Impact] Any user of Ubuntu on multipath, where the default path separator has been changed to something else. This possibly affects other scenarios where the partition separator can be changed. [Test case] 1) Install Ubuntu on multipath system 2) Change /etc/multipath.conf to set "path_separator" to "" or "p". 3) Reboot 4) Run 'sudo fdisk -l /dev/mapper/mpathX', to display a device's partitions where the path separator would be visible. [Regression potential] Minimal. This only affects display. Default separator on Ubuntu remains "-part". If the separator is not one of "", "p", or "-part", then "-part" would be used, as is already the case. == Comment: #0 - Chanh H. Nguyen - 2018-01-09 11:14:07 == We have the Ubuntu1804 installed on our BostonLC system. Create a SAN via the Emulex adapter to have the mpath disk. Running the fdisk -l and ls -l showing the conflict name for the mpath. :~# uname -a Linux boslcp4 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:03:08 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux root@boslcp4:~# cat /etc/os-release NAME="Ubuntu" VERSION="18.04 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu Bionic Beaver (development branch)" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part1 2048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 1258291199 419428352 200G 83 Linux :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:04 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha3 -> ../dm-3 == Comment: #2 - Chanh H. Nguyen - 2018-01-09 11:35:04 == I just modify the partitions and it is still showing the conflicting name on partitions. :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha3 -> ../dm-3 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha4 -> ../dm-4 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha5 -> ../dm-5 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha6 -> ../dm-6 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha7 -> ../dm-7 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha8 -> ../dm-8 :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part12048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 964691967 125829120 60G 83 Linux /dev/mapper/mpatha-part4 964691968 1258291199 293599232 140G 5 Extended /dev/mapper/mpatha-part5 964694016 1006637055 41943040 20G 83 Linux /dev/mapper/mpatha-part6 1006639104 1048582143 41943040 20G 83 Linux /dev/mapper/mpatha-part7 1048584192 1090527231 41943040 20G 83 Linux /dev/mapper/mpatha-part8 1090529280 1132472319 41943040 20G 83 Linux == Comment: #5 - Kyle Mahlkuch - 2018-06-26 13:50:12 == I have created and
[Touch-packages] [Bug 1788659] Re: network manager assigns ethernet default route metric of 20100
Whether it's been running for 30 minutes or not doesn't change much though; the connection *can* fail, and the connectivity checking is a pretty simple HTTP check. Could you please attach debug logs for NetworkManager (with the connectivity checking enabled) -- see https://wiki.gnome.org/Projects/NetworkManager/Debugging#Other_NetworkManager_Debugging. Better yet, please file this bug upstream with NetworkManager developers at https://bugzilla.gnome.org/page.cgi?id=browse.html=NetworkManager to describe the issue, and see if there's anything they can do to improve the situation. Thanks! ** Changed in: network-manager (Ubuntu) Status: Incomplete => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1788659 Title: network manager assigns ethernet default route metric of 20100 Status in network-manager package in Ubuntu: Triaged Bug description: After upgrading from 16.04 to 18.04, when I boot with an ethernet cable connected, Ubuntu prefers to use the wifi interface over the ethernet interface. Wifi is assigned the normal metric of 600 for both of its routing table entries. However ethernet is assigned a metric of 20100. I edited the connection details via nmcli to manually set the ethernet metric to 100. After a reboot, the link route (for the LAN subnet) correctly has a metric of 100. But the default route for eth0 is still 20100. nm-applet shows the wifi icon, correctly indicating that the default route is over wifi rather than ethernet. The only fix is to manually set the route after every reboot, or turn off wifi. This is a regression from 16.04. network-manager 1.10.6-2ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1788659/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1690933] Re: isc-dhcp-server/dhcpd listens on 0.0.0.0:67/UDP no matter which interfaces is specified
No, this is dnsmasq: udp 0 0 0.0.0.0:67 0.0.0.0:* 5382/dnsmasq Please make sure you dnsmasq is correctly configured for your use case (and probably, not configured at all if you want to use isc-dhcp) ** Changed in: isc-dhcp (Ubuntu) Status: Confirmed => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1690933 Title: isc-dhcp-server/dhcpd listens on 0.0.0.0:67/UDP no matter which interfaces is specified Status in isc-dhcp package in Ubuntu: Incomplete Bug description: The behaviour of the `systemd` unit `isc-dhcp-server.service` is the same as on the command line: both `sudo dhcpd` and `sudo dhcpd p18p1` (where `p18p1` is the name of a network interfaces) cause the daemon to listen on all interfaces according to `sudo netstat -tupln | grep :67`: udp0 0 0.0.0.0:67 0.0.0.0:* 5382/dnsmasq The `isc-dhcp-server6.service` unit is deactivated. ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: isc-dhcp-server 4.3.5-3ubuntu1 ProcVersionSignature: Ubuntu 4.10.0-20.22-generic 4.10.8 Uname: Linux 4.10.0-20-generic x86_64 NonfreeKernelModules: zfs zunicode zavl zcommon znvpair ApportVersion: 2.20.4-0ubuntu4 Architecture: amd64 Date: Mon May 15 23:41:54 2017 DhServerLeases: InstallationDate: Installed on 2015-04-20 (756 days ago) InstallationMedia: Ubuntu-Server 14.10 "Utopic Unicorn" - Release amd64 (20141022.2) ProcEnviron: TERM=screen.xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: isc-dhcp UpgradeStatus: Upgraded to zesty on 2017-05-05 (9 days ago) mtime.conffile..etc.dhcp.dhcpd.conf: 2017-05-15T23:37:21.502892 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1690933/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1788659] Re: network manager assigns ethernet default route metric of 20100
This is working as designed. NetworkManager now uses a metric "penalty" when connectivity cannot be detected as full for a connection, and reduces the metric accordingly. This makes it so that if you're connected to both wired and wireless, and your wired connection becomes bad but the wireless connection remains, you should retain connectivity. Similarly, if you need to use your own custom routes to use alternative paths to be online, this makes sure this alternative can be used automatically (the lowest metric is what gets used). You may be able to avoid this issue by removing package 'network- manager-config-connectivity-ubuntu' from your system if it is installed -- disabling connectivity checking, which will avoid going through these code paths. ** Changed in: network-manager (Ubuntu) Status: Confirmed => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1788659 Title: network manager assigns ethernet default route metric of 20100 Status in network-manager package in Ubuntu: Incomplete Bug description: After upgrading from 16.04 to 18.04, when I boot with an ethernet cable connected, Ubuntu prefers to use the wifi interface over the ethernet interface. Wifi is assigned the normal metric of 600 for both of its routing table entries. However ethernet is assigned a metric of 20100. I edited the connection details via nmcli to manually set the ethernet metric to 100. After a reboot, the link route (for the LAN subnet) correctly has a metric of 100. But the default route for eth0 is still 20100. nm-applet shows the wifi icon, correctly indicating that the default route is over wifi rather than ethernet. The only fix is to manually set the route after every reboot, or turn off wifi. This is a regression from 16.04. network-manager 1.10.6-2ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1788659/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1788659] Re: network manager assigns ethernet default route metric of 20100
Marking Incomplete for now, in case there's more to it than a connectivity checking issue. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1788659 Title: network manager assigns ethernet default route metric of 20100 Status in network-manager package in Ubuntu: Incomplete Bug description: After upgrading from 16.04 to 18.04, when I boot with an ethernet cable connected, Ubuntu prefers to use the wifi interface over the ethernet interface. Wifi is assigned the normal metric of 600 for both of its routing table entries. However ethernet is assigned a metric of 20100. I edited the connection details via nmcli to manually set the ethernet metric to 100. After a reboot, the link route (for the LAN subnet) correctly has a metric of 100. But the default route for eth0 is still 20100. nm-applet shows the wifi icon, correctly indicating that the default route is over wifi rather than ethernet. The only fix is to manually set the route after every reboot, or turn off wifi. This is a regression from 16.04. network-manager 1.10.6-2ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1788659/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1784347] Re: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath
** Description changed: + + [Impact] + Any user of Ubuntu on multipath, where the default path separator has been changed to something else. This possibly affects other scenarios where the partition separator can be changed. + + [Test case] + 1) Install Ubuntu on multipath system + 2) Change /etc/multipath.conf to set "path_separator" to "" or "p". + 3) Reboot + 4) Run 'sudo fdisk -l /dev/mapper/mpathX', to display a device's partitions where the path separator would be visible. + + + [Regression potential] + Minimal. This only affects display. Default separator on Ubuntu remains "-part". If the separator is not one of "", "p", or "-part", then "-part" would be used, as is already the case. + + == Comment: #0 - Chanh H. Nguyen - 2018-01-09 11:14:07 == - We have the Ubuntu1804 installed on our BostonLC system. Create a SAN via the Emulex adapter to have the mpath disk. - Running the fdisk -l and ls -l showing the conflict name for the mpath. + We have the Ubuntu1804 installed on our BostonLC system. Create a SAN via the Emulex adapter to have the mpath disk. + Running the fdisk -l and ls -l showing the conflict name for the mpath. :~# uname -a Linux boslcp4 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:03:08 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux root@boslcp4:~# cat /etc/os-release NAME="Ubuntu" VERSION="18.04 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu Bionic Beaver (development branch)" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part1 2048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 1258291199 419428352 200G 83 Linux :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:04 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha3 -> ../dm-3 == Comment: #2 - Chanh H. Nguyen - 2018-01-09 11:35:04 == I just modify the partitions and it is still showing the conflicting name on partitions. :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha3 -> ../dm-3 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha4 -> ../dm-4 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha5 -> ../dm-5 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha6 -> ../dm-6 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha7 -> ../dm-7 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha8 -> ../dm-8 :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part12048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 964691967 125829120 60G 83 Linux /dev/mapper/mpatha-part4 964691968 1258291199 293599232 140G 5 Extended /dev/mapper/mpatha-part5 964694016 1006637055 41943040 20G 83 Linux /dev/mapper/mpatha-part6 1006639104 1048582143 41943040 20G 83 Linux /dev/mapper/mpatha-part7 1048584192 1090527231 41943040 20G 83 Linux /dev/mapper/mpatha-part8 1090529280 1132472319 41943040 20G 83 Linux == Comment: #5 - Kyle Mahlkuch - 2018-06-26 13:50:12 == I have created and submitted a patch that should help with this bug. I will update when/if the patch is accepted. == Comment: #9 - Kyle Mahlkuch - 2018-07-27 09:10:44 == - Here is the patch: + Here is the patch: https://github.com/karelzak/util-linux/commit/73775189767195f1d9f5b6b6f6a54e51f61c4356 -- You received this bug notification
[Touch-packages] [Bug 1784347] Re: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath
Correct, I hadn't noticed that part. The issue I have with this patch still stands, nothing guarantees that the separator is "", "p", or "-part", but at least we're covering the most likely cases. I'm sponsoring the patch now, we'll land this as SRU to 18.10 and 18.04. ** Changed in: util-linux (Ubuntu) Assignee: Canonical Foundations Team (canonical-foundations) => Mathieu Trudel-Lapierre (cyphermox) ** Changed in: util-linux (Ubuntu) Status: New => Triaged ** Changed in: ubuntu-power-systems Assignee: Canonical Foundations Team (canonical-foundations) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1784347 Title: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath Status in The Ubuntu-power-systems project: Triaged Status in util-linux package in Ubuntu: Triaged Bug description: == Comment: #0 - Chanh H. Nguyen - 2018-01-09 11:14:07 == We have the Ubuntu1804 installed on our BostonLC system. Create a SAN via the Emulex adapter to have the mpath disk. Running the fdisk -l and ls -l showing the conflict name for the mpath. :~# uname -a Linux boslcp4 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:03:08 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux root@boslcp4:~# cat /etc/os-release NAME="Ubuntu" VERSION="18.04 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu Bionic Beaver (development branch)" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part1 2048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 1258291199 419428352 200G 83 Linux :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:04 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha3 -> ../dm-3 == Comment: #2 - Chanh H. Nguyen - 2018-01-09 11:35:04 == I just modify the partitions and it is still showing the conflicting name on partitions. :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha3 -> ../dm-3 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha4 -> ../dm-4 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha5 -> ../dm-5 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha6 -> ../dm-6 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha7 -> ../dm-7 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha8 -> ../dm-8 :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part12048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 964691967 125829120 60G 83 Linux /dev/mapper/mpatha-part4 964691968 1258291199 293599232 140G 5 Extended /dev/mapper/mpatha-part5 964694016 1006637055 41943040 20G 83 Linux /dev/mapper/mpatha-part6 1006639104 1048582143 41943040 20G 83 Linux /dev/mapper/mpatha-part7 1048584192 1090527231 41943040 20G 83 Linux /dev/mapper/mpatha-part8 1090529280 1132472319 41943040 20G 83 Linux == Comment: #5 - Kyle Mahlkuch - 2018-06-26 13:50:12 == I have created and submitted a patch that should help with this bug. I will update when/if the patch is acc
