Comment 12 for bug 1590846

Thanks for the update. So far here's what I've seen.

the storage config for the node isn't quite right.

First the nvme devices is marked as grub_boot device, but it's not being used at the root; that's typically what we see. That itself isn;'t fatal, in this case the fatal error is the fact that the node is booting under UEFI (curtin is installing grub-efi packages) and then that fails to work as the storage config does not contain a /boot/efi partition and mountpoint. This typically happens if the node hasn't been commissioned after upgrading to a maas with custom storage config; or generally if the node is out of sync w.r.t maas's view of it's uefi status.

For the reporting/event/install log bug, we can see that the curtin config sent includes a reporting configuration:

install:
  log_file: /tmp/install.log
  post_files: [/tmp/install.log]
reporting:
  maas: {consumer_key: XfeDkMX7pqfMWRx8bL, endpoint: 'http://10.246.64.50/MAAS/metadata/status/4y3h7p',
    token_key: w3M3BpvTecqBGxKCS6, token_secret: LYF5FwgGHwkPN79xWnakTM3uzwQCLqKj,
    type: webhook}

After examining the maas regiond log, we can see that curtin does send events back to maas:

016-06-10 19:45:22 [-] 127.0.0.1 - - [10/Jun/2016:19:45:21 +0000] "POST /MAAS/metadata/status/4y3h7p HTTP/1.1" 200 2 "-" "python-requests/2.9.1"
2016-06-10 19:45:22 [-] 127.0.0.1 - - [10/Jun/2016:19:45:21 +0000] "POST /MAAS/metadata/status/4y3h7p HTTP/1.1" 200 2 "-" "python-requests/2.9.1"
2016-06-10 19:45:23 [-] 127.0.0.1 - - [10/Jun/2016:19:45:22 +0000] "POST /MAAS/metadata/status/4y3h7p HTTP/1.1" 200 2 "-" "Curtin/0.1"
2016-06-10 19:45:23 [-] 127.0.0.1 - - [10/Jun/2016:19:45:22 +0000] "POST /MAAS/metadata/status/4y3h7p HTTP/1.1" 200 2 "-" "Curtin/0.1"

The python-requests post is from cloud-init; which IIUC, those messages are being returned
the 'Curtin/0.1' are from curtin but are not appearing in maas UI.

At this point, I don't think there is a curtin bug here.