[Touch-packages] [Bug 1970402] Re: Initrd out of memory error after upgrade to 22.04

[Andres Rodriguez Reina]

*** This bug is a duplicate of bug 1842320 ***
https://bugs.launchpad.net/bugs/1842320

In case it helps: I just want to add that I had similar issues due to
debug symbols present in my kernel modules (15x initrd size).

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

Title:
  Initrd out of memory error after upgrade to 22.04

Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in initramfs-tools source package in Jammy:
  Confirmed

Bug description:
  After upgrading to 22.04 system is unbootable because of "out of memory" 
error when loading initial ramdisk. I was able to fix it by editing cat 
/etc/initramfs-tools/initramfs.conf
  and changing configuration to:
  MODULES=dep
  COMPRESS=xz
  RUNSIZE=15%

  Not sure which one helped, but I can test it if needed.

  System information:
  Description:Ubuntu 22.04 LTS
  Release:22.04

  initramfs-tools:
Installed: 0.140ubuntu13
Candidate: 0.140ubuntu13
Version table:
   *** 0.140ubuntu13 500
  500 http://pl.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
  500 http://pl.archive.ubuntu.com/ubuntu jammy/main i386 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1970402/+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 1573982] Re: LVM boot problem - volumes not activated after upgrade to Xenial

[Andres Rodriguez]

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

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

Title:
  LVM boot problem - volumes not activated after upgrade to Xenial

Status in curtin:
  Incomplete
Status in MAAS:
  Invalid
Status in lvm2 package in Ubuntu:
  Confirmed

Bug description:
  Soon after upgrade to Xenial (from 15.10) the boot process got broken.
  I'm using LVM for /root swap and other partitions.

  ===
  The current behaviour is:

  When I boot short after the Grub login screen I'm getting log messages
  like:

  ---
  Scanning for Btrfs filesystems
  resume: Could not state the resume device file: '/dev/mapper/VolGroup'
  Please type in the full path...
  ---

  Then I press ENTER, for a few minutes some errors about floppy device
  access are raised (for some reason it tries to scan fd0 when floppy
  drive is empty). And then:

  ---
  Gave up waiting for root device. Common problems: ...
  ...
  ALERT! UUID=xxx-xxx does not exist.
  Dropping to a shell.
  ---

  From the BusyBox shell I managed to recover the boot by issuing "lvm
  vgchange -ay", then exit and then boot continues fine (all LVM file
  systems are successfully mounted).

  ===
  One workaround so far is creating 
/etc/initramfs-tools/scripts/local-top/lvm2-manual script doing "lvm vgchange 
-ay". But I'm looking for cleaner solution.

  Boot used to work fine with 15.10. Actually the first boot after
  upgrading to Xenial actually worked OK too, I'm not sure what might
  changed meanwhile (I've been fixing some packages installation since
  mysql server upgrade has failed).

  ===
  # lsb_release -rd
  Description:  Ubuntu 16.04 LTS
  Release:  16.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1573982/+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 1752737] Re: [2.3.0-6434] mDNS observer problems

[Andres Rodriguez]

In MAAS we have provided a work around in LP: #1773698

** Changed in: maas
Milestone: 2.5.0beta1 => 2.5.0beta2

** No longer affects: maas

** No longer affects: maas/2.4

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

Title:
  [2.3.0-6434] mDNS observer problems

Status in Avahi:
  Unknown
Status in avahi package in Ubuntu:
  Confirmed

Bug description:
  I see avahi-browser choking on non-utf8 characters in my rackd.log:

  ==> rackd.log <==
  2018-02-28 16:54:33 provisioningserver.utils.services: [info] mDNS 
observation process started.
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
Traceback (most recent call last):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 87, in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 83, in main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
run()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 52, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
from provisioningserver.__main__ import main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/__main__.py", line 55, 
in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
91, in __call__
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
self.execute(argv)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
86, in execute
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
args.handler.run(args)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
221, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
_observe_mdns(reader, output, args.verbose)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
145, in _observe_mdns
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in observer(events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
161, in _observe_resolver_found
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in filter(_p_resolver_found, events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
125, in _extract_mdns_events
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in map(parse_avahi_event, lines):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3.5/codecs.py", line 321, in decode
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
(result, consumed) = self._buffer_decode(data, self.errors, final)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc8 in position 240: 
invalid continuation byte
  2018-02-28 16:54:36 provisioningserver.utils.services: [critical] mDNS 
observation process failed.

  Traceback (most recent call last):
  Failure: twisted.internet.error.ProcessTerminated: A process has ended with a 
probable error condition: process ended with exit code 1.

  ==> regiond.log <==
  2018-02-28 16:54:50 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)
  2018-02-28 16:55:20 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)

  ==> maas.log <==
  Feb 28 16:53:52 MAAS-RC01 maas.interface: [info] ens33 (physical) on 
MAAS-RC01: New MAC, IP binding observed: 08:eb:74:ca:d3:6f, 192.168.1.82

  Similar traceback when running from command line:

  maasuser@MAAS-RC01:~$ maas-rack observe-mdns
  {"hostname": "Apple-TV", "interface": "ens33", "address": "192.168.1.81"}
  Got SIGTERM, quitting.
  Traceback (most recent call last):
File 

[Touch-packages] [Bug 1752737] Re: [2.3.0-6434] mDNS observer problems

[Andres Rodriguez]

** Changed in: maas
Milestone: 2.5.0 => 2.5.0beta1

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

Title:
  [2.3.0-6434] mDNS observer problems

Status in Avahi:
  Unknown
Status in MAAS:
  Triaged
Status in MAAS 2.4 series:
  Triaged
Status in avahi package in Ubuntu:
  Confirmed

Bug description:
  I see avahi-browser choking on non-utf8 characters in my rackd.log:

  ==> rackd.log <==
  2018-02-28 16:54:33 provisioningserver.utils.services: [info] mDNS 
observation process started.
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
Traceback (most recent call last):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 87, in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 83, in main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
run()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 52, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
from provisioningserver.__main__ import main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/__main__.py", line 55, 
in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
91, in __call__
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
self.execute(argv)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
86, in execute
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
args.handler.run(args)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
221, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
_observe_mdns(reader, output, args.verbose)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
145, in _observe_mdns
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in observer(events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
161, in _observe_resolver_found
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in filter(_p_resolver_found, events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
125, in _extract_mdns_events
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in map(parse_avahi_event, lines):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3.5/codecs.py", line 321, in decode
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
(result, consumed) = self._buffer_decode(data, self.errors, final)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc8 in position 240: 
invalid continuation byte
  2018-02-28 16:54:36 provisioningserver.utils.services: [critical] mDNS 
observation process failed.

  Traceback (most recent call last):
  Failure: twisted.internet.error.ProcessTerminated: A process has ended with a 
probable error condition: process ended with exit code 1.

  ==> regiond.log <==
  2018-02-28 16:54:50 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)
  2018-02-28 16:55:20 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)

  ==> maas.log <==
  Feb 28 16:53:52 MAAS-RC01 maas.interface: [info] ens33 (physical) on 
MAAS-RC01: New MAC, IP binding observed: 08:eb:74:ca:d3:6f, 192.168.1.82

  Similar traceback when running from command line:

  maasuser@MAAS-RC01:~$ maas-rack observe-mdns
  {"hostname": "Apple-TV", "interface": "ens33", "address": "192.168.1.81"}
  Got SIGTERM, quitting.
  Traceback (most recent call last):
File "/usr/sbin/maas-rack", line 87, in 
  main()
File 

[Touch-packages] [Bug 1752737] Re: [2.3.0-6434] mDNS observer problems

[Andres Rodriguez]

** Changed in: maas/2.4
Milestone: 2.4.2 => 2.4.3

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

Title:
  [2.3.0-6434] mDNS observer problems

Status in Avahi:
  Unknown
Status in MAAS:
  Triaged
Status in MAAS 2.4 series:
  Triaged
Status in avahi package in Ubuntu:
  Confirmed

Bug description:
  I see avahi-browser choking on non-utf8 characters in my rackd.log:

  ==> rackd.log <==
  2018-02-28 16:54:33 provisioningserver.utils.services: [info] mDNS 
observation process started.
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
Traceback (most recent call last):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 87, in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 83, in main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
run()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 52, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
from provisioningserver.__main__ import main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/__main__.py", line 55, 
in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
91, in __call__
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
self.execute(argv)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
86, in execute
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
args.handler.run(args)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
221, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
_observe_mdns(reader, output, args.verbose)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
145, in _observe_mdns
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in observer(events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
161, in _observe_resolver_found
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in filter(_p_resolver_found, events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
125, in _extract_mdns_events
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in map(parse_avahi_event, lines):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3.5/codecs.py", line 321, in decode
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
(result, consumed) = self._buffer_decode(data, self.errors, final)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc8 in position 240: 
invalid continuation byte
  2018-02-28 16:54:36 provisioningserver.utils.services: [critical] mDNS 
observation process failed.

  Traceback (most recent call last):
  Failure: twisted.internet.error.ProcessTerminated: A process has ended with a 
probable error condition: process ended with exit code 1.

  ==> regiond.log <==
  2018-02-28 16:54:50 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)
  2018-02-28 16:55:20 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)

  ==> maas.log <==
  Feb 28 16:53:52 MAAS-RC01 maas.interface: [info] ens33 (physical) on 
MAAS-RC01: New MAC, IP binding observed: 08:eb:74:ca:d3:6f, 192.168.1.82

  Similar traceback when running from command line:

  maasuser@MAAS-RC01:~$ maas-rack observe-mdns
  {"hostname": "Apple-TV", "interface": "ens33", "address": "192.168.1.81"}
  Got SIGTERM, quitting.
  Traceback (most recent call last):
File "/usr/sbin/maas-rack", line 87, in 
  main()
File 

[Touch-packages] [Bug 1752737] Re: [2.3.0-6434] mDNS observer problems

[Andres Rodriguez]

** Changed in: maas/2.4
Milestone: 2.4.1 => 2.4.2

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

Title:
  [2.3.0-6434] mDNS observer problems

Status in Avahi:
  Unknown
Status in MAAS:
  Triaged
Status in MAAS 2.4 series:
  Triaged
Status in avahi package in Ubuntu:
  Confirmed

Bug description:
  I see avahi-browser choking on non-utf8 characters in my rackd.log:

  ==> rackd.log <==
  2018-02-28 16:54:33 provisioningserver.utils.services: [info] mDNS 
observation process started.
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
Traceback (most recent call last):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 87, in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 83, in main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
run()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 52, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
from provisioningserver.__main__ import main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/__main__.py", line 55, 
in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
91, in __call__
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
self.execute(argv)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
86, in execute
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
args.handler.run(args)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
221, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
_observe_mdns(reader, output, args.verbose)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
145, in _observe_mdns
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in observer(events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
161, in _observe_resolver_found
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in filter(_p_resolver_found, events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
125, in _extract_mdns_events
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in map(parse_avahi_event, lines):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3.5/codecs.py", line 321, in decode
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
(result, consumed) = self._buffer_decode(data, self.errors, final)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc8 in position 240: 
invalid continuation byte
  2018-02-28 16:54:36 provisioningserver.utils.services: [critical] mDNS 
observation process failed.

  Traceback (most recent call last):
  Failure: twisted.internet.error.ProcessTerminated: A process has ended with a 
probable error condition: process ended with exit code 1.

  ==> regiond.log <==
  2018-02-28 16:54:50 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)
  2018-02-28 16:55:20 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)

  ==> maas.log <==
  Feb 28 16:53:52 MAAS-RC01 maas.interface: [info] ens33 (physical) on 
MAAS-RC01: New MAC, IP binding observed: 08:eb:74:ca:d3:6f, 192.168.1.82

  Similar traceback when running from command line:

  maasuser@MAAS-RC01:~$ maas-rack observe-mdns
  {"hostname": "Apple-TV", "interface": "ens33", "address": "192.168.1.81"}
  Got SIGTERM, quitting.
  Traceback (most recent call last):
File "/usr/sbin/maas-rack", line 87, in 
  main()
File 

[Touch-packages] [Bug 1752737] Re: [2.3.0-6434] mDNS observer problems

[Andres Rodriguez]

** Also affects: maas/2.4
   Importance: Undecided
   Status: New

** Changed in: maas
Milestone: 2.4.x => 2.5.0

** Changed in: maas/2.4
Milestone: None => 2.4.1

** Changed in: maas/2.4
   Status: New => Triaged

** Changed in: maas/2.4
   Importance: Undecided => High

** Changed in: maas
   Importance: Medium => High

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

Title:
  [2.3.0-6434] mDNS observer problems

Status in Avahi:
  Unknown
Status in MAAS:
  Triaged
Status in MAAS 2.4 series:
  Triaged
Status in avahi package in Ubuntu:
  Confirmed

Bug description:
  I see avahi-browser choking on non-utf8 characters in my rackd.log:

  ==> rackd.log <==
  2018-02-28 16:54:33 provisioningserver.utils.services: [info] mDNS 
observation process started.
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
Traceback (most recent call last):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 87, in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 83, in main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
run()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 52, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
from provisioningserver.__main__ import main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/__main__.py", line 55, 
in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
91, in __call__
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
self.execute(argv)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
86, in execute
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
args.handler.run(args)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
221, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
_observe_mdns(reader, output, args.verbose)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
145, in _observe_mdns
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in observer(events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
161, in _observe_resolver_found
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in filter(_p_resolver_found, events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
125, in _extract_mdns_events
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in map(parse_avahi_event, lines):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3.5/codecs.py", line 321, in decode
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
(result, consumed) = self._buffer_decode(data, self.errors, final)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc8 in position 240: 
invalid continuation byte
  2018-02-28 16:54:36 provisioningserver.utils.services: [critical] mDNS 
observation process failed.

  Traceback (most recent call last):
  Failure: twisted.internet.error.ProcessTerminated: A process has ended with a 
probable error condition: process ended with exit code 1.

  ==> regiond.log <==
  2018-02-28 16:54:50 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)
  2018-02-28 16:55:20 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)

  ==> maas.log <==
  Feb 28 16:53:52 MAAS-RC01 maas.interface: [info] ens33 (physical) on 
MAAS-RC01: New MAC, IP binding observed: 08:eb:74:ca:d3:6f, 192.168.1.82

  Similar traceback when running from 

[Touch-packages] [Bug 1752737] Re: [2.3.0-6434] mDNS observer problems

[Andres Rodriguez]

** Changed in: maas
Milestone: 2.4.0beta4 => 2.4.x

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

Title:
  [2.3.0-6434] mDNS observer problems

Status in Avahi:
  Unknown
Status in MAAS:
  Triaged
Status in avahi package in Ubuntu:
  Confirmed

Bug description:
  I see avahi-browser choking on non-utf8 characters in my rackd.log:

  ==> rackd.log <==
  2018-02-28 16:54:33 provisioningserver.utils.services: [info] mDNS 
observation process started.
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
Traceback (most recent call last):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 87, in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 83, in main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
run()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 52, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
from provisioningserver.__main__ import main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/__main__.py", line 55, 
in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
91, in __call__
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
self.execute(argv)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
86, in execute
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
args.handler.run(args)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
221, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
_observe_mdns(reader, output, args.verbose)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
145, in _observe_mdns
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in observer(events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
161, in _observe_resolver_found
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in filter(_p_resolver_found, events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
125, in _extract_mdns_events
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in map(parse_avahi_event, lines):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3.5/codecs.py", line 321, in decode
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
(result, consumed) = self._buffer_decode(data, self.errors, final)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc8 in position 240: 
invalid continuation byte
  2018-02-28 16:54:36 provisioningserver.utils.services: [critical] mDNS 
observation process failed.

  Traceback (most recent call last):
  Failure: twisted.internet.error.ProcessTerminated: A process has ended with a 
probable error condition: process ended with exit code 1.

  ==> regiond.log <==
  2018-02-28 16:54:50 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)
  2018-02-28 16:55:20 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)

  ==> maas.log <==
  Feb 28 16:53:52 MAAS-RC01 maas.interface: [info] ens33 (physical) on 
MAAS-RC01: New MAC, IP binding observed: 08:eb:74:ca:d3:6f, 192.168.1.82

  Similar traceback when running from command line:

  maasuser@MAAS-RC01:~$ maas-rack observe-mdns
  {"hostname": "Apple-TV", "interface": "ens33", "address": "192.168.1.81"}
  Got SIGTERM, quitting.
  Traceback (most recent call last):
File "/usr/sbin/maas-rack", line 87, in 
  main()
File "/usr/sbin/maas-rack", line 83, in main
  run()

[Touch-packages] [Bug 1752737] Re: [2.3.0-6434] mDNS observer problems

[Andres Rodriguez]

** Changed in: maas
Milestone: 2.4.0beta3 => 2.4.0beta4

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

Title:
  [2.3.0-6434] mDNS observer problems

Status in Avahi:
  Unknown
Status in MAAS:
  Triaged
Status in avahi package in Ubuntu:
  Confirmed

Bug description:
  I see avahi-browser choking on non-utf8 characters in my rackd.log:

  ==> rackd.log <==
  2018-02-28 16:54:33 provisioningserver.utils.services: [info] mDNS 
observation process started.
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
Traceback (most recent call last):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 87, in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 83, in main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
run()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 52, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
from provisioningserver.__main__ import main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/__main__.py", line 55, 
in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
91, in __call__
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
self.execute(argv)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
86, in execute
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
args.handler.run(args)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
221, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
_observe_mdns(reader, output, args.verbose)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
145, in _observe_mdns
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in observer(events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
161, in _observe_resolver_found
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in filter(_p_resolver_found, events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
125, in _extract_mdns_events
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in map(parse_avahi_event, lines):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3.5/codecs.py", line 321, in decode
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
(result, consumed) = self._buffer_decode(data, self.errors, final)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc8 in position 240: 
invalid continuation byte
  2018-02-28 16:54:36 provisioningserver.utils.services: [critical] mDNS 
observation process failed.

  Traceback (most recent call last):
  Failure: twisted.internet.error.ProcessTerminated: A process has ended with a 
probable error condition: process ended with exit code 1.

  ==> regiond.log <==
  2018-02-28 16:54:50 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)
  2018-02-28 16:55:20 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)

  ==> maas.log <==
  Feb 28 16:53:52 MAAS-RC01 maas.interface: [info] ens33 (physical) on 
MAAS-RC01: New MAC, IP binding observed: 08:eb:74:ca:d3:6f, 192.168.1.82

  Similar traceback when running from command line:

  maasuser@MAAS-RC01:~$ maas-rack observe-mdns
  {"hostname": "Apple-TV", "interface": "ens33", "address": "192.168.1.81"}
  Got SIGTERM, quitting.
  Traceback (most recent call last):
File "/usr/sbin/maas-rack", line 87, in 
  main()
File "/usr/sbin/maas-rack", line 83, in main
  

Re: [Touch-packages] [Bug 1763534] Re: ifconfig -s (or -a -s) only outputs 8 characters of the interface name, when interfaces are 10+ characters.

[Andres Rodriguez]

Maas is being fixed to use “ip” instead of ifconfig. The reason why it
wasn’t noticed before is because MAAS does only use LTS releases for
commissioning. Since we only run ifconfig -a during commissioning, then the
regression wasn’t found till recently.

On Thu, Apr 12, 2018 at 9:10 PM Steve Langasek <steve.langa...@canonical.com>
wrote:

> OTOH, it's also been this way since zesty and no one else seems to have
> cared until now that it regressed.  I think the effort is better spent
> fixing maas to not depend on deprecated tools.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1763534
>
> Title:
>   ifconfig -s (or -a -s) only outputs 8 characters of the interface
>   name, when interfaces are 10+ characters.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/1763534/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: distribution=ubuntu; sourcepackage=net-tools;
> component=main; status=Confirmed; importance=Critical;
> assignee=canonical-foundations;
> Launchpad-Bug: distribution=ubuntu; distroseries=bionic;
> sourcepackage=net-tools; component=main; status=Confirmed;
> importance=Critical; assignee=canonical-foundations;
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: andreserl janitor manjo vorlon
> Launchpad-Bug-Reporter: Andres Rodriguez (andreserl)
> Launchpad-Bug-Modifier: Steve Langasek (vorlon)
> Launchpad-Message-Rationale: Subscriber
> Launchpad-Message-For: andreserl
>
-- 
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
MSc. Telecom & Networking
Systems Engineer

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

Title:
  ifconfig -s (or -a -s) only outputs 8 characters of the interface
  name, when interfaces are 10+ characters.

Status in net-tools package in Ubuntu:
  Confirmed
Status in net-tools source package in Bionic:
  Confirmed

Bug description:
  When executing ifconfig, it outputs the whole 10 characters of the
  interface name. However, when using ifconfig -s (or ifconfig -a -s) it
  doesn't include all the name of the interface (or 10+ characters).
  Instead, it outputs only 8 characters of the interface.

  ubuntu@dradis:~$ ifconfig -a
  enP2p1s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
  inet 10.245.71.108  netmask 255.255.248.0  broadcast 10.245.71.255
  inet6 fe80::ae1f:6bff:fe09:c052  prefixlen 64  scopeid 0x20
  ether ac:1f:6b:09:c0:52  txqueuelen 1000  (Ethernet)
  RX packets 154570  bytes 229998298 (229.9 MB)
  RX errors 0  dropped 0  overruns 0  frame 0
  TX packets 61080  bytes 6131460 (6.1 MB)
  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

  enP2p1s0f1: flags=4098<BROADCAST,MULTICAST>  mtu 1500
  ether ac:1f:6b:09:c0:53  txqueuelen 1000  (Ethernet)
  RX packets 0  bytes 0 (0.0 B)
  RX errors 0  dropped 0  overruns 0  frame 0
  TX packets 0  bytes 0 (0.0 B)
  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

  
  ubuntu@dradis:~$ ifconfig -a -s
  Iface  MTURX-OK RX-ERR RX-DRP RX-OVRTX-OK TX-ERR TX-DRP TX-OVR Flg
  enP2p1s0  1500   154607  0  0 0 61101  0  0  0 
BMRU
  enP2p1s0  15000  0  0 0 0  0  0  0 BM

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/1763534/+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 1763534] [NEW] ifconfig -s (or -a -s) only outputs 8 characters of the interface name, when interfaces are 10+ characters.

[Andres Rodriguez]

Public bug reported:

When executing ifconfig, it outputs the whole 10 characters of the
interface name. However, when using ifconfig -s (or ifconfig -a -s) it
doesn't include all the name of the interface (or 10+ characters).
Instead, it outputs only 8 characters of the interface.

ubuntu@dradis:~$ ifconfig -a
enP2p1s0f0: flags=4163  mtu 1500
inet 10.245.71.108  netmask 255.255.248.0  broadcast 10.245.71.255
inet6 fe80::ae1f:6bff:fe09:c052  prefixlen 64  scopeid 0x20
ether ac:1f:6b:09:c0:52  txqueuelen 1000  (Ethernet)
RX packets 154570  bytes 229998298 (229.9 MB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 61080  bytes 6131460 (6.1 MB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enP2p1s0f1: flags=4098  mtu 1500
ether ac:1f:6b:09:c0:53  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


ubuntu@dradis:~$ ifconfig -a -s
Iface  MTURX-OK RX-ERR RX-DRP RX-OVRTX-OK TX-ERR TX-DRP TX-OVR Flg
enP2p1s0  1500   154607  0  0 0 61101  0  0  0 BMRU
enP2p1s0  15000  0  0 0 0  0  0  0 BM

** Affects: net-tools (Ubuntu)
 Importance: Critical
 Status: New

** Affects: net-tools (Ubuntu Bionic)
 Importance: Critical
 Status: New

** Description changed:

  When executing ifconfig, it outputs the whole 10 characters of the
  interface name. However, when using ifconfig -s (or ifconfig -a -s) it
  doesn't include all the name of the interface (or 10+ characters).
  Instead, it outputs only 8 characters of the interface.
  
- ubuntu@dradis:~$ ifconfig
+ ubuntu@dradis:~$ ifconfig -a
  enP2p1s0f0: flags=4163  mtu 1500
  inet 10.245.71.108  netmask 255.255.248.0  broadcast 10.245.71.255
  inet6 fe80::ae1f:6bff:fe09:c052  prefixlen 64  scopeid 0x20
  ether ac:1f:6b:09:c0:52  txqueuelen 1000  (Ethernet)
- RX packets 154396  bytes 229982516 (229.9 MB)
+ RX packets 154570  bytes 229998298 (229.9 MB)
  RX errors 0  dropped 0  overruns 0  frame 0
- TX packets 60547  bytes 6062897 (6.0 MB)
+ TX packets 61080  bytes 6131460 (6.1 MB)
  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
  
- ubuntu@dradis:~$ ifconfig -s
+ enP2p1s0f1: flags=4098  mtu 1500
+ ether ac:1f:6b:09:c0:53  txqueuelen 1000  (Ethernet)
+ RX packets 0  bytes 0 (0.0 B)
+ RX errors 0  dropped 0  overruns 0  frame 0
+ TX packets 0  bytes 0 (0.0 B)
+ TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
+ 
+ 
+ ubuntu@dradis:~$ ifconfig -a -s
  Iface  MTURX-OK RX-ERR RX-DRP RX-OVRTX-OK TX-ERR TX-DRP TX-OVR Flg
- enP2p1s0  1500   154538  0  0 0 61063  0  0  0 
BMRU
- lo   65536  118  0  0 0   118  0  0  0 LRU
+ enP2p1s0  1500   154607  0  0 0 61101  0  0  0 
BMRU
+ enP2p1s0  15000  0  0 0 0  0  0  0 BM

** Changed in: net-tools (Ubuntu)
   Importance: Undecided => Critical

** Summary changed:

- ifconfig -s (or -a -s) doesn't output the full name of the interface
+ ifconfig -s (or -a -s) only outputs 8 characters of the interface name, when 
interfaces are 10+ characters.

** Also affects: net-tools (Ubuntu Bionic)
   Importance: Critical
   Status: New

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

Title:
  ifconfig -s (or -a -s) only outputs 8 characters of the interface
  name, when interfaces are 10+ characters.

Status in net-tools package in Ubuntu:
  New
Status in net-tools source package in Bionic:
  New

Bug description:
  When executing ifconfig, it outputs the whole 10 characters of the
  interface name. However, when using ifconfig -s (or ifconfig -a -s) it
  doesn't include all the name of the interface (or 10+ characters).
  Instead, it outputs only 8 characters of the interface.

  ubuntu@dradis:~$ ifconfig -a
  enP2p1s0f0: flags=4163  mtu 1500
  inet 10.245.71.108  netmask 255.255.248.0  broadcast 10.245.71.255
  inet6 fe80::ae1f:6bff:fe09:c052  prefixlen 64  scopeid 0x20
  ether ac:1f:6b:09:c0:52  txqueuelen 1000  (Ethernet)
  RX packets 154570  bytes 229998298 (229.9 MB)
  RX errors 0  dropped 0  overruns 0  frame 0
  TX packets 61080  bytes 6131460 (6.1 MB)
  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

  enP2p1s0f1: flags=4098  mtu 1500
  ether 

[Touch-packages] [Bug 1752737] Re: [2.3.0-6434] mDNS observer problems

[Andres Rodriguez]

** Changed in: maas
Milestone: 2.4.0beta2 => 2.4.0beta3

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

Title:
  [2.3.0-6434] mDNS observer problems

Status in Avahi:
  Unknown
Status in MAAS:
  Triaged
Status in avahi package in Ubuntu:
  Confirmed

Bug description:
  I see avahi-browser choking on non-utf8 characters in my rackd.log:

  ==> rackd.log <==
  2018-02-28 16:54:33 provisioningserver.utils.services: [info] mDNS 
observation process started.
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
Traceback (most recent call last):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 87, in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 83, in main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
run()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 52, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
from provisioningserver.__main__ import main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/__main__.py", line 55, 
in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
91, in __call__
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
self.execute(argv)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
86, in execute
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
args.handler.run(args)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
221, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
_observe_mdns(reader, output, args.verbose)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
145, in _observe_mdns
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in observer(events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
161, in _observe_resolver_found
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in filter(_p_resolver_found, events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
125, in _extract_mdns_events
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in map(parse_avahi_event, lines):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3.5/codecs.py", line 321, in decode
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
(result, consumed) = self._buffer_decode(data, self.errors, final)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc8 in position 240: 
invalid continuation byte
  2018-02-28 16:54:36 provisioningserver.utils.services: [critical] mDNS 
observation process failed.

  Traceback (most recent call last):
  Failure: twisted.internet.error.ProcessTerminated: A process has ended with a 
probable error condition: process ended with exit code 1.

  ==> regiond.log <==
  2018-02-28 16:54:50 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)
  2018-02-28 16:55:20 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)

  ==> maas.log <==
  Feb 28 16:53:52 MAAS-RC01 maas.interface: [info] ens33 (physical) on 
MAAS-RC01: New MAC, IP binding observed: 08:eb:74:ca:d3:6f, 192.168.1.82

  Similar traceback when running from command line:

  maasuser@MAAS-RC01:~$ maas-rack observe-mdns
  {"hostname": "Apple-TV", "interface": "ens33", "address": "192.168.1.81"}
  Got SIGTERM, quitting.
  Traceback (most recent call last):
File "/usr/sbin/maas-rack", line 87, in 
  main()
File "/usr/sbin/maas-rack", line 83, in main
  

[Touch-packages] [Bug 1761294] Re: Network configuration doesn't survive reboots after bionic dist-upgrade

[Andres Rodriguez]

*** This bug is a duplicate of bug 1756846 ***
https://bugs.launchpad.net/bugs/1756846

Thanks to the investigation from Steve, it seems that during the dist-
upgrade process ifupdown was removed due a transient conflict during the
devel cycle. This caused it to be removed. It being removed didn't
provide network. So this bug is basically a duplicate of #1756846.

17:21 < slangasek> roaksoax: according to your logs, during that upgrade the 
ifupdown package was removed (because of a transient conflict 
   during the devel cycle). you do not have the ifupdown 
package installed.
17:22 < slangasek> roaksoax: reinstalling ifupdown will fix this, and this is 
basically a duplicate of LP: #1756846


** This bug has been marked a duplicate of bug 1756846
   bridge-utils incompatible with ifupdown on bionic

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

Title:
  Network configuration doesn't survive reboots after bionic dist-
  upgrade

Status in cloud-init package in Ubuntu:
  Invalid
Status in ifupdown package in Ubuntu:
  New
Status in netplan.io package in Ubuntu:
  Invalid

Bug description:
  I deployed Xenial in this machine with MAAS. After deployment i had
  re-configured interfaces manually (on /etc/network/interfaces), and
  removed /etc/network/interfaces.d. At some point, I upgraded the
  machine from Xenial to Bionic, and everything was working just fine
  with /e/n/i.

  About 2/3 weeks ago, I dist-upgraded bionic for the latest packages,
  and after reboot, networking didn't come up.


  To recover the machine, what i did is:

  1. From the console, brought up the interfaces manually (eno1)
  2. added an IP address manually (ip addr add)
  3. Configured netplan and applied the config: 

  network:
  version: 2
  renderer: networkd
  ethernets:
  eno1:
  dhcp4: no
  dhcp6: no
  addresses: [192.168.1.13/24]
  gateway4: 192.168.1.1
  nameservers:
  addresses: [8.8.8.8, 8.8.4.4]
  usb0:
  dhcp4: no
  bridges:
  br0:
  interfaces: [usb0]
  dhcp4: no
  addresses: [10.90.90.1/24]
  parameters:
  stp: false
  forward-delay: 0
  max-age: 0

  5. Interfaces dont get configured correctly:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  17: eno1:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  link/ether ec:a8:6b:fd:ac:70 brd ff:ff:ff:ff:ff:ff
  inet 192.168.1.13/24 scope global eno1
     valid_lft forever preferred_lft forever
  inet6 fe80::eea8:6bff:fefd:ac70/64 scope link
     valid_lft forever preferred_lft forever
  19: usb0:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  link/ether 00:0e:c6:88:b7:9f brd ff:ff:ff:ff:ff:ff
  inet6 fe80::20e:c6ff:fe88:b79f/64 scope link
     valid_lft forever preferred_lft forever
  22: wlp2s0:  mtu 1500 qdisc noop state DOWN group 
default qlen 1000
  link/ether c4:d9:87:5b:42:62 brd ff:ff:ff:ff:ff:ff

  6. on reboot, the machine goes back to have no networking again, at
  all.

  Note that I also have /e/n/i configured.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1761294/+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 1761294] Re: Network configuration doesn't survive reboots after bionic dist-upgrade

[Andres Rodriguez]

https://pastebin.ubuntu.com/p/YPRxSrjHZ9/

** Changed in: netplan.io (Ubuntu)
   Status: Incomplete => New

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

Title:
  Network configuration doesn't survive reboots after bionic dist-
  upgrade

Status in cloud-init package in Ubuntu:
  New
Status in ifupdown package in Ubuntu:
  New
Status in netplan.io package in Ubuntu:
  Invalid

Bug description:
  I deployed Xenial in this machine with MAAS. After deployment i had
  re-configured interfaces manually (on /etc/network/interfaces), and
  removed /etc/network/interfaces.d. At some point, I upgraded the
  machine from Xenial to Bionic, and everything was working just fine
  with /e/n/i.

  About 2/3 weeks ago, I dist-upgraded bionic for the latest packages,
  and after reboot, networking didn't come up.


  To recover the machine, what i did is:

  1. From the console, brought up the interfaces manually (eno1)
  2. added an IP address manually (ip addr add)
  3. Configured netplan and applied the config: 

  network:
  version: 2
  renderer: networkd
  ethernets:
  eno1:
  dhcp4: no
  dhcp6: no
  addresses: [192.168.1.13/24]
  gateway4: 192.168.1.1
  nameservers:
  addresses: [8.8.8.8, 8.8.4.4]
  usb0:
  dhcp4: no
  bridges:
  br0:
  interfaces: [usb0]
  dhcp4: no
  addresses: [10.90.90.1/24]
  parameters:
  stp: false
  forward-delay: 0
  max-age: 0

  5. Interfaces dont get configured correctly:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  17: eno1:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  link/ether ec:a8:6b:fd:ac:70 brd ff:ff:ff:ff:ff:ff
  inet 192.168.1.13/24 scope global eno1
     valid_lft forever preferred_lft forever
  inet6 fe80::eea8:6bff:fefd:ac70/64 scope link
     valid_lft forever preferred_lft forever
  19: usb0:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  link/ether 00:0e:c6:88:b7:9f brd ff:ff:ff:ff:ff:ff
  inet6 fe80::20e:c6ff:fe88:b79f/64 scope link
     valid_lft forever preferred_lft forever
  22: wlp2s0:  mtu 1500 qdisc noop state DOWN group 
default qlen 1000
  link/ether c4:d9:87:5b:42:62 brd ff:ff:ff:ff:ff:ff

  6. on reboot, the machine goes back to have no networking again, at
  all.

  Note that I also have /e/n/i configured.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1761294/+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 1761294] Re: Network configuration doesn't survive reboots

[Andres Rodriguez]

cloud-init-output.log after manually rebooting the machine.

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

** Attachment added: "cloud-init-output.log"
   
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1761294/+attachment/5101804/+files/cloud-init-output.log

** Also affects: ifupdown (Ubuntu)
   Importance: Undecided
   Status: New

** Description changed:

  I deployed Xenial in this machine with MAAS. After deployment i had re-
  configured interfaces manually (on /etc/network/interfaces), and removed
  /etc/network/interfaces.d. At some point, I upgraded the machine from
  Xenial to Bionic, and everything was working just fine with /e/n/i.
  
  About 2/3 weeks ago, I dist-upgraded bionic for the latest packages, and
  after reboot, networking didn't come up.
  
+ 
  To recover the machine, what i did is:
  
- 1. From the console, bring up the interfaces.
- 2. Brought up eno1 manually & added an IP address manually (ip addr add)
- 3. Configured netplan interfaces
- 4. Run sudo netplan apply with the following config:
+ 1. From the console, brought up the interfaces manually (eno1)
+ 2. added an IP address manually (ip addr add)
+ 3. Configured netplan and applied the config: 
  
  network:
- version: 2
- renderer: networkd
- ethernets:
- eno1:
- dhcp4: no
- dhcp6: no
- addresses: [192.168.1.13/24]
- gateway4: 192.168.1.1
- nameservers:
- addresses: [8.8.8.8, 8.8.4.4]
- usb0:
- dhcp4: no
- bridges:
- br0:
- interfaces: [usb0]
- dhcp4: no
- addresses: [10.90.90.1/24]
- parameters:
- stp: false
- forward-delay: 0
- max-age: 0
+ version: 2
+ renderer: networkd
+ ethernets:
+ eno1:
+ dhcp4: no
+ dhcp6: no
+ addresses: [192.168.1.13/24]
+ gateway4: 192.168.1.1
+ nameservers:
+ addresses: [8.8.8.8, 8.8.4.4]
+ usb0:
+ dhcp4: no
+ bridges:
+ br0:
+ interfaces: [usb0]
+ dhcp4: no
+ addresses: [10.90.90.1/24]
+ parameters:
+ stp: false
+ forward-delay: 0
+ max-age: 0
  
  5. Interfaces dont get configured correctly:
  
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
- link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
- inet 127.0.0.1/8 scope host lo
-valid_lft forever preferred_lft forever
- inet6 ::1/128 scope host 
-valid_lft forever preferred_lft forever
+ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
+ inet 127.0.0.1/8 scope host lo
+    valid_lft forever preferred_lft forever
+ inet6 ::1/128 scope host
+    valid_lft forever preferred_lft forever
  17: eno1:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
- link/ether ec:a8:6b:fd:ac:70 brd ff:ff:ff:ff:ff:ff
- inet 192.168.1.13/24 scope global eno1
-valid_lft forever preferred_lft forever
- inet6 fe80::eea8:6bff:fefd:ac70/64 scope link 
-valid_lft forever preferred_lft forever
+ link/ether ec:a8:6b:fd:ac:70 brd ff:ff:ff:ff:ff:ff
+ inet 192.168.1.13/24 scope global eno1
+    valid_lft forever preferred_lft forever
+ inet6 fe80::eea8:6bff:fefd:ac70/64 scope link
+    valid_lft forever preferred_lft forever
  19: usb0:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
- link/ether 00:0e:c6:88:b7:9f brd ff:ff:ff:ff:ff:ff
- inet6 fe80::20e:c6ff:fe88:b79f/64 scope link 
-valid_lft forever preferred_lft forever
+ link/ether 00:0e:c6:88:b7:9f brd ff:ff:ff:ff:ff:ff
+ inet6 fe80::20e:c6ff:fe88:b79f/64 scope link
+    valid_lft forever preferred_lft forever
  22: wlp2s0:  mtu 1500 qdisc noop state DOWN group 
default qlen 1000
- link/ether c4:d9:87:5b:42:62 brd ff:ff:ff:ff:ff:ff
+ link/ether c4:d9:87:5b:42:62 brd ff:ff:ff:ff:ff:ff
  
  6. on reboot, the machine goes back to have no networking again, at all.
+ 
+ Note that I also have /e/n/i configured.

** Changed in: netplan.io (Ubuntu)
   Importance: Critical => Undecided

** Summary changed:

- Network configuration doesn't survive reboots
+ Network configuration doesn't survive reboots after bionic dist-upgrade

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

Title:
  Network configuration doesn't survive reboots after bionic dist-
  upgrade

Status in cloud-init package in Ubuntu:
  New
Status in ifupdown package in Ubuntu:
  New
Status in netplan.io package in Ubuntu:
  New

Bug description:
  I deployed Xenial in 

[Touch-packages] [Bug 1752737] Re: [2.3.0-6434] mDNS observer problems

[Andres Rodriguez]

** Changed in: maas
Milestone: 2.4.0beta1 => 2.4.0beta2

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

Title:
  [2.3.0-6434] mDNS observer problems

Status in Avahi:
  Unknown
Status in MAAS:
  Triaged
Status in avahi package in Ubuntu:
  Confirmed

Bug description:
  I see avahi-browser choking on non-utf8 characters in my rackd.log:

  ==> rackd.log <==
  2018-02-28 16:54:33 provisioningserver.utils.services: [info] mDNS 
observation process started.
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
Traceback (most recent call last):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 87, in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 83, in main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
run()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 52, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
from provisioningserver.__main__ import main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/__main__.py", line 55, 
in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
91, in __call__
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
self.execute(argv)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
86, in execute
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
args.handler.run(args)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
221, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
_observe_mdns(reader, output, args.verbose)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
145, in _observe_mdns
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in observer(events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
161, in _observe_resolver_found
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in filter(_p_resolver_found, events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
125, in _extract_mdns_events
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in map(parse_avahi_event, lines):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3.5/codecs.py", line 321, in decode
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
(result, consumed) = self._buffer_decode(data, self.errors, final)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc8 in position 240: 
invalid continuation byte
  2018-02-28 16:54:36 provisioningserver.utils.services: [critical] mDNS 
observation process failed.

  Traceback (most recent call last):
  Failure: twisted.internet.error.ProcessTerminated: A process has ended with a 
probable error condition: process ended with exit code 1.

  ==> regiond.log <==
  2018-02-28 16:54:50 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)
  2018-02-28 16:55:20 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)

  ==> maas.log <==
  Feb 28 16:53:52 MAAS-RC01 maas.interface: [info] ens33 (physical) on 
MAAS-RC01: New MAC, IP binding observed: 08:eb:74:ca:d3:6f, 192.168.1.82

  Similar traceback when running from command line:

  maasuser@MAAS-RC01:~$ maas-rack observe-mdns
  {"hostname": "Apple-TV", "interface": "ens33", "address": "192.168.1.81"}
  Got SIGTERM, quitting.
  Traceback (most recent call last):
File "/usr/sbin/maas-rack", line 87, in 
  main()
File "/usr/sbin/maas-rack", line 83, in main
  

[Touch-packages] [Bug 1752737] Re: [2.3.0-6434] mDNS observer problems

[Andres Rodriguez]

** Changed in: maas
Milestone: None => 2.4.0beta1

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

Title:
  [2.3.0-6434] mDNS observer problems

Status in Avahi:
  Unknown
Status in MAAS:
  Triaged
Status in avahi package in Ubuntu:
  Confirmed

Bug description:
  I see avahi-browser choking on non-utf8 characters in my rackd.log:

  ==> rackd.log <==
  2018-02-28 16:54:33 provisioningserver.utils.services: [info] mDNS 
observation process started.
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
Traceback (most recent call last):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 87, in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 83, in main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
run()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/maas/maas-common", line 52, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
from provisioningserver.__main__ import main
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/__main__.py", line 55, 
in 
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
main()
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
91, in __call__
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
self.execute(argv)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/script.py", line 
86, in execute
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
args.handler.run(args)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
221, in run
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
_observe_mdns(reader, output, args.verbose)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
145, in _observe_mdns
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in observer(events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
161, in _observe_resolver_found
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in filter(_p_resolver_found, events):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3/dist-packages/provisioningserver/utils/avahi.py", line 
125, in _extract_mdns_events
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
for event in map(parse_avahi_event, lines):
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
File "/usr/lib/python3.5/codecs.py", line 321, in decode
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
(result, consumed) = self._buffer_decode(data, self.errors, final)
  2018-02-28 16:54:36 provisioningserver.utils.services: [info] observe-mdns: 
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc8 in position 240: 
invalid continuation byte
  2018-02-28 16:54:36 provisioningserver.utils.services: [critical] mDNS 
observation process failed.

  Traceback (most recent call last):
  Failure: twisted.internet.error.ProcessTerminated: A process has ended with a 
probable error condition: process ended with exit code 1.

  ==> regiond.log <==
  2018-02-28 16:54:50 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)
  2018-02-28 16:55:20 regiond: [info] ::1 GET /MAAS/rpc/ HTTP/1.0 --> 200 OK 
(referrer: -; agent: provisioningserver.rpc.clusterservice.ClusterClientService)

  ==> maas.log <==
  Feb 28 16:53:52 MAAS-RC01 maas.interface: [info] ens33 (physical) on 
MAAS-RC01: New MAC, IP binding observed: 08:eb:74:ca:d3:6f, 192.168.1.82

  Similar traceback when running from command line:

  maasuser@MAAS-RC01:~$ maas-rack observe-mdns
  {"hostname": "Apple-TV", "interface": "ens33", "address": "192.168.1.81"}
  Got SIGTERM, quitting.
  Traceback (most recent call last):
File "/usr/sbin/maas-rack", line 87, in 
  main()
File "/usr/sbin/maas-rack", line 83, in main
  run()

[Touch-packages] [Bug 1537789] Re: MAAS dhcp fails to start on up-to-date Xenial with MAAS built from source

[Andres Rodriguez]

Dear user,

This is an automated message.

We believe this bug report is no longer an issue in the latest version
of MAAS. For such reason, we are making this issue as Won't Fix. If you
believe this issue is still present in the latest version of MAAS,
please re-open this bug report.

** Changed in: maas
   Status: Triaged => Won't Fix

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

Title:
  MAAS dhcp fails to start on  up-to-date Xenial with MAAS built from
  source

Status in MAAS:
  Won't Fix
Status in isc-dhcp package in Ubuntu:
  Fix Released

Bug description:

  /var/log/kern.log

  Jan 25 03:54:41 autopkgtest kernel: [  598.488307] audit: type=1400
  audit(1453712081.200:20): apparmor="DENIED" operation="capable"
  profile="/usr/sbin/dhcpd" pid=13381 comm="dhcpd" capability=0
  capname="chown"

  /var/log/syslog

  Jan 25 05:21:37 autopkgtest systemd[1]: Starting MAAS instance of ISC DHCP 
server for IPv4...
  Jan 25 05:21:37 autopkgtest systemd[1]: Started MAAS instance of ISC DHCP 
server for IPv4.
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: Can't chown new lease file: 
Operation not permitted
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: 
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: If you think you have received this 
message due to a bug rather
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: than a configuration issue please 
read the section on submitting
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: bugs on either our web page at 
www.isc.org or in the README file
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: before submitting a bug.  These 
pages explain the proper
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: process and the information we find 
helpful for debugging..
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: 
  Jan 25 05:21:37 autopkgtest dhcpd[17722]: exiting.
  Jan 25 05:21:37 autopkgtest systemd[1]: maas-dhcpd.service: Main process 
exited, code=exited, status=1/FAILURE
  Jan 25 05:21:37 autopkgtest systemd[1]: maas-dhcpd.service: Unit entered 
failed state.
  Jan 25 05:21:37 autopkgtest systemd[1]: maas-dhcpd.service: Failed with 
result 'exit-code'.

  root@autopkgtest:~# ls -l /var/lib/maas/dhcp/dhcpd.leases
  -rw-r--r-- 1 maas maas 0 Jan 25 03:54 /var/lib/maas/dhcp/dhcpd.leases

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

[Andres Rodriguez]

** Changed in: maas
   Importance: High => Medium

** Changed in: maas
   Status: Won't Fix => Triaged

** Changed in: maas
   Importance: Medium => Low

** Changed in: maas
Milestone: None => 2.4.x

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

Re: [Touch-packages] [Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Andres Rodriguez]

On Thu, Feb 22, 2018 at 10:30 PM Scott Moser <ssmoser2+ubu...@gmail.com>
wrote:

> 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.
>

This is the same issue we are facing in MAAS. Unless a user specifies a
specific set of dns servers on a subnet, which is not always the case, then
MAAS doesn’t know which interface the dns servers belong to.

I believe this is one of the reasons why the “global” config was used,
because effectively, the DNS server doesn’t really “belong” to a specific
interface.

So we either sent it to all, interfaces or pick a “best” interface, which
is not the best approach either.

As per mpontillo’s config, this has the likelihood to break dns
resolution.

That said, maybe option 3 would be to put th dns on the interface which the
default routes will be going through...


> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: product=cloud-init; status=New; importance=Undecided;
> assignee=None;
> Launchpad-Bug: product=maas; milestone=2.4.0alpha2; status=Triaged;
> importance=High; assignee=mike.ponti...@canonical.com;
> Launchpad-Bug: distribution=ubuntu; sourcepackage=nplan; component=main;
> status=New; importance=Critical; assignee=None;
> Launchpad-Bug: distribution=ubuntu; sourcepackage=systemd; component=main;
> status=New; importance=Critical; assignee=None;
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: andreserl cyphermox dean raharper smoser xnox
> Launchpad-Bug-Reporter: Andres Rodriguez (andreserl)
> Launchpad-Bug-Modifier: Scott Moser (smoser)
> Launchpad-Message-Rationale: Subscriber
> Launchpad-Message-For: andreserl
>
-- 
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
MSc. Telecom & Networking
Systems Engineer

-- 
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 fi

[Touch-packages] [Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Andres Rodriguez]

** Changed in: maas
   Importance: Low => High

** Changed in: maas
 Assignee: (unassigned) => Mike Pontillo (mpontillo)

** Changed in: maas
Milestone: None => 2.4.0alpha2

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

[Andres Rodriguez]

** Changed in: maas
   Importance: Undecided => Low

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

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

[Andres Rodriguez]

@Scott,

Sure, we can all improve but I just want to note one thing. The "Silly"
config that MAAS sends to curtin is valid config. That yields valid
configuration in Xenial. Since Curtin is now passing the /same/
configuration to cloud-init, cloud-init is not generating valid
configuration in Bionic. Despite the fact that theres a "global" DNS,
there's also DNS defined for the bridge, but cloud-init is not writing
the bridge config 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:
  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 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Andres Rodriguez]

@Matthieu,

ubuntu@node01:~$ systemd-resolve google.com
google.com: resolve call failed: No appropriate name servers or networks for 
name found

-- 
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 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Andres Rodriguez]

@Mathieu,

Good catch.

@Scott:

Network config MAAS sent is correect, it is the same config sent to
xenial: https://pastebin.canonical.com/p/rjBgzKjdxR/

-- 
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 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic

[Andres Rodriguez]

This is pretty critical to MAAS as this yield Bionic deployments without
DNS resolution.

** Description changed:

  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)
  
  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

** Summary changed:

- [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic
+ [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to 
no DNS resolution

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

[Touch-packages] [Bug 1750884] [NEW] [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Andres Rodriguez]

Public bug reported:

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

** Affects: cloud-init
 Importance: Undecided
 Status: New

** Affects: maas
 Importance: Undecided
 Status: Invalid

** Affects: nplan (Ubuntu)
 Importance: Critical
 Status: New

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

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

** Also affects: nplan (Ubuntu)
   Importance: Undecided
   Status: New

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

** Changed in: nplan (Ubuntu)
   Importance: Undecided => Critical

** Changed in: systemd (Ubuntu)
   Importance: Undecided => Critical

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

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

** Description changed:

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

[Touch-packages] [Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Andres Rodriguez]

ubuntu@node03:~$ systemd-resolve --status --no-pager
Global
  DNSSEC NTA: 10.in-addr.arpa
  16.172.in-addr.arpa
  168.192.in-addr.arpa
  17.172.in-addr.arpa
  18.172.in-addr.arpa
  19.172.in-addr.arpa
  20.172.in-addr.arpa
  21.172.in-addr.arpa
  22.172.in-addr.arpa
  23.172.in-addr.arpa
  24.172.in-addr.arpa
  25.172.in-addr.arpa
  26.172.in-addr.arpa
  27.172.in-addr.arpa
  28.172.in-addr.arpa
  29.172.in-addr.arpa
  30.172.in-addr.arpa
  31.172.in-addr.arpa
  corp
  d.f.ip6.arpa
  home
  internal
  intranet
  lan
  local
  private
  test

Link 3 (br0)
  Current Scopes: LLMNR/IPv4 LLMNR/IPv6
   LLMNR setting: yes
MulticastDNS setting: no
  DNSSEC setting: no
DNSSEC supported: no

Link 2 (enp0s25)
  Current Scopes: none
   LLMNR setting: yes
MulticastDNS setting: no
  DNSSEC setting: no
DNSSEC supported: no
 DNS Servers: 10.90.90.1
  DNS Domain: maaslab
  maas

** Description changed:

  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)
+ 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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in 

[Touch-packages] [Bug 1747460] Re: [MIR] py-macaroon-bakery, protobuf, pyrfc3339

[Andres Rodriguez]

Added a team subscriber


** Changed in: python-nacl (Ubuntu)
   Status: Incomplete => New

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

Title:
  [MIR] py-macaroon-bakery, protobuf, pyrfc3339

Status in protobuf package in Ubuntu:
  Invalid
Status in py-macaroon-bakery package in Ubuntu:
  Triaged
Status in pyrfc3339 package in Ubuntu:
  Triaged
Status in python-nacl package in Ubuntu:
  New

Bug description:
  py-macaroon-bakery
  ==

  1. Availability: all

  2. Rationale:
  Macaroons is a new form of authorization mechanism. The macaroon bakery 
builds on pymacaroons, which allows it working at a higher level.

  In order for MAAS (and other projects) to support macaroon based
  authentication, this needs to be in main. This will allow projects to
  support remote/centralized authentication based on macaroons.

  3. Security:
  No CVE's

  4. QA:
  0 bugs in debian/ubuntu

  5. UI standards:
  None

  6. Dependencies:

  Dependencies in universe:
   - python3-pymacaroons (MIR LP: #1746772)
   - python3-nacl
   - python3-protobuf
   - python3-rfc3339

  7. Standards:
  No lintian errors.

  Packaged with debhelper. Source format is 3.0 (quilt)

  Standards version: 4.4.1

  8. Maintenance:
  Easy.

  9. Background information:
  This is a required dependency to implement third party/centralized 
authentication alongside with pymacaroons. This is a new dependency that's 
required by MAAS.

  python3-protobuf
  ==

  1. Availability: any

  2. Rationale:
  Dependency of python3-macaroonbakery. The library from this same source 
package, libprotobuf10, is already in main.

  3. Security:
  No CVE's

  4. QA:
  protobuf source, 10 bugs in debian, 11 ubuntu

  5. UI standards:
  None

  6. Dependencies:
  All in main

  7. Standards:
  No lintian errors.

  Packaged with debhelper. Source format is 3.0 (quilt)

  Standards version: 3.9.8

  8. Maintenance:
  Easy.

  9. Background information:
  protobuf source already has binaries in main. This is just the python 
bindings that are required by macaroonbakery.

  rfc3339
  ==

  1. Availability: all

  2. Rationale:
  Dependency of python3-macaroonbakery.

  3. Security:
  No CVE's

  4. QA:
  0 bugs in debian/ubuntu

  5. UI standards:
  None

  6. Dependencies:
  All in main

  7. Standards:
  No lintian errors. 1 warning:
  W: pyrfc3339 source: ancient-standards-version 3.9.6 (released 2014-09-17) 
(current is 4.1.3)

  Packaged with debhelper. Source format is 3.0 (quilt)

  8. Maintenance:
  Easy.

  9. Background information:
  Parser and generator of RFC 3339-compliant timestamps. This is a dependency 
for python3-macaroonbakery.

  
  python-nacl
  ==

  1. Availability: any

  2. Rationale:
  Dependency of python3-macaroonbakery.

  3. Security:
  No CVE's

  4. QA:
  0 bugs in debian/ubuntu

  5. UI standards:
  None

  6. Dependencies:
  All in main

  7. Standards:
  No lintian errors.

  Uses standards version 3.9.8

  Packaged with debhelper. Source format is 3.0 (quilt)

  8. Maintenance:
  Easy.

  9. Background information:
  PyNaCl is a Python binding to the Networking and Cryptography library. This 
is a dependency for python3-macaroonbakery.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/protobuf/+bug/1747460/+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 1747460] Re: [MIR] py-macaroon-bakery, protobuf, pyrfc3339

[Andres Rodriguez]

FWIW, i have filed:

https://github.com/go-macaroon-bakery/py-macaroon-bakery/issues/47
https://github.com/ecordell/pymacaroons/issues/44

but doubt this would be resolved before Bionic.

** Also affects: python-nacl (Ubuntu)
   Importance: Undecided
   Status: New

** Description changed:

  py-macaroon-bakery
  ==
  
  1. Availability: all
  
  2. Rationale:
  Macaroons is a new form of authorization mechanism. The macaroon bakery 
builds on pymacaroons, which allows it working at a higher level.
  
  In order for MAAS (and other projects) to support macaroon based
  authentication, this needs to be in main. This will allow projects to
  support remote/centralized authentication based on macaroons.
  
  3. Security:
  No CVE's
  
  4. QA:
  0 bugs in debian/ubuntu
  
  5. UI standards:
  None
  
  6. Dependencies:
  
  Dependencies in universe:
   - python3-pymacaroons (MIR LP: #1746772)
-  - python3-nacl (MIR LP: #1746772)
+  - python3-nacl
   - python3-protobuf
   - python3-rfc3339
  
  7. Standards:
  No lintian errors.
  
  Packaged with debhelper. Source format is 3.0 (quilt)
  
  Standards version: 4.4.1
  
  8. Maintenance:
  Easy.
  
  9. Background information:
  This is a required dependency to implement third party/centralized 
authentication alongside with pymacaroons. This is a new dependency that's 
required by MAAS.
  
  python3-protobuf
  ==
  
  1. Availability: any
  
  2. Rationale:
  Dependency of python3-macaroonbakery. The library from this same source 
package, libprotobuf10, is already in main.
  
  3. Security:
  No CVE's
  
  4. QA:
  protobuf source, 10 bugs in debian, 11 ubuntu
  
  5. UI standards:
  None
  
  6. Dependencies:
  All in main
  
  7. Standards:
  No lintian errors.
  
  Packaged with debhelper. Source format is 3.0 (quilt)
  
  Standards version: 3.9.8
  
  8. Maintenance:
  Easy.
  
  9. Background information:
  protobuf source already has binaries in main. This is just the python 
bindings that are required by macaroonbakery.
  
- 
  rfc3339
  ==
  
  1. Availability: all
  
  2. Rationale:
  Dependency of python3-macaroonbakery.
  
  3. Security:
  No CVE's
  
  4. QA:
  0 bugs in debian/ubuntu
  
  5. UI standards:
  None
  
  6. Dependencies:
  All in main
  
  7. Standards:
  No lintian errors. 1 warning:
  W: pyrfc3339 source: ancient-standards-version 3.9.6 (released 2014-09-17) 
(current is 4.1.3)
  
  Packaged with debhelper. Source format is 3.0 (quilt)
  
  8. Maintenance:
  Easy.
  
  9. Background information:
  Parser and generator of RFC 3339-compliant timestamps. This is a dependency 
for python3-macaroonbakery.

** Description changed:

  py-macaroon-bakery
  ==
  
  1. Availability: all
  
  2. Rationale:
  Macaroons is a new form of authorization mechanism. The macaroon bakery 
builds on pymacaroons, which allows it working at a higher level.
  
  In order for MAAS (and other projects) to support macaroon based
  authentication, this needs to be in main. This will allow projects to
  support remote/centralized authentication based on macaroons.
  
  3. Security:
  No CVE's
  
  4. QA:
  0 bugs in debian/ubuntu
  
  5. UI standards:
  None
  
  6. Dependencies:
  
  Dependencies in universe:
   - python3-pymacaroons (MIR LP: #1746772)
   - python3-nacl
   - python3-protobuf
   - python3-rfc3339
  
  7. Standards:
  No lintian errors.
  
  Packaged with debhelper. Source format is 3.0 (quilt)
  
  Standards version: 4.4.1
  
  8. Maintenance:
  Easy.
  
  9. Background information:
  This is a required dependency to implement third party/centralized 
authentication alongside with pymacaroons. This is a new dependency that's 
required by MAAS.
  
  python3-protobuf
  ==
  
  1. Availability: any
  
  2. Rationale:
  Dependency of python3-macaroonbakery. The library from this same source 
package, libprotobuf10, is already in main.
  
  3. Security:
  No CVE's
  
  4. QA:
  protobuf source, 10 bugs in debian, 11 ubuntu
  
  5. UI standards:
  None
  
  6. Dependencies:
  All in main
  
  7. Standards:
  No lintian errors.
  
  Packaged with debhelper. Source format is 3.0 (quilt)
  
  Standards version: 3.9.8
  
  8. Maintenance:
  Easy.
  
  9. Background information:
  protobuf source already has binaries in main. This is just the python 
bindings that are required by macaroonbakery.
  
  rfc3339
  ==
  
  1. Availability: all
  
  2. Rationale:
  Dependency of python3-macaroonbakery.
  
  3. Security:
  No CVE's
  
  4. QA:
  0 bugs in debian/ubuntu
  
  5. UI standards:
  None
  
  6. Dependencies:
  All in main
  
  7. Standards:
  No lintian errors. 1 warning:
  W: pyrfc3339 source: ancient-standards-version 3.9.6 (released 2014-09-17) 
(current is 4.1.3)
  
  Packaged with debhelper. Source format is 3.0 (quilt)
  
  8. Maintenance:
  Easy.
  
  9. Background information:
  Parser and generator of RFC 3339-compliant timestamps. This is a 

[Touch-packages] [Bug 1747460] Re: [MIR] py-macaroon-bakery, protobuf, pyrfc3339

[Andres Rodriguez]

09:27 < roaksoax> doko: TBH, no idea as i've not looked at what the differences 
are, but will take a look
09:38 < doko> roaksoax: maybe you could ask cjwatson about the differences in 
python-nacl and python-libnacl, he is one of the Debian uploaders
09:39 < roaksoax> doko: that's what I waas planning on doing :)
09:42 < cjwatson> different upstream projects with incompatible APIs
09:43 < cjwatson> more or less similar functions
09:43 < cjwatson> but AIUI switching from one to the other is basically a 
rewrite


** Changed in: py-macaroon-bakery (Ubuntu)
   Status: Incomplete => New

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

Title:
  [MIR] py-macaroon-bakery, protobuf, pyrfc3339

Status in protobuf package in Ubuntu:
  Invalid
Status in py-macaroon-bakery package in Ubuntu:
  New
Status in pyrfc3339 package in Ubuntu:
  New

Bug description:
  py-macaroon-bakery
  ==

  1. Availability: all

  2. Rationale:
  Macaroons is a new form of authorization mechanism. The macaroon bakery 
builds on pymacaroons, which allows it working at a higher level.

  In order for MAAS (and other projects) to support macaroon based
  authentication, this needs to be in main. This will allow projects to
  support remote/centralized authentication based on macaroons.

  3. Security:
  No CVE's

  4. QA:
  0 bugs in debian/ubuntu

  5. UI standards:
  None

  6. Dependencies:

  Dependencies in universe:
   - python3-pymacaroons (MIR LP: #1746772)
   - python3-nacl (MIR LP: #1746772)
   - python3-protobuf
   - python3-rfc3339

  7. Standards:
  No lintian errors.

  Packaged with debhelper. Source format is 3.0 (quilt)

  Standards version: 4.4.1

  8. Maintenance:
  Easy.

  9. Background information:
  This is a required dependency to implement third party/centralized 
authentication alongside with pymacaroons. This is a new dependency that's 
required by MAAS.

  python3-protobuf
  ==

  1. Availability: any

  2. Rationale:
  Dependency of python3-macaroonbakery. The library from this same source 
package, libprotobuf10, is already in main.

  3. Security:
  No CVE's

  4. QA:
  protobuf source, 10 bugs in debian, 11 ubuntu

  5. UI standards:
  None

  6. Dependencies:
  All in main

  7. Standards:
  No lintian errors.

  Packaged with debhelper. Source format is 3.0 (quilt)

  Standards version: 3.9.8

  8. Maintenance:
  Easy.

  9. Background information:
  protobuf source already has binaries in main. This is just the python 
bindings that are required by macaroonbakery.

  
  rfc3339
  ==

  1. Availability: all

  2. Rationale:
  Dependency of python3-macaroonbakery.

  3. Security:
  No CVE's

  4. QA:
  0 bugs in debian/ubuntu

  5. UI standards:
  None

  6. Dependencies:
  All in main

  7. Standards:
  No lintian errors. 1 warning:
  W: pyrfc3339 source: ancient-standards-version 3.9.6 (released 2014-09-17) 
(current is 4.1.3)

  Packaged with debhelper. Source format is 3.0 (quilt)

  8. Maintenance:
  Easy.

  9. Background information:
  Parser and generator of RFC 3339-compliant timestamps. This is a dependency 
for python3-macaroonbakery.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/protobuf/+bug/1747460/+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 1626692] Re: python3 support

[Andres Rodriguez]

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

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

Title:
  python3 support

Status in protobuf package in Ubuntu:
  Fix Released

Bug description:
  Hi,

  could you please enable python3 builds for the new protobuf3 version?
  A patch for it is already floating around: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836821#10

  I tested it in my PPA, just needed to add python3-six as an extra
  explicit dependency (for some reason it was not automatically
  selected, even though python-six was) and the python3
  override_dh_auto_test-arch had a small error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/protobuf/+bug/1626692/+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 1747460] Re: [MIR] py-macaroon-bakery, protobuf, pyrfc3339

[Andres Rodriguez]

** Summary changed:

- [MIR] py-macaroon-bakery, 
+ [MIR] py-macaroon-bakery, protobuf, pyrfc3339

** Description changed:

  py-macaroon-bakery
  ==
  
  1. Availability: all
  
  2. Rationale:
  Macaroons is a new form of authorization mechanism. The macaroon bakery 
builds on pymacaroons, which allows it working at a higher level.
  
  In order for MAAS (and other projects) to support macaroon based
  authentication, this needs to be in main. This will allow projects to
  support remote/centralized authentication based on macaroons.
  
  3. Security:
  No CVE's
  
  4. QA:
  0 bugs in debian/ubuntu
  
  5. UI standards:
  None
  
  6. Dependencies:
  
  Dependencies in universe:
-  - python3-pymacaroons (MIR LP: #1746772)
-  - python3-nacl (MIR LP: #1746772)
-  - python3-protobuf
-  - python3-rfc3339
+  - python3-pymacaroons (MIR LP: #1746772)
+  - python3-nacl (MIR LP: #1746772)
+  - python3-protobuf
+  - python3-rfc3339
  
  7. Standards:
  No lintian errors.
  
  Packaged with debhelper. Source format is 3.0 (quilt)
  
  Standards version: 4.4.1
  
  8. Maintenance:
  Easy.
  
  9. Background information:
  This is a required dependency to implement third party/centralized 
authentication alongside with pymacaroons. This is a new dependency that's 
required by MAAS.
+ 
+ python3-protobuf
+ ==
+ 
+ 1. Availability: any
+ 
+ 2. Rationale:
+ Dependency of python3-macaroonbakery. The library from this same source 
package, libprotobuf10, is already in main.
+ 
+ 3. Security:
+ No CVE's
+ 
+ 4. QA:
+ protobuf source, 10 bugs in debian, 11 ubuntu
+ 
+ 5. UI standards:
+ None
+ 
+ 6. Dependencies:
+ All in main
+ 
+ 7. Standards:
+ No lintian errors.
+ 
+ Packaged with debhelper. Source format is 3.0 (quilt)
+ 
+ Standards version: 4.4.1
+ 
+ 8. Maintenance:
+ Easy.
+ 
+ 9. Background information:
+ protobuf source already has binaries in main. This is just the python 
bindings that are required by macaroonbakery.

** Also affects: protobuf (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: pyrfc3339 (Ubuntu)
   Importance: Undecided
   Status: New

** Description changed:

  py-macaroon-bakery
  ==
  
  1. Availability: all
  
  2. Rationale:
  Macaroons is a new form of authorization mechanism. The macaroon bakery 
builds on pymacaroons, which allows it working at a higher level.
  
  In order for MAAS (and other projects) to support macaroon based
  authentication, this needs to be in main. This will allow projects to
  support remote/centralized authentication based on macaroons.
  
  3. Security:
  No CVE's
  
  4. QA:
  0 bugs in debian/ubuntu
  
  5. UI standards:
  None
  
  6. Dependencies:
  
  Dependencies in universe:
   - python3-pymacaroons (MIR LP: #1746772)
   - python3-nacl (MIR LP: #1746772)
   - python3-protobuf
   - python3-rfc3339
  
  7. Standards:
  No lintian errors.
  
  Packaged with debhelper. Source format is 3.0 (quilt)
  
  Standards version: 4.4.1
  
  8. Maintenance:
  Easy.
  
  9. Background information:
  This is a required dependency to implement third party/centralized 
authentication alongside with pymacaroons. This is a new dependency that's 
required by MAAS.
  
  python3-protobuf
  ==
  
  1. Availability: any
  
  2. Rationale:
  Dependency of python3-macaroonbakery. The library from this same source 
package, libprotobuf10, is already in main.
  
  3. Security:
  No CVE's
  
  4. QA:
  protobuf source, 10 bugs in debian, 11 ubuntu
  
  5. UI standards:
  None
  
  6. Dependencies:
  All in main
  
  7. Standards:
  No lintian errors.
  
  Packaged with debhelper. Source format is 3.0 (quilt)
  
- Standards version: 4.4.1
+ Standards version: 3.9.8
  
  8. Maintenance:
  Easy.
  
  9. Background information:
  protobuf source already has binaries in main. This is just the python 
bindings that are required by macaroonbakery.
+ 
+ 
+ rfc3339
+ ==
+ 
+ 1. Availability: all
+ 
+ 2. Rationale:
+ Dependency of python3-macaroonbakery.
+ 
+ 3. Security:
+ No CVE's
+ 
+ 4. QA:
+ 0 bugs in debian/ubuntu
+ 
+ 5. UI standards:
+ None
+ 
+ 6. Dependencies:
+ All in main
+ 
+ 7. Standards:
+ No lintian errors. 1 warning:
+ W: pyrfc3339 source: ancient-standards-version 3.9.6 (released 2014-09-17) 
(current is 4.1.3)
+ 
+ Packaged with debhelper. Source format is 3.0 (quilt)
+ 
+ 8. Maintenance:
+ Easy.
+ 
+ 9. Background information:
+ Parser and generator of RFC 3339-compliant timestamps. This is a dependency 
for python3-macaroonbakery.

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

Title:
  [MIR] py-macaroon-bakery, protobuf, pyrfc3339

Status in protobuf package in Ubuntu:
  New
Status in py-macaroon-bakery package in Ubuntu:
  New
Status in pyrfc3339 package in Ubuntu:
  New

Bug description:
  py-macaroon-bakery
  ==

  

[Touch-packages] [Bug 1732703] Re: MAAS does not detect properly if Ubuntu is using upstart/systemd

[Andres Rodriguez]

@I've uploaded the new package. I've tested an upgrade to Xenial to
ensure there are no issues and confirm it is good to go.

** Changed in: maas/1.9
 Assignee: Andres Rodriguez (andreserl) => (unassigned)

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

Title:
  MAAS does not detect properly if Ubuntu is using upstart/systemd

Status in MAAS:
  Won't Fix
Status in MAAS 1.9 series:
  In Progress
Status in maas package in Ubuntu:
  Won't Fix
Status in snapd package in Ubuntu:
  Won't Fix
Status in systemd package in Ubuntu:
  New
Status in maas source package in Trusty:
  Triaged
Status in snapd source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  New

Bug description:
  [impact]
  Since Trusty uses upstart by default, MAAS manages its services with upstart. 
However, when a user installs systemd (even if it is not used as the init 
system), MAAS detects systemd installed and tries to manage its services via 
systemd. This obviously creates issues and prevents MAAS from working.

  [Test Case]
  1. Install & configure MAAS
  2. Add machines
  3. install systemd
  4. MAAS will fail to manage machines

  [Regression potential]
  Minimal. This just ensures that upstart is detected correctly even if systemd 
is installed (but not used).

  [Original bug report]
  Trusty uses upstart by default, and installing snapd (e.g. for livepatch 
purposes), pulls systemd too. In this setup, upstart is _not_ replaced by 
systemd, but MAAS "detects" systemd as init because of the existence of 
/run/systemd/system:

  @src/provisioningserver/utils/__init__.py:505

  SYSTEMD_RUN_PATH = '/run/systemd/system'

  def get_init_system():
  """Returns 'upstart' or 'systemd'."""
  if os.path.exists(SYSTEMD_RUN_PATH):
  return 'systemd'
  else:
  return 'upstart'

  One possible solution would be to check if /sbin/init is a symlink
  pointing to /lib/systemd/systemd:

  def get_init_system():
  """Returns 'upstart' or 'systemd'."""
  initpath = os.readlink("/sbin/init")
  if (initpath == "/lib/systemd/systemd"):
  return 'systemd'
  else:
  return 'upstart'

  Other affected parts of the code are the postinst files for maas-proxy
  and maas-dhcp (debian/maas-proxy.postinst debian/maas-dhcp.postinst),
  throwing an error if maas is installed after systemd in Trusty

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1732703/+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 1732703] Re: MAAS does not detect properly if Ubuntu is using upstart/systemd

[Andres Rodriguez]

On Wed, Dec 13, 2017 at 6:00 PM Robie Basak <1732...@bugs.launchpad.net>
wrote:

> On Wed, Dec 13, 2017 at 10:34:25PM -0000, Andres Rodriguez wrote:
> > FWIW, this is currently affecting customers who are running MAAS and
> > require livepatch.
>
> It's been affecting users since January, no?


This hasn’t been affecting users since January. This bug has been reported
in November and only affects users running MAAS who someway or another
installed systemd. In this particular case, on November a customer
installed live patch on a system, hence the issue.

Why the sudden urgency?
> What difference will a week or two make?
>
> > Comments #11 and #12 above confirm that the patch is enough for the MAAS
> > needs. Whichever way MAAS decides to check for systemd is up to MAAS and
> > that is not a reason to block an SRU provided that it does not impact
> > any other piece of software. That said, this patch does not does not
> > introduce  a regression to MAAS nor any other software.
>
> I think that's quite a brave claim to make. I'm sure "does not
> introduce a regression" was a claim that might have been made in the
> systemd SRU that regressed this too, and yet here we are.


There is no supported way on Ubuntu Trusty (nor package in the archive)
that will create a symlink of /sbin/init to systemd. This only happens By
the systemd-sysv package which is only available in Xenial. So, since
systemd is not supported as a init system in trusty and this would only
happen if a user manually does this, then this doesn’t introduce any
regressions in MAAS. So it is not a brave claim to make, it is a claim
based on facts.

>
>
> > Lastly, this patch is *only* for 1.9 as this code path is only available
> > in Trusty, so upgrades to later Ubuntu releases will yield on using a
> > newer version of MAAS that doesn't rely on this code path.
>
> If we did decide to SRU an emergency fix as a stopgap for MAAS' use
> case, and it's for Trusty only, then why have a test at all? Can we just
> return 'upstart' without a test?
>
> To be clear, I'm not demanding or even requesting anything specific
> right now. I don't feel that a case for urgency has yet been made, given
> the currently known regression timeline. In the meantime I think it's
> worth understanding how we want to fix this properly, because requiring
> multiple SRUs while we swing back and forth is bad for everyone, and
> equally I don't want to see us locked into a suboptimal solution.
>
> If a case is accepted on the basis of urgency, or another SRU team
> member disagrees with my assessment, I wouldn't want to block that. Feel
> free to land what you think is appropriate.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1732703
>
> Title:
>   MAAS does not detect properly if Ubuntu is using upstart/systemd
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maas/+bug/1732703/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: product=maas; status=Won't Fix; importance=Undecided;
> assignee=None;
> Launchpad-Bug: product=maas; productseries=1.9; milestone=1.9.6; status=In
> Progress; importance=Critical; assignee=andres...@ubuntu-pe.org;
> Launchpad-Bug: distribution=ubuntu; sourcepackage=maas; component=main;
> status=New; importance=Critical; assignee=None;
> Launchpad-Bug: distribution=ubuntu; sourcepackage=snapd; component=main;
> status=Won't Fix; importance=Undecided; assignee=None;
> Launchpad-Bug: distribution=ubuntu; sourcepackage=systemd; component=main;
> status=New; importance=Undecided; assignee=None;
> Launchpad-Bug: distribution=ubuntu; distroseries=trusty;
> sourcepackage=maas; component=main; status=New; importance=Undecided;
> assignee=None;
> Launchpad-Bug: distribution=ubuntu; distroseries=trusty;
> sourcepackage=snapd; component=universe; status=New; importance=Undecided;
> assignee=None;
> Launchpad-Bug: distribution=ubuntu; distroseries=trusty;
> sourcepackage=systemd; component=main; status=New; importance=Critical;
> assignee=None;
> Launchpad-Bug-Tags: regression-update sts
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: afreiberger andreserl racb vorlon vtapia xnox
> Launchpad-Bug-Reporter: Victor Tapia (vtapia)
> Launchpad-Bug-Modifier: Robie Basak (racb)
> Launchpad-Message-Rationale: Assignee
> Launchpad-Message-For: andreserl
>
-- 
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
MSc. Telecom & Networking
Systems Engineer

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
htt

[Touch-packages] [Bug 1732703] Re: MAAS does not detect properly if Ubuntu is using upstart/systemd

[Andres Rodriguez]

FWIW, this is currently affecting customers who are running MAAS and
require livepatch.

Comments #11 and #12 above confirm that the patch is enough for the MAAS
needs. Whichever way MAAS decides to check for systemd is up to MAAS and
that is not a reason to block an SRU provided that it does not impact
any other piece of software. That said, this patch does not does not
introduce  a regression to MAAS nor any other software.

Lastly, this patch is *only* for 1.9 as this code path is only available
in Trusty, so upgrades to later Ubuntu releases will yield on using a
newer version of MAAS that doesn't rely on this code path.

That said, there's no supported way in Ubuntu that will symlink
/sbin/init -> /lib/systemd/systemd , provided that systemd-sysv is
*only* available in Xenial, and again, upgrades to Xenial will result in
MAAS not using this codepath at all.

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

Title:
  MAAS does not detect properly if Ubuntu is using upstart/systemd

Status in MAAS:
  Won't Fix
Status in MAAS 1.9 series:
  In Progress
Status in maas package in Ubuntu:
  New
Status in snapd package in Ubuntu:
  Won't Fix
Status in systemd package in Ubuntu:
  New
Status in maas source package in Trusty:
  New
Status in snapd source package in Trusty:
  New
Status in systemd source package in Trusty:
  New

Bug description:
  [impact]
  Since Trusty uses upstart by default, MAAS manages its services with upstart. 
However, when a user installs systemd (even if it is not used as the init 
system), MAAS detects systemd installed and tries to manage its services via 
systemd. This obviously creates issues and prevents MAAS from working.

  [Test Case]
  1. Install & configure MAAS
  2. Add machines
  3. install systemd
  4. MAAS will fail to manage machines

  [Regression potential]
  Minimal. This just ensures that upstart is detected correctly even if systemd 
is installed (but not used).

  [Original bug report]
  Trusty uses upstart by default, and installing snapd (e.g. for livepatch 
purposes), pulls systemd too. In this setup, upstart is _not_ replaced by 
systemd, but MAAS "detects" systemd as init because of the existence of 
/run/systemd/system:

  @src/provisioningserver/utils/__init__.py:505

  SYSTEMD_RUN_PATH = '/run/systemd/system'

  def get_init_system():
  """Returns 'upstart' or 'systemd'."""
  if os.path.exists(SYSTEMD_RUN_PATH):
  return 'systemd'
  else:
  return 'upstart'

  One possible solution would be to check if /sbin/init is a symlink
  pointing to /lib/systemd/systemd:

  def get_init_system():
  """Returns 'upstart' or 'systemd'."""
  initpath = os.readlink("/sbin/init")
  if (initpath == "/lib/systemd/systemd"):
  return 'systemd'
  else:
  return 'upstart'

  Other affected parts of the code are the postinst files for maas-proxy
  and maas-dhcp (debian/maas-proxy.postinst debian/maas-dhcp.postinst),
  throwing an error if maas is installed after systemd in Trusty

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1732703/+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 1732522] Re: [2.3] Ephemeral boot environment does not renew DHCP leases

[Andres Rodriguez]

** Changed in: maas
   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/1732522

Title:
  [2.3] Ephemeral boot environment does not renew DHCP leases

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

Bug description:
  I started commissioning+hardware testing on a machine, and while the
  machine was testing (for 2hrs+) i noticed that the IP address had
  disappeared. The machine has the MAC of  00:25:90:4c:e7:9e and IP of
  192.168.0.211 from the dynamic range.

  Checking the MAAS server, I noticed that the IP/MAC was in the ARP
  table:

  andreserl@maas:/var/lib/maas/dhcp$ arp -a | grep 211
  192-168-9-211.maas (192.168.9.211) at 00:25:90:4c:e7:9e [ether] on bond-lan

  Checking the leases file has the following:
  http://pastebin.ubuntu.com/25969442/

  Then I checked a couple areas of MAAS:
   - Device discovery, the machine wasn't there.
   - Subnet details page, the machine wasn't there (e.g. as observed)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1732522/+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 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)

[Andres Rodriguez]

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

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

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

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

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

  Thus dns resolution does not work. Of most interest was the MAAS use
  case of the 'root=http://<>/squashfs' use case.  MAAS 2.3 uses this for
  the installation environment and also the rescue environment.

  [Test Case]
  There are two tests for this.

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

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

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

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

  b.) this is not a container.

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

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

  [Other Info]

  === End SRU Template ===

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

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

  ubuntu@manual:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback

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

  Which correctly includes the DNS server. However:

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

  If restart the interfacE:

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

  Listening on LPF/ens3/52:54:00:ea:57:31
  Sending on   LPF/ens3/52:54:00:ea:57:31
  Sending on   Socket/fallback
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
  DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 
(xid=0x5403eb14)
  DHCPOFFER of 192.168.122.195 from 192.168.122.2
  DHCPACK of 192.168.122.195 from 192.168.122.2
  Restarting ntp (via systemctl): ntp.service.
  bound to 192.168.122.195 -- renewal in 290 seconds.

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

  ubuntu@manual:~$ ping google.com
  PING google.com (216.58.192.46) 56(84) bytes of data.
  64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 

[Touch-packages] [Bug 1573982] Re: LVM boot problem - volumes not activated after upgrade to Xenial

[Andres Rodriguez]

@Chris,

Can you attach the output of:

maas  machine get-curtin-config 

And attach the follow curtin log (you can grab that from the UI under
the Installation tab).

Also, this seems an issue widely with Ubuntu.

Curtin is the one that writes this configuration, so marking this as
Incomplete for MAAS and opening it in curtin.

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

** Also affects: curtin
   Importance: Undecided
   Status: New

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

Title:
  LVM boot problem - volumes not activated after upgrade to Xenial

Status in curtin:
  New
Status in MAAS:
  Incomplete
Status in lvm2 package in Ubuntu:
  Confirmed

Bug description:
  Soon after upgrade to Xenial (from 15.10) the boot process got broken.
  I'm using LVM for /root swap and other partitions.

  ===
  The current behaviour is:

  When I boot short after the Grub login screen I'm getting log messages
  like:

  ---
  Scanning for Btrfs filesystems
  resume: Could not state the resume device file: '/dev/mapper/VolGroup'
  Please type in the full path...
  ---

  Then I press ENTER, for a few minutes some errors about floppy device
  access are raised (for some reason it tries to scan fd0 when floppy
  drive is empty). And then:

  ---
  Gave up waiting for root device. Common problems: ...
  ...
  ALERT! UUID=xxx-xxx does not exist.
  Dropping to a shell.
  ---

  From the BusyBox shell I managed to recover the boot by issuing "lvm
  vgchange -ay", then exit and then boot continues fine (all LVM file
  systems are successfully mounted).

  ===
  One workaround so far is creating 
/etc/initramfs-tools/scripts/local-top/lvm2-manual script doing "lvm vgchange 
-ay". But I'm looking for cleaner solution.

  Boot used to work fine with 15.10. Actually the first boot after
  upgrading to Xenial actually worked OK too, I'm not sure what might
  changed meanwhile (I've been fixing some packages installation since
  mysql server upgrade has failed).

  ===
  # lsb_release -rd
  Description:  Ubuntu 16.04 LTS
  Release:  16.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1573982/+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 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)

[Andres Rodriguez]

I've verified these two manually! Thanks for all the work!

** Tags removed: verification-needed verification-needed-xenial
** Tags added: verification-done verification-done-xenial

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

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

Status in MAAS:
  Fix Committed
Status in resolvconf package in Ubuntu:
  Won't Fix
Status in resolvconf source package in Xenial:
  Fix Committed

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

  Thus dns resolution does not work. Of most interest was the MAAS use
  case of the 'root=http://<>/squashfs' use case.  MAAS 2.3 uses this for
  the installation environment and also the rescue environment.

  [Test Case]
  There are two tests for this.

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

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

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

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

  b.) this is not a container.

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

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

  [Other Info]

  === End SRU Template ===

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

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

  ubuntu@manual:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback

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

  Which correctly includes the DNS server. However:

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

  If restart the interfacE:

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

  Listening on LPF/ens3/52:54:00:ea:57:31
  Sending on   LPF/ens3/52:54:00:ea:57:31
  Sending on   Socket/fallback
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
  DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 
(xid=0x5403eb14)
  DHCPOFFER of 192.168.122.195 from 192.168.122.2
  DHCPACK of 192.168.122.195 from 192.168.122.2
  Restarting ntp (via systemctl): ntp.service.
  bound to 192.168.122.195 -- renewal in 290 seconds.

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

  ubuntu@manual:~$ ping google.com
  PING 

[Touch-packages] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)

[Andres Rodriguez]

Also, I've tested this in GMAAS and confirm the fix works!

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

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

Status in MAAS:
  Fix Committed
Status in resolvconf package in Ubuntu:
  Won't Fix
Status in resolvconf source package in Xenial:
  Confirmed

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

  Thus dns resolution does not work. Of most interest was the MAAS use
  case of the 'root=http://<>/squashfs' use case.  MAAS 2.3 uses this for
  the installation environment and also the rescue environment.

  [Test Case]
  There are two tests for this.

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

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

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

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

  b.) this is not a container.

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

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

  [Other Info]

  === End SRU Template ===

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

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

  ubuntu@manual:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback

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

  Which correctly includes the DNS server. However:

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

  If restart the interfacE:

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

  Listening on LPF/ens3/52:54:00:ea:57:31
  Sending on   LPF/ens3/52:54:00:ea:57:31
  Sending on   Socket/fallback
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
  DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 
(xid=0x5403eb14)
  DHCPOFFER of 192.168.122.195 from 192.168.122.2
  DHCPACK of 192.168.122.195 from 192.168.122.2
  Restarting ntp (via systemctl): ntp.service.
  bound to 192.168.122.195 -- renewal in 290 seconds.

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

  ubuntu@manual:~$ ping google.com
  PING google.com (216.58.192.46) 56(84) bytes of data.
  64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 

[Touch-packages] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)

[Andres Rodriguez]

Bumping this to critical provided that at this point, this completely
breaks MAAS.

** Changed in: resolvconf (Ubuntu Xenial)
   Importance: Medium => Critical

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

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

Status in MAAS:
  Fix Committed
Status in resolvconf package in Ubuntu:
  Won't Fix
Status in resolvconf source package in Xenial:
  Confirmed

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

  Thus dns resolution does not work. Of most interest was the MAAS use
  case of the 'root=http://<>/squashfs' use case.  MAAS 2.3 uses this for
  the installation environment and also the rescue environment.

  [Test Case]
  There are two tests for this.

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

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

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

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

  b.) this is not a container.

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

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

  [Other Info]

  === End SRU Template ===

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

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

  ubuntu@manual:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback

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

  Which correctly includes the DNS server. However:

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

  If restart the interfacE:

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

  Listening on LPF/ens3/52:54:00:ea:57:31
  Sending on   LPF/ens3/52:54:00:ea:57:31
  Sending on   Socket/fallback
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
  DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 
(xid=0x5403eb14)
  DHCPOFFER of 192.168.122.195 from 192.168.122.2
  DHCPACK of 192.168.122.195 from 192.168.122.2
  Restarting ntp (via systemctl): ntp.service.
  bound to 192.168.122.195 -- renewal in 290 seconds.

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

  ubuntu@manual:~$ ping google.com
  PING google.com (216.58.192.46) 

[Touch-packages] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)

[Andres Rodriguez]

@Mark,

I do have access (just tested). I'll give it a try tomorrow! Thanks!

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

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

Status in MAAS:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in resolvconf package in Ubuntu:
  In Progress

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

  Thus dns resolution does not work. Of most interest was the MAAS use
  case of the 'root=http://<>/squashfs' use case.  MAAS 2.3 uses this for
  the installation environment and also the rescue environment.

  [Test Case]
  There are two tests for this.

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

  b.) MAAS test.
  For the full maas test, you need to build a image stream for maas
  with the fix included in the squashfs image and then import that
  stream to maas and use the rescue environment and verify dns.
  This process is beyond the scope of the SRU template, but is
  described partially in 

http://bazaar.launchpad.net/~maas-images-maintainers/maas-images/maas-ephemerals/view/head:/README

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

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

  b.) this is not a container.

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

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

  [Other Info]
   
  === End SRU Template ===

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

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

  ubuntu@manual:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback

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

  Which correctly includes the DNS server. However:

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

  If restart the interfacE:

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

  Listening on LPF/ens3/52:54:00:ea:57:31
  Sending on   LPF/ens3/52:54:00:ea:57:31
  Sending on   Socket/fallback
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
  DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 
(xid=0x5403eb14)
  DHCPOFFER of 192.168.122.195 from 192.168.122.2
  DHCPACK of 192.168.122.195 from 192.168.122.2
  Restarting ntp (via systemctl): ntp.service.
  bound to 192.168.122.195 -- renewal in 290 seconds.

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

  ubuntu@manual:~$ ping google.com
  PING google.com (216.58.192.46) 56(84) bytes of data.
  64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): 

[Touch-packages] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)

[Andres Rodriguez]

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

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

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

Status in MAAS:
  Fix Released
Status in cloud-init package in Ubuntu:
  Confirmed
Status in resolvconf package in Ubuntu:
  In Progress

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

  Thus dns resolution does not work. Of most interest was the MAAS use
  case of the 'root=http://<>/squashfs' use case.  MAAS 2.3 uses this for
  the installation environment and also the rescue environment.

  [Test Case]
  There are two tests for this.

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

  b.) MAAS test.
  For the full maas test, you need to build a image stream for maas
  with the fix included in the squashfs image and then import that
  stream to maas and use the rescue environment and verify dns.
  This process is beyond the scope of the SRU template, but is
  described partially in 

http://bazaar.launchpad.net/~maas-images-maintainers/maas-images/maas-ephemerals/view/head:/README

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

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

  b.) this is not a container.

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

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

  [Other Info]
   
  === End SRU Template ===

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

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

  ubuntu@manual:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback

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

  Which correctly includes the DNS server. However:

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

  If restart the interfacE:

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

  Listening on LPF/ens3/52:54:00:ea:57:31
  Sending on   LPF/ens3/52:54:00:ea:57:31
  Sending on   Socket/fallback
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
  DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 
(xid=0x5403eb14)
  DHCPOFFER of 192.168.122.195 from 192.168.122.2
  DHCPACK of 192.168.122.195 from 192.168.122.2
  Restarting ntp (via systemctl): ntp.service.
  bound to 192.168.122.195 -- renewal in 290 seconds.

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

  ubuntu@manual:~$ ping google.com
  PING google.com (216.58.192.46) 56(84) bytes of data.
  64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 

[Touch-packages] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)

[Andres Rodriguez]

** Changed in: maas
 Assignee: (unassigned) => Andres Rodriguez (andreserl)

** Changed in: maas
   Status: Confirmed => In Progress

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

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

Status in MAAS:
  In Progress
Status in cloud-init package in Ubuntu:
  Confirmed
Status in resolvconf package in Ubuntu:
  In Progress

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

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

  ubuntu@manual:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback

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

  Which correctly includes the DNS server. However:

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

  If restart the interfacE:

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

  Listening on LPF/ens3/52:54:00:ea:57:31
  Sending on   LPF/ens3/52:54:00:ea:57:31
  Sending on   Socket/fallback
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
  DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 
(xid=0x5403eb14)
  DHCPOFFER of 192.168.122.195 from 192.168.122.2
  DHCPACK of 192.168.122.195 from 192.168.122.2
  Restarting ntp (via systemctl): ntp.service.
  bound to 192.168.122.195 -- renewal in 290 seconds.

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

  ubuntu@manual:~$ ping google.com
  PING google.com (216.58.192.46) 56(84) bytes of data.
  64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 
time=7.47 ms
  ^C
  --- google.com ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms

  As such, this either seems like a bug in Ubuntu, or caused by cloud-
  init when writing e/n/i.d/50-cloud-init.cfg

  ubuntu@manual:~$ dpkg -l | grep cloud-init
  ii  cloud-init   0.7.9-153-g16a7302f-0ubuntu1~16.04.2 
  all  Init scripts for cloud instances
  ii  cloud-initramfs-copymods 0.27ubuntu1.4
  all  copy initramfs modules into root filesystem for later use
  ii  cloud-initramfs-dyn-netconf  0.27ubuntu1.4
  all  write a network interface file in /run for BOOTIF

  ubuntu@manual:~$ uname -a
  Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux
  ubuntu@manual:~$ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 16.04.3 LTS
  Release:16.04
  Codename:   xenial

  ubuntu@manual:~$ pastebinit /var/log/cloud-init.log
  http://paste.ubuntu.com/25342738/
  ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log
  http://paste.ubuntu.com/25342740/

  Related bugs:
   * bug 1714308: dns does not work in initramfs after configure_networking
   * bug 1713803: replacement of resolvconf with systemd needs integration

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1711760/+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 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)

[Andres Rodriguez]

** Changed in: maas
Milestone: 2.3.0 => 2.3.0beta2

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

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

Status in MAAS:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in resolvconf package in Ubuntu:
  In Progress

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

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

  ubuntu@manual:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback

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

  Which correctly includes the DNS server. However:

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

  If restart the interfacE:

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

  Listening on LPF/ens3/52:54:00:ea:57:31
  Sending on   LPF/ens3/52:54:00:ea:57:31
  Sending on   Socket/fallback
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
  DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 
(xid=0x5403eb14)
  DHCPOFFER of 192.168.122.195 from 192.168.122.2
  DHCPACK of 192.168.122.195 from 192.168.122.2
  Restarting ntp (via systemctl): ntp.service.
  bound to 192.168.122.195 -- renewal in 290 seconds.

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

  ubuntu@manual:~$ ping google.com
  PING google.com (216.58.192.46) 56(84) bytes of data.
  64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 
time=7.47 ms
  ^C
  --- google.com ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms

  As such, this either seems like a bug in Ubuntu, or caused by cloud-
  init when writing e/n/i.d/50-cloud-init.cfg

  ubuntu@manual:~$ dpkg -l | grep cloud-init
  ii  cloud-init   0.7.9-153-g16a7302f-0ubuntu1~16.04.2 
  all  Init scripts for cloud instances
  ii  cloud-initramfs-copymods 0.27ubuntu1.4
  all  copy initramfs modules into root filesystem for later use
  ii  cloud-initramfs-dyn-netconf  0.27ubuntu1.4
  all  write a network interface file in /run for BOOTIF

  ubuntu@manual:~$ uname -a
  Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux
  ubuntu@manual:~$ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 16.04.3 LTS
  Release:16.04
  Codename:   xenial

  ubuntu@manual:~$ pastebinit /var/log/cloud-init.log
  http://paste.ubuntu.com/25342738/
  ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log
  http://paste.ubuntu.com/25342740/

  Related bugs:
   * bug 1714308: dns does not work in initramfs after configure_networking
   * bug 1713803: replacement of resolvconf with systemd needs integration

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1711760/+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 1711760] [NEW] [2.3] resolv.conf is not set (during commissioning)

[Andres Rodriguez]

Public bug reported:

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

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

ubuntu@manual:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback

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

Which correctly includes the DNS server. However:

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

If restart the interfacE:

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

Listening on LPF/ens3/52:54:00:ea:57:31
Sending on   LPF/ens3/52:54:00:ea:57:31
Sending on   Socket/fallback
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
DHCPREQUEST of 192.168.122.195 on ens3 to 255.255.255.255 port 67 
(xid=0x5403eb14)
DHCPOFFER of 192.168.122.195 from 192.168.122.2
DHCPACK of 192.168.122.195 from 192.168.122.2
Restarting ntp (via systemctl): ntp.service.
bound to 192.168.122.195 -- renewal in 290 seconds.

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

ubuntu@manual:~$ ping google.com
PING google.com (216.58.192.46) 56(84) bytes of data.
64 bytes from mia07s46-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=52 
time=7.47 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.472/7.472/7.472/0.000 ms

As such, this either seems like a bug in Ubuntu, or caused by cloud-init
when writing e/n/i.d/50-cloud-init.cfg

ubuntu@manual:~$ dpkg -l | grep cloud-init
ii  cloud-init   0.7.9-153-g16a7302f-0ubuntu1~16.04.2   
all  Init scripts for cloud instances
ii  cloud-initramfs-copymods 0.27ubuntu1.4  
all  copy initramfs modules into root filesystem for later use
ii  cloud-initramfs-dyn-netconf  0.27ubuntu1.4  
all  write a network interface file in /run for BOOTIF

ubuntu@manual:~$ uname -a
Linux manual 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux
ubuntu@manual:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.3 LTS
Release:16.04
Codename:   xenial

ubuntu@manual:~$ pastebinit /var/log/cloud-init.log 
http://paste.ubuntu.com/25342738/
ubuntu@manual:~$ pastebinit /var/log/cloud-init-output.log 
http://paste.ubuntu.com/25342740/

** Affects: maas
 Importance: Undecided
 Status: New

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

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

** Description changed:

  Using MAAS 2.3, during commissioning (and likely in the rest of the
  ephemeral environment) we have noticed that resolv.conf is not set with
  the DNS server.
  
  That said, during the commissioning process, MAAS does not send any
  metadata to cloud-init to configure the network, rather, we expect the
  image to boot from the network via DHCP. So, cloud-init writes:
  
- ubuntu@manual:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg 
+ ubuntu@manual:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback
  
  # control-manual ens3
  iface ens3 inet dhcp
- broadcast 192.168.122.255
- dns-nameservers 192.168.122.2
- gateway 192.168.122.1
- netmask 255.255.255.0
+ broadcast 192.168.122.255
+ dns-nameservers 192.168.122.2
+ gateway 192.168.122.1
+ netmask 255.255.255.0
  
  Which correctly includes the DNS server. However:
  
  ubuntu@manual:~$ ping 

[Touch-packages] [Bug 1597909] Re: systemd-timesyncd unit still running after installation of ntp package

[Andres Rodriguez]

FWIW, this issue is still present in older releases. Effectively, if NTP
is installed and configured to access X ntp server and timesyncd would
still try to fallback to ntp.ubuntu.com.

In proxied environments, this will result in ntp.ubuntu.com being
unavailable.

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

** Also affects: ntp (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

Title:
  systemd-timesyncd unit still running after installation of ntp package

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Xenial:
  Incomplete
Status in ntp source package in Zesty:
  Incomplete

Bug description:
  I recently installed the ntp package on a fairly vanilla installed-
  from-DVD Xenial system, and noticed that after the package
  installation both systemd-timesyncd and ntp were running:

  # systemctl status ntp systemd-timesyncd.service --no-pager
   ntp.service - LSB: Start NTP daemon
 Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled)
 Active: active (running) since Tue 2016-06-28 19:21:16 HDT; 6min ago
   Docs: man:systemd-sysv-generator(8)
 CGroup: /system.slice/ntp.service
 3364 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 112:118

  [...log lines...]

   systemd-timesyncd.service - Network Time Synchronization
 Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; 
vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
 `-disable-with-time-daemon.conf
 Active: active (running) since Sun 2016-06-26 06:53:05 HDT; 2 days ago
   Docs: man:systemd-timesyncd.service(8)
   Main PID: 821 (systemd-timesyn)
 Status: "Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com)."
 CGroup: /system.slice/systemd-timesyncd.service
 821 /lib/systemd/systemd-timesyncd

  [...log lines...]

  I was able to do "systemctl stop systemd-timesyncd.service" manually
  without any trouble, but presumably if I hadn't noticed the situation
  I might have had problems with the two services both running
  simultaneously until my next reboot.

  (Once the systemd-timesyncd service is stopped, it is prevented from
  starting again by the constraint in the disable-with-time-daemon.conf
  file.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1597909/+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 1701297] Re: NTP reload failure (unable to read library) on overlayfs

[Andres Rodriguez]

@Tyler,

The reason why this wasn't seen before is that previously in Xenial,
cloud-init did not restart 'ntp' with a new config file. Since cloud-
init recently SRU'd a fixed cloud-init that does restart 'ntp' on
overlay, the issue started to show up.

In other words, after a cloud-init bugfix , these issues started
surfacing.

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

Title:
  NTP reload failure (unable to read library) on overlayfs

Status in cloud-init:
  Incomplete
Status in apparmor package in Ubuntu:
  Confirmed
Status in cloud-init package in Ubuntu:
  Incomplete
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After update [1] of cloud-init in Ubuntu (which landed in xenial-
  updates on 2017-06-27), it is causing NTP reload failures.

  https://launchpad.net/ubuntu/+source/cloud-init/0.7.9-153-g16a7302f-
  0ubuntu1~16.04.1

  In MAAS scenarios, this is causing the machine to fail to deploy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701297/+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 1408106] Re: attach_disconnected not sufficient for overlayfs

[Andres Rodriguez]

@Frode,

Users running 2.2 *already* have the apparmor=0 work around for
*ephemeral* environments only.

For users running previous versions, we recommend you upgrade
immediately, provided that 2.0 and 2.1 are out of support. If you decide
not to upgrade, your options are:

1. Use a HWE kernel (such as hwe-16.04). 
https://bugs.launchpad.net/cloud-init/+bug/1701297/comments/21
2. Use apparmor=0 as a global/machine kernel param (this will result in the 
deployed machine with apparmor disabled)

Marking this invalid for MAAS provided the bug is overlayfs.


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

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

Title:
  attach_disconnected not sufficient for overlayfs

Status in AppArmor:
  Invalid
Status in MAAS:
  Invalid
Status in apparmor package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid

Bug description:
  With the following use of overlayfs, we get a disconnected path:

  $ cat ./profile
  #include 
  profile foo {
    #include 

    capability sys_admin,
    capability sys_chroot,
    mount,
    pivot_root,
  }

  $ cat ./overlay.c
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(int argc, char* argv[]) {
  int i = 0;
  int len = 0;
  int ret = 0;
  char* options;

  if (geteuid())
  unshare(CLONE_NEWUSER);
  unshare(CLONE_NEWNS);

  for (i = 1; i < argc; i++) {
  if (i == 1) {
  len = strlen(argv[i]) + strlen("upperdir=,lowerdir=/") + 2;
  options = alloca(len);
  ret = snprintf(options, len, "upperdir=%s,lowerdir=/", argv[i]);
  }
  else {
  len = strlen(argv[i]) + strlen("upperdir=,lowerdir=/mnt") + 2;
  options = alloca(len);
  ret = snprintf(options, len, "upperdir=%s,lowerdir=/mnt", 
argv[i]);
  }

  mount("overlayfs", "/mnt", "overlayfs", MS_MGC_VAL, options);
  }

  chdir("/mnt");
  pivot_root(".", ".");
  chroot(".");

  chdir("/");
  execl("/bin/bash", "/bin/bash", NULL);
  }

  $ sudo apparmor_parser -r ./profile && aa-exec -p foo -- ./a.out /tmp
  [255]
  ...
  Dec 12 14:31:38 localhost kernel: [57278.040216] audit: type=1400 
audit(1418387498.613:712): apparmor="DENIED" operation="exec" info="Failed name 
lookup - disconnected path" error=-13 profile="foo" name="/bin/bash" pid=18255 
comm="a.out" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

  With the above, the expectation was for the denial to be /mnt/bin/bash. There 
are three ways forward:
  1. the correct solution is to patch overlayfs to properly track the loopback, 
but this will take a while, may ultimately be unachievable. UPDATE: upstream is 
currently working on this and Ubuntu will engage with them
  2. we could rely on the fact that overlayfs creates a private unshared 
submount, and provide a way to not mediate the path when that is present, and 
tagged. This would take a bit of time, and might be the preferred method over 1 
longer term
  3. we could extend attach_disconnected so that we can define the attach root. 
Eg, we can use profile foo (attach_disconnected=/mnt) {} such that '/bin/bash' 
maps to '/mnt/bin/bash'. UPDATE: THIS IS NOT VIABLE

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1408106/+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 1701297] Re: NTP reload failure (unable to read library) on overlayfs

[Andres Rodriguez]

When using the following kernel (the default Xenial kernel, aka ga-16.04
in MAAS), we see this issue:

4.4.0-83-generic #106-Ubuntu SMP Mon Jun 26 17:54:43 UTC 2017 x86_64
x86_64 x86_64 GNU/Linux

When using the HWE kernel (aka hwe-16.04 in MAAS), we do NOT see this
issue:

4.8.0-58-generic #63~16.04.1-Ubuntu SMP Mon Jun 26 18:08:51 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux

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

Title:
  NTP reload failure (unable to read library) on overlayfs

Status in cloud-init:
  Incomplete
Status in apparmor package in Ubuntu:
  Confirmed
Status in cloud-init package in Ubuntu:
  Incomplete
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After update [1] of cloud-init in Ubuntu (which landed in xenial-
  updates on 2017-06-27), it is causing NTP reload failures.

  https://launchpad.net/ubuntu/+source/cloud-init/0.7.9-153-g16a7302f-
  0ubuntu1~16.04.1

  In MAAS scenarios, this is causing the machine to fail to deploy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701297/+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 1701297] Re: NTP reload failure (unable to read library) on overlayfs

[Andres Rodriguez]

@Tyler,

That's is correct, MAAS 2.2.0+ sends the apparmor=0 for the ephemeral
environments.

That said, however, this affects else who is not using 2.2 (which in
fact, affects customers who are still in 2.1). Also, based on my
testing, it seems that when using hwe-16.04 kernel this doesn't happen,
but it does with the ga-16.04 kernel.

** Summary changed:

- NTP reload failure (causing deployment failures with MAAS)
+ NTP reload failure (unable to read library) on overlayfs

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

Title:
  NTP reload failure (unable to read library) on overlayfs

Status in cloud-init:
  Incomplete
Status in apparmor package in Ubuntu:
  Confirmed
Status in cloud-init package in Ubuntu:
  Incomplete
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After update [1] of cloud-init in Ubuntu (which landed in xenial-
  updates on 2017-06-27), it is causing NTP reload failures.

  https://launchpad.net/ubuntu/+source/cloud-init/0.7.9-153-g16a7302f-
  0ubuntu1~16.04.1

  In MAAS scenarios, this is causing the machine to fail to deploy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701297/+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 1701297] Re: NTP reload failure (causing deployment failures with MAAS)

[Andres Rodriguez]

It seems that this only happens when using ga-16.04 and doesn't when
using hwe-16.04

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

Title:
  NTP reload failure (causing deployment failures with MAAS)

Status in cloud-init:
  Incomplete
Status in apparmor package in Ubuntu:
  Confirmed
Status in cloud-init package in Ubuntu:
  Incomplete
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After update [1] of cloud-init in Ubuntu (which landed in xenial-
  updates on 2017-06-27), it is causing NTP reload failures.

  https://launchpad.net/ubuntu/+source/cloud-init/0.7.9-153-g16a7302f-
  0ubuntu1~16.04.1

  In MAAS scenarios, this is causing the machine to fail to deploy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701297/+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 1701297] Re: NTP reload failure (causing deployment failures with MAAS)

[Andres Rodriguez]

** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu)
   Importance: Undecided => Critical

** Also affects: apparmor (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: apparmor (Ubuntu)
   Importance: Undecided => Critical

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

Title:
  NTP reload failure (causing deployment failures with MAAS)

Status in cloud-init:
  Incomplete
Status in apparmor package in Ubuntu:
  Confirmed
Status in cloud-init package in Ubuntu:
  Incomplete
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After update [1] of cloud-init in Ubuntu (which landed in xenial-
  updates on 2017-06-27), it is causing NTP reload failures.

  https://launchpad.net/ubuntu/+source/cloud-init/0.7.9-153-g16a7302f-
  0ubuntu1~16.04.1

  In MAAS scenarios, this is causing the machine to fail to deploy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701297/+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 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[Andres Rodriguez]

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

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

Title:
  initramfs-tools configure_networking() fails to dhcp ipv6 addresses

Status in MAAS:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in klibc package in Ubuntu:
  Won't Fix
Status in open-iscsi package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Xenial:
  Fix Released
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in klibc source package in Xenial:
  Won't Fix
Status in open-iscsi source package in Xenial:
  Fix Released
Status in initramfs-tools source package in Yakkety:
  Fix Released
Status in isc-dhcp source package in Yakkety:
  Fix Released
Status in klibc source package in Yakkety:
  Won't Fix
Status in open-iscsi source package in Yakkety:
  Fix Released
Status in klibc package in Debian:
  New

Bug description:
  initramfs' configure_networking function uses ipconfig to configure the 
network.
  ipconfig does not support dhcpv6.  See: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627164

  Related bugs:
    * bug 1229458: grub2 needed changes
    * bug 1621615: network not configured when ipv6 netbooted into cloud-init
    * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6)

  Bugs related to uploads for this specific SRU:

  cloud-init:
  bug 1460715: different fix unrelated to this SRU
  bug 1639930: ip6= on kernel command line
  bug 1642679: different fix unrelated to this SRU
  bug 1644043: different fix unrelated to this SRU

  ifupdown:
  bug 1629972: networking.service takes down lo on stop

  initramfs-tools:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1628306: regression-update (failure when ip="")
  bug 1631474: regression-update (failure when ip=:eth0:dhcp)

  isc-dhcp:
  bug 1621507: no IPv6 DHCP support in early boot
  bug 1633479: dhclient does not wait for IPv6 DAD

  open-iscsi:
  bug 1621507: no IPv6 DHCP support in early boot

  [Impact]

  It is not possible to netboot Ubuntu with a network-based root
  filesystem in an ipv6-only environment.  Anyone wanting to netboot in
  an ipv6-only environment is affected.

  [Stable Fix]

  These uploads add "ip6=" to the command line syntax to configure ipv6
  using the defacto isc-dhcp-client.  IPv4 configuration (and "ip="
  syntax) remain unchanged.

  Valid format for the ip6= command line option is:
     ip6=none (or ip6=off or ip6=) -- do not configure ipv6
     ip6=DEVICE  -- run IPv6 dhclient on device DEVICE.

  [Test Case]

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

  [Regression Potential]

  1) This increases the uncompressed initramfs size by approximately 500KB, 
since isc-dhcp-client is added, but klibc is still needed for some other 
things, and is therefore present.  On systems with a very small /boot 
partition, this could result in failure to upgrade the initramfs.
  2) In at least some cases, DHCP network configuration shifts from klibc's 
ipconfig to isc-dhcp-client's dhclient.  This should be of minimal risk, as 
isc-dhcp-client is in very very widespread use.  In the event of a regression, 
network boot would fail, but the prior kernel should still be bootable.

  [Tests for verification]

  Whoever checks the last one off, please mark verification done.

  MAAS test cases:
   X / Y
  [+]/[+] MAAS on IPv6-only network
  [+]/[+] MAAS on IPv4-only network
  [+]/[+] MAAS booting IPv4 on dual-stack network (with and without dhcp6)
  [+]/[+] MAAS booting IPv6 on dual-stack network (with and without dhcp4)

  Non-MAAS test cases:
   X / Y
  [+]/[+] ip="" and ip6 not present
  [+]/[+] ip=:eth0:dhcp and ip6 not present
  [+]/[+] d-i install with iSCSI remote root should complete normally
  [+]/[+] Validate normal boot without remote root
  [+]/[+] Booting an iSCSI remote root via IPv4 (using ip=)
  [+]/[+] Booting an iSCSI remote root via IPv6 (using ip6=)
  [+]/[+] Booting an iSCSI remote root via IPv4 (no ip=, d-i use case)
  [+]/[+] Booting an iSCSI remote root with BOOTIF specified (BOOTIF=mac of 
booting device)52-54-00-53-5d-24
  [+]/[+] Booting an iSCSI remote root on mixed network with no options (IPv4 
should be used only)

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1621507/+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 1640147] Re: [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE" on commissioning

[Andres Rodriguez]

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

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

Title:
  [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE"
  on commissioning

Status in MAAS:
  Fix Released
Status in MAAS 2.1 series:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Invalid

Bug description:
  When commissioning, /var/log/maas/rsyslog/ is flooded with the
  repeated messages below with over 30,000 lines.

  
  Nov  8 11:57:54 bunyip dhclient[4734]: no link-local IPv6 address for enp4s0f0
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: If you think you have received this 
message due to a bug rather
  Nov  8 11:57:54 bunyip dhclient[4734]: than a configuration issue please read 
the section on submitting
  Nov  8 11:57:54 bunyip dhclient[4734]: bugs on either our web page at 
www.isc.org or in the README file
  Nov  8 11:57:54 bunyip dhclient[4734]: before submitting a bug.  These pages 
explain the proper
  Nov  8 11:57:54 bunyip dhclient[4734]: process and the information we find 
helpful for debugging..
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: exiting.
  

  $ wc -l /var/log/maas/rsyslog/bunyip/2016-11-08/messages
  39278 /var/log/maas/rsyslog/bunyip/2016-11-08/messages

  It would be nice to suppress those lines if those could be safely
  ignored. It would make troubleshooting easier when something wrong
  happened on commissioning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1640147/+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 1640147] Re: [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE" on commissioning

[Andres Rodriguez]

** Changed in: maas/2.1
   Status: Fix Committed => Fix Released

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

Title:
  [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE"
  on commissioning

Status in MAAS:
  Fix Committed
Status in MAAS 2.1 series:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Invalid

Bug description:
  When commissioning, /var/log/maas/rsyslog/ is flooded with the
  repeated messages below with over 30,000 lines.

  
  Nov  8 11:57:54 bunyip dhclient[4734]: no link-local IPv6 address for enp4s0f0
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: If you think you have received this 
message due to a bug rather
  Nov  8 11:57:54 bunyip dhclient[4734]: than a configuration issue please read 
the section on submitting
  Nov  8 11:57:54 bunyip dhclient[4734]: bugs on either our web page at 
www.isc.org or in the README file
  Nov  8 11:57:54 bunyip dhclient[4734]: before submitting a bug.  These pages 
explain the proper
  Nov  8 11:57:54 bunyip dhclient[4734]: process and the information we find 
helpful for debugging..
  Nov  8 11:57:54 bunyip dhclient[4734]: 
  Nov  8 11:57:54 bunyip dhclient[4734]: exiting.
  

  $ wc -l /var/log/maas/rsyslog/bunyip/2016-11-08/messages
  39278 /var/log/maas/rsyslog/bunyip/2016-11-08/messages

  It would be nice to suppress those lines if those could be safely
  ignored. It would make troubleshooting easier when something wrong
  happened on commissioning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1640147/+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 1664748] Re: wifi connection drops, reconnects every 10 minutes

[Andres Rodriguez]

>From the ML

lease {
  interface "enp0s25";
  fixed-address 10.1.8.227;
  option subnet-mask 255.255.255.0;
  option dhcp-lease-time 2592000;
  option routers 10.1.8.1;
  option dhcp-message-type 5;
  option dhcp-server-identifier 10.1.8.1;
  option domain-name-servers 8.8.8.8,8.8.4.4;
  option broadcast-address 10.1.8.255;
  option domain-name "medusa.mezzonet.net";
  renew 5 2017/02/10 09:51:53;
  rebind 4 2017/02/23 03:18:17;
  expire 0 2017/02/26 21:18:17;
}
lease {
  interface "enp0s25";
  fixed-address 10.0.0.112;
  filename "pxelinux.0";
  option subnet-mask 255.255.255.0;
  option routers 10.0.0.1;
  option dhcp-lease-time 600;
  option dhcp-message-type 5;
  option domain-name-servers 10.0.0.3,10.0.0.1;
  option dhcp-server-identifier 10.0.0.3;
  option ntp-servers 10.0.0.3;
  option broadcast-address 10.0.0.255;
  option domain-name "maas";
  renew 2 2017/02/14 23:33:53;
  rebind 2 2017/02/14 23:38:13;
  expire 2 2017/02/14 23:39:28;
}
lease {
  interface "enp0s25";
  fixed-address 10.0.0.112;
  filename "pxelinux.0";
  option subnet-mask 255.255.255.0;
  option routers 10.0.0.1;
  option dhcp-lease-time 600;
  option dhcp-message-type 5;
  option domain-name-servers 10.0.0.3,10.0.0.1;
  option dhcp-server-identifier 10.0.0.3;
  option ntp-servers 10.0.0.3;
  option broadcast-address 10.0.0.255;
  option domain-name "maas";
  renew 2 2017/02/14 23:38:02;
  rebind 2 2017/02/14 23:42:39;
  expire 2 2017/02/14 23:43:54;
}
lease {
  interface "enp0s25";
  fixed-address 10.0.0.112;
  filename "pxelinux.0";
  option subnet-mask 255.255.255.0;
  option routers 10.0.0.1;
  option dhcp-lease-time 600;
  option dhcp-message-type 5;
  option domain-name-servers 10.0.0.3,10.0.0.1;
  option dhcp-server-identifier 10.0.0.3;
  option ntp-servers 10.0.0.3;
  option broadcast-address 10.0.0.255;
  option domain-name "maas";
  renew 2 2017/02/14 23:41:55;
  rebind 2 2017/02/14 23:46:47;
  expire 2 2017/02/14 23:48:02;
}
lease {
  interface "enp0s25";
  fixed-address 10.0.0.112;
  filename "pxelinux.0";
  option subnet-mask 255.255.255.0;
  option routers 10.0.0.1;
  option dhcp-lease-time 600;
  option dhcp-message-type 5;
  option domain-name-servers 10.0.0.3,10.0.0.1;
  option dhcp-server-identifier 10.0.0.3;
  option ntp-servers 10.0.0.3;
  option broadcast-address 10.0.0.255;
  option domain-name "maas";
  renew 2 2017/02/14 23:46:17;
  rebind 2 2017/02/14 23:50:40;
  expire 2 2017/02/14 23:51:55;
}
lease {
  interface "wlp3s0";
  fixed-address 10.0.0.46;
  filename "pxelinux.0";
  option subnet-mask 255.255.255.0;
  option dhcp-lease-time 600;
  option routers 10.0.0.1;
  option dhcp-message-type 5;
  option dhcp-server-identifier 10.0.0.3;
  option domain-name-servers 10.0.0.3,10.0.0.1;
  option broadcast-address 10.0.0.255;
  option ntp-servers 10.0.0.3;
  option domain-name "maas";
  renew 2 2017/02/14 23:30:52;
  rebind 2 2017/02/14 23:35:43;
  expire 2 2017/02/14 23:36:58;
}
lease {
  interface "wlp3s0";
  fixed-address 10.0.0.46;
  filename "pxelinux.0";
  option subnet-mask 255.255.255.0;
  option routers 10.0.0.1;
  option dhcp-lease-time 600;
  option dhcp-message-type 5;
  option domain-name-servers 10.0.0.3,10.0.0.1;
  option dhcp-server-identifier 10.0.0.3;
  option ntp-servers 10.0.0.3;
  option broadcast-address 10.0.0.255;
  option domain-name "maas";
  renew 2 2017/02/14 23:41:27;
  rebind 2 2017/02/14 23:45:48;
  expire 2 2017/02/14 23:47:03;
}

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

Title:
  wifi connection drops, reconnects every 10 minutes

Status in maas package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  I recently moved my home DHCP and DNS server over to MAAS (2.1.3 from
  xenial-updates).

  Since doing so, I've noticed that my wifi connection drops and
  reconnects (with corresponding Unity pop-up notifications) exactly
  every 10 minutes.

  I suppose this is due to the fact that MAAS sets DHCP leases to 10
  minutes by default?

  Has anyone else noticed this behavior?

  Is there a suitable workaround?  Increasing the DHCP lease time?
  Using static addresses?  Something else?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1664748/+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 1664748] Re: wifi connection drops, reconnects every 10 minutes

[Andres Rodriguez]

cat $(ps auxw | grep dhclient | grep -o '\-lf.*' | awk '{ print $2 }')

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

Title:
  wifi connection drops, reconnects every 10 minutes

Status in maas package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  I recently moved my home DHCP and DNS server over to MAAS (2.1.3 from
  xenial-updates).

  Since doing so, I've noticed that my wifi connection drops and
  reconnects (with corresponding Unity pop-up notifications) exactly
  every 10 minutes.

  I suppose this is due to the fact that MAAS sets DHCP leases to 10
  minutes by default?

  Has anyone else noticed this behavior?

  Is there a suitable workaround?  Increasing the DHCP lease time?
  Using static addresses?  Something else?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1664748/+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 1664748] Re: wifi connection drops, reconnects every 10 minutes

[Andres Rodriguez]

@ Dustin,

Can you attach your dhcpd.conf or at least the relevant sections to see
how this hostmap was configured  ?

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

Title:
  wifi connection drops, reconnects every 10 minutes

Status in maas package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  I recently moved my home DHCP and DNS server over to MAAS (2.1.3 from
  xenial-updates).

  Since doing so, I've noticed that my wifi connection drops and
  reconnects (with corresponding Unity pop-up notifications) exactly
  every 10 minutes.

  I suppose this is due to the fact that MAAS sets DHCP leases to 10
  minutes by default?

  Has anyone else noticed this behavior?

  Is there a suitable workaround?  Increasing the DHCP lease time?
  Using static addresses?  Something else?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1664748/+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 1355813] Re: Interface MTU management across MAAS/juju

[Andres Rodriguez]

** Changed in: maas
   Status: Triaged => Fix Released

** Changed in: maas
Milestone: next => None

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

Title:
  Interface MTU management across MAAS/juju

Status in juju-core:
  Fix Released
Status in MAAS:
  Fix Released
Status in juju-core package in Ubuntu:
  Fix Released
Status in lxc package in Ubuntu:
  Invalid

Bug description:
  Context:

  juju + MAAS deployed OpenStack environment, misc services deployed
  under LXC on the bootstrap node, interfaces configured for jumbo
  frames - note that I had to manually set the LXC container interfaces
  to mtu 9000 before the bridge would do the same.

  Action:

  Reboot one of the containers; MTU on br0 resets from 9000 -> 1500.

  This feels like more of a 'we need a better way to orchestrate MTU
  configuration across different services' so raising tasks for MAAS and
  Juju as well.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: lxc 1.0.5-0ubuntu0.1
  ProcVersionSignature: User Name 3.13.0-24.47-generic 3.13.9
  Uname: Linux 3.13.0-24-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.3
  Architecture: amd64
  Date: Tue Aug 12 13:26:00 2014
  KernLog:

  SourcePackage: lxc
  UpgradeStatus: No upgrade log present (probably fresh install)
  defaults.conf:
   lxc.network.type = veth
   lxc.network.link = lxcbr0
   lxc.network.flags = up
   lxc.network.hwaddr = 00:16:3e:xx:xx:xx
  lxcsyslog:

To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-core/+bug/1355813/+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 1629972] Re: networking stop incorrectly disconnects from (network) root filesystem

[Andres Rodriguez]

** Changed in: maas
Milestone: 2.1.2 => 2.1.3

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

Title:
  networking stop incorrectly disconnects from (network) root filesystem

Status in MAAS:
  Triaged
Status in ifupdown package in Ubuntu:
  Fix Released
Status in ifupdown source package in Xenial:
  Confirmed
Status in ifupdown source package in Yakkety:
  Fix Committed
Status in ifupdown package in Debian:
  New

Bug description:
  With the switch to systemd, all support for iscsi root (and other)
  filesystems disappeared, since shutdown yanks the rug out from under
  us.

  Rather than just relying on /etc/iscsi/iscsi.initramfs (which d-i
  creates..), the DEV check should be expanded to include iscsi devices,
  and networking.service ExecStop should honor those checks.

  Related bugs:
* bug 1229458: grub2 needed changes
* bug 1621615: network not configured when ipv6 netbooted into cloud-init
* bug 1621507: ipv6 network boot does not work

  [Impact]

  With the changes from the above, the iscsi root (at least in the ipv6
  case) gets disconneceted prior to clean shutdown (ifdown downs the
  interface), resulting in a failure to enlist, commission, or deploy
  cleanly under MAAS. (and a failure to cleanly unmount the root
  filesystem when it is over iscsi.)

  [Test Case]

  Given a MAAS 2.0 installation, and the packages in the other bugs,
  attempt to enlist, commission, or deploy a host with xenial.

  [Regression potential]

  This restores the pre-xenial behavior of not shutting down the
  interface if there are network drives at the time that neworking is
  stopped (making it a no-op.)  The additional change is to detect
  "/dev/disk/by-path/*-iscsi-*" as a network disk, replacing the check
  for the existence of /etc/iscsi/iscsi.initramfs, which was only
  created by debian-installer (and maas until recently).

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1629972/+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 1629972] Re: networking stop incorrectly disconnects from (network) root filesystem

[Andres Rodriguez]

** Changed in: maas
Milestone: 2.1.0 => 2.1.1

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

Title:
  networking stop incorrectly disconnects from (network) root filesystem

Status in MAAS:
  Triaged
Status in ifupdown package in Ubuntu:
  Confirmed
Status in ifupdown source package in Xenial:
  Confirmed

Bug description:
  With the switch to systemd, all support for iscsi root (and other)
  filesystems disappeared, since shutdown yanks the rug out from under
  us.

  Rather than just relying on /etc/iscsi/iscsi.initramfs (which d-i
  creates..), the DEV check should be expanded to include iscsi devices,
  and networking.service ExecStop should honor those checks.

  Related bugs:
* bug 1229458: grub2 needed changes
* bug 1621615: network not configured when ipv6 netbooted into cloud-init
* bug 1621507: ipv6 network boot does not work

  [Impact]

  With the changes from the above, the iscsi root (at least in the ipv6
  case) gets disconneceted prior to clean shutdown (ifdown downs the
  interface), resulting in a failure to enlist, commission, or deploy
  cleanly under MAAS. (and a failure to cleanly unmount the root
  filesystem when it is over iscsi.)

  [Test Case]

  Given a MAAS 2.0 installation, and the packages in the other bugs,
  attempt to enlist, commission, or deploy a host with xenial.

  [Regression potential]

  This restores the pre-xenial behavior of not shutting down the
  interface if there are network drives at the time that neworking is
  stopped (making it a no-op.)  The additional change is to detect
  "/dev/disk/by-path/*-iscsi-*" as a network disk, replacing the check
  for the existence of /etc/iscsi/iscsi.initramfs, which was only
  created by debian-installer (and maas until recently).

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1629972/+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 1629972] Re: networking stop incorrectly disconnects from (network) root filesystem

[Andres Rodriguez]

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

** Changed in: maas
Milestone: None => 2.1.0

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

Title:
  networking stop incorrectly disconnects from (network) root filesystem

Status in MAAS:
  Triaged
Status in ifupdown package in Ubuntu:
  New
Status in ifupdown source package in Xenial:
  New

Bug description:
  With the switch to systemd, all support for iscsi root (and other)
  filesystems disappeared, since shutdown yanks the rug out from under
  us.

  Rather than just relying on /etc/iscsi/iscsi.initramfs (which d-i
  creates..), the DEV check should be expanded to include iscsi devices,
  and networking.service ExecStop should honor those checks.

  Related bugs:
* bug 1229458: grub2 needed changes
* bug 1621615: network not configured when ipv6 netbooted into cloud-init
* bug 1621507: ipv6 network boot does not work

  [Impact]

  With the changes from the above, the iscsi root (at least in the ipv6
  case) gets disconneceted prior to clean shutdown (ifdown downs the
  interface), resulting in a failure to enlist, commission, or deploy
  cleanly under MAAS. (and a failure to cleanly unmount the root
  filesystem when it is over iscsi.)

  [Test Case]

  Given a MAAS 2.0 installation, and the packages in the other bugs,
  attempt to enlist, commission, or deploy a host with xenial.

  [Regression potential]

  This restores the pre-xenial behavior of not shutting down the
  interface if there are network drives at the time that neworking is
  stopped (making it a no-op.)  The additional change is to detect
  "/dev/disk/by-path/*-iscsi-*" as a network disk, replacing the check
  for the existence of /etc/iscsi/iscsi.initramfs, which was only
  created by debian-installer (and maas until recently).

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1629972/+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 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses

[Andres Rodriguez]

** Changed in: maas
   Status: Triaged => Fix Released

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

Title:
  initramfs-tools configure_networking() fails to dhcp ipv6 addresses

Status in MAAS:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in klibc package in Ubuntu:
  Won't Fix
Status in open-iscsi package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Xenial:
  Fix Released
Status in isc-dhcp source package in Xenial:
  Fix Released
Status in klibc source package in Xenial:
  Won't Fix
Status in open-iscsi source package in Xenial:
  Fix Released
Status in klibc package in Debian:
  New

Bug description:
  initramfs' configure_networking function uses ipconfig to configure the 
network.
  ipconfig does not support dhcpv6.  See: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627164

  Related bugs:
* bug 1229458: grub2 needed changes
    * bug 1621615: network not configured when ipv6 netbooted into cloud-init

  [Impact]

  It is not possible to netboot Ubuntu with a network-based root
  filesystem in an ipv6-only environment.  Anyone wanting to netboot in
  an ipv6-only environment is affected.

  These uploads address this by replacing the one-off klibc dhcp client
  (IPv4-only) with the defacto standard isc-dhcp-client, and thereby
  provide both ipv6 and ipv4 DHCP configuration.

  [Test Case]

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

  [Regression Potential]

  1) This increases the uncompressed initramfs size by approximately 500KB, 
since isc-dhcp-client is added, but klibc is still needed for some other 
things, and is therefore present.  On systems with a very small /boot 
partition, this could result in failure to upgrade the initramfs.
  2) In at least some cases, DHCP network configuration shifts from klibc's 
ipconfig to isc-dhcp-client's dhclient.  This should be of minimal risk, as 
isc-dhcp-client is in very very widespread use.  In the event of a regression, 
network boot would fail, but the prior kernel should still be bootable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1621507/+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 1621507] Re: ipconfig lacks ipv6 support

[Andres Rodriguez]

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

** Changed in: maas
   Importance: Undecided => Critical

** Tags added: maas-ipv6

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

Title:
  ipconfig lacks ipv6 support

Status in MAAS:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  New
Status in klibc package in Ubuntu:
  New
Status in klibc package in Debian:
  Unknown

Bug description:
  initramfs' configure_networking function uses ipconfig to configure
  the network.

  ipconfig does not support dhcpv6.  See: https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=627164

  Anyone wanting to netboot in an ipv6-only environment is affected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1621507/+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 1621507] Re: ipconfig lacks ipv6 support

[Andres Rodriguez]

** Also affects: maas
   Importance: Undecided
   Status: New

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

Title:
  ipconfig lacks ipv6 support

Status in MAAS:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  New
Status in klibc package in Ubuntu:
  New
Status in klibc package in Debian:
  Unknown

Bug description:
  initramfs' configure_networking function uses ipconfig to configure
  the network.

  ipconfig does not support dhcpv6.  See: https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=627164

  Anyone wanting to netboot in an ipv6-only environment is affected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1621507/+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 1251257] Re: [SRU] avahi fails in containers

[Andres Rodriguez]

** No longer affects: maas/1.4

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

Title:
  [SRU] avahi fails in containers

Status in MAAS:
  Fix Released
Status in avahi package in Ubuntu:
  Fix Released
Status in avahi source package in Precise:
  Fix Released
Status in avahi source package in Saucy:
  Fix Released
Status in avahi source package in Trusty:
  Fix Released

Bug description:
  installed a brand new maas server on suacy into an lxc container from
  archive and http:///MAAS is not accessible although http:// is
  accessible

  http:///MAAS is getting logged to /var/log/apache2/access.log
  though so request is making it through

   danwest: can you please pastebin apache2's error and access.log
   http://paste.ubuntu.com/6405411/
   http://paste.ubuntu.com/6405412/

   danwest: I know what it is
   danwest: dbus/avahi
   danwest: try to restart whatever avahi service there is
   "dbus" reminds me of 
https://bugs.launchpad.net/juju-core/+bug/1248283
   but that was about the units, not maas itself
   https://pastebin.canonical.com/100290/
   same problem
   danwest: yeah the avahi daemon is failing to start, causing maas 
to fail
   danwest: maybe restart whatever dbus serviice it is, and then the 
avahi-daemon
   danwest, restart dbus and avahi-daemon, see 
https://bugs.launchpad.net/maas/+bug/1221059

   danwest: did avahi-daemon restart corrrectly?
   nope
   danwest: i guess then an issue with dbus is preventing avahi from 
working... hence maas failing
   roaksoax: should not matter but the only thing that is a little 
unique is that this is in a saucy container

   danwest: ah so then thats the issue...
   what, the container?
   yeah
   how so?
   avahi might have issues running in a container

   hallyn: roaksoax: what should I file that lxc/avahi /maas bug that 
I hit this morning against?
   danwest: i think maas should work around it by unsetting rlimit-nproc
   (and/or by running on trusty in a private user ns

   smoser: fwiw the problem is that avahi sets its nproc rlimit to 
exaclty 3, but in a container it's using a uid that is in use on the host - so 
it exceeds 3 tasks
   (i.e. it's reusing uid which is ntp on the host, and ntp is running; 
 or just another avahi)
   ok...
   so that doesn't seem like maas's problem to me
   nor juju's really.
   smoser: it is.  it needs to pick a unique uid, or configure avahi to 
ignore the rlimit
   maas isn't running avahi
   is it ?
   i duno what's actually running it :)  it's *for* maas, but it 
probably is juju
   what if there was a bug in php, and a user used maas to deploy php.
   should we fix that in maas ?
   you're talking about a bug.  i'm talking about a resource conflict
   having avahi alwasy run without nprocs, for protection, would be 
wrong for this.

  fix is still up for debate on this one...

  [Impact]
  Avahi sets the rlimit_nproc to 3, causing avahi to fail running in 
containers. This This option should not be set in containers at all. This 
causes avahi-daemon to fail, hence all the applications that use avahi will 
also fail. In this particular case, MAAS fails because of this.

  [Test Case]
  1. Install a container.
  2. Install MAAS
  3. Check apache2 log for errors, such as those in [1].

  [Regression Potential]
  Minimal. This has been tested and works as expected.

  [1]: http://paste.ubuntu.com/6405412/

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1251257/+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 1521618] Re: [1.9] wrong subnet in DHCP answer when multiple networks are present

[Andres Rodriguez]

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

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

Title:
  [1.9] wrong subnet in DHCP answer when multiple networks are present

Status in MAAS:
  Fix Released
Status in MAAS 1.9 series:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  So I have 3 interfaces with 3, non-overlapping subnets defined in my
  maas cluster controller.

  The idea would be that there is a provisioning network (10.6.0.0/16)
  to do the actual provisioning and once the node gets deployed it is
  using a different network (because the provisioning network is only
  1x1Gbit while the production network is bonded (LACP) 10Gbit).

  However, when I boot up a fresh, new node to add to MAAS, it gets the
  following DHCP reply:

  ip=10.6.239.3:10.6.250.250:9.4.113.254:255.255.255.0

  So instead of picking up the /16 subnet correctly for the 10.6.239.3
  IP, it picks up the /24 from the network where it gets it's default
  gateway from.

  Is this a bug or my understanding of how MAAS should behave when there
  are multiple networks flawed?

  Here is my /var/lib/maas/dhcpd.conf:

  subnet 9.4.113.0 netmask 255.255.255.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth0";
 ignore-client-uids true;
 option subnet-mask 255.255.255.0;
 option broadcast-address 9.4.113.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option routers 9.4.113.254;
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 9.4.113.150 9.4.113.190;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }
  subnet 10.6.0.0 netmask 255.255.0.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth1";
 ignore-client-uids true;
 option subnet-mask 255.255.0.0;
 option broadcast-address 10.6.255.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 10.6.239.0 10.6.239.239;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }

  Here is "subnets read":

  [
  {
  "dns_servers": [],
  "name": "9.4.113.0/24",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/0/",
  "fabric": "fabric-0",
  "vid": 0,
  "id": 0
  },
  "gateway_ip": "9.4.113.254",
  "cidr": "9.4.113.0/24",
  "id": 1,
  "resource_uri": "/MAAS/api/1.0/subnets/1/"
  },
  {
  "dns_servers": [],
  "name": "10.7.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5001/",
  "fabric": "fabric-1",
  "vid": 0,
  "id": 5001
  },
  "gateway_ip": null,
  "cidr": "10.7.0.0/16",
  "id": 2,
  "resource_uri": "/MAAS/api/1.0/subnets/2/"
  },
  {
  "dns_servers": [],
  "name": "10.6.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5002/",
  "fabric": "fabric-2",
  "vid": 0,
  "id": 5002
  },
  "gateway_ip": null,
  "cidr": "10.6.0.0/16",
  "id": 3,
  "resource_uri": "/MAAS/api/1.0/subnets/3/"
  }
  ]

  Running 1.9.0~rc2+bzr4509-0ubuntu1~trusty1.

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

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

[Touch-packages] [Bug 1521618] Re: [1.9] wrong subnet in DHCP answer when multiple networks are present

[Andres Rodriguez]

** Changed in: maas/1.9
   Status: Fix Committed => Fix Released

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

Title:
  [1.9] wrong subnet in DHCP answer when multiple networks are present

Status in MAAS:
  Fix Committed
Status in MAAS 1.9 series:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  So I have 3 interfaces with 3, non-overlapping subnets defined in my
  maas cluster controller.

  The idea would be that there is a provisioning network (10.6.0.0/16)
  to do the actual provisioning and once the node gets deployed it is
  using a different network (because the provisioning network is only
  1x1Gbit while the production network is bonded (LACP) 10Gbit).

  However, when I boot up a fresh, new node to add to MAAS, it gets the
  following DHCP reply:

  ip=10.6.239.3:10.6.250.250:9.4.113.254:255.255.255.0

  So instead of picking up the /16 subnet correctly for the 10.6.239.3
  IP, it picks up the /24 from the network where it gets it's default
  gateway from.

  Is this a bug or my understanding of how MAAS should behave when there
  are multiple networks flawed?

  Here is my /var/lib/maas/dhcpd.conf:

  subnet 9.4.113.0 netmask 255.255.255.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth0";
 ignore-client-uids true;
 option subnet-mask 255.255.255.0;
 option broadcast-address 9.4.113.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option routers 9.4.113.254;
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 9.4.113.150 9.4.113.190;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }
  subnet 10.6.0.0 netmask 255.255.0.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth1";
 ignore-client-uids true;
 option subnet-mask 255.255.0.0;
 option broadcast-address 10.6.255.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 10.6.239.0 10.6.239.239;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }

  Here is "subnets read":

  [
  {
  "dns_servers": [],
  "name": "9.4.113.0/24",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/0/",
  "fabric": "fabric-0",
  "vid": 0,
  "id": 0
  },
  "gateway_ip": "9.4.113.254",
  "cidr": "9.4.113.0/24",
  "id": 1,
  "resource_uri": "/MAAS/api/1.0/subnets/1/"
  },
  {
  "dns_servers": [],
  "name": "10.7.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5001/",
  "fabric": "fabric-1",
  "vid": 0,
  "id": 5001
  },
  "gateway_ip": null,
  "cidr": "10.7.0.0/16",
  "id": 2,
  "resource_uri": "/MAAS/api/1.0/subnets/2/"
  },
  {
  "dns_servers": [],
  "name": "10.6.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5002/",
  "fabric": "fabric-2",
  "vid": 0,
  "id": 5002
  },
  "gateway_ip": null,
  "cidr": "10.6.0.0/16",
  "id": 3,
  "resource_uri": "/MAAS/api/1.0/subnets/3/"
  }
  ]

  Running 1.9.0~rc2+bzr4509-0ubuntu1~trusty1.

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

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

[Touch-packages] [Bug 1521618] Re: [1.9] wrong subnet in DHCP answer when multiple networks are present

[Andres Rodriguez]

** Summary changed:

- wrong subnet in DHCP answer when multiple networks are present
+ [1.9] wrong subnet in DHCP answer when multiple networks are present

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

Title:
  [1.9] wrong subnet in DHCP answer when multiple networks are present

Status in MAAS:
  Fix Committed
Status in MAAS 1.9 series:
  Fix Committed
Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  So I have 3 interfaces with 3, non-overlapping subnets defined in my
  maas cluster controller.

  The idea would be that there is a provisioning network (10.6.0.0/16)
  to do the actual provisioning and once the node gets deployed it is
  using a different network (because the provisioning network is only
  1x1Gbit while the production network is bonded (LACP) 10Gbit).

  However, when I boot up a fresh, new node to add to MAAS, it gets the
  following DHCP reply:

  ip=10.6.239.3:10.6.250.250:9.4.113.254:255.255.255.0

  So instead of picking up the /16 subnet correctly for the 10.6.239.3
  IP, it picks up the /24 from the network where it gets it's default
  gateway from.

  Is this a bug or my understanding of how MAAS should behave when there
  are multiple networks flawed?

  Here is my /var/lib/maas/dhcpd.conf:

  subnet 9.4.113.0 netmask 255.255.255.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth0";
 ignore-client-uids true;
 option subnet-mask 255.255.255.0;
 option broadcast-address 9.4.113.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option routers 9.4.113.254;
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 9.4.113.150 9.4.113.190;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }
  subnet 10.6.0.0 netmask 255.255.0.0 {
 if option arch = 00:0E {
filename "pxelinux.0";
option path-prefix "ppc64el/";
 } elsif option arch = 00:07 {
filename "bootx64.efi";
 } elsif option arch = 00:0B {
filename "grubaa64.efi";
 } elsif option arch = 00:0C {
filename "bootppc64.bin";
 } else {
filename "pxelinux.0";
 }
 interface "eth1";
 ignore-client-uids true;
 option subnet-mask 255.255.0.0;
 option broadcast-address 10.6.255.255;
 option domain-name-servers 9.4.113.251;
 option domain-name "i.zc2.ibm.com";
 option ntp-servers ntp.ubuntu.com;
 range dynamic-bootp 10.6.239.0 10.6.239.239;
 class "PXE" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
default-lease-time 30;
max-lease-time 30;
 }
  }

  Here is "subnets read":

  [
  {
  "dns_servers": [],
  "name": "9.4.113.0/24",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/0/",
  "fabric": "fabric-0",
  "vid": 0,
  "id": 0
  },
  "gateway_ip": "9.4.113.254",
  "cidr": "9.4.113.0/24",
  "id": 1,
  "resource_uri": "/MAAS/api/1.0/subnets/1/"
  },
  {
  "dns_servers": [],
  "name": "10.7.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5001/",
  "fabric": "fabric-1",
  "vid": 0,
  "id": 5001
  },
  "gateway_ip": null,
  "cidr": "10.7.0.0/16",
  "id": 2,
  "resource_uri": "/MAAS/api/1.0/subnets/2/"
  },
  {
  "dns_servers": [],
  "name": "10.6.0.0/16",
  "space": "space-0",
  "vlan": {
  "name": "untagged",
  "resource_uri": "/MAAS/api/1.0/vlans/5002/",
  "fabric": "fabric-2",
  "vid": 0,
  "id": 5002
  },
  "gateway_ip": null,
  "cidr": "10.6.0.0/16",
  "id": 3,
  "resource_uri": "/MAAS/api/1.0/subnets/3/"
  }
  ]

  Running 1.9.0~rc2+bzr4509-0ubuntu1~trusty1.

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

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

[Touch-packages] [Bug 1575337] Re: syslog.log is completely empty

[Andres Rodriguez]

ok, so I think what the issue is. I found a different rule that would
do:

& ~

However, that means " stop logging anything that matches the last rule",
however, instead of stopping just that rule, it was stopping everything.
The reason why this was stopping everything is because it didn't really
match the last rle, provided that the last rule was wrapped in an if
statement, hence it was completely stopping rsyslog logging.

** No longer affects: rsyslog (Ubuntu)

** Also affects: maas
   Importance: Undecided
   Status: New

** No longer affects: systemd (Ubuntu)

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

Title:
  syslog.log is completely empty

Status in MAAS:
  New

Bug description:
  130 roaksoax@unleashed:~/Desktop/project/packaging⟫ dpkg -l | grep rsyslog
  ii  rsyslog  8.16.0-1ubuntu3  
  amd64reliable system and kernel logging daemon
  ii  rsyslog-gnutls   8.16.0-1ubuntu3  
  amd64TLS protocol support for rsyslog

  roaksoax@unleashed:~/Desktop/project/packaging⟫ sudo service rsyslog status
  [sudo] password for roaksoax: 
  ● rsyslog.service - System Logging Service
 Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor 
preset: enabled)
 Active: active (running) since Tue 2016-04-26 16:12:24 EDT; 1h 39min ago
   Docs: man:rsyslogd(8)
 http://www.rsyslog.com/doc/
   Main PID: 26547 (rsyslogd)
  Tasks: 5 (limit: 512)
 Memory: 1.3M
CPU: 174ms
 CGroup: /system.slice/rsyslog.service
 └─26547 /usr/sbin/rsyslogd -n

  Apr 26 16:12:24 unleashed systemd[1]: Starting System Logging Service...
  Apr 26 16:12:24 unleashed systemd[1]: Started System Logging Service.

  roaksoax@unleashed:~/Desktop/project/packaging⟫ sudo cat /var/log/syslog
  roaksoax@unleashed:~/Desktop/project/packaging⟫

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1575337/+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 1575337] Re: syslog.log is completely empty

[Andres Rodriguez]

Ok, so MAAS install's an rsyslog config to forward messages from syslog
to /var/log/maas/maas.log. Today we noticed that maas.log was completely
empty, and on further checking, we noticed that syslog was completely
empty as well. The fun fact, however, is that MAAS has not changed its
syslog configuration in years, and we definitely don't believe this is
the problem. Also, this was working before just fine without any issues
before , and as such, we don't believe is a problem on rsyslog.

The interesting thing is that rsyslog hasn't really change much in the
past few months (iother that 2, no change rebuilds). Also, syslog logs
that should be on /var/log/syslog are on systemd's journal.

MAAS config on /etc/maas/rsyslog.d/99-maas:

# Log MAAS messages to their own file.
:syslogtag,contains,"maas" /var/log/maas/maas.log

** Also affects: rsyslog (Ubuntu)
   Importance: Undecided
   Status: New

** No longer affects: maas (Ubuntu)

** Description changed:

- /var/log/syslog is empty and everything is under systemd's journal.
+ 130 roaksoax@unleashed:~/Desktop/project/packaging⟫ dpkg -l | grep rsyslog
+ ii  rsyslog  8.16.0-1ubuntu3  
  amd64reliable system and kernel logging daemon
+ ii  rsyslog-gnutls   8.16.0-1ubuntu3  
  amd64TLS protocol support for rsyslog
+ 
+ roaksoax@unleashed:~/Desktop/project/packaging⟫ sudo service rsyslog status
+ [sudo] password for roaksoax: 
+ ● rsyslog.service - System Logging Service
+Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor 
preset: enabled)
+Active: active (running) since Tue 2016-04-26 16:12:24 EDT; 1h 39min ago
+  Docs: man:rsyslogd(8)
+http://www.rsyslog.com/doc/
+  Main PID: 26547 (rsyslogd)
+ Tasks: 5 (limit: 512)
+Memory: 1.3M
+   CPU: 174ms
+CGroup: /system.slice/rsyslog.service
+└─26547 /usr/sbin/rsyslogd -n
+ 
+ Apr 26 16:12:24 unleashed systemd[1]: Starting System Logging Service...
+ Apr 26 16:12:24 unleashed systemd[1]: Started System Logging Service.
+ 
+ roaksoax@unleashed:~/Desktop/project/packaging⟫ sudo cat /var/log/syslog
+ roaksoax@unleashed:~/Desktop/project/packaging⟫

** Changed in: rsyslog (Ubuntu)
   Importance: Undecided => Critical

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

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

Title:
  syslog.log is completely empty

Status in rsyslog package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  130 roaksoax@unleashed:~/Desktop/project/packaging⟫ dpkg -l | grep rsyslog
  ii  rsyslog  8.16.0-1ubuntu3  
  amd64reliable system and kernel logging daemon
  ii  rsyslog-gnutls   8.16.0-1ubuntu3  
  amd64TLS protocol support for rsyslog

  roaksoax@unleashed:~/Desktop/project/packaging⟫ sudo service rsyslog status
  [sudo] password for roaksoax: 
  ● rsyslog.service - System Logging Service
 Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor 
preset: enabled)
 Active: active (running) since Tue 2016-04-26 16:12:24 EDT; 1h 39min ago
   Docs: man:rsyslogd(8)
 http://www.rsyslog.com/doc/
   Main PID: 26547 (rsyslogd)
  Tasks: 5 (limit: 512)
 Memory: 1.3M
CPU: 174ms
 CGroup: /system.slice/rsyslog.service
 └─26547 /usr/sbin/rsyslogd -n

  Apr 26 16:12:24 unleashed systemd[1]: Starting System Logging Service...
  Apr 26 16:12:24 unleashed systemd[1]: Started System Logging Service.

  roaksoax@unleashed:~/Desktop/project/packaging⟫ sudo cat /var/log/syslog
  roaksoax@unleashed:~/Desktop/project/packaging⟫

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1575337/+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 1575337] Re: [2.0a4] maas.log is empty

[Andres Rodriguez]

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

** No longer affects: maas

** Description changed:

- MAAS ships a custom rsyslog.d config which follows:
- 
- /etc/rsyslog.d/20-maas ships:
- 
- # Log MAAS messages to their own file.
- :syslogtag,contains,"maas" /var/log/maas/maas.log
- 
- As of the latest xenial, maas.log is no longer being populated, nor
- syslog is populated with MAAS' log.
- 
- Now, however, all the log is under systemd's 'journalctl'
+ /var/log/syslog is empty and everything is under systemd's journal.

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

Title:
  [2.0a4] maas.log is empty

Status in systemd package in Ubuntu:
  New

Bug description:
  /var/log/syslog is empty and everything is under systemd's journal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1575337/+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 1540522] Re: vfat support broken in initramfs

[Andres Rodriguez]

** Changed in: maas
Milestone: 1.9.2 => None

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

Title:
  vfat support broken in initramfs

Status in MAAS:
  Invalid
Status in maas-images:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released

Bug description:
  when it try to mount the fat32 for the efi it failed with the
  following error : [  117.627721] FAT-fs (sda1): IO charset iso8859-1
  not found

  
  which is due to the missing module : nls_iso8859_1

  workaround is : to apt-get install linux-generic
  than the module is properly loaded.

  here's the error that I've seen in the boot.log : 
   can't create directory '/root/lib/modules': Read-only file system

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1540522/+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 1567744] Re: RTNETLINK answers: Numerical result out of range for alias interface from a usb NIC

[Andres Rodriguez]

** Changed in: ifupdown (Ubuntu)
   Importance: Undecided => Critical

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

Title:
  RTNETLINK answers: Numerical result out of range for alias interface
  from a usb NIC

Status in ifupdown package in Ubuntu:
  New

Bug description:
  I have a USB NIC that is connected to my denial system. I tried to
  create an alias, and after reboot, it wasn't created. When I manually
  try to bring it up I have the error.

  /e/n/i:

  auto enx000ec688b79f
  iface enx000ec688b79f inet static
  address 10.90.90.1
  netmask 255.255.255.0

  auto enx000ec688b79f:1
  iface enx000ec688b79f:1 inet static
  address 192.168.100.1
  netmask 255.255.255.0

  ubuntu@maas00:~$ sudo ifup enx000ec688b79f
  ubuntu@maas00:~$ sudo ifup enx000ec688b79f:1
  RTNETLINK answers: Numerical result out of range
  Failed to bring up enx000ec688b79f:1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1567744/+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 1567744] Re: RTNETLINK answers: Numerical result out of range for alias interface from a usb NIC

[Andres Rodriguez]

** Description changed:

- I have a USB NIC that is connected to my xenial system:
+ I have a USB NIC that is connected to my denial system. I tried to
+ create an alias, and after reboot, it wasn't created. When I manually
+ try to bring it up I have the error.
  
  /e/n/i:
  
  auto enx000ec688b79f
  iface enx000ec688b79f inet static
  address 10.90.90.1
  netmask 255.255.255.0
  
  auto enx000ec688b79f:1
  iface enx000ec688b79f:1 inet static
  address 192.168.100.1
  netmask 255.255.255.0
  
  ubuntu@maas00:~$ sudo ifup enx000ec688b79f
  ubuntu@maas00:~$ sudo ifup enx000ec688b79f:1
  RTNETLINK answers: Numerical result out of range
  Failed to bring up enx000ec688b79f:1.

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

Title:
  RTNETLINK answers: Numerical result out of range for alias interface
  from a usb NIC

Status in ifupdown package in Ubuntu:
  New

Bug description:
  I have a USB NIC that is connected to my denial system. I tried to
  create an alias, and after reboot, it wasn't created. When I manually
  try to bring it up I have the error.

  /e/n/i:

  auto enx000ec688b79f
  iface enx000ec688b79f inet static
  address 10.90.90.1
  netmask 255.255.255.0

  auto enx000ec688b79f:1
  iface enx000ec688b79f:1 inet static
  address 192.168.100.1
  netmask 255.255.255.0

  ubuntu@maas00:~$ sudo ifup enx000ec688b79f
  ubuntu@maas00:~$ sudo ifup enx000ec688b79f:1
  RTNETLINK answers: Numerical result out of range
  Failed to bring up enx000ec688b79f:1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1567744/+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 1567744] [NEW] RTNETLINK answers: Numerical result out of range for alias interface from a usb NIC

[Andres Rodriguez]

Public bug reported:

I have a USB NIC that is connected to my xenial system:

/e/n/i:

auto enx000ec688b79f
iface enx000ec688b79f inet static
address 10.90.90.1
netmask 255.255.255.0

auto enx000ec688b79f:1
iface enx000ec688b79f:1 inet static
address 192.168.100.1
netmask 255.255.255.0

ubuntu@maas00:~$ sudo ifup enx000ec688b79f
ubuntu@maas00:~$ sudo ifup enx000ec688b79f:1
RTNETLINK answers: Numerical result out of range
Failed to bring up enx000ec688b79f:1.

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

** Description changed:

- I have a USB NIC that is connected to my system.
+ I have a USB NIC that is connected to my xenial system:
  
  /e/n/i:
  
  auto enx000ec688b79f
  iface enx000ec688b79f inet static
- address 10.90.90.1
- netmask 255.255.255.0
+ address 10.90.90.1
+ netmask 255.255.255.0
  
  auto enx000ec688b79f:1
  iface enx000ec688b79f:1 inet static
- address 192.168.100.1
- netmask 255.255.255.0
- 
+ address 192.168.100.1
+ netmask 255.255.255.0
  
  ubuntu@maas00:~$ sudo ifup enx000ec688b79f
  ubuntu@maas00:~$ sudo ifup enx000ec688b79f:1
  RTNETLINK answers: Numerical result out of range
  Failed to bring up enx000ec688b79f:1.

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

Title:
  RTNETLINK answers: Numerical result out of range for alias interface
  from a usb NIC

Status in ifupdown package in Ubuntu:
  New

Bug description:
  I have a USB NIC that is connected to my xenial system:

  /e/n/i:

  auto enx000ec688b79f
  iface enx000ec688b79f inet static
  address 10.90.90.1
  netmask 255.255.255.0

  auto enx000ec688b79f:1
  iface enx000ec688b79f:1 inet static
  address 192.168.100.1
  netmask 255.255.255.0

  ubuntu@maas00:~$ sudo ifup enx000ec688b79f
  ubuntu@maas00:~$ sudo ifup enx000ec688b79f:1
  RTNETLINK answers: Numerical result out of range
  Failed to bring up enx000ec688b79f:1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1567744/+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 1540522] Re: vfat support broken in initramfs

[Andres Rodriguez]

** Changed in: maas
Milestone: 1.9.1 => 1.9.2

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

Title:
  vfat support broken in initramfs

Status in MAAS:
  Invalid
Status in maas-images:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released

Bug description:
  when it try to mount the fat32 for the efi it failed with the
  following error : [  117.627721] FAT-fs (sda1): IO charset iso8859-1
  not found

  
  which is due to the missing module : nls_iso8859_1

  workaround is : to apt-get install linux-generic
  than the module is properly loaded.

  here's the error that I've seen in the boot.log : 
   can't create directory '/root/lib/modules': Read-only file system

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1540522/+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 1546358] Re: policycoreutils (in universe) is installed by default by isc-dhcp-server as it is a Recommends

[Andres Rodriguez]

Here's the output of installing without Recommends (and coreutils):

roaksoax@unleashed:~$ lxc exec xenial6 -- /bin/sh
# sudo apt-get install isc-dhcp-server --no-install-recommends
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libirs-export91 libisccfg-export90
Suggested packages:
  isc-dhcp-server-ldap apparmor
Recommended packages:
  policycoreutils
The following NEW packages will be installed:
  isc-dhcp-server libirs-export91 libisccfg-export90
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 483 kB of archives.
After this operation, 1,718 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.ubuntu.com/ubuntu xenial/main i386 libisccfg-export90
i386 1:9.9.5.dfsg-12.1ubuntu1 [21.7 kB]
Get:2 http://archive.ubuntu.com/ubuntu xenial/main i386 libirs-export91
i386 1:9.9.5.dfsg-12.1ubuntu1 [18.5 kB]
Get:3 http://archive.ubuntu.com/ubuntu xenial/main i386 isc-dhcp-server
i386 4.3.3-5ubuntu5 [443 kB]
Fetched 483 kB in 1s (405 kB/s)
Preconfiguring packages ...
Selecting previously unselected package libisccfg-export90.
(Reading database ... 12764 files and directories currently installed.)
Preparing to unpack
.../libisccfg-export90_1%3a9.9.5.dfsg-12.1ubuntu1_i386.deb ...
Unpacking libisccfg-export90 (1:9.9.5.dfsg-12.1ubuntu1) ...
Selecting previously unselected package libirs-export91.
Preparing to unpack .../libirs-export91_1%3a9.9.5.dfsg-12.1ubuntu1_i386.deb
...
Unpacking libirs-export91 (1:9.9.5.dfsg-12.1ubuntu1) ...
Selecting previously unselected package isc-dhcp-server.
Preparing to unpack .../isc-dhcp-server_4.3.3-5ubuntu5_i386.deb ...
Unpacking isc-dhcp-server (4.3.3-5ubuntu5) ...
Processing triggers for libc-bin (2.21-0ubuntu6) ...
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for systemd (229-1ubuntu2) ...
Setting up libisccfg-export90 (1:9.9.5.dfsg-12.1ubuntu1) ...
Setting up libirs-export91 (1:9.9.5.dfsg-12.1ubuntu1) ...
Setting up isc-dhcp-server (4.3.3-5ubuntu5) ...
Generating /etc/default/isc-dhcp-server...
Processing triggers for libc-bin (2.21-0ubuntu6) ...
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for systemd (229-1ubuntu2) ...
# dpkg -l | grep policy
ii  libsemanage-common2.3-1build2  all
 Common files for SELinux policy management libraries
ii  libsemanage1:i386 2.3-1build2  i386
SELinux policy management library
# dpkg -l | grep policycoreutils

On Thu, Feb 18, 2016 at 6:28 PM, Robie Basak <1546...@bugs.launchpad.net>
wrote:

> Downgrading to Medium, as I feel that Critical needs a justification.
>
> ** Changed in: isc-dhcp (Ubuntu)
>Importance: Critical => Medium
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1546358
>
> Title:
>   policycoreutils (in universe) is installed by default by isc-dhcp-
>   server as it is a Recommends
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1546358/+subscriptions
>


-- 
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
MSc. Telecom & Networking
Systems Engineer

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

Title:
  policycoreutils (in universe) is installed by default by isc-dhcp-
  server as it is a Recommends

Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  Policycoreutils is being installed by default because the package is
  listed as a Recommends. This package, however, is in universe and
  seems to be pulling selinux. This should not be a recommends but
  rather, it should be a Suggests.

  It seems that the postinst requires a binary being shipped in
  policycoreutils:

  debian/isc-dhcp-server.postinst:test ! -x /sbin/restorecon ||
  /sbin/restorecon /var/lib/dhcp/dhcpd.leases

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1546358/+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 1546358] Re: policycoreutils (in universe) is installed by default by isc-dhcp-server as it is a Recommends

[Andres Rodriguez]

** Description changed:

- Policycoreutils is being installed by default, and this dependency is in
- Universe. This should not be a recommends but rather, it should be a
- Suggests, because this is pulling selinux dependencies.
+ Policycoreutils is being installed by default because the package is
+ listed as a Recommends. This package, however, is in universe and seems
+ to be pulling selinux. This should not be a recommends but rather, it
+ should be a Suggests.
  
- However, it seems that the postinst requires a binary being shipped in
+ It seems that the postinst requires a binary being shipped in
  policycoreutils:
  
  debian/isc-dhcp-server.postinst:test ! -x /sbin/restorecon ||
  /sbin/restorecon /var/lib/dhcp/dhcpd.leases

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

Title:
  policycoreutils (in universe) is installed by default by isc-dhcp-
  server as it is a Recommends

Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  Policycoreutils is being installed by default because the package is
  listed as a Recommends. This package, however, is in universe and
  seems to be pulling selinux. This should not be a recommends but
  rather, it should be a Suggests.

  It seems that the postinst requires a binary being shipped in
  policycoreutils:

  debian/isc-dhcp-server.postinst:test ! -x /sbin/restorecon ||
  /sbin/restorecon /var/lib/dhcp/dhcpd.leases

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1546358/+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 1546358] [NEW] policycoreutils (in universe) is installed by default by isc-dhcp-server as it is a Recommends

[Andres Rodriguez]

Public bug reported:

Policycoreutils is being installed by default, and this dependency is in
Universe. This should not be a recommends but rather, it should be a
Suggests, because this is pulling selinux dependencies.

However, it seems that the postinst requires a binary being shipped in
policycoreutils:

debian/isc-dhcp-server.postinst:test ! -x /sbin/restorecon ||
/sbin/restorecon /var/lib/dhcp/dhcpd.leases

** Affects: isc-dhcp (Ubuntu)
 Importance: Critical
 Status: New

** Changed in: isc-dhcp (Ubuntu)
   Importance: Undecided => Critical

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

Title:
  policycoreutils (in universe) is installed by default by isc-dhcp-
  server as it is a Recommends

Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  Policycoreutils is being installed by default, and this dependency is
  in Universe. This should not be a recommends but rather, it should be
  a Suggests, because this is pulling selinux dependencies.

  However, it seems that the postinst requires a binary being shipped in
  policycoreutils:

  debian/isc-dhcp-server.postinst:test ! -x /sbin/restorecon ||
  /sbin/restorecon /var/lib/dhcp/dhcpd.leases

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1546358/+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.

[Andres Rodriguez]

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

-- 
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 Committed
Status in MAAS:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in iputils package in Ubuntu:
  Fix Released
Status in lxc package in Ubuntu:
  Triaged
Status in maas package in Ubuntu:
  Confirmed
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 lxc source package in Trusty:
  Triaged
Status in maas source package in Trusty:
  Confirmed
Status in tar source package in Trusty:
  Fix Released
Status in lxc source package in Vivid:
  Triaged
Status in maas source package in Vivid:
  New
Status in lxc source package in Wily:
  Triaged
Status in maas source package in Wily:
  New

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)

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 972077] Re: apt repository disk format has race conditions

[Andres Rodriguez]

** No longer affects: maas

-- 
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 package in Ubuntu:
  Confirmed

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 (e.g. Releases-2), 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
   * Releases-2, a self-signed file that provides hashes and names the index 
files (Packages, Sources, Translations etc)
   * Coexists with existing archive layout

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/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 1355813] Re: Interface MTU management across MAAS/juju

[Andres Rodriguez]

** Changed in: maas
   Importance: Undecided = Wishlist

** Changed in: maas
   Status: New = Triaged

** Changed in: maas
Milestone: None = 1.8.0

** Changed in: maas
Milestone: 1.8.0 = next

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

Title:
  Interface MTU management across MAAS/juju

Status in juju-core:
  Fix Released
Status in MAAS:
  Triaged
Status in juju-core package in Ubuntu:
  Triaged
Status in lxc package in Ubuntu:
  Invalid

Bug description:
  Context:

  juju + MAAS deployed OpenStack environment, misc services deployed
  under LXC on the bootstrap node, interfaces configured for jumbo
  frames - note that I had to manually set the LXC container interfaces
  to mtu 9000 before the bridge would do the same.

  Action:

  Reboot one of the containers; MTU on br0 resets from 9000 - 1500.

  This feels like more of a 'we need a better way to orchestrate MTU
  configuration across different services' so raising tasks for MAAS and
  Juju as well.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: lxc 1.0.5-0ubuntu0.1
  ProcVersionSignature: User Name 3.13.0-24.47-generic 3.13.9
  Uname: Linux 3.13.0-24-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.3
  Architecture: amd64
  Date: Tue Aug 12 13:26:00 2014
  KernLog:

  SourcePackage: lxc
  UpgradeStatus: No upgrade log present (probably fresh install)
  defaults.conf:
   lxc.network.type = veth
   lxc.network.link = lxcbr0
   lxc.network.flags = up
   lxc.network.hwaddr = 00:16:3e:xx:xx:xx
  lxcsyslog:

To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-core/+bug/1355813/+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 1391354] Re: Failure to boot ephemeral image for Utopic Fast Installer deployment: no ID_PATH for iSCSI device any more

[Andres Rodriguez]

** Changed in: maas
Milestone: 1.7.1 = 1.7.2

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

Title:
  Failure to boot ephemeral image for Utopic Fast Installer deployment:
  no ID_PATH for iSCSI device any more

Status in MAAS:
  Incomplete
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Utopic:
  Fix Released

Bug description:
  I am running into issues with the latest Utopic daily ephemeral images
  for Utopic:

Release ArchitectureSizeNodes deployed  Last update
14.10   i386391.2 MB0   Tue Nov 11 00:36:04 2014
14.10   amd64   395.6 MB0   Tue Nov 11 00:36:04 2014
14.10   ppc64el 425.8 MB1   Tue Nov 11 00:36:03 2014
14.04 LTS   i386373.3 MB0   Tue Nov 11 00:36:04 2014
14.04 LTS   ppc64el 408.5 MB1   Tue Nov 11 00:36:04 2014
14.04 LTS   amd64   380.5 MB52  Tue Nov 11 00:36:03 2014
12.04 LTS   amd64   517.5 MB245 Tue Nov 11 00:36:05 2014
12.04 LTS   i386487.3 MB0   Tue Nov 11 00:36:05 2014

  I have tried installing 2 physical servers, moline and premier as well
  as a ppc64el VM, huffman-vm10, and I get the same failure for each.

  

  iscsistart: Logging into 
iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-ppc64el-generic-utopic-daily 
10.245.0.10:3260,1
  iscsistart: can not connect to iSCSI daemon (111)!
  iscsistart: version 2.0-873
  [   17.810223] sd 1:0:0:1: [sdb] Write Protect is on
  [   17.811504] sd 1:0:0:1: [sdb] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
  [   17.828817]  sdb: unknown partition table
  [   17.839360] sd 1:0:0:1: [sdb] Attached SCSI disk
  iscsistart: initiator reported error (15 - session exists)
  done.
  [   35.868265] random: nonblocking pool is initialized
  Begin: Loading essential drivers ... done.
  Begin: Running /scripts/init-premount ... done.
  Begin: Mounting root file system ... Begin: Running /scripts/local-top ... 
IP-Config: eth0 hardware address 52:54:00:95:6b:54 mtu 1500 DHCP RARP
  IP-Config: no response after 2 secs - giving up
  IP-Config: eth0 hardware address 52:54:00:95:6b:54 mtu 1500 DHCP RARP
  hostname huffman-vm-10 hostname huffman-vm-10 IP-Config: eth0 complete (dhcp 
from 10.245.0.10):
   address: 10.245.0.173 broadcast: 10.245.63.255netmask: 255.255.192.0 
  
   gateway: 10.245.0.1   dns0 : 10.245.0.10  dns1   : 0.0.0.0   
  
   domain : oil 
   rootserver: 10.245.0.10 rootpath: 
   filename  : pxelinux.0
  iscsistart: Logging into 
iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-ppc64el-generic-utopic-daily 
10.245.0.10:3260,1
  iscsistart: version 2.0-873
  iscsistart: Connection1:0 to [target: 
iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-ppc64el-generic-utopic-daily, 
portal: 10.245.0.10,3260] through [iface: default] is operational now
  iscsistart: Logging into 
iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-ppc64el-generic-utopic-daily 
10.245.0.10:3260,1
  iscsistart: can not connect to iSCSI daemon (111)!
  iscsistart: version 2.0-873
  iscsistart: initiator reported error (15 - session exists)
  done.
  Gave up waiting for root device.  Common problems:
   - Boot args (cat /proc/cmdline)
 - Check rootdelay= (did the system wait long enough?)
 - Check root= (did the system wait for the right device?)
   - Missing modules (cat /proc/modules; ls /dev)
  ALERT!  
/dev/disk/by-path/ip-10.245.0.10:3260-iscsi-iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-ppc64el-generic-utopic-daily-lun-1
 does not exist.  Dropping to a shell!
  [   78.856173] hidraw: raw HID events driver (C) Jiri Kosina
  [   78.860069] usbcore: registered new interface driver usbhid
  [   78.860272] usbhid: USB HID core driver

  
  BusyBox v1.22.1 (Ubuntu 1:1.22.0-8ubuntu1) built-in shell (ash)
  Enter 'help' for a list of built-in commands.

  (initramfs)

  
  

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