[Touch-packages] [Bug 1959725] [NEW] Segfault from Native.sd_journal_get_fd
Public bug reported: The version of libsystemd0 Ubuntu 20.04 has the following issue present in the package: https://github.com/systemd/systemd/issues/15528 https://github.com/ledbettj/systemd-journal/issues/88 It was fixed here: https://github.com/systemd/systemd/commit/2b6df46d21abe8a8b7481e420588a9a129699cf9 It would be great to get this fixed in the LTS. ** 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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959725 Title: Segfault from Native.sd_journal_get_fd Status in systemd package in Ubuntu: New Bug description: The version of libsystemd0 Ubuntu 20.04 has the following issue present in the package: https://github.com/systemd/systemd/issues/15528 https://github.com/ledbettj/systemd-journal/issues/88 It was fixed here: https://github.com/systemd/systemd/commit/2b6df46d21abe8a8b7481e420588a9a129699cf9 It would be great to get this fixed in the LTS. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1959725/+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 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)
** Changed in: systemd (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1739672 Title: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial) Status in glibc package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Bug description: When testing MAAS on Bionic, we noticed sluggish performance that we could not immediately explain. After comparing the results from a run of the test suite on Xenial to a run on Bionic, we determined that the slowdowns had to do with DNS lookups. In particular, if MAAS attempts to resolve a hostname using getaddrinfo() and the call fails, on Xenial the negative result is returned in a fraction of a second. On Bionic, the negative result is returned in ~1.6 seconds, according to some measures. ### To run the test ### git clone https://github.com/mpontillo/test-getaddrinfo cd test-getaddrinfo make ### Results on Xenial ### $ time ./test not-a-real-hostname Trying to resolve: not-a-real-hostname getaddrinfo errno: Success getaddrinfo() return value: -2 (Name or service not known) real 0m0.015s user 0m0.000s sys 0m0.000s ### Results on Bionic ### $ time ./test not-a-real-hostname Trying to resolve: not-a-real-hostname getaddrinfo errno: Resource temporarily unavailable getaddrinfo() return value: -3 (Temporary failure in name resolution) real 0m1.609s user 0m0.004s sys 0m0.000s To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1739672/+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 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)
$ systemd-resolve --status 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 8 (vethJWPPL8) Current Scopes: LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no Link 4 (lxdbr0) Current Scopes: LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no Link 3 (eno1) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 192.168.1.1 Link 2 (enp4s0) Current Scopes: none LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1739672 Title: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial) Status in glibc package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Bug description: When testing MAAS on Bionic, we noticed sluggish performance that we could not immediately explain. After comparing the results from a run of the test suite on Xenial to a run on Bionic, we determined that the slowdowns had to do with DNS lookups. In particular, if MAAS attempts to resolve a hostname using getaddrinfo() and the call fails, on Xenial the negative result is returned in a fraction of a second. On Bionic, the negative result is returned in ~1.6 seconds, according to some measures. ### To run the test ### git clone https://github.com/mpontillo/test-getaddrinfo cd test-getaddrinfo make ### Results on Xenial ### $ time ./test not-a-real-hostname Trying to resolve: not-a-real-hostname getaddrinfo errno: Success getaddrinfo() return value: -2 (Name or service not known) real 0m0.015s user 0m0.000s sys 0m0.000s ### Results on Bionic ### $ time ./test not-a-real-hostname Trying to resolve: not-a-real-hostname getaddrinfo errno: Resource temporarily unavailable getaddrinfo() return value: -3 (Temporary failure in name resolution) real 0m1.609s user 0m0.004s sys 0m0.000s To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1739672/+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 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)
The issue is with the systemd resolver not with glibc. With systemd-resolve IP in /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 $ time ./test not-a-hostname Trying to resolve: not-a-hostname getaddrinfo errno: No such file or directory getaddrinfo() return value: -2 (Name or service not known) real0m10.076s user0m0.001s sys 0m0.000s Without systemd-resolve in /etc/resolv.conf. I changed it to point to my local DNS server directly. # 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 nameserver 192.168.1.1 $ time ./test not-a-hostname Trying to resolve: not-a-hostname getaddrinfo errno: No such file or directory getaddrinfo() return value: -2 (Name or service not known) real0m0.097s user0m0.001s sys 0m0.000s ** Changed in: glibc (Ubuntu) Status: New => Invalid -- 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/1739672 Title: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial) Status in glibc package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Bug description: When testing MAAS on Bionic, we noticed sluggish performance that we could not immediately explain. After comparing the results from a run of the test suite on Xenial to a run on Bionic, we determined that the slowdowns had to do with DNS lookups. In particular, if MAAS attempts to resolve a hostname using getaddrinfo() and the call fails, on Xenial the negative result is returned in a fraction of a second. On Bionic, the negative result is returned in ~1.6 seconds, according to some measures. ### To run the test ### git clone https://github.com/mpontillo/test-getaddrinfo cd test-getaddrinfo make ### Results on Xenial ### $ time ./test not-a-real-hostname Trying to resolve: not-a-real-hostname getaddrinfo errno: Success getaddrinfo() return value: -2 (Name or service not known) real 0m0.015s user 0m0.000s sys 0m0.000s ### Results on Bionic ### $ time ./test not-a-real-hostname Trying to resolve: not-a-real-hostname getaddrinfo errno: Resource temporarily unavailable getaddrinfo() return value: -3 (Temporary failure in name resolution) real 0m1.609s user 0m0.004s sys 0m0.000s To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1739672/+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 1739672] Re: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial)
$ time ./test not-a-real-hostname Trying to resolve: not-a-real-hostname getaddrinfo errno: No such file or directory getaddrinfo() return value: -2 (Name or service not known) real0m10.007s user0m0.001s sys 0m0.001s -- 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/1739672 Title: Regression in getaddrinfo(): calls block for much longer on Bionic (compared to Xenial) Status in glibc package in Ubuntu: New Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Bug description: When testing MAAS on Bionic, we noticed sluggish performance that we could not immediately explain. After comparing the results from a run of the test suite on Xenial to a run on Bionic, we determined that the slowdowns had to do with DNS lookups. In particular, if MAAS attempts to resolve a hostname using getaddrinfo() and the call fails, on Xenial the negative result is returned in a fraction of a second. On Bionic, the negative result is returned in ~1.6 seconds, according to some measures. ### To run the test ### git clone https://github.com/mpontillo/test-getaddrinfo cd test-getaddrinfo make ### Results on Xenial ### $ time ./test not-a-real-hostname Trying to resolve: not-a-real-hostname getaddrinfo errno: Success getaddrinfo() return value: -2 (Name or service not known) real 0m0.015s user 0m0.000s sys 0m0.000s ### Results on Bionic ### $ time ./test not-a-real-hostname Trying to resolve: not-a-real-hostname getaddrinfo errno: Resource temporarily unavailable getaddrinfo() return value: -3 (Temporary failure in name resolution) real 0m1.609s user 0m0.004s sys 0m0.000s To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1739672/+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)
I have verified that smoser changes do work with MAAS.
Testing steps:
1. Generated xenial amd64 image stream using smosers PPA.
2. Installed MAAS.
3. Removed the workaround in MAAS.
4. Imported the xenial amd64 image with smosers PPA.
5. Entered rescue mode.
6. Pinged google.com. (Worked)
7. Exited rescue mode.
8. Ran internet connectivity test. (Passed)
9. Ran commissioning with SSH.
10. Pinged google.com. (Worked)
--
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
#
[Touch-packages] [Bug 1629972] Re: networking stop incorrectly disconnects from (network) root filesystem
** Changed in: maas Milestone: 2.1.1 => 2.1.2 -- 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 1521618] Re: wrong subnet in DHCP answer when multiple networks are present
** Changed in: maas
Status: Triaged => In Progress
** Also affects: maas/1.9
Importance: Undecided
Status: New
** Changed in: maas/1.9
Status: New => In Progress
** Changed in: maas/1.9
Milestone: None => 1.9.3
** Changed in: maas/1.9
Importance: Undecided => High
** Changed in: maas
Importance: Critical => High
** Changed in: maas
Assignee: (unassigned) => Blake Rouse (blake-rouse)
** Changed in: maas/1.9
Assignee: (unassigned) => Trent Lloyd (lathiat)
--
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:
wrong subnet in DHCP answer when multiple networks are present
Status in MAAS:
In Progress
Status in MAAS 1.9 series:
In Progress
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":
[Touch-packages] [Bug 1521618] Re: wrong subnet in DHCP answer when multiple networks are present
Okay I have played around with this even more and its just not going to
work without fixing isc-dhcp itself. Here is an example configuration,
where the gateway is set in one shared-network and not in the other.
When the machine boots it gets the gateway from the other shared-
network.
http://paste.ubuntu.com/15273844/
Now if you re-order the configuration and place the one without the
gateway first it works as expected. But this will not work as the
ordering can never correct as described in my previous comment.
--
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:
wrong subnet in DHCP answer when multiple networks are present
Status in MAAS:
Triaged
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":
[Touch-packages] [Bug 1521618] Re: wrong subnet in DHCP answer when multiple networks are present
Okay so what needs to be done to fix this issue is to order the subnets
in the generated configuration where the ones without gateways come
first and the ones with gateways follow. This causes isc-dhcp to work
correctly. This might be an issue with shared-network because the order
of the subnets can only go so far before the order of shared-network
breaks it. That is to say if there are 2 shared networks each with 2
subnets and one of each have a gateway defined then one of the 4 will
have an issue as the order in that case cannot be enforced.
Note for next-server:
You also need to set next-server on each subnet to make sure that it can
communicate back to the rack controller on that subnet. If not the PXE client
will select the IP from where it recieved the DHCP response which can be a
different subnet.
I think it might be best to say you can only provide DHCP to subnets
that a rack controller has an IP address in. Without it the machines
will fail to PXE boot. Or we don't enforce it which is legal and might
be a network configuration that the administrator wants, but might be
surprising to other users of MAAS.
--
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:
wrong subnet in DHCP answer when multiple networks are present
Status in MAAS:
Triaged
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":
[Touch-packages] [Bug 1521618] Re: wrong subnet in DHCP answer when multiple networks are present
** Changed in: maas
Importance: Medium => Critical
** Changed in: maas
Milestone: None => 2.0.0
--
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:
wrong subnet in DHCP answer when multiple networks are present
Status in MAAS:
Triaged
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
More help :
[Touch-packages] [Bug 1376531] Re: Voice audio during phone call is muffled
I will need to check with the latest release. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dialer-app in Ubuntu. https://bugs.launchpad.net/bugs/1376531 Title: Voice audio during phone call is muffled Status in dialer-app package in Ubuntu: New Bug description: On my Nexus 4 with T-Mobile the person I am talking to complains about the audio quality. I have listened to the receiving end of the call and it sounds very muffled and hard to understand. If I turn on the speaker mode the audio is fixed and the person can hear me. I have tried holding the phone away from my face while not in speaker mode and it does not fix the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dialer-app/+bug/1376531/+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 1360403] Re: MMS does not work with T-Mobile US
Yes please! Preventing me from using Ubuntu Phone on my Nexus 4. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc-android-config in Ubuntu. https://bugs.launchpad.net/bugs/1360403 Title: MMS does not work with T-Mobile US Status in lxc-android-config package in Ubuntu: Triaged Status in nuntium package in Ubuntu: Confirmed Status in ofono package in Ubuntu: Confirmed Status in ubuntu-download-manager package in Ubuntu: Confirmed Bug description: My /var/lib/ofono/*/gprs file contains: [Settings] Powered=1 RoamingAllowed=0 [context1] Name=T-Mobile GPRS AccessPointName=fast.t-mobile.com Username= Password= Type=internet Protocol=ipv6 MessageProxy= MessageCenter=http://mms.msg.eng.t-mobile.com/mms/wapenc I guess bug #1331813 is getting in the way of IPv6 working, so I was told to try 'Protocol=ip', but it doesn't work either. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc-android-config/+bug/1360403/+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
Has the Utopic image from daily been promoted to releases to fix this issue? ** Also affects: maas-images Importance: Undecided Status: New ** No longer affects: maas ** Changed in: maas-images Status: New = Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1391354 Title: Failure to boot ephemeral image for Utopic Fast Installer deployment: no ID_PATH for iSCSI device any more Status in Maas image builders: Confirmed 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-images/+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
