[Group.of.nepali.translators] [Bug 1686437] Re: glance sync: need keystone v3 auth support

[Scott Moser]

** Changed in: simplestreams (Ubuntu Zesty)
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1686437

Title:
  glance sync: need keystone v3 auth support

Status in simplestreams:
  Fix Committed
Status in simplestreams package in Ubuntu:
  Fix Released
Status in simplestreams source package in Xenial:
  Confirmed
Status in simplestreams source package in Zesty:
  Won't Fix

Bug description:
  When trying to test my changes for bug 1686086, I was unable to auth
  to keystone, which means glance image sync just doesn't work with
  a v3 keystone.

  Related bugs:
   * bug 1719879: swift client needs to use v1 auth prior to ocata
   * bug 1728982: openstack mirror with keystone v3 always imports new images
   * bug 1611987: glance-simplestreams-sync charm doesn't support keystone v3

To manage notifications about this bug go to:
https://bugs.launchpad.net/simplestreams/+bug/1686437/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1762748] Re: Larger than 2 TB disks not possible

[Scott Moser]

** Also affects: cloud-utils (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-utils (Ubuntu)
   Status: New => Confirmed

** Changed in: cloud-utils (Ubuntu)
   Importance: Undecided => Medium

** Changed in: cloud-utils
   Status: Confirmed => Fix Committed

** Also affects: cloud-utils (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cloud-utils (Ubuntu Bionic)
   Importance: Medium
   Status: Confirmed

** Also affects: cloud-utils (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: cloud-utils (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-utils (Ubuntu Artful)
   Status: New => Confirmed

** Changed in: cloud-utils (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-utils (Ubuntu Artful)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1762748

Title:
  Larger than  2 TB disks not possible

Status in cloud-utils:
  Fix Committed
Status in cloud-utils package in Ubuntu:
  Confirmed
Status in cloud-utils source package in Xenial:
  Confirmed
Status in cloud-utils source package in Artful:
  Confirmed
Status in cloud-utils source package in Bionic:
  Confirmed

Bug description:
  Hi,

  We run Openstack and need to provide instances that have very large
  root disks (> 2 TB) and it looks like cloud-init doesn't want to use
  the entire space.

  The regular Ubuntu cloud image has MBR and it doesn't see more than 2
  TB, but even the GPT version (http://cloud-
  images.ubuntu.com/xenial/current/xenial-server-cloudimg-
  amd64-uefi1.img) still fails to see more than 2 TB.

  root@ubuntu-16:~# df -h
  Filesystem  Size  Used Avail Use% Mounted on
  udev121G 0  121G   0% /dev
  tmpfs25G  8.6M   25G   1% /run
  /dev/vda1   2.0T  857M  2.0T   1% /
  tmpfs   121G 0  121G   0% /dev/shm
  tmpfs   5.0M 0  5.0M   0% /run/lock
  tmpfs   121G 0  121G   0% /sys/fs/cgroup
  tmpfs25G 0   25G   0% /run/user/1000

  root@ubuntu-16:~# parted /dev/vda p
  Model: Virtio Block Device (virtblk)
  Disk /dev/vda: 5583GB
  Sector size (logical/physical): 512B/512B
  Partition Table: msdos
  Disk Flags:

  Number  Start   End SizeType File system  Flags
   1  1049kB  2199GB  2199GB  primary  ext4 boot

  root@ubuntu-16:~# lsblk
  NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
  vda253:00  5.1T  0 disk
  └─vda1 253:102T  0 part /
  root@ubuntu-16:~# dpkg -l | grep cloud-init
  ii  cloud-init   17.2-35-gf576b2a2-0ubuntu1~16.04.2   
  all  Init scripts for cloud instances
  ii  cloud-initramfs-copymods 0.27ubuntu1.5
  all  copy initramfs modules into root filesystem for later use
  ii  cloud-initramfs-dyn-netconf  0.27ubuntu1.5
  all  write a network interface file in /run for BOOTIF

  
  The cloud-init.log looks like the disk growing and file system resizing went 
fine:

  018-04-10 14:14:31,332 - stages.py[DEBUG]: Running module growpart () with 
frequency always
  2018-04-10 14:14:31,332 - handlers.py[DEBUG]: start: 
init-network/config-growpart: running config-growpart with frequency always
  2018-04-10 14:14:31,332 - helpers.py[DEBUG]: Running config-growpart using 
lock ()
  2018-04-10 14:14:31,332 - cc_growpart.py[DEBUG]: No 'growpart' entry in cfg.  
Using default: {'mode': 'auto', 'ignore_growroot_disabled': False, 'devices': 
['/']}
  2018-04-10 14:14:31,332 - util.py[DEBUG]: Running command ['growpart', 
'--help'] with allowed return codes [0] (shell=False, capture=True)
  2018-04-10 14:14:31,352 - util.py[DEBUG]: Reading from /proc/1192/mountinfo 
(quiet=False)
  2018-04-10 14:14:31,352 - util.py[DEBUG]: Read 2621 bytes from 
/proc/1192/mountinfo
  2018-04-10 14:14:31,353 - util.py[DEBUG]: Running command 
['systemd-detect-virt', '--quiet', '--container'] with allowed return codes [0] 
(shell=False, capture=True)
  2018-04-10 14:14:31,355 - util.py[DEBUG]: Running command 
['running-in-container'] with allowed return codes [0] (shell=False, 
capture=True)
  2018-04-10 14:14:31,356 - util.py[DEBUG]: Running command 
['lxc-is-container'] with allowed return codes [0] (shell=False, capture=True)
  2018-04-10 14:14:31,357 - util.py[DEBUG]: Reading from /proc/1/environ 
(quiet=False)
  2018-04-10 14:14:31,358 - util.py[DEBUG]: Read 153 bytes from /proc/1/environ
  2018-04-10 14:14:31,358 - util.py[DEBUG]: Reading from /proc/self/status 
(quiet=False)
  2018-04-10 14:14:31,358 - util.py[DEBUG]: Read 906 bytes from 
/proc/self/status
  2018-04-10 14:14:31,358 - util.py[DEBUG]: Reading from 
/sys/class/block/vda1/partition (quiet=False)
  2018-04-10 14:14:31,358 - util.py

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

[Scott Moser]

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Cc-series)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Bionic)
   Importance: Medium
   Status: Confirmed

** Also affects: cloud-init (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Bionic)
   Importance: Medium => Low

** Changed in: cloud-init (Ubuntu Bionic)
   Status: Confirmed => Fix Committed

** Changed in: cloud-init (Ubuntu Cc-series)
   Status: New => Fix Committed

** Changed in: cloud-init (Ubuntu Cc-series)
   Importance: Undecided => Low

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Artful)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Artful)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1767166

Title:
  IBMCloud datasource does not recognize provisioning in debug mode.

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Committed
Status in cloud-init source package in Xenial:
  In Progress
Status in cloud-init source package in Artful:
  Confirmed
Status in cloud-init source package in Bionic:
  Fix Committed
Status in cloud-init source package in CC-Series:
  Fix Committed

Bug description:
  When IBMCloud deploys from a template, artifacts from the 
  provisioning stage are normally cleaned up.  Cloud-init relied'
  on that behavior to determine the provisioning boot from the subsequent
  post-provisioning boot.

  However, when testing, the provisioning stage will leave artifacts
  in place (/root/provisioningConfiguration.cfg).  This caused cloud-init
  to permenantly believe that it was in the provisioning stage.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1767166/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1761240] Re: SRU pollinate 4.32

[Scott Moser]

** Also affects: pollinate (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: pollinate (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Changed in: pollinate (Ubuntu Cosmic)
   Status: New => Fix Released

** Changed in: pollinate (Ubuntu Cosmic)
   Importance: Undecided => Low

** Changed in: pollinate (Ubuntu Trusty)
   Importance: Undecided => Medium

** Changed in: pollinate (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: pollinate (Ubuntu Artful)
   Importance: Undecided => Medium

** Changed in: pollinate (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: pollinate (Ubuntu Trusty)
   Status: New => Confirmed

** Changed in: pollinate (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: pollinate (Ubuntu Artful)
   Status: New => Confirmed

** Changed in: pollinate (Ubuntu Bionic)
   Status: New => Confirmed

** Changed in: pollinate (Ubuntu Cosmic)
 Assignee: (unassigned) => Scott Moser (smoser)

** Changed in: pollinate (Ubuntu Trusty)
 Assignee: (unassigned) => Chad Smith (chad.smith)

** Changed in: pollinate (Ubuntu Xenial)
 Assignee: (unassigned) => Chad Smith (chad.smith)

** Changed in: pollinate (Ubuntu Artful)
 Assignee: (unassigned) => Chad Smith (chad.smith)

** Changed in: pollinate (Ubuntu Bionic)
 Assignee: (unassigned) => Chad Smith (chad.smith)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1761240

Title:
  SRU pollinate 4.32

Status in pollinate package in Ubuntu:
  Fix Released
Status in pollinate source package in Trusty:
  Confirmed
Status in pollinate source package in Xenial:
  Confirmed
Status in pollinate source package in Artful:
  Confirmed
Status in pollinate source package in Bionic:
  Confirmed
Status in pollinate source package in Cosmic:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  The key change is that the user agent string as of Bionic now
  contains the contents of systemd-detect-virt and /etc/cloud/build.info.
  In aggregate, this gives us important usage data to detect improvements
  and regressions in Ubuntu boot times.

  [Test Case]
  Launch a privileged container with:

  1. lxc launch ubuntu-daily:xenial -c security.privileged=true x1-priv
  2. lxc exec x1-priv -- apt update && apt -y install pollen

  Run a local pollen server and have the pollinate (client) connect with
  that via:

  3. lxc exec x1-priv -- pollinate -r --insecure -s https://localhost

  Then check in /var/log/syslog for the client user-agent string. On
  systems without the updated pollinate client, the USER_AGENT value
  does not include virt:

  root@x1-priv:~# grep pollen /var/log/syslog | grep -c virt
  0
  root@x1-priv:~#

  After upgrading to the newer client, virt is now present in the pollen
  entries:

  root@x1-priv:~# grep pollen /var/log/syslog | grep -c virt
  2
  root@x1-priv:~#

  [Regression Potential]
  The script runs with 'set -e', that means that the 'pollinate' script
  will exit failure if either of the commands or files above fail. These
  scenarios seem unlikely, especially in Ubuntu environments.

  === End SRU Template ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pollinate/+bug/1761240/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1774666] Re: Bond interfaces stuck at 1500 MTU on Bionic

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1774666

Title:
  Bond interfaces stuck at 1500 MTU on Bionic

Status in cloud-init:
  Fix Released
Status in MAAS:
  Invalid
Status in cloud-init package in Ubuntu:
  Fix Released
Status in netplan.io package in Ubuntu:
  Confirmed
Status in cloud-init source package in Xenial:
  New
Status in netplan.io source package in Xenial:
  Invalid
Status in cloud-init source package in Artful:
  New
Status in netplan.io source package in Artful:
  Invalid
Status in cloud-init source package in Bionic:
  New
Status in netplan.io source package in Bionic:
  Invalid
Status in cloud-init source package in Cosmic:
  Fix Released
Status in netplan.io source package in Cosmic:
  Confirmed

Bug description:
  When deploying a machine through MAAS with bonded network interfaces,
  the bond does not have a 9000 byte MTU applied despite the attached
  VLANs having had a 9000 MTU explicitly set. The MTU size is set on the
  bond members, but not on the bond itself in Netplan. Consequently,
  when the bond is brought up, the interface MTU is decreased from 9000
  to 1500. Manually changing the interface MTU after boot is successful.

  This is not observed when deploying Xenial on the same machine. The
  bond comes up at the expected 9000 byte MTU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1774666/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1770712] Re: It would be nice if cloud-init provides full version in logs

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1770712

Title:
  It would be nice if cloud-init provides full version in logs

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Artful:
  Confirmed
Status in cloud-init source package in Bionic:
  Confirmed
Status in cloud-init source package in Cosmic:
  Fix Released

Bug description:
  Cloud-init rsyslog has the major version of cloud-init:

  May 11 17:40:51 maas-enlisting-node cloud-init[550]: Cloud-init v.
  18.2 running 'init-local' at Fri, 11 May 2018 17:40:47 +. Up 15.63
  seconds.

  
  However, it would be nice if it places the whole version, so that we can now 
exactly what version of cloud-init its running, e.g:

  May 11 17:40:51 maas-enlisting-node cloud-init[550]: Cloud-init v.
  18.2 (27-g6ef92c98-0ubuntu1~18.04.1) running 'init-local' at Fri, 11
  May 2018 17:40:47 +. Up 15.63 seconds.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1770712/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1766401] Re: full config file wiped after apt-upgrade issued

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1766401

Title:
  full config file wiped after apt-upgrade issued

Status in cloud-images:
  New
Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Artful:
  Fix Released
Status in cloud-init source package in Bionic:
  Confirmed
Status in cloud-init source package in Cosmic:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  Upgrades of cloud-init on official Ubuntu 16.04 and 17.10 images
  running on IBM public cloud will be unreachable after a reboot.

  This is because cloud-init incorrectly recognizes the newly added
  'IBMCloud' as the datasource to use and skips use of the previously used
  ConfigDrive or NoCloud datasource.  This is because
  a.) Official 16.04 and 17.10 images of Ubuntu have seeded data
   in their /var/lib/cloud/seed/ directory that was used on first
   boot and should be continued to be used.
  b.) IBMCloud's datasource in some scenarios appears looks similar
   to that of Config Drive.  The version of cloud-init in xenial and
   artful checks to disable config-drive in order to identify the
   IBMCloud datasource.  That should not happen unless the IBMCloud
   datasource is enabled, which is configured off in those images.

  The fix is to continue using the existing datasource on those images.

  [Test Case]
   * Launch an image on IBM public cloud.
   * add -proposed
   * apt-get update && apt-get install cloud-init
   * reboot
   * ssh back in

  If you are able to ssh back in, then this bug has been fixed.

  [Regression Potential]
  This specific fix is tightly contained down the path involved in
  IBM cloud.   The most likely failure scenario would be failure
  in 18.04 images which do not have the additional datasources built
  into the images.

  [Other Info]
  Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=11172924

  === End SRU Template ===

  
  file: 50-cloud-init.cfg wiped of it's initial (working) configuration after a 
standard apt-upgrade was issued.

  Cloud provider is SoftLayer.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1766401/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1580534] Re: Signature verification is too slow

[Scott Moser]

This bug is believed to be fixed in simplestreams in version 0.1.0. If
this is still a problem for you, please make a comment and set the state
back to New

Thank you.

** Changed in: simplestreams
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1580534

Title:
  Signature verification is too slow

Status in simplestreams:
  Fix Released
Status in simplestreams package in Ubuntu:
  Fix Released
Status in simplestreams source package in Xenial:
  Fix Released

Bug description:
  [Impact]

  When running against http://cloud-
  
images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:download.sjson,
  read_signed() in simplestreams/utils.py seems to take minutes (402
  seconds in my instrumented timing) running 100% CPU. At the time of my
  test, download.sjson is 451737 bytes in 1870 lines.

  This makes a uvtool sync virtually unusable on Xenial.

  [Development Fix]

  The culprit is the constant += of a string as it is read in. This is
  inefficient in Python as each += results in a new string that has to
  be allocated. Keeping the lines in a list and joining them at the end
  reduces the time to 0.127 seconds.

  [Stable Fix]

  No change cherry-pick of fix committed upstream.

  [Test Case]

  On a machine with reasonable connectivity, run: uvt-simplestreams-
  libvirt sync release=xenial arch=amd64

  Expected result: takes a few seconds with minimal CPU use.

  Actual result: takes more than five minutes with CPU pegged at 100%.

  Scott also has a more direct test case here:
  http://paste.ubuntu.com/16377613/

  [Original Notes]

  Merge proposal to follow. I'm filing this bug to track a Xenial SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/simplestreams/+bug/1580534/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1578622] Re: glance do not require hypervisor_mapping

[Scott Moser]

This bug is believed to be fixed in simplestreams in version 0.1.0. If
this is still a problem for you, please make a comment and set the state
back to New

Thank you.

** Changed in: simplestreams
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1578622

Title:
  glance do not require hypervisor_mapping

Status in simplestreams:
  Fix Released
Status in simplestreams package in Ubuntu:
  Fix Released
Status in simplestreams source package in Xenial:
  Confirmed
Status in simplestreams source package in Yakkety:
  Fix Released

Bug description:
  currently the glance mirror requires hypervisor_mapping config in the api.
  Better to not required that as a library consumer would not necessarily 
provide it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/simplestreams/+bug/1578622/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1686086] Re: glance mirror and nova-lxd need support for squashfs images

[Scott Moser]

This bug is believed to be fixed in simplestreams in version 0.1.0. If
this is still a problem for you, please make a comment and set the state
back to New

Thank you.

** Changed in: simplestreams
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1686086

Title:
  glance mirror and nova-lxd need support for squashfs images

Status in nova-lxd:
  Fix Released
Status in simplestreams:
  Fix Released
Status in simplestreams package in Ubuntu:
  Fix Released
Status in simplestreams source package in Xenial:
  Confirmed
Status in simplestreams source package in Artful:
  Confirmed

Bug description:
  Zesty does not produce root.tar.gz or root.tar.xz images.
  This means that for a nova lxd cloud we need some changes to support zesty 
images.

   * simplestreams will need to learn that lxd can support a 'squashfs' image 
type, and how to upload that to glance (what 'disk_format' option to put on the 
glance image).
   * nova-lxd will need to know that it can handle squashfs images (it may 
already do that)
   * nova-lxd will possibly need to do something special with that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova-lxd/+bug/1686086/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1686437] Re: [SRU] glance sync: need keystone v3 auth support

[Scott Moser]

This bug is believed to be fixed in simplestreams in version 0.1.0. If
this is still a problem for you, please make a comment and set the state
back to New

Thank you.

** Changed in: simplestreams
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1686437

Title:
  [SRU] glance sync: need keystone v3 auth support

Status in simplestreams:
  Fix Released
Status in simplestreams package in Ubuntu:
  Fix Released
Status in simplestreams source package in Xenial:
  Fix Committed
Status in simplestreams source package in Zesty:
  Won't Fix

Bug description:
  [Impact]

  simplestreams can't sync images when keystone is configured to use v3,
  keystone v2 is deprecated since mitaka[0] (the version shipped with
  xenial)

  The OpenStack Keystone charm supports v3 only since Queens and
  later[1]

  [Test Case]

  * deploy a openstack environment with keystone v3 enabled
- get a copy of the bundle available at 
http://paste.ubuntu.com/p/hkhsHKqt4h/ , this bundle deploys a minimal version 
of xenial-mitaka.

  Expected result:

  - "glance image-list" lists trusty and xenial images
  - the file glance-simplestreams-sync/0:/var/log/glance-simplestreams-sync.log 
 contains details of the images pulled from cloud-images.u.c (example: 
https://pastebin.ubuntu.com/p/RWG8QrkVDz/ )

  Actual result:

  - "glance image-list" is empty
  - the file glance-simplestreams-sync/0:/var/log/glance-simplestreams-sync.log 
 contains the following stacktrace
  INFO  * 04-09 22:04:06 [PID:14571] * root * Calling DryRun mirror to get 
item list
  ERROR * 04-09 22:04:06 [PID:14571] * root * Exception during syncing:
  Traceback (most recent call last):
File "/usr/share/glance-simplestreams-sync/glance-simplestreams-sync.py", 
line 471, in main
  do_sync(charm_conf, status_exchange)
File "/usr/share/glance-simplestreams-sync/glance-simplestreams-sync.py", 
line 232, in do_sync
  objectstore=store)
File "/usr/lib/python2.7/dist-packages/simplestreams/mirrors/glance.py", 
line 374, in __init__
  super(ItemInfoDryRunMirror, self).__init__(config, objectstore)
File "/usr/lib/python2.7/dist-packages/simplestreams/mirrors/glance.py", 
line 126, in __init__
  self.keystone_creds = openstack.load_keystone_creds()
File "/usr/lib/python2.7/dist-packages/simplestreams/openstack.py", line 
61, in load_keystone_creds
  raise ValueError("(tenant_id or tenant_name)")
  ValueError: (tenant_id or tenant_name)

  
  [Regression Potential]

  * A possible regression will manifest itself figuring out if v2 or v3
  should be used, after the connection is made there are no further
  changes introduced by this SRU

  
  [Other Info]

  When trying to test my changes for bug 1686086, I was unable to auth
  to keystone, which means glance image sync just doesn't work with
  a v3 keystone.

  Related bugs:
   * bug 1719879: swift client needs to use v1 auth prior to ocata
   * bug 1728982: openstack mirror with keystone v3 always imports new images
   * bug 1611987: glance-simplestreams-sync charm doesn't support keystone v3

  [0] 
https://docs.openstack.org/releasenotes/keystone/mitaka.html#deprecation-notes
  [1] 
https://docs.openstack.org/charm-guide/latest/1802.html#keystone-support-is-v3-only-for-queens-and-later

To manage notifications about this bug go to:
https://bugs.launchpad.net/simplestreams/+bug/1686437/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1578624] Re: [SRU] set custom user agent

[Scott Moser]

This bug is believed to be fixed in simplestreams in version 0.1.0. If
this is still a problem for you, please make a comment and set the state
back to New

Thank you.

** Changed in: simplestreams
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1578624

Title:
  [SRU] set custom user agent

Status in simplestreams:
  Fix Released
Status in simplestreams package in Ubuntu:
  Fix Released
Status in simplestreams source package in Trusty:
  Confirmed
Status in simplestreams source package in Wily:
  Confirmed
Status in simplestreams source package in Xenial:
  Fix Released
Status in simplestreams source package in Yakkety:
  Fix Released

Bug description:
  [Impact]
  In order for web service to aggregate custom logs, simplestreams client 
should identify itself via user-agent. 

  This is required by MAAS to properly identify itself when downloading
  images.

  [Test Case]
  1. Install version of simplestreams
  2. Try to download streams from a custom source
  3. Check apache2 logs like:

  192.168.122.1 - - [29/Nov/2016:21:55:03 -0500] "GET /old-
  images/streams/v1/index.json HTTP/1.1" 200 740 "-" "python-
  simplestreams/0.1"

  [Regression Potential]
  None. This doesn't impact the ability for simplestreams to work. It just 
ensures the client identifies itself.

To manage notifications about this bug go to:
https://bugs.launchpad.net/simplestreams/+bug/1578624/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1777912] Re: sru cloud-init (18.2-4-g05926e48-0ubuntu1) to (18.3-9ubuntu1)

[Scott Moser]

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Artful)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1777912

Title:
  sru cloud-init (18.2-4-g05926e48-0ubuntu1) to (18.3-9ubuntu1)

Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Committed
Status in cloud-init source package in Artful:
  Fix Committed
Status in cloud-init source package in Bionic:
  Fix Committed

Bug description:
  UPDATE: SRU regression found during 18.3.0 -proposed validation. fix
  is queued present in 18.3.9 for bug https://bugs.launchpad.net/cloud-
  init/+bug/1780481.

  Updated description of changes for minor SRU-update to 18.3 targets
  Xenial, Artful and Bionic.

   18.2.4 -> 18.3 changeset contains

   - OpenStack now runs at local time frame network config can be rendered from 
