[Group.of.nepali.translators] [Bug 1717477] Re: cloud-init generates ordering cycle via After=cloud-init in systemd-fsck

2017-10-05 Thread Launchpad Bug Tracker
This bug was fixed in the package cloud-init -
0.7.9-233-ge586fe35-0ubuntu1~16.04.2

---
cloud-init (0.7.9-233-ge586fe35-0ubuntu1~16.04.2) xenial-proposed; 
urgency=medium

  * cherry-pick a2f8ce9c: Do not provide systemd-fsck drop-in which
could cause systemd ordering loops (LP: #1717477).

 -- Scott Moser   Fri, 15 Sep 2017 15:23:38 -0400

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

Title:
  cloud-init generates ordering cycle via After=cloud-init in systemd-
  fsck

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/1717477
  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1717477

  === Begin SRU Template ===
  [Impact]
  Cloud-init's inclusion of a systemd drop-in file
/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
  Caused a regression on systems that had entries in /etc/fstab
  that were not authored by cloud-init (specifically that did not have
  something like 'x-systemd.requires=cloud-init.service' in their
  filesystem options.

  [Test Case]
  The test can be done on any cloud that has space to put a non-root
  filesystem.

  a.) launch instance
  b.) upgrade to cloud-init to -updates pocket
  c.) create a filesystem and put it in /etc/fstab
  bdev="/dev/sdb1"
  mkdir -p /mnt
  mkfs.ext4 -F "$bdev"
  echo "$bdev /mnt auto defaults 0 2" >> /etc/fstab

  reboot
  d.) see mention of 'ordering cycle' in journal

  $ journalctl -o short-precise  | grep -i ordering.cycle
  Sep 15 14:08:48.331033 xenial-20170911-174122 systemd[1]: 
local-fs.target: Found ordering cycle on local-fs.target/start
  Sep 15 14:08:48.331097 xenial-20170911-174122 systemd[1]: 
local-fs.target: Breaking ordering cycle by deleting job mnt.mount/start
  Sep 15 14:08:48.331108 xenial-20170911-174122 systemd[1]: mnt.mount: Job 
mnt.mount/start deleted to break ordering cycle starting with 
local-fs.target/start

  e.) upgrade to proposed
  f.) reboot
  g.) expect no mention of ordering cycle as seen in 'd'
  $ journalctl -o short-precise  | grep -i ordering.cycle || echo "no 
cycles"
  no cycles

  [Regression Potential]
  This change will mean that bug 1691489 is present again.
  That bug is much less severe and affects a much smaller set of users.

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

  === End SRU Template ===


  We're running several machines with

    cloud-init_0.7.9-153-g16a7302f-0ubuntu1~16.04.2

  without problems.

  Just upgraded all machines to

    cloud-init_0.7.9-233-ge586fe35-0ubuntu1~16.04.1

  and rebooted them all.

  All machines report ordering cycles in their dmesg, resulting in systemd 
breaking the
  loop by NOT starting some important services, e.g. mouting local filesystems:

  Sep 14 15:43:52.487945 noname systemd[1]: networking.service: Found ordering 
cycle on networking.service/start
  Sep 14 15:43:52.487952 noname systemd[1]: networking.service: Found 
dependency on local-fs.target/start
  Sep 14 15:43:52.487960 noname systemd[1]: networking.service: Found 
dependency on home.mount/start
  Sep 14 15:43:52.487968 noname systemd[1]: networking.service: Found 
dependency on systemd-fsck@dev-disk-by\x2dlabel-Home.service/start
  Sep 14 15:43:52.487975 noname systemd[1]: networking.service: Found 
dependency on cloud-init.service/start
  Sep 14 15:43:52.487982 noname systemd[1]: networking.service: Found 
dependency on networking.service/start
  Sep 14 15:43:52.488297 noname systemd[1]: networking.service: Breaking 
ordering cycle by deleting job local-fs.target/start
  Sep 14 15:43:52.488306 noname systemd[1]: local-fs.target: Job 
local-fs.target/start deleted to break ordering cycle starting with 
networking.service/start

  % cat /etc/fstab
  LABEL=cloudimg-rootfs /ext4   defaults,discard0 1
  LABEL=Home/homexfsdefaults,logbufs=8  0 2

  In this case /home isn't mounted as a result of systemd breaking the
  loop, resulting in services depending on /home not being started.

  1. Tell us your cloud provider

  AWS

  2. dpkg-query -W -f='${Version}' cloud-init

  0.7.9-233-ge586fe35-0ubuntu1~16.04.1

  3. Any appropriate cloud-init configuration you can provide us

  Nothing special - worked with 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 on
  all machines without hassle.

  The problem is this change:

  diff -uaNr 153/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf 

