[Touch-packages] [Bug 2016908] Re: udev fails to make prctl() syscall with apparmor=0 (as used by maas by default)
** Changed in: maas
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2016908
Title:
udev fails to make prctl() syscall with apparmor=0 (as used by maas by
default)
Status in AppArmor:
New
Status in MAAS:
Fix Committed
Status in maas-images:
Invalid
Status in apparmor package in Ubuntu:
New
Status in linux package in Ubuntu:
Fix Committed
Status in systemd package in Ubuntu:
Invalid
Status in apparmor source package in Lunar:
New
Status in linux source package in Lunar:
Fix Committed
Status in systemd source package in Lunar:
New
Bug description:
I'm assuming the image being used for these deploys is 20230417 or
20230417.1 based on the fact that I saw a 6.2 kernel being used which
I don't believe was part of the 20230319 serial. I don't have access
to the maas server, so I can't directly check any log files.
MAAS Version: 3.3.2
Here's where the serial log indicates it can't download the squashfs. The
full log is attached as scobee-lunar-no-squashfs.log (there are some other
console message intermixed):
no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf
/run/net6
-*.conf
::
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
date/squa[ 206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes,
fsverity
=yes
shfs
:: mount_squash downloading
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
4/lunar/candidate/squashfs to /root.tmp.img
Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
wget: can't connect to remote host (10.229.32.21): Network is unreachable
:: mount -t squashfs -o loop '/root.tmp.img' '/root.tmp'
mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
done.
Still gathering logs and info and will update as I go.
Kernel Bug / Apparmor
reproducer
$ wget
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-kernel
$ wget
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-initrd
$ qemu-system-x86_64 -nographic -m 2G -kernel ./boot-kernel -initrd
./boot-initrd -append 'console=ttyS0 break=modules apparmor=0'
#start the VM
Starting systemd-udevd version 252.5-2ubuntu3
Spawning shell within the initramfs
BusyBox v1.35.0 (Ubuntu 1:1.35.0-4ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs) udevadm info --export-db
Failed to set death signal: Invalid argument
Observe that udevadm fails to setup death signal, with in systemd code
is this
https://github.com/systemd/systemd/blob/08c2f9c626e0f0052d505b1b7e52f335c0fbfa1d/src/basic/process-
util.c#L1252
if (flags & (FORK_DEATHSIG|FORK_DEATHSIG_SIGINT))
if (prctl(PR_SET_PDEATHSIG, (flags & FORK_DEATHSIG_SIGINT) ?
SIGINT : SIGTERM) < 0) {
log_full_errno(prio, errno, "Failed to set death
signal: %m");
_exit(EXIT_FAILURE);
}
workaround set kernel commandline to `apparmor=1`
MAAS bug
Why is maas setting `apparmor=0` ? Ubuntu shouldn't be used without apparmor.
Even for deployment and commisioning.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/2016908/+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 1869116] Re: smartctl-validate is borked in a recent release
** Changed in: maas
Status: Triaged => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1869116
Title:
smartctl-validate is borked in a recent release
Status in lxd:
New
Status in MAAS:
Fix Committed
Status in MAAS 2.7 series:
New
Status in MAAS 2.8 series:
New
Bug description:
Bug (maybe?) details first, diatribe second.
Bug Summary: multi-hdd / raid with multiple drives / multiple devices
or something along those lines cannot be commissioned anymore: 2.4.x
worked fine, 2.7.0 does not.
Here is the script output of smartctl-validate:
-
# /dev/sda (Model: PERC 6/i, Serial: 6842b2b0740e9900260e66c9220df4ac)
Unable to run 'smartctl-validate': Storage device 'PERC 6/i' with serial
'6842b2b0740e9900260e66c9220df4ac' not found!
This indicates the storage device has been removed or the OS is unable to
find it due to a hardware failure. Please re-commission this node to
re-discover the storage devices, or delete this device manually.
Given parameters:
{'storage': {'argument_format': '{path
}', 'type': 'storage', 'value': {'id_path':
'/dev/disk/by-id/wwn-0x6842b2b0740e9900260e66c9220df4ac', 'model': 'PERC 6/i',
'name': 'sda', 'physical_blockdevice_id': 33, 'serial':
'6842b2b0740e9900260e66c9220df4ac'
}
}
}
Discovered storage devices: [
{'NAME': 'sda', 'MODEL': 'PERC_6/i', 'SERIAL':
'6842b2b0740e9900260e66c9220df4ac'
},
{'NAME': 'sdb', 'MODEL': 'PERC_6/i', 'SERIAL':
'6842b2b0740e9900260e66f924ecece0'
},
{'NAME': 'sr0', 'MODEL': 'TEAC_DVD-ROM_DV-28SW', 'SERIAL':
'10092013112645'
}
]
Discovered interfaces: {'xx: xx: xx: xx: xx: xx': 'eno1'
}
-
-
# /dev/sdb (Model: PERC 6/i, Serial: 6842b2b0740e9900260e66f924ecece0)
Unable to run 'smartctl-validate': Storage device 'PERC 6/i' with serial
'6842b2b0740e9900260e66f924ecece0' not found!
This indicates the storage device has been removed or the OS is unable to
find it due to a hardware failure. Please re-commission this node to
re-discover the storage devices, or delete this device manually.
Given parameters: {'storage': {'argument_format': '{path
}', 'type': 'storage', 'value': {'id_path':
'/dev/disk/by-id/wwn-0x6842b2b0740e9900260e66f924ecece0', 'model': 'PERC 6/i',
'name': 'sdb', 'physical_blockdevice_id': 34, 'serial':
'6842b2b0740e9900260e66f924ecece0'
}
}
}
Discovered storage devices: [
{'NAME': 'sda', 'MODEL': 'PERC_6/i', 'SERIAL':
'6842b2b0740e9900260e66c9220df4ac'
},
{'NAME': 'sdb', 'MODEL': 'PERC_6/i', 'SERIAL':
'6842b2b0740e9900260e66f924ecece0'
},
{'NAME': 'sr0', 'MODEL': 'TEAC_DVD-ROM_DV-28SW', 'SERIAL':
'10092013112645'
}
]
Discovered interfaces: {'xx: xx: xx: xx: xx: xx': 'eno1'
}
-
You can see that it says the storage cannot be found and immediately
lists it as a discovered device. It does it for both tests (one for
each drive), and for both servers
Bug Details:
I had maas 2.4.x for the longest time over my journey (see below journey) and
have never had any problems re-commissioning (or deleting and re-discovering
over boot PXE) 2 of my servers (r610, r710).
r610 has an iPERC 6, four 10K X00GB drives configured in a RAID10, 1 virtual
disk.
r710 has an iPERC 6, 6x 2TB drives, configured in a RAID10, 2 virtual disks
So commission after commission trying to get through my journey, 0
problems. After I finally get everything figured out on the juju,
network/vlan, quad-nic end, I go to re-commission and I cannot.
smartctl-validate fails on both, over and over again. I even destroyed
and re-created the raid/VDs, still not.
After spending so much time on it I remembered that it was the first
time I had tried to re-commission these two servers since doing an
upgrade from 2.4.x->2.7 in an effort to use the updated KVM
integration to add a couple more guests. Once I got all everything
figured out I went to re-commission everything and boom.
[Upgrade path notes]
In full disclosure, in case this matters. I was on apt install of 2.4.x and
using snap for 2.7, except it didn't work. So I read on how to do apt 2.7 and
did that and did not uninstall snap 2.7 yet. I wanted to migrate from apt to
snap but do not know how to without losing all maas data and could not find
docs on it, so a problem for another day. But in case that is part of the
problem for some odd reason, I wanted to share.
[Diatribe]
My journey to get maas+juju+openstack+kubernets has been less then stellar. I
have ran into problem after problem; albeit some of which were my own. I am so
close, after spending the last 6 months on/off when I had time, and really
hardcore the last 4 days. The last half day of which has been this little gem.
Maas has been pretty fun to work with
[Touch-packages] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)
** Changed in: maas
Status: Fix Released => Fix Committed
--
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): icmp_seq=1
[Touch-packages] [Bug 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)
** Changed in: maas
Status: In Progress => Fix Committed
--
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:
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 1640147] Re: [2.1] rsyslog is flooded with "no link-local IPv6 address for $IFACE" on commissioning
** Changed in: maas/2.1 Status: In Progress => Fix Committed -- 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 Committed 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
** Changed in: maas Status: In Progress => Fix Committed -- 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: New 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 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses
** Changed in: maas Status: In Progress => Fix Committed -- 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 Committed Status in initramfs-tools package in Ubuntu: In Progress Status in isc-dhcp package in Ubuntu: In Progress Status in klibc package in Ubuntu: Won't Fix Status in open-iscsi package in Ubuntu: In Progress Status in initramfs-tools source package in Xenial: Triaged Status in isc-dhcp source package in Xenial: In Progress Status in klibc source package in Xenial: Won't Fix Status in open-iscsi source package in Xenial: In Progress Status in initramfs-tools source package in Yakkety: In Progress Status in isc-dhcp source package in Yakkety: In Progress Status in klibc source package in Yakkety: Won't Fix Status in open-iscsi source package in Yakkety: In Progress 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) [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 1521618] Re: [1.9] wrong subnet in DHCP answer when multiple networks are present
** Changed in: maas
Status: In Progress => Fix Committed
--
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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
[Touch-packages] [Bug 1521618] Re: wrong subnet in DHCP answer when multiple networks are present
** Changed in: maas/1.9
Status: In Progress => Fix Committed
--
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:
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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More
[Touch-packages] [Bug 1313550] Re: ping does not work as a normal user on trusty tarball cloud images.
** Changed in: maas Status: Confirmed = Fix Committed -- 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/1313550 Title: ping does not work as a normal user on trusty tarball cloud images. Status in The curt installer: Confirmed Status in MAAS: Fix Committed Status in curtin package in Ubuntu: Confirmed Status in iputils package in Ubuntu: Fix Released Status in lxc package in Ubuntu: Confirmed Status in maas package in Ubuntu: Confirmed Status in tar package in Ubuntu: Fix Released Status in lxc source package in Precise: Confirmed Status in tar source package in Precise: Confirmed Status in curtin source package in Saucy: Won't Fix Status in lxc source package in Saucy: Won't Fix 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: Confirmed Status in maas source package in Trusty: Confirmed Status in tar source package in Trusty: Fix Released Bug description: With trusty, /bin/ping relies on having extended attributes and kernel capabilities to gain the cap_net_raw+p capability. This allows removing the suid bit. However, the tarball cloud images do not preserve the extended attributes, and thus /bin/ping does not work on a system derived from them. Summary of problem per package: * lxc: ubuntu cloud template needs to extract * download template needs to extract with xattr flags * server side download creation tools need xattr flags * [unconfirmed] tarball caches need creation and extraction with xattr flags * tar: need the '--xattr' and '--acl' flags backported * maas: uec2roottgz needs to use xattr/acl flags * curtin: extraction needs to use xattr/acl flags. * cloud-image-build: needs to create -root.tar.gz with xattr/acl flags Related Bugs: * bug 1382632: horizon insecure key file permissions * bug 1386237: tar strange behavior with --acl and xattr * bug 1313550: ping broken (xattrs lost in tar extraction) 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
