[Yahoo-eng-team] [Bug 1839491] Re: Manully performed partitioning changes get reverted on reboot
Cloud-init is the one performing the resize and MAAS images are based off the Ubuntu cloud images, it is more an issue with cloud-init and the cloud images than MAAS. ** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: maas Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1839491 Title: Manully performed partitioning changes get reverted on reboot Status in cloud-init: New Status in MAAS: Invalid Bug description: Hello, I am facing an issue where I need to make changes to the initially deployed partition layout, but upon making those changes and rebooting, the partition layout gets reverted. My env: MAAS version: 2.6.0 (7802-g59416a869-0ubuntu1~18.04.1) System vendor: HP System product: ProLiant DL360 Gen9 (780021-S01) System version: Unknown Mainboard product: ProLiant DL360 Gen9 Mainboard firmware version: P89 Mainboard firmware date: 12/27/2015 CPU model: Intel(R) Xeon(R) CPU E5-2690 v3 Deployed (16.04 LTS "Xenial Xerus") Kernel: xenial (ga-16.04) Power type: ipmi Power driver: LAN_2_0 [IPMI 2.0] Power boot type: EFI boot Architecture amd64/generic Minimum Kernel: no minimum kernel Interfaces: eno1, eno2, noe3, eno4, eno49, eno50. Only eno49 is used. Storage: sda Physical 1TB, sdb Physical 1TB. Steps to reproduce: 1. Deploy MAAS with the following partition configuration: sda-part1 536.9 MB Partition fat32 formatted filesystem mounted at /boot/efi sda-part2 100.0 GB Partition ext4 formatted filesystem mounted at / 2. Check the partitions on the node: $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:00 931.5G 0 disk |-sda1 8:10 512M 0 part /boot/efi `-sda2 8:20 931G 0 part / sdb 8:16 0 931.5G 0 disk Here we notice the initial partitioning scheme is not respected. This could be related to the main issue of partitioning changes being reverted, but could also be a separate issue. 3. Boot an ubuntu ISO and go into rescue mode. I used ubuntu-16.04.6 -server-amd64.iso 4. Choose "Do not use a root filesystem" and "Execute a shell in the installer environment". 4. Run the following commands: $ e2fsck -f /dev/sda2 $ resize2fs /dev/sda2 150G $ e2fsck -f /dev/sda2 $ sudo parted /dev/sda (parted) unit GiB print (parted) resizepart Partition number? 2 End? 200GiB (parted) print You should see partition 2 resized. (parted) quit $ e2fsck -f /dev/sda2 5. Confirm $ fdisk -l 6. Sync writes $ sync 7. Reboot the node. Remove ISO image. 8. Let system boot, check partitions again: $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:00 931.5G 0 disk |-sda1 8:10 512M 0 part /boot/efi `-sda2 8:20 931G 0 part / sdb 8:16 0 931.5G 0 disk We can see see that the changes were reverted. If I remove cloud-init, I can successfully re-partition and reboot, without the changes being reverted. Attached logs before and after repartition. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1839491/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1835008] Re: network_v2 does not set mtu on eni config
** Also affects: curtin Importance: Undecided Status: New ** Changed in: maas Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1835008 Title: network_v2 does not set mtu on eni config Status in cloud-init: New Status in curtin: New Status in MAAS: Invalid Bug description: The MTU is not set on the bond, nor vlans on the bond, nor the bridges attached to the vlans on a network_v2 configuration. It's only set on the underlying interfaces (eth0, eth1) This does not happen if given a network_v1 configuration. (I'm deploying ubuntu xenial via MAAS 2.6.0, setting force_v1_network_yaml=true is my current workaround.) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1835008/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1621615] Re: network not configured when ipv6 netbooted into cloud-init
** Changed in: maas Status: In Progress => Invalid ** Changed in: maas Assignee: LaMont Jones (lamont) => (unassigned) ** Changed in: maas Milestone: 2.1.3 => None -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1621615 Title: network not configured when ipv6 netbooted into cloud-init Status in cloud-init: Fix Released Status in MAAS: Invalid Status in cloud-init package in Ubuntu: Fix Released Status in cloud-initramfs-tools package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in cloud-initramfs-tools source package in Xenial: Fix Released Status in cloud-init source package in Yakkety: Fix Released Status in cloud-initramfs-tools source package in Yakkety: Fix Released Bug description: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1621507 talks of how IPv6 netboot with iscsi root disk doesn't work, blocking IPv6-only MAAS. After I hand-walked busybox through getting an IPv6 address, everything worked just fine until cloud-init couldn't fetch the instance data, because it insisted on bringing up the interface in IPv4, and there is no IPv4 DHCP on that vlan. Please work with initramfs and friends on getting IPv6 netboot to actually configure the interface. This may be as simple as teaching it about "inet6 dhcp" interfaces, and bolting the pieces together. Note that "use radvd" is not really an option for our use case. Related bugs: * bug 1621507: initramfs-tools configure_networking() fails to dhcp IPv6 addresses * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6) * bug 1639930: initramfs network configuration ignored if only ip6= on kernel command line [Impact] It is not possible to enlist, commmission, or deploy with MAAS in an IPv6-only environment. Anyone wanting to netboot with a network root filesystem in an IPv6-only environment is affected. This upload addresses this by accepting, using, and forwarding any IPV6* variables from the initramfs boot. (See https://launchpad.net/bugs/1621507) [Test Case] See Bug 1229458. Configure radvd, dhcpd, and tftpd for your IPv6-only netbooting world. Pass the boot process an IPv6 address to fetch instance-data from, and see it fail to configure the network. [Regression Potential] 1) If the booting host is in a dual-boot environment, and the instance-dat URL uses a hostname that has both A and RRsets, the booting host may try to talk IPv6 to get instance data. If the instance-data providing host is only allowing that to happen over IPv4, it will fail. (It also represents a configuraiton issue on the providing host...) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1621615/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1686485] Re: cc_ntp fails to work when deploying ubuntu-core
** Also affects: maas Importance: Undecided Status: New ** Changed in: maas Status: New => Triaged ** Changed in: maas Importance: Undecided => High ** Changed in: maas Milestone: None => 2.2.1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1686485 Title: cc_ntp fails to work when deploying ubuntu-core Status in cloud-init: New Status in MAAS: Triaged Bug description: When deploying Ubuntu Core with MAAS I am seeing this error in /var/log/cloud-init.log: 2017-04-26 18:11:45,172 - cc_apt_configure.py[DEBUG]: Nothing to do: No apt config and running on snappy 2017-04-26 18:11:45,172 - handlers.py[DEBUG]: finish: modules-config/config-apt-configure: SUCCESS: config-apt-configure ran successfully 2017-04-26 18:11:45,172 - stages.py[DEBUG]: Running module ntp () with frequency once-per-instance 2017-04-26 18:11:45,172 - handlers.py[DEBUG]: start: modules-config/config-ntp: running config-ntp with frequency once-per-instance 2017-04-26 18:11:45,173 - util.py[DEBUG]: Writing to /var/lib/cloud/instances/mpcgqp/sem/config_ntp - wb: [420] 24 bytes 2017-04-26 18:11:45,173 - helpers.py[DEBUG]: Running config-ntp using lock () 2017-04-26 18:11:45,175 - util.py[DEBUG]: Writing to /var/lib/cloud/instances/mpcgqp/sem/update_sources - wb: [420] 24 bytes 2017-04-26 18:11:45,176 - helpers.py[DEBUG]: Running update-sources using lock () 2017-04-26 18:11:45,176 - util.py[DEBUG]: Running command ['apt-get', '--option=Dpkg::Options::=--force-confold', '--option=Dpkg::options::=--force-unsafe-io', '--assume-yes', '--quiet', 'update'] with allowed return codes [0] (shell=False, capture=False) 2017-04-26 18:11:45,186 - util.py[DEBUG]: apt-update [apt-get --option=Dpkg::Options::=--force-confold --option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet update] took 0.010 seconds 2017-04-26 18:11:45,186 - util.py[DEBUG]: Running command ['apt-get', '--option=Dpkg::Options::=--force-confold', '--option=Dpkg::options::=--force-unsafe-io', '--assume-yes', '--quiet', 'install', 'ntp'] with allowed return codes [0] (shell=False, capture=False) 2017-04-26 18:11:45,191 - util.py[DEBUG]: apt-install [apt-get --option=Dpkg::Options::=--force-confold --option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install ntp] took 0.005 seconds 2017-04-26 18:11:45,193 - util.py[DEBUG]: Reading from /etc/cloud/templates/ntp.conf.ubuntu.tmpl (quiet=False) 2017-04-26 18:11:45,193 - util.py[DEBUG]: Read 2509 bytes from /etc/cloud/templates/ntp.conf.ubuntu.tmpl 2017-04-26 18:11:45,193 - templater.py[DEBUG]: Rendering content of '/etc/cloud/templates/ntp.conf.ubuntu.tmpl' using renderer jinja 2017-04-26 18:11:45,197 - util.py[DEBUG]: Writing to /etc/ntp.conf - wb: [420] 2330 bytes 2017-04-26 18:11:45,200 - handlers.py[DEBUG]: finish: modules-config/config-ntp: FAIL: running config-ntp with frequency once-per-instance 2017-04-26 18:11:45,200 - util.py[WARNING]: Running module ntp () failed 2017-04-26 18:11:45,202 - util.py[DEBUG]: Running module ntp () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 787, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_ntp.py", line 80, in handle write_ntp_config_template(ntp_cfg, cloud) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_ntp.py", line 126, in write_ntp_config_template templater.render_to_file(template_fn, NTP_CONF, params) File "/usr/lib/python3/dist-packages/cloudinit/templater.py", line 131, in render_to_file util.write_file(outfn, contents, mode=mode) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1711, in write_file with open(filename, omode) as fh: OSError: [Errno 30] Read-only file system: '/etc/ntp.conf' Note: This doesn't break deployment. Deployment still succeeds, except for ntp syncing is not setup to point to MAAS. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1686485/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1686485] [NEW] cc_ntp fails to work when deploying ubuntu-core
Public bug reported: When deploying Ubuntu Core with MAAS I am seeing this error in /var/log /cloud-init.log: 2017-04-26 18:11:45,172 - cc_apt_configure.py[DEBUG]: Nothing to do: No apt config and running on snappy 2017-04-26 18:11:45,172 - handlers.py[DEBUG]: finish: modules-config/config-apt-configure: SUCCESS: config-apt-configure ran successfully 2017-04-26 18:11:45,172 - stages.py[DEBUG]: Running module ntp () with frequency once-per-instance 2017-04-26 18:11:45,172 - handlers.py[DEBUG]: start: modules-config/config-ntp: running config-ntp with frequency once-per-instance 2017-04-26 18:11:45,173 - util.py[DEBUG]: Writing to /var/lib/cloud/instances/mpcgqp/sem/config_ntp - wb: [420] 24 bytes 2017-04-26 18:11:45,173 - helpers.py[DEBUG]: Running config-ntp using lock () 2017-04-26 18:11:45,175 - util.py[DEBUG]: Writing to /var/lib/cloud/instances/mpcgqp/sem/update_sources - wb: [420] 24 bytes 2017-04-26 18:11:45,176 - helpers.py[DEBUG]: Running update-sources using lock () 2017-04-26 18:11:45,176 - util.py[DEBUG]: Running command ['apt-get', '--option=Dpkg::Options::=--force-confold', '--option=Dpkg::options::=--force-unsafe-io', '--assume-yes', '--quiet', 'update'] with allowed return codes [0] (shell=False, capture=False) 2017-04-26 18:11:45,186 - util.py[DEBUG]: apt-update [apt-get --option=Dpkg::Options::=--force-confold --option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet update] took 0.010 seconds 2017-04-26 18:11:45,186 - util.py[DEBUG]: Running command ['apt-get', '--option=Dpkg::Options::=--force-confold', '--option=Dpkg::options::=--force-unsafe-io', '--assume-yes', '--quiet', 'install', 'ntp'] with allowed return codes [0] (shell=False, capture=False) 2017-04-26 18:11:45,191 - util.py[DEBUG]: apt-install [apt-get --option=Dpkg::Options::=--force-confold --option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install ntp] took 0.005 seconds 2017-04-26 18:11:45,193 - util.py[DEBUG]: Reading from /etc/cloud/templates/ntp.conf.ubuntu.tmpl (quiet=False) 2017-04-26 18:11:45,193 - util.py[DEBUG]: Read 2509 bytes from /etc/cloud/templates/ntp.conf.ubuntu.tmpl 2017-04-26 18:11:45,193 - templater.py[DEBUG]: Rendering content of '/etc/cloud/templates/ntp.conf.ubuntu.tmpl' using renderer jinja 2017-04-26 18:11:45,197 - util.py[DEBUG]: Writing to /etc/ntp.conf - wb: [420] 2330 bytes 2017-04-26 18:11:45,200 - handlers.py[DEBUG]: finish: modules-config/config-ntp: FAIL: running config-ntp with frequency once-per-instance 2017-04-26 18:11:45,200 - util.py[WARNING]: Running module ntp () failed 2017-04-26 18:11:45,202 - util.py[DEBUG]: Running module ntp () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 787, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_ntp.py", line 80, in handle write_ntp_config_template(ntp_cfg, cloud) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_ntp.py", line 126, in write_ntp_config_template templater.render_to_file(template_fn, NTP_CONF, params) File "/usr/lib/python3/dist-packages/cloudinit/templater.py", line 131, in render_to_file util.write_file(outfn, contents, mode=mode) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1711, in write_file with open(filename, omode) as fh: OSError: [Errno 30] Read-only file system: '/etc/ntp.conf' Note: This doesn't break deployment. Deployment still succeeds, except for ntp syncing is not setup to point to MAAS. ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1686485 Title: cc_ntp fails to work when deploying ubuntu-core Status in cloud-init: New Bug description: When deploying Ubuntu Core with MAAS I am seeing this error in /var/log/cloud-init.log: 2017-04-26 18:11:45,172 - cc_apt_configure.py[DEBUG]: Nothing to do: No apt config and running on snappy 2017-04-26 18:11:45,172 - handlers.py[DEBUG]: finish: modules-config/config-apt-configure: SUCCESS: config-apt-configure ran successfully 2017-04-26 18:11:45,172 - stages.py[DEBUG]: Running module ntp () with frequency once-per-instance 2017-04-26 18:11:45,172 - handlers.py[DEBUG]: start: modules-config/config-ntp: running config-ntp with frequency once-per-instance 2017-04-26 18:11:45,173 - util.py[DEBUG]: Writing to /var/lib/cloud/instances/mpcgqp/sem/config_ntp - wb: [420] 24 bytes 2017-04-26 18:11:45,173 - helpers.py[DEBUG]: Running config-ntp using lock () 2017-04-26 18:11:45,175 - util.py[DEBUG]: Writing to
[Yahoo-eng-team] [Bug 1664712] [NEW] Setting level on reporter breaks cloud-init
Public bug reported:
example config:
'reporting': {
'maas': {
'type': 'webhook',
'endpoint': absolute_reverse(
'metadata-status', args=[node.system_id],
base_url=base_url),
'consumer_key': token.consumer.key,
'token_key': token.key,
'token_secret': token.secret,
'level': 'INFO', # <--- breaks cloud-init
}
}
[ 22.612772] cloud-init[987]: 2017-02-14 20:34:37,062 - util.py[WARNING]:
failed stage init
[ 22.619693] cloud-init[987]: failed run of stage init
[ 22.620822] cloud-init[987]:
[ 22.621872] cloud-init[987]: Traceback (most recent call last):
[ 22.624257] cloud-init[987]: File
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 524, in
status_wrapper
[ 22.625446] cloud-init[987]: ret = functor(name, args)
[ 22.628192] cloud-init[987]: File
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 197, in main_init
[ 22.629186] cloud-init[987]: apply_reporting_cfg(init.cfg)
[ 22.632254] cloud-init[987]: File
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 140, in
apply_reporting_cfg
[ 22.633267] cloud-init[987]:
reporting.update_configuration(cfg.get('reporting'))
[ 22.636398] cloud-init[987]: File
"/usr/lib/python3/dist-packages/cloudinit/reporting/__init__.py", line 35, in
update_configuration
[ 22.637576] cloud-init[987]: instance = cls(**handler_config)
[ 22.640352] cloud-init[987]: TypeError: __init__() got an unexpected keyword
argument 'level'
[ 22.641405] cloud-init[987]:
** Affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1664712
Title:
Setting level on reporter breaks cloud-init
Status in cloud-init:
New
Bug description:
example config:
'reporting': {
'maas': {
'type': 'webhook',
'endpoint': absolute_reverse(
'metadata-status', args=[node.system_id],
base_url=base_url),
'consumer_key': token.consumer.key,
'token_key': token.key,
'token_secret': token.secret,
'level': 'INFO', # <--- breaks cloud-init
}
}
[ 22.612772] cloud-init[987]: 2017-02-14 20:34:37,062 - util.py[WARNING]:
failed stage init
[ 22.619693] cloud-init[987]: failed run of stage init
[ 22.620822] cloud-init[987]:
[ 22.621872] cloud-init[987]: Traceback (most recent call last):
[ 22.624257] cloud-init[987]: File
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 524, in
status_wrapper
[ 22.625446] cloud-init[987]: ret = functor(name, args)
[ 22.628192] cloud-init[987]: File
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 197, in main_init
[ 22.629186] cloud-init[987]: apply_reporting_cfg(init.cfg)
[ 22.632254] cloud-init[987]: File
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 140, in
apply_reporting_cfg
[ 22.633267] cloud-init[987]:
reporting.update_configuration(cfg.get('reporting'))
[ 22.636398] cloud-init[987]: File
"/usr/lib/python3/dist-packages/cloudinit/reporting/__init__.py", line 35, in
update_configuration
[ 22.637576] cloud-init[987]: instance = cls(**handler_config)
[ 22.640352] cloud-init[987]: TypeError: __init__() got an unexpected
keyword argument 'level'
[ 22.641405] cloud-init[987]:
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1664712/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1574113] Re: curtin/maas don't support multiple (derived) archives/repositories with custom keys
** Also affects: maas/1.9
Importance: Undecided
Status: New
** Changed in: maas/1.9
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1574113
Title:
curtin/maas don't support multiple (derived) archives/repositories
with custom keys
Status in cloud-init:
Fix Released
Status in curtin:
Fix Committed
Status in MAAS:
Fix Released
Status in MAAS 1.9 series:
Won't Fix
Status in cloud-init package in Ubuntu:
Fix Released
Status in curtin package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Committed
Status in curtin source package in Xenial:
Fix Released
Bug description:
[Impact]
* Curtin doesn't support multiple derived archive/repositories with
custom keys as typically deployed in an offline Landscape deployment.
Adding the custom key resulted in an error when processing the
apt_source configuration as provided in this setup.
Curtin has been updated to support the updated apt-source model
implemented in cloud-init as well. Together the existing Landscape
deployments for offline users can now supply an apt-source config
that updates curtin to use the specified derived repository with a
custom key.
[Test Case]
* Install proposed curtin package and deploy a system behind a
Landscape Offline configuration with a derived repo.
PASS: Curtin will successfully accept the derived repo and install the
system from the specified apt repository.
FAIL: Curtin will fail to install the OS with an error like:
W: GPG error: http://100.107.231.166 trusty InRelease:
The following signatures couldn't be verified because the public key
is not available: NO_PUBKEY 2C6F2731D2B38BD3
E: There are problems and -y was used without --force-yes
Unexpected error while running command.
Command: ['chroot', '/tmp/tmpcEfTLw/target', 'eatmydata', 'apt-get',
'--quiet', '--assume-yes',
'--option=Dpkg::options::=--force-unsafe-io',
'--option=Dpkg::Options::=--force-confold', 'install',
'lvm2', 'ifenslave']
Exit code: 100
[Regression Potential]
* Other users of previous curtin 'apt_source' configurations may not
continue to work without re-formatting the apt_source configuration.
[Original Description]
In a customer environment I have to deploy using offline resources (no
internet connection at all), so I created apt mirror and MAAS images
mirror. I configured MAAS to use the local mirrors and I'm able to
commission the nodes but I'm not able to deploy the nodes because
there is no way to add gpg key of the local repo in target before the
'late' stage'.
Using curtin I'm able to add the key but too late, in fact according
with http://bazaar.launchpad.net/~curtin-
dev/curtin/trunk/view/head:/curtin/commands/install.py#L52 "late"
stage is executed after "curthooks" this prevent to add the key.
I checked also apt_config function in curthooks.py I did't see code
that add the key for each mirror.
It should be possible to add gpg public of the repository in maas.
--
configs/config-000.cfg
--
#cloud-config
debconf_selections:
maas: |
cloud-init cloud-init/datasources multiselect MAAS
cloud-init cloud-init/maas-metadata-url string
http://100.107.231.164/MAAS/metadata/
cloud-init cloud-init/maas-metadata-credentials string
oauth_token_key=8eZmzQWSSQzsUkaLnE_token_secret=LKmn8sHgzEXfvzSZePAa9jUXvTMRrFNP_consumer_key=htwDZJFtmv2YvQXhUW
cloud-init cloud-init/local-cloud-config string
apt_preserve_sources_list: true\nmanage_etc_hosts: false\nmanual_cache_clean:
true\nreporting:\n maas: {consumer_key: htwDZJFtmv2YvQXhUW, endpoint:
'http://100.107.231.164/MAAS/metadata/status/node-61b6987c-07a7-11e6-9d23-5254003d2515',\n
token_key: 8eZmzQWSSQzsUkaLnE, token_secret:
LKmn8sHgzEXfvzSZePAa9jUXvTMRrFNP,\ntype: webhook}\nsystem_info:\n
package_mirrors:\n - arches: [i386, amd64]\nfailsafe: {primary:
'http://archive.ubuntu.com/ubuntu', security:
'http://security.ubuntu.com/ubuntu'}\nsearch:\n primary:
['http://100.107.231.166/']\n security: ['http://100.107.231.166/']\n -
arches: [default]\nfailsafe: {primary:
'http://ports.ubuntu.com/ubuntu-ports', security:
'http://ports.ubuntu.com/ubuntu-ports'}\nsearch:\n primary:
['http://ports.ubuntu.com/ubuntu-ports']\n security:
['http://ports.ubuntu.com/ubuntu-ports']\n
late_commands:
maas: [wget, '--no-proxy',
'http://100.107.231.164/MAAS/metadata/latest/by-id/node-61b6987c-07a7-11e6-9d23-5254003d2515/',
'--post-data', 'op=netboot_off', '-O', '/dev/null']
apt_key: ["curtin", "in-target", "--", "sh", "-c", "/usr/bin/wget
[Yahoo-eng-team] [Bug 1604104] [NEW] SRU cloud-init power_condition to trusty
Public bug reported: MAAS uses the power_condition feature to prevent poweroff when enlisting and commissioning with Ubuntu. This works on Xenial but to keep the code path the same and make trusty perform as expected this feature needs to be SRU'd into trusty. ** Affects: cloud-init Importance: Undecided Status: Confirmed ** Changed in: cloud-init Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1604104 Title: SRU cloud-init power_condition to trusty Status in cloud-init: Confirmed Bug description: MAAS uses the power_condition feature to prevent poweroff when enlisting and commissioning with Ubuntu. This works on Xenial but to keep the code path the same and make trusty perform as expected this feature needs to be SRU'd into trusty. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1604104/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1597779] Re: Wily Deployements are failing in Maas
This is an issue with cloud-init not MAAS. ** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: maas Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1597779 Title: Wily Deployements are failing in Maas Status in cloud-init: New Status in MAAS: Invalid Bug description: MAAS Version: 1.9.2 , 1.9.3, 2.0 Beta 8 Problem Description: MAAS Wily Deployments have been failing, Even though End of Life is upon us, it still should at least be addressed, to those who are running regression testing across the distributions. This has failed for me on arm64/amd64 so should be easily reproducible and I have rebuilt MAAS 2.0 recently and still encountering this issue. Maas log: Jun 30 13:39:23 maas-devel maas.node: [INFO] ms10-39-mcdivittb0: Status transition from READY to ALLOCATED Jun 30 13:39:23 maas-devel maas.node: [INFO] ms10-39-mcdivittb0: allocated to user ubuntu Jun 30 13:39:23 maas-devel maas.node: [INFO] ms10-39-mcdivittb0: Status transition from ALLOCATED to DEPLOYING Jun 30 13:39:23 maas-devel maas.power: [INFO] Changing power state (on) of node: ms10-39-mcdivittb0 (4y3h7p) Jun 30 13:39:35 maas-devel maas.power: [INFO] Changed power state (on) of node: ms10-39-mcdivittb0 (4y3h7p) Jun 30 13:42:02 maas-devel maas.node: [INFO] ms10-39-mcdivittb0: Status transition from DEPLOYING to FAILED_DEPLOYMENT Jun 30 13:42:02 maas-devel maas.node: [ERROR] ms10-39-mcdivittb0: Marking node failed: Installation failed (refer to the installation log for more information). At the time Maas Switches the deployment attempt to failed we can see on the Host Console: [ OK ] Started Initial cloud-init job (pre-networking). Starting Initial cloud-init job (metadata service crawler)... [ 61.547288] cloud-init[998]: Cloud-init v. 0.7.7 running 'init' at Thu, 30 Jun 2016 10:02:08 +. Up 61.35 seconds. [ 61.547966] cloud-init[998]: ci-info: Net device info [ 61.548500] cloud-init[998]: ci-info: +--+---+--+---+---+---+ [ 61.549001] cloud-init[998]: ci-info: | Device | Up | Address| Mask | Scope | Hw-Address| [ 61.549483] cloud-init[998]: ci-info: +--+---+--+---+---+---+ [ 61.550051] cloud-init[998]: ci-info: | enp1s0 | True | 10.229.65.139 | 255.255.0.0 | . | fc:15:b4:21:00:c2 | [ 61.550562] cloud-init[998]: ci-info: | enp1s0 | True | fe80::fe15:b4ff:fe21:c2/64 | . | link | fc:15:b4:21:00:c2 | [ 61.551064] cloud-init[998]: ci-info: | enp1s0d1 | False | . | . | . | fc:15:b4:21:00:c3 | [ 61.551582] cloud-init[998]: ci-info: |lo| True | 127.0.0.1 | 255.0.0.0 | . | . | [ 61.552094] cloud-init[998]: ci-info: |lo| True | ::1/128| . | host | . | [ 61.552588] cloud-init[998]: ci-info: | lxcbr0 | True | 10.0.3.1 | 255.255.255.0 | . | 96:55:5e:f3:e8:4d | [ 61.553092] cloud-init[998]: ci-info: | lxcbr0 | True | fe80::9455:5eff:fef3:e84d/64 | . | link | 96:55:5e:f3:e8:4d | [ 61.553568] cloud-init[998]: ci-info: +--+---+--+---+---+---+ [ 61.553971] cloud-init[998]: ci-info: Route IPv4 info+ [ 61.554368] cloud-init[998]: ci-info: +---+-++---+---+---+ [ 61.554762] cloud-init[998]: ci-info: | Route | Destination | Gateway | Genmask| Interface | Flags | [ 61.555161] cloud-init[998]: ci-info: +---+-++---+---+---+ [ 61.61] cloud-init[998]: ci-info: | 0 | 0.0.0.0 | 10.229.0.1 | 0.0.0.0| enp1s0 | UG | [ 61.555956] cloud-init[998]: ci-info: | 1 | 10.0.3.0 | 0.0.0.0 | 255.255.255.0 | lxcbr0 | U | [ 61.556349] cloud-init[998]: ci-info: | 2 | 10.229.0.0 | 0.0.0.0 | 255.255.0.0 | enp1s0 | U | [ 61.556741] cloud-init[998]: ci-info: +---+-++---+---+---+ [ 61.559020] cloud-init[998]: 2016-06-30 10:02:09,115 - url_helper.py[WARNING]: Setting oauth clockskew for 10.229.32.22 to 14849 [ 61.559436] cloud-init[998]: 2016-06-30 10:02:09,115 - handlers.py[WARNING]: failed posting event: start: init-network/check-cache: attempting to read from cache
[Yahoo-eng-team] [Bug 1582323] Re: Commissioning fails when competing cloud metadata resides on disk
** No longer affects: cloud-init ** Changed in: maas Status: Triaged => In Progress ** Changed in: maas Importance: High => Critical ** Changed in: maas Assignee: (unassigned) => Blake Rouse (blake-rouse) ** Changed in: maas Milestone: None => 2.0.0 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1582323 Title: Commissioning fails when competing cloud metadata resides on disk Status in MAAS: In Progress Bug description: A customer reused hardware that had previously deployed a RHEL Overcloud-controller which places metadata on the disk as a legitimate source, that cloud-init looks at by default. When the newly enlisted node appeared it had the name of "overcloud-controller-0" vs. maas- enlist, pulled from the disk metadata which had overridden MAAS' metadata. Commissioning continually failed on all of the nodes until the disk metadata was manually removed (KVM boot Ubuntu ISO, rm -f data or dd zeros to disk). To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1582323/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1582323] Re: Commissioning fails when competing cloud metadata resides on disk
It was recommended by smoser to add this to MAAS: http://paste.ubuntu.com/16683033/ But then it was discovered that will not handle all cases. A kernel parameter would be needed to force only one datasource. ** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: cloud-init Status: New => Confirmed ** Changed in: maas Status: In Progress => Triaged ** Changed in: maas Assignee: Blake Rouse (blake-rouse) => (unassigned) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1582323 Title: Commissioning fails when competing cloud metadata resides on disk Status in cloud-init: Confirmed Status in MAAS: Triaged Bug description: A customer reused hardware that had previously deployed a RHEL Overcloud-controller which places metadata on the disk as a legitimate source, that cloud-init looks at by default. When the newly enlisted node appeared it had the name of "overcloud-controller-0" vs. maas- enlist, pulled from the disk metadata which had overridden MAAS' metadata. Commissioning continually failed on all of the nodes until the disk metadata was manually removed (KVM boot Ubuntu ISO, rm -f data or dd zeros to disk). To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1582323/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1582323] Re: Commissioning fails when competing cloud metadata resides on disk
Scott, What can MAAS do to tell cloud-init that its should use the MAAS datasource first and always in the enlistment and commissioning environment. We don't want cloud-init to look at the disk first in the case of MAAS. ** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: maas Status: New => Triaged ** Changed in: cloud-init Status: New => Confirmed ** Changed in: maas Importance: Undecided => High -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1582323 Title: Commissioning fails when competing cloud metadata resides on disk Status in cloud-init: Confirmed Status in MAAS: Triaged Bug description: A customer reused hardware that had previously deployed a RHEL Overcloud-controller which places metadata on the disk as a legitimate source, that cloud-init looks at by default. When the newly enlisted node appeared it had the name of "overcloud-controller-0" vs. maas- enlist, pulled from the disk metadata which had overridden MAAS' metadata. Commissioning continually failed on all of the nodes until the disk metadata was manually removed (KVM boot Ubuntu ISO, rm -f data or dd zeros to disk). To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1582323/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1577960] Re: [2.0b4] After commissioning, subnet lists 'observed' IP address for machines
This seems like a very strange thing that cloud-init should be doing. Maybe for the first interface that MAAS brings up it makes since for cloud-init to do, but all the other interfaces are brought up by the MAAS commissioning scripts. That process is a direct process as well and does not place any information in /etc/network/interfaces for Ubuntu to even know that those IP addresses should be released. Also their is the matter of getting this into cloud-init and having it work across trusty+. It should be rather simple for the MAAS commissioning script to inject a poweroff script that will be ran at the very end of the shutdown process to release all IP addresses on interfaces. ** Changed in: cloud-init Status: New => Invalid ** Changed in: maas Status: Incomplete => Triaged -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1577960 Title: [2.0b4] After commissioning, subnet lists 'observed' IP address for machines Status in cloud-init: Invalid Status in MAAS: Triaged Bug description: I commissioned a whole bunch of machines, and after it compelted, MAAS showed 'Machines' with 'Observed' IP addresses but machines are now off. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1577960/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1565711] Re: vlan configuration/unconfigured interfaces creates slow boot time
So the configuration that MAAS emits and curtin generates looks correct. Cloud-init just waits for the signal so I actually think the issue is with ifupdown. I have targeted that package as well, will leave the others for now just to track. ** Also affects: ifupdown Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1565711 Title: vlan configuration/unconfigured interfaces creates slow boot time Status in cloud-init: New Status in curtin: New Status in ifupdown: New Status in MAAS: New Bug description: maas: 1.9.1+bzr4543-0ubuntu1~trusty1 (from proposed PPA) Deploying juju bootstrap node on Ubuntu 14.04 with the following network configuration: eth0 static assigned IP address, default VLAN (no trunking) eth1 static assigned IP address, secondary VLAN eth1.2667 static assigned IP address, VLAN 2667 eth1.2668 static assigned IP address, VLAN 2668 eth1.2669 static assigned IP address, VLAN 2669 eth1.2670 static assigned IP address, VLAN 2670 eth2 unconfigured eth3 unconfigured MAAS generates a /e/n/i which auto stanzas for the VLAN devices and the unconfigured network interfaces; the upstart process which checks that network configuration is complete waits for /var/run/ifup. to exists for all auto interfaces; these will never appear for either the VLAN interfaces or the unconfigured network interfaces. As a result, boot time if very long as cloud-init and networking both take 2 minutes to timeout waiting for network interfaces that will never appear to be configured. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1565711/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1565711] Re: vlan configuration/unconfigured interfaces creates slow boot time
This might also be related to curtin and cloud-init. Targeting them as well. ** Also affects: curtin Importance: Undecided Status: New ** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: maas Status: New => Incomplete ** Changed in: maas Importance: Undecided => High ** Changed in: maas Milestone: None => 1.9.2 ** Tags added: networking ** Changed in: cloud-init Status: New => Incomplete ** Changed in: curtin Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1565711 Title: vlan configuration/unconfigured interfaces creates slow boot time Status in cloud-init: Incomplete Status in curtin: Incomplete Status in MAAS: Incomplete Bug description: maas: 1.9.1+bzr4543-0ubuntu1~trusty1 (from proposed PPA) Deploying juju bootstrap node on Ubuntu 14.04 with the following network configuration: eth0 static assigned IP address, default VLAN (no trunking) eth1 static assigned IP address, secondary VLAN eth1.2667 static assigned IP address, VLAN 2667 eth1.2668 static assigned IP address, VLAN 2668 eth1.2669 static assigned IP address, VLAN 2669 eth1.2670 static assigned IP address, VLAN 2670 eth2 unconfigured eth3 unconfigured MAAS generates a /e/n/i which auto stanzas for the VLAN devices and the unconfigured network interfaces; the upstart process which checks that network configuration is complete waits for /var/run/ifup. to exists for all auto interfaces; these will never appear for either the VLAN interfaces or the unconfigured network interfaces. As a result, boot time if very long as cloud-init and networking both take 2 minutes to timeout waiting for network interfaces that will never appear to be configured. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1565711/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1499869] Re: maas wily deployment to HP Proliant m400 fails
This is either because curtin is not installing the cloud configuration for MAAS, cloud-init is not reading the correct config, or cloud-init cannot talk to MAAS. I believe cloud-init changed to python-oauthlib instead of python-oauth so that might be the issue. Going to target to both curtin and cloud- init as well just to make sure the appropriate eyes see this. ** Also affects: curtin Importance: Undecided Status: New ** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: maas Milestone: None => 1.9.0 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1499869 Title: maas wily deployment to HP Proliant m400 fails Status in cloud-init: New Status in curtin: New Status in MAAS: New Bug description: This is the error seen on the console: [ 64.149080] cloud-init[834]: 2015-08-27 15:03:29,289 - util.py[WARNING]: Failed fetching metadata from url http://10.229.32.21/MAAS/metadata/curtin [ 124.513212] cloud-init[834]: 2015-09-24 17:23:10,006 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [2427570/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by ConnectTimeoutError(, 'Connection to 169.254.169.254 timed out. (connect timeout=50.0)'))] [ 124.515570] cloud-init[834]: 2015-09-24 17:23:10,007 - DataSourceEc2.py[CRITICAL]: Giving up on md from ['http://169.254.169.25/2009-04-04/meta-data/instance-id'] after 2427570 seconds [ 124.531624] cloud-init[834]: 2015-09-24 17:23:10,024 - url_helper.py[WARNING]: Calling 'http:///latest/meta-data/instance-id' failed [0/120s]: bad status code [404] This times out eventually and the node is left at the login prompt. I can install wily via netboot without issue and some time back, wily was deployable to this node from MAAS. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1499869/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1478103] Re: need support for configuring syslog
** No longer affects: maas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1478103 Title: need support for configuring syslog Status in cloud-init: New Bug description: in order to instruct a host to easily log syslog information to another system, we need to add a cloud-config format for this. The format to use looks like this: ## syslog module allows you to configure the systems syslog. ## configuration of syslog is under the top level cloud-config ## entry 'syslog'. ## ## remotes ## remotes is a dictionary. items are of 'name: remote_info' ## name is simply a name (example 'maas'). It has no importance other than ## for cloud-init merging configs ## ## remote_info is of the format ##* optional filter for log messages ## default if not present: *.* ##* optional leading '@' or '@@' (indicates udp or tcp). ## default if not present (udp): @ ## This is rsyslog format for that. if not present, is '@' which is udp ##* ipv4 or ipv6 or hostname ## ipv6 addresses must be encoded in [::1] format. example: @[fd00::1]:514 ##* optional port ## port defaults to 514 ## ## Example: #cloud-config syslog: remotes: # udp to host 'maas.mydomain' port 514 maashost: maas.mydomain # udp to ipv4 host on port 514 maas: @[10.5.1.56]:514 # tcp to host ipv6 host on port 555 maasipv6: *.* @@[FE80::0202:B3FF:FE1E:8329]:555 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1478103/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
