[Touch-packages] [Bug 1675571] Re: Cloud-init update renders secondary addresses to be incompatible with standard tools
** Description changed:
The change of how cloud-init renders
/etc/network/interface.d/50-cloud-init.cfg, standard tools no longer work as
expected:
* resolvconf will nullify nameservers
* if* commands ignore secondary addresses
-
- The rendering is considered dangerous per Debian
(https://wiki.debian.org/NetworkConfiguration), to whit:
- "Also, ifupdown supports specifying multiple interfaces by repeating iface
sections with the same interface name. The key difference from the method
described above is that all such sections are treated by ifupdown as just one
interface, so user can't add or remove them individually. However, up/down
commands, as well as scripts, are called for every section as it used to be.
-
- "Note however that this method is dangerous! Certain driver/hardware
combinations may sometimes fail to bring the link up if no labels are assigned
to the alias interfaces. (Seen this on Debian Wheezy and Jessie with
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
auto-negotiating to 10/full. A similar warning from another person exists in
the history of this page.)
- "
-
[ORIGINAL REPORT]
Regresion from Bug #1657940.
When provisioning with multiple eth0 addresses, /etc/resolv.conf is
empty:
Consider:
root@tester:~# cat /etc/network/interfaces.d/50-cloud-init.cfg
# 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}
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 138.197.98.102
dns-nameservers 8.8.8.8 8.8.4.4
gateway 138.197.96.1
netmask 255.255.240.0
# control-alias eth0
iface eth0 inet static
address 10.17.0.11
netmask 255.255.0.0
Which then yields an empty /etc/resolv.conf:
root@tester:/run/resolvconf# cat interface/eth0.inet
root@tester:/run/resolvconf# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
The problem is that resolvconfg does pattern matching for eth*.inet. The
second definition of eth0 has no nameserver and therefore overrides the
definition.
--
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/1675571
Title:
Cloud-init update renders secondary addresses to be incompatible with
standard tools
Status in cloud-init:
Confirmed
Status in cloud-init package in Ubuntu:
Confirmed
Status in resolvconf package in Ubuntu:
New
Bug description:
The change of how cloud-init renders
/etc/network/interface.d/50-cloud-init.cfg, standard tools no longer work as
expected:
* resolvconf will nullify nameservers
* if* commands ignore secondary addresses
[ORIGINAL REPORT]
Regresion from Bug #1657940.
When provisioning with multiple eth0 addresses, /etc/resolv.conf is
empty:
Consider:
root@tester:~# cat /etc/network/interfaces.d/50-cloud-init.cfg
# 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}
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 138.197.98.102
dns-nameservers 8.8.8.8 8.8.4.4
gateway 138.197.96.1
netmask 255.255.240.0
# control-alias eth0
iface eth0 inet static
address 10.17.0.11
netmask 255.255.0.0
Which then yields an empty /etc/resolv.conf:
root@tester:/run/resolvconf# cat interface/eth0.inet
root@tester:/run/resolvconf# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
The problem is that resolvconfg does pattern matching for eth*.inet.
The second definition of eth0 has no nameserver and therefore
overrides the definition.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1675571/+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 1053746] Re: Cloud-images all run cron jobs simultaneously
** Changed in: cron (Ubuntu) Assignee: Ben Howard (utlemming) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cron in Ubuntu. https://bugs.launchpad.net/bugs/1053746 Title: Cloud-images all run cron jobs simultaneously Status in cron package in Ubuntu: Confirmed Bug description: Cloud-images all run their cron jobs simultaneously, causing a large resource usage spike on the hosting physical infrastructure. It would be great if cron run-parts were run with a randomized sleep to spread this load. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1053746/+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 1526956] Re: klibc does not support rfc3442; needed for netboot
** Changed in: klibc (Ubuntu) Assignee: Ben Howard (utlemming) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1526956 Title: klibc does not support rfc3442; needed for netboot Status in klibc package in Ubuntu: Confirmed Bug description: klibc does not support classless static routes. If classes routing is used for a netboot device (NFS, iscsi) these devices will fail to boot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1526956/+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 1420544] Re: [SRU] Ubuntu instances on GCE should use NOOP scheduler
** Changed in: linux (Ubuntu) Assignee: Ben Howard (utlemming) => (unassigned) -- 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/1420544 Title: [SRU] Ubuntu instances on GCE should use NOOP scheduler Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Won't Fix Status in systemd source package in Trusty: Fix Released Bug description: [IMPACT] By default, the Ubuntu kernel uses deadline. Google has identified that Cloud Workloads running on Ubuntu perform better using NOOP as the default scheduler. Google has requested that Google Cloud Compute (GCE) instances use NOOP as the default. [FIX] Add udev rule for GCE devices to use NOOP by default. [VALIDATION] 1. Boot Ubuntu instance on Google GCE 2. Confirm that the scheduler is deadline: $ cat /sys/block/sda/queue/scheduler noop [deadline] cfq 3. Install proposed udev package 4. Reboot 5. Confirm that schedule is now noop $ cat /sys/block/sda/queue/scheduler [noop] deadline cfq [RISK] This patch will affect currently running instances and on reboot they should see better performance. However, there is a risk that some users will experience a performance hit. [ORIGINAL REPORT] Per Google's request, Ubuntu instances should use NOOP as the default scheduler. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1420544/+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 1543170] Re: lxc fails to install
** Package changed: ubuntu => lxd (Ubuntu) ** Package changed: lxd (Ubuntu) => lxc (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1543170 Title: lxc fails to install Status in lxc package in Ubuntu: Confirmed Bug description: LXC in Xenial fails to install. Since this is a seed package for the cloud-images, cloud image builds are now broken. Setting up lxc (2.0.0~beta2-0ubuntu2) ... invoke-rc.d: unknown initscript, /etc/init.d/lxc not found. dpkg: error processing package lxc (--configure): subprocess installed post-installation script returned error exit status 100 dpkg: dependency problems prevent configuration of lxc-templates: lxc-templates depends on lxc (>= 0.8.0~rc1-4ubuntu43); however: Package lxc is not configured yet. dpkg: error processing package lxc-templates (--configure): dependency problems - leaving unconfigured Setting up lxcfs (0.17-0ubuntu3) ... Running in chroot, ignoring request. All runlevel operations denied by policy invoke-rc.d: policy-rc.d denied execution of start. Setting up xz-utils (5.1.1alpha+20120614-2ubuntu2) ... update-alternatives: using /usr/bin/xz to provide /usr/bin/lzma (lzma) in auto mode dpkg: dependency problems prevent configuration of lxd: lxd depends on lxc; however: Package lxc is not configured yet. dpkg: error processing package lxd (--configure): To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1543170/+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 1521136] [NEW] NetworkManager segfaults on connect
Public bug reported: Upon connecting, NetworkManager from -updates is segfaulting: [ 139.520739] NetworkManager[15884]: segfault at 0 ip 00497ad7 sp 7fff77195d00 error 4 in NetworkManager[40+1bf000] Nov 30 10:31:23 arbella NetworkManager[16259]: keyfile: add connection in-memory (c4b6e184-67e3-4a12-8dd3-79ec7ef650e0,"enx803f5d087a34") Nov 30 10:31:23 arbella NetworkManager[16259]: (enx803f5d087a34): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41] Nov 30 10:31:23 arbella NetworkManager[16259]: (enx803f5d087a34): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41] Nov 30 10:31:23 arbella NetworkManager[16259]: (enx803f5d087a34): Activation: starting connection 'enx803f5d087a34' (c4b6e184-67e3-4a12-8dd3-79ec7ef650e0) Nov 30 10:31:23 arbella NetworkManager[16259]: nm_device_get_device_type: assertion 'NM_IS_DEVICE (self)' failed Nov 30 10:31:23 arbella NetworkManager[16259]: (lo): link connected Nov 30 10:31:23 arbella NetworkManager[16259]: (lo): new Generic device (carrier: ON, driver: 'unknown', ifindex: 1) Nov 30 10:31:23 arbella NetworkManager[16259]: (wlp2s0): using nl80211 for WiFi device control Nov 30 10:31:23 arbella NetworkManager[16259]: (wlp2s0): driver supports Access Point (AP) mode Nov 30 10:31:23 arbella NetworkManager[16259]: (wlp2s0): new 802.11 WiFi device (carrier: UNKNOWN, driver: 'ath10k_pci', ifindex: 3) Nov 30 10:31:23 arbella NetworkManager[16259]: (wlp2s0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] Nov 30 10:31:23 arbella kernel: [ 140.168048] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready Nov 30 10:31:23 arbella NetworkManager[16259]: urfkill disappeared from the bus Nov 30 10:31:23 arbella NetworkManager[16259]: use BlueZ version 5 Nov 30 10:31:23 arbella NetworkManager[16259]: wpa_supplicant running Nov 30 10:31:23 arbella NetworkManager[16259]: (wlp2s0): supplicant interface state: starting -> ready Nov 30 10:31:23 arbella NetworkManager[16259]: (lxcbr0): device state change: disconnected -> prepare (reason 'none') [30 40 0] Nov 30 10:31:23 arbella NetworkManager[16259]: (enx803f5d087a34): device state change: disconnected -> prepare (reason 'none') [30 40 0] Nov 30 10:31:23 arbella NetworkManager[16259]: Policy set 'enx803f5d087a34' (enx803f5d087a34) as default for IPv4 routing and DNS. ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: Network-Manager 1.0.4-0ubuntu5 ProcVersionSignature: Ubuntu 4.2.0-18.22-generic 4.2.3 Uname: Linux 4.2.0-18-generic x86_64 ApportVersion: 2.19.1-0ubuntu5 Architecture: amd64 CurrentDesktop: Unity Date: Mon Nov 30 10:39:36 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2015-11-21 (9 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021) IpRoute: default via 10.20.64.1 dev wlp2s0 proto static metric 600 10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1 10.20.64.0/21 dev wlp2s0 proto kernel scope link src 10.20.66.104 metric 600 169.254.0.0/16 dev lxcbr0 scope link metric 1000 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-dev: DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH lxcbr0 bridgeconnected /org/freedesktop/NetworkManager/Devices/3 lxcbr0 ac91e68a-905e-4cd2-a937-11b8c5f4bed0 /org/freedesktop/NetworkManager/ActiveConnection/1 wlp2s0 wifi connected /org/freedesktop/NetworkManager/Devices/2 Canonical-2.4GHz-g 4eb6b0d8-a49e-4e11-aff1-18ce3f158523 /org/freedesktop/NetworkManager/ActiveConnection/2 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/1 -- ---- nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug third-party-packages wily -- 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/1521136 Title: NetworkManager segfaults on connect Status in network-manager package in Ubuntu: New Bug description: Upon connecting, NetworkManager from -updates is segfaulting: [ 139.520739] NetworkManager[15884]: segfault at 0 ip 00497ad7 sp 7fff77195d00 error 4 in NetworkManager[40+1bf000] Nov 30 10:31:23 arbella NetworkManager[16259]: keyfile: add connection
[Touch-packages] [Bug 1521136] Re: NetworkManager segfaults on connect
Downgrading (i.e. sudo apt-get -y --reinstall install --force-yes network-manager=1.0.4-0ubuntu5) and then rebooting fixed me. -- 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/1521136 Title: NetworkManager segfaults on connect Status in network-manager package in Ubuntu: New Bug description: Upon connecting, NetworkManager from -updates is segfaulting: [ 139.520739] NetworkManager[15884]: segfault at 0 ip 00497ad7 sp 7fff77195d00 error 4 in NetworkManager[40+1bf000] Nov 30 10:31:23 arbella NetworkManager[16259]: keyfile: add connection in-memory (c4b6e184-67e3-4a12-8dd3-79ec7ef650e0,"enx803f5d087a34") Nov 30 10:31:23 arbella NetworkManager[16259]: (enx803f5d087a34): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41] Nov 30 10:31:23 arbella NetworkManager[16259]: (enx803f5d087a34): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41] Nov 30 10:31:23 arbella NetworkManager[16259]: (enx803f5d087a34): Activation: starting connection 'enx803f5d087a34' (c4b6e184-67e3-4a12-8dd3-79ec7ef650e0) Nov 30 10:31:23 arbella NetworkManager[16259]: nm_device_get_device_type: assertion 'NM_IS_DEVICE (self)' failed Nov 30 10:31:23 arbella NetworkManager[16259]: (lo): link connected Nov 30 10:31:23 arbella NetworkManager[16259]: (lo): new Generic device (carrier: ON, driver: 'unknown', ifindex: 1) Nov 30 10:31:23 arbella NetworkManager[16259]: (wlp2s0): using nl80211 for WiFi device control Nov 30 10:31:23 arbella NetworkManager[16259]: (wlp2s0): driver supports Access Point (AP) mode Nov 30 10:31:23 arbella NetworkManager[16259]: (wlp2s0): new 802.11 WiFi device (carrier: UNKNOWN, driver: 'ath10k_pci', ifindex: 3) Nov 30 10:31:23 arbella NetworkManager[16259]: (wlp2s0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] Nov 30 10:31:23 arbella kernel: [ 140.168048] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready Nov 30 10:31:23 arbella NetworkManager[16259]: urfkill disappeared from the bus Nov 30 10:31:23 arbella NetworkManager[16259]: use BlueZ version 5 Nov 30 10:31:23 arbella NetworkManager[16259]: wpa_supplicant running Nov 30 10:31:23 arbella NetworkManager[16259]: (wlp2s0): supplicant interface state: starting -> ready Nov 30 10:31:23 arbella NetworkManager[16259]: (lxcbr0): device state change: disconnected -> prepare (reason 'none') [30 40 0] Nov 30 10:31:23 arbella NetworkManager[16259]: (enx803f5d087a34): device state change: disconnected -> prepare (reason 'none') [30 40 0] Nov 30 10:31:23 arbella NetworkManager[16259]: Policy set 'enx803f5d087a34' (enx803f5d087a34) as default for IPv4 routing and DNS. ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: Network-Manager 1.0.4-0ubuntu5 ProcVersionSignature: Ubuntu 4.2.0-18.22-generic 4.2.3 Uname: Linux 4.2.0-18-generic x86_64 ApportVersion: 2.19.1-0ubuntu5 Architecture: amd64 CurrentDesktop: Unity Date: Mon Nov 30 10:39:36 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2015-11-21 (9 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021) IpRoute: default via 10.20.64.1 dev wlp2s0 proto static metric 600 10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1 10.20.64.0/21 dev wlp2s0 proto kernel scope link src 10.20.66.104 metric 600 169.254.0.0/16 dev lxcbr0 scope link metric 1000 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-dev: DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH lxcbr0 bridgeconnected /org/freedesktop/NetworkManager/Devices/3 lxcbr0 ac91e68a-905e-4cd2-a937-11b8c5f4bed0 /org/freedesktop/NetworkManager/ActiveConnection/1 wlp2s0 wifi connected /org/freedesktop/NetworkManager/Devices/2 Canonical-2.4GHz-g 4eb6b0d8-a49e-4e11-aff1-18ce3f158523 /org/freedesktop/NetworkManager/ActiveConnection/2 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/1 -- ---- nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1521136/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to :
[Touch-packages] [Bug 1505164] Re: Ubuntu Docker images incorrectly include packages from trusty-proposed
I am unable to repo this bug. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3.4 in Ubuntu. https://bugs.launchpad.net/bugs/1505164 Title: Ubuntu Docker images incorrectly include packages from trusty-proposed Status in docker.io package in Ubuntu: Triaged Status in mod-wsgi package in Ubuntu: Invalid Status in python3.4 package in Ubuntu: Invalid Bug description: Steps to reproduce (using a docker container): $ docker pull ubuntu:trusty $ docker run --rm -it ubuntu:trusty /bin/bash # lsb_release -rd Description: Ubuntu 14.04.3 LTS Release: 14.04 # apt-get update # apt-get install python3.4 python3.4 is already the newest version. # python3 --version Python 3.4.3 # dpkg -l python3.4 ii python3.4 3.4.3-1ubuntu1~14.0 # apt-get install apache2 ... # apt-get install libapache2-mod-wsgi-py3 The following packages have unmet dependencies: libapache2-mod-wsgi-py3 : Depends: libpython3.4 (>= 3.4~b1) but it is not going to be installed E: Unable to correct problems, you have held broken packages. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1505164/+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 1500768] Re: python3.4.3 SRU break requests
See Bug #1505164: # apt-get install libapache2-mod-wsgi-py3 The following packages have unmet dependencies: libapache2-mod-wsgi-py3 : Depends: libpython3.4 (>= 3.4~b1) but it is not going to be installed E: Unable to correct problems, you have held broken packages. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3.4 in Ubuntu. https://bugs.launchpad.net/bugs/1500768 Title: python3.4.3 SRU break requests Status in python3.4 package in Ubuntu: Invalid Status in python3.4 source package in Trusty: Triaged Bug description: Sicne the upgade to python 3.4.3 on trusty, I'm getting this error when using a squid proxy: https://jenkins.qa.ubuntu.com/view/All/job/udtc-trusty-tests/1946/label=ps-trusty-desktop-amd64-1,type=large/testReport/tests.large.test_android/AndroidSDKTests/test_default_android_sdk_install/ The code is using python-requests, with verify=True for ssl connection (default). Some tests are testing that invalid certificates are rejected: https://github.com/ubuntu/ubuntu- make/blob/master/umake/network/download_center.py#L129 Rerunning the same code with previous trusty package (3.4.0~trusty1) doesn't show up this issue. It seems that SNI is broken for the trusty version of python3-requests with 3.4.3. (See the FAQ http://www .python-requests.org/en/latest/community/faq/ with "What are “hostname doesn’t match” errors?" and the stackoverflow question. I did run a test, grabbing requests 2.7 and backporting it to trusty (I needed to as well to take python3-urllib3 willy version). So, 3.4.3 has an incompatible change for existing projects and people with proxys are starting to see some breakage like in https://bugs.launchpad.net/ubuntu/+source/ubuntu-make/+bug/1499890. Can we get it fix somehow, reverting the incompatible change breaking SNI (I wonder if this is "Changed in version 3.4.3: This class now performs all the necessary certificate and hostname checks by default. To revert to the previous, unverified, behavior ssl._create_unverified_context() can be passed to the context parameter." in https://docs.python.org/3/library/http.client.html or something else) so that existing code can either get a new compatible python-requests or avoid incompatible changes in python 3.4.3? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1500768/+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 1505164] Re: Ubuntu Docker images incorrectly include packages from trusty-proposed
Scratch comment #3. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3.4 in Ubuntu. https://bugs.launchpad.net/bugs/1505164 Title: Ubuntu Docker images incorrectly include packages from trusty-proposed Status in docker.io package in Ubuntu: In Progress Status in mod-wsgi package in Ubuntu: Invalid Status in python3.4 package in Ubuntu: Invalid Bug description: Steps to reproduce (using a docker container): $ docker pull ubuntu:trusty $ docker run --rm -it ubuntu:trusty /bin/bash # lsb_release -rd Description: Ubuntu 14.04.3 LTS Release: 14.04 # apt-get update # apt-get install python3.4 python3.4 is already the newest version. # python3 --version Python 3.4.3 # dpkg -l python3.4 ii python3.4 3.4.3-1ubuntu1~14.0 # apt-get install apache2 ... # apt-get install libapache2-mod-wsgi-py3 The following packages have unmet dependencies: libapache2-mod-wsgi-py3 : Depends: libpython3.4 (>= 3.4~b1) but it is not going to be installed E: Unable to correct problems, you have held broken packages. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1505164/+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 1505164] Re: Ubuntu Docker images include packages deleted from trusty-updates
This was caused by Bug #1500768. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3.4 in Ubuntu. https://bugs.launchpad.net/bugs/1505164 Title: Ubuntu Docker images include packages deleted from trusty-updates Status in docker.io package in Ubuntu: In Progress Status in mod-wsgi package in Ubuntu: Invalid Status in python3.4 package in Ubuntu: Invalid Bug description: Steps to reproduce (using a docker container): $ docker pull ubuntu:trusty $ docker run --rm -it ubuntu:trusty /bin/bash # lsb_release -rd Description: Ubuntu 14.04.3 LTS Release: 14.04 # apt-get update # apt-get install python3.4 python3.4 is already the newest version. # python3 --version Python 3.4.3 # dpkg -l python3.4 ii python3.4 3.4.3-1ubuntu1~14.0 # apt-get install apache2 ... # apt-get install libapache2-mod-wsgi-py3 The following packages have unmet dependencies: libapache2-mod-wsgi-py3 : Depends: libpython3.4 (>= 3.4~b1) but it is not going to be installed E: Unable to correct problems, you have held broken packages. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1505164/+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 613022] Re: ssh daemon hangs after publickey packet sent
Closing this out as crufty. If this is seen again, please reopen. ** Changed in: openssh (Ubuntu) Status: Confirmed => Invalid -- 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/613022 Title: ssh daemon hangs after publickey packet sent Status in cloud-init package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Status in openssh package in Ubuntu: Invalid Bug description: A launched ec2 instance in ap-southeast-1 region is unreachable via ssh. $ ssh -vvv ec2-175-41-171-225.ap-southeast-1.compute.amazonaws.com shows progress up to : debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: smoser@brickies debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply Then nothing for minutes before session is killed (manually). In a 'good' connection, the following would be next: debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey I'll attach full 'ssh -vvv' logs good and bad connection. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: openssh-server 1:5.5p1-4ubuntu3 ProcVersionSignature: User Name 2.6.35-14.19-virtual 2.6.35 Uname: Linux 2.6.35-14-virtual x86_64 Architecture: amd64 Date: Tue Aug 3 14:45:25 2010 Ec2AMI: ami-9fc4bbcd Ec2AMIManifest: ubuntu-images-testing-ap-southeast-1/ubuntu-maverick-daily-amd64-server-20100803.1.manifest.xml Ec2AvailabilityZone: ap-southeast-1a Ec2InstanceType: m1.large Ec2Kernel: aki-11d5aa43 Ec2Ramdisk: unavailable ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: openssh To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/613022/+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 1468091] Re: [udev] Ubuntu 15.10 Alpha-1 candidates do not boot in EC2 with Xen
I've confirmed the fix in -proposed in EC2. New builds will happen automagically once the promotion from -proposed happens. -- 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/1468091 Title: [udev] Ubuntu 15.10 Alpha-1 candidates do not boot in EC2 with Xen Status in systemd package in Ubuntu: Fix Committed Bug description: Ubuntu 15.10 Alpha-1 Candidates are not booting in EC2. Instances are dropping to - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/disk/by-uuid/e420d299-69ee-46eb-a1a4-893b54ab89a7 does not exist. Dropping to a shell! This is happening on all instances and whether disks are mounted by label or UUID. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1468091/+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 1468091] Re: Ubuntu 15.04 Alpha-1 candidates do not boot in EC2
Confirmed that this is not happening on OpenStack. I suspect that this is cause is that /dev/disk/by-*/ targets are missing for Xen Block devices. ** Changed in: ubuntu Status: New = Confirmed ** Changed in: ubuntu Importance: Undecided = Critical ** Package changed: ubuntu = systemd (Ubuntu) -- 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/1468091 Title: Ubuntu 15.10 Alpha-1 candidates do not boot in EC2 Status in systemd package in Ubuntu: Confirmed Bug description: Ubuntu 15.10 Alpha-1 Candidates are not booting in EC2. Instances are dropping to - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/disk/by-uuid/e420d299-69ee-46eb-a1a4-893b54ab89a7 does not exist. Dropping to a shell! This is happening on all instances and whether disks are mounted by label or UUID. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1468091/+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 1468091] Re: Ubuntu 15.10 Alpha-1 candidates do not boot in EC2
Actually, PV and HVM instances are both affected. I narrowed it down to udev; installing all updates except for udev results in a bootable instance. -- 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/1468091 Title: Ubuntu 15.10 Alpha-1 candidates do not boot in EC2 Status in systemd package in Ubuntu: Confirmed Bug description: Ubuntu 15.10 Alpha-1 Candidates are not booting in EC2. Instances are dropping to - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/disk/by-uuid/e420d299-69ee-46eb-a1a4-893b54ab89a7 does not exist. Dropping to a shell! This is happening on all instances and whether disks are mounted by label or UUID. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1468091/+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 1420544] Re: [SRU] Ubuntu instances on GCE should use NOOP scheduler
Confirmed -proposed. Marking as validation-done. ** Tags removed: verification-needed ** Tags added: verification-done -- 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/1420544 Title: [SRU] Ubuntu instances on GCE should use NOOP scheduler Status in linux package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Incomplete Status in systemd source package in Trusty: Fix Committed Bug description: [IMPACT] By default, the Ubuntu kernel uses deadline. Google has identified that Cloud Workloads running on Ubuntu perform better using NOOP as the default scheduler. Google has requested that Google Cloud Compute (GCE) instances use NOOP as the default. [FIX] Add udev rule for GCE devices to use NOOP by default. [VALIDATION] 1. Boot Ubuntu instance on Google GCE 2. Confirm that the scheduler is deadline: $ cat /sys/block/sda/queue/scheduler noop [deadline] cfq 3. Install proposed udev package 4. Reboot 5. Confirm that schedule is now noop $ cat /sys/block/sda/queue/scheduler [noop] deadline cfq [RISK] This patch will affect currently running instances and on reboot they should see better performance. However, there is a risk that some users will experience a performance hit. [ORIGINAL REPORT] Per Google's request, Ubuntu instances should use NOOP as the default scheduler. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1420544/+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 1420544] Re: [SRU] Ubuntu instances on GCE should use NOOP scheduler
** Summary changed: - Ubuntu instances on GCE should use NOOP scheduler + [SRU] Ubuntu instances on GCE should use NOOP scheduler -- 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/1420544 Title: [SRU] Ubuntu instances on GCE should use NOOP scheduler Status in linux package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Incomplete Status in systemd source package in Trusty: In Progress Bug description: Per Google's request, Ubuntu instances should use NOOP as the default scheduler. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1420544/+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 1420544] Re: [SRU] Ubuntu instances on GCE should use NOOP scheduler
** Description changed: + [IMPACT] By default, the Ubuntu kernel uses deadline. Google has + identified that Cloud Workloads running on Ubuntu perform better using + NOOP as the default scheduler. Google has requested that Google Cloud + Compute (GCE) instances use NOOP as the default. + + [FIX] Add udev rule for GCE devices to use NOOP by default. + + [VALIDATION] + 1. Boot Ubuntu instance on Google GCE + 2. Confirm that the scheduler is deadline: +$ cat /sys/block/sda/queue/scheduler +noop [deadline] cfq + 3. Install proposed udev package + 4. Reboot + 5. Confirm that schedule is now noop +$ cat /sys/block/sda/queue/scheduler + [noop] deadline cfq + + [RISK] This patch will affect currently running instances and on reboot + they should see better performance. However, there is a risk that some + users will experience a performance hit. + + [ORIGINAL REPORT] + Per Google's request, Ubuntu instances should use NOOP as the default scheduler. -- 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/1420544 Title: [SRU] Ubuntu instances on GCE should use NOOP scheduler Status in linux package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Incomplete Status in systemd source package in Trusty: In Progress Bug description: [IMPACT] By default, the Ubuntu kernel uses deadline. Google has identified that Cloud Workloads running on Ubuntu perform better using NOOP as the default scheduler. Google has requested that Google Cloud Compute (GCE) instances use NOOP as the default. [FIX] Add udev rule for GCE devices to use NOOP by default. [VALIDATION] 1. Boot Ubuntu instance on Google GCE 2. Confirm that the scheduler is deadline: $ cat /sys/block/sda/queue/scheduler noop [deadline] cfq 3. Install proposed udev package 4. Reboot 5. Confirm that schedule is now noop $ cat /sys/block/sda/queue/scheduler [noop] deadline cfq [RISK] This patch will affect currently running instances and on reboot they should see better performance. However, there is a risk that some users will experience a performance hit. [ORIGINAL REPORT] Per Google's request, Ubuntu instances should use NOOP as the default scheduler. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1420544/+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 1420544] Re: [SRU] Ubuntu instances on GCE should use NOOP scheduler
Sorry about missing the SRU info. Added. -- 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/1420544 Title: [SRU] Ubuntu instances on GCE should use NOOP scheduler Status in linux package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Incomplete Status in systemd source package in Trusty: In Progress Bug description: [IMPACT] By default, the Ubuntu kernel uses deadline. Google has identified that Cloud Workloads running on Ubuntu perform better using NOOP as the default scheduler. Google has requested that Google Cloud Compute (GCE) instances use NOOP as the default. [FIX] Add udev rule for GCE devices to use NOOP by default. [VALIDATION] 1. Boot Ubuntu instance on Google GCE 2. Confirm that the scheduler is deadline: $ cat /sys/block/sda/queue/scheduler noop [deadline] cfq 3. Install proposed udev package 4. Reboot 5. Confirm that schedule is now noop $ cat /sys/block/sda/queue/scheduler [noop] deadline cfq [RISK] This patch will affect currently running instances and on reboot they should see better performance. However, there is a risk that some users will experience a performance hit. [ORIGINAL REPORT] Per Google's request, Ubuntu instances should use NOOP as the default scheduler. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1420544/+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 1367883] Re: [SRU] Add Microsoft-owned MAC address to 75-persistent-net-generator.rules
** Tags removed: verification-failed verification-needed ** Tags added: verification-done ** Tags removed: verification-done ** Tags added: verification-needed -- 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/1367883 Title: [SRU] Add Microsoft-owned MAC address to 75-persistent-net- generator.rules Status in systemd package in Ubuntu: Fix Released Status in udev package in Ubuntu: Invalid Status in udev source package in Precise: Fix Committed Status in systemd source package in Trusty: Fix Released Bug description: Impact: As Microsoft expands its public cloud offering it may need to utilize additional MAC address prefixes. If a user launches a Cloud instance when the MAC address is from a Microsoft-owned MAC address that is not in the exclusion list, eth0 is persistently named for the first NIC seen. If a user rebundles, or the machines has its MAC address changed (e.g. VM resize or VM is moved to another host), it will lose network connectivity. Fix: Please add the following Microsoft-owned MAC address to the 75 -persistent-net-generator.rules file: 00:25:ae Microsoft Corporation Test Case : - Launch Hyper-V VM with MAC address with prefix 00:25:ae - Install updated Udev/systemd - Delete any existing udev rule - Reboot and confirm that no new UDEV rule was added To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1367883/+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 1367883] Re: [SRU] Add Microsoft-owned MAC address to 75-persistent-net-generator.rules
Marking as verification done. I am unable to replicate the automated regression check. ** Tags removed: verification-needed ** Tags added: verification-done -- 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/1367883 Title: [SRU] Add Microsoft-owned MAC address to 75-persistent-net- generator.rules Status in systemd package in Ubuntu: Fix Released Status in udev package in Ubuntu: Invalid Status in udev source package in Precise: Fix Committed Status in systemd source package in Trusty: Fix Released Bug description: Impact: As Microsoft expands its public cloud offering it may need to utilize additional MAC address prefixes. If a user launches a Cloud instance when the MAC address is from a Microsoft-owned MAC address that is not in the exclusion list, eth0 is persistently named for the first NIC seen. If a user rebundles, or the machines has its MAC address changed (e.g. VM resize or VM is moved to another host), it will lose network connectivity. Fix: Please add the following Microsoft-owned MAC address to the 75 -persistent-net-generator.rules file: 00:25:ae Microsoft Corporation Test Case : - Launch Hyper-V VM with MAC address with prefix 00:25:ae - Install updated Udev/systemd - Delete any existing udev rule - Reboot and confirm that no new UDEV rule was added To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1367883/+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 1367883] Re: [SRU] Add Microsoft-owned MAC address to 75-persistent-net-generator.rules
** Summary changed: - Add Microsoft-owned MAC address to 75-persistent-net-generator.rules + [SRU] Add Microsoft-owned MAC address to 75-persistent-net-generator.rules -- 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/1367883 Title: [SRU] Add Microsoft-owned MAC address to 75-persistent-net- generator.rules Status in “systemd” package in Ubuntu: Fix Released Status in “udev” package in Ubuntu: Invalid Status in “udev” source package in Precise: In Progress Status in “systemd” source package in Trusty: In Progress Bug description: Impact: As Microsoft expands its public cloud offering it may need to utilize additional MAC address prefixes. If a user launches a Cloud instance when the MAC address is from a Microsoft-owned MAC address that is not in the exclusion list, eth0 is persistently named for the first NIC seen. If a user rebundles, or the machines has its MAC address changed (e.g. VM resize or VM is moved to another host), it will lose network connectivity. Fix: Please add the following Microsoft-owned MAC address to the 75 -persistent-net-generator.rules file: 00:25:ae Microsoft Corporation Test Case : - Launch Hyper-V VM with MAC address with prefix 00:25:ae - Install updated Udev/systemd - Delete any existing udev rule - Reboot and confirm that no new UDEV rule was added To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1367883/+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 1367883] Re: Add Microsoft-owned MAC address to 75-persistent-net-generator.rules
** Changed in: systemd (Ubuntu Trusty) Assignee: (unassigned) = Ben Howard (utlemming) ** Changed in: systemd (Ubuntu Precise) Assignee: (unassigned) = Ben Howard (utlemming) -- 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/1367883 Title: Add Microsoft-owned MAC address to 75-persistent-net-generator.rules Status in “systemd” package in Ubuntu: Fix Released Status in “systemd” source package in Precise: Triaged Status in “systemd” source package in Trusty: Triaged Bug description: Impact: As Microsoft expands its public cloud offering it may need to utilize additional MAC address prefixes. If a user launches a Cloud instance when the MAC address is from a Microsoft-owned MAC address that is not in the exclusion list, eth0 is persistently named for the first NIC seen. If a user rebundles, or the machines has its MAC address changed (e.g. VM resize or VM is moved to another host), it will lose network connectivity. Fix: Please add the following Microsoft-owned MAC address to the 75 -persistent-net-generator.rules file: 00:25:ae Microsoft Corporation Test Case : - Launch Hyper-V VM with MAC address with prefix 00:25:ae - Install updated Udev/systemd - Delete any existing udev rule - Reboot and confirm that no new UDEV rule was added To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1367883/+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 1367883] Re: Add Microsoft-owned MAC address to 75-persistent-net-generator.rules
For Ubuntu 14.04, attached debdiff for systemd_204-5ubuntu20.7 to systemd_204-5ubuntu20.8. ** Patch added: debdiff for 14.04 https://bugs.launchpad.net/ubuntu/trusty/+source/systemd/+bug/1367883/+attachment/4209308/+files/lp-1367883-trusty.diff -- 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/1367883 Title: Add Microsoft-owned MAC address to 75-persistent-net-generator.rules Status in “systemd” package in Ubuntu: Fix Released Status in “systemd” source package in Precise: In Progress Status in “systemd” source package in Trusty: In Progress Bug description: Impact: As Microsoft expands its public cloud offering it may need to utilize additional MAC address prefixes. If a user launches a Cloud instance when the MAC address is from a Microsoft-owned MAC address that is not in the exclusion list, eth0 is persistently named for the first NIC seen. If a user rebundles, or the machines has its MAC address changed (e.g. VM resize or VM is moved to another host), it will lose network connectivity. Fix: Please add the following Microsoft-owned MAC address to the 75 -persistent-net-generator.rules file: 00:25:ae Microsoft Corporation Test Case : - Launch Hyper-V VM with MAC address with prefix 00:25:ae - Install updated Udev/systemd - Delete any existing udev rule - Reboot and confirm that no new UDEV rule was added To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1367883/+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 1361272] Re: error in udev rules for hyperv net rules
Fix confirmed. Marking as 'verification-done'.
** Tags removed: verification-needed
** Tags added: verification-done
** Changed in: udev (Ubuntu Precise)
Assignee: (unassigned) = Ben Howard (utlemming)
** Changed in: systemd (Ubuntu Trusty)
Assignee: (unassigned) = Ben Howard (utlemming)
--
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/1361272
Title:
error in udev rules for hyperv net rules
Status in “systemd” package in Ubuntu:
Fix Committed
Status in “udev” package in Ubuntu:
Invalid
Status in “udev” source package in Precise:
Fix Committed
Status in “systemd” source package in Trusty:
Fix Committed
Status in “systemd” source package in Utopic:
Fix Committed
Bug description:
There is an error in the syntax where the MAC address does not match
if the alpha characters are upper case rather than all lower case. For
example, these rules are not matched properly:
ENV{MATCHADDR}==00:0c:29:*|00:50:56:*|00:05:69:*|00:1C:14:* - should be
00:1c:14:*
ENV{MATCHADDR}==00:12:5A:* - should be 00:12:5a:*
ENV{MATCHADDR}==00:17:FA:* - should be 00:17:fa:*
ENV{MATCHADDR}==00:50:F2:* - should be 00:50:f2:*
ENV{MATCHADDR}==Dc:B4:c4:* - should be dc:b4:c4:*
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1361272/+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 1342875] Re: Unable to delete currently logged in user
** Changed in: shadow (Ubuntu Utopic) Importance: Undecided = Medium ** Changed in: shadow (Ubuntu Trusty) Importance: Undecided = Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1342875 Title: Unable to delete currently logged in user Status in “shadow” package in Ubuntu: Confirmed Status in “shadow” source package in Trusty: Confirmed Status in “shadow” source package in Utopic: Confirmed Bug description: A user can not delete themselves using the command 'sudo userdel -rf username', this is common in cloud tools that clean up running images prior to capture. A quick test shows that this worked from Precise (didn't look back further) to Raring and stopped working with Saucy. Here's a quick example of the failure (from trusty): # sudo adduser test # sudo usermod -aG sudo test ## As the 'test' user # sudo userdel -rf test userdel: user test is currently used by process 9600 userdel: cannot open /etc/subuid ## User is not removed Previously (output from precise) # sudo userdel -rf test userdel: user test is currently logged in userdel: warning: can't remove /var/mail/test: No such file or directory ## User is removed This is being run as the last command by tools that remove the 'ubuntu' user to clean the image prior to capture. This had previously worked and it is preferable that this could be made to work again. The alternative is removal by root, but the root user on cloud images is locked down and we would not want the user to enable root to run userdel on the risk of it not getting disabled properly prior to image capture. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1342875/+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 1359590] Re: Getty's on serial consoles need to be consistent
One big thing to consider with this is that some clouds (i.e CloudSigma and Joyent) use a serial console as a meta-data channel. In at least one case, activating a getty on the meta-data channel tty will result in the instance being unbootable. For this reason, I think that baking them into the Cloud Images is probably a bad thing. -- 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/1359590 Title: Getty's on serial consoles need to be consistent Status in Init scripts for use on cloud images: Confirmed Status in “util-linux” package in Ubuntu: Confirmed Bug description: In our cloud images today we launch a getty on ttyS0, as long as it's not in a container. We don't launch a getty on ttyS1-n even if they exist. In MAAS, which also uses cloud images, it would often be useful to put getty's on the serial port that is mapped to remote serial access, such as IPMI SOL. It is however difficult to know which is the correct getty. Broadly speaking I think we should have a consistent approach to getty's. That might mean: * launch a getty on each ttySn that passes an stty test (as per ttyS0 currently) * allow cloud-init to prevent some of those, via vendordata or userdata or default behaviour per-cloud or * launch no getty's on ttyS, but * allow cloud-init to create them based on vendordata or userdata or default behaviour per-cloud To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1359590/+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 1361272] Re: error in udev rules for hyperv net rules
** Patch added: debdiff for 14.10 (Utopic)
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1361272/+attachment/4186809/+files/utopic-debdiff.patch
--
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/1361272
Title:
error in udev rules for hyperv net rules
Status in “systemd” package in Ubuntu:
Triaged
Bug description:
There is an error in the syntax where the MAC address does not match
if the alpha characters are upper case rather than all lower case. For
example, these rules are not matched properly:
ENV{MATCHADDR}==00:0c:29:*|00:50:56:*|00:05:69:*|00:1C:14:* - should be
00:1c:14:*
ENV{MATCHADDR}==00:12:5A:* - should be 00:12:5a:*
ENV{MATCHADDR}==00:17:FA:* - should be 00:17:fa:*
ENV{MATCHADDR}==00:50:F2:* - should be 00:50:f2:*
ENV{MATCHADDR}==Dc:B4:c4:* - should be dc:b4:c4:*
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1361272/+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 1361272] Re: error in udev rules for hyperv net rules
** Patch added: debdiff for 14.04 (Trusty)
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1361272/+attachment/4186819/+files/trusty-debdiff.patch
--
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/1361272
Title:
error in udev rules for hyperv net rules
Status in “systemd” package in Ubuntu:
Triaged
Bug description:
There is an error in the syntax where the MAC address does not match
if the alpha characters are upper case rather than all lower case. For
example, these rules are not matched properly:
ENV{MATCHADDR}==00:0c:29:*|00:50:56:*|00:05:69:*|00:1C:14:* - should be
00:1c:14:*
ENV{MATCHADDR}==00:12:5A:* - should be 00:12:5a:*
ENV{MATCHADDR}==00:17:FA:* - should be 00:17:fa:*
ENV{MATCHADDR}==00:50:F2:* - should be 00:50:f2:*
ENV{MATCHADDR}==Dc:B4:c4:* - should be dc:b4:c4:*
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1361272/+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 1091792] Re: The disk drive for /tmp is not ready yet or not present
Also seeing this on Trusty in the Cloud Images: * Stopping log initial device creation [74G[ OK ] * Starting configure network device [74G[ OK ] * Stopping Mount network filesystems[74G[ OK ] The disk drive for /tmp is not ready yet or not present. keys:Continue to wait, or Press S to skip mounting or M for manual recovery * Starting userspace bootsplash [74G[ OK ] ** Changed in: mountall (Ubuntu) Status: Fix Released = Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mountall in Ubuntu. https://bugs.launchpad.net/bugs/1091792 Title: The disk drive for /tmp is not ready yet or not present Status in “mountall” package in Ubuntu: Confirmed Status in “mountall” source package in Precise: Triaged Status in “mountall” source package in Quantal: Triaged Bug description: I'm using Ubuntu 13.04 dev with mountall 2.46 and on booting I'm getting the message The disk drive for /tmp is not ready yet or not present. But it seems that this message doesn't make any troubles. I'm able to use /tmp without any problems. Maybe something is trying to mount /tmp too early. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1091792/+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
