[Touch-packages] [Bug 1918955] Re: SRU network: fix LXC_NET_NONE cleanup

[Scott Moser]

Marking this fix-released in focal as bug 1923232 was released to focal.
So this should be fixed in '1:4.0.6-0ubuntu1~20.04.1'.


** Changed in: lxc (Ubuntu Focal)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1918955

Title:
  SRU network: fix LXC_NET_NONE cleanup

Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Focal:
  Fix Released
Status in lxc source package in Groovy:
  Confirmed
Status in lxc source package in Hirsute:
  Fix Released

Bug description:
  Hi.  I'm using 20.04, and I need a fix for
  https://github.com/lxc/lxc/pull/3589

  I think my only options to get that via packaging are
   a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master
   b.) build my own.

  I don't love either of those options.

  Can we please get a SRU update to 20.04 of an lxc with that fix?

  The fix is not in 4.0.5, so I marked this as affecting Groovy
  (currently 1:4.0.4-0ubuntu3) without testing.

  Related bugs:
   * bug 1923232:  SRU of LXC 4.0.6 to focal (upstream bugfix release)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1707222] Re: usage of /tmp during boot is not safe due to systemd-tmpfiles-clean

[Scott Moser]

Norman,
Thanks for the comment. On first pass, it looks like you've diagnosed a failure 
correctly.
Please open another bug and add output of 'cloud-init collect-logs'.

thanks.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1707222

Title:
  usage of /tmp during boot is not safe due to systemd-tmpfiles-clean

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Won't Fix

Bug description:
  Earlier this week on Zesty on Azure I saw a cloud-init failure in its 
'mount_cb' function.
  That function esentially does:
   a.) make a tmp directory for a mount point
   b.)  mount some filesystem to that mount point
   c.) call a function
   d.) unmount the directory

  What I recall was that access to a file inside the mount point failed during 
'c'.
  This seems possible as systemd-tmpfiles-clean may be running at the same time 
as cloud-init (cloud-init.service in this example).

  
  It seems that this service basically inhibits *any* other service from using 
tmp files.
  It's ordering statements are only:

After=local-fs.target time-sync.target
Before=shutdown.target

  So while in most cases only services that run early in the boot
  process like cloud-init will be affected, any service could have its
  tmp files removed.  this service could take quite a long time to run
  if /tmp/ had been filled with lots of files in the previous boot.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1923232] Re: SRU of LXC 4.0.6 to focal (upstream bugfix release)

[Scott Moser]

lxc auto package tests show green for 4.0.6-0ubuntu1 other than i386,
which failed previously.

 * amd64: 
https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/l/lxc/20210525_040935_c4b64@/log.gz
 * arm64: 
https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/arm64/l/lxc/20210525_041453_b8cfc@/log.gz
 * armhf: (skipped) 
https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/armhf/l/lxc/20210525_035510_ea5c7@/log.gz
 * i386: (failed) 
https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/i386/l/lxc/20210525_035427_d5ede@/log.gz
 * ppc64el: 
https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/ppc64el/l/lxc/20210525_040452_d2faa@/log.gz
 * s390x: 
https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/s390x/l/lxc/20210525_040245_aea9b@/log.gz

Given the comments above from bdmurray and stgraber, and also the '[Test
Case]' section in the SRU template, I think that should qualify as
'verification-done'.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1923232

Title:
  SRU of LXC 4.0.6 to focal (upstream bugfix release)

Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Focal:
  Fix Committed

Bug description:
  LXC released 4.0.6 as a bugfix release with the following changelog:

  - Improve handling for compatibility architectures for seccomp
  - Harden seccomp notifier implementation
  - Rework parsing of /proc//mountinfo to handle kernel regression
  - Improve network device restoration
  - Significantly cleanup and harden config file parsing
  - Support new capabilities CAP_PERFORM, CAP_BPF, and 
CAP_CHECKPOINT_RESTORE
  - Harden containers started without CAP_NET_ADMIN
* New upstream bugfix release (4.0.5):
  - Support allocating PTS devices from within the container
  - Harden more path/mount handling logics
  - Rework LSM logic to limit initializer use
* Cherry-pick upstream fixes:
  - 0002-commands-fix-check-for-seccomp-notify-support.patch
  - 0003-configure-skip-libseccomp-tests-if-it-is-disabled.patch
  - 0004-conf-fix-containers-retaining-CAP_NET_ADMIN.patch
  - 0005-cgroups-fix-cgroup-mounting.patch
  - 0006-lsm-remove-obsolute-comment-about-constructor.patch
  - 0007-lxc_attach-include-rexec-conditionally.patch
  - 0008-tree-wide-fix-some-header-inclusions.patch
  - 0009-initutils-fix-missing-includes.patch
  - 0010-configure-support-static-binaries.patch
  - 0011-autotools-enable-static-builds-for-tools.patch
  - 0012-autotools-enable-static-builds-for-commands.patch
  - 0013-tree-wide-fix-compilation-with-Wstrict-prototypes-Wo.patch
  - 0014-config-update-ax_pthread.m4.patch
  - 0015-configure-add-AC_SYS_LARGEFILE-checking.patch
  - 0016-autotools-update-build.patch
  - 0017-file_utils-introduce-read_file_at.patch
  - 0018-string_utils-add-must_make_path_relative.patch
  - 0019-cgroups-coding-style-fixes.patch
  - 0020-cgroups-rework-cg_unified_init.patch
  - 0021-cgroups-detect-and-record-cgroup2-freezer-support.patch
  - 0022-criu-handle-cgroup2-freezer.patch
  - 0023-mkdir-p-proc-sys-on-container-startup.patch
  - 0024-conf-fix-coding-style.patch
  - 0025-conf-coding-style-fixes.patch
  - 0026-conf-move-proc-and-sys-mountpoint-creation-int-lxc_m.patch
  - 0027-attach-invert-child-parent-handling.patch
  - 0028-attach-use-__do_free-cleanup-macro-for-cwd.patch
  - 0029-attach-tweak-logging.patch
  - 0030-attach-use-__do_close-for-labelfd.patch
  - 0031-attach-coding-style-fixes.patch
  - 0032-attach-use-free_disarm.patch
  - 0033-attach-s-attach_child_main-do_attach-g.patch
  - 0034-attach-mark-do_attach-as-__noreturn.patch
  - 0035-attach-make-do_attach-void.patch
  - 0036-attach-use-close_prot_errno_disarm.patch
  - 0037-attach-add-some-DEBUG-logging-to-stdfd-dpulication.patch
  - 0038-cgroups-fix-cgroup-mounting.patch
  - 0039-utils-fix-mount_at.patch
  - 0040-configure-fix-static-builds-with-clang-12-and-LTO.patch
  - 0041-cgroups-bpf-fixes.patch
  - 0042-croups-improve-__do_bpf_program_free.patch
  - 0043-cgroups-coding-style-fixes.patch
  - 0044-cgroups-don-t-initiliaze-NULL-log.patch
  - 0045-cgroups-ensure-all-memory-is-zeroed.patch
  - 0046-cgroups-use-zalloc.patch
  - 0047-cgroups-tweak-cgroup-initialization.patch
  - 0048-log-remove-pointless-inline.patch
  - 0049-log-add-lxc_log_get_fd.patch
  - 0050-seccomp-use-lxc_log_get_fd.patch
  - 0051-log-rework-lxc_log_get_level.patch
  - 0052-seccomp-use-lxc_log_get_level.patch
  - 0053-cgroups-use-bpf-log-when-logging-at-trace-level.patch
  - 0054-log-add-lxc_log_trace-helper.patch
  - 0055-cgroups-use-PTR_TO_U64.patch
  - 0056-cgroups-align-methods.patch
  - 

[Touch-packages] [Bug 1918955] Re: SRU network: fix LXC_NET_NONE cleanup

[Scott Moser]

** Description changed:

  Hi.  I'm using 20.04, and I need a fix for
  https://github.com/lxc/lxc/pull/3589
  
  I think my only options to get that via packaging are
   a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master
   b.) build my own.
  
  I don't love either of those options.
  
  Can we please get a SRU update to 20.04 of an lxc with that fix?
  
  The fix is not in 4.0.5, so I marked this as affecting Groovy (currently
  1:4.0.4-0ubuntu3) without testing.
+ 
+ 
+ Related bugs:
+  * #1923232:  SRU of LXC 4.0.6 to focal (upstream bugfix release)

** Description changed:

  Hi.  I'm using 20.04, and I need a fix for
  https://github.com/lxc/lxc/pull/3589
  
  I think my only options to get that via packaging are
   a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master
   b.) build my own.
  
  I don't love either of those options.
  
  Can we please get a SRU update to 20.04 of an lxc with that fix?
  
  The fix is not in 4.0.5, so I marked this as affecting Groovy (currently
  1:4.0.4-0ubuntu3) without testing.
  
- 
  Related bugs:
-  * #1923232:  SRU of LXC 4.0.6 to focal (upstream bugfix release)
+  * bug 1923232:  SRU of LXC 4.0.6 to focal (upstream bugfix release)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1918955

Title:
  SRU network: fix LXC_NET_NONE cleanup

Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Focal:
  Confirmed
Status in lxc source package in Groovy:
  Confirmed
Status in lxc source package in Hirsute:
  Fix Released

Bug description:
  Hi.  I'm using 20.04, and I need a fix for
  https://github.com/lxc/lxc/pull/3589

  I think my only options to get that via packaging are
   a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master
   b.) build my own.

  I don't love either of those options.

  Can we please get a SRU update to 20.04 of an lxc with that fix?

  The fix is not in 4.0.5, so I marked this as affecting Groovy
  (currently 1:4.0.4-0ubuntu3) without testing.

  Related bugs:
   * bug 1923232:  SRU of LXC 4.0.6 to focal (upstream bugfix release)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1918955] Re: SRU network: fix LXC_NET_NONE cleanup

[Scott Moser]

Just fwi, this is in 4.0.6 which is up for SRU in LP: #1923232.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1918955

Title:
  SRU network: fix LXC_NET_NONE cleanup

Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Focal:
  Confirmed
Status in lxc source package in Groovy:
  Confirmed
Status in lxc source package in Hirsute:
  Fix Released

Bug description:
  Hi.  I'm using 20.04, and I need a fix for
  https://github.com/lxc/lxc/pull/3589

  I think my only options to get that via packaging are
   a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master
   b.) build my own.

  I don't love either of those options.

  Can we please get a SRU update to 20.04 of an lxc with that fix?

  The fix is not in 4.0.5, so I marked this as affecting Groovy
  (currently 1:4.0.4-0ubuntu3) without testing.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1923232] Re: SRU of LXC 4.0.6 to focal (upstream bugfix release)

[Scott Moser]

This would fix LP: #1918955.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1923232

Title:
  SRU of LXC 4.0.6 to focal (upstream bugfix release)

Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Focal:
  Fix Committed

Bug description:
  LXC released 4.0.6 as a bugfix release with the following changelog:

  - Improve handling for compatibility architectures for seccomp
  - Harden seccomp notifier implementation
  - Rework parsing of /proc//mountinfo to handle kernel regression
  - Improve network device restoration
  - Significantly cleanup and harden config file parsing
  - Support new capabilities CAP_PERFORM, CAP_BPF, and 
CAP_CHECKPOINT_RESTORE
  - Harden containers started without CAP_NET_ADMIN
* New upstream bugfix release (4.0.5):
  - Support allocating PTS devices from within the container
  - Harden more path/mount handling logics
  - Rework LSM logic to limit initializer use
* Cherry-pick upstream fixes:
  - 0002-commands-fix-check-for-seccomp-notify-support.patch
  - 0003-configure-skip-libseccomp-tests-if-it-is-disabled.patch
  - 0004-conf-fix-containers-retaining-CAP_NET_ADMIN.patch
  - 0005-cgroups-fix-cgroup-mounting.patch
  - 0006-lsm-remove-obsolute-comment-about-constructor.patch
  - 0007-lxc_attach-include-rexec-conditionally.patch
  - 0008-tree-wide-fix-some-header-inclusions.patch
  - 0009-initutils-fix-missing-includes.patch
  - 0010-configure-support-static-binaries.patch
  - 0011-autotools-enable-static-builds-for-tools.patch
  - 0012-autotools-enable-static-builds-for-commands.patch
  - 0013-tree-wide-fix-compilation-with-Wstrict-prototypes-Wo.patch
  - 0014-config-update-ax_pthread.m4.patch
  - 0015-configure-add-AC_SYS_LARGEFILE-checking.patch
  - 0016-autotools-update-build.patch
  - 0017-file_utils-introduce-read_file_at.patch
  - 0018-string_utils-add-must_make_path_relative.patch
  - 0019-cgroups-coding-style-fixes.patch
  - 0020-cgroups-rework-cg_unified_init.patch
  - 0021-cgroups-detect-and-record-cgroup2-freezer-support.patch
  - 0022-criu-handle-cgroup2-freezer.patch
  - 0023-mkdir-p-proc-sys-on-container-startup.patch
  - 0024-conf-fix-coding-style.patch
  - 0025-conf-coding-style-fixes.patch
  - 0026-conf-move-proc-and-sys-mountpoint-creation-int-lxc_m.patch
  - 0027-attach-invert-child-parent-handling.patch
  - 0028-attach-use-__do_free-cleanup-macro-for-cwd.patch
  - 0029-attach-tweak-logging.patch
  - 0030-attach-use-__do_close-for-labelfd.patch
  - 0031-attach-coding-style-fixes.patch
  - 0032-attach-use-free_disarm.patch
  - 0033-attach-s-attach_child_main-do_attach-g.patch
  - 0034-attach-mark-do_attach-as-__noreturn.patch
  - 0035-attach-make-do_attach-void.patch
  - 0036-attach-use-close_prot_errno_disarm.patch
  - 0037-attach-add-some-DEBUG-logging-to-stdfd-dpulication.patch
  - 0038-cgroups-fix-cgroup-mounting.patch
  - 0039-utils-fix-mount_at.patch
  - 0040-configure-fix-static-builds-with-clang-12-and-LTO.patch
  - 0041-cgroups-bpf-fixes.patch
  - 0042-croups-improve-__do_bpf_program_free.patch
  - 0043-cgroups-coding-style-fixes.patch
  - 0044-cgroups-don-t-initiliaze-NULL-log.patch
  - 0045-cgroups-ensure-all-memory-is-zeroed.patch
  - 0046-cgroups-use-zalloc.patch
  - 0047-cgroups-tweak-cgroup-initialization.patch
  - 0048-log-remove-pointless-inline.patch
  - 0049-log-add-lxc_log_get_fd.patch
  - 0050-seccomp-use-lxc_log_get_fd.patch
  - 0051-log-rework-lxc_log_get_level.patch
  - 0052-seccomp-use-lxc_log_get_level.patch
  - 0053-cgroups-use-bpf-log-when-logging-at-trace-level.patch
  - 0054-log-add-lxc_log_trace-helper.patch
  - 0055-cgroups-use-PTR_TO_U64.patch
  - 0056-cgroups-align-methods.patch
  - 0057-utils-use-SYSTRACE-when-logging-stdio-permission-fix.patch
  - 0058-attach-log-failues-to-dup2-with-SYSDEBUG.patch
  - 0059-attach-fix-logging-for-stdfd-replacement.patch
  - 0060-attach-fix-error-checking-for-dup2.patch
  - 0061-cgroups-initialize-variable.patch
  - 0062-commands_utils-don-t-leak-memory.patch
  - 0063-conf-use-lxc_log_trace.patch
  - 0064-confile_utils-use-lxc_log_trace.patch
  - 0065-rexec-check-lseek-return-value.patch

* Cherry-pick upstream bugfix:
  - cgroups: fix armhf builds

* Cherry-pick upstream bugfix:
  - cgfsng: fix cgroup attach cgroup creation

* New upstream bugfix release (4.0.4):
  - Support for new Linux clone flags (clone into cgroup)
  - Support for new Linux VFS system calls
  - Internal symbols are now properly hidden from external consumers
* New upstream bugfix release (4.0.3):
  - Improvement to cgroupv1/cgroupv2 

[Touch-packages] [Bug 1918955] Re: SRU network: fix LXC_NET_NONE cleanup

[Scott Moser]

** Description changed:

  Hi.  I'm using 20.04, and I need a fix for
  https://github.com/lxc/lxc/pull/3589
  
- I think my only options to get that via packaging are 
-  a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master
-  b.) build my own.
+ I think my only options to get that via packaging are
+  a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master
+  b.) build my own.
  
  I don't love either of those options.
  
  Can we please get a SRU update to 20.04 of an lxc with that fix?
+ 
+ The fix is not in 4.0.5, so I marked this as affecting Groovy (currently
+ 1:4.0.4-0ubuntu3) without testing.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1918955

Title:
  SRU network: fix LXC_NET_NONE cleanup

Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Focal:
  Confirmed
Status in lxc source package in Groovy:
  Confirmed
Status in lxc source package in Hirsute:
  Fix Released

Bug description:
  Hi.  I'm using 20.04, and I need a fix for
  https://github.com/lxc/lxc/pull/3589

  I think my only options to get that via packaging are
   a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master
   b.) build my own.

  I don't love either of those options.

  Can we please get a SRU update to 20.04 of an lxc with that fix?

  The fix is not in 4.0.5, so I marked this as affecting Groovy
  (currently 1:4.0.4-0ubuntu3) without testing.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1918955] [NEW] SRU network: fix LXC_NET_NONE cleanup

[Scott Moser]

Public bug reported:

Hi.  I'm using 20.04, and I need a fix for
https://github.com/lxc/lxc/pull/3589

I think my only options to get that via packaging are 
 a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master
 b.) build my own.

I don't love either of those options.

Can we please get a SRU update to 20.04 of an lxc with that fix?

** Affects: lxc (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: lxc (Ubuntu Focal)
 Importance: Undecided
 Status: Confirmed

** Affects: lxc (Ubuntu Groovy)
 Importance: Undecided
 Status: Confirmed

** Affects: lxc (Ubuntu Hirsute)
 Importance: Undecided
 Status: Fix Released

** Also affects: lxc (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: lxc (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

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

** Changed in: lxc (Ubuntu Hirsute)
   Status: New => Fix Released

** Changed in: lxc (Ubuntu Groovy)
   Status: New => Confirmed

** Changed in: lxc (Ubuntu Focal)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1918955

Title:
  SRU network: fix LXC_NET_NONE cleanup

Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Focal:
  Confirmed
Status in lxc source package in Groovy:
  Confirmed
Status in lxc source package in Hirsute:
  Fix Released

Bug description:
  Hi.  I'm using 20.04, and I need a fix for
  https://github.com/lxc/lxc/pull/3589

  I think my only options to get that via packaging are 
   a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master
   b.) build my own.

  I don't love either of those options.

  Can we please get a SRU update to 20.04 of an lxc with that fix?

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1693900] Re: apt-get update should return exit code != 0 on error

[Scott Moser]

For reference, ubuntu-devel post about '-o APT::Update::Error-Mode=any'
at https://lists.ubuntu.com/archives/ubuntu-devel/2021-February/041374.html

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1693900

Title:
  apt-get update should return exit code != 0 on error

Status in apt package in Ubuntu:
  Triaged

Bug description:
  When running 'apt-get update' (e.g. on a container install post-
  install script), apt-get return with exit code 0, even so it wasn't
  able to "update" properly. E.g.:

  + apt-get update
  Err:1 http://de.archive.ubuntu.com/ubuntu xenial InRelease
Temporary failure resolving 'de.archive.ubuntu.com'
  Err:2 http://security.ubuntu.com/ubuntu xenial-security InRelease
Temporary failure resolving 'security.ubuntu.com'
  Err:3 http://de.archive.ubuntu.com/ubuntu xenial-updates InRelease
Temporary failure resolving 'de.archive.ubuntu.com'
  Reading package lists... Done
  W: Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/xenial/InRelease 
 Temporary failure resolving 'de.archive.ubuntu.com'
  W: Failed to fetch 
http://de.archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease  Temporary 
failure resolving 'de.archive.ubuntu.com'
  W: Failed to fetch 
http://security.ubuntu.com/ubuntu/dists/xenial-security/InRelease  Temporary 
failure resolving 'security.ubuntu.com'
  W: Some index files failed to download. They have been ignored, or old ones 
used instead.

  It should be corrected to return useful exit code, so that scripts can
  take the appropriate actions ...

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1825155] Re: lxc-start crashed with SIGSEGV in cgfsng_payload_create()

[Scott Moser]

I bumped into this yesterday on bionic.
The commit 1e04bb71da3ed829 [1] reports to fix it.

  [1]
https://github.com/lxc/lxc/commit/1e04bb71da3ed829761ae8c729c3d021a6a709df

Hopefully there will be a 3.0.x update to bionic at some point.


** Also affects: lxc (Ubuntu Focal)
   Importance: Medium
   Status: Fix Committed

** Also affects: lxc (Ubuntu Eoan)
   Importance: Undecided
   Status: New

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

** Changed in: lxc (Ubuntu Focal)
   Status: Fix Committed => Fix Released

** Changed in: lxc (Ubuntu Eoan)
   Status: New => Fix Released

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1825155

Title:
  lxc-start crashed with SIGSEGV in cgfsng_payload_create()

Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Bionic:
  Confirmed
Status in lxc source package in Eoan:
  Fix Released
Status in lxc source package in Focal:
  Fix Released

Bug description:
  https://errors.ubuntu.com/problem/8e0f1b9682f08bab5dedd4100e42f59cfe2cc004

  Steps to reproduce:
  1) Prepare creating unprivileged containers as described here: 
https://linuxcontainers.org/lxc/getting-started/
  2) Create a new container (e.g. "lxc-create -n container -t download" and 
then "debian", "stretch" and "amd64").
  3) Start the created container in foreground using "lxc-start -n container -F"

  ProblemType: Crash
  DistroRelease: Ubuntu 18.10
  Package: lxc-utils 3.0.3-0ubuntu1~18.10.1
  ProcVersionSignature: Ubuntu 4.18.0-17.18-generic 4.18.20
  Uname: Linux 4.18.0-17-generic x86_64
  ApportVersion: 2.20.10-0ubuntu13.2
  Architecture: amd64
  CrashCounter: 1
  CurrentDesktop: KDE
  Date: Wed Apr 17 12:03:37 2019
  ExecutablePath: /usr/bin/lxc-start
  InstallationDate: Installed on 2019-04-15 (1 days ago)
  InstallationMedia: Kubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.2)
  ProcCmdline: BOOT_IMAGE=/vmlinuz-4.18.0-17-generic 
root=UUID=0739f905-33c9-4de3-9ba9-a63b8d69e5e5 ro quiet splash vt.handoff=1
  SegvAnalysis:
   Segfault happened at: 0x7f6292c5dbbd:mov(%rax),%r15
   PC (0x7f6292c5dbbd) ok
   source "(%rax)" (0x) not located in a known VMA region (needed 
readable region)!
   destination "%r15" ok
  SegvReason: reading NULL VMA
  Signal: 11
  SourcePackage: lxc
  StacktraceTop:
   ?? () from /usr/lib/x86_64-linux-gnu/liblxc.so.1
   __lxc_start () from /usr/lib/x86_64-linux-gnu/liblxc.so.1
   lxc_start () from /usr/lib/x86_64-linux-gnu/liblxc.so.1
   ?? () from /usr/lib/x86_64-linux-gnu/liblxc.so.1
   ?? () from /usr/lib/x86_64-linux-gnu/liblxc.so.1
  Title: lxc-start crashed with SIGSEGV in __lxc_start()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  defaults.conf:
   lxc.net.0.type = veth
   lxc.net.0.link = lxcbr0
   lxc.net.0.flags = up
   lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx
  mtime.conffile..etc.apport.crashdb.conf: 2019-04-17T11:58:15.556166

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Scott Moser]

this seemed to "just work" for me.
http://paste.ubuntu.com/p/93dWDPZfZT/

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1834875

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  Fix Committed
Status in cloud-initramfs-tools package in Ubuntu:
  Confirmed
Status in cloud-utils package in Ubuntu:
  Confirmed
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Scott Moser]

a.) I gave the wrong link. ugh. It should have been:
  
https://code.launchpad.net/~smoser/cloud-initramfs-tools/+git/cloud-initramfs-tools/+merge/379774

b.) the fixed link to 'a' probably makes more sense now.  But basically
you need a newer cloud-initramfs-tools to adjust for the fact that
growpart needs flock now.

cloud-initramfs-tools I believe is still a "native package".  So it just
has the packaging along side

c.) you can use new-upstream-snapshot.  cloud-utils is set to use the
same basic workflow as cloud-init or curtin.


I'm OK to upload cloud-initramfs-tools and also cloud-utils, but I think
in both cases it makes sense to get someone from server team to do it.
Just to have someone other than myself having done it.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1834875

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  Fix Committed
Status in cloud-initramfs-tools package in Ubuntu:
  Confirmed
Status in cloud-utils package in Ubuntu:
  Confirmed
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Scott Moser]

The fix is in cloud-utils upstream now.
Still to do:
 a.) review/merge cloud-initramfs-tools pull request 
   
https://code.launchpad.net/~raharper/cloud-utils/+git/cloud-utils/+merge/379177
 b.) upload cloud-initramfs-tools to focal
 c.) upload cloud-utils to focal
 d.) any SRU

the order of 'b' and 'c' are not *terribly* important, because I do not
think that there are many users of 'growroot' at this point.  That
said... the change to cloud-utils *does* break cloud-initramfs-tools so
they should be done in that order.

I personally do not really want to babysit these getting in.  Can
someone else sign up for that?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1834875

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  Fix Committed
Status in cloud-initramfs-tools package in Ubuntu:
  Confirmed
Status in cloud-utils package in Ubuntu:
  Confirmed
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Scott Moser]

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1834875

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  Fix Committed
Status in cloud-initramfs-tools package in Ubuntu:
  Confirmed
Status in cloud-utils package in Ubuntu:
  Confirmed
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Scott Moser]

** Merge proposal linked:
   
https://code.launchpad.net/~raharper/cloud-utils/+git/cloud-utils/+merge/379177

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

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

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

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1834875

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  Fix Committed
Status in cloud-initramfs-tools package in Ubuntu:
  New
Status in cloud-utils package in Ubuntu:
  Confirmed
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1856560] Re: ds-identify - stuck in uninterruptible sleep state

[Scott Moser]

> If someone manually installs Ubuntu Desktop / Server using an installer,
> one should not be installing or using cloud-init as clearly, it will never
> complete without a correct metadata source present. And when it fails to
> complete, it re-attempts to reprovision the machine on every boot.

I'd just like to clarify something.  The above statement is neither true
nor helpful.

cloud-init (since 18.04) does not run unless it is on a cloud or has cloud
platform metadata.  It is perfectly fine to have cloud-init installed on a
desktop or a server that is not running "on a cloud".

In order to accomplish this, cloud-init is only enabled via a generator.
That generator ran 'blkid', and 'blkid' blocked indefinitely.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1856560

Title:
  ds-identify - stuck in uninterruptible sleep state

Status in cloud-init:
  Invalid
Status in util-linux package in Ubuntu:
  Incomplete

Bug description:
  We got recurring issues with the cloud-init/ds-identify process. It
  spawns sub-processes "blkid -c /dev/null -o export" which gets stuck
  in the "D" uninterruptible sleep state.

  The processes cannot be killed, so the only solution is to reboot the
  affected server.

  root 3839 0.0 0.0 4760 1840 ? S Dec05 0:00 /bin/sh 
/usr/lib/cloud-init/ds-identify
  root 3844 0.0 0.0 11212 2836 ? D Dec05 0:00 \_ blkid -c /dev/null -o export
  root 6943 0.0 0.0 4760 1880 ? S Dec05 0:00 /bin/sh 
/usr/lib/cloud-init/ds-identify
  root 6948 0.0 0.0 11212 2844 ? D Dec05 0:00 \_ blkid -c /dev/null -o export
  root 6111 0.0 0.0 4760 1916 ? S Dec12 0:00 /bin/sh 
/usr/lib/cloud-init/ds-identify
  root 6149 0.0 0.0 11212 2940 ? D Dec12 0:00 \_ blkid -c /dev/null -o export
  root 8765 0.0 0.3 926528 24968 ? Ssl Dec12 0:12 /usr/lib/snapd/snapd
  root 9179 0.0 0.0 4760 1892 ? S Dec12 0:00 /bin/sh 
/usr/lib/cloud-init/ds-identify
  root 9185 0.0 0.0 11980 3552 ? D Dec12 0:00 \_ blkid -c /dev/null -o export

  Distributor ID: Ubuntu
  Description: Ubuntu 18.04.3 LTS
  Release: 18.04
  Codename: bionic

  5.0.0-36-generic #39~18.04.1-Ubuntu SMP Tue Nov 12 11:09:50 UTC 2019
  x86_64 x86_64 x86_64 GNU/Linux

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Scott Moser]

> > So that means we have this sequence of events:
> >  a.) growpart change partition table
> >  b.) growpart call partx
> >  c.) udev created and events being processed

> That is not true. whilst sfdisk is deleting, creating, finishing
> partition table (a) and partx is called (b), udev events are already fired
> and running in parallel and may complete against deleted, partially new,
> completely new partition table, with or without partx completed.

You're correct... I left out some 'events created and handled' after 'a'.
But that doesn't change anything.  The problem we're seeing here is *not*
that 'b' had any issue.

> 
> No amount of settling for events will fix the fact that events were run
> against racy state of the partition table _during_ sfdisk and partx calls.

