Comment 18 for bug 1532935

Ran into this issue multiple times while using Landscape Autopilot to deploy Openstack, which was never able to complete due to at least one machine failing to deploy, after getting stuck at the grub menu. Juju 1.25.5 and MAAS 1.9.2 were being used.

Once stopped at the grub menu I was able to bring the system up for inspection by doing the following:

    - Reboot the server and drop into the boot menue (F11 on HP)
    - Select the UEFI module option
    - Use the file explorer to drill down to and run shimx64.efi
    - grub> cat /boot/grub/menu.lst (to see configured kernel and initrd paths)
    - grub> linux /boot/vmlinuz-3.13.0-86-generic root=LABEL=root ro console=ttyS1,38400 1
    - grub> initrd /boot/initrd.img-3.13.0-86-generic
    - grub> boot
    - Boot would stop at run level 1 and drop to a root shell prompt
    - /etc/init.d/networking start
    - service ssh start
    - ifconfig (to find configured IP)
    - ssh into the system as the ubuntu user

During the Openstack deploy attempts, 4 different machines hit this issue while others installed and booted successfully. Trusty 14.04.4 was being install on all machines. Two identical HP servers had the following differences:

1. The failing server's disk was configured with a 'gpt' partition table, while the
 successful server was configured with a 'msdos' partition table.

2. The failing server had two partitions defined (partition 1 has efi files) :
  1 1049kB 538MB 537MB fat32 boot
  2 538MB 500GB 500GB ext4

   The successful server had only one partition defined:
   1 1049kB 500GB 500GB primary ext4

3. The failing server's /boot directory is configured for EFI and the successful server is not.

Seems MAAS, Curtin or Grub is inconsistently making decisions about how the partitions should be defined and whether or not to use EFI. When EFI is used grub does not boot the server.