[Group.of.nepali.translators] [Bug 1717477] Re: cloud-init generates ordering cycle via After=cloud-init in systemd-fsck

2017-10-05 Thread Launchpad Bug Tracker
This bug was fixed in the package cloud-init -
0.7.9-233-ge586fe35-0ubuntu1~17.04.2

---
cloud-init (0.7.9-233-ge586fe35-0ubuntu1~17.04.2) zesty; urgency=medium

  * cherry-pick a2f8ce9c: Do not provide systemd-fsck drop-in which
could cause systemd ordering cycles (LP: #1717477).

 -- Scott Moser   Fri, 15 Sep 2017 15:30:01 -0400

** Changed in: cloud-init (Ubuntu Zesty)
   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/1717477

Title:
  cloud-init generates ordering cycle via After=cloud-init in systemd-
  fsck

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

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

  === Begin SRU Template ===
  [Impact]
  Cloud-init's inclusion of a systemd drop-in file
/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
  Caused a regression on systems that had entries in /etc/fstab
  that were not authored by cloud-init (specifically that did not have
  something like 'x-systemd.requires=cloud-init.service' in their
  filesystem options.

  [Test Case]
  The test can be done on any cloud that has space to put a non-root
  filesystem.

  a.) launch instance
  b.) upgrade to cloud-init to -updates pocket
  c.) create a filesystem and put it in /etc/fstab
  bdev="/dev/sdb1"
  mkdir -p /mnt
  mkfs.ext4 -F "$bdev"
  echo "$bdev /mnt auto defaults 0 2" >> /etc/fstab

  reboot
  d.) see mention of 'ordering cycle' in journal

  $ journalctl -o short-precise  | grep -i ordering.cycle
  Sep 15 14:08:48.331033 xenial-20170911-174122 systemd[1]: 
local-fs.target: Found ordering cycle on local-fs.target/start
  Sep 15 14:08:48.331097 xenial-20170911-174122 systemd[1]: 
local-fs.target: Breaking ordering cycle by deleting job mnt.mount/start
  Sep 15 14:08:48.331108 xenial-20170911-174122 systemd[1]: mnt.mount: Job 
mnt.mount/start deleted to break ordering cycle starting with 
local-fs.target/start

  e.) upgrade to proposed
  f.) reboot
  g.) expect no mention of ordering cycle as seen in 'd'
  $ journalctl -o short-precise  | grep -i ordering.cycle || echo "no 
cycles"
  no cycles

  [Regression Potential]
  This change will mean that bug 1691489 is present again.
  That bug is much less severe and affects a much smaller set of users.

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

  === End SRU Template ===


  We're running several machines with

    cloud-init_0.7.9-153-g16a7302f-0ubuntu1~16.04.2

  without problems.

  Just upgraded all machines to

    cloud-init_0.7.9-233-ge586fe35-0ubuntu1~16.04.1

  and rebooted them all.

  All machines report ordering cycles in their dmesg, resulting in systemd 
breaking the
  loop by NOT starting some important services, e.g. mouting local filesystems:

  Sep 14 15:43:52.487945 noname systemd[1]: networking.service: Found ordering 
cycle on networking.service/start
  Sep 14 15:43:52.487952 noname systemd[1]: networking.service: Found 
dependency on local-fs.target/start
  Sep 14 15:43:52.487960 noname systemd[1]: networking.service: Found 
dependency on home.mount/start
  Sep 14 15:43:52.487968 noname systemd[1]: networking.service: Found 
dependency on systemd-fsck@dev-disk-by\x2dlabel-Home.service/start
  Sep 14 15:43:52.487975 noname systemd[1]: networking.service: Found 
dependency on cloud-init.service/start
  Sep 14 15:43:52.487982 noname systemd[1]: networking.service: Found 
dependency on networking.service/start
  Sep 14 15:43:52.488297 noname systemd[1]: networking.service: Breaking 
ordering cycle by deleting job local-fs.target/start
  Sep 14 15:43:52.488306 noname systemd[1]: local-fs.target: Job 
local-fs.target/start deleted to break ordering cycle starting with 
networking.service/start

  % cat /etc/fstab
  LABEL=cloudimg-rootfs /ext4   defaults,discard0 1
  LABEL=Home/homexfsdefaults,logbufs=8  0 2

  In this case /home isn't mounted as a result of systemd breaking the
  loop, resulting in services depending on /home not being started.

  1. Tell us your cloud provider

  AWS

  2. dpkg-query -W -f='${Version}' cloud-init

  0.7.9-233-ge586fe35-0ubuntu1~16.04.1

  3. Any appropriate cloud-init configuration you can provide us

  Nothing special - worked with 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 on
  all machines without hassle.

  The problem is this change:

  diff -uaNr 153/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf 

[Group.of.nepali.translators] [Bug 1717477] Re: cloud-init generates ordering cycle via After=cloud-init in systemd-fsck

2017-09-22 Thread Scott Moser
This bug is believed to be fixed in cloud-init 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: 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/1717477

Title:
  cloud-init generates ordering cycle via After=cloud-init in systemd-
  fsck

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

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

  === Begin SRU Template ===
  [Impact]
  Cloud-init's inclusion of a systemd drop-in file
/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
  Caused a regression on systems that had entries in /etc/fstab
  that were not authored by cloud-init (specifically that did not have
  something like 'x-systemd.requires=cloud-init.service' in their
  filesystem options.

  [Test Case]
  The test can be done on any cloud that has space to put a non-root
  filesystem.

  a.) launch instance
  b.) upgrade to cloud-init to -updates pocket
  c.) create a filesystem and put it in /etc/fstab
  bdev="/dev/sdb1"
  mkdir -p /mnt
  mkfs.ext4 -F "$bdev"
  echo "$bdev /mnt auto defaults 0 2" >> /etc/fstab

  reboot
  d.) see mention of 'ordering cycle' in journal

  $ journalctl -o short-precise  | grep -i ordering.cycle
  Sep 15 14:08:48.331033 xenial-20170911-174122 systemd[1]: 
local-fs.target: Found ordering cycle on local-fs.target/start
  Sep 15 14:08:48.331097 xenial-20170911-174122 systemd[1]: 
local-fs.target: Breaking ordering cycle by deleting job mnt.mount/start
  Sep 15 14:08:48.331108 xenial-20170911-174122 systemd[1]: mnt.mount: Job 
mnt.mount/start deleted to break ordering cycle starting with 
local-fs.target/start

  e.) upgrade to proposed
  f.) reboot
  g.) expect no mention of ordering cycle as seen in 'd'
  $ journalctl -o short-precise  | grep -i ordering.cycle || echo "no 
cycles"
  no cycles

  [Regression Potential]
  This change will mean that bug 1691489 is present again.
  That bug is much less severe and affects a much smaller set of users.

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

  === End SRU Template ===


  We're running several machines with

    cloud-init_0.7.9-153-g16a7302f-0ubuntu1~16.04.2

  without problems.

  Just upgraded all machines to

    cloud-init_0.7.9-233-ge586fe35-0ubuntu1~16.04.1

  and rebooted them all.

  All machines report ordering cycles in their dmesg, resulting in systemd 
breaking the
  loop by NOT starting some important services, e.g. mouting local filesystems:

  Sep 14 15:43:52.487945 noname systemd[1]: networking.service: Found ordering 
cycle on networking.service/start
  Sep 14 15:43:52.487952 noname systemd[1]: networking.service: Found 
dependency on local-fs.target/start
  Sep 14 15:43:52.487960 noname systemd[1]: networking.service: Found 
dependency on home.mount/start
  Sep 14 15:43:52.487968 noname systemd[1]: networking.service: Found 
dependency on systemd-fsck@dev-disk-by\x2dlabel-Home.service/start
  Sep 14 15:43:52.487975 noname systemd[1]: networking.service: Found 
dependency on cloud-init.service/start
  Sep 14 15:43:52.487982 noname systemd[1]: networking.service: Found 
dependency on networking.service/start
  Sep 14 15:43:52.488297 noname systemd[1]: networking.service: Breaking 
ordering cycle by deleting job local-fs.target/start
  Sep 14 15:43:52.488306 noname systemd[1]: local-fs.target: Job 
local-fs.target/start deleted to break ordering cycle starting with 
networking.service/start

  % cat /etc/fstab
  LABEL=cloudimg-rootfs /ext4   defaults,discard0 1
  LABEL=Home/homexfsdefaults,logbufs=8  0 2

  In this case /home isn't mounted as a result of systemd breaking the
  loop, resulting in services depending on /home not being started.

  1. Tell us your cloud provider

  AWS

  2. dpkg-query -W -f='${Version}' cloud-init

  0.7.9-233-ge586fe35-0ubuntu1~16.04.1

  3. Any appropriate cloud-init configuration you can provide us

  Nothing special - worked with 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 on
  all machines without hassle.

  The problem is this change:

  diff -uaNr 153/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf 
233/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
  --- 153/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
1970-01-01 01:00:00.0 +0100
  +++ 233/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
2017-07-28 

[Group.of.nepali.translators] [Bug 1717477] Re: cloud-init generates ordering cycle via After=cloud-init in systemd-fsck

2017-09-15 Thread Launchpad Bug Tracker
This bug was fixed in the package cloud-init - 0.7.9-280-ge626966e-
0ubuntu1

---
cloud-init (0.7.9-280-ge626966e-0ubuntu1) artful; urgency=medium

  * debian/rules: install rsyslog file with 0644 mode instead of 0755.
  * debian/rules, debian/apport-launcher.py: add an apport hook. (LP: #1607345)
  * New upstream snapshot.
- cmdline: add collect-logs subcommand. [Chad Smith] (LP: #1607345)
- CloudStack: consider dhclient lease files named with a hyphen.
  (LP: #1717147)
- resizefs: Drop check for read-only device file, do not warn on
  overlayroot. [Chad Smith]
- Do not provide systemd-fsck drop-in which could cause ordering cycles.
  [Balint Reczey] (LP: #1717477)
- tests: Enable the NoCloud KVM platform [Joshua Powers]
- resizefs: pass mount point to xfs_growfs [Dusty Mabe]
- vmware: Enable nics before sending the SUCCESS event. [Sankar Tanguturi]
- cloud-config modules: honor distros definitions in each module
  [Chad Smith] (LP: #1715738, #1715690)
- chef: Add option to pin chef omnibus install version
  [Ethan Apodaca] (LP: #1462693)
- tests: execute: support command as string [Joshua Powers]
- schema and docs: Add jsonschema to resizefs and bootcmd modules
  [Chad Smith]
- tools: Add xkvm script, wrapper around qemu-system [Joshua Powers]
- vmware customization: return network config format
  [Sankar Tanguturi] (LP: #1675063)

 -- Scott Moser   Fri, 15 Sep 2017 16:09:07 -0400

** Changed in: cloud-init (Ubuntu Artful)
   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/1717477

Title:
  cloud-init generates ordering cycle via After=cloud-init in systemd-
  fsck

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

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

  === Begin SRU Template ===
  [Impact]
  Cloud-init's inclusion of a systemd drop-in file
/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
  Caused a regression on systems that had entries in /etc/fstab
  that were not authored by cloud-init (specifically that did not have
  something like 'x-systemd.requires=cloud-init.service' in their
  filesystem options.

  [Test Case]
  The test can be done on any cloud that has space to put a non-root
  filesystem.

  a.) launch instance
  b.) upgrade to cloud-init to -updates pocket
  c.) create a filesystem and put it in /etc/fstab
  bdev="/dev/sdb1"
  mkdir -p /mnt
  mkfs.ext4 -F "$bdev"
  echo "$bdev /mnt auto defaults 0 2" >> /etc/fstab

  reboot
  d.) see mention of 'ordering cycle' in journal

  $ journalctl -o short-precise  | grep -i ordering.cycle
  Sep 15 14:08:48.331033 xenial-20170911-174122 systemd[1]: 
local-fs.target: Found ordering cycle on local-fs.target/start
  Sep 15 14:08:48.331097 xenial-20170911-174122 systemd[1]: 
local-fs.target: Breaking ordering cycle by deleting job mnt.mount/start
  Sep 15 14:08:48.331108 xenial-20170911-174122 systemd[1]: mnt.mount: Job 
mnt.mount/start deleted to break ordering cycle starting with 
local-fs.target/start

  e.) upgrade to proposed
  f.) reboot
  g.) expect no mention of ordering cycle as seen in 'd'
  $ journalctl -o short-precise  | grep -i ordering.cycle || echo "no 
cycles"
  no cycles

  [Regression Potential]
  This change will mean that bug 1691489 is present again.
  That bug is much less severe and affects a much smaller set of users.

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

  === End SRU Template ===


  We're running several machines with

    cloud-init_0.7.9-153-g16a7302f-0ubuntu1~16.04.2

  without problems.

  Just upgraded all machines to

    cloud-init_0.7.9-233-ge586fe35-0ubuntu1~16.04.1

  and rebooted them all.

  All machines report ordering cycles in their dmesg, resulting in systemd 
breaking the
  loop by NOT starting some important services, e.g. mouting local filesystems:

  Sep 14 15:43:52.487945 noname systemd[1]: networking.service: Found ordering 
cycle on networking.service/start
  Sep 14 15:43:52.487952 noname systemd[1]: networking.service: Found 
dependency on local-fs.target/start
  Sep 14 15:43:52.487960 noname systemd[1]: networking.service: Found 
dependency on home.mount/start
  Sep 14 15:43:52.487968 noname systemd[1]: networking.service: Found 
dependency on systemd-fsck@dev-disk-by\x2dlabel-Home.service/start
  Sep 14 15:43:52.487975 noname systemd[1]: networking.service: Found 
dependency on