complete non-sense.  I dont care about any racy state *during* anything. I 
call 'udevadm settle'.  That means "block until stuff is done."  I think
you're saying that I cannot:
 1.) do something that causes udev events
 2.) wait until all udev events caused by that something are finished

if that is the case, then nothing ever can fix this, and we might as well
go find jobs on a farm.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1834875

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Scott Moser]

I really think you are all *way* over thinking this.
 a. growpart made a change to the partition table (using sfdisk)
 b. growpart called partx --update --nr 3 /dev/sda
 c. growpart exited

With a and b growpart created udev events. If you create udev events,
you really need to wait for those events to finish, or your just pushing
complexity onto your consumer.

Now Daniel's updated cloud-init with output captured in comment 14
clearly called udevadm settle after 'c'. But the problem still existed.

So that means we have this sequence of events:
 a.) growpart change partition table
 b.) growpart call partx
 c.) udev created and events being processed
 d.) growpart exits
 e.) cloud-init calls udevadm settle
 f.) udev events occurring that removed the link
 g.) cloud-init raced on reading that size - fail

To  me, that means either udevadm settle called in 'e' didn't actually
do what it is suppsoed to do and wait for all events in the queue to
clear.  Or, something else created new events.  I have long suspected
that to be the case, and I think the thing doing it is udev rules.

If that is true, then udev events cause more udev events, so a single
'settle' is never enough.  Nor can you actually ever know if you *have*
settled long enough.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1834875

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

[Scott Moser]

best. fix. ever.

working after a reboot.

$ snap list lxd
Name  Version  RevTracking  Publisher   Notes
lxd   3.18 12211  stablecanonical✓  -

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1779156

Title:
  lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

Status in linux package in Ubuntu:
  Triaged
Status in lxc package in Ubuntu:
  Confirmed
Status in linux source package in Cosmic:
  Triaged
Status in lxc source package in Cosmic:
  Confirmed
Status in linux source package in Disco:
  New
Status in lxc source package in Disco:
  New
Status in linux source package in Eoan:
  Triaged
Status in lxc source package in Eoan:
  Confirmed

Bug description:
  I'm not sure exactly what got me into this state, but I have several
  lxc containers that cannot be deleted.

  $ lxc info
  
  api_status: stable
  api_version: "1.0"
  auth: trusted
  public: false
  auth_methods:
  - tls
  environment:
addresses: []
architectures:
- x86_64
- i686
certificate: |
  -BEGIN CERTIFICATE-
  
  -END CERTIFICATE-
certificate_fingerprint: 
3af6f8b8233c5d9e898590a9486ded5c0bec045488384f30ea921afce51f75cb
driver: lxc
driver_version: 3.0.1
kernel: Linux
kernel_architecture: x86_64
kernel_version: 4.15.0-23-generic
server: lxd
server_pid: 15123
server_version: "3.2"
storage: zfs
storage_version: 0.7.5-1ubuntu15
server_clustered: false
server_name: milhouse

  $ lxc delete --force b1
  Error: Failed to destroy ZFS filesystem: cannot destroy 