network_data.json if configured "apply_network_config: true".
   - Fix utf-8 content in user-data (LP: #1768600)
   - many SmartOS improvements

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

  - Explicitly prevent `sudo` access for user module [Jacob Bednarz]
  - lxd: Delete default network and detach device if lxd-init created them.
  - openstack: avoid unneeded metadata probe on non-openstack platforms
  - stages: fix tracebacks if a module stage is undefined or empty
    [Robert Schweikert]
  - Be more safe on string/bytes when writing multipart user-data to disk.
  - Fix get_proc_env for pids that have non-utf8 content in environment.
  - netplan: fix mtu if provided by network config for all rendered types
  - subp: support combine_capture argument.
  - util: add get_linux_distro function to replace platform.dist
  - Enable SmartOS network metadata to work with netplan via per-subnet
    routes [Dan McDonald]
  - openstack: Allow discovery in init-local using dhclient in a sandbox.
  - yaml_load/schema: Add invalid line and column nums to error message
  - Azure: Ignore NTFS mount errors when checking ephemeral drive
    [Paul Meyer]
  - Update version.version_string to contain packaged version.
  - cc_mounts: Do not add devices to fstab that are already present.
    [Lars Kellogg-Stedman]
  - ds-identify: ensure that we have certain tokens in PATH.
  - read_file_or_url: move to url_helper, fix bug in its FileResponse.
  - ds-identify: recognize container-other as a container, test SmartOS.
  - cloud-config.service: run After snap.seeded.service.
  - SmartOS: fix get_interfaces for nics that do not have addr_assign_type.
  - azure: Add reported ready marker file. [Joshua Chan]
  - FreeBSD: Invoke growfs on ufs filesystems such that it does not prompt.
  - netinfo: fix netdev_pformat when a nic does not have an address 
assigned.
  - collect-logs: add -v flag, write to stderr, limit journal to single 
boot.
  - IBMCloud: Disable config-drive and nocloud only if IBMCloud is enabled.
  - Add reporting events and log_time around early source of blocking time
   --- Addtional changelog delta for Xenial, Artful 
  - net: detect unstable network names and trigger a settle if needed
  - DataSourceSmartOS: add locking of serial device. [Mike Gerdts]
  - DataSourceSmartOS: sdc:hostname is ignored [Mike Gerdts]
  - DataSourceSmartOS: list() should always return a list [Mike Gerdts]
  - schema: in validation, raise ImportError if strict but no jsonschema.
  - set_passwords: Add newline to end of sshd config, only restart if
    updated.
  - Schema: do not warn on duplicate items in commands.
  - net: Depend on iproute2's ip instead of net-tools ifconfig or route
  - DataSourceSmartOS: fix hang when metadata service is down [Mike Gerdts]
  - DataSourceSmartOS: change default fs on ephemeral disk from ext3 to
    ext4. [Mike Gerdts]
  - Implement bash completion script for cloud-init command line
  - renderer: support unicode in render_from_file.
  - Implement ntp client spec with auto support for distro selection
  - Apport: add Brightbox, IBM, LXD, and OpenTelekomCloud to list of clouds.

  [Test Case]
  The following development and SRU process was followed:
  https://wiki.ubuntu.com/CloudinitUpdates

  The cloud-init team will be in charge of attaching the artifacts and
  console ou

[Group.of.nepali.translators] [Bug 1893064] Re: sru cloud-init (20.2-45 to 20.3-0) Xenial, Bionic, and Focal

[Scott Moser]

s: support more lxd image formats (#482) [Paride Legovini]
  - Add update_etc_hosts as default module on *BSD (#479) [Adam Dobrawy]
  - cloudinit: fix tip-pylint failures and bump pinned pylint version (#478)
  - Added BirknerAlex as contributor and sorted the file (#477)
[Alexander Birkner]
  - Update list of types of modules in cli.rst [saurabhvartak1982]
  - tests: use markers to configure disable_subp_usage (#473)
  - Add mention of vendor-data to no-cloud format documentation (#470)
[Landon Kirk]
  - Fix broken link to OpenStack metadata service docs (#467)
[Matt Riedemann]
  - Disable ec2 mirror for non aws instances (#390)
[lucasmoura] (LP: #1456277)
  - cloud_tests: don't pass --python-version to read-dependencies (#465)
  - networking: refactor is_physical from cloudinit.net (#457) (LP: 
#1884619)
  - Enable use of the caplog fixture in pytest tests, and add a
cc_final_message test using it (#461)
  - RbxCloud: Add support for FreeBSD (#464) [Adam Dobrawy]
  - Add schema for cc_chef module (#375) [lucasmoura] (LP: #185)
  - test_util: add (partial) testing for util.mount_cb (#463)
  - .travis.yml: revert to installing ubuntu-dev-tools (#460)
  - HACKING.rst: add details of net refactor tracking (#456)
  - .travis.yml: rationalise installation of dependencies in host (#449)
  - Add dermotbradley as contributor. (#458) [dermotbradley]
  - net/networking: remove unused functions/methods (#453)
  - distros.networking: initial implementation of layout (#391)
  - cloud-init.service.tmpl: use "rhel" instead of "redhat" (#452)
  - Change from redhat to rhel in systemd generator tmpl (#450)
[Eduardo Otubo]
  - Hetzner: support reading user-data that is base64 encoded. (#448)
[Scott Moser] (LP: #1884071)
  - HACKING.rst: add strpath gotcha to testing gotchas section (#446)
  - cc_final_message: don't create directories when writing boot-finished
(#445) (LP: #1883903)
  - .travis.yml: only store new schroot if something has changed (#440)
  - util: add ensure_dir_exists parameter to write_file (#443)
  - printing the error stream of the dhclient process before killing it
(#369) [Moustafa Moustafa]
  - Fix link to the MAAS documentation (#442)
[Paride Legovini] (LP: #1883666)
  - RPM build: disable the dynamic mirror URLs when using a proxy (#437)
[Paride Legovini]
  - util: rename write_file's copy_mode parameter to preserve_mode (#439)
  - .travis.yml: use $TRAVIS_BUILD_DIR for lxd_image caching (#438)
  - cli.rst: alphabetise devel subcommands and add net-convert to list 
(#430)
  - Default to UTF-8 in /var/log/cloud-init.log (#427) [James Falcon]
  - travis: cache the chroot we use for package builds (#429)
  - test: fix all flake8 E126 errors (#425) [Joshua Powers]
  - Fixes KeyError for bridge with no "parameters:" setting (#423)
[Brian Candler] (LP: #1879673)
  - When tools.conf does not exist, running cmd "vmware-toolbox-cmd
config get deployPkg enable-custom-scripts", the return code will
be EX_UNAVAILABLE(69), on this condition, it should not take it as
error. (#413) [chengcheng-chcheng]
  - Document CloudStack data-server well-known hostname (#399) [Gregor 
Riepl]
  - test: move conftest.py to top-level, to cover tests/ also (#414)
  - Replace cc_chef is_installed with use of subp.is_exe. (#421)
[Scott Moser]
  - Move runparts to subp. (#420) [Scott Moser]
  - Move subp into its own module. (#416) [Scott Moser]
  - readme: point at travis-ci.com (#417) [Joshua Powers]
  - New feature flag functionality and fix includes failing silently (#367)
[James Falcon] (LP: #1734939)
  - Enhance poll imds logging (#365) [Moustafa Moustafa]
  - test: fix all flake8 E121 and E123 errors (#404) [Joshua Powers]
  - test: fix all flake8 E241 (#403) [Joshua Powers]
  - test: ignore flake8 E402 errors in main.py (#402) [Joshua Powers]
  - cc_grub_dpkg: determine idevs in more robust manner with grub-probe
(#358) [Matthew Ruffell] (LP: #1877491)
  - test: fix all flake8 E741 errors (#401) [Joshua Powers]
  - tests: add groovy integration tests for ubuntu (#400)
  - Enable chef_license support for chef infra client (#389) [Bipin Bachhao]
  - testing: use flake8 again (#392) [Joshua Powers]
  - enable Puppet, Chef mcollective in default config (#385)
[Mina Galić (deprecated: Igor Galić)] (LP: #1880279)
  - HACKING.rst: introduce .net -> Networking refactor section (#384)
  - Travis: do not install python3-contextlib2 (dropped dependency) (#388)
[Paride Legovini]
  - HACKING: mention that .github-cla-signers is alpha-sorted (#380)
  - Add bipinbachhao as contributor (

[Group.of.nepali.translators] [Bug 1832382] Re: Azure Datasource should use cloud-init builtin agent to provision instead of walinuxagent

[Scott Moser]

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1832382

Title:
  Azure Datasource should use cloud-init builtin agent to provision
  instead of walinuxagent

Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  New

Bug description:
  In Bionic and newer cloud-init uses the built-in agent on Azure to
  negotiate with Azure control plane to obtain the user provided ssh
  keys.

  In Xenial, Cloud-init defers to walinuxagent to do the negotiation.
  Given the amount of time we have had on Bionic and other versions and
  also the amount of validation (both functionalities and performance)
  we are comfortable to have Xenial use Cloud-init builtin agent, which
  is the same behavior with Bionic

  For reference, this is the patch that should be removed
  
https://git.launchpad.net/cloud-init/tree/debian/patches/azure-use-walinux-agent.patch?h=ubuntu/xenial

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1832382/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1835509] Re: False warning "The kernel version is not supported." on xenial with -hwe kernels

[Scott Moser]

** Also affects: makedumpfile (Ubuntu Focal)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1835509

Title:
  False warning "The kernel version is not supported."  on xenial with
  -hwe kernels

Status in makedumpfile package in Ubuntu:
  New
Status in makedumpfile source package in Xenial:
  New
Status in makedumpfile source package in Focal:
  New

Bug description:
  [Impact]

  The message appears as when running -hwe kernels (4.15) on Xenial.
  This happens because makedumpfile defines a LATEST_VERSION kernel that 
"officially" 
  supports. 
  Currently, makedumpfile package for xenial has this version set to 4.14.8 and 
this is 
  why it shows this message with 4.15 kernels.

  [Test Case]
  TBD

  [Regression Potential]
  TBD

  [Other]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1835509/+subscriptions


___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)

[Scott Moser]

** Also affects: resolvconf (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Changed in: resolvconf (Ubuntu Zesty)
   Status: New => Triaged

** Changed in: resolvconf (Ubuntu Zesty)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1711760

Title:
  [2.3] resolv.conf is not set (during commissioning or testing)

Status in MAAS:
  Fix Released
Status in resolvconf package in Ubuntu:
  Won't Fix
Status in resolvconf source package in Trusty:
  Fix Released
Status in resolvconf source package in Xenial:
  Fix Released
Status in resolvconf source package in Zesty:
  Triaged

Bug description:
  === Begin SRU Template ===
  [Impact]
  Without this fix applied, dns settings provided to the dhcp response
  in the initramfs are not reflected in the "real root".

  Thus dns resolution does not work. Of most interest was the MAAS use
  case of the 'root=http://<>/squashfs' use case.

  MAAS 2.3 uses this for the installation environment and also the rescue
  environment.  In most cases the 14.04 specific fix will only apply
  to installation as 16.04 is most likely to be used in rescue mode.

  [Test Case]
  There are two tests for this.

  a.) local/non-MAAS test
  Download the test case attached.
  Run it and follow the instructions.
  Login to the guest (ubuntu:password), and inspect /etc/resolv.conf
  without the fix there would be no data in /etc/resolv.conf.  With the
  fix you should see 'nameserver 10.0.2.2' and 'search mydomain.com bar.com'

  b.) MAAS test.
  For the full maas test, you need to build a image stream for maas
  with the fix included in the squashfs image and then import that
  stream to maas and use the rescue environment and verify dns.
  This process is beyond the scope of the SRU template, but is
  described partially in
    
http://bazaar.launchpad.net/~maas-images-maintainers/maas-images/maas-ephemerals/view/head:/README

  [Regression Potential]
  Regression potential should be very low.  There are gates in the code
  to make sure that this code is inactive other than when it is explicitly
  enabled.

  net-interface-handler will exit without doing anything unless:
  a.) there exist files /run/net-$INTERFACE.conf or /run/net6-$INTERFACE.conf
  and these files have non-empty values for a variable mentioned above.
  (These files are written by the initramfs code when 'ip=' is seen).

  b.) this is not a container.
    trusty uses 'running-in-container' to determine this.
    xenial uses 'systemd-detect-virt'

  c.) there is no OPENISCSI_MARKER file (/run/initramfs/open-iscsi.interface)
  if open-iscsi has written this file due to open-iscsi root, then it
  will handle this functionality. resolvconf will get out of the way.

  d.) /proc/cmdline contains cloud-config-url=* or 'rc-initrd-dns'
  This lowers the scope of changes in runtime to cases with where either the
  new flag is seen or cloud-config-url is passed. The MAAS use case will
  contain this flag.

  [Other Info]

  === End SRU Template ===

  Using MAAS 2.3, during commissioning (and likely in the rest of the
  ephemeral environment) we have noticed that resolv.conf is not set
  with the DNS server.

  That said, during the commissioning process, MAAS does not send any
  metadata to cloud-init to configure the network, rather, we expect the
  image to boot from the network via DHCP. So, cloud-init writes:

  ubuntu@manual:~$ 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

  # control-manual ens3
  iface ens3 inet dhcp
  broadcast 192.168.122.255
  dns-nameservers 192.168.122.2
  gateway 192.168.122.1
  netmask 255.255.255.0

  Which correctly includes the DNS server. However:

  ubuntu@manual:~$ ping google.com
  ping: unknown host google.com

  If restart the interfacE:

  ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
  ifdown: interface ens3 not configured
  Internet Systems Consortium DHCP Client 4.3.3
  Copyright 2004-2015 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/ens3/52:54:00:ea:57:31
  Sending on   LPF/ens3/52:54:00:ea:57:31
  Sending on   Socket/fallback
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
  DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 
(xid=0x5403eb14)
  DHCPOFFER of 192.168.122.195 from 192.168.122.2
  DHCPACK of 1

[Group.of.nepali.translators] [Bug 1735331] Re: ec2: zesty tempfile sandbox dhclient.pid file can't be created

[Scott Moser]

This bug is believed to be fixed in cloud-init in 1705804. If this is
still a problem for you, please make a comment and set the state back to
New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1735331

Title:
  ec2: zesty tempfile sandbox dhclient.pid file can't be created

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Fix Released
Status in cloud-init source package in Bionic:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  Ec2 instances could hit race condition with tempdir removal where dhclient 
doesn't write a pidfile and DataSourceEc2Local hits a traceback trying to read 
that non-existent pidfile. This traceback causes the instance to fallback and 
get discovered in init-network stage as DataSourceEc2. The thrashing costs 
instances a couple extra seconds to boot while re-discovering in a different 
stage.

  [Test Case]

  # Launch instance under test
  $ for release in xenial zesty artful; do
  echo "Handling $release";
  launch-ec2 --series $release;
  ssh ubuntu@ cat /run/cloud-init/result.json;
  ssh ubuntu@ grep Trace /var/log/cloud-init.log;
  ssh ubuntu@ sudo sed 's/ $release / $release-proposed /' 
/etc/apt/sources.list;
  ssh ubuntu@ sudo apt update;
  ssh ubuntu@ sudo apt install cloud-init;
  # Show upgrade without restart doesn't break
  ssh ubuntu@ sudo cloud-init init;
  # Show clean install doesn't break
  ssh ubuntu@ 'sudo rm -rf /var/log/cloud-init* 
/var/lib/cloud; sudo reboot'
  ssh ubuntu@ 'sudo cat /run/cloud-init/result.json
  ssh ubuntu@ 'sudo grep Trace /var/log/cloud-init*';
  # Asssert no intermittent tracebacks from dhcp_discovery and no leaked 
dhcpclients;
  ssh ubuntu@ "sudo python3 -c 'from cloudinit.net.dhcp import 
maybe_perform_dhcp_discovery; maybe_perform_dhcp_discovery()";
  sudo ps -afe |grep dhclient;
    done

  [Regression Potential]
  Regression would still result in Tracebacks in DataSourceEc2Local which would 
cause cloud-init to fallback to DataSourceEc2 in init-network stage.

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=7acc9e68f
  === End SRU Template ===

  === Original Description ===

  Saw an issue once on EC2 zesty image with 17.1.41 during SRU testing.

  Looks like we hit an inability to create the pid file (from syslog)

   syslog
  Nov 30 04:20:35 ip-10-0-20-176 cloud-init[440]: Cloud-init v. 17.1 running 
'init-local' at Thu, 30 Nov 2017 04:20:32 +. Up 7.16 seconds.
  Nov 30 04:20:35 ip-10-0-20-176 cloud-init[440]: 2017-11-30 04:20:32,768 - 
util.py[WARNING]: Getting data from  failed
  Nov 30 04:20:35 ip-10-0-20-176 dhclient[669]: Can't create 
/var/tmp/cloud-init/cloud-init-dhcp-hnatdvwi/dhclient.pid: No such file or 
directory

   end syslog

  A traceback when trying to read the temporary pid file that was
  created  by our dhclient run during Ec2Local setup. Maybe we exited
  out of the dhcp run before we could read the pid file?

  ...
  2017-11-30 04:20:32,738 - util.py[DEBUG]: Running command ['ip', 'link', 
'set', 'dev', 'eth0', 'up'] with allowed return codes [0] (shell=False, 
capture=True)
  2017-11-30 04:20:32,744 - util.py[DEBUG]: Running command 
['/var/tmp/cloud-init/cloud-init-dhcp-hnatdvwi/dhclient', '-1', '-v', '-lf', 
'/var/tmp/cloud-init/cloud-init-dhcp-hnatdvwi/dhcp.leases', '-pf', 
'/var/tmp/cloud-init/cloud-init-dhcp-hnatdvwi/dhclient.pid', 'eth0', '-sf', 
'/bin/true'] with allowed return codes [0] (shell=False, capture=True)
  2017-11-30 04:20:32,768 - util.py[DEBUG]: Reading from 
/var/tmp/cloud-init/cloud-init-dhcp-hnatdvwi/dhclient.pid (quiet=False)
  2017-11-30 04:20:32,768 - handlers.py[DEBUG]: finish: 
init-local/search-Ec2Local: FAIL: no local data found from DataSourceEc2Local
  2017-11-30 04:20:32,768 - util.py[WARNING]: Getting data from  failed
  2017-11-30 04:20:32,768 - util.py[DEBUG]: Getting data from  failed
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 
332, in find_source
  if s.get_data():
    File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceEc2.py", 
line 378, in get_data
  return super(DataSourceEc2Local, self).get_data()
    File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceEc2.py", 
line 100, in get_data
  self.fallback_interface)
    File "/usr/lib/python3/dist-packages/cloudinit/net/dhcp.py", line 57, in 
maybe_perform_dhcp_discovery
  return dhcp_discovery(dhclient_path, nic, tdir)
 

[Group.of.nepali.translators] [Bug 1724354] Re: WARNING in logs due to missing python-jsonschema

[Scott Moser]

This bug is believed to be fixed in cloud-init in 1705804. If this is
still a problem for you, please make a comment and set the state back to
New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1724354

Title:
  WARNING in logs due to missing python-jsonschema

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  If python3-jsonschema is not installed, then WARNING will be written
  to console log and to /var/log/cloud-init.log with certain cloud-config
  data is provided.

  python3-jsonschema is a soft dependency of cloud-init and specically
  not listed in 16.04 and 17.04 packaging as it was not a dependency in
  the versions of cloud-init originally released then.

  The WARNING is only "scary", and has no negative affect on runtime.

  [Test Case]
  The change for this bug modified the integration test suite so
  that WARN in /var/log/cloud-init would trigger a test failure.
  Running the integration testsuite would show this failure with
  that test now in place.

  A manual test can be done though as follows.

  $ cat > my.cfg < /run/bootcmd-works"
  runcmd:
    - "cat /proc/uptime > /run/runcmd-works"
  EOF

  $ for r in zesty xenial; do
     lxc init $r-proposed $r-info &&
     lxc-pstart $r-info \
   sh -c 'dpkg-query --show cloud-init; cat /etc/cloud/build.info' &&
   lxc delete --force $r-info; done

  # show container info just to show versions.
  $ for r in zesty xenial; do
     lxc init $r-proposed $r-info >/dev/null 2>&1 && echo == $r-info == &&
     lxc-pstart $r-info -- \
    sh -xc 'dpkg-query --show cloud-init; cat /etc/cloud/build.info' &&
     lxc delete --force $r-info; done

  ## launch an instance of each release and grab logs.
  $ for rel in xenial zesty; do
     n=$rel-1724354
     lxc launch $rel-proposed $n "--config=user.user-data=$(cat my.cfg)"
     lxc exec $n -- sh -c \
    'while ! [ -e /run/cloud-init/result.json ]; do echo -n .; sleep 1; 
done; echo'
     lxc file pull $n/var/log/cloud-init.log $n-cloud-init.log
  done

  # check that 1724354 is installed.
  $ grep "WARN" *-1724354-cloud-init.log

  [Regression Potential]
  Highest chance for regression would be in the integration test
  suite.  The only change in code path is in cloudinit/config/schema.py:
   - logging.warning(
   + logging.debug(

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=41152f10ddb

  Note, this is not specifically in artful at this point, but also
  note that this bug does not affect artful.  Artful's package
  has a depends on python3-jsonschema, so it will not demonstrate
  the issue.

  === End SRU Template ===

  $ dpkg-query --show cloud-init
  cloud-init  17.1-18-gd4f70470-0ubuntu1~16.04.1

  $ sudo cat /var/lib/cloud/instance/user-data.txt
  #cloud-config
  bootcmd:
    - "cat /proc/uptime > /run/bootcmd-works"
  runcmd:
    - "cat /proc/uptime > /run/runcmd-works"

  $ grep WARN /var/log/cloud-init.log
  2017-10-17 19:08:10,509 - schema.py[WARNING]: Ignoring schema validation. 
python-jsonschema is not present
  2017-10-17 19:08:10,586 - schema.py[WARNING]: Ignoring schema validation. 
python-jsonschema is not present
  2017-10-17 19:08:14,651 - schema.py[WARNING]: Ignoring schema validation. 
python-jsonschema is not present

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1724354/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1724951] Re: Ntp schema definition permits empty ntp cloud-config, but code disallows

[Scott Moser]

This bug is believed to be fixed in cloud-init in 1705804. If this is
still a problem for you, please make a comment and set the state back to
New

Thank you.

** Changed in: cloud-init
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1724951

Title:
  Ntp schema definition permits empty ntp cloud-config, but code
  disallows

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Fix Released

Bug description:
  http://pad.lv/1724951
  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1724951

  === Begin SRU Template ===
  [Impact]
  Customers who provide the following cloud-config will get a Runtime error
  #cloud-config
  ntp:

  The expected behavior, per docs, is that an empty ntp configuration will 
result in
  "4 pools will be used in the format {0-3}.{distro}.pool.ntp.org.".

  [Test Case]

  if [ ! -f './lxc-proposed-snapshot' ]; then
    wget 
https://raw.githubusercontent.com/cloud-init/ubuntu-sru/master/bin/lxc-proposed-snapshot;
    chmod 755 lxc-proposed-snapshot;
  fi

  # 1. Provide a empty ntp configuration to cloud-init
  cat > install-ntp.conf 

[Group.of.nepali.translators] [Bug 1721579] Re: azure: remove sriov device configuration

[Scott Moser]

This bug is believed to be fixed in cloud-init in 1705804. If this is
still a problem for you, please make a comment and set the state back to
New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1721579

Title:
  azure: remove sriov device configuration

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Fix Released

Bug description:
  Microsoft has requested that we remove the VF/sriov specific changes
  we made to the Azure datasource under private bug 1695119.

  There is another solution in place now in the linux kernel that
  will suffice.

  Essentially, this means backing out much of the commit
   ebc9ecbc8a76bdf511a456fb72339a7eb4c20568
  https://git.launchpad.net/cloud-init/commit/?id=ebc9ecbc8a7

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1721579/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1728152] Re: EC2 IPv4 and IPv6 Dual Stack Does Not work when instance is not assigned public IPv4 address

[Scott Moser]

This bug is believed to be fixed in cloud-init in 1705804. If this is
still a problem for you, please make a comment and set the state back to
New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1728152

Title:
  EC2 IPv4 and IPv6 Dual Stack Does Not work when instance is not
  assigned public IPv4 address

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Fix Released
Status in cloud-init source package in Bionic:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  Support for configuration of IPV6 addresses on the primary network
  interface in EC2 changed behavior of the automatic network configuration.
  This changed behavior in 2 ways:
  a.) Instances with only a private ipv4 address would not get *any* ipv4
  address.

  b.) Instances with multiple NICs attached at boot would get all NICs
  configured. Previously only the primary network interface would be
  configured by cloud-init.

  'b' is not necessarily a bug for Artful.  A new release can bring new
  behavior.  However, the change of behavior was not intended and not desired
  for an SRU.  In an effort to keep this behavior consistent across 16.04+
  we will be changing the behavior of Artful to only configure the primary
  network interface.

  [Test Case]
  To verify this code is fixed for all cases involved:

  1. Verify that instances without public ipv4 get an ipv4 address.
   * Launch an instance on EC2 without a public IPV4 address.
   * Verify the instance has its Ipv4 address configured via ssh and
 checking 'ip' output.

  2. Verify no regression is done to public systems.
   * Launch an instance on EC2 with a public IPV4 address.
   * Verify the instance has its ipv4 address configured.

  3. Verify only the primary NIC is configured (17.10 only)
   * Launch an instance on EC2 with multiple  nics configured.
   * Verify that only the primary nic has configuration by default.

  For each of the above, verification entails inspection of
  network config (/etc/network/interfaces.d/* or /etc/netplan/)
  and also network state ('ip a' output).

  [Regression Potential]
  Regression in this area of code is certainly limited to EC2,
  and most likely limited to network configuration.

  Complete failure would show itself as no networking at all and
  a WARNING or stack trace on the console logs.

  [Other Info]
  Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=XX

  === End SRU Template ===

  With the following cloud-init configuration:
  system_info:
    network:
  renderers: ['netplan', 'eni', 'sysconfig']

  network:
    version: 2
    ethernets:
  id0:
  match:
  name: e*
  dhcp4: true
  dhcp6: true

  with version  17.1-18-gd4f70470-0ubuntu1 on ami-36a8754c, it writes out the 
following network configuration:
  # 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:
  dhcp6: true
  match:
  macaddress: 02:14:13:66:8a:66
  set-name: ens3

  

  This instance is in a (default) VPC with a private IPv4 address and no
  public IPv4 addresses.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1728152/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1718681] Re: Package copyright file omits Apache 2 license

[Scott Moser]

This bug is believed to be fixed in cloud-init in 1705804. If this is
still a problem for you, please make a comment and set the state back to
New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1718681

Title:
  Package copyright file omits Apache 2 license

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Fix Released

Bug description:

  http://pad.lv/1718681
  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1718681

  === Begin SRU Template ===
  [Impact]
  Apache 2 license terms missing from /usr/share/doc/cloud-init/copyright

  [Test Case]

  
  if [ ! -f './lxc-proposed-snapshot' ]; then
    wget 
https://raw.githubusercontent.com/cloud-init/ubuntu-sru/master/bin/lxc-proposed-snapshot;
    chmod 755 lxc-proposed-snapshot;
  fi

  for release in xenial zesty; do
ref=$release-proposed;
echo "$release START --";
lxc-proposed-snapshot -p -P $release $ref;
lxc init $ref test-$release;
lxc start test-$release;
lxc exec test-$release -- grep Apache -A 1 
/usr/share/doc/cloud-init/copyright
  done

  [Regression Potential]
  None

  [Other Info]
  Upstream commists at
https://git.launchpad.net/cloud-init/commit/?id=a88768a6048
https://git.launchpad.net/cloud-init/commit/?id=02b6994803b
  === End SRU Template ===

  
   Original bug description ===
  In the Ubuntu package source, packages/debian/copyright says the License is 
either GPL-3 or Apache 2.0 and includes summaries of both licenses with links 
to the full license texts.

  debian/copyright says that the license is either GPL-3 or Apache 2.0,
  but only includes the GPL-3 summary and link (together with the MIT
  licence terms for cloudinit/boto_utils.py)

  I believe the terms of the Apache licence and the terms the LICENSE
  file require the inclusion of the Apache 2 summary and link in the
  debian/copyright file.

  cloud-init.tar is not relevant to this issue.

  Seen on Azure
  $ dpkg-query -W -f='${Version}' cloud-init
  0.7.9-233-ge586fe35-0ubuntu1~16.04.1
  $ cat /usr/share/doc/cloud-init/copyright
  Format-Specification: 
http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135
  Name: cloud-init
  Maintainer: Scott Moser 
  Source: https://launchpad.net/cloud-init

  This package was debianized by Soren Hansen  on
  Thu, 04 Sep 2008 12:49:15 +0200 as ec2-init.  It was later renamed to
  cloud-utils by Scott Moser 

  Upstream Author: Scott Moser 
  Soren Hansen 
  Chuck Short 

  Copyright: 2010, Canonical Ltd.
  License: GPL-3 or Apache-2.0
   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License version 3, as
   published by the Free Software Foundation.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see <http://www.gnu.org/licenses/>.

   The complete text of the GPL version 3 can be seen in
   /usr/share/common-licenses/GPL-3.

  Files: cloudinit/boto_utils.py
  Copyright: 2006,2007, Mitch Garnaat http://garnaat.org/
  License: MIT
   Permission is hereby granted, free of charge, to any person obtaining a
   copy of this software and associated documentation files (the
   "Software"), to deal in the Software without restriction, including
   without limitation the rights to use, copy, modify, merge, publish, dis-
   tribute, sublicense, and/or sell copies of the Software, and to permit
   persons to whom the Software is furnished to do so, subject to the fol-
   lowing conditions:

   The above copyright notice and this permission notice shall be included
   in all copies or substantial portions of the Software.

   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABIL-
   ITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
   SHALL THE AUTHOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
   WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
   OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
   IN THE SOFTWARE.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1718681/+subscription

[Group.of.nepali.translators] [Bug 1728048] Re: squashfs url matching is to strict

[Scott Moser]

** Also affects: cloud-initramfs-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cloud-initramfs-tools (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: cloud-initramfs-tools (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Changed in: cloud-initramfs-tools (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-initramfs-tools (Ubuntu Zesty)
   Status: New => Confirmed

** Changed in: cloud-initramfs-tools (Ubuntu Artful)
   Status: New => Confirmed

** Changed in: cloud-initramfs-tools (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-initramfs-tools (Ubuntu Zesty)
   Importance: Undecided => Medium

** Changed in: cloud-initramfs-tools (Ubuntu Artful)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1728048

Title:
  squashfs url matching is to strict

Status in cloud-initramfs-tools:
  Fix Released
Status in cloud-initramfs-tools package in Ubuntu:
  Fix Released
Status in cloud-initramfs-tools source package in Xenial:
  Confirmed
Status in cloud-initramfs-tools source package in Zesty:
  Confirmed
Status in cloud-initramfs-tools source package in Artful:
  Confirmed

Bug description:
  The code that automatically determines a squashfs url is just to strict.
  You can explicitly declare it as squash with:
 root=squashfs:http://<>/...
  but currently the automatic matching requires it to end in .squashfs or 
.squash.

  This doesn't match urls like
/squashfs
/my-squash

  which are as obviously squashfs urls as others.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-initramfs-tools/+bug/1728048/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1574113] Re: curtin/maas don't support multiple (derived) archives/repositories with custom keys

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1574113

Title:
  curtin/maas don't support multiple (derived) archives/repositories
  with custom keys

Status in cloud-init:
  Fix Released
Status in curtin:
  Fix Released
Status in MAAS:
  Fix Released
Status in MAAS 1.9 series:
  Won't Fix
Status in cloud-init package in Ubuntu:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Committed
Status in curtin source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * Curtin doesn't support multiple derived archive/repositories with
 custom keys as typically deployed in an offline Landscape deployment.
 Adding the custom key resulted in an error when processing the
 apt_source configuration as provided in this setup.

 Curtin has been updated to support the updated apt-source model
 implemented in cloud-init as well.  Together the existing Landscape
 deployments for offline users can now supply an apt-source config
 that updates curtin to use the specified derived repository with a
 custom key.
 
  [Test Case]

   * Install proposed curtin package and deploy a system behind a
 Landscape Offline configuration with a derived repo.

PASS: Curtin will successfully accept the derived repo and install the
  system from the specified apt repository.

FAIL: Curtin will fail to install the OS with an error like:

W: GPG error: http://100.107.231.166 trusty InRelease:
The following signatures couldn't be verified because the public key
is not available: NO_PUBKEY 2C6F2731D2B38BD3
E: There are problems and -y was used without --force-yes

Unexpected error while running command.
Command: ['chroot', '/tmp/tmpcEfTLw/target', 'eatmydata', 'apt-get',
  '--quiet', '--assume-yes',
  '--option=Dpkg::options::=--force-unsafe-io',
  '--option=Dpkg::Options::=--force-confold', 'install',
  'lvm2', 'ifenslave']
Exit code: 100


  [Regression Potential]

   * Other users of previous curtin 'apt_source' configurations may not
 continue to work without re-formatting the apt_source configuration.

  
  [Original Description]

  In a customer environment I have to deploy using offline resources (no
  internet connection at all), so I created apt mirror and MAAS images
  mirror. I configured MAAS  to use the local  mirrors and I'm able to
  commission the nodes but I'm not able to deploy the nodes because
  there is no way to add gpg key of the local repo in target before the
  'late' stage'.

  Using curtin I'm able to add the key but too late, in fact  according
  with http://bazaar.launchpad.net/~curtin-
  dev/curtin/trunk/view/head:/curtin/commands/install.py#L52 "late"
  stage is executed  after "curthooks" this prevent to add the key.

  I checked also apt_config function in curthooks.py  I did't see code
  that add the key for each mirror.

  It should be possible to add gpg public of the repository in maas.

  --
  configs/config-000.cfg
  --

  #cloud-config
  debconf_selections:
   maas: |
    cloud-init   cloud-init/datasources  multiselect MAAS
    cloud-init   cloud-init/maas-metadata-url  string 
http://100.107.231.164/MAAS/metadata/
    cloud-init   cloud-init/maas-metadata-credentials  string 
oauth_token_key=8eZmzQWSSQzsUkaLnE&oauth_token_secret=LKmn8sHgzEXfvzSZePAa9jUXvTMRrFNP&oauth_consumer_key=htwDZJFtmv2YvQXhUW
    cloud-init   cloud-init/local-cloud-config  string 
apt_preserve_sources_list: true\nmanage_etc_hosts: false\nmanual_cache_clean: 
true\nreporting:\n  maas: {consumer_key: htwDZJFtmv2YvQXhUW, endpoint: 
'http://100.107.231.164/MAAS/metadata/status/node-61b6987c-07a7-11e6-9d23-5254003d2515',\n
token_key: 8eZmzQWSSQzsUkaLnE, token_secret: 
LKmn8sHgzEXfvzSZePAa9jUXvTMRrFNP,\ntype: webhook}\nsystem_info:\n  
package_mirrors:\n  - arches: [i386, amd64]\nfailsafe: {primary: 
'http://archive.ubuntu.com/ubuntu', security: 
'http://security.ubuntu.com/ubuntu'}\nsearch:\n  primary: 
['http://100.107.231.166/']\n  security: ['http://100.107.231.166/']\n  - 
arches: [default]\nfailsafe: {primary: 
'http://ports.ubuntu.com/ubuntu-ports', security: 
'http://ports.ubuntu.com/ubuntu-ports'}\nsearch:\n  primary: 
['http://ports.ubuntu.com/ubuntu-ports']\n  security: 
['http://ports.ubuntu.com/ubuntu-ports']\n
  late_commands:
    maas: [wget, '--no-proxy', 
'http://100.107.231.164/MAAS/metadata/latest/by-id/node-61b6987c-07a7-11e6-

[Group.of.nepali.translators] [Bug 1588547] Re: Generated bonding configuration is incorrect.

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1588547

Title:
  Generated bonding configuration is incorrect.

Status in curtin:
  Fix Released
Status in MAAS:
  Opinion
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Trusty:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * Users attempting to configure nic bonding and using both ipv4 and ipv6
 encounter a misconfigured network due to a bug in curtin's handling of
 bond configuration and ipv6.  The error results in superflous 
 attributes and then broken ipv4 entries if preceeded by an ipv6
 address.

 This affects all curtin releases which support networking
 configuration.
 
   * This SRU fixes bonding and ipv6 configurations by no longer emitting
 attributes for aliased interfaces and calculating the correct
 inet type for a given interface.

  
  [Test Case]

   * On a Xenial 16.04 system
  - apt-get install curtin
  - cat >test.yaml 

[Group.of.nepali.translators] [Bug 1551937] Re: lvm and multipath and xenial not happy together

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1551937

Title:
  lvm and multipath and xenial not happy together

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Trusty:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * MaaS deployments to systems with multipath configures cannot
 install Xenial releases due to a change in how multipath configures
 its friendly names.  On older releases (multipath-tools < 0.5.0)
 multipath-tools expects that the names of the devices will include
 names and parses the file with that expectation. However, on newer
 releases (multipath-tools >= 0.5.0) multipath-tools uses spaces to
 separate fields in the bindings file and fails if the device name
 includes spaces. 

 Curtin will detect the level of multipath-tools to be used in the
 target OS and adjusts how it generates device names for the binding
 file accordingly.
 
  [Test Case]

   * Install proposed curtin package and deploy custom storage
 configuration against a Power8 or similiar configured multipath
 system and select Xenial as the target OS.

PASS: The multipath configured machine will successfully install
both Xenial and Trusty.

FAIL: The multipath configured machine will fail to install Xenial
but will successfully install Trusty.

  [Regression Potential]

   * May impact users of systems with multipath storage configurations.

  
  [Original Description]

  tried deploy of xenial with curtin on a powerNV system.  the result was 
failure to mount the root, ending like this:
  Begin: Running /scripts/local-block ...   lvmetad is not active yet, using 
direc
  t activation during sysinit
    Volume group "mpath0" not found
    Cannot process volume group mpath0
  done.
  Begin: Running /scripts/local-block ...   lvmetad is not active yet, using 
direct activation during sysinit
    Volume group "mpath0" not found
    Cannot process volume group mpath0
  done.
  done.
  Gave up waiting for root device.  Common problems:
   - 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/mapper/mpath0-part2 does not exist.  Dropping to a shell!

  Related bugs:
   * bug 1429327: Boot from a unique, stable, multipath-dependent symlink
   * bug 1432062: multipath-tools-boot: support booting without 
user_friendly_names on devices with spaces in identifiers
   * bug 1552319: xenial kernel boot slow/timeout on power8 powerNV

  $ dpkg-query --show | egrep '(maas|curtin)'
  curtin-common   0.1.0~bzr359-0ubuntu1
  maas1.9.1+bzr4541-0ubuntu1~trusty1
  maas-cli1.9.1+bzr4541-0ubuntu1~trusty1
  maas-cluster-controller 1.9.1+bzr4541-0ubuntu1~trusty1
  maas-common 1.9.1+bzr4541-0ubuntu1~trusty1
  maas-dhcp   1.9.1+bzr4541-0ubuntu1~trusty1
  maas-dns1.9.1+bzr4541-0ubuntu1~trusty1
  maas-provision  2.2.2-0ubuntu4
  maas-provision-common   2.2.2-0ubuntu4
  maas-proxy  1.9.1+bzr4541-0ubuntu1~trusty1
  maas-region-controller  1.9.1+bzr4541-0ubuntu1~trusty1
  maas-region-controller-min  1.9.1+bzr4541-0ubuntu1~trusty1
  python-curtin   0.1.0~bzr359-0ubuntu1
  python-django-maas  1.9.1+bzr4541-0ubuntu1~trusty1
  python-maas-client  1.9.1+bzr4541-0ubuntu1~trusty1
  python-maas-provision   2.2.2-0ubuntu4
  python-maas-provisioningserver  1.9.1+bzr4541-0ubuntu1~trusty1

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1551937/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1524031] Re: attempting to preserve disk curtin expects PTTYPE in blkid output

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1524031

Title:
  attempting to preserve disk curtin expects PTTYPE in blkid output

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * On a Trusty host, if users enable storage disk preserve feature,
 the use of blkid expects PTTYPE value in the output, however, this is
 not present in Trusty blkid output.  This prevents Trusty hosts from
 preserving existing partitions.

 Curtin has been updated to fallback to using parted to determine how to
 preserve existing partitions on disks when directed.
 
  [Test Case]

   * Install proposed curtin package and deploy in a Trusty ephemeral
 environment with the following storage configuration:

 storage:
  version: 1
  config:
- id: vdg
  model: Unknown Model
  preserve: true
  ptable: gpt
  serial: 64bddb21-61f3-4869-8
  type: disk
  wipe: superblock

PASS: Successfully deploy image while preserving the original partition
  table.

FAIL: Deployment fails with the following error:

line 530, in disk_handler
out.splitlines()))[0].split("=")[-1]
IndexError: list index out of range
list index out of range

  
  [Regression Potential]

   * No known other failures when using parted as replacement for blkid
 partition data.


  [Original Description]
  On a trusty host, this storage configuration breaks:

  storage:
    version: 1
    config:
  - id: vdg
    model: Unknown Model
    preserve: true
    ptable: gpt
    serial: 64bddb21-61f3-4869-8
    type: disk
    wipe: superblock

  like this:

  Running command ['partprobe', '/dev/vdg'] with allowed return codes [0, 1] 
(shell=False, capture=False)
  Running command ['udevadm', 'settle'] with allowed return codes [0] 
(shell=False, capture=False)
  Running command ['blkid', '-o', 'export', '/dev/vdg'] with allowed return 
codes [0] (shell=False, capture=True)
  An error occured handling 'vdg': IndexError - list index out of range
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/curtin/commands/main.py", line 208, in 
main
  ret = args.func(args)
    File "/usr/lib/python3/dist-packages/curtin/commands/block_meta.py", line 
63, in block_meta
  meta_custom(args)
    File "/usr/lib/python3/dist-packages/curtin/commands/block_meta.py", line 
1208, in meta_custom
  handler(command, storage_config_dict)
    File "/usr/lib/python3/dist-packages/curtin/commands/block_meta.py", line 
530, in disk_handler
  out.splitlines()))[0].split("=")[-1]
  IndexError: list index out of range
  list index out of range

  From this code here:

  # Check state of current ptable
  try:
  (out, _err) = util.subp(["blkid", "-o", "export", disk],
  capture=True)
  except util.ProcessExecutionError:
  raise ValueError("disk '%s' has no readable partition table or \
  cannot be accessed, but preserve is set to true, so cannot \
  continue")
  current_ptable = list(filter(lambda x: "PTTYPE" in x,
   out.splitlines()))[0].split("=")[-1]

  And the output of blkid -o export /dev/vdg on trusty instance is:

  # blkid -o export /dev/vdg
  UUID=ef30955b-8aa0-453f-a37d-d631a09a6f7c
  UUID_SUB=9a21ae23-6f14-405d-9e9a-8955855132d5
  TYPE=btrfs

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1524031/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1562249] Re: Failed to deploy machine with HP Smart Array Raid 6i

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1562249

Title:
  Failed to deploy machine with HP Smart Array Raid 6i

Status in curtin:
  Fix Released
Status in Landscape Server:
  Invalid
Status in MAAS:
  Invalid
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Trusty:
  Confirmed
Status in curtin source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * Attempting to deploy a machine with a HP Smart Array Raid 6i fails to
 install due to Curtin miscalculating the device path to CCISS
 partitions

 Curtin has been updated to properly calculate and handle the
 different forms of the HP CCISS array devices and partition path names
 in /dev and in /sys
 
  [Test Case]

   * Install proposed curtin package and deploy Ubuntu images to a system
 with an HP Smart Array device.

 PASS: Ubuntu OS successfully installed

 FAIL: Ubuntu fails to install with error message like:

  An error occured handling 'cciss!c0d0':
  OSError - [Errno 2] No such file or directory:  '/sys/block/c0d0/holders'

  [Regression Potential]

   * The fix included changes to how curtin determines the sysfs path to
 block devices and partitions.  It's possible that these changes could
 cause working systems which currently deploy to fail to deploy.
 However, this is mitigated by the fact that only HP Smart Array devices
 have special naming scheme for partitions so it's unlikely that non-HP
 storage devices are using the kernel path /dev/cciss as a prefix.

  
  [Original Description]
  Attempting to deploy a machine with a HP Smart Array Raid 6i fails. 
Installation output contains:

  Error: Partition(s) 5 on /dev/cciss/c0d0 have been written, but we have been 
unable to inform the kernel of the change, probably because it/they are in use. 
As a result, the old partition(s) will remain in use. You should reboot now 
before making further changes.
  An error occured handling 'cciss!c0d0': OSError - [Errno 2] No such file or 
directory: '/sys/block/c0d0/holders'
  [Errno 2] No such file or directory: '/sys/block/c0d0/holders'
  Installation failed with exception: Unexpected error while running command.
  Command: ['curtin', 'block-meta', 'custom']
  Exit code: 3
  Reason: -
  Stdout: "Error: Partition(s) 5 on /dev/cciss/c0d0 have been written, but we 
have been unable to inform the kernel of the change, probably because it/they 
are in use. As a result, the old partition(s) will remain in use. You should 
reboot now before making further changes.\nAn error occured handling 
'cciss!c0d0': OSError - [Errno 2] No such file or directory: 
'/sys/block/c0d0/holders'\n[Errno 2] No such file or directory: 
'/sys/block/c0d0/holders'\n"

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1562249/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1351085] Re: documentation is out of date and sparse

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1351085

Title:
  documentation is out of date and sparse

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * Curtin documentation is out-of-date and sparse.

 Curtin has been updated to include detailed documentation about
 its configuration, features, function and implementation.  The
 latest configuration is now available at:

 http://curtin.readthedocs.io/en/latest/
 
  [Test Case]

   n/a

  [Regression Potential]

   n/a

  
  [Original Description]

  The only documentation I could find curtin is doc/topics/overview.rst
  in the source.  It has several problems:

   - It talks about a final_commands hook which doesn't exist AFAICS

   - It doesn't talk about the late_commands hook which definitely does
     exist

   - It refers to both TARGET_MOUNT_POINT and TARGET_MP; I suspect only
     one exists

   - It has confusing examples which I don't think work/make sense, e.g:

  | config_hook: {{TARGET_MP}}/opt/curtin/config-hook

  The documentation is also pretty sparse in many ways, it doesn't for
  example:

   - Explain that the config is YAML

   - Explain other basic things about the config, e.g. what are the keys
     for hooks?  Do the names matter?  Does ordering matter?

   - Explain why you might want to use a list versus scalar for values

   - Explain how one might use YAML features such as 'repeated notes' to
     include data in the config that's intended for files

   - Explain that you probably want to use -- with curtin in-target to
     stop options of what you're trying to run being swallowed up by
     curtin

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1351085/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1713537] Re: iscsi-targets don't quit session on shutdown

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1713537

Title:
  iscsi-targets don't quit session on shutdown

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Confirmed
Status in curtin source package in Zesty:
  Confirmed
Status in curtin source package in Artful:
  Fix Released

Bug description:
  1. Artful (MAAS Image)[a]
  2. open-iscsi 2.0.874-4ubuntu1
  3. On shutdown, all iscsi sessions to be stopped and unmounted
  4. Iscsi stops but does not stop sessions and shutdown is blocked/hung

  [^[[0;32m  OK  ^[[0m] Reached target Shutdown.
  [  125.666350]  connection4:0: ping timeout of 5 secs expired, recv timeout 
5, last rx 4294921130, last ping 4294922432, now 4294923712
  [  125.922334]  connection3:0: ping timeout of 5 secs expired, recv timeout 
5, last rx 4294921211, last ping 4294922496, now 4294923776
  [  126.178553]  connection2:0: ping timeout of 5 secs expired, recv timeout 
5, last rx 4294921292, last ping 4294922560, now 4294923840
  [  126.434334]  connection1:0: ping timeout of 5 secs expired, recv timeout 
5, last rx 4294921371, last ping 4294922624, now 4294923904

  Note, previously released Artful MAAS images work fine:
  http://images.maas.io/ephemeral-v2/daily/artful/amd64/20170721/
  which contain 

  open-iscsi  2.0.873+git0.3b4b4500-14ubuntu17

  a. http://images.maas.io/ephemeral-v2/daily/artful/amd64/20170826/

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1713537/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1662346] Re: vmtest: s390x requires zipl command

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1662346

Title:
  vmtest: s390x requires zipl command

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released
Status in curtin source package in Yakkety:
  Fix Released

Bug description:
  [Impact]
  Installations of s390x systems will fail.  s390x requires zipl to boot
  and curtin assumed it was in the target image.  The change is simply
  to install it from the archive if it is not present.

  [Test Case]
  Run curtin vmtest on s390 as:
/tools/jenkins-runner tests/vmtests/test_simple.py:XenialTestSimple

  [Regression Potential]
  No regression potential on s390x as it simply did not work.
  Errant code could accidently attempt installation of zipl on other
  arch, but successful installation of other arch show that is not the
  case.

  [Other Info]

  Before any s390x vmtests can be run on any regular basis the zipl
  command needs to be added as a dependency during install. Currently a
  basic test fails [1] with the output:

  [  114.303504] cloud-init[1482]: Running command ['chroot', 
'/tmp/tmpua0mwwjb/target', 'zipl'] with allowed return codes [0] (shell=False, 
capture=False)
  [  114.304453] cloud-init[1482]: chroot: failed to run command 'zipl': No 
such file or directory

  [1] https://jenkins.ubuntu.com/server/job/curtin-vmtest-s390x/8/

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1662346/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1661337] Re: curtin does not retry when gpg fails to recv key

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1661337

Title:
  curtin does not retry when gpg fails to recv key

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released
Status in curtin source package in Yakkety:
  Fix Released

Bug description:
   Begin SRU Template 
  [Impact]
  Curtin installation can be configured to install additional apt
  repositories and import gpg keys from a remote keyserver by fingerprint.
  'gpg --recv' can transiently fail, causing installation failure.

  The fix is to just retry
    gpg --keyserver keyserver.ubuntu.com --recv 

  [Test Case]
  Run curtin vmtest on XenialTestAptSrcDisablePockets
   ./tools/jenkins-runner tests/vmtests/test_apt_source.py

  The named test pushes curtin through use of gpg --keyserver.
  It does not guarantee failure and re-try, but does test the
  happy path.  Even if the gpg server was available on the first
  time, we at very least then verify that there is no regression.

  [Regression Potential]
  Low risk of regression.  The code change is just to sleep and retry
  a command if it failed.

  [Other Info]
  When looking further into some failures in add-apt-repository that were
  not fixed by re-trying, we found bug 1532855 .  It is not explicitly
  related to this bug, but is a similar failure path.

   End   SRU Template 

  In some cases we have transient network failure while attempting to
  recv gpg keys when configuring apt.

  https://jenkins.ubuntu.com/server/job/curtin-
  vmtest/737/artifact/output/XenialTestAptSrcDisablePockets/logs
  /install-serial.log

  [   40.161264] cloud-init[1528]: Command: ['gpg', '--keyserver', 
'keyserver.ubuntu.com', '--recv', '0E72 9061 0D2F 6DC4 D65E  A921 9A31 4EC5 
F470 A0AC']
  [   40.162213] cloud-init[1528]: Exit code: 2
  [   40.163711] cloud-init[1528]: Reason: -
  [   40.164256] cloud-init[1528]: Stdout: "gpgkeys: key 
0E7290610D2F6DC4D65EA9219A314EC5F470A0AC can't be retrieved\n"
  [   40.174200] cloud-init[1528]: Stderr: 'gpg: requesting key F470A0AC from 
hkp server keyserver.ubuntu.com\ngpg: no valid OpenPGP data found.\ngpg: Total 
number processed: 0\ngpg: keyserver communications error: keyserver helper 
general error\ngpg: keyserver communications error: unknown pubkey 
algorithm\ngpg: keyserver receive failed: unknown pubkey algorithm\n'
  [   40.180654] cloud-init[1528]: During handling of the above exception, 
another exception occurred:
  [   40.182056] cloud-init[1528]: Traceback (most recent call last):
  [   40.183644] cloud-init[1528]:   File "/curtin/curtin/gpg.py", line 65, in 
getkeybyid
  [   40.185067] cloud-init[1528]: recv_key(keyid, keyserver=keyserver)
  [   40.186653] cloud-init[1528]:   File "/curtin/curtin/gpg.py", line 48, in 
recv_key
  [   40.187895] cloud-init[1528]: (key, keyserver, error))

  Curtin should retry this command.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1661337/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1649652] Re: [MAAS 2.1.2] Issue with adding routes to hosts via maas

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1649652

Title:
  [MAAS 2.1.2] Issue with adding routes to hosts  via maas

Status in curtin:
  Fix Released
Status in MAAS:
  Invalid
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released
Status in curtin source package in Yakkety:
  Fix Released

Bug description:
   Begin SRU Template 
  [Impact]
  System configuration of networking with static routes did not
  work properly.  Systems where static routes were necessary would
  install but not come up with the desired networking.

  [Test Case]
  Run curtin vmtest on tests/vmtests/test_network_static_routes.py
  These tests show the failure without a patched curtin,
  and passing verifies the fix.

  [Regression Potential]
  Likeliest path to regression would be in failure of other network
  configurations.

  [Other Info]
   End   SRU Template 

  I'm trying to set routes for a subnet and have them be passed to a
  host during provision.

  This fails due to formatting issues in the /etc/network/interfaces
  file.

  I've attached both /etc/network/interfaces and the output of get-
  curtin-config. I'm running version 2.1.2+bzr-0ubuntu1~16.04.1.

  roaksoax suggested this was a curtin issue, but would still be tracked
  here.

  Please let me know if you need anymore information.

  Thanks,
  Brandon

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1649652/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1645515] Re: [FFe] Support for ISCSI block devices

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1645515

Title:
  [FFe] Support for ISCSI block devices

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released
Status in curtin source package in Yakkety:
  Fix Released

Bug description:
   Begin Curtin SRU Template 
  [Impact]
  Curtin currently does not support specifying iSCSI targets in the storage
  configuration.  That means that MAAS or other users of curtin are not able
  to install to use iscsi disks during installation.

  The changes in this bug add the ability to specify non-root iSCSI targets
  to curtin, and include integration tests (vmtest) and unit tests to excercise
  the functionality.

  [Test Case]
  Run curtin vmtest on tests/vmtests/test_iscsi.py.
   ./tools/jenkins-runner tests/vmtests/test_iscsi.py

  The named test sets up an iscsi server with tgt and does an installation
  utilizing the disks provided by that iscsi server.

  [Regression Potential]
  Regression would most likely be a result of the new iscsi functionality
  mis-identifying configuration for a local disk as a iscsi disk, and then
  failing to do things as a result.

   End Curtin SRU Template 

  [FFe Justification]

   - Curtin currently does not support specifying iSCSI targets in the
  storage configuration.

   - Users have iSCSI targets they would like to install to via curtin.

   - The changes in this bug add the ability to specify non-root iSCSI
  targets in the YAML and include vmtests and unittests for that
  functionality.

   - Existing users are unaffected by this change, as if they specified
  a iSCSI compatible value in their YAML currently it would fail to
  parse. The added code is only used when iSCSI is used.

  ---

  Curtin needs to support the ability to attach an ISCSI block device
  during the installation and perform disk operations just like a
  locally attached block device. The disk also needs to be auto mounted
  when Ubuntu is rebooted after installation.

  Possible format:

  - id: sdb
    type: disk
    iscsi:
  target: iqn.2016-11.io.maas:storage.lun1
  portal: 192.168.122.2:3260

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1645515/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1659509] Re: curtin fails to create MD devices

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1659509

Title:
  curtin fails to create MD devices

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released
Status in curtin source package in Yakkety:
  Fix Released

Bug description:
   Begin SRU Template 
  [Impact]
  On some machines with existing MDADM RAID metadata on one or
  more disks, curtin can fails to remove this existing metadata when
  instructed to do so and fails to install on such machines.

  Improvement in curtin's ability to release holders on a disk
  and clear it mean that installation succeeds.

  [Test Case]
  Run curtin vmtest on tests/unittests/test_commands_block_meta.py
./tools/jenkins-runner tests/unittests/test_commands_block_meta.py

  [Regression Potential]
  Installation failures would be the most likely regression, and
  then most likely with multipath, raid or both.

  [Other Info]
   End   SRU Template 

   * On some machines which have existing MDADM RAID metadata on one or
     more disks, curtin fails to remove this existing metadata when
     instructed to do so and fails to install on such machines.

  On xenial we used curtin: 0.1.0~bzr425-0ubuntu1~16.04.1
  and for trusty deployment curtin_0.1.0~bzr399-0ubuntu1~14.04.1

  please see the attached full installation log.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1659509/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1645680] Re: apt feature broken on >=Yakkety due to new gpg agent

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1645680

Title:
  apt feature broken on >=Yakkety due to new gpg agent

Status in curtin:
  Fix Released
Status in GnuPG:
  Incomplete
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released
Status in curtin source package in Yakkety:
  Fix Released
Status in curtin source package in Zesty:
  Fix Released

Bug description:
  - Begin SRU Template -
  [Impact]
  The mechanism for adding PPAs during was prone to failure when installing
  16.10 (yakkety) or newer systems.

  A curtin install of yakkety with the following configuration would
  fail:
apt:
sources:
  ignored1:
source: "ppa:paelzer/yourppa"

  [Test Case]
  Install a yakkety or zesty system with the above configuration.
  This can be accomplished by running the vmtest YakketyTestAptConfigCMDCMD
  with the installed version of curtin.

  It has configuration of
  apt:
sources:
  ignored:
 source: "ppa:curtin-dev/test-archive"
  curtin-test1.list:
 source: "deb $MIRROR $RELEASE-proposed main"

  
  [Regression Potential]

  [Other Info]
  This failure came as a result of change in behavior of gpg.  Curtin
  (indirectly through add-apt-repository) uses GPG to add PPAs into a
  chroot.  GPG2 began daemonizing itself, which meant that unmounts of the
  filesystem would fail due to open filehandles of the daemonized gpg
  process.

  There is further discussion both on the bug and in the upstream
  merge proposal [1] on other ways to do this.  The solution taken was
  a killall of processes named 'dirmgr' or 'gpg-agent' that were spawned
  after the chroot.

  [1] 
https://code.launchpad.net/~paelzer/curtin/curtin-bug-1645680-gpgagent/+merge/312143
  - End   SRU Template -

  Hi,
  while testing I found that when running apt feature related to 
add-apt-repository like:

  apt:
    sources:
  ignored1:
    source: "ppa:paelzer/yourppa"

  Or in fact any sort of add-apt-repository (also unrelated to the apt feature 
itself) like:
  late_commands:
   01_install_ppa: ['curtin', 'in-target --', 'add-apt-repository --yes 
ppa:paelzer/bug-1645274-multipath-merge']

  Then the installation fails.

  Both use the chroot to execute in target, but recent add-apt-
  repository seems so cause daemons to spawn which then let the umount
  fail.

  Failure is usually around something like:
  "umount: /tmp/tmptmucmfm0/target/dev: target is busy"

  Here an excerpt from a lsof +fg afterwards.
  dirmngr   6771 root1r   CHRLG,0x81,9  
0t0   11 /tmp/tmptmucmfm0/target/dev/urandom
  dirmngr   6771 root2w   CHR  W,LG1,3  
0t06 /tmp/tmptmucmfm0/target/dev/null
  gpg-agent 6776 root0r   CHRLG1,3  
0t06 /tmp/tmptmucmfm0/target/dev/null
  gpg-agent 6776 root1w   CHR  W,LG1,3  
0t06 /tmp/tmptmucmfm0/target/dev/null
  gpg-agent 6776 root2w   CHR  W,LG1,3  
0t06 /tmp/tmptmucmfm0/target/dev/null

  One of them could be shut down by:
  gpg-connect-agent --verbose KILLAGENT
  But not dirmngr, that has to be killed.
  Actually killing them seems ok (does not seem to create and later fallout).

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1645680/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1641661] Re: curtin fails to partition software raid md0

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1641661

Title:
  curtin fails to partition software raid md0

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released
Status in curtin source package in Yakkety:
  Fix Released
Status in curtin source package in Zesty:
  Fix Released

Bug description:
  - Begin SRU Template -
  [Impact]
  Curtin is unable to partition md (raid) devices.
  A system configured to put partitions on a raided device will fail to
  install.

  [Test Case]
  We added 2 test paths for this code to curtin
  a.) unit tests - these will run in the build process, so successful build
  verifies that this has passed.
  b.) vmtests named: *MirrorbootPartitions

  vmtests are currently only run on trunk, but we can modify source
  to run with the packaged version.  So, then to test the md path
  with a vm install, we will:
  i) run a xenial system
  ii) enable proposed
  iii) install curtin
  iv) run vmtests of the Mirrorboot tests using curtin from the sru.

  [Regression Potential]
  Quite low, the path for failure would be if there were some cases
  when the device name for a mdadm partition was /dev/mdNM rather than
  /dev/mdNpM.

  [Other Info]
  The upstream merge proposal is at
   https://code.launchpad.net/~raharper/curtin/trunk.lp1641661/+merge/311275
  and shows the code that went in to fix this.

  - End SRU Template -

  It seem curtin has problem with software RAID partitioning: md*
  Trying to deploy node in MAAS Version 2.0.0+bzr5189-0ubuntu1 (16.04.1).
  During partitioning stage curtin returns following error:

  An error occured handling 'md0-part1': OSError - could not get path to dev 
from kname: md01
  finish: cmd-install/stage-partitioning/builtin/cmd-block-meta: FAIL: failed: 
configuring partition: md0-part1
  finish: cmd-install/stage-partitioning/builtin/cmd-block-meta: FAIL: failed: 
curtin command block-meta
  Traceback (most recent call last):
    File "/curtin/curtin/commands/main.py", line 211, in main
  ret = args.func(args)
    File "/curtin/curtin/commands/block_meta.py", line 62, in block_meta
  meta_custom(args)
    File "/curtin/curtin/commands/block_meta.py", line 1041, in meta_custom
  handler(command, storage_config_dict)
    File "/curtin/curtin/commands/block_meta.py", line 550, in partition_handler
  get_path_to_storage_volume(info.get('id'), storage_config),
    File "/curtin/curtin/commands/block_meta.py", line 267, in 
get_path_to_storage_volume
  volume_path = block.kname_to_path(partition_kname)
    File "/curtin/curtin/block/__init__.py", line 114, in kname_to_path
  raise OSError('could not get path to dev from kname: {}'.format(kname))
  OSError: could not get path to dev from kname: md01
  could not get path to dev from kname: md01
  builtin command failed
  finish: cmd-install/stage-partitioning/builtin: FAIL: failed: running 'curtin 
block-meta custom'
  builtin took 8.861 seconds

  I've added commit which fixes mentioned error:
  http://bazaar.launchpad.net/~ruslan-
  lutcenko/curtin/curtin/revision/431

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1641661/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1597923] Re: curtin is unable to create whole disk fat/vfat formats

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1597923

Title:
  curtin is unable to create whole disk fat/vfat formats

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * Curtin is unable to create FAT/VFAT filesystems on whole disks. The FAT
 filesystem creation utilities do not, by default, support creating a
 FAT filesystem against an unpartitioned device.

 Curtin has been updated to support passing a force flag to the
 utilities to allow custom storage configurations to use FAT/VFAT
 filesystems against such a device.
 
  [Test Case]

   * Install proposed curtin package and deploy Ubuntu to target system
 specifying a VFAT filesystem on top of a whole block device.

PASS: Ubuntu installation succeeds

FAIL: Ubuntu installation fails when attempting to format the block
  device on which the VFAT filesystem would reside.


  [Regression Potential]

   * Other OSes which may attempt to mount and read a VFAT filesystem
 created in so-called 'superfloppy' format might not recognize the
 filesystem.

  
  [Original Description]
  The mkfs.fat and mkfs.vfat tools do not by default permit the creation of a 
filesystem on a disk that has not been partitioned. This is not really a 
limitation of the filesystems themselves; it is just a safety feature to keep 
people from accidentally overwriting data.

  Since some curtin users may have a need for whole disk fat/vfat
  filesystems, it makes sense to use the '-I' flag for mkfs.vfat
  commands, which forces the tools to work on whole disks. It appears
  that this flag does not interfere with any of the other options in
  mkfs, and so is essentially a force flag, and can just be added to
  family_flag_mappings in block.mkfs

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1597923/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1615780] Re: Confusing 'success' message when apply_net fails.

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1615780

Title:
  Confusing 'success' message when apply_net fails.

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * Curtin produced a configusing 'success' message when failying to apply
 a provided network configuration.

 Curtin has been updated to ensure that if 'apply_net' commands fail
 the return code is propagated up to the invocation and no longer 
 prints both a success and failure message when a failure occurs.
 
  [Test Case]

   * Install proposed curtin package and run the command
 - # curtin apply_net -t target -c bad.yaml

PASS: Curtin does not emit successful message:
  'Applied network configuration successfully'

FAIL: Curtin emits both
  'Applied network configuration successfully' and
  'failed to apply network config'

  [Regression Potential]

   * Users of apply_net cli command may have examined the output of the
 command which is now modified, as well as the return code.

  
  [Original Description]

  When apply_net fails, the user both a fail message and a success
  message.. a bit confusing.

  root@x1:~# curtin apply_net -t target -c bad.yaml
  Applying network configuration
  failed to apply network config
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/curtin/commands/apply_net.py", line 
78, in apply_net_main
  network_config=state['network_config'])
    File "/usr/lib/python3/dist-packages/curtin/commands/apply_net.py", line 
44, in apply_net
  ns = net.parse_net_config(network_config)
    File "/usr/lib/python3/dist-packages/curtin/net/__init__.py", line 283, in 
parse_net_config
  net_config = config.load_config(path)
    File "/usr/lib/python3/dist-packages/curtin/config.py", line 117, in 
load_config
  return yaml.safe_load(content)
    File "/usr/lib/python3/dist-packages/yaml/__init__.py", line 94, in 
safe_load
  return load(stream, SafeLoader)
    File "/usr/lib/python3/dist-packages/yaml/__init__.py", line 72, in load
  return loader.get_single_data()
    File "/usr/lib/python3/dist-packages/yaml/constructor.py", line 35, in 
get_single_data
  node = self.get_single_node()
    File "/usr/lib/python3/dist-packages/yaml/composer.py", line 36, in 
get_single_node
  document = self.compose_document()
    File "/usr/lib/python3/dist-packages/yaml/composer.py", line 55, in 
compose_document
  node = self.compose_node(None, None)
    File "/usr/lib/python3/dist-packages/yaml/composer.py", line 84, in 
compose_node
  node = self.compose_mapping_node(anchor)
    File "/usr/lib/python3/dist-packages/yaml/composer.py", line 133, in 
compose_mapping_node
  item_value = self.compose_node(node, item_key)
    File "/usr/lib/python3/dist-packages/yaml/composer.py", line 84, in 
compose_node
  node = self.compose_mapping_node(anchor)
    File "/usr/lib/python3/dist-packages/yaml/composer.py", line 127, in 
compose_mapping_node
  while not self.check_event(MappingEndEvent):
    File "/usr/lib/python3/dist-packages/yaml/parser.py", line 98, in 
check_event
  self.current_event = self.state()
    File "/usr/lib/python3/dist-packages/yaml/parser.py", line 428, in 
parse_block_mapping_key
  if self.check_token(KeyToken):
    File "/usr/lib/python3/dist-packages/yaml/scanner.py", line 116, in 
check_token
  self.fetch_more_tokens()
    File "/usr/lib/python3/dist-packages/yaml/scanner.py", line 257, in 
fetch_more_tokens
  self.get_mark())
  yaml.scanner.ScannerError: while scanning for the next token
  found character '\t' that cannot start any token
    in "", line 4, column 5:
    config:
  ^
  Applied network configuration successfully

  Note the emitting of messages

  "failed to apply network config"
  AND
  "Applied network configuration successfully"

  Really a minor issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1615780/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1617375] Re: AttributeError: module 'curtin.util' has no attribute 'RunInChroot'

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1617375

Title:
  AttributeError: module 'curtin.util' has no attribute 'RunInChroot'

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * Curtin removed a previously used python module method,
 'RunInChroot' which was used by non-ubuntu curthooks for 
 deploying OSes like CentOS.  Removing the method prevents
 deploying CentOS where it worked prior to updating.

 Curtin has been updated to include an alias to the previous method that
 provides backward compat to callers of 'RunInChroot'
 
  [Test Case]

   * Install proposed curtin package and deploy CentOS to target system

PASS: CentOS deploys successfully.

FAIL: CentOS deployment fails with message:

AttributeError: module 'curtin.util' has no attribute 'RunInChroot'

  [Regression Potential]

   * Other OSes besides CentOS may have used other flags against
 the original 'RunInChroot' method which is not being tested and
 may fail with the backward compat mode supporting 'RunInChroot'.


  [Original Description]
  I tested curtin bzr418 and bzr415, and I get the following error. This is a 
regression provided that it is not backward compatible and will cause all 
CentOS deployments via MAAS to fail.

  MAAS injects curtin_hooks code to CentOS images that call such
  function. If users upgrade to the latest curtin, they wont be able to
  deploy CentOS.

  AttributeError: module 'curtin.util' has no attribute 'RunInChroot'

  curtin bzr418:

  In [1]: import curtin.util

  In [2]: curtin.util.RunInChroot
  ---
  AttributeErrorTraceback (most recent call last)
   in ()
  > 1 curtin.util.RunInChroot

  AttributeError: module 'curtin.util' has no attribute 'RunInChroot'

  curtin bzr399:

  In [1]: import curtin.util

  In [2]: curtin.util.RunInChroot
  Out[2]: curtin.util.RunInChroot

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1617375/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1598310] Re: Curtin block.get_blockdev_sector_size incorrectly assumes block._lsblock will return a dictionary with only a single entry

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1598310

Title:
  Curtin block.get_blockdev_sector_size incorrectly assumes
  block._lsblock will return a dictionary with only a single entry

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * Curtin block module method `get_blockdev_sector_size` fails when
 pointed at a device with multiple partitions instead of only 
 a partition.
 
 Curtin has been updated to filter the results to find the expected
 device path and return results for that device.
 
  [Test Case]

   * Install proposed curtin package on a system with a block device with
 multiple partitions.
 - python3 -c 'from curtin import block;
   block.get_blockdev_sector_size("/dev/sda")'

PASS: method call returns tuple with values
 - (512, 512)

FAIL: method call fails with stacktrace like
 - Traceback (most recent call last):
 File "", line 1, in 
 File "curtin/curtin/block/__init__.py", line 426,
  in get_blockdev_sector_size
   [parent] = info
 ValueError: too many values to unpack (expected 1)

  [Regression Potential]

   * Third-party consumers of curtin modules may have relied on this failure
 to detect devices which contained partitions.


  [Original Description]
  The function curtin.get_blockdev_sector_size will not work when called with a 
devpath which lsblk will return multiple lines of results for.

  This means that in some cases formatting a device other than a
  partition may fail, because block.mkfs checks for logical block size
  using this function.

  For example:
  Python 3.5.1+ (default, Mar 30 2016, 22:46:26)
  [GCC 5.3.1 20160330] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> from curtin import block
  >>> block.get_blockdev_sector_size('/dev/sda1')
  (512, 512)
  >>> block.get_blockdev_sector_size('/dev/sda5')
  Traceback (most recent call last):
    File "", line 1, in 
    File "/home/magicanus/code/curtin-clean/curtin/curtin/block/__init__.py", 
line 426, in get_blockdev_sector_size
  [parent] = info
  ValueError: too many values to unpack (expected 1)
  >>> block.get_blockdev_sector_size('/dev/sda')
  Traceback (most recent call last):
    File "", line 1, in 
    File "/home/magicanus/code/curtin-clean/curtin/curtin/block/__init__.py", 
line 426, in get_blockdev_sector_size
  [parent] = info
  ValueError: too many values to unpack (expected 1)

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1598310/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1618429] Re: Curtin doesn't clean up previous MD configuration

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1618429

Title:
  Curtin doesn't clean up previous MD configuration

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * On some machines which have existing MDADM RAID metadata on one or
 more of disks, curtin fails to remove this existing metadata when
 instructed to do so and fails to install on such machines.

 Curtin has been updated to ignore mdadm asseble errors specifically
 in the case where curtin has been instructed to wipe a designated
 device. In the above case, curtin encountered an unexpected return
 code from mdadm assemble command which is not relevant since curtin
 is going to wipe the underlying device for re-installation.
 
  [Test Case]

   * Install proposed curtin package and deploy to a machine with a
 partial mdadm raid array which cannot be properly assembled.

PASS: Successfully deploy image with RAID configuration included.

FAIL: Deployment fails with the following error:

  Command: ['mdadm', '--assemble', '--scan']
  Exit code: 3
  Reason: -
  Stdout: ''
  Stderr: u'mdadm: /dev/md/4 assembled from 3 drives
  not enough to start the array.

  [Regression Potential]

   * Users requesting curtin 'preserve' existing raid configurations may
 be impacted.

  
  [Original Description]

  When deploying a machine in MAAS with a MD setup, deployment fails.
  Inspection shows that curtin doesn't clean up existin MD devices. On a
  failed machine I can see in dmesg:

  [   22.352672] md/raid1:md2: active with 2 out of 2 mirrors
  [   22.730212] md/raid1:md1: active with 2 out of 2 mirrors

  these are MD devices from previous deployment. Instead of deleting
  those, curtin tries to create a new one. So /proc/mdstat shows:

  Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] 
[raid10]
  md3 : inactive md1[1](S) md2[2](S)
    3125299568 blocks super 1.2

  md1 : active raid1 sdd[1] sdc[0]
    1562649792 blocks super 1.2 [2/2] [UU]

  md2 : active raid1 sdf[1] sde[0]
    1562649792 blocks super 1.2 [2/2] [UU]

  unused devices: 

  MAAS's storage config appears to be correct.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1618429/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1597522] Re: curtin passes wrong args to mkfs when making filesystem on advanced format disks

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1597522

Title:
  curtin passes wrong args to mkfs when making filesystem on advanced
  format disks

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * curtin passes wrong args to mkfs when making filesystem on advanced
 format disks (4k sector size)

 Curtin has been modified to only pass the '-s 1' sector-size flag 
 to the vfat formatting tools.  Curtin has been updated to specify
 the correct sector-size flags and values to other formatting
 utilities that support such settings.
 

  [Test Case]

   * Install proposed curtin package and attempt to format a disk with
 xfs filesystem using 4K logical blocksize for the disk.

PASS: Ubuntu successfully installs with xfs filesystem on top of a
  4k Disk

FAIL: Ubuntu fails to install with xfs filesystem on 4k disk.
  
  [Regression Potential]

   * Low; current users expecting xfs on 4k disks were blocked without
 this fix.

  
  [Original Description]
  During format handling, curtin detects the underlying block size of the disk 
and sets the filesystem block size accordingly.

  In order to properly handle a bug in mkfs.vfat, curtin adds the flag
  '-s 1'. However, curtin adds this flag to all disk format commands,
  not just to commands using 'mkfs.vfat'. This can lead to unexpected
  behavior with some formatting tools, and can cause installation to
  halt with others.

  For example, the mkfs.btrfs utility understands '-s' to mean
  sectorsize, so when curtin installs to an advanced format disk and
  storage config includes a btrfs formatted filesystem, curtin will
  create a filesystem that uses 1 byte sectors. This will greatly harm
  filesystem performance.

  For xfs volumes, this means that installation will fail completely, as
  the sectorsize attribute for xfs volumes must be specified in the
  format '-s size=512', so '-s 1' will cause mkfs.xfs to fail.

  Fortunately, this does not affect mkfs.ext* because these tools seem
  to silently ignore the '-s' flag, so most users likely have not been
  affected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1597522/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1592149] Re: simple networking mode (net-meta) does not account for device names

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1592149

Title:
  simple networking mode (net-meta) does not account for device names

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Trusty:
  Fix Released
Status in curtin source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * Users which do not use a customized network configuration rely
 on curtin's fallback/automatic configuration.  On Xenial and newer
 systems the network configuration that is generated doesn't always
 work due to the persistent nic names which do not match between
 initial install environment and booting the system after
 installation.

 This affects all curtin releases which use auto configure
 networking and an Ubuntu release which uses persistent network
 device nameing.
 
   * This SRU resolves the bug by ensuring auto configured networking
 includes nic naming rules to ensure the network device names match
 what is generated in the config.

  
  [Test Case]

   * On a Xenial 16.04 system
  - % apt-get install curtin
  - % OUTPUT_NETWORK_CONFIG=rendered-eni curtin net-meta -t /tmp auto

  
FAIL: Systems with the error will print an interfaces file to stdout

PASS: Systems with the fix with emit host networking config to the file
  "rendered-eni" and produces no output to stdout.

  
  [Regression Potential]

   * Users that use auto configuration may find that the persistent nic
 names in the target system are no longer ethN, but named based on
 location.

  
  [Original Description]
  I ran
   nosetests3 -v tests/vmtests/test_basic.py:XenialTestBasic
  and was seeing failures.

  That does an install without network config, so it relies on 'net-
  meta' of 'auto'.

  The install worked, but boot failed as networking was not configured.

  The issue is that the net-meta was writing /etc/network/interfaces
  file, but no udev rules or other mechanism to ensure that the device
  got the same name in the new environment.  That, coupled with a change
  in the commands between 'launch' and 'xkvm' meant that the install
  environment named the device 'ens3' and the installed environment
  'ens4'.

  I'll attach logs just for completeness.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1592149/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1551636] Re: MaaS on older releases need support for newer curtin images

[Scott Moser]

This bug is believed to be fixed in curtin in 17.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1551636

Title:
  MaaS on older releases need support for newer curtin images

Status in curtin:
  Fix Released
Status in MAAS:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Trusty:
  Confirmed
Status in curtin source package in Wily:
  Confirmed
Status in curtin source package in Xenial:
  Fix Released

Bug description:
  This came up when we chatted about problems using Xenial images on
  Maas this morning. And it will likely become a big problem when Xenial
  is released. Server environments do not change that quickly, so we
  should expect hosts running Trusty (cloud-archive or maas from the
  PPA) trying to provision Xenial.

  This currently is broken because the smarts of the curtin installer
  seems to have changed and the rootfs-tgz (the base filesystem used) no
  longer comes with the kernel (and modules) pre-installed. But the init
  phase of older curtin versions does not include steps to download a
  kernel from the archive. So we end up with a client that starts the
  final reboot without any kernel installed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1551636/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1735046] Re: mkfs.btrfs error checking mount status of loop device backing_file

[Scott Moser]

I just marked xenial explicitly as fixed here.  The fix is in all
supported ubuntu releases > trusty.


** Also affects: btrfs-tools (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Changed in: btrfs-tools (Ubuntu)
   Status: New => Fix Released

** Changed in: btrfs-tools (Ubuntu Trusty)
   Status: New => In Progress

** Changed in: btrfs-tools (Ubuntu Trusty)
   Importance: Undecided => Medium

** Changed in: btrfs-tools (Ubuntu Trusty)
 Assignee: (unassigned) => Ryan Harper (raharper)

** Also affects: btrfs-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: btrfs-tools (Ubuntu Xenial)
   Status: New => Fix Released

** Changed in: btrfs-tools (Ubuntu Xenial)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1735046

Title:
  mkfs.btrfs error checking mount status of loop device backing_file

Status in btrfs-tools package in Ubuntu:
  Fix Released
Status in btrfs-tools source package in Trusty:
  In Progress
Status in btrfs-tools source package in Xenial:
  Fix Released

Bug description:
  SRU Template

  [Impact]

   * Users may be unable to successfully create a btrfs filesystem on 
 block devices when a loop device is mounted and the backing file
 no longer exists.  This typically happens in the precense of
 overlayroot but may be encountered in other situations.

 This affects the btrfs-tools package prior to the 3.13 release.
 
   * Backporting the fix from the upstream repository is required to
 allow Trusty MAAS/Cloud images which use overlayrootfs to create
 btrfs filesystems in the presence of a loopdevice with a missing
 backing file.

   * All patches applied are already accepted upstream.  Xenial, Artful,
 and Bionic are not affected.
 

  [Test Case]

   * On a Trusty 14.04 system with a secondary disk (vdb)
  - apt-get install btrfs-tools
  - truncate -s 1G testloop.img
  - losetup /dev/loop0 testloop.img
  - mkfs.ext4 /dev/loop0
  - mount /dev/loop0 /mnt
  - rm testloop.img
  - mkfs.btrfs --force /dev/vdb

  PASS if mkfs.btrfs returns 0 and /dev/vdb has a btrfs filesystem

  FAIL if mkfs.btrfs returns non-zero and /dev/vdb does not have a
  btrfs filesystem.  mkfs.btrfs returns the error message:

  Error: error checking /dev/vdb mount status

  [Regression Potential]

   * mkfs.btrfs fails to detect that the target device is already mounted
 and an existing btrfs filesystem is destroyed.

  
  [Original Description]
  # lsb_release -rd
  Description:Ubuntu 14.04.5 LTS
  Release:14.04

  # apt-cache policy btrfs-tools
  btrfs-tools:
    Installed: 3.12-1ubuntu0.1
    Candidate: 3.12-1ubuntu0.1
    Version table:
   *** 3.12-1ubuntu0.1 0
  500 http://archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   3.12-1 0
  500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

  # mkfs.btrfs --force /dev/vdd   succeeds

  # # mkfs.btrfs --force /dev/vdd
  Error: error checking /dev/vdd mount status

  # strace -f mkfs.btrfs --force /dev/vdd
  
  stat("/dev/loop0", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0
  lstat("/dev", {st_mode=S_IFDIR|0755, st_size=4180, ...}) = 0
  lstat("/dev/loop0", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0
  open("/sys/block//loop0/loop/backing_file", O_RDONLY) = 5
  fstat(5, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fe8bd73c000
  read(5, "/root.tmp.img (deleted)\n", 4096) = 24
  close(5)= 0
  munmap(0x7fe8bd73c000, 4096)= 0
  lstat("/dev", {st_mode=S_IFDIR|0755, st_size=4180, ...}) = 0
  lstat("/dev/vdd", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 48), ...}) = 0
  lstat("/root.tmp.img (deleted)", 0x7ffeaa3f0bf0) = -1 ENOENT (No such file or 
directory)
  close(4)= 0
  munmap(0x7fe8bd73d000, 4096)= 0
  close(3)= 0
  write(2, "Error: error checking /dev/vdd m"..., 44Error: error checking 
/dev/vdd mount status
  ) = 44
  exit_group(1)   = ?
  +++ exited with 1 +++

  It appears that mkfs.btrfs doesn't like the loop device, /dev/loop0
  which has a deleted backing file.

  root@ubuntu:~# cat /sys/block/loop0/loop/backing_file
  /root.tmp.img (deleted)
  root@ubuntu:~# ls -al /root.tmp.img
  ls: cannot access /root.tmp.img: No such file or directory

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: btrfs-tools 3.12-1ubuntu0.1
  ProcVersionSignature: Ubuntu 3.13.0-135.184-generic 3.13.11-ckt39
  Uname: Linux 3.13.0-135-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.27
  Architecture: amd64
  

[Group.of.nepali.translators] [Bug 1666573] Re: transient systemd ordering cycle in boot with overlayroot ver read-only open-iscsi root

[Scott Moser]

I'm going to un-tag this bug for sru, as I'm planning on sru-ing a the second 
fix.
The change in this bug resulted in the following change in the rendered 
/etc/fstab:
 - LABEL=cloudimg-rootfs /media/root-ro/ ext4 ro,defaults 0 0
 + LABEL=cloudimg-rootfs /media/root-ro/ ext4 ro,defaults,noauto 0 0

The change in bug 1723183 was:

 - LABEL=cloudimg-rootfs /media/root-ro/ ext4 ro,defaults,noauto 0 0
 + #LABEL=cloudimg-rootfs /media/root-ro/ ext4 ro,defaults,noauto 0 0

That change supersedes this one.

** Description changed:

-  Begin SRU Template 
- [Impact] 
- Overlayfs allows a user to mount the root filesystem read-only
- and put an overlay over it.
- It handles mounting of the root filesystem in the initramfs, and updates
- /etc/fstab to account for non-root filesystems and generally make
- /etc/fstab "correct".
- 
- systemd can get confused by a /etc/fstab that looks like this:
- 
-LABEL=cloudimg-rootfs /media/root-ro/ ext4 ro,defaults,noauto 0 0
-/media/root-ro/ / overlay lowerdir=...
- 
- It would not recognize that the LABEL=cloudimg-rootfs image *was* mounted.
- This would lead to boot ordering cycles.  The fix that was ultimately
- applied was just to comment out the line for /media/root-ro.
- 
- That way systemd wouldnt try to ensure that /media/root-ro got mounted.
- 
- [Test Case]
- TBD
- 
- [Regression Potential] 
- Not to omany things would depend on the /etc/fstab that exists in
- an system booted with overlayroot.  Something that was reading /etc/fstab
- could be confused by this change.
- 
- [Other Info]
- This change is believed to fix bug 1680197 as well, but due to the
- sporadic nature, we are not certain.
- 
-  End SRU Template 
- 
  In the open-iscsi test we boot a read-only root iscsi target, using
  overlayroot.
  
  Transiently this operation fails, ultimately leading to emergency shell.
  Since this occurs in automated test, there is no access to that console
  (it is being logged to a file).
  
  The open iscsi test that triggers this is described at [1], including how
  to run it.
  
  Most recently, the open-iscsi version 2.0.873+git0.3b4b4500-14ubuntu17 has
  run both successfully and failed when running for trigger cloud-utils and
  systemd [2]
  
  I am attaching a tarball with logs and artifacts from the autopackage
  test runs here for posterity.
  
  In the failure case we see evidence of failure at
    [   52.729092] systemd[1]: media-root\x2dro.mount: Found ordering cycle on 
media-root\x2dro.mount/start
    [   52.730938] systemd[1]: media-root\x2dro.mount: Found dependency on 
-.mount/start
    [   52.735138] systemd[1]: media-root\x2dro.mount: Found dependency on 
media-root\x2dro.mount/start
    [   52.739910] systemd[1]: Unable to break cycle
    [   52.744992] systemd[1]: Requested transaction contains an unfixable 
cyclic ordering dependency: Resource deadlock avoided
  
  And then it all goes sour later with:
    [ TIME ] Timed out waiting for device dev-disk-by\x2dlabel-UEFI.device.
    [DEPEND] Dependency failed for /boot/efi.
    [DEPEND] Dependency failed for Local File Systems.
    [ TIME ] Timed out waiting for device VIRTUAL-DISK cloudimg-rootfs.
  
  for reference, the image's fstab is:
    LABEL=cloudimg-rootfs   /ext4   defaults0 0
    LABEL=UEFI  /boot/efi   vfatdefaults0 0
  
  but /etc/fstab is updated by overlayroot in the initramfs, and as such
  contains the following:
    #
    #  This fstab is in an overlay. The real one can be found at
    #  /media/root-ro/etc/fstab
    #  The original entry for '/' and other mounts have been updated to be 
placed
    #  under /media/root-ro.
    #  To permanently modify this (or any other file), you should change-root 
into
    #  a writable view of the underlying filesystem using:
    #  sudo overlayroot-chroot
    #
    LABEL=cloudimg-rootfs /media/root-ro/ ext4 ro,defaults 0 0
    /media/root-ro/ / overlay 
lowerdir=/media/root-ro/,upperdir=/media/root-rw/overlay/,workdir=/media/root-rw/overlay-workdir/_
 0 0
    LABEL=UEFI /boot/efi vfat defaults 0 0 # overlayroot:fs-unsupported
  
  --
  [1] 
https://git.launchpad.net/~usd-import-team/ubuntu/+source/open-iscsi/tree/debian/tests/README-boot-test.md?h=ubuntu/devel
  [2] http://autopkgtest.ubuntu.com/packages/o/open-iscsi/zesty/amd64
  
  ProblemType: Bug
  DistroRelease: Ubuntu 17.04
  Package: open-iscsi 2.0.873+git0.3b4b4500-14ubuntu17
  ProcVersionSignature: User Name 4.9.0-15.16-generic 4.9.5
  Uname: Linux 4.9.0-15-generic x86_64
  ApportVersion: 2.20.4-0ubuntu2
  Architecture: amd64
  Date: Tue Feb 21 15:50:58 2017
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: open-iscsi
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.iscsi.iscsid.conf: [inaccessible: [Errno 13] 
Permission denied: '/etc/iscsi/iscsid.conf']
  
  Related bugs:
   * bug 1680197: Zesty 

[Group.of.nepali.translators] [Bug 1741300] [NEW] mount-image-callback fails on qcow image on xenial

[Scott Moser]

Public bug reported:

On xenial only:

$ wget 
http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img
$ cp -a xenial-server-cloudimg-amd64-disk1.img disk.img
$ sudo mount-image-callback -v disk.img truewaiting on pidfile for /dev/nbd0 in 
/sys/block/nbd0/pid
connected disk.img (qcow2) to /dev/nbd0. waiting for device.
partitioned disk.
waiting for /dev/nbd0p1 part=1 to be ready.
waiting for /dev/nbd0p1 part=1 to be ready.
waiting for /dev/nbd0p1 part=1 to be ready.
waiting for /dev/nbd0p1 part=1 to be ready.
waiting for /dev/nbd0p1 part=1 to be ready.
waiting for /dev/nbd0p1 part=1 to be ready.
waiting for /dev/nbd0p1 part=1 to be ready.
waiting for /dev/nbd0p1 part=1 to be ready.
waiting for /dev/nbd0p1 part=1 to be ready.
gave up on waiting for /dev/nbd0p1
$ echo $?
1

This fix seems to work and should be safe.
=== modified file 'bin/mount-image-callback'
--- bin/mount-image-callback2018-01-03 15:44:47 +
+++ bin/mount-image-callback2018-01-04 17:21:23 +
@@ -316,6 +316,8 @@
fi
 
i=0
+   [ -b "$mdev" ] || blockdev --rereadpt $nbd ||
+   { error "blockdev --rereadpt $nbd failed"; return 1; }
while :; do
[ -b "$mdev" ] && break
i=$(($i+1))

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: cloud-image-utils 0.27-0ubuntu24
ProcVersionSignature: User Name 4.4.0-104.127-generic 4.4.98
Uname: Linux 4.4.0-104-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.14
Architecture: amd64
Date: Thu Jan  4 17:23:15 2018
Ec2AMI: ami-0388
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
PackageArchitecture: all
ProcEnviron:
 TERM=screen
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: cloud-utils
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: cloud-utils (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: cloud-utils (Ubuntu Xenial)
 Importance: Undecided
 Status: Fix Released

** Affects: cloud-utils (Ubuntu Artful)
 Importance: Undecided
 Status: Fix Released

** Affects: cloud-utils (Ubuntu Bionic)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug ec2-images xenial

** Also affects: cloud-utils (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: cloud-utils (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cloud-utils (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: cloud-utils (Ubuntu Xenial)
   Status: New => Fix Released

** Changed in: cloud-utils (Ubuntu Artful)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1741300

Title:
  mount-image-callback fails on qcow image on xenial

Status in cloud-utils package in Ubuntu:
  New
Status in cloud-utils source package in Xenial:
  Fix Released
Status in cloud-utils source package in Artful:
  Fix Released
Status in cloud-utils source package in Bionic:
  New

Bug description:
  On xenial only:

  $ wget 
http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img
  $ cp -a xenial-server-cloudimg-amd64-disk1.img disk.img
  $ sudo mount-image-callback -v disk.img truewaiting on pidfile for /dev/nbd0 
in /sys/block/nbd0/pid
  connected disk.img (qcow2) to /dev/nbd0. waiting for device.
  partitioned disk.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  gave up on waiting for /dev/nbd0p1
  $ echo $?
  1

  This fix seems to work and should be safe.
  === modified file 'bin/mount-image-callback'
  --- bin/mount-image-callback2018-01-03 15:44:47 +
  +++ bin/mount-image-callback2018-01-04 17:21:23 +
  @@ -316,6 +316,8 @@
  fi
   
  i=0
  +   [ -b "$mdev" ] || blockdev --rereadpt $nbd ||
  +   { error "blockdev --rereadpt $nbd failed"; return 1; }
  while :; do
  [ -b "$mdev" ] && break
  i=$(($i+1))

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: cloud-image-utils 0.27-0ubuntu24
  ProcVersionSignature: User Name 4.4.0-104.127-generic 4.4.98
  Uname: Linux 4.4.0-104-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.14
  Architecture: amd64
  Date: Thu Jan  4 17:23:15 2018
  Ec2AMI: ami-0388
  Ec2AMIManifest: FIXME
  Ec2AvailabilityZone: nova
  Ec2InstanceType: m1.small
  Ec2Kernel: unavailable
  E

[Group.of.nepali.translators] [Bug 1741300] Re: mount-image-callback fails on qcow image on xenial

[Scott Moser]

** Changed in: cloud-utils (Ubuntu Xenial)
   Status: Fix Released => Confirmed

** Changed in: cloud-utils (Ubuntu Bionic)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1741300

Title:
  mount-image-callback fails on qcow image on xenial

Status in cloud-utils package in Ubuntu:
  Fix Released
Status in cloud-utils source package in Xenial:
  Confirmed
Status in cloud-utils source package in Artful:
  Fix Released
Status in cloud-utils source package in Bionic:
  Fix Released

Bug description:
  On xenial only:

  $ wget 
http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img
  $ cp -a xenial-server-cloudimg-amd64-disk1.img disk.img
  $ sudo mount-image-callback -v disk.img truewaiting on pidfile for /dev/nbd0 
in /sys/block/nbd0/pid
  connected disk.img (qcow2) to /dev/nbd0. waiting for device.
  partitioned disk.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  waiting for /dev/nbd0p1 part=1 to be ready.
  gave up on waiting for /dev/nbd0p1
  $ echo $?
  1

  This fix seems to work and should be safe.
  === modified file 'bin/mount-image-callback'
  --- bin/mount-image-callback2018-01-03 15:44:47 +
  +++ bin/mount-image-callback2018-01-04 17:21:23 +
  @@ -316,6 +316,8 @@
  fi
   
  i=0
  +   [ -b "$mdev" ] || blockdev --rereadpt $nbd ||
  +   { error "blockdev --rereadpt $nbd failed"; return 1; }
  while :; do
  [ -b "$mdev" ] && break
  i=$(($i+1))

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: cloud-image-utils 0.27-0ubuntu24
  ProcVersionSignature: User Name 4.4.0-104.127-generic 4.4.98
  Uname: Linux 4.4.0-104-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.14
  Architecture: amd64
  Date: Thu Jan  4 17:23:15 2018
  Ec2AMI: ami-0388
  Ec2AMIManifest: FIXME
  Ec2AvailabilityZone: nova
  Ec2InstanceType: m1.small
  Ec2Kernel: unavailable
  Ec2Ramdisk: unavailable
  PackageArchitecture: all
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: cloud-utils
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-utils/+bug/1741300/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1743618] Re: sru curtin 2018-01-16 - 17.1-5-gfae8ffb1

[Scott Moser]

** Summary changed:

- sru curtin 20180116 - 17.1-5-gfae8ffb1
+ sru curtin 2018-01-16 - 17.1-5-gfae8ffb1

** Summary changed:

- sru curtin 2018-01-16 - 17.1-5-gfae8ffb1
+ sru curtin 2018-01-16 - 17.1-6-g8b145067

** No longer affects: curtin (Ubuntu)

** Changed in: curtin (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: curtin (Ubuntu Artful)
   Status: New => In Progress

** Changed in: curtin (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: curtin (Ubuntu Artful)
   Importance: Undecided => Medium

** Changed in: curtin (Ubuntu Xenial)
 Assignee: (unassigned) => Ryan Harper (raharper)

** Changed in: curtin (Ubuntu Artful)
 Assignee: (unassigned) => Ryan Harper (raharper)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1743618

Title:
  sru curtin 2018-01-16 - 17.1-6-g8b145067

Status in curtin source package in Xenial:
  In Progress
Status in curtin source package in Artful:
  In Progress

Bug description:
  == Begin SRU Template ==
  [Impact]
  This release sports both bug-fixes and new features and we would like to
  make sure all of our supported customers have access to these improvements.
  The notable ones are:

     * storage: add 'options' key mount type to specify mount parameters for
   filesystems (LP: #1709284)
     * Re-add curthooks.write_files method for backwards compat
   (LP: #1731709)
     * block: handle wiping bcache parts (LP: #1718699)
     * bcache: accept sysfs write failure in shutdown handler if path
   missing (LP: #1700564)
     * block_meta: use block.wipe_volume(mode=superblock) to clear MBR/GPT
   tables (LP: #1722322)

  See the changelog entry below for a full list of changes and bugs.

  [Test Case]
  The following development and SRU process was followed:
  https://wiki.ubuntu.com/CurtinUpdates

  Curtin now contains an extensive integration test suite that is ran using
  the SRU package for each releases. These suite has documentation here:
  https://curtin.readthedocs.io/en/latest/topics/integration-testing.html

  In order to avoid regression to existing MAAS product, the MAAS team will
  run their continuous integration test against the curtin that is in
  -proposed.  A successful run will be required before the proposed curtin
  can be let into -updates.

  The curtin team will be in charge of attaching the artifacts and console
  output of the appropriate run to the bug.  Curtin team members will not
  mark ‘verification-done’ until this has happened.

  [Verification]
  integration tests for xenial:
   * log: see attached TODO
   * artifacts: see attached TODO

  integration tests for artful:
   * log: see attached TODO
   * artifacts: see attached TODO

  maas qa tests for xenial:
   * log: see attached TODO
   * artifacts: see attached TODO

  [Regression Potential]
  In order to mitigate the regression potential, the results of the
  aforementioned integration tests are attached to this bug.

  
  

  [Discussion]
  The primary motiviation for this SRU is to bring 'options' mount parameters 
(LP# 1709284).

  == End SRU Template ==

  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/xenial/+source/curtin/+bug/1743618/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1527727] Re: grub-probe for zfs assumes all devices prefix with /dev, ignoring /dev/disk/...

[Scott Moser]

I've marked this 'Fix Released' in xenial as Ubuntu's package in xenial
at 0.6.5.6-0ubuntu3 which has the fix at [1] as mentioned in comment 29.
Further, my experience with our zfs work in curtin indicates that it is
fixed.

--
https://github.com/zfsonlinux/zfs/commit/d2f3e292dccab23e47ade3c67677a10f353b9e85

** Changed in: zfs-linux (Ubuntu Xenial)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1527727

Title:
  grub-probe for zfs assumes all devices prefix with /dev, ignoring
  /dev/disk/...

Status in grub:
  Unknown
Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2-signed package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  Fix Released
Status in grub2 source package in Xenial:
  In Progress
Status in grub2-signed source package in Xenial:
  In Progress
Status in zfs-linux source package in Xenial:
  Fix Released

Bug description:
  [Impact]
  Installs over ZFS where a ZFS disk is expected to be used as a root device.

  [Test case]
  - Run update-grub on a system with a ZFS root filesystem.

  [Regression Potential]
  Installs relying on the current broken behavior to avoid listing other 
operating systems in grub menu may find that new entries are added.

  ---

  update-grub runs /usr/sbin/grub-probe

  Without libzfslinux support compiled in, /usr/sbin/grub-probe runs
  ["zpool", "status", poolname] to find out ZFS info.

  zpool responds with device names as used at (I think!) pool creation
  time. Often, this is /dev/disk/by-id/... names, without the path.

  grub-probe then parses the output, and takes the names of devices, and
  if they do not start with a "/", it prepends "/dev/".

  It then tests the existence of the path name of the device. it fails.

  grub-probe then returns  something like

  /usr/sbin/grub-probe: error: failed to get canonical path of `/dev
  /ata-ST31000333AS_-part1'.

  The actual path is of course /dev/disk/by-
  id/ST31000333AS_-part1

  It can prepend smarter than "/dev" or it can understand ZFS natively,
  to fix the problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/grub/+bug/1527727/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1742560] Re: zfsutils-linux recommends dkms when it's not needed

[Scott Moser]

** Changed in: zfs-linux (Ubuntu)
   Status: New => Fix Released

** Changed in: zfs-linux (Ubuntu)
   Importance: Undecided => Medium

** Also affects: zfs-linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: zfs-linux (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: zfs-linux (Ubuntu Xenial)
   Importance: Undecided => Medium

** Also affects: zfs-linux (Ubuntu Bionic)
   Importance: Medium
   Status: Fix Released

** Also affects: zfs-linux (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: zfs-linux (Ubuntu Artful)
   Status: New => Fix Released

** Changed in: zfs-linux (Ubuntu Artful)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1742560

Title:
  zfsutils-linux recommends dkms when it's not needed

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Confirmed
Status in zfs-linux source package in Artful:
  Fix Released
Status in zfs-linux source package in Bionic:
  Fix Released

Bug description:
  1.
  $ lsb_release -rd
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04

  2.
  $ apt-cache policy zfsutils-linux
  zfsutils-linux:
Installed: 0.6.5.6-0ubuntu18
Candidate: 0.6.5.6-0ubuntu18
Version table:
   *** 0.6.5.6-0ubuntu18 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   0.6.5.6-0ubuntu8 500
  500 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages

  3. apt install zfsutils-linux does not install dkms,spl-dkms and
  dependencies since 16.04 kernel already contains zfs.ko

  4. apt install zfsutils-linux installs all of the following:

  dkms fakeroot gcc gcc-5 libasan2 libatomic1 libc-dev-bin libc6-dev libcc1-0 
libcilkrts5 libfakeroot libfreetype6 libgcc-5-dev libgomp1 libitm1
liblsan0 libmpx0 libquadmath0 libtsan0 libubsan0 linux-libc-dev 
manpages-dev spl spl-dkms

  and then any kernel install/update then attempts to dkms rebuild zfs
  and spl even though the modules are already provided.

  % dpkg -S /lib/modules/4.13.0-19-generic/kernel/zfs/zfs/zfs.ko
  linux-image-4.13.0-19-generic: 
/lib/modules/4.13.0-19-generic/kernel/zfs/zfs/zfs.ko
  % dpkg -S /lib/modules/4.13.0-19-generic/kernel/zfs/spl/spl.ko
  linux-image-4.13.0-19-generic: 
/lib/modules/4.13.0-19-generic/kernel/zfs/spl/spl.ko

  
  We can see from the package requirements, that it Recommends zfs-dkms, but 
only on Xenial.  Releases newer than Xenial do not have this package 
requirement.  

  % apt-cache show zfsutils-linux
  Package: zfsutils-linux
  Architecture: amd64
  Version: 0.6.5.6-0ubuntu18
  Priority: extra
  Section: admin
  Source: zfs-linux
  Origin: Ubuntu
  Maintainer: Ubuntu Developers 
  Original-Maintainer: Darik Horn 
  Bugs: https://bugs.launchpad.net/ubuntu/+filebug
  Installed-Size: 779
  Provides: zfs
  Depends: init-system-helpers (>= 1.18~), zfs-doc (= 0.6.5.6-0ubuntu18), 
libblkid1 (>= 2.16), libc6 (>= 2.14), libnvpair1linux, libuuid1 (>= 2.16), 
libuutil1linux, libzfs2linux, libzpool2linux, python3:any (>= 3.3.2-2~), python3
  Recommends: zfs-dkms, zfs-zed
  Suggests: samba-common-bin (>= 3.0.23), nfs-kernel-server, zfs-initramfs
  Conflicts: zfs, zfs-fuse
  Replaces: zfs
  Filename: pool/main/z/zfs-linux/zfsutils-linux_0.6.5.6-0ubuntu18_amd64.deb
  Size: 275970
  MD5sum: 02ead25f1fed812980d70865da916468
  SHA1: e6736c223c3b2198bba8777153836bb8d4789518
  SHA256: c4ad2b81ee13072cb3f4e31fd3aed93cf66c7c50872fc542cc2425120b222eed
  Homepage: https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.6.5.6
  Description-en: Native OpenZFS management utilities for Linux
   This package provides the zpool and zfs commands that are used to
   manage OpenZFS filesystems.
  Description-md5: 7b0f98269f6c33505790717cd478736c
  Supported: 5y

  
  Here's Artful
  ~$ lsb_release -rd
  Description:  Ubuntu 17.10
  Release:  17.10
  $ apt-cache show zfsutils-linux
  Package: zfsutils-linux
  Architecture: amd64
  Version: 0.6.5.11-1ubuntu3
  Priority: extra
  Section: admin
  Source: zfs-linux
  Origin: Ubuntu
  Maintainer: Ubuntu Developers 
  Original-Maintainer: Debian ZFS on Linux maintainers 

  Bugs: https://bugs.launchpad.net/ubuntu/+filebug
  Installed-Size: 1100
  Provides: zfsutils
  Depends: init-system-helpers (>= 1.18~), libblkid1 (>= 2.16), libc6 (>= 
2.14), libnvpair1linux, libuuid1 (>= 2.16), libuutil1linux, libzfs2linux, 
libzpool2linux, python3:any, python3
  Recommends: lsb-base, zfs-zed
  Suggests: nfs-kernel-server, samba-common-bin (>= 3.0.23), zfs-initramfs | 
zfs-dracut
  Conflicts: zfs, zfs-fuse, zutils
  Filename: pool/main/z/zfs-linux/zfsutils-linux_0.6.5.11-1ubuntu3_amd64.deb
  Size: 328574
  MD5sum: d1ce7f5ffa75c9b46e7d5285430efff3
  SHA1: 8a8ab05186b83c3

[Group.of.nepali.translators] [Bug 1581416] Re: grub-legacy-ec2 installs files in /etc/kernel/kernel/post(inst|rm).d

[Scott Moser]

I've just pushed a commit to cloud-init's upstream packaging for this at [1]
It should get pulled into the next ubuntu Stable Release of cloud-init.
A "cloud-init daily" ppa build should occur tonight and arrive at [2].

You can test that PPA with:
  sudo add-apt-repository ppa:cloud-init-dev/daily
  sudo apt-get update

It would be helpful if you provided feedback here that the changes fix the
issue you are having.  Also, please provide some info on where you were
seeing an issue.  I'm trying to grab information on where this grub-legacy-ec2
code still runs.

Thanks!


[1] 
https://git.launchpad.net/cloud-init/commit/?h=ubuntu/xenial&id=f12fc84e8bf88b
[2] https://launchpad.net/~cloud-init-dev/+archive/ubuntu/daily

** Also affects: cloud-init (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Artful)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu Artful)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1581416

Title:
  grub-legacy-ec2 installs files in /etc/kernel/kernel/post(inst|rm).d

Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Artful:
  Fix Released

Bug description:
  Hi,

  can't use apport, so reporting this via the web.

  $ lsb_release -rd
  Description:Ubuntu 16.04 LTS
  Release:16.04
  $ apt-cache policy grub-legacy-ec2
  grub-legacy-ec2:
Installed: 0.7.7~bzr1212-0ubuntu1
Candidate: 0.7.7~bzr1212-0ubuntu1
Version table:
   *** 0.7.7~bzr1212-0ubuntu1 500
  500 http://de.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  500 http://de.archive.ubuntu.com/ubuntu xenial/main i386 Packages
  100 /var/lib/dpkg/status

  The debian/grub-legacy-ec2.install file seems to be wrong, files end
  up in

  $ dpkg -L grub-legacy-ec2  | grep /etc
  /etc
  /etc/kernel
  /etc/kernel/kernel
  /etc/kernel/kernel/postinst.d
  /etc/kernel/kernel/postinst.d/x-grub-legacy-ec2
  /etc/kernel/kernel/postrm.d
  /etc/kernel/kernel/postrm.d/x-grub-legacy-ec2

  where they will not be picked up by linux-image-* postinst scripts.

  Cheers
  Wolfgang

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1581416/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1747059] Re: sru cloud-init (17.1.46-g7acc9e86-0ubuntu1) update to 17.2.30-gf7deaf15-0ubuntu1

[Scott Moser]

** Also affects: cloud-init (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Artful)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Artful)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1747059

Title:
  sru cloud-init (17.1.46-g7acc9e86-0ubuntu1) update to
  17.2.30-gf7deaf15-0ubuntu1

Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Artful:
  Confirmed

Bug description:
  == Begin SRU Template ==

  [Impact]
  This release provides both bug-fixes and new features and we would like to
  make sure all of our supported customers have access to these
  improvements. Notable changes for Ubuntu stable releases are:

  
  - debian/grub-legacy-ec2.install: install post(inst|rm) files correctly.
[Simon Deziel] (LP: #1581416)
  - OVF: Extend well-known labels to include OVFENV. (LP: #1698669)
  - Fix potential cases of uninitialized variables. (LP: #1744796)
  - Azure VM Preprovisioning support. [Douglas Jordan] (LP: #1734991)
  - btrfs: support resizing if root is mounted ro.
[Robert Schweikert] (LP: #1734787)
  - OpenNebula: Improve network configuration support.
[Akihiko Ota] (LP: #1719157, #1716397, #1736750)
  - GCE: Improvements and changes to ssh key behavior for default user.
[Max Illfelder] (LP: #1670456, #1707033, #1707037, #1707039)
  - subp: make ProcessExecutionError have expected types in stderr, stdout.
  - Recognize uppercase vfat disk labels [James Penick] (LP: #1598783)
  - Do not log warning on config files that represent None. (LP: #1742479)
  - MAAS: add check_instance_id based off oauth tokens. (LP: #1712680)
  - cli: cloud-init clean handles symlinks [Chad Smith] (LP: #1741093)
  - Azure: Only bounce network when necessary. [Chad Smith] (LP: #1722668)
  - cli: Fix error in cloud-init modules --mode=init. (LP: #1736600)
  - debian/patches/ds-identify-behavior-xenial.patch: refresh patch
  - ds-identify: failure in NoCloud due to unset variable usage.
(LP: #1737704)
  - ec2: Use instance-identity doc for region and instance-id
[Andrew Jorgensen]
  - setup.py: Do not include rendered files in SOURCES.txt
  - OVF: improve ds-identify to support finding OVF iso transport.
(LP: #1731868)
  - Datasources: Formalize DataSource get_data and related properties.
[Chad Smith]
  - cli: Add clean and status subcommands [Chad Smith]

  
  See the === Changelog === entry below for a full list of changes and bugs.

  [Test Case]
  The following development and SRU process was followed:
  https://wiki.ubuntu.com/CloudinitUpdates

  The cloud-init team will be in charge of attaching the artifacts and
  console output of the appropriate run to the bug. cloud-init team
  members will not mark ‘verification-done’ until this has happened.

  * Automated Test Results
  automated lxd results are run by jenkins nightly CI
   * https://jenkins.ubuntu.com/server/job/cloud-init-ci-nightly/

  * Automated nocloud/kvm Results:
   * xenial: TODO
   * artful: TODO

  solutions testing team results:
   * xenial: TODO

  MAAS team results:
   * xenial: TODO

  Manual test artifacts from:
   * EC2: 
 - xenial: TODO
 - artful: TODO
   * nocloud:
  - Xenial :TODO
  - Artful: TODO
   * lxd: TODO
   * gce: TODO
   * azure: TODO

  Additional manual test results related to this SRU
  https://github.com/cloud-init/ubuntu-sru/tree/master/20180202

  [Regression Potential]
  In order to mitigate the regression potential, the results of the
  aforementioned integration tests are attached to this bug.

  [Other Info]

  [Discussion]

  == End SRU Template ==

  == Changelog ==
  cloud-init (17.2-30-gf7deaf15-0ubuntu1~16.04.1) UNRELEASED; urgency=medium

* New upstream snapshot.
  - docs: Update RTD content for cloud-init subcommands.
  - OVF: Extend well-known labels to include OVFENV. (LP: #1698669)
  - Fix potential cases of uninitialized variables. (LP: #1744796)
  - tests: Collect script output as binary, collect systemd journal, fix 
lxd.
  - HACKING.rst: mention setting user name and email via git config.
  - Azure VM Preprovisioning support. [Douglas Jordan] (LP: #1734991)
  - tools/read-version: Fix read

[Group.of.nepali.translators] [Bug 1749222] Re: apport-collect requires python2

[Scott Moser]

** Summary changed:

- apport-collect requires python2 or suggests installing already-installed 
python3-apport
+ apport-collect requires python2

** Changed in: apport (Ubuntu)
   Status: New => Fix Released

** Changed in: apport (Ubuntu)
   Importance: Undecided => Medium

** Also affects: apport (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: apport (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: apport (Ubuntu Xenial)
   Importance: Undecided => Low

** Description changed:

  I'm booted into a 16.04 maas rescue environment.
  
- $ apport-collect 
+ $ apport-collect
  You need to run 'sudo apt-get install python-apport' for apport-collect to 
work.
  
  running the provided command will get me a python2 stack.
  python3-apport is already installed.
  
  python3 should be used.
  
+ I then tried a stock bionic container, and run the same.  The message
+ changes to suggest python3-apport.
  
- I then tried a stock bionic container, and run the same.  The message changes 
to suggest python3-apport.
- 
- root@b1:~# apport-collect 
+ root@b1:~# apport-collect
  You need to run 'sudo apt-get install python3-apport' for apport-collect to 
work.
- 
  
  That seems better.  However, python3-apport is already installed.
  # sudo apt-get install python3-apport
  Reading package lists... Done
- Building dependency tree   
+ Building dependency tree
  Reading state information... Done
  python3-apport is already the newest version (2.20.8-0ubuntu8).
  
  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: apport 2.20.1-0ubuntu2.15
  ProcVersionSignature: User Name 4.13.0-32.35~16.04.1-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.15
  Architecture: amd64
  Date: Tue Feb 13 15:38:43 2018
  PackageArchitecture: all
  ProcEnviron:
-  TERM=xterm-256color
-  PATH=(custom, no user)
-  XDG_RUNTIME_DIR=
-  LANG=en_US.UTF-8
-  SHELL=/bin/bash
+  TERM=xterm-256color
+  PATH=(custom, no user)
+  XDG_RUNTIME_DIR=
+  LANG=en_US.UTF-8
+  SHELL=/bin/bash
  SourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)
+ 
+ Related bugs:
+  * bug 1748621: apport-collect won't work (bionic)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1749222

Title:
  apport-collect requires python2

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Xenial:
  Confirmed

Bug description:
  I'm booted into a 16.04 maas rescue environment.

  $ apport-collect
  You need to run 'sudo apt-get install python-apport' for apport-collect to 
work.

  running the provided command will get me a python2 stack.
  python3-apport is already installed.

  python3 should be used.

  I then tried a stock bionic container, and run the same.  The message
  changes to suggest python3-apport.

  root@b1:~# apport-collect
  You need to run 'sudo apt-get install python3-apport' for apport-collect to 
work.

  That seems better.  However, python3-apport is already installed.
  # sudo apt-get install python3-apport
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  python3-apport is already the newest version (2.20.8-0ubuntu8).

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: apport 2.20.1-0ubuntu2.15
  ProcVersionSignature: User Name 4.13.0-32.35~16.04.1-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.15
  Architecture: amd64
  Date: Tue Feb 13 15:38:43 2018
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

  Related bugs:
   * bug 1748621: apport-collect won't work (bionic)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1749222/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

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

[Scott Moser]

** Also affects: bcache-tools (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: bcache-tools (Ubuntu)
   Status: New => Confirmed

** Changed in: bcache-tools (Ubuntu)
   Importance: Undecided => Medium

** Changed in: bcache-tools (Ubuntu)
   Status: Confirmed => In Progress

** Changed in: bcache-tools (Ubuntu)
 Assignee: (unassigned) => Ryan Harper (raharper)

** Also affects: bcache-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: bcache-tools (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: bcache-tools (Ubuntu Bionic)
   Importance: Medium
 Assignee: Ryan Harper (raharper)
   Status: In Progress

** Also affects: bcache-tools (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: bcache-tools (Ubuntu Trusty)
   Status: New => Confirmed

** Changed in: bcache-tools (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: bcache-tools (Ubuntu Artful)
   Status: New => Confirmed

** Changed in: bcache-tools (Ubuntu Trusty)
   Importance: Undecided => Medium

** Changed in: bcache-tools (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: bcache-tools (Ubuntu Artful)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1728742

Title:
  curtin dname for bcache uses unstable devname instead of UUID

Status in bcache-tools:
  New
Status in curtin:
  New
Status in bcache-tools package in Ubuntu:
  In Progress
Status in bcache-tools source package in Trusty:
  Confirmed
Status in bcache-tools source package in Xenial:
  Confirmed
Status in bcache-tools source package in Artful:
  Confirmed
Status in bcache-tools source package in Bionic:
  In Progress

Bug description:
  Bcache device names like /dev/bcache0 are unstable.  Bcache does not
  use any predictable ordering when assembling bcache devices, so on
  systems with multiple bcache devices, a symlink to /dev/bcache0 may
  end up pointing do a different device.

  the bcache dname symlink should point to the /dev/bcache/by-
  uuid/ which matches the backing device UUID that's set at
  creation time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/bcache-tools/+bug/1728742/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1729145] Re: /dev/bcache/by-uuid links not created after reboot

[Scott Moser]

** Description changed:

  1. $ lsb_release -rd
  Description:  Ubuntu 17.10
  Release:  17.10
  
  2. $ apt-cache policy linux-image-`uname -r`
  linux-image-4.13.0-16-generic:
-   Installed: 4.13.0-16.19
-   Candidate: 4.13.0-16.19
-   Version table:
-  *** 4.13.0-16.19 500
- 500 http://nova.clouds.archive.ubuntu.com/ubuntu artful/main amd64 
Packages
- 100 /var/lib/dpkg/status
+   Installed: 4.13.0-16.19
+   Candidate: 4.13.0-16.19
+   Version table:
+  *** 4.13.0-16.19 500
+ 500 http://nova.clouds.archive.ubuntu.com/ubuntu artful/main amd64 
Packages
+ 100 /var/lib/dpkg/status
  
  3. After creating some bcache devices and rebooting 
/dev/bcache/by-uuid/ -> ../../bcacheN
  symlinks point to the current bcache device which is caching the dev.uuid 
found after creating a backing device.
  
  4. /dev/bcache/by-uuid does not exist and there are not symlinks
  underneath
  
- 
- It appears that since the initramfs loads the bcache module which probes and 
finds all of the cache devices and backing devices then once the rootfs is 
mounted and udev gets to run, the bcache kernel module does not emit the 
CACHED_UUID value into the environment if the underlying devices are already 
registered.
+ It appears that since the initramfs loads the bcache module which probes
+ and finds all of the cache devices and backing devices then once the
+ rootfs is mounted and udev gets to run, the bcache kernel module does
+ not emit the CACHED_UUID value into the environment if the underlying
+ devices are already registered.
  
  In dmesg, one can see that prior to mounting the rootfs, we see bcache
  register events:
  
  [5.333973] bcache: register_bdev() registered backing device vdb2
  [5.354138] bcache: register_bdev() registered backing device vdb4
  [5.365665] bcache: register_bdev() registered backing device vdb3
  [5.397720] bcache: bch_journal_replay() journal replay done, 0 keys in 1 
entries, seq 1
  [5.428683] bcache: register_cache() registered cache device vdb1
  
  then rootfs ismounted and systemd starts systemd-udev
  
  [9.350889] systemd[1]: Listening on udev Kernel Socket.
  
  And then the coldplug replay of kernel events triggers 
/lib/udev/rules.d/69-bcache.rules
  which invokes /lib/udev/bcache-register which writes the device name 
(/dev/vdb1 or /dev/bcache0) into /sys/fs/bcache/register and results is the 
bcache kernel driver attempting to register the block device.  However, there 
is already a bcache device associated already and registration fails
  
  [   11.173141] bcache: register_bcache() error opening /dev/vdb2: device 
already registered
  [   11.184617] bcache: register_bcache() error opening /dev/vdb3: device 
already registered
  [   11.199130] bcache: register_bcache() error opening /dev/vdb1: device 
already registered
  [   11.271694] bcache: register_bcache() error opening /dev/vdb4: device 
already registered
  
  The problem then is that only a kernel call to bch_cached_dev_run()
  which happens like this:
  
  bcache_register()
-   register_bdev()
- bch_cached_dev_run()
-   kobject_uevent_env(&disk_to_dev(d->disk)->kobj, KOBJ_CHANGE, env);
-   
- where env includes: 
- "DRIVER=bcache",
- kasprintf(GFP_KERNEL, "CACHED_UUID=%pU", dc->sb.uuid),
- NULL,
- NULL,
- };
+   register_bdev()
+ bch_cached_dev_run()
+   kobject_uevent_env(&disk_to_dev(d->disk)->kobj, KOBJ_CHANGE, env);
+ 
+ where env includes:
+ "DRIVER=bcache",
+ kasprintf(GFP_KERNEL, "CACHED_UUID=%pU", dc->sb.uuid),
+ NULL,
+ NULL,
+ };
  
  Since that event is not emitted for any previously registered device,
  then the symlink will not be created.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: linux-image-4.13.0-16-generic 4.13.0-16.19
  ProcVersionSignature: User Name 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  AlsaDevices:
-  total 0
-  crw-rw 1 root audio 116,  1 Oct 31 22:09 seq
-  crw-rw 1 root audio 116, 33 Oct 31 22:09 timer
+  total 0
+  crw-rw 1 root audio 116,  1 Oct 31 22:09 seq
+  crw-rw 1 root audio 116, 33 Oct 31 22:09 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.7-0ubuntu3.1
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  CRDA: N/A
  Date: Wed Nov  1 01:39:01 2017
  Ec2AMI: ami-030b
  Ec2AMIManifest: FIXME
  Ec2AvailabilityZone: nova
  Ec2InstanceType: m1.small
  Ec2Kernel: unavailable
  Ec2Ramdisk: unavailable
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb:
-  Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd 
-  Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
+  Bus 001 Device 002: ID 0627:0001 Adomax Technol

[Group.of.nepali.translators] [Bug 1749222] Re: apport-collect requires python2

[Scott Moser]

Based on Brian's comment, marking wont-fix.

Not the end of the world, just less than ideal.


** Changed in: apport (Ubuntu Xenial)
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1749222

Title:
  apport-collect requires python2

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Xenial:
  Won't Fix

Bug description:
  I'm booted into a 16.04 maas rescue environment.

  $ apport-collect
  You need to run 'sudo apt-get install python-apport' for apport-collect to 
work.

  running the provided command will get me a python2 stack.
  python3-apport is already installed.

  python3 should be used.

  I then tried a stock bionic container, and run the same.  The message
  changes to suggest python3-apport.

  root@b1:~# apport-collect
  You need to run 'sudo apt-get install python3-apport' for apport-collect to 
work.

  That seems better.  However, python3-apport is already installed.
  # sudo apt-get install python3-apport
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  python3-apport is already the newest version (2.20.8-0ubuntu8).

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: apport 2.20.1-0ubuntu2.15
  ProcVersionSignature: User Name 4.13.0-32.35~16.04.1-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.15
  Architecture: amd64
  Date: Tue Feb 13 15:38:43 2018
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

  Related bugs:
   * bug 1748621: apport-collect won't work (bionic)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1749222/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1752711] Re: cloud-init no longer processes user data on GCE in artful

[Scott Moser]

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => High

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => High

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Bionic)
   Importance: High
   Status: Confirmed

** Also affects: cloud-init (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Artful)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Critical

** Changed in: cloud-init (Ubuntu Artful)
   Importance: Undecided => Critical

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1752711

Title:
  cloud-init no longer processes user data on GCE in artful

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Artful:
  Confirmed
Status in cloud-init source package in Bionic:
  Confirmed

Bug description:
  If I pass in user data like so:

  $ cat cfg
  #!/bin/sh
  touch /tmp/foobar

  $ gcloud compute instances create aa-$(date +%y%m%d-%H%M) --image-family 
ubuntu-1710 --image-project ubuntu-os-cloud-devel --metadata-from-file 
user-data=cfg
  ...

  Then in the instance:

  $ ls /tmp/foobar
  $ sudo cat /var/lib/cloud/instance/user-data.txt
  $ curl 
"http://metadata.google.internal/computeMetadata/v1/instance/attributes/user-data";
 -H "Metadata-Flavor: Google"
  #/bin/sh
  touch /tmp/foobar

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1752711/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1628289] Re: snapd should depend on squashfuse (for use in containers)

[Scott Moser]

** Also affects: snap (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: snap (Ubuntu)
   Status: New => Confirmed

** Changed in: snap (Ubuntu)
   Importance: Undecided => Medium

** Changed in: snap (Ubuntu)
   Status: Confirmed => Fix Committed

** Changed in: snap (Ubuntu)
   Status: Fix Committed => Confirmed

** Changed in: snap (Ubuntu)
   Status: Confirmed => Triaged

** Changed in: squashfuse (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1628289

Title:
  snapd should depend on squashfuse (for use in containers)

Status in Snappy:
  In Progress
Status in snap package in Ubuntu:
  Triaged
Status in squashfuse package in Ubuntu:
  Fix Released
Status in squashfuse source package in Xenial:
  Fix Released

Bug description:
  We're finally making progress on the apparmor stacking and snapd in
  container front. The next LXD release will include the needed support
  as will the kernel soon afterwards.

  With that, one can finally get snaps to install inside containers, but
  for any of it to work, squashfuse must be present in the container so
  that snapd can use it to mount the filesystem.

  squashfuse is in the archive and I've contributed support to snapd a
  while back, so all that should be needed is for the snapd package to
  be updated to depend or at least recommend squashfuse.

To manage notifications about this bug go to:
https://bugs.launchpad.net/snappy/+bug/1628289/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1628289] Re: snapd should depend on squashfuse (for use in containers)

[Scott Moser]

** Also affects: snapd (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: snapd (Ubuntu)
   Status: New => Confirmed

** Changed in: snapd (Ubuntu)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1628289

Title:
  snapd should depend on squashfuse (for use in containers)

Status in Snappy:
  In Progress
Status in snapd package in Ubuntu:
  Confirmed
Status in squashfuse package in Ubuntu:
  Fix Released
Status in squashfuse source package in Xenial:
  Fix Released

Bug description:
  We're finally making progress on the apparmor stacking and snapd in
  container front. The next LXD release will include the needed support
  as will the kernel soon afterwards.

  With that, one can finally get snaps to install inside containers, but
  for any of it to work, squashfuse must be present in the container so
  that snapd can use it to mount the filesystem.

  squashfuse is in the archive and I've contributed support to snapd a
  while back, so all that should be needed is for the snapd package to
  be updated to depend or at least recommend squashfuse.

To manage notifications about this bug go to:
https://bugs.launchpad.net/snappy/+bug/1628289/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1750770] Re: installing cloud init in vmware breaks ubuntu user

[Scott Moser]

I suspect this is 16.04 only.
in 18.04, ds-identify should disable cloud-init correctly.
in 16.04 its still set to reporting only mode. and in the log it shows that the 
list got set to Ec2 (maybe).  

I'm not sure what you were expectin though, whether you thouht cloud-
init should get some vmware data from somewhere.


** Changed in: cloud-init
   Status: New => Incomplete

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1750770

Title:
  installing cloud init in vmware breaks ubuntu user

Status in cloud-init:
  Incomplete
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  New

Bug description:
  When installing cloud-init in vmware without any setup for user/vendor
  data it breaks the ubuntu user.

  Steps to reproduce:
  1. take vmwre (free 30 days is fine)
  2. install xenial (maybe newer as well but my case was xenial)
  3. set up your user to be ubuntu/ubuntu (through the vmware fast installer)
  # you now have a working system
  # no user/vendor data provider was set up (unless vmware did some internally)
  4. install cloud-init
  5. reboot
  # on reboot I see the cloud init vmware data gatherer timing out (fine as 
expected)
  # But after that I can't login anymore, so it seems it changed the user

  This came up in debugging another issue - so there is a chance I
  messed the service dependencies up enough to trigger this :-/ (we need
  to check that)

  Sorry, this sucks at getting logs and since I can't login anymore ...
  I'll have to setup a new system with a second user to use to take a look.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1750770/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1735821] Re: netplan needs bridge port-priority support

[Scott Moser]

** Changed in: nplan (Ubuntu)
   Importance: Undecided => Medium

** Changed in: nplan (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: nplan (Ubuntu Artful)
   Importance: Undecided => Medium

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1735821

Title:
  netplan needs bridge port-priority support

Status in cloud-init:
  Confirmed
Status in nplan package in Ubuntu:
  Fix Released
Status in nplan source package in Xenial:
  Fix Committed
Status in nplan source package in Artful:
  Fix Committed

Bug description:
  [Impact]
  Users of netplan configuring any bridge. Port priority is a very common 
setting to change when setting up bridge devices that might have multiple 
interfaces.

  [Test case]
  1) Write a netplan configuration:
  network:
  version: 2
  ethernets:
  eth0:
  match:
  name: eth0
  bridges:
  br0:
  addresses:
  - 192.168.14.2/24
  interfaces:
  - eth0
  parameters:
  path-cost:
  eth0: 50
  priority: 22
  port-priority:
  eth0: 14

  2) Run 'sudo netplan apply'

  3) Validate that the config generated by netplan is correct:

  In /run/systemd/network/10-netplan-eth0.network:

  [...]
  [Bridge]
  [...]
  Priority=14

  4) Validate that the port-priority value for the bridge has been
  correctly set:

  $ cat /sys/class/net/mybr/brif/eth0/priority


  [Regression potential]
  This might impact STP behavior, such that while the port priority for a 
bridge changes, the general network topology might change -- this may lead to 
loss of connectivity on the bridge itself or on other devices on the network, 
invalid packet traffic (packets showing up where they should not), etc.

  ---

  Now that systemd supports port-priority for bridges (LP: #1668347)
  netplan should handle port-priority like it does path-cost.

  1) % lsb_release -rd
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04

  1) # lsb_release -rd
  Description:  Ubuntu Bionic Beaver (development branch)
  Release:  18.04

  2) # apt-cache policy nplan
  nplan:
    Installed: 0.30
    Candidate: 0.32
    Version table:
   0.32 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
   *** 0.30 100
  100 /var/lib/dpkg/status

  3) netplan generate renders a networkd .network file which has
  [Bridge] section including  Priority  value set on each of the bridge
  ports specified

  4) netplan fails to parse the input yaml with

  Sample config that should parse:

  % cat br-pp.yaml
  network:
  version: 2
  ethernets:
  eth0:
  match:
  macaddress: '52:54:00:12:34:04'
  bridges:
  br0:
  addresses:
  - 192.168.14.2/24
  interfaces:
  - eth0
  parameters:
  path-cost:
  eth0: 50
  priority: 22
  port-priority:
  eth0: 14

  % netplan generate
  Error in network definition br-pp.yaml line 13 column 16: unknown key 
port-priority

  If fixed, then I would expect a /run/systemd/network/10-netplan-eth0.network 
that looks like
  [Match]
  MACAddress=52:54:00:12:34:00
  Name=eth0

  [Network]
  Bridge=br0
  LinkLocalAddressing=no
  IPv6AcceptRA=no

  [Bridge]
  Cost=50
  Priority=14

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1735821/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1570997] Re: fail if HOME environment variable is not set

[Scott Moser]

** Also affects: ssh-import-id (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1570997

Title:
  fail if HOME environment variable is not set

Status in ssh-import-id:
  Fix Committed
Status in ssh-import-id package in Ubuntu:
  Fix Released
Status in ssh-import-id source package in Xenial:
  New

Bug description:
  === Begin SRU Template ===
  [Impact] 
  Running ssh-import-id without environment variable HOME set
  will fail and print an error message like:

   TypeError: join() argument must be str or bytes, not 'NoneType'

  [Test Case]
  $ name="my-x"
  $ ud=$(printf '%s\n%s\n' '#!/bin/sh' 'ssh-import-id smoser')
  $ lxc launch ubuntu-daily:xenial "$name" "--config=user.user-data=$ud"

  To see failure, you can then just:
  $ lxc exec "$name" -- cat /run/cloud-init/result.json
  {
   "v1": {
"datasource": "DataSourceHetzner",
"errors": [
 "('scripts-user', RuntimeError('Runparts: 1 failures in 1 attempted 
commands',))"
]
   }
  }

  $ lxc exec "$name" -- grep "ssh-import-id smoser" /root/.ssh/authorized_keys 
&&
  echo GOOD || echo FAIL

  [Regression Potential] 
  Regression is unlikely.  The code only does anything if HOME is not present.
  This has been in Artful and Bionic since 2016-09-16.

  [Other Info]
  Upstream merge proposal:
   
https://code.launchpad.net/~smoser/ssh-import-id/trunk.lp1570997/+merge/326692

  === End SRU Template ===

  I've modified /usr/bin/ssh-import-id to show a stack trace rather than 
unhelpful message:
   TypeError: join() argument must be str or bytes, not 'NoneType'

  Then, running:
  $ env -u HOME ssh-import-id smoser
  Traceback (most recent call last):
    File "/usr/bin/ssh-import-id", line 62, in 
  main()
    File "/usr/bin/ssh-import-id", line 45, in main
  k = import_keys(proto, username, parser.options.useragent)
    File "/usr/lib/python3/dist-packages/ssh_import_id/__init__.py", line 204, 
in import_keys
  local_keys = key_list(read_keyfile())
    File "/usr/lib/python3/dist-packages/ssh_import_id/__init__.py", line 135, 
in read_keyfile
  output_file = parser.options.output or os.path.join(os.getenv("HOME"), 
".ssh", "authorized_keys")
    File "/usr/lib/python3.5/posixpath.py", line 89, in join
  genericpath._check_arg_types('join', a, *p)
    File "/usr/lib/python3.5/genericpath.py", line 143, in _check_arg_types
  (funcname, s.__class__.__name__)) from None
  TypeError: join() argument must be str or bytes, not 'NoneType'

  I came to find this by trying to  launch an instance with:

  $ ec2metadata --user-data
  #!/bin/sh
  exec >/my.log 2>&1
  cat /proc/uptime
  date -R
  ssh-import-id smoser

  The basic issue is that the environment that cloud-init runs in does
  not have HOME set.

  I suggest using os.path.expanduser
  def authorized_key_file():
  return os.path.join(os.path.expanduser("~"), ".ssh", 
"authorized_keys")

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ssh-import-id 5.5-0ubuntu1 [modified: usr/bin/ssh-import-id]
  ProcVersionSignature: User Name 4.4.0-18.34-generic 4.4.6
  Uname: Linux 4.4.0-18-generic x86_64
  ApportVersion: 2.20.1-0ubuntu1
  Architecture: amd64
  Date: Fri Apr 15 17:36:09 2016
  Ec2AMI: ami-929f8cf8
  Ec2AMIManifest: 
ubuntu-us-east-1/images-testing/hvm-instance/ubuntu-xenial-daily-amd64-server-20160412.manifest.xml
  Ec2AvailabilityZone: us-east-1c
  Ec2InstanceType: m3.medium
  Ec2Kernel: unavailable
  Ec2Ramdisk: unavailable
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: ssh-import-id
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ssh-import-id/+bug/1570997/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1746348] Re: support installation of fsimage via copy

[Scott Moser]

This bug is believed to be fixed in curtin in 18.1. If this is still a
problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: curtin
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1746348

Title:
  support installation of fsimage via copy

Status in curtin:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  Confirmed
Status in curtin source package in Artful:
  Confirmed

Bug description:
  Since maas v3 streams makes available only an squashfs image, we do not
  currently have a way to install that without first booting it.  It would
  be nice to have support in curtin to
   a.) download image (if a url)
   b.) mount the image
   c.) copy contents to target

  Related bugs:
   * bug 1739761: maas 2.3 fails to install precise.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1746348/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1553815] Re: host keys never restored following metadata api outage

[Scott Moser]

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu Trusty)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Wily)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Wily)
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1553815

Title:
  host keys never restored following metadata api outage

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Trusty:
  Confirmed
Status in cloud-init source package in Wily:
  Won't Fix
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  We are running an Openstack cloud and have noticed some unexpected
  behaviour in our Ubuntu Trusty cloud instances created by Nova.

  We have observed that if a previously initialised instance (e.g.
  DataSourceOpenstack has already been run) is rebooted while the
  metadata api is not available (i.e. 169.254.169.264 is unreachable),
  cloud-init will retry a few times then switch to DataSourceNone and
  regenerate host keys.

  # Boot instance under normal conditions
  ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance
  /var/lib/cloud/instances/cd535bc4-9c2f-4d31-8903-0ede59c7ef95
  ubuntu@vm1:~$ grep "Generating public/private rsa key pair." 
/var/log/cloud-init-output.log 
  Generating public/private rsa key pair.

  # Stop neutron metadata api service and reboot instance (observing that 
host keys were regenerated)
  ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance
  /var/lib/cloud/instances/iid-datasource-none
  ubuntu@vm1:~$ grep "Generating public/private rsa key pair." 
/var/log/cloud-init-output.log 
  Generating public/private rsa key pair.
  Generating public/private rsa key pair.

  So far so good since we expect this behaviour, but now we reboot this 
instance with the metadata api is once again reachable. Cloud-init rightly 
selects the original DataSourceOpenstack instance but it does nothing since it 
already ran once (and it is set to only run once). The problem here is that the 
original host keys are never 
  restored so any client connecting to that instance will have no option to 
accept the new host keys along with MITM attack warning.

  ubuntu@vm1:~$ sudo reboot
  ...
  ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance
  /var/lib/cloud/instances/cd535bc4-9c2f-4d31-8903-0ede59c7ef95

  Surely we could find a way for cloud-init to know that if if the
  current DataSourceOpenstack uuid matches its previously run uuid, then
  it can check that the host keys are consistent with the original run.
  @smoser suggested in a side discussion that dmidecode info could
  perhaps be used since the Openstack instance uuid can be found there:

  ubuntu@vm1:~$ sudo dmidecode -t system
  # dmidecode 2.12
  SMBIOS 2.8 present.

  Handle 0x0100, DMI type 1, 27 bytes
  System Information
Manufacturer: OpenStack Foundation
Product Name: OpenStack Nova
Version: 13.0.0
Serial Number: ba5f7371-fd4c-a25e-132f-3dd1e5b92e93
UUID: CD535BC4-9C2F-4D31-8903-0EDE59C7EF95
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Virtual Machine

  Handle 0x2000, DMI type 32, 11 bytes
  System Boot Information
Status: No errors detected

  If cloud-init kept a copy of previous host keys prior to regenerating
  them, it could presumably use this info to know when to safely restore
  the original host keys.

  Since it is not inconceivable for the metadata api to become
  unreachable for a brief period (perhpas during an upgrade), i think we
  really need to make cloud-init more tolerant of this circumstance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1553815/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1449318] Re: power_state does not take effect when runcmd errors

[Scott Moser]

This is fixed in trunk at revno 1157.

** Changed in: cloud-init
   Status: Confirmed => Fix Committed

** Changed in: cloud-init
 Assignee: (unassigned) => Scott Moser (smoser)

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Wily)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu Wily)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu Wily)
   Status: Fix Released => Won't Fix

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => High

** Changed in: cloud-init (Ubuntu Wily)
   Importance: Undecided => Low

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1449318

Title:
  power_state does not take effect when runcmd errors

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Wily:
  Won't Fix
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  When the runcmd errors the power-state-change does not take effect and
  the instance is not powered off.

  
  AMI ID: ubuntu-vivid-15.04-amd64-server-20150422 (ami-2d10241d)

  Instance launched on EC2 using awscli:

  $ aws --region us-west-2 ec2 run-instances --image-id ami-2d10241d
  --instance-type t2.medium --security-groups ssh-http-https --user-data
  file://fail.cfg

  Minimal fail.cfg cloud config:
  ```
  #cloud-config
  power_state:
mode: poweroff

  runcmd:
  - set -e
  - python3 -c "raise Exception"
  ```

  Longer fail.cfg used for retrieving logs:
  ```
  #cloud-config
  output:
all: '| tee -a /var/log/cloud-init-output.log'

  power_state:
mode: poweroff

  bootcmd:
  - cloud-init-per once ssh-users-ca echo "TrustedUserCAKeys 
/etc/ssh/users_ca.pub" >> /etc/ssh/sshd_config

  runcmd:
  - set -e
  - python3 -c "raise Exception"

  write_files:
  - path: /etc/ssh/users_ca.pub
content: 
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1449318/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1595302] [NEW] xenial cloud-init update

[Scott Moser]

Public bug reported:

There are several fixes in the current yaketty version of cloud-init
that need to make it back to 16.04.  These are both bug fixes and more
general improvements in code.

This bug is a 'SRU metabug' to cover that SRU.  Below is a changelog
format with individual bugs listed.  The uploaded version will have the
bug references removed, but I will mark bugs individually as fix-
released and reference this bug.

  * debian/new-upstream-snapshot: minor change supporting revision
passed in as an argument.
  * New upstream snapshot.
- user_data: fix error when user-data is not utf-8 decodable (LP: #1532072)
- write_files: if no permissions are provided, use the default without
  logging a warning.
- do not write /etc/systemd/network/50-cloud-init-*.link files
  (LP: #1594546)
- fix several potential errors identified by pylint.
- move 'main' into cloudinit/cmd/ for easier testing
- Remove trailing dot from GCE metadata URL (LP: #1581200) [Phil Roche]
- Refactor cloudinit networking module to improve testing
- Change missing Cheetah log warning to debug [Andrew Jorgensen]
- network configuration improvements
  - centrally handle 'dsmode' (DataSource mode) to be 'local' or 'net.
  - support networking information being read on dreamcompute
  - support reading and applying networking information on SmartOS
  - improve reading networking from openstack network_data.json
  - support for renaming devices in a container (LP: #1579130).
  - remove blocking of udev rules (LP: #1577844, LP: #1571761)
- Apt sources configuration improvements (LP: #1574113)
- cloud-config specified on kernel command line will now override
  system settings (LP: #1582323).
- fix timestamp in reporting events.
- Paths: fix instance path if datasource's id has a '/'. (LP: #1575938)
- Config Drive: fix check_instance_id signature. (LP: #1575055)
- cloudstack: Only use DHCPv4 lease files as a datasource (LP: #1576273)

** Affects: cloud-init (Ubuntu)
 Importance: Medium
 Status: Fix Released

** Affects: cloud-init (Ubuntu Xenial)
 Importance: High
 Status: In Progress

** Affects: cloud-init (Ubuntu Yakkety)
 Importance: Medium
 Status: Fix Released

** Changed in: cloud-init
   Status: New => Fix Released

** Changed in: cloud-init
   Importance: Undecided => High

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** No longer affects: cloud-init

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1595302

Title:
  xenial cloud-init update

Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  In Progress
Status in cloud-init source package in Yakkety:
  Fix Released

Bug description:
  There are several fixes in the current yaketty version of cloud-init
  that need to make it back to 16.04.  These are both bug fixes and more
  general improvements in code.

  This bug is a 'SRU metabug' to cover that SRU.  Below is a changelog
  format with individual bugs listed.  The uploaded version will have
  the bug references removed, but I will mark bugs individually as fix-
  released and reference this bug.

* debian/new-upstream-snapshot: minor change supporting revision
  passed in as an argument.
* New upstream snapshot.
  - user_data: fix error when user-data is not utf-8 decodable (LP: 
#1532072)
  - write_files: if no permissions are provided, use the default without
logging a warning.
  - do not write /etc/systemd/network/50-cloud-init-*.link files
(LP: #1594546)
  - fix several potential errors identified by pylint.
  - move 'main' into cloudinit/cmd/ for easier testing
  - Remove trailing dot from GCE metadata URL (LP: #1581200) [Phil Roche]
  - Refactor cloudinit networking module to improve testing
  - Change missing Cheetah log warning to debug [Andrew Jorgensen]
  - network configuration improvements
- centrally handle 'dsmode' (DataSource mode) to be 'local' or 'net.
- support networking information being read on dreamcompute
- support reading and applying networking information on SmartOS
- improve reading networking from openstack network_data.json
- support for r

[Group.of.nepali.translators] [Bug 1579130] Re: need to support renaming of devices in container and on first boot

[Scott Moser]

Hello,
An SRU upload of cloud-init for 16.04 that contains a fix for this bug has been 
made under bug 1595302.  Please track that bug if you are interested.

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => In Progress

** No longer affects: systemd (Ubuntu Xenial)

** Changed in: cloud-init (Ubuntu)
 Assignee: (unassigned) => Scott Moser (smoser)

** Changed in: cloud-init (Ubuntu Xenial)
 Assignee: (unassigned) => Scott Moser (smoser)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1579130

Title:
  need to support renaming of devices in container and on first boot

Status in cloud-init package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Triaged
Status in cloud-init source package in Xenial:
  In Progress

Bug description:
  We're interested in supporting network configuration of cloud
  instances including lxc containers via maas/cloud-init yaml format.

  For Containers, the end goal is to do:
  $ lxc init xenial x1
  $ ncpath=/var/lib/cloud/seed/nocloud-net/network-config
  $ sudo tee /var/lib/lxd/containers/x1/rootfs/$ncpath < 
into 'eth0').
   That is implemented by check of 
/sys/devices/virtual/net/eth0/name_assign_type . Value of 4 means renamed.

   c.) systemd.link will not attempt to rename a device that does not have a 
driver.
     To see that run: udevadm test-builtin net_setup_link /sys/class/net/eth0
     http://paste.ubuntu.com/16261974/

   d.) on first boot of a cloud instance, the systemd.link files in the
  initramfs are either pristine or from the previous instance.  The
  devices will leave the initramfs either named incorrectly or named
  with standard persistent naming and will have already been renamed.

  To force these systemd.link files to run in spite of 'b' on kvm guests
  or bare metal, we have found that unbind and rebind of the device will
  clear the state and rename would occur.  that can be done as shown in
  https://bugs.launchpad.net/ubuntu/+source/cloud-
  init/+bug/1577844/comments/3 but since there is no 'driver' we cannot
  unbind and rebind veth devices.

  To do this right, we need to support:
   1.) renaming on first boot with initramfs and with 'stale' initramfs
   2.) renaming in lxc containers
   3.) user updating whatever files or mechanism is used post first boot.  For 
example, if the user wrote a 25-my-rules.link after first boot, a reboot should 
prefer their provided names to whatever were originally there.
   4.) if cloud-init networking is disabled, the renaming should not occur.

  Related Bugs:
   * bug 1594546: no need to write systemd.link files 

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: udev 229-4ubuntu4
  ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
  Uname: Linux 4.4.0-21-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  Date: Fri May  6 15:42:52 2016
  MachineType: LENOVO 33672B7
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-21-generic.efi.signed 
root=UUID=19ac97d5-6973-4193-9a09-2e6bbfa38262 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/18/2013
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G8ET96WW (2.56 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 33672B7
  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: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvrG8ET96WW(2.56):bd12/18/2013:svnLENOVO:pn33672B7:pvrThinkPadX131e:rvnLENOVO:rn33672B7:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.name: 33672B7
  dmi.product.version: ThinkPad X131e
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1579130/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1577844] Re: Drop unnecessary blocking of all net udev rules

[Scott Moser]

Hello,
An SRU upload of cloud-init for 16.04 that contains a fix for this bug has been 
made under bug 1595302.  Please track that bug if you are interested.

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: cloud-init (Ubuntu Xenial)
 Assignee: (unassigned) => Scott Moser (smoser)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1577844

Title:
  Drop unnecessary blocking of all net udev rules

Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  In Progress

Bug description:
  cloud-inits networking setup currently jumps through a lot of bad
  hoops to make sure that ifup@ does not run until after cloud-init-
  local.service. This includes blocking udev rules for an indefinite
  time, which is racy, a potential deadlock, and highly non-elegant.

  This is also not necessary: while ifupdown's net udev rule certainly
  can fire before cloud-init-local, it only asynchronously starts
  ifup@.service which will be deferred until after network-pre.target
  and thus after cloud-init-local.service.

  ---
  Original description, which turned out to be completely false and just us 
being misled:

  ifup@.service can (and often does) run for a particular interface
  before networking.service runs. This is brittle as during early boot
  ifup is prone to fail: / might still be read-only, /var might not yet
  exist or be writable, dhclient-enter-hooks.d/ or if-up.d/ hooks might
  silently fail, etc. It is also unnecessary as networking.service will
  bring up all "auto" and all present "allow-hotplug" interfaces anyway,
  and it runs at the right time.

  We should make either 80-ifupdown.rules or ifup@.service ignore events
  until networking.service is active, or wait until after it has run
  (slower, but avoids race conditions when hotplug events happen while
  networking.service is running). Thus we need to add
  After=networking.service to ifup@.service, so that this only does
  stuff after doing the "coldplug" configuration.

  This also affects cloud-init's setup of networking: this currently
  jumps through a lot of bad hoops to make sure that ifup@ does not run
  until after cloud-init-local.service. This includes blocking udev
  rules for an indefinite time, which is racy, a potential deadlock, and
  highly non-elegant.

  https://bugs.debian.org/752919 is related to this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1577844/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1582323] Re: Commissioning fails when competing cloud metadata resides on disk

[Scott Moser]

Hello,
An SRU upload of cloud-init for 16.04 that contains a fix for this bug has been 
made under bug 1595302.  Please track that bug if you are interested.

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: cloud-init (Ubuntu Xenial)
 Assignee: (unassigned) => Scott Moser (smoser)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1582323

Title:
  Commissioning fails when competing cloud metadata resides on disk

Status in cloud-init:
  Fix Committed
Status in MAAS:
  Triaged
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  In Progress

Bug description:
  A customer reused hardware that had previously deployed a RHEL
  Overcloud-controller which places metadata on the disk as a legitimate
  source, that cloud-init looks at by default.  When the newly enlisted
  node appeared it had the name of "overcloud-controller-0" vs. maas-
  enlist, pulled from the disk metadata which had overridden MAAS'
  metadata.  Commissioning continually failed on all of the nodes until
  the disk metadata was manually removed (KVM boot Ubuntu ISO, rm -f
  data or dd zeros to disk).

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1582323/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1575938] Re: Instance path in / if instance-id starts with '/'

[Scott Moser]

Hello,
An SRU upload of cloud-init for 16.04 that contains a fix for this bug has been 
made under bug 1595302.  Please track that bug if you are interested.

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: cloud-init (Ubuntu Xenial)
 Assignee: (unassigned) => Scott Moser (smoser)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1575938

Title:
  Instance path in / if instance-id starts with '/'

Status in cloud-init:
  In Progress
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  In Progress

Bug description:
  A cloud using the Ec2 datasource has an instance-id metadata value in
  the form:

  /Compute-$TENANT/$CLOUDUSERNAME/$UUID

  The leading '/' causes /var/lib/cloud/instance to link to
  /Compute-$TENANT/$CLOUDUSERNAME/$UUID rather than
  /var/lib/cloud/instances/Compute-$TENANT/$CLOUDUSERNAME/$UUID

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1575938/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1571761] Re: zfs-import-cache.service slows boot by 60 seconds

[Scott Moser]

Hello,
An SRU upload of cloud-init for 16.04 that contains a fix for this bug has been 
made under bug 1595302.  Please track that bug if you are interested.

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: zfs-linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Fix Released => In Progress

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: cloud-init (Ubuntu Xenial)
 Assignee: (unassigned) => Scott Moser (smoser)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1571761

Title:
  zfs-import-cache.service slows boot by 60 seconds

Status in cloud-init package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  Confirmed
Status in cloud-init source package in Xenial:
  In Progress
Status in zfs-linux source package in Xenial:
  New

Bug description:
  Fresh uvt-kvm guest, then
  $ sudo apt-get install zfsutils-linux
  $ sudo reboot

  The reboot will show on console waiting for tasks, then after ~ 60 seconds it 
continues boot.
  Logging in shows:

  $ sudo systemd-analyze critical-chain zfs-mount.service
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  zfs-mount.service +81ms
  └─zfs-import-cache.service @1min 786ms +272ms
└─systemd-udev-settle.service @494ms +1min 275ms
  └─systemd-udev-trigger.service @415ms +55ms
└─systemd-udevd-control.socket @260ms
  └─-.mount @124ms
└─system.slice @129ms
  └─-.slice @124ms

  Seems possibly related / or some discussion at
  https://github.com/zfsonlinux/zfs/issues/2368

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: zfsutils-linux 0.6.5.6-0ubuntu8
  ProcVersionSignature: User Name 4.4.0-18.34-generic 4.4.6
  Uname: Linux 4.4.0-18-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu1
  Architecture: amd64
  Date: Mon Apr 18 16:42:35 2016
  ProcEnviron:
   TERM=screen.xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: zfs-linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.sudoers.d.zfs: [deleted]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1571761/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1574113] Re: curtin/maas don't support multiple (derived) archives/repositories with custom keys

[Scott Moser]

Hello,
An SRU upload of cloud-init for 16.04 that contains a fix for this bug has been 
made under bug 1595302.  Please track that bug if you are interested.

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
 Assignee: (unassigned) => Scott Moser (smoser)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1574113

Title:
  curtin/maas don't support multiple (derived) archives/repositories
  with custom keys

Status in cloud-init:
  Fix Committed
Status in curtin:
  Confirmed
Status in MAAS:
  Triaged
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  In Progress

Bug description:
  In a customer environment I have to deploy using offline resources (no
  internet connection at all), so I created apt mirror and MAAS images
  mirror. I configured MAAS  to use the local  mirrors and I'm able to
  commission the nodes but I'm not able to deploy the nodes because
  there is no way to add gpg key of the local repo in target before the
  'late' stage'.

  Using curtin I'm able to add the key but too late, in fact  according
  with http://bazaar.launchpad.net/~curtin-
  dev/curtin/trunk/view/head:/curtin/commands/install.py#L52 "late"
  stage is executed  after "curthooks" this prevent to add the key.

  I checked also apt_config function in curthooks.py  I did't see code
  that add the key for each mirror.

  It should be possible to add gpg public of the repository in maas.

  --
  configs/config-000.cfg
  --

  #cloud-config
  debconf_selections:
   maas: |
    cloud-init   cloud-init/datasources  multiselect MAAS
    cloud-init   cloud-init/maas-metadata-url  string 
http://100.107.231.164/MAAS/metadata/
    cloud-init   cloud-init/maas-metadata-credentials  string 
oauth_token_key=8eZmzQWSSQzsUkaLnE&oauth_token_secret=LKmn8sHgzEXfvzSZePAa9jUXvTMRrFNP&oauth_consumer_key=htwDZJFtmv2YvQXhUW
    cloud-init   cloud-init/local-cloud-config  string 
apt_preserve_sources_list: true\nmanage_etc_hosts: false\nmanual_cache_clean: 
true\nreporting:\n  maas: {consumer_key: htwDZJFtmv2YvQXhUW, endpoint: 
'http://100.107.231.164/MAAS/metadata/status/node-61b6987c-07a7-11e6-9d23-5254003d2515',\n
token_key: 8eZmzQWSSQzsUkaLnE, token_secret: 
LKmn8sHgzEXfvzSZePAa9jUXvTMRrFNP,\ntype: webhook}\nsystem_info:\n  
package_mirrors:\n  - arches: [i386, amd64]\nfailsafe: {primary: 
'http://archive.ubuntu.com/ubuntu', security: 
'http://security.ubuntu.com/ubuntu'}\nsearch:\n  primary: 
['http://100.107.231.166/']\n  security: ['http://100.107.231.166/']\n  - 
arches: [default]\nfailsafe: {primary: 
'http://ports.ubuntu.com/ubuntu-ports', security: 
'http://ports.ubuntu.com/ubuntu-ports'}\nsearch:\n  primary: 
['http://ports.ubuntu.com/ubuntu-ports']\n  security: 
['http://ports.ubuntu.com/ubuntu-ports']\n
  late_commands:
    maas: [wget, '--no-proxy', 
'http://100.107.231.164/MAAS/metadata/latest/by-id/node-61b6987c-07a7-11e6-9d23-5254003d2515/',
 '--post-data', 'op=netboot_off', '-O', '/dev/null']
apt_key: ["curtin", "in-target", "--", "sh", "-c", "/usr/bin/wget 
--no-proxy -qO - http://100.107.231.166/magellan.key | apt-key add -"]
  power_state:
    mode: reboot
  apt_mirrors:
    ubuntu_archive: http://100.107.231.166//
    ubuntu_security: http://100.107.231.166//

  - curtin end of log --
  Leaving 'diversion of /etc/init/ureadahead.conf to 
/etc/init/ureadahead.conf.disabled by cloud-init'
  Setting up swapspace version 1, size = 8388604 KiB
  no label, UUID=e2fe91bc-91e9-4e43-b50f-209dfcf04089
  Get:1 http://100.107.231.166 trusty InRelease [17.7 kB]
  Get:2 http://100.107.231.166 trusty-updates InRelease [17.7 kB]
  Get:3 http://100.107.231.166 trusty-security InRelease [17.7 kB]
  Ign http://100.107.231.166 trusty InRelease
  Get:4 http://100.107.231.166 trusty/main amd64 Packages [412 kB]
  Ign http://100.107.231.166 trusty-updates InRelease
  Ign http://100.107.231.166 trusty-security InRelease
  Get:5 http://100.107.231.166 trusty/restricted amd64 Packages [20 B]
  Get:6 http://100.107.231.166 trusty/universe amd64 Packages [20 B]
  Get:7 http://100.107.231.166 trusty/multiverse amd64 Packages [20 B]
  Get:8 http://100.107.231.166 trusty-updates/main amd64 Packages [33.0 kB

[Group.of.nepali.translators] [Bug 1571068] Re: libvirtError: cannot unlink file '/var/lib/libvirt/images/xxx.qcow2': Success

[Scott Moser]

in the bugzilla bug this is marked as fixed in 1.3.3 of libvirt, and
yakkety currently has 1.3.4, so I've marked fix-released in Ubuntu
(yakkety), and targetted xenial and wily for SRU.


** Also affects: libvirt (Ubuntu Wily)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: libvirt (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: libvirt (Ubuntu Wily)
   Status: New => Confirmed

** Changed in: libvirt (Ubuntu Wily)
   Importance: Undecided => Medium

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: libvirt (Ubuntu Xenial)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1571068

Title:
  libvirtError: cannot unlink file '/var/lib/libvirt/images/xxx.qcow2':
  Success

Status in libvirt:
  Unknown
Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Wily:
  Confirmed
Status in libvirt source package in Xenial:
  Confirmed

Bug description:
  Steps to reproduce:

  1) Create VM using virt-install
  2) Delete the VM with its associated volume

  Expected results:

  The VM is removed and the volume is deleted

  Actual results:

  When trying to remove the volume the following error is printed:

  Errors encountered while removing certain storage devices.

  cannot unlink file '/var/lib/libvirt/images/bootstrap.qcow2': Success
  Traceback (most recent call last):
    File "/usr/share/virt-manager/virtManager/delete.py", line 182, in 
_async_delete
  self._async_delete_path(conn, path, meter)
    File "/usr/share/virt-manager/virtManager/delete.py", line 228, in 
_async_delete_path
  vol.delete(0)
    File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3359, in delete
  if ret == -1: raise libvirtError ('virStorageVolDelete() failed', 
vol=self)
  libvirtError: cannot unlink file '/var/lib/libvirt/images/xxx.qcow2': Success

  And the volume is still there
  $ sudo virsh vol-list default
   Name Path
  --
   bootstrap.qcow2  /var/lib/libvirt/images/bootstrap.qcow2
  $ sudo file /var/lib/libvirt/images/bootstrap.qcow2
  /var/lib/libvirt/images/bootstrap.qcow2: QEMU QCOW Image (v3), 21474836480 
bytes

  Other info:

  I found an upstream bug that is related to this problem
  https://bugzilla.redhat.com/show_bug.cgi?id=1293804 , I tested the
  merged patch and it fixed the problem for me.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.10
  Package: libvirt-bin 1.2.16-2ubuntu11.15.10.3
  ProcVersionSignature: Ubuntu 4.2.0-34.39-generic 4.2.8-ckt4
  Uname: Linux 4.2.0-34-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.19.1-0ubuntu5
  Architecture: amd64
  Date: Fri Apr 15 17:05:34 2016
  InstallationDate: Installed on 2014-12-06 (495 days ago)
  InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1)
  SourcePackage: libvirt
  UpgradeStatus: Upgraded to wily on 2016-03-08 (38 days ago)
  modified.conffile..etc.apparmor.d.usr.lib.libvirt.virt.aa.helper: [modified]
  modified.conffile..etc.libvirt.qemu.conf: [inaccessible: [Errno 13] 
Permission denied: '/etc/libvirt/qemu.conf']
  modified.conffile..etc.libvirt.qemu.networks.default.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/qemu/networks/default.xml']
  mtime.conffile..etc.apparmor.d.usr.lib.libvirt.virt.aa.helper: 
2016-03-14T13:22:07.751461

To manage notifications about this bug go to:
https://bugs.launchpad.net/libvirt/+bug/1571068/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1576273] Re: CloudStack datasource fails to find DHCP lease if IPv6 present

[Scott Moser]

Hello,
An SRU upload of cloud-init for 16.04 that contains a fix for this bug has been 
made under bug 1595302. Please track that bug if you are interested.

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Fix Committed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Changed in: cloud-init
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1576273

Title:
  CloudStack datasource fails to find DHCP lease if IPv6 present

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Committed

Bug description:
  The CloudStack data source looks in /var/lib/dhcp for DHCP lease files
  and compares the timestamps.

  If you have a dhclient.leases and dhclient6.leases file present it
  will look in the dhclient6.leases file for a DHCP server to connect
  to.

  The fix for this is rather simple, change a if-statement so that it
  checks if the leases file starts with 'dhclient.'

  if file_name.startswith("dhclient.") and \
 (file_name.endswith(".lease") or file_name.endswith(".leases")):

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1576273/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1597875] Re: Networking issues with the SmartOS datasource under Xenial

[Scott Moser]

Hello,
An SRU upload of cloud-init for 16.04 that contains a fix for this bug has been 
made under bug 1595302. Please track that bug if you are interested.

This should be functioning now for yakkety images and soon for xenial.


** Changed in: cloud-init
   Importance: Undecided => Medium

** Changed in: cloud-init
   Status: New => Fix Released

** Changed in: cloud-init
 Assignee: (unassigned) => Scott Moser (smoser)

** Changed in: cloud-init
   Status: Fix Released => Fix Committed

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu)
 Assignee: (unassigned) => Scott Moser (smoser)

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Fix Committed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
 Assignee: (unassigned) => Scott Moser (smoser)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1597875

Title:
  Networking issues with the SmartOS datasource under Xenial

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Committed

Bug description:
  Under xenial (16.04) on a VM with more than one IP/interface cloud-
  init fails to setup additional IPS. So for instance if I provision and
  VM with two IPs, cloud-init only sets up one IP (which is typcially
  the main/public IP). I believe the underlying issue has to do with
  changes in systemd and how interfaces are now named in the new world.
  Specifically, you can no longer assume "eth" prefixed interface names.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1597875/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1596690] Re: restoring from datasource without dsmode causes stacktrace

[Scott Moser]

fixed in trunk at revno 1246

** Changed in: cloud-init
   Importance: Undecided => High

** Changed in: cloud-init
   Status: New => Fix Committed

** Changed in: cloud-init
 Assignee: (unassigned) => Scott Moser (smoser)

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => High

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Fix Committed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
 Assignee: (unassigned) => Scott Moser (smoser)

** Changed in: cloud-init (Ubuntu)
 Assignee: (unassigned) => Scott Moser (smoser)

** Tags removed: verification-needed
** Tags added: verification-done

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1596690

Title:
  restoring from datasource without dsmode causes stacktrace

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  On reboot, if cloud-init found a cached /var/lib/cloud/instance/obj.pkl it 
would restore from it.
  If that class did not have a 'dsmode', then main would stack trace like:
  | "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 530, in 
status_wrapper
  | ret = functor(name, args)
  |   File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 247, in 
main_init
  | if mode == sources.DSMODE_NETWORK and init.datasource.dsmode != mode:
  | AttributeError: 'DataSourceAzureNet' object has no attribute 'dsmode'

  This would affect upgrade and reboot on any datasource that did not
  have a dsmode previously.

  That list is
cloudinit/sources/DataSourceAzure.py
cloudinit/sources/DataSourceBigstep.py
cloudinit/sources/DataSourceCloudStack.py
cloudinit/sources/DataSourceDigitalOcean.py
cloudinit/sources/DataSourceEc2.py
cloudinit/sources/DataSourceGCE.py
cloudinit/sources/DataSourceMAAS.py
cloudinit/sources/DataSourceNone.py
cloudinit/sources/DataSourceOVF.py
cloudinit/sources/DataSourceSmartOS.py

  The non-broken datasources then were the ones that previously had a dsmode:
cloudinit/sources/DataSourceAltCloud.py
cloudinit/sources/DataSourceCloudSigma.py
cloudinit/sources/DataSourceConfigDrive.py
cloudinit/sources/DataSourceNoCloud.py
cloudinit/sources/DataSourceOpenNebula.py
cloudinit/sources/DataSourceOpenStack.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1596690/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1577844] Re: Drop unnecessary blocking of all net udev rules

[Scott Moser]

fix is now released to xenial under bug 1595302.  daily cloud-images
with this newer version of cloud-init should appear in the next few
days.  Any image with a serial number *newer* than 20160707 should have
cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .

** Changed in: cloud-init (Ubuntu Xenial)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1577844

Title:
  Drop unnecessary blocking of all net udev rules

Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  cloud-inits networking setup currently jumps through a lot of bad
  hoops to make sure that ifup@ does not run until after cloud-init-
  local.service. This includes blocking udev rules for an indefinite
  time, which is racy, a potential deadlock, and highly non-elegant.

  This is also not necessary: while ifupdown's net udev rule certainly
  can fire before cloud-init-local, it only asynchronously starts
  ifup@.service which will be deferred until after network-pre.target
  and thus after cloud-init-local.service.

  ---
  Original description, which turned out to be completely false and just us 
being misled:

  ifup@.service can (and often does) run for a particular interface
  before networking.service runs. This is brittle as during early boot
  ifup is prone to fail: / might still be read-only, /var might not yet
  exist or be writable, dhclient-enter-hooks.d/ or if-up.d/ hooks might
  silently fail, etc. It is also unnecessary as networking.service will
  bring up all "auto" and all present "allow-hotplug" interfaces anyway,
  and it runs at the right time.

  We should make either 80-ifupdown.rules or ifup@.service ignore events
  until networking.service is active, or wait until after it has run
  (slower, but avoids race conditions when hotplug events happen while
  networking.service is running). Thus we need to add
  After=networking.service to ifup@.service, so that this only does
  stuff after doing the "coldplug" configuration.

  This also affects cloud-init's setup of networking: this currently
  jumps through a lot of bad hoops to make sure that ifup@ does not run
  until after cloud-init-local.service. This includes blocking udev
  rules for an indefinite time, which is racy, a potential deadlock, and
  highly non-elegant.

  https://bugs.debian.org/752919 is related to this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1577844/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1582323] Re: Commissioning fails when competing cloud metadata resides on disk

[Scott Moser]

fix is now released to xenial under bug 1595302.  daily cloud-images
with this newer version of cloud-init should appear in the next few
days.  Any image with a serial number *newer* than 20160707 should have
cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .

** Changed in: cloud-init (Ubuntu Xenial)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1582323

Title:
  Commissioning fails when competing cloud metadata resides on disk

Status in cloud-init:
  Fix Committed
Status in MAAS:
  Triaged
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  A customer reused hardware that had previously deployed a RHEL
  Overcloud-controller which places metadata on the disk as a legitimate
  source, that cloud-init looks at by default.  When the newly enlisted
  node appeared it had the name of "overcloud-controller-0" vs. maas-
  enlist, pulled from the disk metadata which had overridden MAAS'
  metadata.  Commissioning continually failed on all of the nodes until
  the disk metadata was manually removed (KVM boot Ubuntu ISO, rm -f
  data or dd zeros to disk).

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1582323/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1575938] Re: Instance path in / if instance-id starts with '/'

[Scott Moser]

fix is now released to xenial under bug 1595302.  daily cloud-images
with this newer version of cloud-init should appear in the next few
days.  Any image with a serial number *newer* than 20160707 should have
cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .

** Changed in: cloud-init (Ubuntu Xenial)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1575938

Title:
  Instance path in / if instance-id starts with '/'

Status in cloud-init:
  In Progress
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  A cloud using the Ec2 datasource has an instance-id metadata value in
  the form:

  /Compute-$TENANT/$CLOUDUSERNAME/$UUID

  The leading '/' causes /var/lib/cloud/instance to link to
  /Compute-$TENANT/$CLOUDUSERNAME/$UUID rather than
  /var/lib/cloud/instances/Compute-$TENANT/$CLOUDUSERNAME/$UUID

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1575938/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1575055] Re: check_instance_id() error on reboots when using config-drive

[Scott Moser]

fix is now released to xenial under bug 1595302.  daily cloud-images
with this newer version of cloud-init should appear in the next few
days.  Any image with a serial number *newer* than 20160707 should have
cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1575055

Title:
  check_instance_id() error on reboots when using config-drive

Status in cloud-init:
  Fix Committed
Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  Problem Description
  =
  When using a config-drive to provide meta-data to cloud-init on ubuntu (for 
Linux guest running in KVM for z Systems) we get a check_instance_id() error 
whenever we soft reboot after the (successful) initial boot.

  The error shows:

  [5.283203] cloud-init[1637]: Cloud-init v. 0.7.7 running 'init-local' at 
Sat, 23 Apr 2016 00:50:58 +. Up 5.25 seconds.
  [5.283368] cloud-init[1637]: 2016-04-22 20:50:58,839 - util.py[WARNING]: 
failed of stage init-local
  [5.286659] cloud-init[1637]: failed run of stage init-local
  [5.286770] cloud-init[1637]: 

  [5.286849] cloud-init[1637]: Traceback (most recent call last):
  [5.286924] cloud-init[1637]:   File "/usr/bin/cloud-init", line 520, in 
status_wrapper
  [5.286998] cloud-init[1637]: ret = functor(name, args)
  [5.287079] cloud-init[1637]:   File "/usr/bin/cloud-init", line 250, in 
main_init
  [5.287152] cloud-init[1637]: init.fetch(existing=existing)
  [5.287225] cloud-init[1637]:   File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 322, in fetch
  [5.287298] cloud-init[1637]: return 
self._get_data_source(existing=existing)
  [5.287371] cloud-init[1637]:   File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 229, in 
_get_data_source
  [5.287445] cloud-init[1637]: ds.check_instance_id(self.cfg)):
  [5.287518] cloud-init[1637]: TypeError: check_instance_id() takes 1 
positional argument but 2 were given
  [5.287592] cloud-init[1637]: 

  [FAILED] Failed to start Initial cloud-init job (pre-networking).

  
  The failure of the init-local pre-networking does seem to lead to a boot up 
delay as cloud-init tries to search for networking outside of the already saved 
networking data.   

  Otherwise the error is purely cosmetic as later init modules find (or
  let existing IP configuration take over) and bring up the correct
  interfaces.

  The original problem was found outside of openstack with stand-alone
  cloud-config iso images.  But have been able to reproduce the problem
  within an openstack ICM environment.

  Team has had some success getting around the problem by patching the
  check_instance_id function in /usr/lib/python3/dist-
  packages/cloudinit/sources/DataSourceConfigDrive.py so that it
  accepted an extra argument, ex:

  ubuntu@markvercd:~$ sudo cat check_instance_id.patch 
  --- /usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py 
2016-04-06 15:29:59.0 +
  +++ 
/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py.new   
  2016-04-11 22:53:47.799867139 +
  @@ -155,7 +155,7 @@
   
   return True
   
  -def check_instance_id(self):
  +def check_instance_id(self,somecfg):
   # quickly (local check only) if self.instance_id is still valid
   return 
sources.instance_id_matches_system_uuid(self.get_instance_id())
   
  ubuntu@markvercd:~$ 

  ---uname output---
  Linux k6mpathcl.pokprv.stglabs.ibm.com 4.4.0-21-generic #37-Ubuntu SMP Mon 
Apr 18 18:31:26 UTC 2016 s390x s390x s390x GNU/Linux
   
  Machine Type = KVM guest on a z13 (2827-732) LPAR 

  Steps to Reproduce
  =
   1) set up ubuntu guest image with cloud-init
  2) pass in iso image with cloud-config data in cdrom device
  3) boot up successfully with cloud-config data
  4) attempt a soft reboot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1575055/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1576273] Re: CloudStack datasource fails to find DHCP lease if IPv6 present

[Scott Moser]

fix is now released to xenial under bug 1595302.  daily cloud-images
with this newer version of cloud-init should appear in the next few
days.  Any image with a serial number *newer* than 20160707 should have
cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1576273

Title:
  CloudStack datasource fails to find DHCP lease if IPv6 present

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  The CloudStack data source looks in /var/lib/dhcp for DHCP lease files
  and compares the timestamps.

  If you have a dhclient.leases and dhclient6.leases file present it
  will look in the dhclient6.leases file for a DHCP server to connect
  to.

  The fix for this is rather simple, change a if-statement so that it
  checks if the leases file starts with 'dhclient.'

  if file_name.startswith("dhclient.") and \
 (file_name.endswith(".lease") or file_name.endswith(".leases")):

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1576273/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1579130] Re: need to support renaming of devices in container and on first boot

[Scott Moser]

fix is now released to xenial under bug 1595302.  daily cloud-images
with this newer version of cloud-init should appear in the next few
days.  Any image with a serial number *newer* than 20160707 should have
cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .

** Changed in: cloud-init (Ubuntu Xenial)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1579130

Title:
  need to support renaming of devices in container and on first boot

Status in cloud-init package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Triaged
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  We're interested in supporting network configuration of cloud
  instances including lxc containers via maas/cloud-init yaml format.

  For Containers, the end goal is to do:
  $ lxc init xenial x1
  $ ncpath=/var/lib/cloud/seed/nocloud-net/network-config
  $ sudo tee /var/lib/lxd/containers/x1/rootfs/$ncpath < 
into 'eth0').
   That is implemented by check of 
/sys/devices/virtual/net/eth0/name_assign_type . Value of 4 means renamed.

   c.) systemd.link will not attempt to rename a device that does not have a 
driver.
     To see that run: udevadm test-builtin net_setup_link /sys/class/net/eth0
     http://paste.ubuntu.com/16261974/

   d.) on first boot of a cloud instance, the systemd.link files in the
  initramfs are either pristine or from the previous instance.  The
  devices will leave the initramfs either named incorrectly or named
  with standard persistent naming and will have already been renamed.

  To force these systemd.link files to run in spite of 'b' on kvm guests
  or bare metal, we have found that unbind and rebind of the device will
  clear the state and rename would occur.  that can be done as shown in
  https://bugs.launchpad.net/ubuntu/+source/cloud-
  init/+bug/1577844/comments/3 but since there is no 'driver' we cannot
  unbind and rebind veth devices.

  To do this right, we need to support:
   1.) renaming on first boot with initramfs and with 'stale' initramfs
   2.) renaming in lxc containers
   3.) user updating whatever files or mechanism is used post first boot.  For 
example, if the user wrote a 25-my-rules.link after first boot, a reboot should 
prefer their provided names to whatever were originally there.
   4.) if cloud-init networking is disabled, the renaming should not occur.

  Related Bugs:
   * bug 1594546: no need to write systemd.link files 

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: udev 229-4ubuntu4
  ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
  Uname: Linux 4.4.0-21-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  Date: Fri May  6 15:42:52 2016
  MachineType: LENOVO 33672B7
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-21-generic.efi.signed 
root=UUID=19ac97d5-6973-4193-9a09-2e6bbfa38262 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/18/2013
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G8ET96WW (2.56 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 33672B7
  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: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvrG8ET96WW(2.56):bd12/18/2013:svnLENOVO:pn33672B7:pvrThinkPadX131e:rvnLENOVO:rn33672B7:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.name: 33672B7
  dmi.product.version: ThinkPad X131e
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1579130/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1581200] Re: Ubuntu cloud-init expects trailing dot on GCE metadata FQDN

[Scott Moser]

fix is now released to xenial under bug 1595302.  daily cloud-images
with this newer version of cloud-init should appear in the next few
days.  Any image with a serial number *newer* than 20160707 should have
cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu Xenial)
 Assignee: (unassigned) => Scott Moser (smoser)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1581200

Title:
  Ubuntu cloud-init expects trailing dot on GCE metadata FQDN

Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Trusty:
  In Progress
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * If bind9 is installed and configured as a local DNS server on an
  ubuntu instance on GCE then on every reboot cloud-init will fail to
  retrieve instance metadata from GCE due to the lookup hostname not
  resolving.

   * Backporting of this is necessary as instances with bind9 installed
  can no longer take advantage of cloud-init

   * The patch fixes this bug by updating the hostname used in the
  metadata lookup to one that is included in /etc/hosts. As such it will
  resolve, even if bind9 hasn't started yet.

  [Test Case]

  #launch an instance of ubuntu 14.04 on GCE
  sudo apt-get update
  sudo apt-get install -y bind9
  #Add the Google DNS servers as global forwarders and configure bind9 for the 
GCE environment
  cat << EOF | sudo tee /etc/bind/named.conf.options
  options {
  directory "/var/cache/bind";

  forwarders {
  169.254.169.254;
  };  

  recursion yes;
  dnssec-validation no; 
  dnssec-enable no; 
  auth-nxdomain no;
  listen-on { 127.0.0.1; };
};
  EOF  
  sudo service bind9 restart
  #setup your instance to use bind9 instead of the Google server
  echo "supersede domain-name-servers 127.0.0.1;" | sudo tee -a 
/etc/dhcp/dhclient.conf
  sudo dhclient -pf /run/dhclient.eth0.pid -x
  sudo dhclient -1 -v -pf /run/dhclient.eth0.pid -lf 
/var/lib/dhcp/dhclient.eth0.leases eth0
  if grep -q "nameserver 127.0.0.1" "/etc/resolv.conf"; then echo "resolv.conf 
has been updated"; fi
  if host -t A metadata.google.internal | grep '169.254.169.254' > /dev/null; 
then echo "host lookup succeeded as expected"; fi
  sudo service bind9 stop
  if host -t A metadata.google.internal | grep 'connection timed out' > 
/dev/null; then echo "host lookup failed as expected"; fi

  #Now reboot the instance
  sudo reboot
  #Once rebooted run the following
  if grep -q "http://metadata.google.internal./computeMetadata/v1/ is not 
resolvable" "/var/log/cloud-init.log"; then echo "cloud-init failed to lookup 
metadata as expected"; else echo "cloud-init did _not_ fail to lookup metadata 
as expected";  fi

  A patched ubuntu14.04 has been built. To test the patch run the above but 
after reboot run
  #launch a patched instance
  gcloud compute instances create ubuntu1404-patched-cloudinit --image 
daily-ubuntu-proche-cloudinit-1404-trusty-v20160627 --image-project 
ubuntu-os-cloud-devel

  #on a patched instance run the following after reboot
  if grep -q "http://metadata.google.internal/computeMetadata/v1/ is not 
resolvable" "/var/log/cloud-init.log"; then echo "cloud-init failed to retrieve 
metadata"; else echo "cloud-init did successfully retrieve metadata as 
expected";  fi

  [Regression Potential]

   * GCE are questing this change. 
   * The reported issue only affects GCE users and only a small set of those 
users will be using a local DNS server. 
   * The change is a single character change and has been tested and as such 
has limited regression potential. 

  
  [Original Bug Report]

  cloud-init hostname breaks because /etc/hosts does not have the
  trailing dot on metadata FQDN.

  Background:
  On Ubuntu, cloud-init sets the hostname using our metadata service. To do 
this, it hits "metadata.google.internal." (note trailing dot) via HTTP.

  We have entries in /etc/hosts for the metadata service to ensure that
  we can access it at boot time (if DNS is not yet up) as we have other
  init scripts which block bootup when metadata cannot be reached.
  However, these /etc/hosts entries only have "metadata.google.internal"
  (no trailing dot) entries.

  When a customer runs their own bind9 daemon, it starts *after* cloud-
  init, meaning that cloud-init must use /etc/hosts to find the metadata
  service. When it cannot, it incorrectly sets the hostname to
  "$hostname.localdomain" instead of just $hostname.

  Proposed fix:
  U

[Group.of.nepali.translators] [Bug 1532072] Re: cloud-init fails with UnicodeDecodeError

[Scott Moser]

fix is now released to xenial under bug 1595302.  daily cloud-images
with this newer version of cloud-init should appear in the next few
days.  Any image with a serial number *newer* than 20160707 should have
cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1532072

Title:
  cloud-init fails with UnicodeDecodeError

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Fix Released

Bug description:
  I'm running the latest Ubuntu Wily AMI on EC2 (ami-15b7e87f). When the
  instance boots up cloud-init fails with the following exception:

  [   69.519513] cloud-init[901]: 2016-01-08 03:43:00,902 - util.py[WARNING]: 
failed of stage init
  [   69.551842] cloud-init[901]: failed run of stage init
  [   69.552029] cloud-init[901]: 

  [   69.552427] cloud-init[901]: Traceback (most recent call last):
  [   69.552591] cloud-init[901]: File "/usr/bin/cloud-init", line 509, in 
status_wrapper
  [   69.557342] cloud-init[901]: ret = functor(name, args)
  [   69.557524] cloud-init[901]: File "/usr/bin/cloud-init", line 272, in 
main_init
  [   69.557695] cloud-init[901]: init.update()
  [   69.557859] cloud-init[901]: File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 351, in update
  [   69.558020] cloud-init[901]: self._store_userdata()
  [   69.558185] cloud-init[901]: File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 360, in 
_store_userdata
  [   69.558344] cloud-init[901]: processed_ud = self.datasource.get_userdata()
  [   69.558502] cloud-init[901]: File 
"/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 83, in 
get_userdata
  [   69.558660] cloud-init[901]: self.userdata = 
self.ud_proc.process(self.get_userdata_raw())
  [   69.558832] cloud-init[901]: File 
"/usr/lib/python3/dist-packages/cloudinit/user_data.py", line 96, in process
  [   69.560273] cloud-init[901]: self._process_msg(convert_string(blob), 
accumulating_msg)
  [   69.560440] cloud-init[901]: File 
"/usr/lib/python3/dist-packages/cloudinit/user_data.py", line 342, in 
convert_string
  [   69.560603] cloud-init[901]: data = 
util.decode_binary(util.decomp_gzip(raw_data))
  [   69.560764] cloud-init[901]: File 
"/usr/lib/python3/dist-packages/cloudinit/util.py", line 86, in decode_binary
  [   69.560926] cloud-init[901]: return blob.decode(encoding)
  [   69.561094] cloud-init[901]: UnicodeDecodeError: 'utf-8' codec can't 
decode byte 0x8d in position 0: invalid start byte

  I've tracked it down to the following commit:

  https://github.com/number5/cloud-
  init/commit/a7835683afd19f1ae291cc93f008320a7820b24f#diff-
  a543026d533dadf4f39b57d1f65dc1b7R339

  The user-data that is set on our instances is beyond my control.
  Here's a sample of it:

  
b'\x8dV\xd9\x8e\xa3H\x16\xfd\x95\x92_\x9d\x99\xec\x06\xf2\x8d\xc5,\x06\x8c1;\xa3\xd1\x88}3;\x18C\xab\xff\xbd\xa32kT\xea\x87\x1e\r\x0f!\xc5\xb9q\xe3\x9es\xe3@\xf0\xc7!\n\xa7\xd4\xbe\xab\x87\xcfC1\xcf\xfd\'\x04=\xba8|\x14\xdd4\x7f\x9eh\x1a\x86\xa2\xa5|$\x13\x14\xe6i;\x9b\xe9\xf8LG\xe8\xf0v\x98\xe6p\x9c\x97\xde*\x9b\xb4[\x00\x1ewm2\x1d>O0\xfcv\xa8\xd3M\x0b[\x9002\x8f\xbc\x1b\xcb\xb9h\xaea\x93\x82\n\xe6\xd2z\x04L\x83\xfcy\\\xa6\xf9\x1fV\xdd\x14\xd9\x03K\x9at\x0e\xf9p\x0e\x0f\x9f\x7f\x00\x92M\xd4u\x1f\xa0\xf8Tv\xed\xc7\xd4\xa7q\x99\x95\xf1G\x02\xe2\x1f?\t\xcf\x00\x06\xa9\x13\x06\x04|/~\xffb\xfc>\xa6\x8f\x14(|_\xa6\xf7\x14\x81\x88\x0f\x04~\xd7\xf9w0\xc20\x05aT\x96d\x08\x1a\xa1\x08\x89#d\x16#h\x1ag\x08\x15\xa5p\x8a\x00)\xa7\x13uJ\xe2\x08\x8e\x00\x9b_\x0c\xa6\xaf\x0e|de\x0b\x88\xf7c\xd9\xce\xa0\xea\x89BI\x14\xa7\t\xb0%\r#\x08E\xa2
  
!\\\xa7\x8f\xaf.\xa5\x890v\r\xfb\x95\x0f\x16\x03\xe5\xe9\xef\x06\x9a\xf1X\xf6\xf3\x7f`\x10\xf8\x95\xf3E\x9b\x99\xa6\xb4\x89\x1e\x9b\xfa[\xda\xff\xaf\x8a\x8e\x93,\xca\xd2\x88"\xf18\xa2\x93\x98\xa4q\x84HQ\x92"C\x9c\x86\xd18\xc6\x12\x84\xa4\x888\xcc2\x1c\x8dOx\x94\xd11\ng\t\t\xc0\x0cO\xc2\xdfj\xcb\x16\xd0l\xe3\xf4\x1f\x1a>\xfdf\xfd\x9d\xf0\xed\x0f\xe7\xfb\x94@\xf0\xef\xc4\x0e\x7f\xbe\x1d\x96)\xb5\x96\xb6M\x1fB7J\xc0o\x87\xcf\x9f\xfd\xf8;~i\xa6\xff\xc2e\xdevc\xca\xa5\xe3\xfc\xb3z8\xa7\\\x91\xc65\x08g\xe1c\x02\xf1\xf4\x11Ns\x19\xcb\rh\x0b\xd7\xb5Y\x99/\xe3\x17599|\xa2\'\x14\xc1q\n\x98\xedk\xe7[7\xce_
  
\x8a\xbf}y\xfd6v\xaf\xed\x1b\xc5O\x04\x8d\xbd\x1d\xaaf\xfa5\'P\xf2\xcb\xc8\xe6\x0c\xea\x1f>\xffu\xa8@\xd5\xb7\x03\xb4`G\xd2`\xc0#\xff\x1c\xd8\x9f\x03c0R\xe0\xbe\x8a\x18\xbb\xf7\xfe\n\xe6\x8e\x9c\xc9\x18\xc9\xff\x8cW\x15\xc71~\xb7\xf2\xb9\xaf(\xab\xcf\xb2\xccy`\x8a3\xcb\x186\xc3\xca2\x9b<\x8c\xa3\x0f{\xbcBs\xa1\xe3\xd7\x1b\x8f3F\xe7c\xbd\xc9\x

[Group.of.nepali.translators] [Bug 1571761] Re: zfs-import-cache.service slows boot by 60 seconds

[Scott Moser]

fix is now released to xenial under bug 1595302.  daily cloud-images
with this newer version of cloud-init should appear in the next few
days.  Any image with a serial number *newer* than 20160707 should have
cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .

** Changed in: cloud-init (Ubuntu Xenial)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1571761

Title:
  zfs-import-cache.service slows boot by 60 seconds

Status in cloud-init package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  Confirmed
Status in cloud-init source package in Xenial:
  Fix Released
Status in zfs-linux source package in Xenial:
  New

Bug description:
  Fresh uvt-kvm guest, then
  $ sudo apt-get install zfsutils-linux
  $ sudo reboot

  The reboot will show on console waiting for tasks, then after ~ 60 seconds it 
continues boot.
  Logging in shows:

  $ sudo systemd-analyze critical-chain zfs-mount.service
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  zfs-mount.service +81ms
  └─zfs-import-cache.service @1min 786ms +272ms
└─systemd-udev-settle.service @494ms +1min 275ms
  └─systemd-udev-trigger.service @415ms +55ms
└─systemd-udevd-control.socket @260ms
  └─-.mount @124ms
└─system.slice @129ms
  └─-.slice @124ms

  Seems possibly related / or some discussion at
  https://github.com/zfsonlinux/zfs/issues/2368

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: zfsutils-linux 0.6.5.6-0ubuntu8
  ProcVersionSignature: User Name 4.4.0-18.34-generic 4.4.6
  Uname: Linux 4.4.0-18-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu1
  Architecture: amd64
  Date: Mon Apr 18 16:42:35 2016
  ProcEnviron:
   TERM=screen.xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: zfs-linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.sudoers.d.zfs: [deleted]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1571761/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1602373] Re: cloud-init doesn't always land files that one expects

[Scott Moser]

** Changed in: cloud-init
   Importance: Undecided => High

** Changed in: cloud-init
   Status: New => In Progress

** Changed in: cloud-init
 Assignee: (unassigned) => Scott Moser (smoser)

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => High

** Changed in: cloud-init (Ubuntu)
   Status: New => Confirmed

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1602373

Title:
  cloud-init doesn't always land files that one expects

Status in cloud-init:
  In Progress
Status in cloud-init package in Ubuntu:
  Confirmed
Status in cloud-init source package in Xenial:
  Confirmed

Bug description:
  Trove launches instances using the servers.create() API with some
  files. Trove provides a dictionary of files that it wants on the
  instance and most of the time this works. Nova passes them to the
  launched VM as metadata on config drive.

  Sometimes though, it doesn't.

  When injection fails, I see a cloud-init.log that looks like this:

  https://gist.github.com/amrith/7566d8fef4b6e813cca77e5e3b1f1d5a

  When injection succeeds, I see a cloud-init.log that looks like this:

  https://gist.github.com/amrith/50d9e3050d88ec51e13b0a510bd718c3

  Observe that the one that succeeds properly injects three files:

  /etc/injected_files (which is something I added just for debugging)
  /etc/trove/conf.d/... two files here ...

  On a machine where this injection failed:

  root@m10:/tmp/zz/openstack/content# ls -l /etc/trove
  total 4
  drwxr-xr-x 2 amrith root 4096 Jul 12 16:55 conf.d
  root@m10:/tmp/zz/openstack/content# ls -l /etc/trove/conf.d/
  total 4
  root@m10:/tmp/zz/openstack/content#

  Clearly, no files made it over. Yet, the files are definitely there on
  the config drive ...

  I've mounted the config drive.

  root@m10:/tmp/zz/openstack/content# mount | grep zz
  /dev/sr0 on /tmp/zz type iso9660 (ro,relatime)

  root@m10:/tmp/zz/openstack/content# cd /tmp/zz
  root@m10:/tmp/zz# find .
  .
  ./ec2
  ./ec2/2009-04-04
  ./ec2/2009-04-04/meta-data.json
  ./ec2/latest
  ./ec2/latest/meta-data.json
  ./openstack
  ./openstack/2012-08-10
  ./openstack/2012-08-10/meta_data.json
  ./openstack/2013-04-04
  ./openstack/2013-04-04/meta_data.json
  ./openstack/2013-10-17
  ./openstack/2013-10-17/meta_data.json
  ./openstack/2013-10-17/vendor_data.json
  ./openstack/2015-10-15
  ./openstack/2015-10-15/meta_data.json
  ./openstack/2015-10-15/network_data.json
  ./openstack/2015-10-15/vendor_data.json
  ./openstack/2016-06-30
  ./openstack/2016-06-30/meta_data.json
  ./openstack/2016-06-30/network_data.json
  ./openstack/2016-06-30/vendor_data.json
  ./openstack/content
  ./openstack/content/
  ./openstack/content/0001
  ./openstack/content/0002
  ./openstack/latest
  ./openstack/latest/meta_data.json
  ./openstack/latest/network_data.json
  ./openstack/latest/vendor_data.json

  root@m10:/tmp/zz# cd openstack/latest/
  root@m10:/tmp/zz/openstack/latest# cat meta_data.json
  {"files": [{"path": "/etc/injected_files", "content_path": "/content/"}, 
{"path": "/etc/trove/conf.d/guest_info.conf", "content_path": "/content/0001"}, 
{"path": "/etc/trove/conf.d/trove-guestagent.conf", "content_path": 
"/content/0002"}], "admin_pass": "pf2ng7tT8JSt", "random_seed": 
"uSNqQ3udiKspue4y8R8b4gg33Qe6klYYJa8ebvDS0t4i88rq2Owu4yC8TysAfsmsYpno0rbWpWisiTQ3raAOPsx+kGgkrunM9UR5khs/1XRh60tlpKJVIHZnKpLv4PcisLKL2DDoHaaFLV9lPcVtZi3iTqKu6RhcwFyhh+A0mD0xg2G89qACD/RNhWiAuQs4X8le+qgIeoRb3wwg7+4dpujLiqKyx7edDgs9zaEsng21YxO0kv47PiwQf7GoIXObR3xtBYClQQfWQ8a1o35gpDPkPSowqHNKJIxFnIrdFgVHBK5EFTAmwN2JY/GcLwQxLydK02+aalem+bznOpsa1Jl86rNAI9pwltyFYDVz8CGwy46pNYtCOJ2W5WZ+wF4KssE0LkxeWcq7w7CXoFCgz42k13ki0gcHYHw0ieJTMULQT3k65gLwGL2/EsJrZjgil5AaCQhLBLkY2sPhHKYs0k+331QttHHs7PjoX/0as63iNiY62M10givhwyrPDaeYSOAidD0PfRpvVZVcQym/jgKmytV6ZU8DBDwAujGtHjdXK4AovcAvqc96H97arahQr/1SHk8RktyedYjqLC6iYwbSFSHTs+7Fb07MspWKQ2cJLlpmytd/lcZHYAElF/b0VBhR8/eU0dUqdpxjvfGsx8T9/rflMaM5wrDlhad/ikQ=",
 "uuid": "38731f42-611e-465f-b3e4-1e80aa623caf", "availability_zone": "nova", 
"hostname": "m10.novalocal", "launch_index": 0, "devices": [], "project_id": 
"eeec3236ef004821a77ccbd26b81f18f", "name": "m10"}

  root@m10:/tmp/zz/openstack/latest#

  Sure enough, the 

[Group.of.nepali.translators] [Bug 1597699] Re: cc_mcollective.py fails on Ubuntu16.04

[Scott Moser]

** Description changed:

   Begin SRU Template 
  [Impact]
  mcollective usage via cloud-init is not possible.
  
  [Test Case]
  launch instance with cloud-config containing 'mcollective' entry.
  
+ $ cat >user-data <<"EOF"
+ #cloud-config
+ mcollective:
+   conf:
+ main_collective: mcollective
+ collectives: mcollective
+ libdir: /usr/share/mcollective/plugins
+ logfile: /var/log/mcollective.log
+ loglevel: debug
+ daemonize: 1
+ direct_addressing: 1
+ ttl: 4294957
+ securityprovider: psk
+ plugin.psk: unset
+ identity: 2
+ 
+ connector: rabbitmq
+ plugin.rabbitmq.vhost: mcollective
+ plugin.rabbitmq.pool.size: 1
+ plugin.rabbitmq.pool.1.host: 10.10.0.2
+ plugin.rabbitmq.pool.1.port: 61613
+ plugin.rabbitmq.pool.1.user: mcollective
+ plugin.rabbitmq.pool.1.password: ScwpVo8egrZ0OmT6sRmp9zEA
+ plugin.rabbitmq.heartbeat_interval: 30
+ 
+ factsource: yaml
+ plugin.yaml: /etc/mcollective/facts.yaml
+ EOF
+ 
+ $ keyname=brickies; image=$image;
+ $ openstack server create \
+--key-name=$keyname --flavor=m1.small \
+--image=$image --user-data=user-data mcollective-test0
+ 
+ # then ssh in and
+ a.) verifiy mcollective package is installed
+ $ dpkg-query --show mcollective
+ mcollective 2.6.0+dfsg-2.1
+ 
+ b.) verify mcollective service is running
+ $ systemctl status mcollective
+ 
+ c.) grep WARN /var/log/cloud-init.log && echo FAIL
+ 
  [Regression Potential]
  low to none.  This has been unfortunately broken since wily.
  
  [Other Info]
   End SRU Template 
- 
  
  How to reproduce:
  
  #cat /etc/issue.net
  Ubuntu 16.04 LTS
  #( cd /var/lib/cloud/ && rm -rf * )
  #cloud-init -d init
  
  #grep ^mcollective: -A25 instance/user-data.txt
  mcollective:
    conf:
  main_collective: mcollective
  collectives: mcollective
  libdir: /usr/share/mcollective/plugins
  logfile: /var/log/mcollective.log
  loglevel: debug
  daemonize: 1
  direct_addressing: 1
  ttl: 4294957
  securityprovider: psk
  plugin.psk: unset
  identity: 2
  
  connector: rabbitmq
  plugin.rabbitmq.vhost: mcollective
  plugin.rabbitmq.pool.size: 1
  plugin.rabbitmq.pool.1.host: 10.10.0.2
  plugin.rabbitmq.pool.1.port: 61613
  plugin.rabbitmq.pool.1.user: mcollective
  plugin.rabbitmq.pool.1.password: ScwpVo8egrZ0OmT6sRmp9zEA
  plugin.rabbitmq.heartbeat_interval: 30
  
  factsource: yaml
  plugin.yaml: /etc/mcollective/facts.yaml
  
  #cloud-init -d single --name mcollective
  
  The log will contain
  
  Jun 30 08:26:43 node-2 [CLOUDINIT] util.py[DEBUG]: Running module
  mcollective ()
  failed#012Traceback (most recent call last):#012  File "/usr/lib/python3
  /dist-packages/cloudinit/stages.py", line 739, in _run_modules#012
  freq=freq)#012  File "/usr/lib/python3/dist-
  packages/cloudinit/cloud.py", line 70, in run#012return
  self._runners.run(name, functor, args, freq, clear_on_fail)#012  File
  "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 199, in
  run#012results = functor(*args)#012  File "/usr/lib/python3/dist-
  packages/cloudinit/config/cc_mcollective.py", line 83, in handle#012
  mcollective_config.write(contents)#012  File "/usr/lib/python3/dist-
  packages/configobj.py", line 2126, in write#012
  outfile.write(output_bytes)#012TypeError: string argument expected, got
  'bytes'

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => High

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: cloud-init
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1597699

Title:
  cc_mcollective.py fails on Ubuntu16.04

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed

Bug description:
   Begin SRU Template 
  [Impact]
  mcollective usage via cloud-init is not possible.

  [Test Case]
  launch instance with cloud-config containing 'mcollective' entry.

  $ cat >user-data <<"EOF"
  #cloud-config
  mcollective:
conf:
  main_collective: mcollective
  collectives: mcollective
  libdir: /usr/share/mcollective/plugins
  logfile: /var/log/mcollective.log
  loglevel: debug
  daemonize: 1
  direct_addressing: 1
  ttl: 4294957
  securityprovider: psk
  plugin.psk: unset
  identity: 2

  connector: rabbitmq
  plugin.rabbitmq.vhos

[Group.of.nepali.translators] [Bug 1603222] Re: Azure: incorrect entry in fstab for ephemeral disk

[Scott Moser]

I think this is a matter of bug 1411582 actually not having been SRU'd 
correctly.
$ lsb_release -sc
trusty
$ dpkg-query --show cloud-init
cloud-init  0.7.5-0ubuntu1.19
$ dpkg -L cloud-init | grep udev
$ dpkg -L cloud-init | grep udev || echo no files named udev
no files named udev


I also checked that the version that was marked as SRU'd in (0.7.5-0ubuntu1.8) 
does not have any udev files.  So it seems that it just never got in, versus 
having regressed since 0.7.5-0ubuntu1.8.

$ wget 
https://launchpad.net/ubuntu/+archive/primary/+files/cloud-init_0.7.5-0ubuntu1.8_all.deb
$ dpkg -c cloud-init_0.7.5-0ubuntu1.8_all.deb | grep udev || echo no files 
named udev
no files named udev

** Also affects: cloud-init (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: High
   Status: Confirmed

** Also affects: cloud-init (Ubuntu Wily)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: Confirmed => Fix Released

** No longer affects: cloud-init (Ubuntu Yakkety)

** No longer affects: cloud-init (Ubuntu Xenial)

** Changed in: cloud-init (Ubuntu Trusty)
   Importance: Undecided => High

** Changed in: cloud-init (Ubuntu Trusty)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1603222

Title:
  Azure: incorrect entry in fstab for ephemeral disk

Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Precise:
  New
Status in cloud-init source package in Trusty:
  Confirmed
Status in cloud-init source package in Wily:
  New

Bug description:
  During provisioning cloud-init adds an entry for the ephemeral disk in
  /etc/fstab. After provisioning this entry is correct and points to
  "/dev/disk/azure/resource-part1". This symlink is created dynamically
  by 66-azure-storage.rules.

  For some reason after the first reboot cloud-init overwrites the fstab
  entry and changes the "/dev/disk/azure/resource-part1" to the device
  name that it points to, i.e. /dev/sdb1.  However, this is incorrect
  since /dev/sd* device names are not persistent.

  
  Repro:

  1) Provision an Ubuntu VM on Azure (I tested with 14.04.4)
  2) The fstab entry for the ephemeral disk (/mnt) correctly points to 
"/dev/disk/azure/resource-part1".
  3) Reboot the VM (sudo reboot)
  4) The fstab entry now incorrectly points to /dev/sdb1 instead of the symlink.

  Impact:
  There is a chance that the customer's ephemeral disk will not be mounted 
properly if the device names change after a reboot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1603222/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1590104] Re: network config from datasource overrides network config from system

[Scott Moser]

Hi,
This bug was fixed in cloud-init at revision 1228 and was sru'd to xenial under 
bug 1595302, but unfortunately not even marked in that bug. 

So anything newer than 0.7.7~bzr1245-0ubuntu1~16.04.1 in xenial should
have the fix.


** Changed in: cloud-init (Ubuntu Xenial)
   Status: Confirmed => Fix Released

** Changed in: cloud-init
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1590104

Title:
  network config from datasource overrides network config from system

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Fix Released

Bug description:
  network configuration in system config should override that found as provided 
by a datasource.
  The order of precedence should be:
datasource
system config
kernel command line

  When juju creates lxc containers they want to be in control of networking and 
do not want cloud-init to configure networking either from the datasource 
(lxc's template provided nocloud) or from fallback.
  They are specifying that configuration directly in /etc/network/interfaces.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: cloud-init 0.7.7~bzr1212-0ubuntu1
  ProcVersionSignature: Ubuntu 4.4.0-23.41-generic 4.4.10
  Uname: Linux 4.4.0-23-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  Date: Tue Jun  7 18:16:09 2016
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
  SourcePackage: cloud-init
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1590104/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1577982] Re: ConfigDrive: cloud-init fails to configure network from network_data.json

[Scott Moser]

Hi,
This bug was fixed in cloud-init at revision 1225 and was sru'd to xenial under 
bug 1595302, but unfortunately not even marked in that bug.

So anything newer than 0.7.7~bzr1245-0ubuntu1~16.04.1 in xenial should
have the fix.


** Changed in: cloud-init (Ubuntu Xenial)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1577982

Title:
  ConfigDrive: cloud-init fails to configure network from
  network_data.json

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  When running Ubuntu 16.04 on OpenStack, cloud-init fails to properly
  configure the network from network_data.json found in ConfigDrive.

  When instance boots, network is configured fine until next reboot
  where it falls back to dhcp.

  The /etc/network/interfaces.d/50-cloud-init.cfg file has the following
  content when instance is initially booted, this could explain why dhcp
  is used on second boot:

  auto lo
  iface lo inet loopback
  
  auto eth0
  iface eth0 inet dhcp

  When debugging, if this line in stages.py [1] is commented, we can see
  that cloud-init initially copy the /etc/network/interfaces file found
  in the configdrive (the network template injected by Nova) and isn't
  using the network config found in network_data.json. But later it
  falls back to "dhcp" and rewrites yet again the network config.

  I also found that within self._find_networking_config(), it looks like
  no datasource is found at this point. This could be because cloud-init
  is still in "local" dsmode and then refuses to use the network config
  found in the ConfigDrive. (triggering the "dhcp" fallback logic)

  Manually forcing "net" dsmode makes cloud-init configure
  /etc/network/interfaces.d/50-cloud-init.cfg properly with network
  config found in the ConfigDrive. However no gateway is configured and
  so, instance doesn't respond to ping or SSH.

  At that point, I'm not sure what's going on and how I can debug
  further.

  Notes:
  * The image used for testing uses "net.ifnames=0". Removing this config makes 
things much worst. (no ping at all on first boot)
  * Logs, configs and configdrive can be found attached to this bug report.

  [1] http://bazaar.launchpad.net/~cloud-init-dev/cloud-
  init/trunk/view/head:/cloudinit/stages.py#L604

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1577982/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1605956] Re: package missing in 16.04

[Scott Moser]

** Changed in: bzr-fastimport (Ubuntu)
   Status: New => Confirmed

** Changed in: bzr-fastimport (Ubuntu)
   Importance: Undecided => High

** Also affects: bzr-fastimport (Ubuntu Yakkety)
   Importance: High
   Status: Confirmed

** Also affects: bzr-fastimport (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: bzr-fastimport (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: bzr-fastimport (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: bzr-fastimport (Ubuntu Yakkety)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1605956

Title:
  package missing in 16.04

Status in bzr-fastimport package in Ubuntu:
  Fix Released
Status in bzr-fastimport source package in Xenial:
  Confirmed
Status in bzr-fastimport source package in Yakkety:
  Fix Released

Bug description:
  This package does not exist in 16.04.  Trying to install it yields:

  ```
  Package bzr-fastimport is not available, but is referred to by another 
package.
  This may mean that the package is missing, has been obsoleted, or
  is only available from another source
  However the following packages replace it:
python-fastimport

  ```

  But the python-fastimport package doesn't appear relevant to Bazaar
  (and is missing both the fast-import and fast-export commands).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bzr-fastimport/+bug/1605956/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1597699] Re: cc_mcollective.py fails on Ubuntu16.04

[Scott Moser]

This is fixed in cloud-init 0.7.7

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1597699

Title:
  cc_mcollective.py fails on Ubuntu16.04

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
   Begin SRU Template 
  [Impact]
  mcollective usage via cloud-init is not possible.

  [Test Case]
  launch instance with cloud-config containing 'mcollective' entry.

  $ cat >user-data <<"EOF"
  #cloud-config
  mcollective:
    conf:
  main_collective: mcollective
  collectives: mcollective
  libdir: /usr/share/mcollective/plugins
  logfile: /var/log/mcollective.log
  loglevel: debug
  daemonize: 1
  direct_addressing: 1
  ttl: 4294957
  securityprovider: psk
  plugin.psk: unset
  identity: 2

  connector: rabbitmq
  plugin.rabbitmq.vhost: mcollective
  plugin.rabbitmq.pool.size: 1
  plugin.rabbitmq.pool.1.host: 10.10.0.2
  plugin.rabbitmq.pool.1.port: 61613
  plugin.rabbitmq.pool.1.user: mcollective
  plugin.rabbitmq.pool.1.password: ScwpVo8egrZ0OmT6sRmp9zEA
  plugin.rabbitmq.heartbeat_interval: 30

  factsource: yaml
  plugin.yaml: /etc/mcollective/facts.yaml
  EOF

  $ keyname=brickies; image=$image;
  $ openstack server create \
     --key-name=$keyname --flavor=m1.small \
     --image=$image --user-data=user-data mcollective-test0

  # then ssh in and
  a.) verify mcollective package is installed
  $ dpkg-query --show mcollective
  mcollective 2.6.0+dfsg-2.1

  b.) verify mcollective service is running
  $ systemctl status mcollective

  c.) grep WARN /var/log/cloud-init.log && echo FAIL

  [Regression Potential]
  low to none.  This has been unfortunately broken since wily.

  [Other Info]
   End SRU Template 

  How to reproduce:

  #cat /etc/issue.net
  Ubuntu 16.04 LTS
  #( cd /var/lib/cloud/ && rm -rf * )
  #cloud-init -d init

  #grep ^mcollective: -A25 instance/user-data.txt
  mcollective:
    conf:
  main_collective: mcollective
  collectives: mcollective
  libdir: /usr/share/mcollective/plugins
  logfile: /var/log/mcollective.log
  loglevel: debug
  daemonize: 1
  direct_addressing: 1
  ttl: 4294957
  securityprovider: psk
  plugin.psk: unset
  identity: 2

  connector: rabbitmq
  plugin.rabbitmq.vhost: mcollective
  plugin.rabbitmq.pool.size: 1
  plugin.rabbitmq.pool.1.host: 10.10.0.2
  plugin.rabbitmq.pool.1.port: 61613
  plugin.rabbitmq.pool.1.user: mcollective
  plugin.rabbitmq.pool.1.password: ScwpVo8egrZ0OmT6sRmp9zEA
  plugin.rabbitmq.heartbeat_interval: 30

  factsource: yaml
  plugin.yaml: /etc/mcollective/facts.yaml

  #cloud-init -d single --name mcollective

  The log will contain

  Jun 30 08:26:43 node-2 [CLOUDINIT] util.py[DEBUG]: Running module
  mcollective ()
  failed#012Traceback (most recent call last):#012  File
  "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 739, in
  _run_modules#012freq=freq)#012  File "/usr/lib/python3/dist-
  packages/cloudinit/cloud.py", line 70, in run#012return
  self._runners.run(name, functor, args, freq, clear_on_fail)#012  File
  "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 199, in
  run#012results = functor(*args)#012  File "/usr/lib/python3/dist-
  packages/cloudinit/config/cc_mcollective.py", line 83, in handle#012
  mcollective_config.write(contents)#012  File "/usr/lib/python3/dist-
  packages/configobj.py", line 2126, in write#012
  outfile.write(output_bytes)#012TypeError: string argument expected,
  got 'bytes'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1597699/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1449318] Re: power_state does not take effect when runcmd errors

[Scott Moser]

This is fixed in cloud-init 0.7.7

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1449318

Title:
  power_state does not take effect when runcmd errors

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Wily:
  Won't Fix
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  When the runcmd errors the power-state-change does not take effect and
  the instance is not powered off.

  
  AMI ID: ubuntu-vivid-15.04-amd64-server-20150422 (ami-2d10241d)

  Instance launched on EC2 using awscli:

  $ aws --region us-west-2 ec2 run-instances --image-id ami-2d10241d
  --instance-type t2.medium --security-groups ssh-http-https --user-data
  file://fail.cfg

  Minimal fail.cfg cloud config:
  ```
  #cloud-config
  power_state:
mode: poweroff

  runcmd:
  - set -e
  - python3 -c "raise Exception"
  ```

  Longer fail.cfg used for retrieving logs:
  ```
  #cloud-config
  output:
all: '| tee -a /var/log/cloud-init-output.log'

  power_state:
mode: poweroff

  bootcmd:
  - cloud-init-per once ssh-users-ca echo "TrustedUserCAKeys 
/etc/ssh/users_ca.pub" >> /etc/ssh/sshd_config

  runcmd:
  - set -e
  - python3 -c "raise Exception"

  write_files:
  - path: /etc/ssh/users_ca.pub
content: 
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1449318/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1577982] Re: ConfigDrive: cloud-init fails to configure network from network_data.json

[Scott Moser]

This is fixed in cloud-init 0.7.7

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1577982

Title:
  ConfigDrive: cloud-init fails to configure network from
  network_data.json

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  When running Ubuntu 16.04 on OpenStack, cloud-init fails to properly
  configure the network from network_data.json found in ConfigDrive.

  When instance boots, network is configured fine until next reboot
  where it falls back to dhcp.

  The /etc/network/interfaces.d/50-cloud-init.cfg file has the following
  content when instance is initially booted, this could explain why dhcp
  is used on second boot:

  auto lo
  iface lo inet loopback
  
  auto eth0
  iface eth0 inet dhcp

  When debugging, if this line in stages.py [1] is commented, we can see
  that cloud-init initially copy the /etc/network/interfaces file found
  in the configdrive (the network template injected by Nova) and isn't
  using the network config found in network_data.json. But later it
  falls back to "dhcp" and rewrites yet again the network config.

  I also found that within self._find_networking_config(), it looks like
  no datasource is found at this point. This could be because cloud-init
  is still in "local" dsmode and then refuses to use the network config
  found in the ConfigDrive. (triggering the "dhcp" fallback logic)

  Manually forcing "net" dsmode makes cloud-init configure
  /etc/network/interfaces.d/50-cloud-init.cfg properly with network
  config found in the ConfigDrive. However no gateway is configured and
  so, instance doesn't respond to ping or SSH.

  At that point, I'm not sure what's going on and how I can debug
  further.

  Notes:
  * The image used for testing uses "net.ifnames=0". Removing this config makes 
things much worst. (no ping at all on first boot)
  * Logs, configs and configdrive can be found attached to this bug report.

  [1] http://bazaar.launchpad.net/~cloud-init-dev/cloud-
  init/trunk/view/head:/cloudinit/stages.py#L604

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1577982/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1590104] Re: network config from datasource overrides network config from system

[Scott Moser]

This is fixed in cloud-init 0.7.7

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1590104

Title:
  network config from datasource overrides network config from system

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Fix Released

Bug description:
  network configuration in system config should override that found as provided 
by a datasource.
  The order of precedence should be:
datasource
system config
kernel command line

  When juju creates lxc containers they want to be in control of networking and 
do not want cloud-init to configure networking either from the datasource 
(lxc's template provided nocloud) or from fallback.
  They are specifying that configuration directly in /etc/network/interfaces.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: cloud-init 0.7.7~bzr1212-0ubuntu1
  ProcVersionSignature: Ubuntu 4.4.0-23.41-generic 4.4.10
  Uname: Linux 4.4.0-23-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  Date: Tue Jun  7 18:16:09 2016
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
  SourcePackage: cloud-init
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1590104/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1602373] Re: cloud-init doesn't always land files that one expects

[Scott Moser]

This is fixed in cloud-init 0.7.7

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1602373

Title:
  cloud-init doesn't always land files that one expects

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
   Begin SRU Template 
  [Impact]
  Injected files functionality of OpenStack's config drive is broken.

  [Test Case]
  == Reproduce broken functionality ==
  $ echo "hi mom" > my-file.txt
  $ cat > "user-data" <<"EOF"
  #!/bin/sh
  logfile=/run/my.log
  file="/my-file.txt"
  if [ -e "$file" ]; then
     ( echo "=== PASS: file $file " ; cat $file ) | tee -a $logfile
     exit 0
  else
     echo "=== FAIL: no file $file " | tee -a $logfile
     exit 0
  fi
  EOF

  openstack server create --key-name=brickies --flavor=m1.small \
    --config-drive=1 --image=$img \
    --user-data=user-data --file=/my-file.txt=my-file.txt \
    injected-file0

  The launched system will have a file in /run/my.log that shows 'FAIL'
  and will not have /my-file.txt on disk.

  == See Fix ==
  # enable proposed
  $ cat > enable-proposed <<"EOF"
  #!/bin/sh
  set -e
  rel=$(lsb_release -sc)
  awk '$1 == "deb" && $2 ~ /ubuntu.com/ {
    printf("%s %s %s-proposed main universe\n", $1, $2, rel); exit(0) };
    ' "rel=$rel" /etc/apt/sources.list |
  tee /etc/apt/sources.list.d/proposed.list
  EOF
  $ sudo sh ./enable-proposed
  $ sudo apt-get update
  $ sudo apt-get install cloud-init

  # Remove /var/lib/cloud and /var/log/cloud-init* to remove state
  # and indicate this is a new instance on reboot
  $ sudo rm -Rf /var/lib/cloud /var/log/cloud-init*
  $ sudo reboot

  Now ssh back in after reboot, you should
  a.) have /my-file.txt
  b.) see PASS in /run/my.log
  c.) see mention of the 'injected file' in /var/log/cloud-init.log

  [Regression Potential]
  Regression potential on Ubuntu should be very small.

   End SRU Template 

  Trove launches instances using the servers.create() API with some
  files. Trove provides a dictionary of files that it wants on the
  instance and most of the time this works. Nova passes them to the
  launched VM as metadata on config drive.

  Sometimes though, it doesn't.

  When injection fails, I see a cloud-init.log that looks like this:

  https://gist.github.com/amrith/7566d8fef4b6e813cca77e5e3b1f1d5a

  When injection succeeds, I see a cloud-init.log that looks like this:

  https://gist.github.com/amrith/50d9e3050d88ec51e13b0a510bd718c3

  Observe that the one that succeeds properly injects three files:

  /etc/injected_files (which is something I added just for debugging)
  /etc/trove/conf.d/... two files here ...

  On a machine where this injection failed:

  root@m10:/tmp/zz/openstack/content# ls -l /etc/trove
  total 4
  drwxr-xr-x 2 amrith root 4096 Jul 12 16:55 conf.d
  root@m10:/tmp/zz/openstack/content# ls -l /etc/trove/conf.d/
  total 4
  root@m10:/tmp/zz/openstack/content#

  Clearly, no files made it over. Yet, the files are definitely there on
  the config drive ...

  I've mounted the config drive.

  root@m10:/tmp/zz/openstack/content# mount | grep zz
  /dev/sr0 on /tmp/zz type iso9660 (ro,relatime)

  root@m10:/tmp/zz/openstack/content# cd /tmp/zz
  root@m10:/tmp/zz# find .
  .
  ./ec2
  ./ec2/2009-04-04
  ./ec2/2009-04-04/meta-data.json
  ./ec2/latest
  ./ec2/latest/meta-data.json
  ./openstack
  ./openstack/2012-08-10
  ./openstack/2012-08-10/meta_data.json
  ./openstack/2013-04-04
  ./openstack/2013-04-04/meta_data.json
  ./openstack/2013-10-17
  ./openstack/2013-10-17/meta_data.json
  ./openstack/2013-10-17/vendor_data.json
  ./openstack/2015-10-15
  ./openstack/2015-10-15/meta_data.json
  ./openstack/2015-10-15/network_data.json
  ./openstack/2015-10-15/vendor_data.json
  ./openstack/2016-06-30
  ./openstack/2016-06-30/meta_data.json
  ./openstack/2016-06-30/network_data.json
  ./openstack/2016-06-30/vendor_data.json
  ./openstack/content
  ./openstack/content/
  ./openstack/content/0001
  ./openstack/content/0002
  ./openstack/latest
  ./openstack/latest/meta_data.json
  ./openstack/latest/network_data.json
  ./openstack/latest/vendor_data.json

  root@m10:/tmp/zz# cd openstack/latest/
  root@m10:/tmp/zz/openstack/latest# cat meta_data.json
  {"files": [{"path": "/etc/injected_files", "content_path": "/content/"}, 
{"path": "/etc/trove/conf.d/guest_info.conf", "content_path": "/content/0001"}, 
{"path": "/etc/trove/conf.d/trove-guestagent.conf", "content_path": 
"/content/0002"}], "admin_pass": "pf2ng7tT8JSt", "random_seed": 
"uSNqQ3udiKspue4y8R8b4gg33Qe6klYYJa8ebvDS0t4i88rq2Owu4yC8TysAfsmsYpno0rbWpWisiTQ3raAOPsx+kGgkrunM9UR5khs/1XRh60tlpKJVIHZnKpLv4PcisLKL2DDoHaaFLV9lPcVtZi3iTqKu6RhcwFyhh+A

[Group.of.nepali.translators] [Bug 1596690] Re: restoring from datasource without dsmode causes stacktrace

[Scott Moser]

This is fixed in cloud-init 0.7.7

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1596690

Title:
  restoring from datasource without dsmode causes stacktrace

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  On reboot, if cloud-init found a cached /var/lib/cloud/instance/obj.pkl it 
would restore from it.
  If that class did not have a 'dsmode', then main would stack trace like:
  | "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 530, in 
status_wrapper
  | ret = functor(name, args)
  |   File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 247, in 
main_init
  | if mode == sources.DSMODE_NETWORK and init.datasource.dsmode != mode:
  | AttributeError: 'DataSourceAzureNet' object has no attribute 'dsmode'

  This would affect upgrade and reboot on any datasource that did not
  have a dsmode previously.

  That list is
cloudinit/sources/DataSourceAzure.py
cloudinit/sources/DataSourceBigstep.py
cloudinit/sources/DataSourceCloudStack.py
cloudinit/sources/DataSourceDigitalOcean.py
cloudinit/sources/DataSourceEc2.py
cloudinit/sources/DataSourceGCE.py
cloudinit/sources/DataSourceMAAS.py
cloudinit/sources/DataSourceNone.py
cloudinit/sources/DataSourceOVF.py
cloudinit/sources/DataSourceSmartOS.py

  The non-broken datasources then were the ones that previously had a dsmode:
cloudinit/sources/DataSourceAltCloud.py
cloudinit/sources/DataSourceCloudSigma.py
cloudinit/sources/DataSourceConfigDrive.py
cloudinit/sources/DataSourceNoCloud.py
cloudinit/sources/DataSourceOpenNebula.py
cloudinit/sources/DataSourceOpenStack.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1596690/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp