[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