'default/containers/b1': dataset is busy

  Talking in #lxc-dev, stgraber and sforeshee provided diagnosis:

   | short version is that something unshared a mount namespace causing
   | them to get a copy of the mount table at the time that dataset was
   | mounted, which then prevents zfs from being able to destroy it)

  The work around provided was

   | you can unstick this particular issue by doing:
   |  grep default/containers/b1 /proc/*/mountinfo
   | then for any of the hits, do:
   |   nsenter -t PID -m -- umount 
/var/snap/lxd/common/lxd/storage-pools/default/containers/b1
   | then try the delete again

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: linux-image-4.15.0-23-generic 4.15.0-23.25
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  smoser31412 F pulseaudio
   /dev/snd/controlC2:  smoser31412 F pulseaudio
   /dev/snd/controlC0:  smoser31412 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jun 28 10:42:45 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (1071 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  MachineType: 
b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
 
b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-23-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-23-generic N/A
   linux-backports-modules-4.15.0-23-generic  N/A
   linux-firmware 1.174
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 03/09/2015
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: RYBDWi35.86A.0246.2015.0309.1355
  dmi.board.asset.tag: �
  dmi.board.name: NUC5i5RYB
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H40999-503
  dmi.chassis.asset.tag: �
  dmi.chassis.type: 3
  dmi.chassis.vendor: �
  dmi.chassis.version: �
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrRYBDWi35.86A.0246.2015.0309.1355:bd03/09/2015:svn:pn:pvr:rvnIntelCorporation:rnNUC5i5RYB:rvrH40999-503:cvn:ct3:cvr:
  dmi.product.family: �
  dmi.product.name: �
  dmi.product.version: �
  dmi.sys.vendor: �

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Scott Moser]

If there is a race, or a need to wait, it almost certainly is in cloud-
utils (growpart).  If you use growpart to grow a partition, the result
should be that that is done, and it is ready.  The caller should not
expect that they have to know additional information (to call 'udevadm
settle') or should have to wait some amount of time.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1834875

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Scott Moser]

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1834875

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1831258] Re: journalctl --list-boots does not recognize boots in a container

[Scott Moser]

Filed issue with lxcfs at 
https://github.com/lxc/lxcfs/issues/285


** Bug watch added: LXCFS bug tracker #285
   https://github.com/lxc/lxcfs/issues/285

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1831258

Title:
  journalctl --list-boots does not recognize boots in a container

Status in lxd package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Invalid
Status in lxd source package in Bionic:
  New
Status in systemd source package in Bionic:
  Invalid
Status in lxd source package in Eoan:
  New
Status in systemd source package in Eoan:
  Invalid

Bug description:
  $ lxc launch ubuntu-daily:eoan devel1
  $ sleep 10 # wait for boot

  $ lxc exec devel1 /bin/bash
  root@devel1:~# cat /proc/uptime
  183.00 173.00
  root@devel1:~# cat /etc/cloud/build.info
  build_name: server
  serial: 20190531
  root@devel1:~# lsb_release -sc
  eoan

  root@devel1:~# journalctl --no-pager --list-boots
   0 4ecd6fb081964b75b1ddc09baf1be3d9 Fri 2019-05-31 14:58:48 UTC—Fri 
2019-05-31 15:06:10 UTC
  root@devel1:~# reboot
  root@devel1:~#

  $ lxc exec devel1 /bin/bash
  ## verify the reboot happened
  root@devel1:~# cat /proc/uptime
  12.00 6.00
  ## but journalctl only shows the same boot it did before.
  root@devel1:~# journalctl --no-pager --list-boots
   0 4ecd6fb081964b75b1ddc09baf1be3d9 Fri 2019-05-31 14:58:48 UTC—Fri 
2019-05-31 15:09:10 UTC

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: systemd 240-6ubuntu5
  ProcVersionSignature: Ubuntu 4.15.0-50.54-generic 4.15.18
  Uname: Linux 4.15.0-50-generic x86_64
  ApportVersion: 2.20.11-0ubuntu2
  Architecture: amd64
  Date: Fri May 31 15:06:24 2019
  MachineType: LENOVO 20KGS3Y900
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-50-generic 
root=UUID=25df9069-80c7-46f4-a47c-305613c2cb6b ro quiet splash vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/20/2019
  dmi.bios.vendor: LENOVO
  dmi.bios.version: N23ET63W (1.38 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20KGS3Y900
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40697 WIN
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.modalias: 
dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KGS3Y900:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KGS3Y900:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
  dmi.product.family: ThinkPad X1 Carbon 6th
  dmi.product.name: 20KGS3Y900
  dmi.product.version: ThinkPad X1 Carbon 6th
  dmi.sys.vendor: LENOVO

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1831258] [NEW] journalctl --list-boots does not recognize boots in a container

[Scott Moser]

Public bug reported:

$ lxc launch ubuntu-daily:eoan devel1
$ sleep 10 # wait for boot

$ lxc exec devel1 /bin/bash
root@devel1:~# cat /proc/uptime
183.00 173.00
root@devel1:~# cat /etc/cloud/build.info
build_name: server
serial: 20190531
root@devel1:~# lsb_release -sc
eoan

root@devel1:~# journalctl --no-pager --list-boots
 0 4ecd6fb081964b75b1ddc09baf1be3d9 Fri 2019-05-31 14:58:48 UTC—Fri 2019-05-31 
15:06:10 UTC
root@devel1:~# reboot
root@devel1:~#

$ lxc exec devel1 /bin/bash
## verify the reboot happened
root@devel1:~# cat /proc/uptime
12.00 6.00
## but journalctl only shows the same boot it did before.
root@devel1:~# journalctl --no-pager --list-boots
 0 4ecd6fb081964b75b1ddc09baf1be3d9 Fri 2019-05-31 14:58:48 UTC—Fri 2019-05-31 
15:09:10 UTC

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: systemd 240-6ubuntu5
ProcVersionSignature: Ubuntu 4.15.0-50.54-generic 4.15.18
Uname: Linux 4.15.0-50-generic x86_64
ApportVersion: 2.20.11-0ubuntu2
Architecture: amd64
Date: Fri May 31 15:06:24 2019
MachineType: LENOVO 20KGS3Y900
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=C.UTF-8
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-50-generic 
root=UUID=25df9069-80c7-46f4-a47c-305613c2cb6b ro quiet splash vt.handoff=1
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/20/2019
dmi.bios.vendor: LENOVO
dmi.bios.version: N23ET63W (1.38 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20KGS3Y900
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: 
dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KGS3Y900:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KGS3Y900:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad X1 Carbon 6th
dmi.product.name: 20KGS3Y900
dmi.product.version: ThinkPad X1 Carbon 6th
dmi.sys.vendor: LENOVO

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: systemd (Ubuntu Bionic)
 Importance: Undecided
 Status: New

** Affects: systemd (Ubuntu Eoan)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug eoan uec-images

** Also affects: systemd (Ubuntu Eoan)
   Importance: Undecided
   Status: New

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1831258

Title:
  journalctl --list-boots does not recognize boots in a container

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Bionic:
  New
Status in systemd source package in Eoan:
  New

Bug description:
  $ lxc launch ubuntu-daily:eoan devel1
  $ sleep 10 # wait for boot

  $ lxc exec devel1 /bin/bash
  root@devel1:~# cat /proc/uptime
  183.00 173.00
  root@devel1:~# cat /etc/cloud/build.info
  build_name: server
  serial: 20190531
  root@devel1:~# lsb_release -sc
  eoan

  root@devel1:~# journalctl --no-pager --list-boots
   0 4ecd6fb081964b75b1ddc09baf1be3d9 Fri 2019-05-31 14:58:48 UTC—Fri 
2019-05-31 15:06:10 UTC
  root@devel1:~# reboot
  root@devel1:~#

  $ lxc exec devel1 /bin/bash
  ## verify the reboot happened
  root@devel1:~# cat /proc/uptime
  12.00 6.00
  ## but journalctl only shows the same boot it did before.
  root@devel1:~# journalctl --no-pager --list-boots
   0 4ecd6fb081964b75b1ddc09baf1be3d9 Fri 2019-05-31 14:58:48 UTC—Fri 
2019-05-31 15:09:10 UTC

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: systemd 240-6ubuntu5
  ProcVersionSignature: Ubuntu 4.15.0-50.54-generic 4.15.18
  Uname: Linux 4.15.0-50-generic x86_64
  ApportVersion: 2.20.11-0ubuntu2
  Architecture: amd64
  Date: Fri May 31 15:06:24 2019
  MachineType: LENOVO 20KGS3Y900
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-50-generic 
root=UUID=25df9069-80c7-46f4-a47c-305613c2cb6b ro quiet splash vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/20/2019
  dmi.bios.vendor: LENOVO
  dmi.bios.version: N23ET63W (1.38 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20KGS3Y900
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40697 WIN
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.modalias: 
dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KGS3Y900:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KGS3Y900:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
  dmi.product.family: ThinkPad X1 Carbon 6th
  dmi.product.name: 20KGS3Y900
  dmi.product.version: ThinkPad X1 Carbon 6th
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:

[Touch-packages] [Bug 1723390] Re: lxd containers have become degraded

[Scott Moser]

Quite a pleasent surprise I found today.

$ lxc launch ubuntu-daily:devel devel1
$ sleep 20
$ lxc exec devel1 systemctl status | grep State
State: running

$ lxc exec devel1 -- sh -c 'cat /etc/cloud/build.info; lsb_release -sc'
build_name: server
serial: 20190531
eoan


$ lxc exec devel1 -- systemctl status --no-pager
● devel1
State: running
 Jobs: 0 queued
   Failed: 0 units
Since: Fri 2019-05-31 14:58:48 UTC; 3min 32s ago
   CGroup: /
   ├─1204 systemctl status --no-pager
   ├─init.scope
   │ └─1 /sbin/init
   └─system.slice
 ├─systemd-networkd.service
 │ └─135 /lib/systemd/systemd-networkd
 ├─systemd-udevd.service
 │ └─87 /lib/systemd/systemd-udevd
 ├─cron.service
 │ └─185 /usr/sbin/cron -f
 ├─polkit.service
 │ └─222 /usr/lib/policykit-1/polkitd --no-debug
 ├─networkd-dispatcher.service
 │ └─187 /usr/bin/python3 /usr/bin/networkd-dispatcher --run-star...
 ├─accounts-daemon.service
 │ └─180 /usr/lib/accountsservice/accounts-daemon
 ├─systemd-journald.service
 │ └─58 /lib/systemd/systemd-journald
 ├─atd.service
 │ └─198 /usr/sbin/atd -f
 ├─unattended-upgrades.service
 │ └─256 /usr/bin/python3 /usr/share/unattended-upgrades/unattend...
 ├─ssh.service
 │ └─200 /usr/sbin/sshd -D
 ├─snap-core-6964.mount
 │ └─472 snapfuse /var/lib/snapd/snaps/core_6964.snap /snap/core/...
 ├─snapd.service
 │ └─502 /usr/lib/snapd/snapd
 ├─rsyslog.service
 │ └─181 /usr/sbin/rsyslogd -n -iNONE
 ├─console-getty.service
 │ └─213 /sbin/agetty -o -p -- \u --noclear --keep-baud console 1...
 ├─snap-lxd-10756.mount
 │ └─672 snapfuse /var/lib/snapd/snaps/lxd_10756.snap /snap/lxd/1...
 ├─systemd-resolved.service
 │ └─137 /lib/systemd/systemd-resolved
 ├─dbus.service
 │ └─184 /usr/bin/dbus-daemon --system --address=systemd: --nofor...
 └─systemd-logind.service
   └─188 /lib/systemd/systemd-logind


** Also affects: systemd (Ubuntu Eoan)
   Importance: Undecided
   Status: Confirmed

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

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

** Changed in: systemd (Ubuntu Eoan)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1723390

Title:
  lxd containers have become degraded

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Confirmed
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  20170920 container boots degraded with 
  Oct 13 10:09:28 test20170920 systemd[256]: systemd-hostnamed.service: Failed 
at step NETWORK spawning /lib/systemd/systemd-hostnamed: Permission denied

  20170919 container boots non-degraded. Package list changes are
  insignificant.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1809027] Re: Make retired Ubuntu keyrings available from the archive

[Scott Moser]

The easiest thing to do would be to just ship a keyring that had the
obsolete public signing keys.  Then the consumer could hard code
that 'precise' was signed with keys A, B, C.  and work stuff out like
that.

Alternatively possibly we might want to deliver some distro-info like
data.

ubuntu-release|
fingerprint | status | used-releases
790BC7277767219C42C86F933B4FE6ACC0B21F32 | expired | precise quantal raring 
saucy trusty utopic ...
F6ECB3762474EDA9D21B7022871920D1991BC93C | current | trusty utopic vivid wily 
xenial yakkety ...

Then the consumer expecting to verify 'precise' data could determine
they should use the 790B key.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-keyring in Ubuntu.
https://bugs.launchpad.net/bugs/1809027

Title:
  Make retired Ubuntu keyrings available from the archive

Status in ubuntu-keyring package in Ubuntu:
  New

Bug description:
  Currently, if an Ubuntu developer (or their code) is attempting to
  interact with the precise archive (which is still supported in some
  form via ESM) from a machine running bionic or later, they will run in
  to issues verifying signatures, because the keys used to sign the
  precise archive are no longer included in the default keyring as of
  bionic.

  (Some form of this problem will present every time an archive key
  rotation happens; eventually the old key will no longer be trusted,
  and similar failures to the ones today will occur.)

  Whilst the old keys should never be used by the system's apt (or other
  installed software), it would be good if there were some way to
  install those keys from the archives for projects which knowingly want
  to use the older signatures.  (The old keys should be in a path that
  isn't currently used by anything, so that they have to be explicitly
  used.)

  (This bug came out of a discussion on
  https://code.launchpad.net/~smoser/vmbuilder/mfdiff-apt-key-
  transition/+merge/313797.)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1576353] Re: Install openssh-server with disabled password auth by default on servers

[Scott Moser]

@Adam,

> See the comment on the linked debian-cd MP from Marc Deslauriers. Note
> that the goal of removing the cloud-image seed is still entirely
> reasonable and doable, openssh-server should just move to livecd-rootfs
> as something always added to cloud images. Done and done. There's no

Your argument can then be extended to indicate that we do not need *any*
seeds at all.  We'll just hard code package lists that we install in
some arbitrary scripts on some server/git-repo.  "Done and done."

That doesn't make sense.  The point of 'Ubuntu Server' seed is that
having it implies "default ubuntu server".  The user can expect certain
behaviors of a system that is "Ubuntu Server".

That is not consistent, user-friendly or "just works".

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1576353

Title:
  Install openssh-server with disabled password auth by default on
  servers

Status in Ubuntu CD Images:
  Won't Fix
Status in livecd-rootfs package in Ubuntu:
  Won't Fix
Status in openssh package in Ubuntu:
  Fix Released
Status in ubuntu-meta package in Ubuntu:
  Won't Fix

Bug description:
  we want to remove 'cloud-image' seed and join it with 'server' seed.
  openssh-server is one of the few (3) packages that are in cloud image and not 
in 'ubuntu-server'.

  We'd like to have the server iso install openssh-server by default and
  prompt the user if they want to enable it or not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1576353/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1795410] [NEW] cannot bring up window menu via keybinding (alt-space or otherwise)

[Scott Moser]

Public bug reported:

I'm accustomed to hitting 'alt-space' to 'Activate the window menu'
where there are options like 'Always on Top' or 'Always on visible
workspace'.

After an upgrade today I can no longer bring up that menu.

Alt-space simply does nothing. Configuring the keyboard shortcut in
gnome-control-center to another shortcut has no effect.

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: ubuntu-desktop 1.424
ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5
Uname: Linux 4.18.0-7-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.10-0ubuntu11
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Mon Oct  1 10:13:53 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2015-07-23 (1166 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: ubuntu-meta
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: mutter (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug cosmic third-party-packages

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1795410

Title:
  cannot bring up window menu via keybinding (alt-space or otherwise)

Status in mutter package in Ubuntu:
  New

Bug description:
  I'm accustomed to hitting 'alt-space' to 'Activate the window menu'
  where there are options like 'Always on Top' or 'Always on visible
  workspace'.

  After an upgrade today I can no longer bring up that menu.

  Alt-space simply does nothing. Configuring the keyboard shortcut in
  gnome-control-center to another shortcut has no effect.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: ubuntu-desktop 1.424
  ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5
  Uname: Linux 4.18.0-7-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu11
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Oct  1 10:13:53 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (1166 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: ubuntu-meta
  UpgradeStatus: No upgrade log present (probably fresh install)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

[Scott Moser]

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

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1671951

Title:
  networkd should allow configuring IPV6 MTU

Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Bionic:
  Confirmed
Status in netplan.io source package in Bionic:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  1) Zesty
  2) systemd-232-19
  3) I need to configure the IPV6 MTU for tunneling by adding an 
IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 
static address in the [Network] section
  4) networkd does not parse or read the value and does not apply this 
configuration to the interface.

  Upstream has discussed this issue here:

  https://github.com/systemd/systemd/pull/1533

  But it's been closed in favor of only setting via RA.

  However, we know of multiple use-case which are currently supported in
  ifdupdown where we want to retain control over IPV6 MTU values outside
  of PMTU Discovery configurations.

  
  Some context from those discussions

  
  >> Client systems that route their ipv6 packets to a 6in4 router also
  >> have to have their ipv6 mtu lowered.  They could lower their link mtu,
  >> so their ipv6 packets are small enough, but that reduces performance
  >> of their ipv4 network.

  Yes.  Anything that creates a PMTUD black hole can result in
  situations where the higher header overhead of IPv6 will cause IPv4 to
  pass but IPv6 traffic to be dropped.

  One example here is egress from an ipsec tunnel wherein the next
  hop MTU is too low for IPv6 datagrams to pass.  Another is VM ->
  whatever -> host bridge -> tunnel ingress.  If the datagram cannot enter
  the tunnel due to size, it is dropped, and an ICMP response uses the
  tunnel address as a source, which may not be routable back to the
  origin.  This one is an issue with IPv4 as well, and is one case where
  manually setting the IPv6 MTU lower than the (also manually set) device
  MTU is of benefit.

  In essence, any of these sort of cases that require an explicit
  setting of the device MTU will likely require a setting of the IPv6 mtu
  as well to account for its larger header overhead.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

[Scott Moser]

Hm...

Our tests show that this is not fixed in cosmic or bionic.

https://jenkins.ubuntu.com/server/job/curtin-vmtest-devel-amd64/533/console
shows curtin's vmtest failing.  Partial output shows:

==
ERROR: test_ipv6_mtu_smaller_than_ipv4_v6_iface_first 
(vmtests.test_network_mtu.CosmicTestNetworkMtu)
--
Traceback (most recent call last):
  File 
"/var/lib/jenkins/slaves/torkoal/workspace/curtin-vmtest-devel-amd64/curtin-533/tests/vmtests/__init__.py",
 line 468, in wrapper
raise RuntimeError(msg)
RuntimeError: 
skip_by_date(CosmicTestNetworkMtu.test_ipv6_mtu_smaller_than_ipv4_v6_iface_first)
 LP: #1671951 fixby=2018-09-26 removeby=2018-10-17: (PAST_FIXBY) Failed: 1480 
!= 1500
 >> begin captured stdout << -
iface=interface4 subnets=[{'address': '2001:4800:78ff:1b:be76:4eff:fe06:5000', 
'netmask': 64, 'type': 'static', 'mtu': 1480}, {'address': '192.168.5.2/24', 
'type': 'static', 'mtu': 1501}]
subnet:{'address': '2001:4800:78ff:1b:be76:4eff:fe06:5000', 'netmask': 64, 
'type': 'static', 'mtu': 1480}
mtu_data:{'device': 1500, 'ipv6': 1500}
subnet_mtu=1480 ipv6_mtu=1500

- >> end captured stdout << --


** Attachment added: "console log of curtin vmtest amd64 533"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1671951/+attachment/5194078/+files/curtin-vmtest-devel-amd64-533-console.log

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1671951

Title:
  networkd should allow configuring IPV6 MTU

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  New

Bug description:
  1) Zesty
  2) systemd-232-19
  3) I need to configure the IPV6 MTU for tunneling by adding an 
IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 
static address in the [Network] section
  4) networkd does not parse or read the value and does not apply this 
configuration to the interface.

  Upstream has discussed this issue here:

  https://github.com/systemd/systemd/pull/1533

  But it's been closed in favor of only setting via RA.

  However, we know of multiple use-case which are currently supported in
  ifdupdown where we want to retain control over IPV6 MTU values outside
  of PMTU Discovery configurations.

  
  Some context from those discussions

  
  >> Client systems that route their ipv6 packets to a 6in4 router also
  >> have to have their ipv6 mtu lowered.  They could lower their link mtu,
  >> so their ipv6 packets are small enough, but that reduces performance
  >> of their ipv4 network.

  Yes.  Anything that creates a PMTUD black hole can result in
  situations where the higher header overhead of IPv6 will cause IPv4 to
  pass but IPv6 traffic to be dropped.

  One example here is egress from an ipsec tunnel wherein the next
  hop MTU is too low for IPv6 datagrams to pass.  Another is VM ->
  whatever -> host bridge -> tunnel ingress.  If the datagram cannot enter
  the tunnel due to size, it is dropped, and an ICMP response uses the
  tunnel address as a source, which may not be routable back to the
  origin.  This one is an issue with IPv4 as well, and is one case where
  manually setting the IPv6 MTU lower than the (also manually set) device
  MTU is of benefit.

  In essence, any of these sort of cases that require an explicit
  setting of the device MTU will likely require a setting of the IPv6 mtu
  as well to account for its larger header overhead.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1134036] Re: Failure when using ssh with a locale that is not configured on the server

[Scott Moser]

** Changed in: maas (Ubuntu Bionic)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to base-files in Ubuntu.
https://bugs.launchpad.net/bugs/1134036

Title:
  Failure when using ssh with a locale that is not configured on the
  server

Status in base-files package in Ubuntu:
  Fix Released
Status in maas package in Ubuntu:
  Invalid
Status in base-files source package in Bionic:
  Fix Released
Status in maas source package in Bionic:
  Invalid

Bug description:
  [impact]
  The setup:

  1) The user has LC_ALL set to a locale on their machine (or some other LC_* 
variable but it's usually LC_ALL).
  2) This locale does not exist on an Ubuntu server.
  3) The user sshes into the server.

  ssh (at least with the settings that are default on Debian and Ubuntu
  and Fedora) send the value of LC_ALL to the remote server, where the
  default settings on Ubuntu allow this to be set in the environment of
  the process it launches.

  Because we are now in a situation where LC_ALL is set to a value that
  is not valid for the system, various undesirable things happen,
  including ugly messages from cloud-init and perl complaining every
  time a perl process starts and the bug that the original description
  below describes.

  [test case]
  Configure the setup as described above. Ssh into the server and run "perl < 
/dev/null" and check for warnings.

  [regression potential]
  This adds a step to the startup of every login shell, which obviously is not 
entirely trivial. However, the new executable being invoked is very simple and 
even if it fails, the startup of the shell should not be inhibited.

  
  [original description]

  
  If LC_ALL is not set (which seems to be the default on a few server 
installations I've done now), mid way through installing, you get this 
backtrace and then the installation just hangs.  You can ctrl-c out of it but 
the package is left half configured.

  Traceback (most recent call last):
    File "/usr/bin/django-admin", line 5, in 
  management.execute_from_command_line()
    File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 443, in execute_from_command_line
  utility.execute()
    File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 382, in execute
  self.fetch_command(subcommand).run_from_argv(self.argv)
    File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", 
line 196, in run_from_argv
  self.execute(*args, **options.__dict__)
    File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", 
line 232, in execute
  output = self.handle(*args, **options)
    File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", 
line 371, in handle
  return self.handle_noargs(**options)
    File 
"/usr/lib/python2.7/dist-packages/south/management/commands/syncdb.py", line 
90, in handle_noargs
  syncdb.Command().execute(**options)
    File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", 
line 232, in execute
  output = self.handle(*args, **options)
    File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", 
line 371, in handle
  return self.handle_noargs(**options)
    File 
"/usr/lib/python2.7/dist-packages/django/core/management/commands/syncdb.py", 
line 57, in handle_noargs
  cursor = connection.cursor()
    File "/usr/lib/python2.7/dist-packages/django/db/backends/__init__.py", 
line 308, in cursor
  cursor = util.CursorWrapper(self._cursor(), self)
    File 
"/usr/lib/python2.7/dist-packages/django/db/backends/postgresql_psycopg2/base.py",
 line 177, in _cursor
  self.connection = Database.connect(**conn_params)
    File "/usr/lib/python2.7/dist-packages/psycopg2/__init__.py", line 179, in 
connect
  connection_factory=connection_factory, async=async)
  psycopg2.OperationalError: FATAL:  password authentication failed for user 
"maas"
  FATAL:  password authentication failed for user "maas"

  Related bugs:
   * bug 969462: [postgres] fails to start after install if invalid locale is 
set

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1134036/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 1788188] Re: transient systemd ordering cycle in boot with overlayroot

[Scott Moser]

@xnox,
Are you suggesting the /media/root-ro entry in /etc/fstab line for
/media/root-ro should have x-systemd.DefaultDependencies=no ?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1788188

Title:
  transient systemd ordering cycle in boot with overlayroot

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  open-iscsi test utilizes overlayroot to boot a cloud-image with root
  filesystem on a read-only iscsi server.

  The /etc/fstab file in the image looks like this:
    LABEL=cloudimg-rootfs   /ext4   defaults0 0
    #LABEL=UEFI /boot/efi   vfatdefaults0 0

  when init takes over from the initramfs, we have

    /proc/cmdline:
  nomodeset iscsi_initiator=maas-enlist
  iscsi_target_name=tgt-boot-test-2abbnj iscsi_target_ip=10.0.12.2
  iscsi_target_port=3260 iscsi_initiator=maas-enlist
  ip=maas-enlist:BOOTIF ro net.ifnames=0 BOOTIF_DEFAULT=eth0
  
root=/dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1
  overlayroot=tmpfs console=ttyS0
  ds=nocloud-net;seedfrom=http://10.0.12.2:32600/ init=/bin/bash

    /etc/fstab:
  # cat /etc/fstab
  #
  #  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,noauto 0 0
  /media/root-ro/ / overlay 
lowerdir=/media/root-ro/,upperdir=/media/root-rw/over0
  #LABEL=UEFI /boot/efi vfat defaults 0 0

   /root/root-ro/etc/fstab:
  LABEL=cloudimg-rootfs   /ext4   defaults0 0
  #LABEL=UEFI /boot/efi   vfatdefaults0 0

   /proc/mounts:
     sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
     proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
     udev /dev devtmpfs 
rw,nosuid,relatime,size=233748k,nr_inodes=58437,mode=755 0 0
     devpts /dev/pts devpts 
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
     tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=49288k,mode=755 0 0
     /dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1 
/media/root-ro ext4 ro,relatime 0 0
     tmpfs-root /media/root-rw tmpfs rw,relatime 0 0
     overlayroot / overlay 
ro,relatime,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_
 0 0

   /proc/1/mountinfo:
     21 28 0:20 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
     22 28 0:4 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
     23 28 0:6 / /dev rw,nosuid,relatime - devtmpfs udev 
rw,size=233748k,nr_inodes=58437,mode=755
     24 23 0:21 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts 
rw,gid=5,mode=620,ptmxmode=000
     25 28 0:22 / /run rw,nosuid,noexec,relatime - tmpfs tmpfs 
rw,size=49288k,mode=755
     26 28 8:1 / /media/root-ro ro,relatime - ext4 
/dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1 ro
     27 28 0:23 / /media/root-rw rw,relatime - tmpfs tmpfs-root rw
     28 0 0:24 / / ro,relatime - overlay overlayroot 
ro,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_

  overlayroot's scripts/init-bottom/overlayroot script [1] inherits a
  read-only mount of block device on mount point '$ROOTMNT'
  (ROOTMNT=/root). In order to set up the overlayroot, it does the
  following:

   mkdir /media/root-ro /media/root-rw # in the initramfs
   mount -t tmpfs tmpfs-root /media/root-rw
   mkdir /media/root-rw/overlay-workdir/_
   mount --move $ROOTMNT /media/root-ro
   mount -t overlay -o 
lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_
 overlayroot /root
   mkdir $ROOTMNT/media/root-ro
   mkdir $ROOTMNT/media/root-rw
   mount --move /media/root-ro "${ROOTMNT}/media/root-ro"
   mount --move /media/root-rw "${ROOTMNT}/media/root-rw"

   # then, if 'ro' on the command line, it mounts /root read-only.
   mount -o remount,ro $ROOTMNT

  The script then exits, as ROOTMNT is now set up with a read-only mount
  of the overlayroot.  All the mounts it has done have been moved
  under ROOTMNT.

  On failure systemd reports:
     [  104.098833] systemd[1]: media-root\x2dro.mount: Found ordering cycle on 
-.mount/start
     [  104.109897] systemd[1]: media-root\x2dro.mount: Found dependency on 
media-root\x2dro.mount/start
     [  104.121386] systemd[1]: media-root\x2dro.mount: Unable to break cycle 
starting with media-root\x2dro.mount/start
     [  104.137591] systemd[1]: Requested transaction contains an unfixable 
cyclic ordering 

[Touch-packages] [Bug 1792168] Re: ifupdown hotplug dhcp fails due to udevadm RestrictAddressFamilies

[Scott Moser]

This is invalid.
It actually all still works because:
 udev hook /lib/udev/rules.d/80-ifupdown.rules calls /lib/udev/ifupdown-hotplug
 which calls
   systemctl --no-block start $(systemd-escape --template ifup@.service 
$INTERFACE)

Then the ifup@.service is what actually brings up the device.

That service is then not beholden to the udevadm restrcitions.


** Changed in: ifupdown (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1792168

Title:
  ifupdown hotplug dhcp fails due to udevadm RestrictAddressFamilies

Status in ifupdown package in Ubuntu:
  Invalid

Bug description:
  I haven't verified this, but I believe that ifupdown works through udevadm 
hooks.
  So udevadm hotplug event -> ifup eth0.
  Any subprocesses of a udevadm hook will be restricted by the 
systemd-udevd.service
  restrictions, which currently are
 RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6

  We found this when playing with udevamd hooks to bring up network
  devices on cosmic (netplan).

  root@b1:~# systemctl cat udev.service
  # /lib/systemd/system/systemd-udevd.service
  #  SPDX-License-Identifier: LGPL-2.1+
  #
  #  This file is part of systemd.
  #
  #  systemd is free software; you can redistribute it and/or modify it
  #  under the terms of the GNU Lesser General Public License as published by
  #  the Free Software Foundation; either version 2.1 of the License, or
  #  (at your option) any later version.

  [Unit]
  Description=udev Kernel Device Manager
  Documentation=man:systemd-udevd.service(8) man:udev(7)
  DefaultDependencies=no
  After=systemd-sysusers.service systemd-hwdb-update.service
  Before=sysinit.target
  ConditionPathIsReadWrite=/sys

  [Service]
  Type=notify
  OOMScoreAdjust=-1000
  Sockets=systemd-udevd-control.socket systemd-udevd-kernel.socket
  Restart=always
  RestartSec=0
  ExecStart=/lib/systemd/systemd-udevd
  KillMode=mixed
  WatchdogSec=3min
  TasksMax=infinity
  MountFlags=slave
  MemoryDenyWriteExecute=yes
  RestrictRealtime=yes
  RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
  SystemCallArchitectures=native
  LockPersonality=yes
  IPAddressDeny=any

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: ifupdown 0.8.17ubuntu1.1
  ProcVersionSignature: Ubuntu 4.17.0-9.10-generic 4.17.17
  Uname: Linux 4.17.0-9-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.3
  Architecture: amd64
  Date: Wed Sep 12 15:09:01 2018
  ProcEnviron:
   TERM=screen.xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: ifupdown
  UpgradeStatus: No upgrade log present (probably fresh install)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1792168] [NEW] ifupdown hotplug dhcp fails due to udevadm RestrictAddressFamilies

[Scott Moser]

Public bug reported:

I haven't verified this, but I believe that ifupdown works through udevadm 
hooks.
So udevadm hotplug event -> ifup eth0.
Any subprocesses of a udevadm hook will be restricted by the 
systemd-udevd.service
restrictions, which currently are
   RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6

We found this when playing with udevamd hooks to bring up network
devices on cosmic (netplan).

root@b1:~# systemctl cat udev.service
# /lib/systemd/system/systemd-udevd.service
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=udev Kernel Device Manager
Documentation=man:systemd-udevd.service(8) man:udev(7)
DefaultDependencies=no
After=systemd-sysusers.service systemd-hwdb-update.service
Before=sysinit.target
ConditionPathIsReadWrite=/sys

[Service]
Type=notify
OOMScoreAdjust=-1000
Sockets=systemd-udevd-control.socket systemd-udevd-kernel.socket
Restart=always
RestartSec=0
ExecStart=/lib/systemd/systemd-udevd
KillMode=mixed
WatchdogSec=3min
TasksMax=infinity
MountFlags=slave
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
SystemCallArchitectures=native
LockPersonality=yes
IPAddressDeny=any

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ifupdown 0.8.17ubuntu1.1
ProcVersionSignature: Ubuntu 4.17.0-9.10-generic 4.17.17
Uname: Linux 4.17.0-9-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.3
Architecture: amd64
Date: Wed Sep 12 15:09:01 2018
ProcEnviron:
 TERM=screen.xterm-256color
 PATH=(custom, no user)
 LANG=C.UTF-8
SourcePackage: ifupdown
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: ifupdown (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug bionic uec-images

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1792168

Title:
  ifupdown hotplug dhcp fails due to udevadm RestrictAddressFamilies

Status in ifupdown package in Ubuntu:
  New

Bug description:
  I haven't verified this, but I believe that ifupdown works through udevadm 
hooks.
  So udevadm hotplug event -> ifup eth0.
  Any subprocesses of a udevadm hook will be restricted by the 
systemd-udevd.service
  restrictions, which currently are
 RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6

  We found this when playing with udevamd hooks to bring up network
  devices on cosmic (netplan).

  root@b1:~# systemctl cat udev.service
  # /lib/systemd/system/systemd-udevd.service
  #  SPDX-License-Identifier: LGPL-2.1+
  #
  #  This file is part of systemd.
  #
  #  systemd is free software; you can redistribute it and/or modify it
  #  under the terms of the GNU Lesser General Public License as published by
  #  the Free Software Foundation; either version 2.1 of the License, or
  #  (at your option) any later version.

  [Unit]
  Description=udev Kernel Device Manager
  Documentation=man:systemd-udevd.service(8) man:udev(7)
  DefaultDependencies=no
  After=systemd-sysusers.service systemd-hwdb-update.service
  Before=sysinit.target
  ConditionPathIsReadWrite=/sys

  [Service]
  Type=notify
  OOMScoreAdjust=-1000
  Sockets=systemd-udevd-control.socket systemd-udevd-kernel.socket
  Restart=always
  RestartSec=0
  ExecStart=/lib/systemd/systemd-udevd
  KillMode=mixed
  WatchdogSec=3min
  TasksMax=infinity
  MountFlags=slave
  MemoryDenyWriteExecute=yes
  RestrictRealtime=yes
  RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
  SystemCallArchitectures=native
  LockPersonality=yes
  IPAddressDeny=any

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: ifupdown 0.8.17ubuntu1.1
  ProcVersionSignature: Ubuntu 4.17.0-9.10-generic 4.17.17
  Uname: Linux 4.17.0-9-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.3
  Architecture: amd64
  Date: Wed Sep 12 15:09:01 2018
  ProcEnviron:
   TERM=screen.xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: ifupdown
  UpgradeStatus: No upgrade log present (probably fresh install)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1788188] Re: transient systemd ordering cycle in boot with overlayroot

[Scott Moser]

I uploaded open-iscsi_2.0.874-5ubuntu8 which has the debug code
that we were toying with included.  It also includes a fix for
FTBFS bug 1791154.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1788188

Title:
  transient systemd ordering cycle in boot with overlayroot

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  open-iscsi test utilizes overlayroot to boot a cloud-image with root
  filesystem on a read-only iscsi server.

  The /etc/fstab file in the image looks like this:
    LABEL=cloudimg-rootfs   /ext4   defaults0 0
    #LABEL=UEFI /boot/efi   vfatdefaults0 0

  when init takes over from the initramfs, we have

    /proc/cmdline:
  nomodeset iscsi_initiator=maas-enlist
  iscsi_target_name=tgt-boot-test-2abbnj iscsi_target_ip=10.0.12.2
  iscsi_target_port=3260 iscsi_initiator=maas-enlist
  ip=maas-enlist:BOOTIF ro net.ifnames=0 BOOTIF_DEFAULT=eth0
  
root=/dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1
  overlayroot=tmpfs console=ttyS0
  ds=nocloud-net;seedfrom=http://10.0.12.2:32600/ init=/bin/bash

    /etc/fstab:
  # cat /etc/fstab
  #
  #  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,noauto 0 0
  /media/root-ro/ / overlay 
lowerdir=/media/root-ro/,upperdir=/media/root-rw/over0
  #LABEL=UEFI /boot/efi vfat defaults 0 0

   /root/root-ro/etc/fstab:
  LABEL=cloudimg-rootfs   /ext4   defaults0 0
  #LABEL=UEFI /boot/efi   vfatdefaults0 0

   /proc/mounts:
     sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
     proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
     udev /dev devtmpfs 
rw,nosuid,relatime,size=233748k,nr_inodes=58437,mode=755 0 0
     devpts /dev/pts devpts 
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
     tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=49288k,mode=755 0 0
     /dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1 
/media/root-ro ext4 ro,relatime 0 0
     tmpfs-root /media/root-rw tmpfs rw,relatime 0 0
     overlayroot / overlay 
ro,relatime,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_
 0 0

   /proc/1/mountinfo:
     21 28 0:20 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
     22 28 0:4 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
     23 28 0:6 / /dev rw,nosuid,relatime - devtmpfs udev 
rw,size=233748k,nr_inodes=58437,mode=755
     24 23 0:21 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts 
rw,gid=5,mode=620,ptmxmode=000
     25 28 0:22 / /run rw,nosuid,noexec,relatime - tmpfs tmpfs 
rw,size=49288k,mode=755
     26 28 8:1 / /media/root-ro ro,relatime - ext4 
/dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1 ro
     27 28 0:23 / /media/root-rw rw,relatime - tmpfs tmpfs-root rw
     28 0 0:24 / / ro,relatime - overlay overlayroot 
ro,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_

  overlayroot's scripts/init-bottom/overlayroot script [1] inherits a
  read-only mount of block device on mount point '$ROOTMNT'
  (ROOTMNT=/root). In order to set up the overlayroot, it does the
  following:

   mkdir /media/root-ro /media/root-rw # in the initramfs
   mount -t tmpfs tmpfs-root /media/root-rw
   mkdir /media/root-rw/overlay-workdir/_
   mount --move $ROOTMNT /media/root-ro
   mount -t overlay -o 
lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_
 overlayroot /root
   mkdir $ROOTMNT/media/root-ro
   mkdir $ROOTMNT/media/root-rw
   mount --move /media/root-ro "${ROOTMNT}/media/root-ro"
   mount --move /media/root-rw "${ROOTMNT}/media/root-rw"

   # then, if 'ro' on the command line, it mounts /root read-only.
   mount -o remount,ro $ROOTMNT

  The script then exits, as ROOTMNT is now set up with a read-only mount
  of the overlayroot.  All the mounts it has done have been moved
  under ROOTMNT.

  On failure systemd reports:
     [  104.098833] systemd[1]: media-root\x2dro.mount: Found ordering cycle on 
-.mount/start
     [  104.109897] systemd[1]: media-root\x2dro.mount: Found dependency on 
media-root\x2dro.mount/start
     [  104.121386] systemd[1]: media-root\x2dro.mount: Unable to break cycle 
starting with media-root\x2dro.mount/start
     [  104.137591] systemd[1]: Requested transaction contains an unfixable 
cyclic 

[Touch-packages] [Bug 1788188] Re: transient systemd ordering cycle in boot with overlayroot

[Scott Moser]

I've hit that 'retrigger' button 2 more times and have not seen failures.
I just did again. Don't know what to do. :-(

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1788188

Title:
  transient systemd ordering cycle in boot with overlayroot

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  open-iscsi test utilizes overlayroot to boot a cloud-image with root
  filesystem on a read-only iscsi server.

  The /etc/fstab file in the image looks like this:
    LABEL=cloudimg-rootfs   /ext4   defaults0 0
    #LABEL=UEFI /boot/efi   vfatdefaults0 0

  when init takes over from the initramfs, we have

    /proc/cmdline:
  nomodeset iscsi_initiator=maas-enlist
  iscsi_target_name=tgt-boot-test-2abbnj iscsi_target_ip=10.0.12.2
  iscsi_target_port=3260 iscsi_initiator=maas-enlist
  ip=maas-enlist:BOOTIF ro net.ifnames=0 BOOTIF_DEFAULT=eth0
  
root=/dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1
  overlayroot=tmpfs console=ttyS0
  ds=nocloud-net;seedfrom=http://10.0.12.2:32600/ init=/bin/bash

    /etc/fstab:
  # cat /etc/fstab
  #
  #  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,noauto 0 0
  /media/root-ro/ / overlay 
lowerdir=/media/root-ro/,upperdir=/media/root-rw/over0
  #LABEL=UEFI /boot/efi vfat defaults 0 0

   /root/root-ro/etc/fstab:
  LABEL=cloudimg-rootfs   /ext4   defaults0 0
  #LABEL=UEFI /boot/efi   vfatdefaults0 0

   /proc/mounts:
     sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
     proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
     udev /dev devtmpfs 
rw,nosuid,relatime,size=233748k,nr_inodes=58437,mode=755 0 0
     devpts /dev/pts devpts 
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
     tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=49288k,mode=755 0 0
     /dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1 
/media/root-ro ext4 ro,relatime 0 0
     tmpfs-root /media/root-rw tmpfs rw,relatime 0 0
     overlayroot / overlay 
ro,relatime,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_
 0 0

   /proc/1/mountinfo:
     21 28 0:20 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
     22 28 0:4 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
     23 28 0:6 / /dev rw,nosuid,relatime - devtmpfs udev 
rw,size=233748k,nr_inodes=58437,mode=755
     24 23 0:21 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts 
rw,gid=5,mode=620,ptmxmode=000
     25 28 0:22 / /run rw,nosuid,noexec,relatime - tmpfs tmpfs 
rw,size=49288k,mode=755
     26 28 8:1 / /media/root-ro ro,relatime - ext4 
/dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1 ro
     27 28 0:23 / /media/root-rw rw,relatime - tmpfs tmpfs-root rw
     28 0 0:24 / / ro,relatime - overlay overlayroot 
ro,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_

  overlayroot's scripts/init-bottom/overlayroot script [1] inherits a
  read-only mount of block device on mount point '$ROOTMNT'
  (ROOTMNT=/root). In order to set up the overlayroot, it does the
  following:

   mkdir /media/root-ro /media/root-rw # in the initramfs
   mount -t tmpfs tmpfs-root /media/root-rw
   mkdir /media/root-rw/overlay-workdir/_
   mount --move $ROOTMNT /media/root-ro
   mount -t overlay -o 
lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_
 overlayroot /root
   mkdir $ROOTMNT/media/root-ro
   mkdir $ROOTMNT/media/root-rw
   mount --move /media/root-ro "${ROOTMNT}/media/root-ro"
   mount --move /media/root-rw "${ROOTMNT}/media/root-rw"

   # then, if 'ro' on the command line, it mounts /root read-only.
   mount -o remount,ro $ROOTMNT

  The script then exits, as ROOTMNT is now set up with a read-only mount
  of the overlayroot.  All the mounts it has done have been moved
  under ROOTMNT.

  On failure systemd reports:
     [  104.098833] systemd[1]: media-root\x2dro.mount: Found ordering cycle on 
-.mount/start
     [  104.109897] systemd[1]: media-root\x2dro.mount: Found dependency on 
media-root\x2dro.mount/start
     [  104.121386] systemd[1]: media-root\x2dro.mount: Unable to break cycle 
starting with media-root\x2dro.mount/start
     [  104.137591] systemd[1]: Requested transaction contains an unfixable 
cyclic ordering dependency: Resource 

[Touch-packages] [Bug 1788188] Re: transient systemd ordering cycle in boot with overlayroot

[Scott Moser]

here is a pastebin of boot with systemd debugging.
 http://paste.ubuntu.com/p/vGTRh6WB3B/

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1788188

Title:
  transient systemd ordering cycle in boot with overlayroot

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  open-iscsi test utilizes overlayroot to boot a cloud-image with root
  filesystem on a read-only iscsi server.

  The /etc/fstab file in the image looks like this:
    LABEL=cloudimg-rootfs   /ext4   defaults0 0
    #LABEL=UEFI /boot/efi   vfatdefaults0 0

  when init takes over from the initramfs, we have

    /proc/cmdline:
  nomodeset iscsi_initiator=maas-enlist
  iscsi_target_name=tgt-boot-test-2abbnj iscsi_target_ip=10.0.12.2
  iscsi_target_port=3260 iscsi_initiator=maas-enlist
  ip=maas-enlist:BOOTIF ro net.ifnames=0 BOOTIF_DEFAULT=eth0
  
root=/dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1
  overlayroot=tmpfs console=ttyS0
  ds=nocloud-net;seedfrom=http://10.0.12.2:32600/ init=/bin/bash

    /etc/fstab:
  # cat /etc/fstab
  #
  #  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,noauto 0 0
  /media/root-ro/ / overlay 
lowerdir=/media/root-ro/,upperdir=/media/root-rw/over0
  #LABEL=UEFI /boot/efi vfat defaults 0 0

   /root/root-ro/etc/fstab:
  LABEL=cloudimg-rootfs   /ext4   defaults0 0
  #LABEL=UEFI /boot/efi   vfatdefaults0 0

   /proc/mounts:
     sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
     proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
     udev /dev devtmpfs 
rw,nosuid,relatime,size=233748k,nr_inodes=58437,mode=755 0 0
     devpts /dev/pts devpts 
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
     tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=49288k,mode=755 0 0
     /dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1 
/media/root-ro ext4 ro,relatime 0 0
     tmpfs-root /media/root-rw tmpfs rw,relatime 0 0
     overlayroot / overlay 
ro,relatime,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_
 0 0

   /proc/1/mountinfo:
     21 28 0:20 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
     22 28 0:4 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
     23 28 0:6 / /dev rw,nosuid,relatime - devtmpfs udev 
rw,size=233748k,nr_inodes=58437,mode=755
     24 23 0:21 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts 
rw,gid=5,mode=620,ptmxmode=000
     25 28 0:22 / /run rw,nosuid,noexec,relatime - tmpfs tmpfs 
rw,size=49288k,mode=755
     26 28 8:1 / /media/root-ro ro,relatime - ext4 
/dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1 ro
     27 28 0:23 / /media/root-rw rw,relatime - tmpfs tmpfs-root rw
     28 0 0:24 / / ro,relatime - overlay overlayroot 
ro,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_

  overlayroot's scripts/init-bottom/overlayroot script [1] inherits a
  read-only mount of block device on mount point '$ROOTMNT'
  (ROOTMNT=/root). In order to set up the overlayroot, it does the
  following:

   mkdir /media/root-ro /media/root-rw # in the initramfs
   mount -t tmpfs tmpfs-root /media/root-rw
   mkdir /media/root-rw/overlay-workdir/_
   mount --move $ROOTMNT /media/root-ro
   mount -t overlay -o 
lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_
 overlayroot /root
   mkdir $ROOTMNT/media/root-ro
   mkdir $ROOTMNT/media/root-rw
   mount --move /media/root-ro "${ROOTMNT}/media/root-ro"
   mount --move /media/root-rw "${ROOTMNT}/media/root-rw"

   # then, if 'ro' on the command line, it mounts /root read-only.
   mount -o remount,ro $ROOTMNT

  The script then exits, as ROOTMNT is now set up with a read-only mount
  of the overlayroot.  All the mounts it has done have been moved
  under ROOTMNT.

  On failure systemd reports:
     [  104.098833] systemd[1]: media-root\x2dro.mount: Found ordering cycle on 
-.mount/start
     [  104.109897] systemd[1]: media-root\x2dro.mount: Found dependency on 
media-root\x2dro.mount/start
     [  104.121386] systemd[1]: media-root\x2dro.mount: Unable to break cycle 
starting with media-root\x2dro.mount/start
     [  104.137591] systemd[1]: Requested transaction contains an unfixable 
cyclic ordering dependency: Resource deadlock avoided

  On 

[Touch-packages] [Bug 1788188] Re: transient systemd ordering cycle in boot with overlayroot

[Scott Moser]

I pushed a branch up to
 
https://code.launchpad.net/~smoser/ubuntu/+source/open-iscsi/+git/open-iscsi/+ref/bug/1788188-debug
that Christian and I are trying to get some additional debug information out of 
a failure.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1788188

Title:
  transient systemd ordering cycle in boot with overlayroot

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  open-iscsi test utilizes overlayroot to boot a cloud-image with root
  filesystem on a read-only iscsi server.

  The /etc/fstab file in the image looks like this:
    LABEL=cloudimg-rootfs   /ext4   defaults0 0
    #LABEL=UEFI /boot/efi   vfatdefaults0 0

  when init takes over from the initramfs, we have

    /proc/cmdline:
  nomodeset iscsi_initiator=maas-enlist
  iscsi_target_name=tgt-boot-test-2abbnj iscsi_target_ip=10.0.12.2
  iscsi_target_port=3260 iscsi_initiator=maas-enlist
  ip=maas-enlist:BOOTIF ro net.ifnames=0 BOOTIF_DEFAULT=eth0
  
root=/dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1
  overlayroot=tmpfs console=ttyS0
  ds=nocloud-net;seedfrom=http://10.0.12.2:32600/ init=/bin/bash

    /etc/fstab:
  # cat /etc/fstab
  #
  #  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,noauto 0 0
  /media/root-ro/ / overlay 
lowerdir=/media/root-ro/,upperdir=/media/root-rw/over0
  #LABEL=UEFI /boot/efi vfat defaults 0 0

   /root/root-ro/etc/fstab:
  LABEL=cloudimg-rootfs   /ext4   defaults0 0
  #LABEL=UEFI /boot/efi   vfatdefaults0 0

   /proc/mounts:
     sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
     proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
     udev /dev devtmpfs 
rw,nosuid,relatime,size=233748k,nr_inodes=58437,mode=755 0 0
     devpts /dev/pts devpts 
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
     tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=49288k,mode=755 0 0
     /dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1 
/media/root-ro ext4 ro,relatime 0 0
     tmpfs-root /media/root-rw tmpfs rw,relatime 0 0
     overlayroot / overlay 
ro,relatime,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_
 0 0

   /proc/1/mountinfo:
     21 28 0:20 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
     22 28 0:4 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
     23 28 0:6 / /dev rw,nosuid,relatime - devtmpfs udev 
rw,size=233748k,nr_inodes=58437,mode=755
     24 23 0:21 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts 
rw,gid=5,mode=620,ptmxmode=000
     25 28 0:22 / /run rw,nosuid,noexec,relatime - tmpfs tmpfs 
rw,size=49288k,mode=755
     26 28 8:1 / /media/root-ro ro,relatime - ext4 
/dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1 ro
     27 28 0:23 / /media/root-rw rw,relatime - tmpfs tmpfs-root rw
     28 0 0:24 / / ro,relatime - overlay overlayroot 
ro,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_

  overlayroot's scripts/init-bottom/overlayroot script [1] inherits a
  read-only mount of block device on mount point '$ROOTMNT'
  (ROOTMNT=/root). In order to set up the overlayroot, it does the
  following:

   mkdir /media/root-ro /media/root-rw # in the initramfs
   mount -t tmpfs tmpfs-root /media/root-rw
   mkdir /media/root-rw/overlay-workdir/_
   mount --move $ROOTMNT /media/root-ro
   mount -t overlay -o 
lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_
 overlayroot /root
   mkdir $ROOTMNT/media/root-ro
   mkdir $ROOTMNT/media/root-rw
   mount --move /media/root-ro "${ROOTMNT}/media/root-ro"
   mount --move /media/root-rw "${ROOTMNT}/media/root-rw"

   # then, if 'ro' on the command line, it mounts /root read-only.
   mount -o remount,ro $ROOTMNT

  The script then exits, as ROOTMNT is now set up with a read-only mount
  of the overlayroot.  All the mounts it has done have been moved
  under ROOTMNT.

  On failure systemd reports:
     [  104.098833] systemd[1]: media-root\x2dro.mount: Found ordering cycle on 
-.mount/start
     [  104.109897] systemd[1]: media-root\x2dro.mount: Found dependency on 
media-root\x2dro.mount/start
     [  104.121386] systemd[1]: media-root\x2dro.mount: Unable to break cycle 
starting with media-root\x2dro.mount/start
     [  

[Touch-packages] [Bug 1788188] [NEW] transient systemd ordering cycle in boot with overlayroot

[Scott Moser]

Public bug reported:

open-iscsi test utilizes overlayroot to boot a cloud-image with root
filesystem on a read-only iscsi server.

The /etc/fstab file in the image looks like this:
  LABEL=cloudimg-rootfs   /ext4   defaults0 0
  #LABEL=UEFI /boot/efi   vfatdefaults0 0

when init takes over from the initramfs, we have

  /proc/cmdline:
nomodeset iscsi_initiator=maas-enlist
iscsi_target_name=tgt-boot-test-2abbnj iscsi_target_ip=10.0.12.2
iscsi_target_port=3260 iscsi_initiator=maas-enlist
ip=maas-enlist:BOOTIF ro net.ifnames=0 BOOTIF_DEFAULT=eth0

root=/dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1
overlayroot=tmpfs console=ttyS0
ds=nocloud-net;seedfrom=http://10.0.12.2:32600/ init=/bin/bash

  /etc/fstab:
# cat /etc/fstab
#
#  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,noauto 0 0
/media/root-ro/ / overlay 
lowerdir=/media/root-ro/,upperdir=/media/root-rw/over0
#LABEL=UEFI /boot/efi vfat defaults 0 0

 /root/root-ro/etc/fstab:
LABEL=cloudimg-rootfs   /ext4   defaults0 0
#LABEL=UEFI /boot/efi   vfatdefaults0 0

 /proc/mounts:
   sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
   proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
   udev /dev devtmpfs rw,nosuid,relatime,size=233748k,nr_inodes=58437,mode=755 
0 0
   devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 
0 0
   tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=49288k,mode=755 0 0
   /dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1 
/media/root-ro ext4 ro,relatime 0 0
   tmpfs-root /media/root-rw tmpfs rw,relatime 0 0
   overlayroot / overlay 
ro,relatime,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_
 0 0

 /proc/1/mountinfo:
   21 28 0:20 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
   22 28 0:4 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
   23 28 0:6 / /dev rw,nosuid,relatime - devtmpfs udev 
rw,size=233748k,nr_inodes=58437,mode=755
   24 23 0:21 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts 
rw,gid=5,mode=620,ptmxmode=000
   25 28 0:22 / /run rw,nosuid,noexec,relatime - tmpfs tmpfs 
rw,size=49288k,mode=755
   26 28 8:1 / /media/root-ro ro,relatime - ext4 
/dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-2abbnj-lun-1-part1 ro
   27 28 0:23 / /media/root-rw rw,relatime - tmpfs tmpfs-root rw
   28 0 0:24 / / ro,relatime - overlay overlayroot 
ro,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_

overlayroot's scripts/init-bottom/overlayroot script [1] inherits a
read-only mount of block device on mount point '$ROOTMNT'
(ROOTMNT=/root). In order to set up the overlayroot, it does the
following:

 mkdir /media/root-ro /media/root-rw # in the initramfs
 mount -t tmpfs tmpfs-root /media/root-rw
 mkdir /media/root-rw/overlay-workdir/_
 mount --move $ROOTMNT /media/root-ro
 mount -t overlay -o 
lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_
 overlayroot /root
 mkdir $ROOTMNT/media/root-ro
 mkdir $ROOTMNT/media/root-rw
 mount --move /media/root-ro "${ROOTMNT}/media/root-ro"
 mount --move /media/root-rw "${ROOTMNT}/media/root-rw"

 # then, if 'ro' on the command line, it mounts /root read-only.
 mount -o remount,ro $ROOTMNT

The script then exits, as ROOTMNT is now set up with a read-only mount
of the overlayroot.  All the mounts it has done have been moved
under ROOTMNT.

On failure systemd reports:
   [  104.098833] systemd[1]: media-root\x2dro.mount: Found ordering cycle on 
-.mount/start
   [  104.109897] systemd[1]: media-root\x2dro.mount: Found dependency on 
media-root\x2dro.mount/start
   [  104.121386] systemd[1]: media-root\x2dro.mount: Unable to break cycle 
starting with media-root\x2dro.mount/start
   [  104.137591] systemd[1]: Requested transaction contains an unfixable 
cyclic ordering dependency: Resource deadlock avoided

On successful boot, we can login and see:

$  find /run/systemd/ -name "*.mount" | xargs ls -l
-rw-r--r-- 1 root root 322 Aug 21 13:55 /run/systemd/generator/-.mount
lrwxrwxrwx 1 root root  10 Aug 21 13:55 
/run/systemd/generator/local-fs.target.requires/-.mount -> ../-.mount
lrwxrwxrwx 1 root root  32 Aug 21 13:55 
/run/systemd/units/invocation:dev-hugepages.mount -> 
b847fc2d06b54b1ab86a6f526d149522
lrwxrwxrwx 1 root root  32 Aug 21 13:55 
/run/systemd/units/invocation:dev-mqueue.mount -> 
f991d3bfe35d4e2bb9aa86677ff31d70
lrwxrwxrwx 

[Touch-packages] [Bug 1134036] Re: Failure when using ssh with a locale that is not configured on the server

[Scott Moser]

@mwhudson,
your suggested change seems reasonable to me.
I don't love the use of 'eval', but it seems reasonably safe here.

Instead of quoting you could just reject argv[1] input if it
had characters other than [a-zA-z_.-] .  Perhaps that makes
this more difficult.

Also, maybe you should try to 'setlocale(argv[1])' to check that
it is valid ? Ie, as it is right now if input is bogus then
the program will exit success and write bogus output.

$ LC_ALL=asdf /tmp/my-test bogus ; echo $?
LC_ALL='bogus'
0

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to base-files in Ubuntu.
https://bugs.launchpad.net/bugs/1134036

Title:
  Failure when using ssh with a locale that is not configured on the
  server

Status in base-files package in Ubuntu:
  In Progress
Status in maas package in Ubuntu:
  Invalid

Bug description:
  If LC_ALL is not set (which seems to be the default on a few server
  installations I've done now), mid way through installing, you get this
  backtrace and then the installation just hangs.  You can ctrl-c out of
  it but the package is left half configured.

  Traceback (most recent call last):
    File "/usr/bin/django-admin", line 5, in 
  management.execute_from_command_line()
    File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 443, in execute_from_command_line
  utility.execute()
    File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 382, in execute
  self.fetch_command(subcommand).run_from_argv(self.argv)
    File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", 
line 196, in run_from_argv
  self.execute(*args, **options.__dict__)
    File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", 
line 232, in execute
  output = self.handle(*args, **options)
    File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", 
line 371, in handle
  return self.handle_noargs(**options)
    File 
"/usr/lib/python2.7/dist-packages/south/management/commands/syncdb.py", line 
90, in handle_noargs
  syncdb.Command().execute(**options)
    File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", 
line 232, in execute
  output = self.handle(*args, **options)
    File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", 
line 371, in handle
  return self.handle_noargs(**options)
    File 
"/usr/lib/python2.7/dist-packages/django/core/management/commands/syncdb.py", 
line 57, in handle_noargs
  cursor = connection.cursor()
    File "/usr/lib/python2.7/dist-packages/django/db/backends/__init__.py", 
line 308, in cursor
  cursor = util.CursorWrapper(self._cursor(), self)
    File 
"/usr/lib/python2.7/dist-packages/django/db/backends/postgresql_psycopg2/base.py",
 line 177, in _cursor
  self.connection = Database.connect(**conn_params)
    File "/usr/lib/python2.7/dist-packages/psycopg2/__init__.py", line 179, in 
connect
  connection_factory=connection_factory, async=async)
  psycopg2.OperationalError: FATAL:  password authentication failed for user 
"maas"
  FATAL:  password authentication failed for user "maas"

  
  Related bugs:
   * bug 969462: [postgres] fails to start after install if invalid locale is 
set

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1134036/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1785683] [NEW] dep8 tests fail on non-intel

[Scott Moser]

Public bug reported:

According to proposed migration
 
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html

Software-properties tests have 'Always failed' on arch other than intel.

This failure is not specific to dep8 but rather can be seen just by running
the unit tests.

In a fresh non-intel container:
 (launched with 'lxc launch ubuntu-daily:cosmic c1' on ppc64 host)

 % apt-get update -q && apt-get build-dep -y software-properties
 % apt-get install bzr --no-install-recommends
 % bzr branch lp:software-properties
 % cd software-properties
 ## taken from debian/tests/run-tests
 % LC_ALL=C.UTF-8 xvfb-run -e "/tmp/xvfb.log" python3 -m unittest tests/test*.py


Or just run the failing test:
 % LC_ALL=C.UTF-8 xvfb-run -e "/tmp/xvfb.log" python3 -m unittest \
tests.test_dbus.TestDBus.test_enable_enable_disable_source_code_sources


 
 $ LC_ALL=C.UTF-8 xvfb-run -e "/tmp/xvfb.log" python3 -m unittest 
tests.test_dbus.TestDBus.test_enable_enable_disable_source_code_sources


software-properties (0.96.24.36 to 0.96.26)

Maintainer: Michael Vogt
3 days old
autopkgtest for crash/7.2.3+real-1: amd64: Pass, arm64: Pass, armhf: Pass, 
i386: Pass, ppc64el: Pass, s390x: Pass
autopkgtest for livecd-rootfs/2.533: amd64: Pass, arm64: Pass, armhf: Pass, 
i386: Pass, ppc64el: Pass, s390x: Pass
autopkgtest for software-properties/0.96.26: amd64: Pass, arm64: Always 
failed, armhf: Always failed, i386: Pass, ppc64el: Always failed, s390x: Always 
failed
Valid candidate

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: software-properties-common 0.96.24.36
ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
Uname: Linux 4.15.0-29-generic ppc64le
ApportVersion: 2.20.10-0ubuntu7
Architecture: ppc64el
Date: Mon Aug  6 17:20:32 2018
PackageArchitecture: all
ProcEnviron:
 TERM=screen-256color
 PATH=(custom, no user)
 LANG=C.UTF-8
ProcLoadAvg: 0.15 0.11 0.08 1/2275 21089
ProcLocks:
 9: POSIX  ADVISORY  WRITE 187 00:3c:129 0 EOF
 14: FLOCK  ADVISORY  WRITE 193 00:3c:143 0 EOF
ProcSwaps:
 Filename   TypeSizeUsedPriority
 nonevirtual8388544 8388544 0
ProcVersion: Linux version 4.15.0-29-generic (buildd@bos02-ppc64el-015) (gcc 
version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #31-Ubuntu SMP Tue Jul 17 15:37:15 UTC 
2018
SourcePackage: software-properties
UpgradeStatus: No upgrade log present (probably fresh install)
VarLogDump_list: total 0
cpu_cores: Number of cores present = 20
cpu_coreson: Number of cores online = 20
cpu_smt: SMT=8

** Affects: software-properties (Ubuntu)
 Importance: Medium
 Assignee: Scott Moser (smoser)
 Status: Confirmed


** Tags: apport-bug cosmic ppc64el uec-images

** Changed in: software-properties (Ubuntu)
   Status: New => Confirmed

** Changed in: software-properties (Ubuntu)
   Importance: Undecided => Medium

** Changed in: software-properties (Ubuntu)
 Assignee: (unassigned) => Scott Moser (smoser)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1785683

Title:
  dep8 tests fail on non-intel

Status in software-properties package in Ubuntu:
  Confirmed

Bug description:
  According to proposed migration
   
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html

  Software-properties tests have 'Always failed' on arch other than
  intel.

  This failure is not specific to dep8 but rather can be seen just by running
  the unit tests.

  In a fresh non-intel container:
   (launched with 'lxc launch ubuntu-daily:cosmic c1' on ppc64 host)

   % apt-get update -q && apt-get build-dep -y software-properties
   % apt-get install bzr --no-install-recommends
   % bzr branch lp:software-properties
   % cd software-properties
   ## taken from debian/tests/run-tests
   % LC_ALL=C.UTF-8 xvfb-run -e "/tmp/xvfb.log" python3 -m unittest 
tests/test*.py

  
  Or just run the failing test:
   % LC_ALL=C.UTF-8 xvfb-run -e "/tmp/xvfb.log" python3 -m unittest \
  tests.test_dbus.TestDBus.test_enable_enable_disable_source_code_sources

  
   
   $ LC_ALL=C.UTF-8 xvfb-run -e "/tmp/xvfb.log" python3 -m unittest 
tests.test_dbus.TestDBus.test_enable_enable_disable_source_code_sources

  
  software-properties (0.96.24.36 to 0.96.26)

  Maintainer: Michael Vogt
  3 days old
  autopkgtest for crash/7.2.3+real-1: amd64: Pass, arm64: Pass, armhf: 
Pass, i386: Pass, ppc64el: Pass, s390x: Pass
  autopkgtest for livecd-rootfs/2.533: amd64: Pass, arm64: Pass, armhf: 
Pass, i386: Pass, ppc64el: Pass, s390x: Pass
  autopkgtest for software-properties/0.96.26: amd64: Pass, arm64: Always 
failed, armhf: Always failed, i386: Pass, ppc64el: Always failed, s390x: Always 
failed
  

[Touch-packages] [Bug 1667725] Re: [feature request] make full ppa signing public key available over https

[Scott Moser]

** Changed in: software-properties (Ubuntu)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1667725

Title:
  [feature request] make full ppa signing public key available over
  https

Status in Launchpad itself:
  Fix Released
Status in software-properties package in Ubuntu:
  In Progress

Bug description:
  Currently, for a ppa, launchpad makes the long key fingerprint
  available over https. I'd like to request that it also make the full
  public key available over https.

  Many people use add-apt-repository extensively for using ppas ('add-
  apt-repository -y smoser/archive')

  As I understand it, that basically does:
   a. request the 'archive urls', 'description' and long key fingerprint over 
https from launchpad.net
   b. does gpg --recv  from 
hkp://keyserver.ubuntu.com:80/ (or the --keyserver argument)
   c. adds the result of 'b' to apt using 'apt-key'

  Since launchpad is the owner of the signing key for the ppa, why not
  have it just give us the full public key over the same api that it
  provides the other bits of information?

  My experience is that gpg servers are less reliable than we'd like,
  and even if they were as reliable as launchpad, any use of a ppa now
  effectively depends on 2 external systems when 1 could suffice.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1667725] Re: [feature request] make full ppa signing public key available over https

[Scott Moser]

** Also affects: software-properties (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: software-properties (Ubuntu)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1667725

Title:
  [feature request] make full ppa signing public key available over
  https

Status in Launchpad itself:
  Fix Released
Status in software-properties package in Ubuntu:
  In Progress

Bug description:
  Currently, for a ppa, launchpad makes the long key fingerprint
  available over https. I'd like to request that it also make the full
  public key available over https.

  Many people use add-apt-repository extensively for using ppas ('add-
  apt-repository -y smoser/archive')

  As I understand it, that basically does:
   a. request the 'archive urls', 'description' and long key fingerprint over 
https from launchpad.net
   b. does gpg --recv  from 
hkp://keyserver.ubuntu.com:80/ (or the --keyserver argument)
   c. adds the result of 'b' to apt using 'apt-key'

  Since launchpad is the owner of the signing key for the ppa, why not
  have it just give us the full public key over the same api that it
  provides the other bits of information?

  My experience is that gpg servers are less reliable than we'd like,
  and even if they were as reliable as launchpad, any use of a ppa now
  effectively depends on 2 external systems when 1 could suffice.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1724623] Re: Update ubuntu cloud info

[Scott Moser]

cloud-init can collect relevant logs with 'cloud-init collect-logs'

that is what we tell people to run (and what gets done with 'ubuntu-bug
cloud-init').

I know that is not exactly what you're after.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1724623

Title:
  Update ubuntu cloud info

Status in apport package in Ubuntu:
  New

Bug description:
  add_cloud_info() in data/general-hooks/ubuntu.py needs an overhaul.

  Issues:
   - Using the presence of cloud-init to flag an image as a cloud image is 
incorrect now that ubuntu-server includes cloud-init (and ubuntu-core images)
   - Using the presence of EC2 metadata source is incorrect as many non-EC2 
clouds provide EC2 metadata.  Thus we have bugs like bug #1722946 that are 
tagged as an 'ec2-images' bug which are clearly on openstack
   - Marking all bugs that have cloud-init but no EC2 metadata source as an 
'uec-images' bug uses a name that no longer has meaning.

  Solution:
   - If cloud-init is present, check for /etc/cloud/build.info to indicate an 
Ubuntu cloud images, tag as 'cloud-images'.  Pull the build_name and serial 
from that file into the bug comments.
   - If cloud-init is present, check for the presence of 
/run/cloud-init/cloud.cfg.  Parse this yaml to determine the datasource type.  
Add the datasource used to the bug comment.

  I have filed bug #1724626 to ask cloud-init development to surface
  more information from ds-identify to help ID the cloud so that we can
  better tag/annotate the bug.  There may also be some info we can get
  to indicate the image ID on more clouds than just AWS.  At a minimum I
  would like to see dsidentify make the EC2 platform it found available
  for consumers in cloud.cfg.  This would allow us to identify AWS EC2
  from look-alike datasources so that we can tag a bug as ec2-images for
  bug really on AWS and add EC2 specific fields to the
  description/attachments.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1732028] Re: timeout in iscsi boot fail with overlayroot [open-iscsi autopkg tests on LP Infra]

[Scott Moser]

i attached as reference
 https://hackmd.io/E0ydu7Y7QEe-kroPb6-OOA
at some point we can improve the doc in the debian/tests directory with that.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1732028

Title:
  timeout in iscsi boot fail with overlayroot [open-iscsi autopkg tests
  on LP Infra]

Status in open-iscsi package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  This issue keeps cropping up.  It shows itself in open-iscsi autopkg tests.
  I think it might just be "really slow system".  It seems the timeout is only
   1 minute 30 seconds for the disk to appear, and in a happy run you
  might see something very close:

  [K[   [0;31m*[0;1;31m*[0m[0;31m*[0m] A start job is running for 
dev-disk…-UEFI.device (1min 29s / 1min 32s)
  [K[  [0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for 
dev-disk…-UEFI.device (1min 30s / 1min 32s)
  [K[[0;32m  OK  [0m] Found device VIRTUAL-DISK UEFI.
   Mounting /boot/efi...

  ---
  There is information on the open-iscsi tests at [1].
    [1] 
https://git.launchpad.net/~usd-import-team/ubuntu/+source/open-iscsi/tree/debian/tests/README-boot-test.md

  The tests set up an iscsi target and boot a kvm guest off that read-
  only root with overlayroot.

  # get open-iscsi source
  $ apt-get source open-iscsi
  $ cd open-iscsi-2.0.874/

  $ sudo apt-get install -qy simplestreams tgt qemu-system-x86 \
   cloud-image-utils distro-info
  $ cd open-iscsi-2.0.874/

  ## we're now mostly following debian/tests/README-boot-test.md
  # download the image and get kernel/initrd
  $ PATH=$PWD/debian/tests:$PATH
  $ get-image bionic.d bionic
  $ sudo `which patch-image` \
  --kernel=bionic.d/kernel --initrd=bionic.d/initrd bionic.d/disk.img

  $ tgt-boot-test -v bionic.d/disk.img bionic.d/kernel bionic.d/initrd
  

  Success is being able to log in with 'ubuntu' and 'passw0rd'.
  Failure as seen in the log is dropping into an emergency shell.

  Once inside (this was successful) you'll see a mostly sane system.
  Some things to note:
  a.) tgt-boot-test boots without kvm enabled.  This is because using
   kvm with qemu in nested virt would cause system lockups. Its slower
  but more reliable to go wtihout.
  b.) under bug 1723183 I  made overlayroot comment out the root filesystem
  from the rendered /etc/fstab.  That was because systemd got confused and
  assumed that /media/root-ro had to be on top of /.
  c.) you can enable or disable kvm by setting _USE_KVM=0 or _USE_KVM=1
     in your environment.

  $ grep -v "^# " /etc/fstab
  #
  #
  #LABEL=cloudimg-rootfs /media/root-ro/ ext4 ro,defaults,noauto 0 0
  /media/root-ro/ / overlay 
lowerdir=/media/root-ro/,upperdir=/media/root-rw/overl
  ay/,workdir=/media/root-rw/overlay-workdir/_ 0 0
  LABEL=UEFI /boot/efi vfat defaults 0 0 # overlayroot:fs-unsupported

  $ sudo blkid
  /dev/sda1: LABEL="cloudimg-rootfs" 
UUID="7b1980bd-9102-4356-8df0-ec7a0c062411" TYPE="ext4" 
PARTUUID="c0b5ace0-4703-4667-babb-3d38137cab88"
  /dev/sda15: LABEL="UEFI" UUID="B177-3CC9" TYPE="vfat" 
PARTUUID="0ab0b9fd-2c28-4724-857a-1559f0cf76ea"
  /dev/sda14: PARTUUID="221662d6-cab0-4290-ba1c-e72acf2bf193"

  $ cat /run/systemd/generator/local-fs.target.requires/boot-efi.mount
  # Automatically generated by systemd-fstab-generator

  [Unit]
  SourcePath=/etc/fstab
  Documentation=man:fstab(5) man:systemd-fstab-generator(8)
  Before=local-fs.target

  [Mount]
  Where=/boot/efi
  What=/dev/disk/by-label/UEFI
  Type=vfat

  Related bugs:
   * bug 1680197: Zesty deployments failing sporadically
   * bug 1723183: transient systemd ordering issue when using overlayroot
   * bug 1666573: transient systemd ordering cycle in boot with overlayroot ver 
read-only open-iscsi root 

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 234-2ubuntu12
  ProcVersionSignature: User Name 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu4
  Architecture: amd64
  Date: Mon Nov 13 21:06:36 2017
  Lsusb: Error: command ['lsusb'] failed with exit code 1:
  MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
  ProcEnviron:
   TERM=vt220
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: nomodeset iscsi_initiator=maas-enlist 
iscsi_target_name=tgt-boot-test-7xuhwl iscsi_target_ip=10.0.12.2 
iscsi_target_port=3260 iscsi_initiator=maas-enlist ip=maas-enlist:BOOTIF ro 
net.ifnames=0 BOOTIF_DEFAULT=eth0 
root=/dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-7xuhwl-lun-1-part1 
overlayroot=tmpfs console=ttyS0 ds=nocloud-net;seedfrom=http://10.0.12.2:32600/
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/01/2014
  dmi.bios.vendor: SeaBIOS
  dmi.bios.version: 1.10.2-1ubuntu1
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU

[Touch-packages] [Bug 1732028] Re: timeout in iscsi boot fail with overlayroot [open-iscsi autopkg tests on LP Infra]

[Scott Moser]

** Description changed:

  This issue keeps cropping up.  It shows itself in open-iscsi autopkg tests.
  I think it might just be "really slow system".  It seems the timeout is only
-  1 minute 30 seconds for the disk to appear, and in a happy run you
+  1 minute 30 seconds for the disk to appear, and in a happy run you
  might see something very close:
  
  [K[   [0;31m*[0;1;31m*[0m[0;31m*[0m] A start job is running for 
dev-disk…-UEFI.device (1min 29s / 1min 32s)
  [K[  [0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for 
dev-disk…-UEFI.device (1min 30s / 1min 32s)
  [K[[0;32m  OK  [0m] Found device VIRTUAL-DISK UEFI.
-  Mounting /boot/efi...
+  Mounting /boot/efi...
  
  ---
  There is information on the open-iscsi tests at [1].
-   [1] 
https://git.launchpad.net/~usd-import-team/ubuntu/+source/open-iscsi/tree/debian/tests/README-boot-test.md
+   [1] 
https://git.launchpad.net/~usd-import-team/ubuntu/+source/open-iscsi/tree/debian/tests/README-boot-test.md
  
  The tests set up an iscsi target and boot a kvm guest off that read-only
  root with overlayroot.
  
  # get open-iscsi source
  $ apt-get source open-iscsi
  $ cd open-iscsi-2.0.874/
  
  $ sudo apt-get install -qy simplestreams tgt qemu-system-x86 \
-  cloud-image-utils distro-info
+  cloud-image-utils distro-info
  $ cd open-iscsi-2.0.874/
  
  ## we're now mostly following debian/tests/README-boot-test.md
  # download the image and get kernel/initrd
  $ PATH=$PWD/debian/tests:$PATH
- $ get-image bionic.d bionic 
+ $ get-image bionic.d bionic
  $ sudo `which patch-image` \
- --kernel=bionic.d/kernel --initrd=bionic.d/initrd bionic.d/disk.img
+ --kernel=bionic.d/kernel --initrd=bionic.d/initrd bionic.d/disk.img
  
  $ tgt-boot-test -v bionic.d/disk.img bionic.d/kernel bionic.d/initrd
  
  
  Success is being able to log in with 'ubuntu' and 'passw0rd'.
  Failure as seen in the log is dropping into an emergency shell.
  
  Once inside (this was successful) you'll see a mostly sane system.
  Some things to note:
  a.) tgt-boot-test boots without kvm enabled.  This is because using
-  kvm with qemu in nested virt would cause system lockups. Its slower
+  kvm with qemu in nested virt would cause system lockups. Its slower
  but more reliable to go wtihout.
  b.) under bug 1723183 I  made overlayroot comment out the root filesystem
  from the rendered /etc/fstab.  That was because systemd got confused and
  assumed that /media/root-ro had to be on top of /.
  c.) you can enable or disable kvm by setting _USE_KVM=0 or _USE_KVM=1
-in your environment.
+    in your environment.
  
  $ grep -v "^# " /etc/fstab
  #
  #
  #LABEL=cloudimg-rootfs /media/root-ro/ ext4 ro,defaults,noauto 0 0
  /media/root-ro/ / overlay 
lowerdir=/media/root-ro/,upperdir=/media/root-rw/overl
  ay/,workdir=/media/root-rw/overlay-workdir/_ 0 0
  LABEL=UEFI /boot/efi vfat defaults 0 0 # overlayroot:fs-unsupported
  
  $ sudo blkid
  /dev/sda1: LABEL="cloudimg-rootfs" 
UUID="7b1980bd-9102-4356-8df0-ec7a0c062411" TYPE="ext4" 
PARTUUID="c0b5ace0-4703-4667-babb-3d38137cab88"
  /dev/sda15: LABEL="UEFI" UUID="B177-3CC9" TYPE="vfat" 
PARTUUID="0ab0b9fd-2c28-4724-857a-1559f0cf76ea"
  /dev/sda14: PARTUUID="221662d6-cab0-4290-ba1c-e72acf2bf193"
  
  $ cat /run/systemd/generator/local-fs.target.requires/boot-efi.mount
  # Automatically generated by systemd-fstab-generator
  
  [Unit]
  SourcePath=/etc/fstab
  Documentation=man:fstab(5) man:systemd-fstab-generator(8)
  Before=local-fs.target
  
  [Mount]
  Where=/boot/efi
  What=/dev/disk/by-label/UEFI
  Type=vfat
  
  Related bugs:
-  * bug 1680197: Zesty deployments failing sporadically
-  * bug 1723183: transient systemd ordering issue when using overlayroot
+  * bug 1680197: Zesty deployments failing sporadically
+  * bug 1723183: transient systemd ordering issue when using overlayroot
+  * bug 1666573: transient systemd ordering cycle in boot with overlayroot ver 
read-only open-iscsi root 
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 234-2ubuntu12
  ProcVersionSignature: User Name 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu4
  Architecture: amd64
  Date: Mon Nov 13 21:06:36 2017
  Lsusb: Error: command ['lsusb'] failed with exit code 1:
  MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
  ProcEnviron:
-  TERM=vt220
-  PATH=(custom, no user)
-  XDG_RUNTIME_DIR=
-  LANG=C.UTF-8
-  SHELL=/bin/bash
+  TERM=vt220
+  PATH=(custom, no user)
+  XDG_RUNTIME_DIR=
+  LANG=C.UTF-8
+  SHELL=/bin/bash
  ProcKernelCmdLine: nomodeset iscsi_initiator=maas-enlist 
iscsi_target_name=tgt-boot-test-7xuhwl iscsi_target_ip=10.0.12.2 
iscsi_target_port=3260 iscsi_initiator=maas-enlist ip=maas-enlist:BOOTIF ro 
net.ifnames=0 BOOTIF_DEFAULT=eth0 
root=/dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-7xuhwl-lun-1-part1 
overlayroot=tmpfs console=ttyS0 ds=nocloud-net;seedfrom=http://10.0.12.2:32600/
  SourcePackage: 

[Touch-packages] [Bug 1779302] Re: should retry reading key from keyserver (in _recv_key)

[Scott Moser]

I saw this "in the wild" with /var/log/cloud-init.log showing:

2018-07-09 15:20:22,666 - util.py[DEBUG]: Running command 
['add-apt-repository', 'cloud-archive:ocata'] with allowed return codes [0] 
(shell=False, capture=True)
2018-07-09 15:20:24,907 - cc_apt_configure.py[ERROR]: add-apt-repository failed.
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", 
line 615, in add_apt_sources
util.subp(["add-apt-repository", source], target=target)
  File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1957, in subp
cmd=args)
cloudinit.util.ProcessExecutionError: Unexpected error while running command.
Command: ['add-apt-repository', 'cloud-archive:ocata']
Exit code: 1
Reason: -
Stdout:  Ubuntu Cloud Archive for OpenStack Ocata
 More info: https://wiki.ubuntu.com/ServerTeam/CloudArchive
Reading package lists...
Building dependency tree...
Reading state information...
Failed to add key.
Stderr: E: Unable to locate package ubuntu-cloud-keyring


** Description changed:

  Some recent events have made keyservers less reliable than they were
  previously:
-   https://bitbucket.org/skskeyserver/sks-keyserver/issues/57
-   https://bitbucket.org/skskeyserver/sks-keyserver/issues/60
+   https://bitbucket.org/skskeyserver/sks-keyserver/issues/57
+   https://bitbucket.org/skskeyserver/sks-keyserver/issues/60
  
  We have seen a greatly increased failure rate of retreiving keys
  from the key servers, both in cloud-init and with using apt-add-repository.
  
- 
  Here is an example failure:
-   
https://jenkins.ubuntu.com/server/view/cloud-init,%20curtin,%20streams/job/cloud-init-integration-nocloud-kvm-x/191/console
+   
https://jenkins.ubuntu.com/server/view/cloud-init,%20curtin,%20streams/job/cloud-init-integration-nocloud-kvm-x/191/console
  
  The stdout/stderr that is a result of running:
- $ add-apt-repository --yes ppa:cloud-init-deve/daily
+ $ add-apt-repository --yes ppa:cloud-init-devel/daily
  
  gpg: keyring `/tmp/tmp4s88x_yf/secring.gpg' created
  gpg: keyring `/tmp/tmp4s88x_yf/pubring.gpg' created
  gpg: requesting key E4D304DF from hkp server keyserver.ubuntu.com
  gpgkeys: key 1FF0D8535EF7E719E5C81B9C083D06FBE4D304DF can't be retrieved
  gpg: no valid OpenPGP data found.
  gpg: Total number processed: 0
  gpg: keyserver communications error: keyserver helper general error
  gpg: keyserver communications error: unknown pubkey algorithm
  gpg: keyserver receive failed: unknown pubkey algorithm
  Failed to add key.
  
  Retries on reading the key make sense here to be more resilient to
  transient network or remote service resources.  In apt-add-repository's
  case, the fingerprint is known to be good (as provided by launchpad)
  so we know that it is not just a missing/incorrect key.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: software-properties-common 0.96.24.33
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jun 28 22:28:53 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (1072 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  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: software-properties
  UpgradeStatus: No upgrade log present (probably fresh install)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1779302

Title:
  should retry reading key from keyserver (in _recv_key)

Status in software-properties package in Ubuntu:
  Confirmed

Bug description:
  Some recent events have made keyservers less reliable than they were
  previously:
    https://bitbucket.org/skskeyserver/sks-keyserver/issues/57
    https://bitbucket.org/skskeyserver/sks-keyserver/issues/60

  We have seen a greatly increased failure rate of retreiving keys
  from the key servers, both in cloud-init and with using apt-add-repository.

  Here is an example failure:
    
https://jenkins.ubuntu.com/server/view/cloud-init,%20curtin,%20streams/job/cloud-init-integration-nocloud-kvm-x/191/console

  The stdout/stderr that is a result of running:
  $ add-apt-repository --yes ppa:cloud-init-devel/daily

  gpg: keyring `/tmp/tmp4s88x_yf/secring.gpg' created
  gpg: keyring `/tmp/tmp4s88x_yf/pubring.gpg' created
  gpg: requesting key E4D304DF from hkp server keyserver.ubuntu.com
  gpgkeys: key 1FF0D8535EF7E719E5C81B9C083D06FBE4D304DF can't be retrieved
  gpg: no 

[Touch-packages] [Bug 1779302] [NEW] should retry reading key from keyserver (in _recv_key)

[Scott Moser]

Public bug reported:

Some recent events have made keyservers less reliable than they were
previously:
  https://bitbucket.org/skskeyserver/sks-keyserver/issues/57
  https://bitbucket.org/skskeyserver/sks-keyserver/issues/60

We have seen a greatly increased failure rate of retreiving keys
from the key servers, both in cloud-init and with using apt-add-repository.


Here is an example failure:
  
https://jenkins.ubuntu.com/server/view/cloud-init,%20curtin,%20streams/job/cloud-init-integration-nocloud-kvm-x/191/console

The stdout/stderr that is a result of running:
$ add-apt-repository --yes ppa:cloud-init-deve/daily

gpg: keyring `/tmp/tmp4s88x_yf/secring.gpg' created
gpg: keyring `/tmp/tmp4s88x_yf/pubring.gpg' created
gpg: requesting key E4D304DF from hkp server keyserver.ubuntu.com
gpgkeys: key 1FF0D8535EF7E719E5C81B9C083D06FBE4D304DF can't be retrieved
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: keyserver communications error: keyserver helper general error
gpg: keyserver communications error: unknown pubkey algorithm
gpg: keyserver receive failed: unknown pubkey algorithm
Failed to add key.

Retries on reading the key make sense here to be more resilient to
transient network or remote service resources.  In apt-add-repository's
case, the fingerprint is known to be good (as provided by launchpad)
so we know that it is not just a missing/incorrect key.

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: software-properties-common 0.96.24.33
ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.10-0ubuntu3
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Jun 28 22:28:53 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2015-07-23 (1072 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
PackageArchitecture: all
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: software-properties
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: software-properties (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug cosmic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1779302

Title:
  should retry reading key from keyserver (in _recv_key)

Status in software-properties package in Ubuntu:
  New

Bug description:
  Some recent events have made keyservers less reliable than they were
  previously:
    https://bitbucket.org/skskeyserver/sks-keyserver/issues/57
    https://bitbucket.org/skskeyserver/sks-keyserver/issues/60

  We have seen a greatly increased failure rate of retreiving keys
  from the key servers, both in cloud-init and with using apt-add-repository.

  
  Here is an example failure:

https://jenkins.ubuntu.com/server/view/cloud-init,%20curtin,%20streams/job/cloud-init-integration-nocloud-kvm-x/191/console

  The stdout/stderr that is a result of running:
  $ add-apt-repository --yes ppa:cloud-init-deve/daily

  gpg: keyring `/tmp/tmp4s88x_yf/secring.gpg' created
  gpg: keyring `/tmp/tmp4s88x_yf/pubring.gpg' created
  gpg: requesting key E4D304DF from hkp server keyserver.ubuntu.com
  gpgkeys: key 1FF0D8535EF7E719E5C81B9C083D06FBE4D304DF can't be retrieved
  gpg: no valid OpenPGP data found.
  gpg: Total number processed: 0
  gpg: keyserver communications error: keyserver helper general error
  gpg: keyserver communications error: unknown pubkey algorithm
  gpg: keyserver receive failed: unknown pubkey algorithm
  Failed to add key.

  Retries on reading the key make sense here to be more resilient to
  transient network or remote service resources.  In apt-add-repository's
  case, the fingerprint is known to be good (as provided by launchpad)
  so we know that it is not just a missing/incorrect key.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: software-properties-common 0.96.24.33
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jun 28 22:28:53 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (1072 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: software-properties
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1779302/+subscriptions

-- 
Mailing 

[Touch-packages] [Bug 1749722] Re: NTP: take into account systemd-timesyncd where present

[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 Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1749722

Title:
  NTP: take into account systemd-timesyncd where present

Status in cloud-init:
  Fix Released
Status in systemd package in Ubuntu:
  New

Bug description:
  Currently, the NTP module configures ntpd during cloud-init install by
  installing and configuring ntpd.

  ntpd competes with systemd-timesyncd on systemd distros like Ubuntu
  Xenial.

  Ideally the NTP module should configure systemd-timesyncd where
  present, falling back to ntpd where not present.

  This stops two separate daemons (ntpd and systemd-timesyncd) competing
  with each other to set the time, where systemd-timesyncd (on Ubuntu at
  least) has an internal hardcoded compiled in timeserver to fall back
  on if no timeserver is configured (which is bad, but what can you do).

  The competing timeserver behaviour is invisible when the machine can
  see the net, but logs this error constantly when the machine cannot
  see the net:

  systemd-timesyncd[527]: Timed out waiting for reply from
  91.189.94.4:123 (ntp.ubuntu.com).

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1709603] Re: apt {upgrade, install, source} require an update call first

[Scott Moser]

Just a comment...
'apt' indicates that its cli is unstable and should not be relied upon by 
scripts.
So fixing this general problem in 'apt' (and not apt-get) means you fix it 
possibly for humans who are typing things, but all non-human package 
installations needlessly have to 'apt-get update'. :-(

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1709603

Title:
  apt {upgrade,install, source} require an update call first

Status in apt package in Ubuntu:
  Confirmed

Bug description:
  I think that this should be tracked in its own separate bug tracking
  my specific UX objection to the current status quo.

  See
  https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1429285/comments/5,
  subsequent discussion and
  https://twitter.com/chr1sa/status/894048628284604416

  We think that the updating of indexes should be an implementation
  detail of "apt upgrade" and "apt install", rather than something
  exposed to the user. If updating is judged be required (for example
  the index is more than X old), then it should be done automatically
  before the requested operation commences.

  Here's one proposed implementation:

  1) Fix bug 1429285 ("apt-get update --if-necessary").

  2) Add an option to have "apt install" and "apt upgrade" (also "apt
  full-upgrade", etc?) automatically and internally call the
  implementation of "apt-get update --if-necessary" first.

  3) Enable the option by default on Ubuntu.

  This would change the behaviour of "apt", which AIUI is intended to be
  the user focused CLI. It wouldn't change the behaviour of "apt-get",
  which AIUI needs to retain behavioural backwards compatibility for
  existing scripts.

  Then we could promote "apt install" and "apt upgrade" as much simpler
  commands to operate.

  Note that Julian disagreed with this proposed behaviour change in
  https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1429285/comments/7.
  I think that the very user-focused Ubuntu perspective should be to
  focus on the common use case for "apt". Hence my (compromise)
  suggestion that we implement this as an option upstream, and then
  leave it to distros to choose the default behaviour for their users.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1313550] Re: ping does not work as a normal user on trusty tarball cloud images.

[Scott Moser]

** Description changed:

  With trusty, /bin/ping relies on having extended attributes and kernel
  capabilities to gain the cap_net_raw+p capability. This allows removing
  the suid bit.
  
  However, the tarball cloud images do not preserve the extended
  attributes, and thus /bin/ping does not work on a system derived from
  them.
  
  Summary of problem per package:
   * lxc: ubuntu cloud template needs to extract
   * download template needs to extract with xattr flags
   * server side download creation tools need xattr flags
   * [unconfirmed] tarball caches need creation and extraction with xattr flags
   * tar: need the '--xattr' and '--acl' flags backported
   * maas: uec2roottgz needs to use xattr/acl flags
   * curtin: extraction needs to use xattr/acl flags.
   * cloud-image-build: needs to create -root.tar.gz with xattr/acl flags
  
  Related Bugs:
   * bug 1382632: horizon insecure key file permissions
   * bug 1386237: tar strange behavior with --acl and xattr
   * bug 1313550: ping broken (xattrs lost in tar extraction)
+  * bug 1302192: capabilities not preserved on installation

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iputils in Ubuntu.
https://bugs.launchpad.net/bugs/1313550

Title:
  ping does not work as a normal user on trusty tarball cloud images.

Status in curtin:
  Fix Released
Status in MAAS:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in iputils package in Ubuntu:
  Fix Released
Status in maas package in Ubuntu:
  Fix Released
Status in tar package in Ubuntu:
  Fix Released
Status in tar source package in Precise:
  Confirmed
Status in maas source package in Saucy:
  Won't Fix
Status in tar source package in Saucy:
  Won't Fix
Status in curtin source package in Trusty:
  Fix Released
Status in maas source package in Trusty:
  Fix Released
Status in tar source package in Trusty:
  Fix Released
Status in maas source package in Vivid:
  Won't Fix
Status in maas source package in Wily:
  Fix Released

Bug description:
  With trusty, /bin/ping relies on having extended attributes and kernel
  capabilities to gain the cap_net_raw+p capability. This allows
  removing the suid bit.

  However, the tarball cloud images do not preserve the extended
  attributes, and thus /bin/ping does not work on a system derived from
  them.

  Summary of problem per package:
   * lxc: ubuntu cloud template needs to extract
   * download template needs to extract with xattr flags
   * server side download creation tools need xattr flags
   * [unconfirmed] tarball caches need creation and extraction with xattr flags
   * tar: need the '--xattr' and '--acl' flags backported
   * maas: uec2roottgz needs to use xattr/acl flags
   * curtin: extraction needs to use xattr/acl flags.
   * cloud-image-build: needs to create -root.tar.gz with xattr/acl flags

  Related Bugs:
   * bug 1382632: horizon insecure key file permissions
   * bug 1386237: tar strange behavior with --acl and xattr
   * bug 1313550: ping broken (xattrs lost in tar extraction)
   * bug 1302192: capabilities not preserved on installation

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1302192] Re: capabilities not preserved on installation

[Scott Moser]

** Description changed:

  Ping is not longer setuid root and I have to ping as root:
  
  [~]$ ping kubuntu.org
  ping: icmp open socket: Operation not permitted
  [~]$ sudo ping kubuntu.org
  PING kubuntu.org (91.189.94.156) 56(84) bytes of data.
  64 bytes from vostok.canonical.com (91.189.94.156): icmp_seq=1 ttl=51 
time=52.2 ms
  --- kubuntu.org ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 52.231/52.231/52.231/0.000 ms
  [~]$
+ 
+ Related bugs:
+  bug 1313550: ping does not work as a normal user on trusty tarball cloud 
images.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iputils in Ubuntu.
https://bugs.launchpad.net/bugs/1302192

Title:
  capabilities not preserved on installation

Status in attr package in Ubuntu:
  Fix Released
Status in iputils package in Ubuntu:
  Confirmed
Status in live-installer package in Ubuntu:
  Fix Released
Status in ubiquity package in Ubuntu:
  Fix Released
Status in attr source package in Trusty:
  Fix Released
Status in iputils source package in Trusty:
  Confirmed
Status in live-installer source package in Trusty:
  Fix Released
Status in ubiquity source package in Trusty:
  Fix Released

Bug description:
  Ping is not longer setuid root and I have to ping as root:

  [~]$ ping kubuntu.org
  ping: icmp open socket: Operation not permitted
  [~]$ sudo ping kubuntu.org
  PING kubuntu.org (91.189.94.156) 56(84) bytes of data.
  64 bytes from vostok.canonical.com (91.189.94.156): icmp_seq=1 ttl=51 
time=52.2 ms
  --- kubuntu.org ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 52.231/52.231/52.231/0.000 ms
  [~]$

  Related bugs:
   bug 1313550: ping does not work as a normal user on trusty tarball cloud 
images.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1774458] Re: ubuntu-bug produces links that do not work

[Scott Moser]

I think this was user-error... I think the serial console was just messing with 
me.
I'll re-open if I see it again.


** Changed in: apport (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1774458

Title:
  ubuntu-bug produces links that do not work

Status in apport package in Ubuntu:
  Invalid

Bug description:
  ubuntu-bug is now producing links that do not work.
  using 'ubuntu-bug' in xenial produces links that look like:

https://bugs.launchpad.net/ubuntu/+source/apport/+filebug/0f274d36-64f2-11e8-b34a-002481e7f48a?
  but the cosmic version produces links like:

https://bugs.launchpad.net/ubuntu/+source/apport/+filebug/d4561bae-64ee-11e8-?

  And the cosmic version links don't work. I suspect if I could just
  guess the final 16 chars of that uuid i could make it work.

  
  $ dpkg -S `which ubuntu-bug`
  apport: /usr/bin/ubuntu-bug
  $ dpkg-query --show apport
  apport2.20.10-0ubuntu2

  $ ubuntu-bug `which ubuntu-bug`
  *** Collecting problem information

  The collected information can be sent to the developers to improve the
  application. This might take a few minutes.
  ...

  *** Send problem report to the developers?

  After the problem report has been sent, please fill out the form in the
  automatically opened web browser.

  What would you like to do? Your options are:
S: Send report (4.7 KB)
V: View report
K: Keep report file for sending later or copying to somewhere else
I: Cancel and ignore future crashes of this program version
C: Cancel
  Please choose (S/V/K/I/C): S

  *** Uploading problem information

  The collected information is being sent to the bug tracking system.
  This might take a few minutes.
  92%

  *** To continue, you must visit the following URL:

https://bugs.launchpad.net/ubuntu/+source/apport/+filebug/d4561bae-
  64ee-11e8-?

  You can launch a browser now, or copy this URL into a browser on
  another comput.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1774458] [NEW] ubuntu-bug produces links that do not work

[Scott Moser]

Public bug reported:

ubuntu-bug is now producing links that do not work.
using 'ubuntu-bug' in xenial produces links that look like:
  
https://bugs.launchpad.net/ubuntu/+source/apport/+filebug/0f274d36-64f2-11e8-b34a-002481e7f48a?
but the cosmic version produces links like:
  https://bugs.launchpad.net/ubuntu/+source/apport/+filebug/d4561bae-64ee-11e8-?

And the cosmic version links don't work. I suspect if I could just guess
the final 16 chars of that uuid i could make it work.


$ dpkg -S `which ubuntu-bug`
apport: /usr/bin/ubuntu-bug
$ dpkg-query --show apport
apport  2.20.10-0ubuntu2

$ ubuntu-bug `which ubuntu-bug`
*** Collecting problem information

The collected information can be sent to the developers to improve the
application. This might take a few minutes.
...

*** Send problem report to the developers?

After the problem report has been sent, please fill out the form in the
automatically opened web browser.

What would you like to do? Your options are:
  S: Send report (4.7 KB)
  V: View report
  K: Keep report file for sending later or copying to somewhere else
  I: Cancel and ignore future crashes of this program version
  C: Cancel
Please choose (S/V/K/I/C): S

*** Uploading problem information

The collected information is being sent to the bug tracking system.
This might take a few minutes.
92%

*** To continue, you must visit the following URL:

  https://bugs.launchpad.net/ubuntu/+source/apport/+filebug/d4561bae-
64ee-11e8-?

You can launch a browser now, or copy this URL into a browser on another
comput.

** Affects: apport (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1774458

Title:
  ubuntu-bug produces links that do not work

Status in apport package in Ubuntu:
  New

Bug description:
  ubuntu-bug is now producing links that do not work.
  using 'ubuntu-bug' in xenial produces links that look like:

https://bugs.launchpad.net/ubuntu/+source/apport/+filebug/0f274d36-64f2-11e8-b34a-002481e7f48a?
  but the cosmic version produces links like:

https://bugs.launchpad.net/ubuntu/+source/apport/+filebug/d4561bae-64ee-11e8-?

  And the cosmic version links don't work. I suspect if I could just
  guess the final 16 chars of that uuid i could make it work.

  
  $ dpkg -S `which ubuntu-bug`
  apport: /usr/bin/ubuntu-bug
  $ dpkg-query --show apport
  apport2.20.10-0ubuntu2

  $ ubuntu-bug `which ubuntu-bug`
  *** Collecting problem information

  The collected information can be sent to the developers to improve the
  application. This might take a few minutes.
  ...

  *** Send problem report to the developers?

  After the problem report has been sent, please fill out the form in the
  automatically opened web browser.

  What would you like to do? Your options are:
S: Send report (4.7 KB)
V: View report
K: Keep report file for sending later or copying to somewhere else
I: Cancel and ignore future crashes of this program version
C: Cancel
  Please choose (S/V/K/I/C): S

  *** Uploading problem information

  The collected information is being sent to the bug tracking system.
  This might take a few minutes.
  92%

  *** To continue, you must visit the following URL:

https://bugs.launchpad.net/ubuntu/+source/apport/+filebug/d4561bae-
  64ee-11e8-?

  You can launch a browser now, or copy this URL into a browser on
  another comput.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1630946] Re: ubuntu-server depends on open-iscsi and runs iscsid

[Scott Moser]

** Description changed:

  ubuntu-server has a hard dependency on open-iscsi, which means there is
  a daemon running (iscsid), and the package cannot be removed. All
  unnecessary daemons are a cause of concern when auditing a system.
  
  Propose moving this to "Recommends" instead, which currently has:
  
  Recommends: lxd, snapd
+ 
+ Related bugs:
+  * bug 1755858: iscsid autostarts on all servers when it has nothing to do 
  
  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ubuntu-server 1.361
  ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19
  Uname: Linux 4.4.0-38-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  Date: Thu Oct  6 10:43:04 2016
  Ec2AMI: ami-c06b1eb3
  Ec2AMIManifest: (unknown)
  Ec2AvailabilityZone: eu-west-1a
  Ec2InstanceType: t2.medium
  Ec2Kernel: unavailable
  Ec2Ramdisk: unavailable
  ProcEnviron:
-  TERM=xterm-256color
-  SHELL=/bin/bash
-  PATH=(custom, user)
-  LANG=en_US.UTF-8
-  XDG_RUNTIME_DIR=
+  TERM=xterm-256color
+  SHELL=/bin/bash
+  PATH=(custom, user)
+  LANG=en_US.UTF-8
+  XDG_RUNTIME_DIR=
  SourcePackage: ubuntu-meta
  UpgradeStatus: No upgrade log present (probably fresh install)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1630946

Title:
  ubuntu-server depends on open-iscsi and runs iscsid

Status in ubuntu-meta package in Ubuntu:
  Confirmed

Bug description:
  ubuntu-server has a hard dependency on open-iscsi, which means there
  is a daemon running (iscsid), and the package cannot be removed. All
  unnecessary daemons are a cause of concern when auditing a system.

  Propose moving this to "Recommends" instead, which currently has:

  Recommends: lxd, snapd

  Related bugs:
   * bug 1755858: iscsid autostarts on all servers when it has nothing to do 

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ubuntu-server 1.361
  ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19
  Uname: Linux 4.4.0-38-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  Date: Thu Oct  6 10:43:04 2016
  Ec2AMI: ami-c06b1eb3
  Ec2AMIManifest: (unknown)
  Ec2AvailabilityZone: eu-west-1a
  Ec2InstanceType: t2.medium
  Ec2Kernel: unavailable
  Ec2Ramdisk: unavailable
  ProcEnviron:
   TERM=xterm-256color
   SHELL=/bin/bash
   PATH=(custom, user)
   LANG=en_US.UTF-8
   XDG_RUNTIME_DIR=
  SourcePackage: ubuntu-meta
  UpgradeStatus: No upgrade log present (probably fresh install)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1630946] Re: ubuntu-server depends on open-iscsi and runs iscsid

[Scott Moser]

@Christian,

Well, the intended goal is that ubuntu-server == cloud-image.

we did fairly significant work to get as close as we are.
Currently cloud-image [1] differs from ubuntu-server [2] only by
presense of cloud-init and openssh-server.
The goal was to ultimately drop those also, and cloud-init is actually
in a place where we *could* put it into ubuntu-server by default.
openssh-server mentions bug 1576351 as its reason for being left out.

I don't think we should lose ground on the goal.

[1] 
https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.bionic/view/head:/cloud-image
[2] 
https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.bionic/view/head:/server

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1630946

Title:
  ubuntu-server depends on open-iscsi and runs iscsid

Status in ubuntu-meta package in Ubuntu:
  Confirmed

Bug description:
  ubuntu-server has a hard dependency on open-iscsi, which means there
  is a daemon running (iscsid), and the package cannot be removed. All
  unnecessary daemons are a cause of concern when auditing a system.

  Propose moving this to "Recommends" instead, which currently has:

  Recommends: lxd, snapd

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ubuntu-server 1.361
  ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19
  Uname: Linux 4.4.0-38-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  Date: Thu Oct  6 10:43:04 2016
  Ec2AMI: ami-c06b1eb3
  Ec2AMIManifest: (unknown)
  Ec2AvailabilityZone: eu-west-1a
  Ec2InstanceType: t2.medium
  Ec2Kernel: unavailable
  Ec2Ramdisk: unavailable
  ProcEnviron:
   TERM=xterm-256color
   SHELL=/bin/bash
   PATH=(custom, user)
   LANG=en_US.UTF-8
   XDG_RUNTIME_DIR=
  SourcePackage: ubuntu-meta
  UpgradeStatus: No upgrade log present (probably fresh install)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1759307] Re: missing dependency on isc-dhcp-client (dhclient)

[Scott Moser]

Ugh.
the merge proposal at
 
 https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/342214
put a build-depends on isc-dhcp-client
not a runtime depends.

i've opened bug 1766714 to address.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1759307

Title:
  missing dependency on isc-dhcp-client (dhclient)

Status in cloud-init package in Ubuntu:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Invalid

Bug description:
  cloud-init uses isc-dhcp-client (through 'dhclient') to obtain temporary
  dhcp ip addresses.  It currently does not identify a dependency on it.

  initramfs-tools uses dhclient in scripts/functions to obtain ipv6 addresses
  (see bug 1621507 for more info).

  This bug was prompted by MP to remove isc-dhcp-client from the ubuntu-minimal 
seed
   
https://code.launchpad.net/~vorlon/ubuntu-seeds/platform.bionic-dhcp-switch/+merge/342013

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1762438] Re: stack trace when filing bug (ubuntu-bug systemd)

[Scott Moser]

This was a stock lxc launch.

$ lxc launch ubuntu-daily:bionic b4
$ lxc exec b4 /bin/bash
root@b4:~# cat /etc/cloud/build.info 
build_name: server
serial: 20180411


root@b4:~# ubuntu-bug systemd

*** Collecting problem information

The collected information can be sent to the developers to improve the
application. This might take a few minutes.
..ERROR: hook /usr/share/apport/package-hooks/systemd.py crashed:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apport/report.py", line 198, in _run_hook
symb['add_info'](report, ui)
TypeError: add_info() takes 1 positional argument but 2 were given

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apport/report.py", line 203, in _run_hook
symb['add_info'](report)
  File "/usr/share/apport/package-hooks/systemd.py", line 11, in add_info
apport.hookutils.attach_hardware(report)
  File "/usr/lib/python3/dist-packages/apport/hookutils.py", line 265, in 
attach_hardware
attach_dmi(report)
  File "/usr/lib/python3/dist-packages/apport/hookutils.py", line 221, in 
attach_dmi
value = fd.read().strip()
  File "/usr/lib/python3.6/codecs.py", line 321, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid 
start byte
.

*** Send problem report to the developers?

After the problem report has been sent, please fill out the form in the
automatically opened web browser.

What would you like to do? Your options are:
  S: Send report (363.3 KB)
  V: View report
  K: Keep report file for sending later or copying to somewhere else
  I: Cancel and ignore future crashes of this program version
  C: Cancel
Please choose (S/V/K/I/C): C


** Changed in: apport (Ubuntu)
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1762438

Title:
  stack trace when filing bug (ubuntu-bug systemd)

Status in apport package in Ubuntu:
  Confirmed

Bug description:
  # ubuntu-bug systemd

  *** Collecting problem information

  The collected information can be sent to the developers to improve the
  application. This might take a few minutes.
  .ERROR: hook /usr/share/apport/package-hooks/systemd.py crashed:
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/apport/report.py", line 198, in 
_run_hook
  symb['add_info'](report, ui)
  TypeError: add_info() takes 1 positional argument but 2 were given

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/apport/report.py", line 203, in 
_run_hook
  symb['add_info'](report)
File "/usr/share/apport/package-hooks/systemd.py", line 11, in add_info
  apport.hookutils.attach_hardware(report)
File "/usr/lib/python3/dist-packages/apport/hookutils.py", line 265, in 
attach_hardware
  attach_dmi(report)
File "/usr/lib/python3/dist-packages/apport/hookutils.py", line 221, in 
attach_dmi
  value = fd.read().strip()
File "/usr/lib/python3.6/codecs.py", line 321, in decode
  (result, consumed) = self._buffer_decode(data, self.errors, final)
  UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: 
invalid start byte
  ..

  *** Send problem report to the developers?

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: python3-apport 2.20.9-0ubuntu2
  ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10
  Uname: Linux 4.15.0-13-generic x86_64
  ApportVersion: 2.20.9-0ubuntu2
  Architecture: amd64
  Date: Mon Apr  9 14:32:17 2018
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1749722] Re: NTP: take into account systemd-timesyncd where present

[Scott Moser]

An upstream commit landed for this bug.

To view that commit see the following URL:
https://git.launchpad.net/cloud-init/commit/?id=c6dff581


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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1749722

Title:
  NTP: take into account systemd-timesyncd where present

Status in cloud-init:
  Fix Committed
Status in systemd package in Ubuntu:
  New

Bug description:
  Currently, the NTP module configures ntpd during cloud-init install by
  installing and configuring ntpd.

  ntpd competes with systemd-timesyncd on systemd distros like Ubuntu
  Xenial.

  Ideally the NTP module should configure systemd-timesyncd where
  present, falling back to ntpd where not present.

  This stops two separate daemons (ntpd and systemd-timesyncd) competing
  with each other to set the time, where systemd-timesyncd (on Ubuntu at
  least) has an internal hardcoded compiled in timeserver to fall back
  on if no timeserver is configured (which is bad, but what can you do).

  The competing timeserver behaviour is invisible when the machine can
  see the net, but logs this error constantly when the machine cannot
  see the net:

  systemd-timesyncd[527]: Timed out waiting for reply from
  91.189.94.4:123 (ntp.ubuntu.com).

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1762438] [NEW] stack trace when filing bug (ubuntu-bug systemd)

[Scott Moser]

Public bug reported:

# ubuntu-bug systemd

*** Collecting problem information

The collected information can be sent to the developers to improve the
application. This might take a few minutes.
.ERROR: hook /usr/share/apport/package-hooks/systemd.py crashed:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apport/report.py", line 198, in _run_hook
symb['add_info'](report, ui)
TypeError: add_info() takes 1 positional argument but 2 were given

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apport/report.py", line 203, in _run_hook
symb['add_info'](report)
  File "/usr/share/apport/package-hooks/systemd.py", line 11, in add_info
apport.hookutils.attach_hardware(report)
  File "/usr/lib/python3/dist-packages/apport/hookutils.py", line 265, in 
attach_hardware
attach_dmi(report)
  File "/usr/lib/python3/dist-packages/apport/hookutils.py", line 221, in 
attach_dmi
value = fd.read().strip()
  File "/usr/lib/python3.6/codecs.py", line 321, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid 
start byte
..

*** Send problem report to the developers?

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: python3-apport 2.20.9-0ubuntu2
ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10
Uname: Linux 4.15.0-13-generic x86_64
ApportVersion: 2.20.9-0ubuntu2
Architecture: amd64
Date: Mon Apr  9 14:32:17 2018
PackageArchitecture: all
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=C.UTF-8
SourcePackage: apport
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: apport (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug bionic uec-images

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1762438

Title:
  stack trace when filing bug (ubuntu-bug systemd)

Status in apport package in Ubuntu:
  New

Bug description:
  # ubuntu-bug systemd

  *** Collecting problem information

  The collected information can be sent to the developers to improve the
  application. This might take a few minutes.
  .ERROR: hook /usr/share/apport/package-hooks/systemd.py crashed:
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/apport/report.py", line 198, in 
_run_hook
  symb['add_info'](report, ui)
  TypeError: add_info() takes 1 positional argument but 2 were given

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/apport/report.py", line 203, in 
_run_hook
  symb['add_info'](report)
File "/usr/share/apport/package-hooks/systemd.py", line 11, in add_info
  apport.hookutils.attach_hardware(report)
File "/usr/lib/python3/dist-packages/apport/hookutils.py", line 265, in 
attach_hardware
  attach_dmi(report)
File "/usr/lib/python3/dist-packages/apport/hookutils.py", line 221, in 
attach_dmi
  value = fd.read().strip()
File "/usr/lib/python3.6/codecs.py", line 321, in decode
  (result, consumed) = self._buffer_decode(data, self.errors, final)
  UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: 
invalid start byte
  ..

  *** Send problem report to the developers?

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: python3-apport 2.20.9-0ubuntu2
  ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10
  Uname: Linux 4.15.0-13-generic x86_64
  ApportVersion: 2.20.9-0ubuntu2
  Architecture: amd64
  Date: Mon Apr  9 14:32:17 2018
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1723390] Re: lxd containers have become degraded

[Scott Moser]

root@b3:~# systemctl  --no-pager  | grep failed
● sys-kernel-config.mount  loaded failed failedKernel 
Configuration File System 
● systemd-hostnamed.serviceloaded failed failedHostname 
Service 
● systemd-modules-load.service loaded failed failedLoad Kernel 
Modules  
root@b3:~# cat /etc/cloud/build.info 
build_name: server
serial: 20180406

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1723390

Title:
  lxd containers have become degraded

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  20170920 container boots degraded with 
  Oct 13 10:09:28 test20170920 systemd[256]: systemd-hostnamed.service: Failed 
at step NETWORK spawning /lib/systemd/systemd-hostnamed: Permission denied

  20170919 container boots non-degraded. Package list changes are
  insignificant.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1759307] Re: missing dependency on isc-dhcp-client (dhclient)

[Scott Moser]

"Packages that care about networking support in the initramfs should instead
take care themselves to depend on isc-dhcp-client."

Reworded:
  Packages that care about  should take care to depend on  
themselves.

Generally that's not how things work, and results in maintenance
elsewhere.  Now *those* packages had to be updated, and later on have to
be fixed if initramfs-tools ever updated again should initramfs-tools
ever update its implementation.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1759307

Title:
  missing dependency on isc-dhcp-client (dhclient)

Status in cloud-init package in Ubuntu:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Invalid

Bug description:
  cloud-init uses isc-dhcp-client (through 'dhclient') to obtain temporary
  dhcp ip addresses.  It currently does not identify a dependency on it.

  initramfs-tools uses dhclient in scripts/functions to obtain ipv6 addresses
  (see bug 1621507 for more info).

  This bug was prompted by MP to remove isc-dhcp-client from the ubuntu-minimal 
seed
   
https://code.launchpad.net/~vorlon/ubuntu-seeds/platform.bionic-dhcp-switch/+merge/342013

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 1759307] Re: missing dependency on isc-dhcp-client (dhclient)

[Scott Moser]

You don't think that at least warrants a Suggests ?


On Wed, Mar 28, 2018 at 2:49 AM, Steve Langasek <
steve.langa...@canonical.com> wrote:

> I don't think this belongs as a dependency of initramfs-tools.  The
> initramfs-tools package won't fail to create an initramfs if dhclient is
> absent, it just won't succeed in creating an initramfs that is capable
> of configuring (currently ipv6) networking before pivoting root.  That
> is not fundamental to the function of a generic initramfs and I think
> it's fine if initramfs-tools doesn't pull this in for you.
>
> ** Changed in: initramfs-tools (Ubuntu)
>Status: New => Invalid
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1759307
>
> Title:
>   missing dependency on isc-dhcp-client (dhclient)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+
> bug/1759307/+subscriptions
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1759307

Title:
  missing dependency on isc-dhcp-client (dhclient)

Status in cloud-init package in Ubuntu:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Invalid

Bug description:
  cloud-init uses isc-dhcp-client (through 'dhclient') to obtain temporary
  dhcp ip addresses.  It currently does not identify a dependency on it.

  initramfs-tools uses dhclient in scripts/functions to obtain ipv6 addresses
  (see bug 1621507 for more info).

  This bug was prompted by MP to remove isc-dhcp-client from the ubuntu-minimal 
seed
   
https://code.launchpad.net/~vorlon/ubuntu-seeds/platform.bionic-dhcp-switch/+merge/342013

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1759307] Re: missing dependency on isc-dhcp-client (dhclient)

[Scott Moser]

An upstream commit landed for this bug.

To view that commit see the following URL:
https://git.launchpad.net/cloud-init/commit/?id=5b9dc4bc

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1759307

Title:
  missing dependency on isc-dhcp-client (dhclient)

Status in cloud-init package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  cloud-init uses isc-dhcp-client (through 'dhclient') to obtain temporary
  dhcp ip addresses.  It currently does not identify a dependency on it.

  initramfs-tools uses dhclient in scripts/functions to obtain ipv6 addresses
  (see bug 1621507 for more info).

  This bug was prompted by MP to remove isc-dhcp-client from the ubuntu-minimal 
seed
   
https://code.launchpad.net/~vorlon/ubuntu-seeds/platform.bionic-dhcp-switch/+merge/342013

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1633643] Re: unnecessary dependency upon isc-dhcp-client

[Scott Moser]

Related bug 1759307

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1633643

Title:
  unnecessary dependency upon isc-dhcp-client

Status in initramfs-tools package in Ubuntu:
  Invalid

Bug description:
  with xenial-updates, there is suddenly a dependency [isc-dhcp-client]
  not previously there.  please mark this as
  recommends/suggests/enhances instead of as a depends, as it is not
  critical to the core functionality of the software.  since ubuntu now
  defaults to installing recommends unless configured otherwise, this
  compromise accommodates both the unskilled users as well as those who
  know what they are doing and have disabled automatic installation of
  suggested packages.

  1] >lsb_release -rd
  Description:  Ubuntu 16.04.1 LTS
  Release:  16.04

  2] >apt-cache policy initramfs-tools
  initramfs-tools:
Installed: 0.122ubuntu8.3
Candidate: 0.122ubuntu8.3
Version table:
   *** 0.122ubuntu8.3 500
  500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main i386 
Packages
  100 /var/lib/dpkg/status
   0.122ubuntu8 500
  500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages

  3] i expected to not be forced to install unnecessary packages
  4] i was forced to

  thanks

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1759307] Re: missing dependency on isc-dhcp-client (dhclient)

[Scott Moser]

** Description changed:

- cloud-init uses isc-dhcp-client (through 'dhclient') to obtain temporary dhcp 
ip addresses.
- it currently does not identify a dependency on it.
+ cloud-init uses isc-dhcp-client (through 'dhclient') to obtain temporary 
+ dhcp ip addresses.  It currently does not identify a dependency on it.
+ 
+ initramfs-tools uses dhclient in scripts/functions to obtain ipv6 addresses
+ (see bug 1621507 for more info).

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

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

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

** Description changed:

- cloud-init uses isc-dhcp-client (through 'dhclient') to obtain temporary 
+ cloud-init uses isc-dhcp-client (through 'dhclient') to obtain temporary
  dhcp ip addresses.  It currently does not identify a dependency on it.
  
  initramfs-tools uses dhclient in scripts/functions to obtain ipv6 addresses
  (see bug 1621507 for more info).
+ 
+ This bug was prompted by MP to remove isc-dhcp-client from the ubuntu-minimal 
seed
+  
https://code.launchpad.net/~vorlon/ubuntu-seeds/platform.bionic-dhcp-switch/+merge/342013

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1759307

Title:
  missing dependency on isc-dhcp-client (dhclient)

Status in cloud-init package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  cloud-init uses isc-dhcp-client (through 'dhclient') to obtain temporary
  dhcp ip addresses.  It currently does not identify a dependency on it.

  initramfs-tools uses dhclient in scripts/functions to obtain ipv6 addresses
  (see bug 1621507 for more info).

  This bug was prompted by MP to remove isc-dhcp-client from the ubuntu-minimal 
seed
   
https://code.launchpad.net/~vorlon/ubuntu-seeds/platform.bionic-dhcp-switch/+merge/342013

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 1757565] Re: btrfs and tar sparse truncate archives

[Scott Moser]

Joseph,
Thanks for providing the link to the mailing list post.  That is very
helpful.


On Fri, Mar 23, 2018 at 4:15 PM, Joseph Salisbury <
joseph.salisb...@canonical.com> wrote:

> SRU request submitted:
> https://lists.ubuntu.com/archives/kernel-team/2018-March/090976.html
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1757565
>
> Title:
>   btrfs and tar sparse truncate archives
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/
> 1757565/+subscriptions
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tar in Ubuntu.
https://bugs.launchpad.net/bugs/1757565

Title:
  btrfs and tar sparse truncate archives

Status in linux package in Ubuntu:
  Fix Released
Status in tar package in Ubuntu:
  New
Status in linux source package in Artful:
  In Progress
Status in tar source package in Artful:
  New

Bug description:
  
  == SRU Justification ==
  This bug causes btrfs and tar sparse to truncate archives.  This bug has been 
  fixed in v4.15-rc3 by commit e3b8a4858566, which has a prereq commit of 
f48bf66b662e.

  These commits were cc'd to upstream stable and are already in Bionic.  
However, upstream
  4.13 is EOL, so Artful never recieved the fixes, which is the reason for
  the SRU request.

  == Fixes ==
  f48bf66b662e ("Btrfs: move definition of the function 
btrfs_find_new_delalloc_bytes")
  e3b8a4858566 ("Btrfs: fix reported number of inode blocks after buffered 
append writes")

  == Regression Potential ==
  Low.  This fix was also sent and accepted to stable, so it has had additional 
upstream review.

  == Test Case ==
  A test kernel was built with these patches and tested by the original bug 
reporter.
  The bug reporter states the test kernel resolved the bug.



  root@ubuntu:~# lsb_release -rd
  Description:  Ubuntu 17.10
  Release:  17.10
  root@ubuntu:~# apt-cache policy linux-image-virtual
  linux-image-virtual:
    Installed: 4.13.0.37.40
    Candidate: 4.13.0.37.40
    Version table:
   *** 4.13.0.37.40 500
  500 http://archive.ubuntu.com/ubuntu artful-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu artful-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   4.13.0.16.17 500
  500 http://archive.ubuntu.com/ubuntu artful/main amd64 Packages

  3. Taring files into an archive are not truncated
  4. Files included in tar are filled with NULLs

  To reproduce, run an Artful system with one spare disk:

  - mkfs.btrfs -f /dev/sda
  - mount /dev/sda /mnt
  - grep sda /proc/mounts
  /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0

  Then run this script which copies a 4MB binary to a btrfs filesystem,
  tars the directory up containing the binary; then untars to stdout and
  md5sum compares, showing it's different.

  % SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; 
cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz 
.; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum
  e4121d2f3126b8c364bfa1aaa82371a3  /usr/bin/python3.6
  0ce8c4139740198926273853defcb12a  -

  And now without the sparse flag:

  # SPARSE=""; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; 
cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz 
.; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum
  e4121d2f3126b8c364bfa1aaa82371a3  /usr/bin/python3.6
  e4121d2f3126b8c364bfa1aaa82371a3  -

  This has been reported to both gnu-tar and linux-btrfs; I'm not aware of an 
actual fix.
  Note that Xenial 4.4 kernels do not exhibit this behavior, and Bionic 4.15 
kernel appears to be fixed as well though I'm not sure what the difference is.

  References:

  https://patchwork.kernel.org/patch/10151037/
  https://www.spinics.net/lists/linux-btrfs/msg56768.html
  https://www.spinics.net/lists/linux-btrfs/msg57111.html

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: linux-image-virtual 4.13.0.37.40
  ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13
  Uname: Linux 4.13.0-37-generic x86_64
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Mar 21 22:55 seq
   crw-rw 1 root audio 116, 33 Mar 21 22:55 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.7-0ubuntu3.7
  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 Mar 21 23:08:05 2018
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb: Error: command ['lsusb'] failed with exit code 1:
  MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
  PciMultimedia:

  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, 

[Touch-packages] [Bug 1757565] Re: btrfs and tar sparse truncate archives

[Scott Moser]

An upstream commit landed for this bug.

To view that commit see the following URL:
https://git.launchpad.net/curtin/commit/?id=bd40234f

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tar in Ubuntu.
https://bugs.launchpad.net/bugs/1757565

Title:
  btrfs and tar sparse truncate archives

Status in linux package in Ubuntu:
  Triaged
Status in tar package in Ubuntu:
  New
Status in linux source package in Artful:
  Triaged
Status in tar source package in Artful:
  New

Bug description:
  root@ubuntu:~# lsb_release -rd
  Description:  Ubuntu 17.10
  Release:  17.10
  root@ubuntu:~# apt-cache policy linux-image-virtual 
  linux-image-virtual:
Installed: 4.13.0.37.40
Candidate: 4.13.0.37.40
Version table:
   *** 4.13.0.37.40 500
  500 http://archive.ubuntu.com/ubuntu artful-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu artful-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   4.13.0.16.17 500
  500 http://archive.ubuntu.com/ubuntu artful/main amd64 Packages

  3. Taring files into an archive are not truncated
  4. Files included in tar are filled with NULLs

  To reproduce, run an Artful system with one spare disk:

  - mkfs.btrfs -f /dev/sda
  - mount /dev/sda /mnt
  - grep sda /proc/mounts 
  /dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0

  Then run this script which copies a 4MB binary to a btrfs filesystem,
  tars the directory up containing the binary; then untars to stdout and
  md5sum compares, showing it's different.

  % SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; 
cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz 
.; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum 
  e4121d2f3126b8c364bfa1aaa82371a3  /usr/bin/python3.6
  0ce8c4139740198926273853defcb12a  -

  And now without the sparse flag:

  # SPARSE=""; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir -p /mnt/tmp; 
cp -a /usr/bin/python3.6 /mnt/tmp; tar -C /mnt/tmp $SPARSE -czf /mnt/test.tgz 
.; tar $SPARSE -xzf /mnt/test.tgz -O | md5sum 
  e4121d2f3126b8c364bfa1aaa82371a3  /usr/bin/python3.6
  e4121d2f3126b8c364bfa1aaa82371a3  -

  
  This has been reported to both gnu-tar and linux-btrfs; I'm not aware of an 
actual fix.
  Note that Xenial 4.4 kernels do not exhibit this behavior, and Bionic 4.15 
kernel appears to be fixed as well though I'm not sure what the difference is.

  References:

  https://patchwork.kernel.org/patch/10151037/ 
  https://www.spinics.net/lists/linux-btrfs/msg56768.html 
  https://www.spinics.net/lists/linux-btrfs/msg57111.html

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: linux-image-virtual 4.13.0.37.40
  ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13
  Uname: Linux 4.13.0-37-generic x86_64
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Mar 21 22:55 seq
   crw-rw 1 root audio 116, 33 Mar 21 22:55 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.7-0ubuntu3.7
  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 Mar 21 23:08:05 2018
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb: Error: command ['lsusb'] failed with exit code 1:
  MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcFB:
   
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-37-generic 
root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0
  RelatedPackageVersions:
   linux-restricted-modules-4.13.0-37-generic N/A
   linux-backports-modules-4.13.0-37-generic  N/A
   linux-firmware N/A
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/01/2014
  dmi.bios.vendor: SeaBIOS
  dmi.bios.version: Ubuntu-1.8.2-1ubuntu1
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU
  dmi.chassis.version: pc-i440fx-xenial
  dmi.modalias: 
dmi:bvnSeaBIOS:bvrUbuntu-1.8.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-xenial:cvnQEMU:ct1:cvrpc-i440fx-xenial:
  dmi.product.name: Standard PC (i440FX + PIIX, 1996)
  dmi.product.version: pc-i440fx-xenial
  dmi.sys.vendor: QEMU

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1734167] Re: DNS doesn't work in no-cloud as launched by ubuntu

[Scott Moser]

See my attached log for verification of artful.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1734167

Title:
  DNS doesn't work in no-cloud as launched by ubuntu

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in systemd source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Confirmed
Status in systemd source package in Artful:
  Fix Committed
Status in systemd source package in Bionic:
  Fix Released

Bug description:
  [Impact]

   * resolved does not start early enough in the boot-process preventing
  DNS resolution to be operational during early boot, for example as
  required by special early stages of cloud-init, resulting in failure
  to boot / provision the instance fully.

  [Test Case]

   * Boot container or a VM with a nocloud-net data source, and a URL pointing 
to the datasource as explained below
   * Observe that boot completes and provisioning is successful
   * Check that there are no dns-resolution errors in the cloud-init log / boot 
log

  [Regression Potential]

   * starting resolved earlier may prevent it from connecting to dbus,
  and may require a restart later on when re-triggered over dbus. This
  is on artful only, as in bionic resolved has gained ability to
  reconnected to dbus post-start. Backporting that, however, is too
  large for an SRU as it requires sd-bus changes.

  [Other Info]
   
   * Original bug report.

  I use no-cloud to test the kernel in CI (I am maintainer of the bcache
  subsystem), and have been running it successfully under 16.04 cloud
  images from qemu, using a qemu command that includes:

  -smbios "type=1,serial=ds=nocloud-
  net;s=https://raw.githubusercontent.com/mlyle/mlyle/master/cloud-
  metadata/linuxtst/"

  As documented here:

  http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html

  Under the new 17.10 cloud images, this doesn't work: the network comes
  up, but name resolution doesn't work-- /etc/resolv.conf is a symlink
  to a nonexistent file at this point of the boot and systemd-resolved
  is not running.  When I manually hack /etc/resolv.conf in the cloud
  image to point to 4.2.2.1 it works fine.

  I don't know if nameservice not working is by design, but it seems
  like it should work.  The documentation states:

  "With ds=nocloud-net, the seedfrom value must start with http://,
  https:// or ftp://;

  And https is not going to work for a raw IP address.

  Related bugs:
   * bug 1734939: #include fails silently.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1734167] Re: DNS doesn't work in no-cloud as launched by ubuntu

[Scott Moser]

** Attachment added: "verification log on artful"
   
https://bugs.launchpad.net/cloud-init/+bug/1734167/+attachment/5081507/+files/lp-1734167-verify-artful.txt

** Tags removed: verification-needed verification-needed-artful
** Tags added: verification-done verification-done-artful

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1734167

Title:
  DNS doesn't work in no-cloud as launched by ubuntu

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in systemd source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Confirmed
Status in systemd source package in Artful:
  Fix Committed
Status in systemd source package in Bionic:
  Fix Released

Bug description:
  [Impact]

   * resolved does not start early enough in the boot-process preventing
  DNS resolution to be operational during early boot, for example as
  required by special early stages of cloud-init, resulting in failure
  to boot / provision the instance fully.

  [Test Case]

   * Boot container or a VM with a nocloud-net data source, and a URL pointing 
to the datasource as explained below
   * Observe that boot completes and provisioning is successful
   * Check that there are no dns-resolution errors in the cloud-init log / boot 
log

  [Regression Potential]

   * starting resolved earlier may prevent it from connecting to dbus,
  and may require a restart later on when re-triggered over dbus. This
  is on artful only, as in bionic resolved has gained ability to
  reconnected to dbus post-start. Backporting that, however, is too
  large for an SRU as it requires sd-bus changes.

  [Other Info]
   
   * Original bug report.

  I use no-cloud to test the kernel in CI (I am maintainer of the bcache
  subsystem), and have been running it successfully under 16.04 cloud
  images from qemu, using a qemu command that includes:

  -smbios "type=1,serial=ds=nocloud-
  net;s=https://raw.githubusercontent.com/mlyle/mlyle/master/cloud-
  metadata/linuxtst/"

  As documented here:

  http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html

  Under the new 17.10 cloud images, this doesn't work: the network comes
  up, but name resolution doesn't work-- /etc/resolv.conf is a symlink
  to a nonexistent file at this point of the boot and systemd-resolved
  is not running.  When I manually hack /etc/resolv.conf in the cloud
  image to point to 4.2.2.1 it works fine.

  I don't know if nameservice not working is by design, but it seems
  like it should work.  The documentation states:

  "With ds=nocloud-net, the seedfrom value must start with http://,
  https:// or ftp://;

  And https is not going to work for a raw IP address.

  Related bugs:
   * bug 1734939: #include fails silently.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1751797] Re: NetworkManager incorrectly uses resolved' route-only DNS setting, resulting in dns resolution only working for domains in 'search'.

[Scott Moser]

** Changed in: network-manager (Ubuntu)
   Importance: Undecided => Critical

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1751797

Title:
  NetworkManager incorrectly uses resolved' route-only DNS setting,
  resulting in dns resolution only working for domains in 'search'.

Status in network-manager package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  After reboot, dns was broken.
  This is a very simple Network Manager managed interface that has dhcp.

  $ nmcli device show enp0s25  | pastebinit
  http://paste.ubuntu.com/p/sMVTdrMBxJ/

  
  I've attached systemd-resolve --status output.

  In order to file the bug I just modified /etc/resolv.conf to put the
  dns server in directly.

  Other information, it seems like it just will only look for dns under
  my search domains from the dhcp server:

  $ systemd-resolve home.mosers.us
  home.mosers.us: 23.28.108.176

  -- Information acquired via protocol DNS in 1.5ms.
  -- Data is authenticated: no

  $ systemd-resolve google.com
  google.com: resolve call failed: No appropriate name servers or networks for 
name found

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Feb 26 09:35:32 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (949 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-32-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.vendor: Intel Corporation

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1751797/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1751797] Re: dns resolution only works for domains in 'search'.

[Scott Moser]

connection.id:  System Ethernet
connection.uuid:72c7fac3-c017-4b76-9954-b4fb08262376
connection.stable-id:   --
connection.type:802-3-ethernet
connection.interface-name:  --
connection.autoconnect: yes
connection.autoconnect-priority:0
connection.autoconnect-retries: -1 (default)
connection.auth-retries:-1
connection.timestamp:   1521122033
connection.read-only:   no
connection.permissions: --
connection.zone:--
connection.master:  --
connection.slave-type:  --
connection.autoconnect-slaves:  -1 (default)
connection.secondaries: --
connection.gateway-ping-timeout:0
connection.metered: unknown
connection.lldp:default
802-3-ethernet.port:--
802-3-ethernet.speed:   0
802-3-ethernet.duplex:  --
802-3-ethernet.auto-negotiate:  no
802-3-ethernet.mac-address: --
802-3-ethernet.cloned-mac-address:  --
802-3-ethernet.generate-mac-address-mask:--
802-3-ethernet.mac-address-blacklist:   --
802-3-ethernet.mtu: auto
802-3-ethernet.s390-subchannels:--
802-3-ethernet.s390-nettype:--
802-3-ethernet.s390-options:--
802-3-ethernet.wake-on-lan: default
802-3-ethernet.wake-on-lan-password:--
ipv4.method:auto
ipv4.dns:   --
ipv4.dns-search:--
ipv4.dns-options:   ""
ipv4.dns-priority:  0
ipv4.addresses: --
ipv4.gateway:   --
ipv4.routes:--
ipv4.route-metric:  -1
ipv4.route-table:   0 (unspec)
ipv4.ignore-auto-routes:no
ipv4.ignore-auto-dns:   no
ipv4.dhcp-client-id:--
ipv4.dhcp-timeout:  0 (default)
ipv4.dhcp-send-hostname:yes
ipv4.dhcp-hostname: --
ipv4.dhcp-fqdn: --
ipv4.never-default: no
ipv4.may-fail:  yes
ipv4.dad-timeout:   -1 (default)
ipv6.method:auto
ipv6.dns:   --
ipv6.dns-search:--
ipv6.dns-options:   ""
ipv6.dns-priority:  0
ipv6.addresses: --
ipv6.gateway:   --
ipv6.routes:--
ipv6.route-metric:  -1
ipv6.route-table:   0 (unspec)
ipv6.ignore-auto-routes:no
ipv6.ignore-auto-dns:   no
ipv6.never-default: no
ipv6.may-fail:  yes
ipv6.ip6-privacy:   -1 (unknown)
ipv6.addr-gen-mode: stable-privacy
ipv6.dhcp-send-hostname:yes
ipv6.dhcp-hostname: --
ipv6.token: --
proxy.method:   none
proxy.browser-only: no
proxy.pac-url:  --
proxy.pac-script:   --
GENERAL.NAME:   System Ethernet
GENERAL.UUID:   72c7fac3-c017-4b76-9954-b4fb08262376
GENERAL.DEVICES:enp0s25
GENERAL.STATE:  activated
GENERAL.DEFAULT:yes
GENERAL.DEFAULT6:   no
GENERAL.SPEC-OBJECT:--
GENERAL.VPN:no
GENERAL.DBUS-PATH:  
/org/freedesktop/NetworkManager/ActiveConnection/1
GENERAL.CON-PATH:   
/org/freedesktop/NetworkManager/Settings/1
GENERAL.ZONE:   --
GENERAL.MASTER-PATH:--
IP4.ADDRESS[1]: 10.7.2.103/16
IP4.GATEWAY:10.7.0.1
IP4.ROUTE[1]:   dst = 0.0.0.0/0, nh = 10.7.0.1, mt = 100
IP4.ROUTE[2]:   dst = 10.7.0.0/16, nh = 0.0.0.0, mt = 
100
IP4.ROUTE[3]:   dst = 169.254.0.0/16, nh = 0.0.0.0, mt 
= 1000
IP4.DNS[1]: 10.7.0.1
IP4.DOMAIN[1]:  mydomain.com
DHCP4.OPTION[1]:requested_subnet_mask = 1
DHCP4.OPTION[2]:
requested_rfc3442_classless_static_routes = 1
DHCP4.OPTION[3]:subnet_mask = 255.255.0.0
DHCP4.OPTION[4]:domain_name_servers = 10.7.0.1
DHCP4.OPTION[5]:ip_address = 10.7.2.103
DHCP4.OPTION[6]:

[Touch-packages] [Bug 1751797] Re: dns resolution only works for domains in 'search'.

[Scott Moser]

$ systemd-resolve --status enp0s25
Link 2 (enp0s25)
  Current Scopes: DNS
   LLMNR setting: yes
MulticastDNS setting: no
  DNSSEC setting: no
DNSSEC supported: no
 DNS Servers: 10.7.0.1
  fdfd::::1
  DNS Domain: ~mydomain.com

$ cat 
/var/lib/NetworkManager/dhclient-72c7fac3-c017-4b76-9954-b4fb08262376-enp0s25.lease
 
lease {
  interface "enp0s25";
  fixed-address 10.7.2.103;
  filename "pxelinux.0";
  option subnet-mask 255.255.0.0;
  option dhcp-lease-time 43200;
  option routers 10.7.0.1;
  option dhcp-message-type 5;
  option dhcp-server-identifier 10.7.0.1;
  option domain-name-servers 10.7.0.1;
  option dhcp-renewal-time 21600;
  option dhcp-rebinding-time 37800;
  option broadcast-address 10.7.255.255;
  option host-name "milhouse-eth0";
  option domain-name "mydomain.com";
  renew 4 2018/03/15 18:51:36;
  rebind 4 2018/03/15 23:41:37;
  expire 5 2018/03/16 01:11:37;
}
lease {
  interface "enp0s25";
  fixed-address 10.7.2.103;
  filename "pxelinux.0";
  option subnet-mask 255.255.0.0;
  option routers 10.7.0.1;
  option dhcp-lease-time 43200;
  option dhcp-message-type 5;
  option domain-name-servers 10.7.0.1;
  option dhcp-server-identifier 10.7.0.1;
  option dhcp-renewal-time 21600;
  option broadcast-address 10.7.255.255;
  option dhcp-rebinding-time 37800;
  option host-name "milhouse-eth0";
  option domain-name "mydomain.com";
  renew 4 2018/03/15 18:19:57;
  rebind 4 2018/03/15 23:48:56;
  expire 5 2018/03/16 01:18:56;
}

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1751797

Title:
  dns resolution only works for domains in 'search'.

Status in network-manager package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  After reboot, dns was broken.
  This is a very simple Network Manager managed interface that has dhcp.

  $ nmcli device show enp0s25  | pastebinit
  http://paste.ubuntu.com/p/sMVTdrMBxJ/

  
  I've attached systemd-resolve --status output.

  In order to file the bug I just modified /etc/resolv.conf to put the
  dns server in directly.

  Other information, it seems like it just will only look for dns under
  my search domains from the dhcp server:

  $ systemd-resolve home.mosers.us
  home.mosers.us: 23.28.108.176

  -- Information acquired via protocol DNS in 1.5ms.
  -- Data is authenticated: no

  $ systemd-resolve google.com
  google.com: resolve call failed: No appropriate name servers or networks for 
name found

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Feb 26 09:35:32 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (949 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-32-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.vendor: Intel Corporation

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1751797/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1751797] Re: dns resolution only works for domains in 'search'.

[Scott Moser]

** Also affects: network-manager (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1751797

Title:
  dns resolution only works for domains in 'search'.

Status in network-manager package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  After reboot, dns was broken.
  This is a very simple Network Manager managed interface that has dhcp.

  $ nmcli device show enp0s25  | pastebinit
  http://paste.ubuntu.com/p/sMVTdrMBxJ/

  
  I've attached systemd-resolve --status output.

  In order to file the bug I just modified /etc/resolv.conf to put the
  dns server in directly.

  Other information, it seems like it just will only look for dns under
  my search domains from the dhcp server:

  $ systemd-resolve home.mosers.us
  home.mosers.us: 23.28.108.176

  -- Information acquired via protocol DNS in 1.5ms.
  -- Data is authenticated: no

  $ systemd-resolve google.com
  google.com: resolve call failed: No appropriate name servers or networks for 
name found

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Feb 26 09:35:32 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (949 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-32-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.vendor: Intel Corporation

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1751797/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1714308] Re: dns does not work in initramfs after configure_networking

[Scott Moser]

** Merge proposal unlinked:
   
https://code.launchpad.net/~smoser/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/341203

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1714308

Title:
  dns does not work in initramfs after configure_networking

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

Bug description:
  in an initramfs built with mkinitramfs-tools that has been booted with
  'ip=' and a dhcp server responded in the dhcp request, you would
  expect dns to work.

  currently it does not.
  at least part of the issue is that libnss_dns.so is missing.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: initramfs-tools 0.125ubuntu9
  ProcVersionSignature: User Name 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  Date: Thu Aug 31 16:43:05 2017
  Ec2AMI: ami-00e4
  Ec2AMIManifest: FIXME
  Ec2AvailabilityZone: nova
  Ec2InstanceType: m1.small
  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: initramfs-tools
  UpgradeStatus: No upgrade log present (probably fresh install)

  Related bugs:
   * bug 1698181: Switch to netplan renderer in Artful
   * bug 1714028: artful network vmtests fail now that ifdown command is removed

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1713803] Re: replacement of resolvconf with systemd needs integration

[Scott Moser]

** Merge proposal linked:
   
https://code.launchpad.net/~smoser/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/341203

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1713803

Title:
  replacement of resolvconf with systemd needs integration

Status in android-androresolvd package in Ubuntu:
  Triaged
Status in avahi package in Ubuntu:
  Triaged
Status in bind9 package in Ubuntu:
  Triaged
Status in cloud-init package in Ubuntu:
  Incomplete
Status in cloud-initramfs-tools package in Ubuntu:
  Invalid
Status in dhcpcd5 package in Ubuntu:
  New
Status in dibbler package in Ubuntu:
  Won't Fix
Status in dnscrypt-proxy package in Ubuntu:
  Confirmed
Status in dnsmasq package in Ubuntu:
  Invalid
Status in dnssec-trigger package in Ubuntu:
  Invalid
Status in fetchmail package in Ubuntu:
  Confirmed
Status in freedombox-setup package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in ndisc6 package in Ubuntu:
  Fix Released
Status in netscript-2.4 package in Ubuntu:
  Won't Fix
Status in open-iscsi package in Ubuntu:
  Triaged
Status in openvpn package in Ubuntu:
  Confirmed
Status in postfix package in Ubuntu:
  New
Status in pppconfig package in Ubuntu:
  Confirmed
Status in pump package in Ubuntu:
  Confirmed
Status in resolvconf package in Ubuntu:
  Invalid
Status in sendmail package in Ubuntu:
  New
Status in squid3 package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Invalid
Status in unbound package in Ubuntu:
  New
Status in vpnc package in Ubuntu:
  Invalid
Status in vpnc-scripts package in Ubuntu:
  Invalid
Status in whereami package in Ubuntu:
  Triaged

Bug description:
  There is a plan to remove resolvconf from the Ubuntu Server image.
  resolvconf integrated with other parts of the system in 2 ways:
   * hooks invoked on change (/etc/resolvconf/update.d/)
   * resolvconf tool (invoked with -a and -d or -u)

  Packages which install files into /etc/resolvconf/update.d are:
  - dnsmasq: This may be mostly covered by systemd-resolved itself (the dns
    caching path).
  - resolvconf: This probably isn't necessary in systemd-resolved path.
  - unbound: This is another "validating, recursive, caching DNS resolver".

  The list of Depends/Suggests/Recommends on resolvconf.

  # for pkg in $(apt-cache rdepends resolvconf | grep -v openreso | grep -v 
Reverse); do out=$(apt-cache show $pkg | grep resolvconf); src=$(apt-cache show 
$pkg | awk '$1 == "Source:" { print $2 }'); [ -n "$src" ] || src=$pkg; case 
"$out" in Depends:*resolvconf) r=depends;; Suggests:*) r=suggests;; 
Recommends:*) r=recommends;; esac; echo "$r $src"; done  | sort -u
  depends android-androresolvd
  recommends avahi
  recommends dhcpcd5
  recommends dibbler
  recommends ndisc6
  recommends whereami
  suggests bind9
  suggests dnscrypt-proxy
  suggests dnsmasq
  suggests dnssec-trigger
  suggests fetchmail
  suggests freedombox-setup
  suggests isc-dhcp
  suggests netscript-2.4
  suggests openvpn
  suggests postfix
  suggests pppconfig
  suggests pump
  suggests resolvconf
  suggests sendmail
  suggests squid3
  suggests vpnc
  suggests vpnc-scripts

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: systemd 234-2ubuntu9
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  ApportVersion: 2.20.6-0ubuntu7
  Architecture: amd64
  Date: Tue Aug 29 18:53:50 2017
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.12.0-11-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.vendor: Intel Corporation

  Related bugs:
   * bug 1698181: Switch to netplan renderer in Artful
   * bug 1714308: dns does not work in initramfs after configure_networking
   * bug 1717983 replacement of isc-dhcp-client with with systemd-networkd for 
dhclient needs integration

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/android-androresolvd/+bug/1713803/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1714308] Re: dns does not work in initramfs after configure_networking

[Scott Moser]

** Merge proposal linked:
   
https://code.launchpad.net/~smoser/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/341203

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1714308

Title:
  dns does not work in initramfs after configure_networking

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

Bug description:
  in an initramfs built with mkinitramfs-tools that has been booted with
  'ip=' and a dhcp server responded in the dhcp request, you would
  expect dns to work.

  currently it does not.
  at least part of the issue is that libnss_dns.so is missing.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: initramfs-tools 0.125ubuntu9
  ProcVersionSignature: User Name 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  Date: Thu Aug 31 16:43:05 2017
  Ec2AMI: ami-00e4
  Ec2AMIManifest: FIXME
  Ec2AvailabilityZone: nova
  Ec2InstanceType: m1.small
  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: initramfs-tools
  UpgradeStatus: No upgrade log present (probably fresh install)

  Related bugs:
   * bug 1698181: Switch to netplan renderer in Artful
   * bug 1714028: artful network vmtests fail now that ifdown command is removed

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Scott Moser]

** No longer affects: maas

** No longer affects: nplan (Ubuntu)

** No longer affects: systemd (Ubuntu)

** Changed in: cloud-init
   Status: New => Confirmed

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

** Changed in: cloud-init
 Assignee: (unassigned) => Ryan Harper (raharper)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750884

Title:
  [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
  leads to no DNS resolution

Status in cloud-init:
  Confirmed

Bug description:
  When deploying Bionic, /etc/resolv.conf is not configured correctly,
  which leads to no DNS resolution. In the output below, you will see
  that netplan config is correctly to the 10.90.90.1 nameserver, but in
  resolv.conf that's a local address.

  Resolv.conf should really be configured to use the provided DNS
  server(s). That said, despite that fact, DNS resolution doesn't work
  with the local address.

  Bionic
  --

  ubuntu@node01:~$ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  enp0s25:
  match:
  macaddress: b8:ae:ed:7d:17:d2
  mtu: 1500
  nameservers:
  addresses:
  - 10.90.90.1
  search:
  - maaslab
  - maas
  set-name: enp0s25
  bridges:
  br0:
  addresses:
  - 10.90.90.3/24
  gateway4: 10.90.90.1
  interfaces:
  - enp0s25
  parameters:
  forward-delay: 15
  stp: false
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 127.0.0.53

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  ping: google.com: Temporary failure in name resolution

  [...]

  ubuntu@node01:~$ sudo vim /etc/resolv.conf
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 10.90.90.1

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  PING google.com (172.217.0.174) 56(84) bytes of data.
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=1 ttl=52 
time=4.46 ms
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=2 ttl=52 
time=4.38 ms

  =
  Xenial
  ==

  ubuntu@node05:~$ 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
  dns-nameservers 10.90.90.1
  dns-search maaslab maas

  auto enp0s25
  iface enp0s25 inet static
  address 10.90.90.162/24
  gateway 10.90.90.1
  mtu 1500
  ubuntu@node05:~$ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  nameserver 10.90.90.1
  search maaslab maas

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Scott Moser]

I'm pretty sure that if you you rm /etc/resolv.conf
and then just write what ever you want in there, it wont get overritten.

mv /etc/resolv.conf /etc/resolv.conf.dist
echo "nameserver 8.8.8.8" > /etc/resolv.conf


On Thu, Mar 8, 2018 at 4:36 PM, Mike Pontillo 
wrote:

> We discussed this today and decided that the proper place to fix this is
> not in MAAS; the v1 YAML containing global DNS servers should be
> converted to equivalent valid Netplan (using a heuristic).
>
> Alternatively, global DNS could be added to the Netplan schema (possibly
> as a shortcut to apply configuration to a group of interfaces).
>
> --
> You received this bug notification because you are a member of Canonical
> Cloudware, which is subscribed to cloud-init.
> Matching subscriptions: cloud-init bugs
> https://bugs.launchpad.net/bugs/1750884
>
> Title:
>   [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
>   leads to no DNS resolution
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cloud-init/+bug/1750884/+subscriptions
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750884

Title:
  [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
  leads to no DNS resolution

Status in cloud-init:
  New
Status in MAAS:
  Triaged
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  When deploying Bionic, /etc/resolv.conf is not configured correctly,
  which leads to no DNS resolution. In the output below, you will see
  that netplan config is correctly to the 10.90.90.1 nameserver, but in
  resolv.conf that's a local address.

  Resolv.conf should really be configured to use the provided DNS
  server(s). That said, despite that fact, DNS resolution doesn't work
  with the local address.

  Bionic
  --

  ubuntu@node01:~$ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  enp0s25:
  match:
  macaddress: b8:ae:ed:7d:17:d2
  mtu: 1500
  nameservers:
  addresses:
  - 10.90.90.1
  search:
  - maaslab
  - maas
  set-name: enp0s25
  bridges:
  br0:
  addresses:
  - 10.90.90.3/24
  gateway4: 10.90.90.1
  interfaces:
  - enp0s25
  parameters:
  forward-delay: 15
  stp: false
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 127.0.0.53

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  ping: google.com: Temporary failure in name resolution

  [...]

  ubuntu@node01:~$ sudo vim /etc/resolv.conf
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 10.90.90.1

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  PING google.com (172.217.0.174) 56(84) bytes of data.
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=1 ttl=52 
time=4.46 ms
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=2 ttl=52 
time=4.38 ms

  =
  Xenial
  ==

  ubuntu@node05:~$ 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
  dns-nameservers 10.90.90.1
  dns-search maaslab maas

  auto enp0s25
  iface enp0s25 inet static
  address 10.90.90.162/24
  gateway 10.90.90.1
  mtu 1500
  ubuntu@node05:~$ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  nameserver 10.90.90.1
  search maaslab maas

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

-- 
Mailing list: 

[Touch-packages] [Bug 972077] Re: apt repository disk format has race conditions

[Scott Moser]

Hi.
Just to re-iterate what Robie said.

If you are seeing hashsum mismatch errors on 16.04 or later, something is wrong.
That could be:
a.) you have a proxy in your way, and the proxy cached a bad download.
Apt is recognizing this and not installing it.
That is working as designed.
Note, that http proxies can be transparent (ie, no explicit configuration from 
you).
Your ISP could be providing a proxy service that is simply broken.

b.) You're using a mirror that does not support 'by-hash'.

c.) there could be an error in the official ubuntu publishers.  If they updated
the Release file before content that it referenced was complete then
that would cause apt to correctly identify the invalid data.

So, what should you do?

First, rule out the most likely problem... the proxy.
If you have an explicitly configured proxy, then unconfigure it.

You can probably verify there is a proxy in your path via:
wget -q -S http://archive.ubuntu.com/ubuntu/dists/xenial/Release -O/dev/null

If you see 'X-Cache' in the output, then there is a proxy between you
and archive.ubuntu.com.


If you are seeing this issue on Ubuntu 14.04, then that is not easily fixed.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/972077

Title:
  apt repository disk format has race conditions

Status in APT:
  Fix Released
Status in apt package in Ubuntu:
  Fix Released

Bug description:
  Apt archives are accessed over HTTP; this has resulted in a cluster of
  bugs (reported here, and upstream) about problems behind intercepting
  caches, problems with squid etc.

  There are 3 interlocking issues:
  A - mirror networks may be out of sync with each other (e.g. a file named on 
one mirror may no longer exist, or may not yet exist, on another mirror)
  B - updating files on a single mirror is not atomic - and even small windows 
of inconsistency will, given enough clients, cause headaches.
  C - caches exacerbate race conditions - when one happens, until the cached 
data expires, all clients of the cache will suffer from the race

  Solving this requires one of several things:
   - file system transactions
   - an archive format that requires only weakly ordered updates to the files 
at particular urls with the assumption that only one file may be observed to 
change at a time (because a lookup of file A, then B, may get a cache miss on A 
and a cache hit on B, so even if all clients strictly go A, then B, updates may 
still see old files when paths are reused).
   - super robust clients that repeatedly retry with progressively less cache 
friendly headers until they have a consistent view. (This is very tricky to do).

  It may be possible to do a tweak to the apt repository format though,
  which would allow publishing a race-free format in parallel with the
  existing layout, while clients migrate. To be safe against issue (A)
  the mirror network would need some care around handling of dns round-
  robin mirrors [to minimise the situation where referenced data is not
  available], but this should be doable - or alternatively clients doing
  'apt-get update' may need to be willing to retry to accommodate round-
  robin skew.

  What would such an archive format look like?
  It would have only one well known file name (InRelease), which would be 
internally signed. Rather than signing e.g. Packages.gz, it would sign a 
uniquely named packages and sources file - e.g. Packages-$HASH.gz or 
Packages-$serialno.gz.

  Backwards compatibility is achieved by using the same filenames for
  deb's and the like. We need to keep writing Packages.gz though, and
  Releases, until we no longer worry about old apt clients. We can
  optimise disk space a little by making Packages.gz a symlink to a
  Packages-$HASH.gz (and so on for Sources..), but it may be simpler and
  less prone to unexpected behaviour to keep using regular files.

  tl;dr
   * Unique file names for all unique file content with one exception
   * InRelease, a self-signed file that provides hashes and names the index 
files (Packages, Sources, Translations etc)
   * Coexists with existing archive layout

  Related bugs:
   * bug 804252: Please support InRelease files
   * bug 1430011: support apt by-hash mirrors

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1751797] Re: dns resolution only works for domains in 'search'.

[Scott Moser]

** Changed in: systemd (Ubuntu)
   Importance: Undecided => Critical

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1751797

Title:
  dns resolution only works for domains in 'search'.

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  After reboot, dns was broken.
  This is a very simple Network Manager managed interface that has dhcp.

  $ nmcli device show enp0s25  | pastebinit
  http://paste.ubuntu.com/p/sMVTdrMBxJ/

  
  I've attached systemd-resolve --status output.

  In order to file the bug I just modified /etc/resolv.conf to put the
  dns server in directly.

  Other information, it seems like it just will only look for dns under
  my search domains from the dhcp server:

  $ systemd-resolve home.mosers.us
  home.mosers.us: 23.28.108.176

  -- Information acquired via protocol DNS in 1.5ms.
  -- Data is authenticated: no

  $ systemd-resolve google.com
  google.com: resolve call failed: No appropriate name servers or networks for 
name found

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Feb 26 09:35:32 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (949 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-32-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.vendor: Intel Corporation

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Scott Moser]

Currently maas sends v1 config to cloud-init. cloud-init converts
that to netplan.  MAAS could certainly change change to either
a.) improve the v1 config that it sends to put dns as per-interface
b.) send v2 config with dns per-interface.

I don't think there is reason to justify either of those at this time.

I do think that at some point MAAS network configuration will be
hindered and they'll end up wanting to describe dns more eloquently.
That time is not yet upon us.

Mathieu, you tell us how to indicate global dns in netplan configuration
and cloud-init will make sure it gets through to netplan correctly.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750884

Title:
  [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
  leads to no DNS resolution

Status in cloud-init:
  New
Status in MAAS:
  Triaged
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  When deploying Bionic, /etc/resolv.conf is not configured correctly,
  which leads to no DNS resolution. In the output below, you will see
  that netplan config is correctly to the 10.90.90.1 nameserver, but in
  resolv.conf that's a local address.

  Resolv.conf should really be configured to use the provided DNS
  server(s). That said, despite that fact, DNS resolution doesn't work
  with the local address.

  Bionic
  --

  ubuntu@node01:~$ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  enp0s25:
  match:
  macaddress: b8:ae:ed:7d:17:d2
  mtu: 1500
  nameservers:
  addresses:
  - 10.90.90.1
  search:
  - maaslab
  - maas
  set-name: enp0s25
  bridges:
  br0:
  addresses:
  - 10.90.90.3/24
  gateway4: 10.90.90.1
  interfaces:
  - enp0s25
  parameters:
  forward-delay: 15
  stp: false
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 127.0.0.53

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  ping: google.com: Temporary failure in name resolution

  [...]

  ubuntu@node01:~$ sudo vim /etc/resolv.conf
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 10.90.90.1

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  PING google.com (172.217.0.174) 56(84) bytes of data.
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=1 ttl=52 
time=4.46 ms
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=2 ttl=52 
time=4.38 ms

  =
  Xenial
  ==

  ubuntu@node05:~$ 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
  dns-nameservers 10.90.90.1
  dns-search maaslab maas

  auto enp0s25
  iface enp0s25 inet static
  address 10.90.90.162/24
  gateway 10.90.90.1
  mtu 1500
  ubuntu@node05:~$ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  nameserver 10.90.90.1
  search maaslab maas

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750780] Re: Race with local file systems can make open-vm-tools fail to start

[Scott Moser]

I agree with reverting change in bionic, and that xenial still needs
some fix.

I recreated your failure in xenial and agree with your change there.
I used this job as it actually tries to write to the private tmp.

If I change 'ExecStart' below to be  just '/bin/true' like in your job,
it does not fail (status says 'code=exited, status=0/SUCCESS).  But the
command below seems to never get exited (it produces no output).

So it seems to me that the 'Read only filesystem' error is not even from
the service itself, but rather from systemd, and also dependent on the
content in ExecStart.

$ cat /lib/systemd/system/my-ptmp-test.service
[Unit]
Description=foo
DefaultDependencies=no
[Service]
Type=oneshot
PrivateTmp=yes
ExecStart=/bin/sh -ec 'f=/tmp/my.txt; uptime > $f; echo ==; cat $f; echo ==; 
cat /proc/mounts'
[Install]
WantedBy=multi-user.target


Then we can see the same failure:

$ journalctl -o short-monotonic --no-pager | grep --context=2 my-ptmp-test
[7.715220] xenial-20180223-142555 systemd[1]: Created slice System Slice.
[7.718923] xenial-20180223-142555 systemd[1]: Created slice 
system-systemd\x2dfsck.slice.
[7.740250] xenial-20180223-142555 systemd[1]: my-ptmp-test.service: Failed 
to run 'start' task: Read-only file system
[7.749135] xenial-20180223-142555 systemd[1]: Failed to start foo.
[7.754114] xenial-20180223-142555 systemd[1]: my-ptmp-test.service: Unit 
entered failed state.
[7.760217] xenial-20180223-142555 systemd[1]: my-ptmp-test.service: Failed 
with result 'resources'.
[7.764170] xenial-20180223-142555 systemd[1]: Starting Load Kernel 
Modules...
[7.775558] xenial-20180223-142555 systemd[1]: Starting Journal Service...

$ systemctl status my-ptmp-test.service --no-pager --full
● my-ptmp-test.service - foo
   Loaded: loaded (/lib/systemd/system/my-ptmp-test.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: resources)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750780

Title:
  Race with local file systems can make open-vm-tools fail to start

Status in cloud-init:
  Invalid
Status in open-vm-tools package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in open-vm-tools source package in Xenial:
  Triaged
Status in systemd source package in Xenial:
  New
Status in open-vm-tools package in Debian:
  Incomplete

Bug description:
  Since the change in [1] open-vm-tools-service starts very (very) early.
  Not so much due to the 
  Before=cloud-init-local.service
  But much more by
  DefaultDependencies=no

  That can trigger an issue that looks like
  root@ubuntuguest:~# systemctl status -l open-vm-tools.service
  ● open-vm-tools.service - Service for virtual machines hosted on VMware
 Loaded: loaded (/lib/systemd/system/open-vm-tools.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: resources)

  
  As it is right now open-vm-tools can race with the other early start and then 
fail.
  In detail one can find a message like:
open-vm-tools.service: Failed to run 'start' task: Read-only file system"

  This is due to privtaeTmp=yes which is also set needing a writable
  /var/tmp [2]

  To ensure this works PrivateTmp would have to be removed (not good) or some 
after dependencies added that make this work reliably.
  I added
  After=local-fs.target
  which made it work for me in 3/3 tests.

  I' like to have an ack by the cloud-init Team that this does not totally kill 
the originally intended Before=cloud-init-local.service
  I think it does not as local-fs can complete before cloud-init-local, then 
open-vm-tools can initialize and finally cloud-init-local can pick up the data.

  To summarize:
  # cloud-init-local #
  DefaultDependencies=no
  Wants=network-pre.target
  After=systemd-remount-fs.service
  Before=NetworkManager.service
  Before=network-pre.target
  Before=shutdown.target
  Before=sysinit.target
  Conflicts=shutdown.target
  RequiresMountsFor=/var/lib/cloud

  # open-vm-tools #
  DefaultDependencies=no
  Before=cloud-init-local.service

  Proposed is to add to the latter:
  After=local-fs.target

  [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859677
  [2]: https://github.com/systemd/systemd/issues/5610

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1751797] Re: dns resolution only works for domains in 'search'.

[Scott Moser]

** Description changed:

  After reboot, dns was broken.
+ This is a very simple Network Manager managed interface that has dhcp.
+ 
+ $ nmcli device show enp0s25  | pastebinit
+ http://paste.ubuntu.com/p/sMVTdrMBxJ/
+ 
+ 
  I've attached systemd-resolve --status output.
  
  In order to file the bug I just modified /etc/resolv.conf to put the dns
  server in directly.
  
  Other information, it seems like it just will only look for dns under my
  search domains from the dhcp server:
  
  $ systemd-resolve home.mosers.us
  home.mosers.us: 23.28.108.176
  
  -- Information acquired via protocol DNS in 1.5ms.
  -- Data is authenticated: no
  
  $ systemd-resolve google.com
  google.com: resolve call failed: No appropriate name servers or networks for 
name found
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Feb 26 09:35:32 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (949 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  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
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-32-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.vendor: Intel Corporation

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1751797

Title:
  dns resolution only works for domains in 'search'.

Status in systemd package in Ubuntu:
  New

Bug description:
  After reboot, dns was broken.
  This is a very simple Network Manager managed interface that has dhcp.

  $ nmcli device show enp0s25  | pastebinit
  http://paste.ubuntu.com/p/sMVTdrMBxJ/

  
  I've attached systemd-resolve --status output.

  In order to file the bug I just modified /etc/resolv.conf to put the
  dns server in directly.

  Other information, it seems like it just will only look for dns under
  my search domains from the dhcp server:

  $ systemd-resolve home.mosers.us
  home.mosers.us: 23.28.108.176

  -- Information acquired via protocol DNS in 1.5ms.
  -- Data is authenticated: no

  $ systemd-resolve google.com
  google.com: resolve call failed: No appropriate name servers or networks for 
name found

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Feb 26 09:35:32 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (949 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-32-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.vendor: Intel Corporation

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1732028] Re: transient boot fail with overlayroot [open-iscsi dep8 tests]

[Scott Moser]

** Summary changed:

- transient boot fail with overlayroot
+ transient boot fail with overlayroot [open-iscsi dep8 tests]

** Attachment added: "bionic failure log 2.0.874-5ubuntu2   
qemu/1:2.11+dfsg-1ubuntu2"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1732028/+attachment/5063566/+files/log.gz

** Summary changed:

- transient boot fail with overlayroot [open-iscsi dep8 tests]
+ transient boot fail with overlayroot [open-iscsi autopkg tests]

** Also affects: open-iscsi (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1732028

Title:
  transient boot fail with overlayroot [open-iscsi autopkg tests]

Status in open-iscsi package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  This issue keeps cropping up.  It shows itself in open-iscsi autopkg tests.
  I think it might just be "really slow system".  It seems the timeout is only
   1 minute 30 seconds for the disk to appear, and in a happy run you
  might see something very close:

  [K[   [0;31m*[0;1;31m*[0m[0;31m*[0m] A start job is running for 
dev-disk…-UEFI.device (1min 29s / 1min 32s)
  [K[  [0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for 
dev-disk…-UEFI.device (1min 30s / 1min 32s)
  [K[[0;32m  OK  [0m] Found device VIRTUAL-DISK UEFI.
   Mounting /boot/efi...

  ---
  There is information on the open-iscsi tests at [1].
[1] 
https://git.launchpad.net/~usd-import-team/ubuntu/+source/open-iscsi/tree/debian/tests/README-boot-test.md

  The tests set up an iscsi target and boot a kvm guest off that read-
  only root with overlayroot.

  # get open-iscsi source
  $ apt-get source open-iscsi
  $ cd open-iscsi-2.0.874/

  $ sudo apt-get install -qy simplestreams tgt qemu-system-x86 \
   cloud-image-utils distro-info
  $ cd open-iscsi-2.0.874/

  ## we're now mostly following debian/tests/README-boot-test.md
  # download the image and get kernel/initrd
  $ PATH=$PWD/debian/tests:$PATH
  $ get-image bionic.d bionic 
  $ sudo `which patch-image` \
  --kernel=bionic.d/kernel --initrd=bionic.d/initrd bionic.d/disk.img

  $ tgt-boot-test -v bionic.d/disk.img bionic.d/kernel bionic.d/initrd
  

  Success is being able to log in with 'ubuntu' and 'passw0rd'.
  Failure as seen in the log is dropping into an emergency shell.

  Once inside (this was successful) you'll see a mostly sane system.
  Some things to note:
  a.) tgt-boot-test boots without kvm enabled.  This is because using
   kvm with qemu in nested virt would cause system lockups. Its slower
  but more reliable to go wtihout.
  b.) under bug 1723183 I  made overlayroot comment out the root filesystem
  from the rendered /etc/fstab.  That was because systemd got confused and
  assumed that /media/root-ro had to be on top of /.
  c.) you can enable or disable kvm by setting _USE_KVM=0 or _USE_KVM=1
 in your environment.

  $ grep -v "^# " /etc/fstab
  #
  #
  #LABEL=cloudimg-rootfs /media/root-ro/ ext4 ro,defaults,noauto 0 0
  /media/root-ro/ / overlay 
lowerdir=/media/root-ro/,upperdir=/media/root-rw/overl
  ay/,workdir=/media/root-rw/overlay-workdir/_ 0 0
  LABEL=UEFI /boot/efi vfat defaults 0 0 # overlayroot:fs-unsupported

  $ sudo blkid
  /dev/sda1: LABEL="cloudimg-rootfs" 
UUID="7b1980bd-9102-4356-8df0-ec7a0c062411" TYPE="ext4" 
PARTUUID="c0b5ace0-4703-4667-babb-3d38137cab88"
  /dev/sda15: LABEL="UEFI" UUID="B177-3CC9" TYPE="vfat" 
PARTUUID="0ab0b9fd-2c28-4724-857a-1559f0cf76ea"
  /dev/sda14: PARTUUID="221662d6-cab0-4290-ba1c-e72acf2bf193"

  $ cat /run/systemd/generator/local-fs.target.requires/boot-efi.mount
  # Automatically generated by systemd-fstab-generator

  [Unit]
  SourcePath=/etc/fstab
  Documentation=man:fstab(5) man:systemd-fstab-generator(8)
  Before=local-fs.target

  [Mount]
  Where=/boot/efi
  What=/dev/disk/by-label/UEFI
  Type=vfat

  Related bugs:
   * bug 1680197: Zesty deployments failing sporadically
   * bug 1723183: transient systemd ordering issue when using overlayroot

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 234-2ubuntu12
  ProcVersionSignature: User Name 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu4
  Architecture: amd64
  Date: Mon Nov 13 21:06:36 2017
  Lsusb: Error: command ['lsusb'] failed with exit code 1:
  MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
  ProcEnviron:
   TERM=vt220
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: nomodeset iscsi_initiator=maas-enlist 
iscsi_target_name=tgt-boot-test-7xuhwl iscsi_target_ip=10.0.12.2 
iscsi_target_port=3260 iscsi_initiator=maas-enlist ip=maas-enlist:BOOTIF ro 
net.ifnames=0 BOOTIF_DEFAULT=eth0 
root=/dev/disk/by-path/ip-10.0.12.2:3260-iscsi-tgt-boot-test-7xuhwl-lun-1-part1 
overlayroot=tmpfs console=ttyS0 

[Touch-packages] [Bug 1751797] [NEW] dns resolution only works for domains in 'search'.

[Scott Moser]

Public bug reported:

After reboot, dns was broken.
I've attached systemd-resolve --status output.

In order to file the bug I just modified /etc/resolv.conf to put the dns
server in directly.

Other information, it seems like it just will only look for dns under my
search domains from the dhcp server:

$ systemd-resolve home.mosers.us
home.mosers.us: 23.28.108.176

-- Information acquired via protocol DNS in 1.5ms.
-- Data is authenticated: no

$ systemd-resolve google.com
google.com: resolve call failed: No appropriate name servers or networks for 
name found

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd 237-3ubuntu3
ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13
Uname: Linux 4.13.0-32-generic x86_64
NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
ApportVersion: 2.20.8-0ubuntu10
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Mon Feb 26 09:35:32 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2015-07-23 (949 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-32-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.vendor: Intel Corporation

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug bionic

** Attachment added: "output of systemd-resolve --status"
   
https://bugs.launchpad.net/bugs/1751797/+attachment/5063476/+files/systemd-resolv-status.txt

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1751797

Title:
  dns resolution only works for domains in 'search'.

Status in systemd package in Ubuntu:
  New

Bug description:
  After reboot, dns was broken.
  I've attached systemd-resolve --status output.

  In order to file the bug I just modified /etc/resolv.conf to put the
  dns server in directly.

  Other information, it seems like it just will only look for dns under
  my search domains from the dhcp server:

  $ systemd-resolve home.mosers.us
  home.mosers.us: 23.28.108.176

  -- Information acquired via protocol DNS in 1.5ms.
  -- Data is authenticated: no

  $ systemd-resolve google.com
  google.com: resolve call failed: No appropriate name servers or networks for 
name found

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Feb 26 09:35:32 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (949 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-32-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.vendor: Intel Corporation

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1751797] Re: dns resolution only works for domains in 'search'.

[Scott Moser]

I had hoped that simply disconnect/reconnect of the interface would
work, but that did not improve things. (nmcli device disconnect enp0s25
; nmcli device connect enp0s25)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1751797

Title:
  dns resolution only works for domains in 'search'.

Status in systemd package in Ubuntu:
  New

Bug description:
  After reboot, dns was broken.
  I've attached systemd-resolve --status output.

  In order to file the bug I just modified /etc/resolv.conf to put the
  dns server in directly.

  Other information, it seems like it just will only look for dns under
  my search domains from the dhcp server:

  $ systemd-resolve home.mosers.us
  home.mosers.us: 23.28.108.176

  -- Information acquired via protocol DNS in 1.5ms.
  -- Data is authenticated: no

  $ systemd-resolve google.com
  google.com: resolve call failed: No appropriate name servers or networks for 
name found

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Feb 26 09:35:32 2018
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (949 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-32-generic 
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.vendor: Intel Corporation

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750031] Re: scary/unexpected output in adduser and deluser

[Scott Moser]

I've also tried a bionic azure image 
$ cat /etc/cloud/build.info 
build_name: server
serial: 20180222

It did not reproduce there.
So as far as I can tell it shows itself only on Azure 16.04 images.


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

** Changed in: cloud-images
   Status: New => Confirmed

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

** Changed in: cloud-images
   Importance: Medium => Low

** Description changed:

+ On 16.04 images on Azure,
  adduser and deluser are now printing to stderr 'sent invalidate(passwd)' and
  'sent invalidate(group)'.
  
- These are confusing at best and new in bionic.
+ These are confusing at best.
  See below. They do not seem harmful, but not wonderful.
  
+ I only see them on images of 16.04 on Azure.  I cannot reproduce in
+ 16.04 or 18.04 images on LXD, Openstack.  I cannot reproduce in 18.04
+ on Azure.
  
  smoser@ubuntu1:~$ sudo adduser guest
  Adding user `guest' ...
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Adding new group `guest' (1001) ...
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Adding new user `guest' (1001) with group `guest' ...
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  The home directory `/home/guest' already exists.  Not copying from 
`/etc/skel'.
- Enter new UNIX password: 
- Retype new UNIX password: 
+ Enter new UNIX password:
+ Retype new UNIX password:
  passwd: password updated successfully
  Changing the user information for guest
  Enter the new value, or press ENTER for the default
- Full Name []: Foo Bar
- Room Number []: 
- Work Phone []: 
- Home Phone []: 
- Other []: 
+ Full Name []: Foo Bar
+ Room Number []:
+ Work Phone []:
+ Home Phone []:
+ Other []:
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
- Is the information correct? [Y/n] 
+ Is the information correct? [Y/n]
  smoser@ubuntu1:~$ sudo deluser guest
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Removing user `guest' ...
  Warning: group `guest' has no more members.
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Done.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: adduser 3.113+nmu3ubuntu4
  ProcVersionSignature: User Name 4.13.0-1007.9-azure 4.13.13
  Uname: Linux 4.13.0-1007-azure x86_64
  ApportVersion: 2.20.1-0ubuntu2.15
  Architecture: amd64
  Date: Fri Feb 16 19:30:12 2018
  PackageArchitecture: all
  ProcEnviron:
-  TERM=screen
-  PATH=(custom, no user)
-  XDG_RUNTIME_DIR=
-  LANG=en_US.UTF-8
-  SHELL=/bin/bash
+  TERM=screen
+  PATH=(custom, no user)
+  XDG_RUNTIME_DIR=
+  LANG=en_US.UTF-8
+  SHELL=/bin/bash
  SourcePackage: adduser
  UpgradeStatus: No upgrade log present (probably fresh install)

** Also affects: cloud-images/x-series
   Importance: Undecided
   Status: New

** Changed in: cloud-images/x-series
   Status: New => Confirmed

** Changed in: cloud-images/x-series
   Importance: Undecided => Low

** Changed in: cloud-images
   Status: Confirmed => Invalid

** No longer affects: adduser (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to adduser in Ubuntu.
https://bugs.launchpad.net/bugs/1750031

Title:
  scary/unexpected output in adduser and deluser

Status in cloud-images:
  Invalid
Status in cloud-images x-series series:
  Confirmed

Bug description:
  On 16.04 images on Azure,
  adduser and deluser are now printing to stderr 'sent invalidate(passwd)' and
  'sent invalidate(group)'.

  These are confusing at best.
  See below. They do not seem harmful, but not wonderful.

  I only see them on images of 16.04 on Azure.  I cannot reproduce in
  16.04 or 18.04 images on LXD, Openstack.  I cannot reproduce in 18.04
  on Azure.

  smoser@ubuntu1:~$ sudo adduser guest
  Adding user `guest' ...
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Adding new group `guest' (1001) ...
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Adding new user `guest' (1001) with group 

[Touch-packages] [Bug 1750031] Re: scary/unexpected output in adduser and deluser

[Scott Moser]

This bug was reproduced on a xenial Azure cloud image 
$ cat /etc/cloud/build.info 
build_name: server
serial: 20180222

I cannot reproduce it locally in a container.

** Tags added: xenial

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to adduser in Ubuntu.
https://bugs.launchpad.net/bugs/1750031

Title:
  scary/unexpected output in adduser and deluser

Status in adduser package in Ubuntu:
  Confirmed

Bug description:
  adduser and deluser are now printing to stderr 'sent invalidate(passwd)' and
  'sent invalidate(group)'.

  These are confusing at best and new in bionic.
  See below. They do not seem harmful, but not wonderful.

  
  smoser@ubuntu1:~$ sudo adduser guest
  Adding user `guest' ...
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Adding new group `guest' (1001) ...
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Adding new user `guest' (1001) with group `guest' ...
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  The home directory `/home/guest' already exists.  Not copying from 
`/etc/skel'.
  Enter new UNIX password: 
  Retype new UNIX password: 
  passwd: password updated successfully
  Changing the user information for guest
  Enter the new value, or press ENTER for the default
  Full Name []: Foo Bar
  Room Number []: 
  Work Phone []: 
  Home Phone []: 
  Other []: 
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  Is the information correct? [Y/n] 
  smoser@ubuntu1:~$ sudo deluser guest
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Removing user `guest' ...
  Warning: group `guest' has no more members.
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Done.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: adduser 3.113+nmu3ubuntu4
  ProcVersionSignature: User Name 4.13.0-1007.9-azure 4.13.13
  Uname: Linux 4.13.0-1007-azure x86_64
  ApportVersion: 2.20.1-0ubuntu2.15
  Architecture: amd64
  Date: Fri Feb 16 19:30:12 2018
  PackageArchitecture: all
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: adduser
  UpgradeStatus: No upgrade log present (probably fresh install)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750031] Re: scary/unexpected output in adduser and deluser

[Scott Moser]

** Tags removed: xenial

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to adduser in Ubuntu.
https://bugs.launchpad.net/bugs/1750031

Title:
  scary/unexpected output in adduser and deluser

Status in adduser package in Ubuntu:
  Confirmed

Bug description:
  adduser and deluser are now printing to stderr 'sent invalidate(passwd)' and
  'sent invalidate(group)'.

  These are confusing at best and new in bionic.
  See below. They do not seem harmful, but not wonderful.

  
  smoser@ubuntu1:~$ sudo adduser guest
  Adding user `guest' ...
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Adding new group `guest' (1001) ...
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Adding new user `guest' (1001) with group `guest' ...
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  The home directory `/home/guest' already exists.  Not copying from 
`/etc/skel'.
  Enter new UNIX password: 
  Retype new UNIX password: 
  passwd: password updated successfully
  Changing the user information for guest
  Enter the new value, or press ENTER for the default
  Full Name []: Foo Bar
  Room Number []: 
  Work Phone []: 
  Home Phone []: 
  Other []: 
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  Is the information correct? [Y/n] 
  smoser@ubuntu1:~$ sudo deluser guest
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Removing user `guest' ...
  Warning: group `guest' has no more members.
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Done.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: adduser 3.113+nmu3ubuntu4
  ProcVersionSignature: User Name 4.13.0-1007.9-azure 4.13.13
  Uname: Linux 4.13.0-1007-azure x86_64
  ApportVersion: 2.20.1-0ubuntu2.15
  Architecture: amd64
  Date: Fri Feb 16 19:30:12 2018
  PackageArchitecture: all
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: adduser
  UpgradeStatus: No upgrade log present (probably fresh install)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750851] Re: re-add cloud-initramfs-dyn-netconf to ubuntu-server

[Scott Moser]

cloud-images 20180222 do *not* have cloud-initramfs-dyn-netconf or ubuntu-meta 
at 1.411.
That is expected as it just wasnt fixed at the time of the build.

Anything newer than 20180222 should have this fixed.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1750851

Title:
  re-add cloud-initramfs-dyn-netconf to ubuntu-server

Status in ubuntu-meta package in Ubuntu:
  Fix Released

Bug description:
  I (smoser) removed cloud-initramfs-dyn-netconf from ubuntu-server meta
  package.  That package provides functionality needed by MAAS and cause bug
  1748875.  Under that bug we re-added cloud-initramfs-dyn-netconf to the
  initramfs that MAAS publishes.

  We subsequently saw failure in open-iscsi tests, which utilize that same
  function.

  My commit message to the fix of maas-images is below for informational
  purposes [1]:
[1] 
https://code.launchpad.net/~smoser/maas-images/trunk.lp1749019-re-add-cloud-intramfs-dyn-netconf/+merge/337605

  'b' is *also* used by the open-iscsi use case.  It boots with a slightly
  different form than maas images:
BOOTIF_DEFAULT=eth0 and ip=:name:BOOTIF

  Here, 'BOOTIF' will be replaced with 'eth0'.

  | Re-add cloud-initramfs-dyn-netconf. Needed by maas for BOOTIF in ip=.
  |
  | The previous commit to trunk dropped cloud-initramfs-dyn-netconf from
  | the maas image in releases newer than xenial.
  | 
  | That caused errors in MAAS. cloud-initramfs-dyn-netconf does 2 things:
  | a.) writes /run/network/dynamic-interfaces
  | this is a ENI style file with data retrived from ipconfig
  | b.) convert 'BOOTIF' string in the value of IP
  |   Example:
  | ip=foobar:BOOTIF BOOTIF=01-00-22-68-10-c1-e6
  |   will be effectively rendered as:
  | ip=foobar:eth0
  |
  | 'b' is still required by maas.
  |
  | Note: in maas v3 images, the squashfs image is re-used pristine
  | from cloud-images. Because of this, the installation into the image
  | affects initramfs creation, but does not affect the image. That is
  | correct in that this package is not needed in the image but only
  | in the initramfs.

  Related bugs:
   * bug 1748875:  Unable to deploy Bionic on bare-metals with MaaS 2.3.0

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Scott Moser]

Getting this fixed in cloud-init is tricky.
In ifupdown (/etc/network/interfaces) world, we just took the "global dns" 
entries and put them on the loopback device (lo).  Since that device would 
always be brought up, and never really brought down, it served its purpose.

That is what Ryan tried above, but it doesnt seem to work.  Even if it
*did* work, the solution would be systemd-networkd specific, and cloud-
init doesn't speak to systemd-networkd or systemd-resolved.  It speaks
to netplan.  So we would still need a way for cloud-init to tell netplan
to do this.

That leaves us with 2 not-so-great solutions in cloud-init only:
a.) blindly put global dns entries on *all* interfaces
b.) cloud-init search through the config and find the "right" interface to put 
the global dns entry on.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750884

Title:
  [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
  leads to no DNS resolution

Status in cloud-init:
  New
Status in MAAS:
  Triaged
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  When deploying Bionic, /etc/resolv.conf is not configured correctly,
  which leads to no DNS resolution. In the output below, you will see
  that netplan config is correctly to the 10.90.90.1 nameserver, but in
  resolv.conf that's a local address.

  Resolv.conf should really be configured to use the provided DNS
  server(s). That said, despite that fact, DNS resolution doesn't work
  with the local address.

  Bionic
  --

  ubuntu@node01:~$ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  enp0s25:
  match:
  macaddress: b8:ae:ed:7d:17:d2
  mtu: 1500
  nameservers:
  addresses:
  - 10.90.90.1
  search:
  - maaslab
  - maas
  set-name: enp0s25
  bridges:
  br0:
  addresses:
  - 10.90.90.3/24
  gateway4: 10.90.90.1
  interfaces:
  - enp0s25
  parameters:
  forward-delay: 15
  stp: false
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 127.0.0.53

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  ping: google.com: Temporary failure in name resolution

  [...]

  ubuntu@node01:~$ sudo vim /etc/resolv.conf
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 10.90.90.1

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  PING google.com (172.217.0.174) 56(84) bytes of data.
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=1 ttl=52 
time=4.46 ms
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=2 ttl=52 
time=4.38 ms

  =
  Xenial
  ==

  ubuntu@node05:~$ 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
  dns-nameservers 10.90.90.1
  dns-search maaslab maas

  auto enp0s25
  iface enp0s25 inet static
  address 10.90.90.162/24
  gateway 10.90.90.1
  mtu 1500
  ubuntu@node05:~$ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  nameserver 10.90.90.1
  search maaslab maas

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Scott Moser]

It seems to me that each of maas, cloud-init and netplan could do better
here.

a.) maas declares 'global' nameserver/dns info.
this is kind of silly in that such a thing doesn't really exist.
maas has the information necessary to declare the nameserver on the
device with the address that has a route to it.

b.) cloud-init is currently sticking that global definition on an
interface that doesnt have an address.  so cloud-init could do better.

c.) netplan or systemd-networkd could realize enp0s25 interface is "up"
and that it should have its nameservers used.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750884

Title:
  [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
  leads to no DNS resolution

Status in cloud-init:
  New
Status in MAAS:
  Invalid
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  When deploying Bionic, /etc/resolv.conf is not configured correctly,
  which leads to no DNS resolution. In the output below, you will see
  that netplan config is correctly to the 10.90.90.1 nameserver, but in
  resolv.conf that's a local address.

  Resolv.conf should really be configured to use the provided DNS
  server(s). That said, despite that fact, DNS resolution doesn't work
  with the local address.

  Bionic
  --

  ubuntu@node01:~$ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  enp0s25:
  match:
  macaddress: b8:ae:ed:7d:17:d2
  mtu: 1500
  nameservers:
  addresses:
  - 10.90.90.1
  search:
  - maaslab
  - maas
  set-name: enp0s25
  bridges:
  br0:
  addresses:
  - 10.90.90.3/24
  gateway4: 10.90.90.1
  interfaces:
  - enp0s25
  parameters:
  forward-delay: 15
  stp: false
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 127.0.0.53

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  ping: google.com: Temporary failure in name resolution

  [...]

  ubuntu@node01:~$ sudo vim /etc/resolv.conf
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 10.90.90.1

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  PING google.com (172.217.0.174) 56(84) bytes of data.
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=1 ttl=52 
time=4.46 ms
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=2 ttl=52 
time=4.38 ms

  =
  Xenial
  ==

  ubuntu@node05:~$ 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
  dns-nameservers 10.90.90.1
  dns-search maaslab maas

  auto enp0s25
  iface enp0s25 inet static
  address 10.90.90.162/24
  gateway 10.90.90.1
  mtu 1500
  ubuntu@node05:~$ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  nameserver 10.90.90.1
  search maaslab maas

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750851] Re: re-add cloud-initramfs-dyn-netconf to ubuntu-server

[Scott Moser]

Marked as 'fix-committed' as I pushed to the seed branch.
I need to wait for some server side things to happen before I can upload 
ubuntu-meta,

but any  ubuntu-meta > 1.411 should have this fix.


** Changed in: ubuntu-meta (Ubuntu)
   Status: New => Fix Committed

** Changed in: ubuntu-meta (Ubuntu)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1750851

Title:
  re-add cloud-initramfs-dyn-netconf to ubuntu-server

Status in ubuntu-meta package in Ubuntu:
  Fix Committed

Bug description:
  I (smoser) removed cloud-initramfs-dyn-netconf from ubuntu-server meta
  package.  That package provides functionality needed by MAAS and cause bug
  1748875.  Under that bug we re-added cloud-initramfs-dyn-netconf to the
  initramfs that MAAS publishes.

  We subsequently saw failure in open-iscsi tests, which utilize that same
  function.

  My commit message to the fix of maas-images is below for informational
  purposes [1]:
[1] 
https://code.launchpad.net/~smoser/maas-images/trunk.lp1749019-re-add-cloud-intramfs-dyn-netconf/+merge/337605

  'b' is *also* used by the open-iscsi use case.  It boots with a slightly
  different form than maas images:
BOOTIF_DEFAULT=eth0 and ip=:name:BOOTIF

  Here, 'BOOTIF' will be replaced with 'eth0'.

  | Re-add cloud-initramfs-dyn-netconf. Needed by maas for BOOTIF in ip=.
  |
  | The previous commit to trunk dropped cloud-initramfs-dyn-netconf from
  | the maas image in releases newer than xenial.
  | 
  | That caused errors in MAAS. cloud-initramfs-dyn-netconf does 2 things:
  | a.) writes /run/network/dynamic-interfaces
  | this is a ENI style file with data retrived from ipconfig
  | b.) convert 'BOOTIF' string in the value of IP
  |   Example:
  | ip=foobar:BOOTIF BOOTIF=01-00-22-68-10-c1-e6
  |   will be effectively rendered as:
  | ip=foobar:eth0
  |
  | 'b' is still required by maas.
  |
  | Note: in maas v3 images, the squashfs image is re-used pristine
  | from cloud-images. Because of this, the installation into the image
  | affects initramfs creation, but does not affect the image. That is
  | correct in that this package is not needed in the image but only
  | in the initramfs.

  Related bugs:
   * bug 1748875:  Unable to deploy Bionic on bare-metals with MaaS 2.3.0

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Scott Moser]

MAAS is sending a "global" nameserver, and a ethernet device on a bridge.
cloud-init is rendering that nameserver onto the ethernet device rather
than on the bridge or as a "global" entry.


$ cat my.yaml
network:
  config: [
   {"id": "enp0s25", "type": "physical", "name": "enp0s25",
"mac_address": "b8:ae:ed:7d:16:d0", "mtu": 1500,
"subnets": [{"type": "manual"}]},
   {"id": "br0", "type": "bridge", "name": "br0",
"mac_address": "b8:ae:ed:7d:16:d0", "bridge_interfaces": ["enp0s25"],
"mtu": 1500, "params": {'bridge_fd': 15, 'bridge_stp': 0},
"subnets": [
   {"type": "static", "address": "10.90.90.4/24", "dns_nameservers": [],
"gateway": "10.90.90.1"}
 ]},
   {"type": "nameserver", "address": ["10.90.90.1"],
"search": ["maaslab", "maas"]},
  ]
  version: 1

$ PYTHONPATH=$PWD python3 ./tools/net-convert.py \
   --network-data=my.yaml  --kind=yaml --output-kind=netplan --directory=out.d

$ cat out.d/etc/netplan/50-cloud-init.yaml

network:
version: 2
ethernets:
enp0s25:
match:
macaddress: b8:ae:ed:7d:16:d0
mtu: 1500
nameservers:
addresses:
- 10.90.90.1
search:
- maaslab
- maas
set-name: enp0s25
bridges:
br0:
addresses:
- 10.90.90.4/24
gateway4: 10.90.90.1
interfaces:
- enp0s25
parameters:
forward-delay: 15
stp: false

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750884

Title:
  [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
  leads to no DNS resolution

Status in cloud-init:
  New
Status in MAAS:
  Invalid
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  When deploying Bionic, /etc/resolv.conf is not configured correctly,
  which leads to no DNS resolution. In the output below, you will see
  that netplan config is correctly to the 10.90.90.1 nameserver, but in
  resolv.conf that's a local address.

  Resolv.conf should really be configured to use the provided DNS
  server(s). That said, despite that fact, DNS resolution doesn't work
  with the local address.

  Bionic
  --

  ubuntu@node01:~$ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  enp0s25:
  match:
  macaddress: b8:ae:ed:7d:17:d2
  mtu: 1500
  nameservers:
  addresses:
  - 10.90.90.1
  search:
  - maaslab
  - maas
  set-name: enp0s25
  bridges:
  br0:
  addresses:
  - 10.90.90.3/24
  gateway4: 10.90.90.1
  interfaces:
  - enp0s25
  parameters:
  forward-delay: 15
  stp: false
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 127.0.0.53

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  ping: google.com: Temporary failure in name resolution

  [...]

  ubuntu@node01:~$ sudo vim /etc/resolv.conf
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 10.90.90.1

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  PING google.com (172.217.0.174) 56(84) bytes of data.
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=1 ttl=52 
time=4.46 ms
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=2 ttl=52 
time=4.38 ms

  =
  Xenial
  ==

  ubuntu@node05:~$ 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
  dns-nameservers 10.90.90.1
  dns-search maaslab maas

  auto enp0s25
  iface 

[Touch-packages] [Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Scott Moser]

Hi,

cloud-init has never updated resolv.conf directly.
/etc/resolv.conf in 16.04 is managed via resolvconf through 
/etc/network/interfaces.
/etc/resolv.conf in 18.04 is managed via systemd-resolve (netplan -> 
systemd-networkd -> systemd-resolve).

Can you provide the content of:
   systemd-resolve --status --no-pager

And does this happen in the ephemeral environment, the installed
environment, or both?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750884

Title:
  [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
  leads to no DNS resolution

Status in cloud-init:
  New
Status in MAAS:
  Invalid
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  When deploying Bionic, /etc/resolv.conf is not configured correctly,
  which leads to no DNS resolution. In the output below, you will see
  that netplan config is correctly to the 10.90.90.1 nameserver, but in
  resolv.conf that's a local address.

  Resolv.conf should really be configured to use the provided DNS
  server(s). That said, despite that fact, DNS resolution doesn't work
  with the local address.

  Bionic
  --

  ubuntu@node01:~$ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  enp0s25:
  match:
  macaddress: b8:ae:ed:7d:17:d2
  mtu: 1500
  nameservers:
  addresses:
  - 10.90.90.1
  search:
  - maaslab
  - maas
  set-name: enp0s25
  bridges:
  br0:
  addresses:
  - 10.90.90.3/24
  gateway4: 10.90.90.1
  interfaces:
  - enp0s25
  parameters:
  forward-delay: 15
  stp: false
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 127.0.0.53

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  ping: google.com: Temporary failure in name resolution

  [...]

  ubuntu@node01:~$ sudo vim /etc/resolv.conf
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 10.90.90.1

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  PING google.com (172.217.0.174) 56(84) bytes of data.
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=1 ttl=52 
time=4.46 ms
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=2 ttl=52 
time=4.38 ms

  =
  Xenial
  ==

  ubuntu@node05:~$ 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
  dns-nameservers 10.90.90.1
  dns-search maaslab maas

  auto enp0s25
  iface enp0s25 inet static
  address 10.90.90.162/24
  gateway 10.90.90.1
  mtu 1500
  ubuntu@node05:~$ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  nameserver 10.90.90.1
  search maaslab maas

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750851] [NEW] re-add cloud-initramfs-dyn-netconf to ubuntu-server

[Scott Moser]

Public bug reported:

I (smoser) removed cloud-initramfs-dyn-netconf from ubuntu-server meta
package.  That package provides functionality needed by MAAS and cause bug
1748875.  Under that bug we re-added cloud-initramfs-dyn-netconf to the
initramfs that MAAS publishes.

We subsequently saw failure in open-iscsi tests, which utilize that same
function.

My commit message to the fix of maas-images is below for informational
purposes [1]:
  [1] 
https://code.launchpad.net/~smoser/maas-images/trunk.lp1749019-re-add-cloud-intramfs-dyn-netconf/+merge/337605

'b' is *also* used by the open-iscsi use case.  It boots with a slightly
different form than maas images:
  BOOTIF_DEFAULT=eth0 and ip=:name:BOOTIF

Here, 'BOOTIF' will be replaced with 'eth0'.

| Re-add cloud-initramfs-dyn-netconf. Needed by maas for BOOTIF in ip=.
|
| The previous commit to trunk dropped cloud-initramfs-dyn-netconf from
| the maas image in releases newer than xenial.
| 
| That caused errors in MAAS. cloud-initramfs-dyn-netconf does 2 things:
| a.) writes /run/network/dynamic-interfaces
| this is a ENI style file with data retrived from ipconfig
| b.) convert 'BOOTIF' string in the value of IP
|   Example:
| ip=foobar:BOOTIF BOOTIF=01-00-22-68-10-c1-e6
|   will be effectively rendered as:
| ip=foobar:eth0
|
| 'b' is still required by maas.
|
| Note: in maas v3 images, the squashfs image is re-used pristine
| from cloud-images. Because of this, the installation into the image
| affects initramfs creation, but does not affect the image. That is
| correct in that this package is not needed in the image but only
| in the initramfs.

Related bugs:
 * bug 1748875:  Unable to deploy Bionic on bare-metals with MaaS 2.3.0

** Affects: ubuntu-meta (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1750851

Title:
  re-add cloud-initramfs-dyn-netconf to ubuntu-server

Status in ubuntu-meta package in Ubuntu:
  New

Bug description:
  I (smoser) removed cloud-initramfs-dyn-netconf from ubuntu-server meta
  package.  That package provides functionality needed by MAAS and cause bug
  1748875.  Under that bug we re-added cloud-initramfs-dyn-netconf to the
  initramfs that MAAS publishes.

  We subsequently saw failure in open-iscsi tests, which utilize that same
  function.

  My commit message to the fix of maas-images is below for informational
  purposes [1]:
[1] 
https://code.launchpad.net/~smoser/maas-images/trunk.lp1749019-re-add-cloud-intramfs-dyn-netconf/+merge/337605

  'b' is *also* used by the open-iscsi use case.  It boots with a slightly
  different form than maas images:
BOOTIF_DEFAULT=eth0 and ip=:name:BOOTIF

  Here, 'BOOTIF' will be replaced with 'eth0'.

  | Re-add cloud-initramfs-dyn-netconf. Needed by maas for BOOTIF in ip=.
  |
  | The previous commit to trunk dropped cloud-initramfs-dyn-netconf from
  | the maas image in releases newer than xenial.
  | 
  | That caused errors in MAAS. cloud-initramfs-dyn-netconf does 2 things:
  | a.) writes /run/network/dynamic-interfaces
  | this is a ENI style file with data retrived from ipconfig
  | b.) convert 'BOOTIF' string in the value of IP
  |   Example:
  | ip=foobar:BOOTIF BOOTIF=01-00-22-68-10-c1-e6
  |   will be effectively rendered as:
  | ip=foobar:eth0
  |
  | 'b' is still required by maas.
  |
  | Note: in maas v3 images, the squashfs image is re-used pristine
  | from cloud-images. Because of this, the installation into the image
  | affects initramfs creation, but does not affect the image. That is
  | correct in that this package is not needed in the image but only
  | in the initramfs.

  Related bugs:
   * bug 1748875:  Unable to deploy Bionic on bare-metals with MaaS 2.3.0

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 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 Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750031] [NEW] scary/unexpected output in adduser and deluser

[Scott Moser]

Public bug reported:

adduser and deluser are now printing to stderr 'sent invalidate(passwd)' and
'sent invalidate(group)'.

These are confusing at best and new in bionic.
See below. They do not seem harmful, but not wonderful.


smoser@ubuntu1:~$ sudo adduser guest
Adding user `guest' ...
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
Adding new group `guest' (1001) ...
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
Adding new user `guest' (1001) with group `guest' ...
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
The home directory `/home/guest' already exists.  Not copying from `/etc/skel'.
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
Changing the user information for guest
Enter the new value, or press ENTER for the default
Full Name []: Foo Bar
Room Number []: 
Work Phone []: 
Home Phone []: 
Other []: 
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
Is the information correct? [Y/n] 
smoser@ubuntu1:~$ sudo deluser guest
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
Removing user `guest' ...
Warning: group `guest' has no more members.
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
Done.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: adduser 3.113+nmu3ubuntu4
ProcVersionSignature: User Name 4.13.0-1007.9-azure 4.13.13
Uname: Linux 4.13.0-1007-azure x86_64
ApportVersion: 2.20.1-0ubuntu2.15
Architecture: amd64
Date: Fri Feb 16 19:30:12 2018
PackageArchitecture: all
ProcEnviron:
 TERM=screen
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: adduser
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: adduser (Ubuntu)
 Importance: Undecided
 Status: Confirmed


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

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to adduser in Ubuntu.
https://bugs.launchpad.net/bugs/1750031

Title:
  scary/unexpected output in adduser and deluser

Status in adduser package in Ubuntu:
  Confirmed

Bug description:
  adduser and deluser are now printing to stderr 'sent invalidate(passwd)' and
  'sent invalidate(group)'.

  These are confusing at best and new in bionic.
  See below. They do not seem harmful, but not wonderful.

  
  smoser@ubuntu1:~$ sudo adduser guest
  Adding user `guest' ...
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Adding new group `guest' (1001) ...
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Adding new user `guest' (1001) with group `guest' ...
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  The home directory `/home/guest' already exists.  Not copying from 
`/etc/skel'.
  Enter new UNIX password: 
  Retype new UNIX password: 
  passwd: password updated successfully
  Changing the user information for guest
  Enter the new value, or press ENTER for the default
  Full Name []: Foo Bar
  Room Number []: 
  Work Phone []: 
  Home Phone []: 
  Other []: 
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  Is the information correct? [Y/n] 
  smoser@ubuntu1:~$ sudo deluser guest
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Removing user `guest' ...
  Warning: group `guest' has no more members.
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  sent invalidate(passwd) request, exiting
  sent invalidate(group) request, exiting
  Done.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: adduser 3.113+nmu3ubuntu4
  ProcVersionSignature: User Name 4.13.0-1007.9-azure 4.13.13
  Uname: Linux 

[Touch-packages] [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(_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(_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 Technology Co., 

[Touch-packages] [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 Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp