date:20161223

[Group.of.nepali.translators] [Bug 1651602] Re: [2.1.1] MAAS has nvme0n1 set as boot disk, curtin fails

2016-12-23 Thread Dan Streetman

Chris, as your specific problem seems different than the 1-cpu NVMe bug
that the rest of this bug describes, and my patch fixes, can you open a
new bug please.

** Changed in: maas
   Status: New => Invalid

-- 
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/1651602

Title:
  [2.1.1] MAAS has nvme0n1 set as boot disk, curtin fails

Status in MAAS:
  Invalid
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  Confirmed

Bug description:
  MAAS Version 2.1.1+bzr5544-0ubuntu1 (16.10.1)
  Deploying Xenial Nodes

  1) Deploy MAAS 2.1.1 on Yakkety
  2) Associate Juju 2.1 beta3
  3) Juju deploy Kubernetes Core

  Nodes begin to deploy but fail

  Installation failed with exception: Unexpected error while running command.
  Command: ['curtin', 'block-meta', 'custom']
  Exit code: 3
  Reason: -
  Stdout: b"no disk with serial 'CVMD434500BN400AGN' found\n"

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1651602/+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

2016-12-23 Thread Launchpad Bug Tracker

This bug was fixed in the package cloud-init - 0.7.9-0ubuntu1

---
cloud-init (0.7.9-0ubuntu1) zesty; urgency=medium

  * New upstream snapshot.
- release 0.7.9
- doc: adjust headers in tests documentation for consistency.
- integration test: initial commit of integration test framework
  [Wesley Wiedenmeier]
- LICENSE: Allow dual licensing GPL-3 or Apache 2.0 [Jon Grimm]
- Fix config order of precedence, putting kernel command line over system.
  [Wesley Wiedenmeier] (LP: #1582323)
- Update the list of valid ssh keys. [Michael Felt]
- network: add ENI unit test for statically rendered routes.
- set_hostname: avoid erroneously appending domain to fqdn
  [Lars Kellogg-Stedman] (LP: #1647910)
- doc: change 'nobootwait' to 'nofail' in docs [Anhad Jai Singh]
- Replace an expired bit.ly link in code comment.

 -- Scott Moser   Fri, 23 Dec 2016 12:54:50 -0500

** Changed in: cloud-init (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/1582323

Title:
  Commissioning fails when competing cloud metadata resides on disk

Status in cloud-init:
  Fix Released
Status in MAAS:
  Fix Committed
Status in MAAS 2.1 series:
  Fix Committed
Status in MAAS trunk series:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed

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 1611074] Re: Reformatting of ephemeral drive fails on resize of Azure VM

2016-12-23 Thread Scott Moser

This is fixed in 0.7.9.

** 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/1611074

Title:
  Reformatting of ephemeral drive fails on resize of Azure VM

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:
  === Begin SRU Template ===
  [Impact]
  In some cases, cloud-init writes entries to /etc/fstab, and on azure it will
  even format a disk for mounting and then write the entry for that 'ephemeral'
  disk there.

  A supported operation on Azure is to "resize" the system.  When you do this
  the system is shut down, resized (given larger/faster disks and more CPU) and
  then brought back up.  In that process, the "ephemeral" disk re-initialized
  to its original NTFS format.  The designed goal is for cloud-init to recognize
  this situation and re-format the disk to ext4.

  The problem is that the mount of that disk happens before cloud-init can
  reformat.  Thats because the entry in fstab has 'auto' and is automatically
  mounted.  The end result is that after resize operation the user will be left
  with the ephemeral disk mounted at /mnt and having a ntfs filesystem rather
  than ext4.

  [Test Case]
  The text in comment 3 describes how to recreate by the original reporter.
  Another way to do this is to just re-format the ephemeral disk as
  ntfs and then reboot.  The result *should* be that after reboot it
  comes back up and has an ext4 filesystem on it.

  1.) boot system on azure
    (for this, i use https://gist.github.com/smoser/5806147, but you can
     use web ui or any other way).
     Save output of
   journalctl --no-pager > journalctl.orig
   systemctl status --no-pager > systemctl-status.orig
   systemctl --no-pager > systemctl.orig

  2.) unmount the ephemeral disk
     $ umount /mnt

  3.) repartition it so that mkfs.ntfs does less and is faster
     This is not strictly necessary, but mkfs.ntfs can take upwards of
     20 minutes.  shrinking /dev/sdb2 to be 200M means it will finish
     in < 1 minute.

     $ disk=/dev/disk/cloud/azure_resource
     $ part=/dev/disk/cloud/azure_resource-part1
     $ echo "2048,$((2*1024*100)),7" | sudo sfdisk "$disk"
     $ time mkfs.ntfs --quick "$part"

  4.) reboot
  5.) expect that /proc/mounts has /dev/disk/cloud/azure_resource-part1 as ext4
  and that fstab has x-systemd.requires in it.

  $ awk '$2 == "/mnt" { print $0 }' /proc/mounts
  /dev/sdb1 /mnt ext4 rw,relatime,data=ordered 0 0

  $ awk '$2 == "/mnt" { print $0 }' /etc/fstab
  /dev/sdb1 /mnt auto 
defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig 0 2

  6.) collect journal and systemctl information as described in step 1 above.
  Compare output, specifically looking for case insensitve "breaks"

  [Regression Potential]
  Regression is unlikely.  Likely failure case is just that the problem is not
  correctly fixed, and the user ends up with either an NTFS formated disk that
  is mounted at /mnt or there is nothing mounted at /mnt.

  === End SRU Template ===

  After resizing a 16.04 VM on Azure, the VM is presented with a new
  ephemeral drive (of a different size), which initially is NTFS
  formatted. Cloud-init tries to format the appropriate partition ext4,
  but fails because it is mounted. Cloud-init has unmount logic for
  exactly this case in the get_data call on the Azure data source, but
  this is never called because fresh cache is found.

  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] handlers.py[DEBUG]: start: 
init-network/check-cache: attempting to read from cache [trust]
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Reading from 
/var/lib/cloud/instance/obj.pkl (quiet=False)
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Read 5950 bytes 
from /var/lib/cloud/instance/obj.pkl
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] stages.py[DEBUG]: restored from 
cache: DataSourceAzureNet [seed=/dev/sr0]
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] handlers.py[DEBUG]: finish: 
init-network/check-cache: SUCCESS: restored from cache: DataSourceAzureNet 
[seed=/dev/sr0]
  ...
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] cc_disk_setup.py[DEBUG]: Creating 
file system None on /dev/sdb1
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] cc_disk_setup.py[DEBUG]:  
Using cmd: /sbin/mkfs.ext4 /dev/sdb1
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Running command 
['/sbin/mkfs.ext4', '/dev/sdb1'] with allowed return codes [0] (shell=False, 
capture=True)
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Creating fs for 
/dev/disk/cloud/azure_resource took 0.052 seconds

[Group.of.nepali.translators] [Bug 1623868] Re: cloud-final.service does not run due to dependency cycle

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   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/1623868

Title:
  cloud-final.service does not run due to dependency cycle

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]
  As part of the change in bug 1576692, we made cloud-final.target
  run After multi-user.target.  That created a dependency loop between
  cloud-init.target and multi-user.target and cloud-final.target.

  Most of the time systemd would break that loop by dropping
  cloud-init.target.  But sometimes, it would break the loop by dropping
  cloud-final.target, which would mean that user scripts do not run
  and generally cloud-init doesn't finish.

  [Test Case]
  ## Failure in a xenial image can only be reproduced by
  ## patching an image up to the previous xenial-proposed upload
  ## (0.7.7-31-g65ace7b-0ubuntu1~16.04.1), then cleaning it
  ## and then restarting.  We will focus on verifying there is not
  ## a problem.

  ## Launch an instance and patch it up to xenial-proposed
  $ release=xenial
  $ name=x1
  $ lxc launch ubuntu-daily:$release $name

  # wait for it to boot
  $ while ! lxc exec $name -- [ -e /run/cloud-init/result.json ]; do sleep 1; 
done

  ## Now update container, clean and reboot to show first boot
  $ lxc exec $name -- sh -c '
  p=/etc/apt/sources.list.d/proposed.list
  echo deb http://archive.ubuntu.com/ubuntu xenial-proposed main > "$p" &&
  apt-get update -q && apt-get -qy install cloud-init'
  $ lxc exec $name -- sh -c '
  cd /var/lib/cloud && for d in *; do [ "$d" = "seed" ] || rm -Rf "$d"; done
  rm -Rf /var/log/cloud-init*'

  ## This is like first boot now.
  $ lxc exec $name reboot
  $ while ! lxc exec $name -- [ -e /run/cloud-init/result.json ]; do sleep 1; 
done

  ## The services should show active
  $ lxc exec $name -- journalctl | grep Break || echo Good, no breaks
  $ lxc exec $name -- systemctl --no-pager status cloud-final.service
  $ lxc exec $name -- systemctl --no-pager status cloud-init.target

  [Regression Potential]
  Playing with boot order can cause problems.  Regression would be around
  some targets not running.   On a booted system this would show itself inx
    journalctl | grep -i Break
  or
    journalctl | grep -i ordering

   End SRU Template 

  With current yakkety cloud images (at least in Scalingstack), I often
  run into this dependency cycle at boot:

  Sep 15 09:28:51 ubuntu systemd[1]: cloud-init.target: Found ordering cycle on 
cloud-init.target/start
  Sep 15 09:28:51 ubuntu systemd[1]: cloud-init.target: Found dependency on 
cloud-final.service/start
  Sep 15 09:28:51 ubuntu systemd[1]: cloud-init.target: Found dependency on 
multi-user.target/start
  Sep 15 09:28:51 ubuntu systemd[1]: cloud-init.target: Found dependency on 
cloud-init.target/start
  Sep 15 09:28:51 ubuntu systemd[1]: cloud-init.target: Breaking ordering cycle 
by deleting job cloud-final.service/start
  Sep 15 09:28:51 ubuntu systemd[1]: cloud-final.service: Job 
cloud-final.service/start deleted to break ordering cycle starting with 
cloud-init.target/start

  ● cloud-final.service - Execute cloud user/final scripts
     Loaded: loaded (/lib/systemd/system/cloud-final.service; enabled; vendor 
preset: enabled)
     Active: inactive (dead)

  Thus /var/lib/cloud/instance/boot-finished never gets written and thus
  waiting for an instance to init just times out.

  This is with the most recent https://launchpad.net/ubuntu/+source
  /cloud-init/0.7.7-31-g65ace7b-0ubuntu1

  Related bugs:
   * bug 1576692: fully support package installation in systemd

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1623868/+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 1354694] Re: useradd crashes if group list contains whitespace on Fedora

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** 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/1354694

Title:
  useradd crashes if group list contains whitespace on Fedora

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 Yakkety:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact]
  A specific usage of user data to cloud-init will fail to add a user.

  This cloud-config:
#cloud-config
users:
  - default
  - name: foobar
gecos: "My User"
groups: sudo, adm

  Will fail with information in the cloud-init log showing:
  2016-12-19 21:39:32,713 - util.py[WARNING]: Failed to create group  adm
  2016-12-19 21:39:32,713 - util.py[DEBUG]: Failed to create group  adm
  Traceback (most recent call last):
  ...
  cloudinit.util.ProcessExecutionError: Unexpected error while running command.
  Command: ['groupadd', ' adm']
  Exit code: 3
  Reason: -
  Stdout: ''
  Stderr: "groupadd: ' adm' is not a valid group name\n"

  While changing the last line to the following would work:
groups: [sudo, adm]

  [Test Case]
  $ cat > user-data <"EOF"
  #cloud-config
  users:
- default
- name: foobar
  gecos: "My User"
  groups: sudo, adm
- name: wark
  groups: [sudo, adm]

  $ release=yakkety
  $ name="$release-1354694"

  $ lxc launch "ubuntu-daily:$release" "$name" \
   "--config=user.user-data=$(cat user-data)"

  $ sleep 10

  ## Check foobar is in expected groups
  $ lxc exec $name -- groups foobar
  foobar : foobar adm sudo

  $ lxc exec $name -- groups wark
  wark : wark adm sudo

  $ lxc exec $name -- grep WARN /var/log/cloud-init.log || echo "no warn"
  no warn

  [Regression Potential]
  There are 3 changes in this commit
  a.) if 'groups' entry is a string, split on "," and strip pieces
  The most likely path to failure here is if previously a non-string
  (possibly bytes) was being passed in and now will be ignored.
  That seems unlikely and clearly wrong input.

  b.) fix and unit tests to explicitly set system=False or no_create_home=True.
  Previously those paths did not test the value of the entry, only the
  presense of the entry.
  This meant that these 2 configs were the same:
users: {name: bob, system: True}
  and
users: {name: bob, system: False}

  That bug is fixed here so that 'system: False' is just explicitly
  disabling the '--system' flag to adduser.

  c.) debug message cleanup:

 LOG.debug("created group %s for user %s", name, group)
 LOG.debug("created group '%s' for user '%s'", group, name)

  [Other Info]
  Upstream commit at

https://git.launchpad.net/cloud-init/commit/?id=ca3ae67211d907b4cfdcd685c0ae4f9530cb7da1

  === End SRU Template ===

  
  See downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1126365

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1354694/+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 1354694] Re: useradd crashes if group list contains whitespace on Fedora

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   Status: Fix Released => 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/1354694

Title:
  useradd crashes if group list contains whitespace on Fedora

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 Yakkety:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact]
  A specific usage of user data to cloud-init will fail to add a user.

  This cloud-config:
#cloud-config
users:
  - default
  - name: foobar
gecos: "My User"
groups: sudo, adm

  Will fail with information in the cloud-init log showing:
  2016-12-19 21:39:32,713 - util.py[WARNING]: Failed to create group  adm
  2016-12-19 21:39:32,713 - util.py[DEBUG]: Failed to create group  adm
  Traceback (most recent call last):
  ...
  cloudinit.util.ProcessExecutionError: Unexpected error while running command.
  Command: ['groupadd', ' adm']
  Exit code: 3
  Reason: -
  Stdout: ''
  Stderr: "groupadd: ' adm' is not a valid group name\n"

  While changing the last line to the following would work:
groups: [sudo, adm]

  [Test Case]
  $ cat > user-data <"EOF"
  #cloud-config
  users:
- default
- name: foobar
  gecos: "My User"
  groups: sudo, adm
- name: wark
  groups: [sudo, adm]

  $ release=yakkety
  $ name="$release-1354694"

  $ lxc launch "ubuntu-daily:$release" "$name" \
   "--config=user.user-data=$(cat user-data)"

  $ sleep 10

  ## Check foobar is in expected groups
  $ lxc exec $name -- groups foobar
  foobar : foobar adm sudo

  $ lxc exec $name -- groups wark
  wark : wark adm sudo

  $ lxc exec $name -- grep WARN /var/log/cloud-init.log || echo "no warn"
  no warn

  [Regression Potential]
  There are 3 changes in this commit
  a.) if 'groups' entry is a string, split on "," and strip pieces
  The most likely path to failure here is if previously a non-string
  (possibly bytes) was being passed in and now will be ignored.
  That seems unlikely and clearly wrong input.

  b.) fix and unit tests to explicitly set system=False or no_create_home=True.
  Previously those paths did not test the value of the entry, only the
  presense of the entry.
  This meant that these 2 configs were the same:
users: {name: bob, system: True}
  and
users: {name: bob, system: False}

  That bug is fixed here so that 'system: False' is just explicitly
  disabling the '--system' flag to adduser.

  c.) debug message cleanup:

 LOG.debug("created group %s for user %s", name, group)
 LOG.debug("created group '%s' for user '%s'", group, name)

  [Other Info]
  Upstream commit at

https://git.launchpad.net/cloud-init/commit/?id=ca3ae67211d907b4cfdcd685c0ae4f9530cb7da1

  === End SRU Template ===

  
  See downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1126365

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1354694/+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 1354694] Re: useradd crashes if group list contains whitespace on Fedora

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** 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/1354694

Title:
  useradd crashes if group list contains whitespace on Fedora

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 Yakkety:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact]
  A specific usage of user data to cloud-init will fail to add a user.

  This cloud-config:
#cloud-config
users:
  - default
  - name: foobar
gecos: "My User"
groups: sudo, adm

  Will fail with information in the cloud-init log showing:
  2016-12-19 21:39:32,713 - util.py[WARNING]: Failed to create group  adm
  2016-12-19 21:39:32,713 - util.py[DEBUG]: Failed to create group  adm
  Traceback (most recent call last):
  ...
  cloudinit.util.ProcessExecutionError: Unexpected error while running command.
  Command: ['groupadd', ' adm']
  Exit code: 3
  Reason: -
  Stdout: ''
  Stderr: "groupadd: ' adm' is not a valid group name\n"

  While changing the last line to the following would work:
groups: [sudo, adm]

  [Test Case]
  $ cat > user-data <"EOF"
  #cloud-config
  users:
- default
- name: foobar
  gecos: "My User"
  groups: sudo, adm
- name: wark
  groups: [sudo, adm]

  $ release=yakkety
  $ name="$release-1354694"

  $ lxc launch "ubuntu-daily:$release" "$name" \
   "--config=user.user-data=$(cat user-data)"

  $ sleep 10

  ## Check foobar is in expected groups
  $ lxc exec $name -- groups foobar
  foobar : foobar adm sudo

  $ lxc exec $name -- groups wark
  wark : wark adm sudo

  $ lxc exec $name -- grep WARN /var/log/cloud-init.log || echo "no warn"
  no warn

  [Regression Potential]
  There are 3 changes in this commit
  a.) if 'groups' entry is a string, split on "," and strip pieces
  The most likely path to failure here is if previously a non-string
  (possibly bytes) was being passed in and now will be ignored.
  That seems unlikely and clearly wrong input.

  b.) fix and unit tests to explicitly set system=False or no_create_home=True.
  Previously those paths did not test the value of the entry, only the
  presense of the entry.
  This meant that these 2 configs were the same:
users: {name: bob, system: True}
  and
users: {name: bob, system: False}

  That bug is fixed here so that 'system: False' is just explicitly
  disabling the '--system' flag to adduser.

  c.) debug message cleanup:

 LOG.debug("created group %s for user %s", name, group)
 LOG.debug("created group '%s' for user '%s'", group, name)

  [Other Info]
  Upstream commit at

https://git.launchpad.net/cloud-init/commit/?id=ca3ae67211d907b4cfdcd685c0ae4f9530cb7da1

  === End SRU Template ===

  
  See downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1126365

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1354694/+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 1460715] Re: MBR disk setup fails because sfdisk no longer accepts M as a valid unit

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** 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/1460715

Title:
  MBR disk setup fails because sfdisk no longer accepts M as a valid
  unit

Status in cloud-init:
  Fix Released
Status in Ubuntu Image:
  Invalid
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:
  In Progress

Bug description:
  === Begin SRU Template ===
  [Impact]
  Cloud-init has function to partition disks on devices.
  Creating partitions on a disk no longer works with sfdisk as recent versions 
of
  sfdisk no accept the unit 'M' as input, this function is broken.

  [Test Case]
  1. Launch an instance with provided user-data

     On Azure, this will work:
   #cloud-config
   disk_setup:
     ephemeral0:
     table_type: mbr
     layout: [66, [33, 82]]
     overwrite: True
   fs_setup:
     - device: ephemeral0.1
   filesystem: ext4
     - device: ephemeral0.2
   filesystem: swap
   mounts:
     - ["ephemeral0.1", "/mnt2"]
     - ["ephemeral0.2", "none", "swap", "sw", "0", "0"]

     On a typical kvm openstack use:
   #cloud-config
   disk_setup:
     /dev/vdb:
     table_type: mbr
     layout: [66, [33, 82]]
     overwrite: True
   fs_setup:
     - device: /dev/vdb1
   filesystem: ext4
     - device: /dev/vdb2
   filesystem: swap
   mounts:
     - ["/dev/vdb1", "/mnt2"]
     - ["/dev/vdb2", "none", "swap", "sw", "0", "0"]

  2. Add proposed, update, and reboot as fresh instance.

     # enable proposed
     echo deb http://archive.ubuntu.com/ubuntu $(lsb_release -sc)-proposed main 
| sudo tee /etc/apt/sources.list.d/proposed.list
     sudo apt-get -qy update && sudo apt-get -qy install cloud-init https://bugs.launchpad.net/cloud-init/+bug/1460715/+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 1626243] Re: Cloud-init fails to write ext4 filesystem to Azure Ephemeral Drive

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** 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/1626243

Title:
  Cloud-init fails to write ext4 filesystem to Azure Ephemeral Drive

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
Status in cloud-init source package in Zesty:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  There is a race condition that occurs when cloud-init tries to partition a
  block device (/dev/sdb) and then put a filesystem on a partition on it.  It is
  possible that cloud-init tries to run mkfs on /dev/sdb1 after partitioning the
  device /dev/sdb but before the partition device node '/dev/sdb1' exists.

  When this race condition occurs, cloud-init will fail to make the "ephemeral"
  device available to the user on Azure.

  [Test Case]
  A reliable reproduce test case is hard to come by here.  The failure case
  is believed to be well understood.

  [Regression Potential]
  There should be very little chance for regression, as essentially all the 
change
  does is change:

  1.   sgdisk -n 1:0:0 /dev/sdb
  2.   mkfs.ext4 /dev/sdb1

  to

  1.   sgdisk -n 1:0:0 /dev/sdb
  1a   udevadm settle
  1b   blockdev --rereadpt
  1c   udevadm settle
  2.   mkfs.ext4 /dev/sdb1

  The steps '1b' and '1c' above are not necessary, but were present already in
  the method.  They serve here as additional wait.

  [Other Info]
  The change that fixes this is viewable at [1].  For context, viewin all of
  cc_disk_setup.py [2].  Basically we just add a call to read_parttbl [3] to
  exec_mkpart_gpt after invoking a sgdisk command that partitions a disk.
  read_partbl basically does a udevadm settle which fixes the race condition 
that
  was seen.

  [1] 
https://git.launchpad.net/cloud-init/commit/?id=29348af1c889931e8973f8fc8cb090c063316f7a
  [2] 
https://git.launchpad.net/cloud-init/tree/cloudinit/config/cc_disk_setup.py?id=29348af1c889931e8973f8fc8cb090c063316f7a
  [3] 
https://git.launchpad.net/cloud-init/tree/cloudinit/config/cc_disk_setup.py?id=29348af1c889931e8973f8fc8cb090c063316f7a#n674

  === End SRU Template ===

  The symptom is similar to bug 1611074 but the cause is different. In
  this case it seems there is an error accessing /dev/sdb1 when lsblk is
  run, possibly because sgdisk isn't done creating the partition. The
  specific error message is "/dev/sdb1: not a block device." A simple
  wait and retry here may resolve the issue.

  util.py[DEBUG]: Running command ['/sbin/sgdisk', '-p', '/dev/sdb'] with 
allowed return codes [0] (shell=False, capture=True)
  cc_disk_setup.py[DEBUG]: Device partitioning layout matches
  util.py[DEBUG]: Creating partition on /dev/disk/cloud/azure_resource took 
0.056 seconds
  cc_disk_setup.py[DEBUG]: setting up filesystems: [{'filesystem': 'ext4', 
'device': 'ephemeral0.1', 'replace_fs': 'ntfs'}]
  cc_disk_setup.py[DEBUG]: ephemeral0.1 is mapped to 
disk=/dev/disk/cloud/azure_resource part=1
  cc_disk_setup.py[DEBUG]: Creating new filesystem.
  cc_disk_setup.py[DEBUG]: Checking /dev/sdb against default devices
  cc_disk_setup.py[DEBUG]: Manual request of partition 1 for /dev/sdb1
  cc_disk_setup.py[DEBUG]: Checking device /dev/sdb1
  util.py[DEBUG]: Running command ['/sbin/blkid', '-c', '/dev/null', 
'/dev/sdb1'] with allowed return codes [0, 2] (shell=False, capture=True)
  cc_disk_setup.py[DEBUG]: Device /dev/sdb1 has None None
  cc_disk_setup.py[DEBUG]: Device /dev/sdb1 is cleared for formating
  cc_disk_setup.py[DEBUG]: File system None will be created on /dev/sdb1
  util.py[DEBUG]: Running command ['/bin/lsblk', '--pairs', '--output', 
'NAME,TYPE,FSTYPE,LABEL', '/dev/sdb1', '--nodeps'] with allowed return codes 
[0] (shell=False, capture=True)
  util.py[DEBUG]: Creating fs for /dev/disk/cloud/azure_resource took 0.008 
seconds
  util.py[WARNING]: Failed during filesystem operation#012Failed during disk 
check for /dev/sdb1#012Unexpected error while running command.#012Command: 
['/bin/lsblk', '--pairs', '--output', 'NAME,TYPE,FSTYPE,LABEL', '/dev/sdb1', 
'--nodeps']#012Exit code: 32#012Reason: -#012Stdout: ''#012Stderr: 'lsblk: 
/dev/sdb1: not a block device\n'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1626243/+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 1621615] Re: network not configured when ipv6 netbooted into cloud-init

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** 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/1621615

Title:
  network not configured when ipv6 netbooted into cloud-init

Status in cloud-init:
  Fix Released
Status in MAAS:
  In Progress
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-initramfs-tools package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-initramfs-tools source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Fix Released
Status in cloud-initramfs-tools source package in Yakkety:
  Fix Released

Bug description:
  https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1621507 talks of
  how IPv6 netboot with iscsi root disk doesn't work, blocking IPv6-only
  MAAS.

  After I hand-walked busybox through getting an IPv6 address,
  everything worked just fine until cloud-init couldn't fetch the
  instance data, because it insisted on bringing up the interface in
  IPv4, and there is no IPv4 DHCP on that vlan.

  Please work with initramfs and friends on getting IPv6 netboot to
  actually configure the interface.  This may be as simple as teaching
  it about "inet6 dhcp" interfaces, and bolting the pieces together.
  Note that "use radvd" is not really an option for our use case.

  Related bugs:
   * bug 1621507: initramfs-tools configure_networking() fails to dhcp IPv6 
addresses
   * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6)
   * bug 1639930: initramfs network configuration ignored if only ip6= on 
kernel command line 

  [Impact]

  It is not possible to enlist, commmission, or deploy with MAAS in an
  IPv6-only environment. Anyone wanting to netboot with a network root
  filesystem in an IPv6-only environment is affected.

  This upload addresses this by accepting, using, and forwarding any
  IPV6* variables from the initramfs boot.  (See
  https://launchpad.net/bugs/1621507)

  [Test Case]

  See Bug 1229458. Configure radvd, dhcpd, and tftpd for your IPv6-only
  netbooting world. Pass the boot process an IPv6 address to fetch
  instance-data from, and see it fail to configure the network.

  [Regression Potential]

  1) If the booting host is in a dual-boot environment, and the
  instance-dat URL uses a hostname that has both A and  RRsets, the
  booting host may try to talk IPv6 to get instance data.  If the
  instance-data providing host is only allowing that to happen over
  IPv4, it will fail. (It also represents a configuraiton issue on the
  providing host...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1621615/+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 1628337] Re: cloud-init tries to install NTP before even configuring the archives

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** 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/1628337

Title:
  cloud-init tries to install NTP before even configuring the archives

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]
  When told to configure ntp, and the ntp package is not installed
  in an image, cloud-init will attempt to install the package.

  The problem here is that it currently tries to install the package before
  it configures apt.  As a result, no apt proxy or mirror configuration is
  setup, and the stock image apt config is used.

  [Test Case]
  ## Failure can be shown like this:
  $ cat > user-data  "$p" &&
  apt-get update -q && apt-get -qy install cloud-init'
  $ lxc exec $name -- sh -c '
  cd /var/lib/cloud && for d in *; do [ "$d" = "seed" ] || rm -Rf "$d"; done
  rm -Rf /var/log/cloud-init*'

  $ lxc file pull $name/var/log/cloud-init-output.log - | egrep "^[EW]:" ||
echo "FIX WORKED."

  [Regression Potential]
  The 'ntp' function is fairly new, and is only used if a user specifies
  an ntp configuration as shown above.  Regression chance is low then
  and should be restricted to scenarios where users are providing
  the ntp configuration.
  == End SRU Template ==

  cloud-init tries to install NTP package before it actually configures
  /etc/apt/sources.list.

  In a closed MAAS environment where MAAS is limited to access to
  us.archive.ubuntu.com , cloud-init is trying to access to
  archive.ubuntu.com.

  In commissioning, however, cloud-init is doing this:

  1. cloud-init gets metadata from MAAS
  2. cloud-init tries to install NTP from archive.ubuntu.com
  3. cloud-init configures /etc/apt/sources.list with us.archive.ubuntu.com
  4. cloud-init installs other packages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1628337/+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 1635350] Re: unit tests fail as non-root on maas deployed system

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** 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/1635350

Title:
  unit tests fail as non-root on maas deployed 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:
  === Begin SRU Template ===
  [Impact]
  Running cloud-init's unit test cases on a system deployed by MAAS would
  fail.  The reason is that the non-root user would not be able to read
  files with MAAS node credentials in /etc/cloud/cloud.cfg.d

  We want this change SRU so that an attempt to build and run tests on a
  system deployed by maas will work rather than fail due to unit test failure.

  [Test Case]
  Run unit tests on a system deployed by maas, or even just with:
    f=/etc/cloud/cloud.cfg.d/90_dpkg_maas.cfg
    sh -c 'mkdir -p "${1%/*}" && touch "$1" && chmod ugo-r "$1"' -- "$f"
    tox -e py3

  [Regression Potential]
  This was just to fix a build break or unit tests being run.
  Changes are only to unit tests.
  === End SRU Template ===

  Observed Behavior:

  On a system deployed by MAAS I checked out master and then tried to 
immediately build it:
  > git clone https://git.launchpad.net/cloud-init
  > cd cloud-init
  > ./packages/bddeb

  I get a number of errors around permission issues around this file:
  PermissionError: [Errno 13] Permission denied: 
\'/etc/cloud/cloud.cfg.d/90_dpkg_maas.cfg\'

  See: https://paste.ubuntu.com/23354559/
   or formatted better: http://paste.ubuntu.com/23374383/

  If I run as root however, it build as expected.

  Expected Behavior:
  Running bddeb works as a non-root user.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1635350/+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 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)

2016-12-23 Thread Scott Moser

** Also affects: cloud-init
   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/1636912

Title:
  systemd-networkd runs too late for cloud-init.service (net)

Status in cloud-init:
  New
Status in systemd:
  Fix Released
Status in cloud-init package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  New
Status in systemd source package in Yakkety:
  Fix Released

Bug description:
  Ubuntu Core 16 images using cloud-init fail to function when the
  DataSource is over the network (Like OpenStack) as networking is not
  yet available when cloud-init.service runs.

  cloud-init service unit deps look like this:

  [Unit]
  Description=Initial cloud-init job (metadata service crawler)
  DefaultDependencies=no
  Wants=cloud-init-local.service
  Wants=local-fs.target
  Wants=sshd-keygen.service
  Wants=sshd.service
  After=cloud-init-local.service
  After=networking.service
  Requires=networking.service
  Before=basic.target
  Before=dbus.socket
  Before=network-online.target
  Before=sshd-keygen.service
  Before=sshd.service
  Before=systemd-user-sessions.service
  Conflicts=shutdown.target

  Here's networkd unit deps:

  [Unit]
  Description=Network Service
  Documentation=man:systemd-networkd.service(8)
  ConditionCapability=CAP_NET_ADMIN
  DefaultDependencies=no
  # dbus.service can be dropped once on kdbus, and systemd-udevd.service can be
  # dropped once tuntap is moved to netlink
  After=systemd-udevd.service dbus.service network-pre.target 
systemd-sysusers.service systemd-sysctl.service
  Before=network.target multi-user.target shutdown.target
  Conflicts=shutdown.target
  Wants=network.target

  # On kdbus systems we pull in the busname explicitly, because it
  # carries policy that allows the daemon to acquire its name.
  Wants=org.freedesktop.network1.busname
  After=org.freedesktop.network1.busname

  And a critical-chain output:

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd
  Failed to get ID: Unit name systemd-networkd is not valid.
  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.

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd.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.

  systemd-networkd.service +440ms
  └─dbus.service @11.461s
    └─basic.target @11.403s
  └─sockets.target @11.401s
    └─dbus.socket @11.398s
  └─cloud-init.service @10.127s +1.266s
    └─networking.service @9.305s +799ms
  └─network-pre.target @9.295s
    └─cloud-init-local.service @3.822s +5.469s
  └─local-fs.target @3.813s
    └─run-cgmanager-fs.mount @12.687s
  └─local-fs-pre.target @1.393s
    └─systemd-tmpfiles-setup-dev.service @1.116s +195ms
  └─kmod-static-nodes.service @887ms +193ms
    └─system.slice @783ms
  └─-.slice @721ms

  cloud-init would need networkd to run at or before
  'networking.service' so it can raise networking to then find and use
  network-based datasources.

  # grep systemd /usr/share/snappy/dpkg.list
  ii  libnss-resolve:amd64  229-4ubuntu11   
 amd64nss module to resolve names via systemd-resolved
  ii  libpam-systemd:amd64  229-4ubuntu11   
 amd64system and service manager - PAM module
  ii  libsystemd0:amd64 229-4ubuntu11   
 amd64systemd utility library
  ii  systemd   229-4ubuntu11   
 amd64system and service manager
  ii  systemd-sysv  229-4ubuntu11   
 amd64system and service manager - SysV links

  # grep cloud-init /usr/share/snappy/dpkg.list
  ii  cloud-init
0.7.8-201610260005-gf7a5756-0ubuntu1~trunk~ubuntu16.04.1 all  Init 
scripts for cloud instances

  SRU INFORMATION FOR systemd
  ===
  Fix: For xenial it is sufficient to drop systemd-networkd's 
After=dbus.service (https://github.com/systemd/systemd/commit/5f004d1e32) and 
(for xenial only) drop the useless org.freedesktop.network1.busname unit (which 
is always "condition failed" as there is no kdbus, but it moves 
systemd-network.service

[Group.of.nepali.translators] [Bug 1639930] Re: initramfs network configuration ignored if only ip6= on kernel command line

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** 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/1639930

Title:
  initramfs network configuration ignored if only ip6= on kernel command
  line

Status in cloud-init:
  Fix Released
Status in MAAS:
  New
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:
  In Progress

Bug description:
  === Begin SRU Template ===
  [Impact]
  On a system booted with both ip6= and ip= on the kernel command line
  cloud-init will raise an exception and fail to process user-data and
  have its normal affect on boot.

  That is because cloud-init previously raised an exception when more
  than one file in /run/net*.conf declared the same DEVICE.  Changes to
  isc-dhcp and initramfs-tools have changed their behavior and cloud-init
  has to adjust to allow DEVICE6= and DEVICE= in separate files.

  [Test Case]
  Boot a system on a network with both ipv4 and ipv6 dhcp servers,
  and pass kernel command line with:
    ip=dhcp ip6=dhcp

  [Regression Potential]
  Regression seems unlikely as this is relaxing a check.  Where previously
  an exception would have been raised, cloud-init will now go on.

  So it seems most likely, something that didn't work before (due to raised
  exception) would now still not work, but with failures.  That is not
  expected, but that would likely be where regressions were found.

  === End SRU Template ===

  In changes made under bug 1621615 (specifically a1cdebdea), we now
  expect that there may be a 'ip6=' argument on the kernel command line.
  The changes made did not test the case where there is 'ip6=' and no
  'ip='.

  The code currently will return with no network configuration found if
  there is only ip6=...

  Related bugs:
   * bug 1621615: network not configured when ipv6 netbooted into cloud-init
   * bug 1621507: initramfs-tools configure_networking() fails to dhcp IPv6 
addresses
   * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1639930/+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 1629797] Re: resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** 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/1629797

Title:
  resolve service in nsswitch.conf adds 25 seconds to failed lookups
  before systemd-resolved is up

Status in cloud-init:
  Fix Released
Status in D-Bus:
  Unknown
Status in cloud-init package in Ubuntu:
  Fix Released
Status in dbus package in Ubuntu:
  Won't Fix
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact] 
  In cases where cloud-init used dns during early boot and system was
  configured in nsswitch.conf to use systemd-resolvd, the system would
  timeout on dns attempts making system boot terribly slow.

  [Test Case]
  Boot a system on GCE.
  check for WARN in /var/log/messages
  check that time to boot is reasonable (<30 seconds).  In failure case the
  times would be minutes.

  [Regression Potential]
  Changing order in boot can be dangerous.  There is real chance for 
  regression here, but it should be fairly small as xenial does not include
  systemd-resolved usage.  This was first noticed on yakkety where it did.

  [Other Info]
  It seems useful to SRU this in the event that systemd-resolvd is used
  on 16.04 or the case where user upgrades components (admittedly small use
  case).

  === End SRU Template ===


  
  During boot, cloud-init does DNS resolution checks to if particular metadata 
services are available (in order to determine which cloud it is running on).  
These checks happen before systemd-resolved is up[0] and if they resolve 
unsuccessfully they take 25 seconds to complete.

  This has substantial impact on boot time in all contexts, because
  cloud-init attempts to resolve three known-invalid addresses ("does-
  not-exist.example.com.", "example.invalid." and a random string) to
  enable it to detect when it's running in an environment where a DNS
  server will always return some sort of redirect.  As such, we're
  talking a minimum impact of 75 seconds in all environments.  This
  increases when cloud-init is configured to check for multiple
  environments.

  This means that yakkety is consistently taking 2-3 minutes to boot on
  EC2 and GCE, compared to the ~30 seconds of the first boot and ~10
  seconds thereafter in xenial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1629797/+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 1642679] Re: The OpenStack network_config.json implementation fails on Hyper-V compute nodes

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   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/1642679

Title:
  The OpenStack network_config.json implementation fails on Hyper-V
  compute nodes

Status in cloud-init:
  Fix Released
Status in OpenStack Compute (nova):
  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:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact]
  When a config drive provides network_data.json on Azure OpenStack,
  cloud-init will fail to configure networking.

  Console log and /var/log/cloud-init.log will show:
   ValueError: Unknown network_data link type: hyperv

  This woudl also occur when the type of the network device as declared
  to cloud-init was 'hw_veb', 'hyperv', or 'vhostuser'.

  [Test Case]
  Launch an instance with config drive on hyperv cloud.

  [Regression Potential]
  Low to none.   cloud-init is relaxing requirements and will accept things
  now that it previously complained were invalid.
  === End SRU Template ===

  We have discovered an issue when booting Xenial instances on OpenStack
  environments (Liberty or newer) and Hyper-V compute nodes using config
  drive as metadata source.

  When applying the network_config.json, cloud-init fails with this error:
  http://paste.openstack.org/show/RvHZJqn48JBb0TO9QznL/

  The fix would be to add 'hyperv' as a link type here:
  /usr/lib/python3/dist-packages/cloudinit/sources/helpers/openstack.py, line 
587

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1642679/+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 1643990] Re: cloud-init-local.service messages not written to /var/log/cloud-init.log in systemd

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** 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/1643990

Title:
cloud-init-local.service messages not written to /var/log/cloud-
init.log in systemd

Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Triaged
Status in cloud-init source package in Yakkety:
In Progress

Bug description:
=== Begin SRU Template ===
[Impact]
Cloud-init's logging is inconsistent due to availability of syslog during
boot.

Cloud-init logs to /var/log/cloud-init.log by default. It does this in
a way that was originally designed to prefer to use syslog if it was
available, and then fall back to writing directly to that file.

Over time this has been shown to be problematic.
a.) it relied on syslog during boot, and on some distros it wasn't
present.
b.) sometimes it would not be available during cloud-init-local.service
and then would be during cloud-init.service. The result was that
the log would have two different time stamp formats (one written
by rsyslog and one by python logging).
c.) if rsyslog was used, micro seconds were not included in the log.
d.) since the move to systemd, there has even been times when cloud-init's
attempt to determine if syslog was available would false-positive.
that would result logging not being written to the file at all.

Over all, the complexity was just not found to worth the benefit.

[Test Case]
* Launch an instance.
* Look at /var/log/cloud-init.log.
on start, the cloud-int process logs a message like
'Cloud-init v 0.7.8 running'
Look at those messages specifically. In the example here (lxd), neither
cloud-init.service or cloud-init-local.service successfully logged at all.

# grep Cloud-init /var/log/cloud-init.log
Dec 2 18:06:56 y2 [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.8
running 'modules:config' at Fri, 02 Dec 2016 18:06:56 +. Up 5.0 seconds.
Dec 2 18:06:58 y2 [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.8
running 'modules:final' at Fri, 02 Dec 2016 18:06:58 +. Up 7.0 seconds.
Dec 2 18:06:58 y2 [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.8
finished at Fri, 02 Dec 2016 18:06:58 +. Datasource DataSourceNoCloud
[seed=/var/lib/cloud/seed/nocloud-net][dsmode=net]. Up 7.0 seconds

* update to proposed, cleanup reboot
# enable propose and update
# cleanup

sudo rm -Rf /var/log/cloud-init* /var/lib/cloud/
sudo reboot

* login again and look.

This time, all messages will have the format:
2016-12-02 17:58:43,175 - util.py[DEBUG]: Cloud-init v. 0.7.8 running
'init-local' at Fri, 02 Dec 2016 17:58:43 +. Up 13.73 seconds.

And you will have one for each 'init-local', 'init', 'modules:config' and
modules:final.

[Regression Potential]
Users relying on cloud-init writing entries to syslog will lose that.

[Other Info]

=== End SRU Template ===

output of cloud-init-local.service can get lost in systemd.
The result is that there is no output in /var/log/cloud-init.log from
cloud-init-local.service.

There is some information in
https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/301729
about how this occurrs and how it used to work.
copying part of that here:

Cloud-init's logging basically employed a "try syslog and fallback to direct
log to file".
The proposed "just log to a file" is definitely dramatically simpler and
advantageous in some cases.

The way the "try syslog and fallback" works (or worked) on Ubuntu up
until systemd was:

a.) cloud-init init --local
1. read logging config,
2. attempt to log to syslog ([ *log_base, *log_syslog ])
3. that fail, so it log to file directly

b.) cloud-init init
1.) rsyslog would have /dev/log up functional at this point
2.) cloud-init logging config read and ends up logging to syslog

Systemd changed some things in teh way /dev/log was handled, and the
above no longer worked well.

Additionally, cloud-init installs a file
/etc/rsyslog.d/21-cloudinit.conf which tells rsyslog to redirect
messages generated by cloud-init to /var/log/cloud-init.log

The value of doing this in this way was that we use syslog, so if the
user had configured the system to log remotely, cloud-init's logs
would go to that remote system as they desired.

If we directly log to a file, then cloud-init's log messages will not
without further configuration go to syslog.

One other thing to be aware of is that cloud-init can itself configure
rsyslog through cloudinit/config/cc_rsyslog.py . So, the user could

[Group.of.nepali.translators] [Bug 1648380] Re: cloud-init fails to find CloudSigma datasource with cloud-init 0.7.8-1-g3705bb5-0ubuntu1

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Importance: Undecided => Medium

** Changed in: cloud-init
   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/1648380

Title:
  cloud-init fails to find CloudSigma datasource with cloud-init
  0.7.8-1-g3705bb5-0ubuntu1

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:
  Confirmed

Bug description:
  [SRU justification]
  Without this fix, images built with cloud-init 0.7.8-1-g3705bb5-0ubuntu1  and 
later will not correctly boot and become unreachable

  [Impact]
  Some cloud images built with this version of cloud-init may become unusable

  [Fix]
  Reinstate the second element of the datasources list as a tuple instead of a 
string.

  [Test Case]
  This test must be done on CloudSigma to complete correctly :

  Build cloud image with only the CloudSigma datasource using cloud-init 
version 0.7.8-1-g3705bb5-0ubuntu1 or later
  Launch an instance with this image
  The instance will boot but will not be accessible through ssh

  With this fix,the instance will complete its boot sequence and be
  accessible through ssh

  [Regression]
  None expected, the second element was a tuple in previous versions of the 
CloudSigma datasource

  [Description of the problem]
  The issue materialized itself on cloud instances launched with such images 
that became unreachable through SSH with the following message:

  "Connection closed by {IP} port 22"

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1648380/+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 1642062] Re: cloud-init-local.service should be RequiresMountsFor=/var/lib/cloud rather than /var/lib

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** 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/1642062

Title:
  cloud-init-local.service should be RequiresMountsFor=/var/lib/cloud
  rather than /var/lib

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:
  New

Bug description:
  cloud-init-local.service writes to /var/lib/cloud/ and is more correct
  to have that listed here than /var/lib.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1642062/+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

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9

** 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/1582323

Title:
  Commissioning fails when competing cloud metadata resides on disk

Status in cloud-init:
  Fix Released
Status in MAAS:
  Fix Committed
Status in MAAS 2.1 series:
  Fix Committed
Status in MAAS trunk series:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in cloud-init source package in Xenial:
  Confirmed

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 1644043] Re: Read Kernel Config tests missing MAC Address

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** 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/1644043

Title:
  Read Kernel Config tests missing MAC 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 Yakkety:
  In Progress

Bug description:
  http://pad.lv/1644043
  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1644043
  
  === Begin SRU Template ===
  [Impact] 
  Unit tests would fail, causing build failure.

  [Test Case]
  Run cloud-init tests a system with a network device named 'eth0'
  Building cloud-init runs the unit tests, so even just building on
  such a system is sufficient.

  lxc provides such an environment.

  Generally, the build worked, so unit tests passed.

  [Regression Potential] 
  None: unit test changes only.

  === End SRU Template ===

  
  Unittests are broken [1] preventing cloud-init from building currently. The 
issue is the kernel config tests are looking for a MAC address that is not 
there.

  [1] https://jenkins.ubuntu.com/server/job/cloud-init-integration-
  lts/35/console

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1644043/+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 1647708] Re: Ephemeral disk on xenial is not mounted at boot

2016-12-23 Thread Scott Moser

This is fixed in cloud-init 0.7.9.

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Importance: Undecided => High

** Changed in: cloud-init
   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/1647708

Title:
  Ephemeral disk on xenial is not mounted at boot

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:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact]
  An ephemeral disk will not correctly be mounted on /mnt.
  This affects Azure and other instances where an ephemeral device is
  mounted by default on /mnt.  It is recreated in Azure and on OpenStack.

  This can be mitigated by either:
   1.) mount -a
   2.) reboot

  [Test Case]
  In a correctly functioning image on OpenStack or Azure, you should be
  able to:

  1.) Launch an instance
  2.) ssh into instance and look around
 $ awk '$2 == "/mnt" { print $0 }' /etc/fstab
 /dev/vdb /mnt  auto  
defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig  0  2
 $ awk '$2 == "/mnt" { print $0 }' /proc/mounts
  /dev/vdb /mnt vfat 
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro
 0 0

 $ df -h /mnt
 Filesystem  Size  Used Avail Use% Mounted on
 /dev/vdb 40G   32K   40G   1% /mnt

  To check that this is functional with -proposed, after you've seen it
  failed

  3.) enable -proposed and apt-get install cloud-init
  4.) clean up and reboot as if fresh:
  sudo rm -Rf /var/lib/cloud /var/log/cloud-init
  sudo sed -i '/cloudconfig/d' /etc/fstab
  sudo reboot

  [Regression Potential]
  This is a regression caused by bug 1611074, so in addition to the above
  test case, we should go through the test cases shown there to see that
  those also work.
  === End SRU Template ===


  When I boot the latest xenial Azure image (containing cloud-init
  0.7.8-49-g9e904bb-0ubuntu1~16.04.1), the ephemeral disk does not end
  up mounted (though it is formatted appropriately).  Restarting the
  mnt.mount service does mount it, which suggests there is an issue in
  the ordering of the services at boot.

  $ mount | grep mnt
  $ sudo systemctl status mnt.mount
  ● mnt.mount - /mnt
     Loaded: loaded (/etc/fstab; bad; vendor preset: enabled)
     Active: inactive (dead)
  Where: /mnt
   What: /dev/disk/cloud/azure_resource-part1
   Docs: man:fstab(5)
     man:systemd-fstab-generator(8)
  $ sudo journalctl -u mnt.mount
  -- No entries --
  $ cat /etc/fstab
  # CLOUD_IMG: This file was created/modified by the Cloud Image build process
  UUID=6a8554fa-8e1d-4916-ba03-4ca3837feb34 /ext4   
defaults,discard0 0
  /dev/disk/cloud/azure_resource-part1  /mntauto
defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig   
0   2
  $ sudo systemctl restart mnt.mount
  $ mount | grep mnt
  /dev/sdb1 on /mnt type ext4 (rw,relatime,data=ordered)
  $ ls /mnt/
  lost+found
  $ sudo systemctl status mnt.mount
  ● mnt.mount - /mnt
     Loaded: loaded (/etc/fstab; bad; vendor preset: enabled)
     Active: active (mounted) since Tue 2016-12-06 12:49:06 UTC; 6s ago
  Where: /mnt
   What: /dev/sdb1
   Docs: man:fstab(5)
     man:systemd-fstab-generator(8)
    Process: 1916 ExecMount=/bin/mount /dev/disk/cloud/azure_resource-part1 
/mnt -o defaults,x-systemd.requires=cloud-init.service,comment=cloudconfig 
(code=exited, status=0/SUCCESS)
  Tasks: 0
     Memory: 88.0K
    CPU: 15ms

  Dec 06 12:49:06 xenial-161206-1345 systemd[1]: Mounting /mnt...
  Dec 06 12:49:06 xenial-161206-1345 systemd[1]: Mounted /mnt.

  Related bugs:
   * bug 1611074: Reformatting of ephemeral drive fails on resize of Azure VM
   * bug 1642383: Unable to configure swap space on ephemeral disk in Azure

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1647708/+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 1651602] Re: [2.1.1] MAAS has nvme0n1 set as boot disk, curtin fails

[Group.of.nepali.translators] [Bug 1582323] Re: Commissioning fails when competing cloud metadata resides on disk

[Group.of.nepali.translators] [Bug 1611074] Re: Reformatting of ephemeral drive fails on resize of Azure VM

[Group.of.nepali.translators] [Bug 1623868] Re: cloud-final.service does not run due to dependency cycle

[Group.of.nepali.translators] [Bug 1354694] Re: useradd crashes if group list contains whitespace on Fedora

[Group.of.nepali.translators] [Bug 1354694] Re: useradd crashes if group list contains whitespace on Fedora

[Group.of.nepali.translators] [Bug 1354694] Re: useradd crashes if group list contains whitespace on Fedora

[Group.of.nepali.translators] [Bug 1460715] Re: MBR disk setup fails because sfdisk no longer accepts M as a valid unit

[Group.of.nepali.translators] [Bug 1626243] Re: Cloud-init fails to write ext4 filesystem to Azure Ephemeral Drive

[Group.of.nepali.translators] [Bug 1621615] Re: network not configured when ipv6 netbooted into cloud-init

[Group.of.nepali.translators] [Bug 1628337] Re: cloud-init tries to install NTP before even configuring the archives

[Group.of.nepali.translators] [Bug 1635350] Re: unit tests fail as non-root on maas deployed system

[Group.of.nepali.translators] [Bug 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)

[Group.of.nepali.translators] [Bug 1639930] Re: initramfs network configuration ignored if only ip6= on kernel command line

[Group.of.nepali.translators] [Bug 1629797] Re: resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up

[Group.of.nepali.translators] [Bug 1642679] Re: The OpenStack network_config.json implementation fails on Hyper-V compute nodes

[Group.of.nepali.translators] [Bug 1643990] Re: cloud-init-local.service messages not written to /var/log/cloud-init.log in systemd

[Group.of.nepali.translators] [Bug 1648380] Re: cloud-init fails to find CloudSigma datasource with cloud-init 0.7.8-1-g3705bb5-0ubuntu1

[Group.of.nepali.translators] [Bug 1642062] Re: cloud-init-local.service should be RequiresMountsFor=/var/lib/cloud rather than /var/lib

[Group.of.nepali.translators] [Bug 1582323] Re: Commissioning fails when competing cloud metadata resides on disk

[Group.of.nepali.translators] [Bug 1644043] Re: Read Kernel Config tests missing MAC Address

[Group.of.nepali.translators] [Bug 1647708] Re: Ephemeral disk on xenial is not mounted at boot

22 matches

Site Navigation

Mail list logo

Footer information