[2.1] Add ability to select the boot device when deploying Windows.

Bug #1640301 reported by Andrei Bacos
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
High
Unassigned
2.1
Won't Fix
High
Unassigned
curtin
Fix Released
Medium
Unassigned

Bug Description

Deploying on servers with multiple disks, like 2 identical SSD drives results in a system that cannot boot.
There is no way of knowing which device will be used to deploy the OS and there is no correlation between BIOS order and how the deployment image orders the disks.

Our use case requires us to deploy disk images (windows) which do not support custom disk layout but we observed this issue deploying ubuntu on servers with multiple raid controllers and sets of disks.

ii maas 2.0.0+bzr5189-0ubuntu1~16.04.1 all "Metal as a Service" is a physical cloud and IPAM
ii maas-cli 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS client and command-line interface
un maas-cluster-controller <none> <none> (no description available)
ii maas-common 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS server common files
ii maas-dhcp 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS DHCP server
ii maas-dns 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS DNS server
ii maas-proxy 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS Caching Proxy
ii maas-rack-controller 2.0.0+bzr5189-0ubuntu1~16.04.1 all Rack Controller for MAAS
ii maas-region-api 2.0.0+bzr5189-0ubuntu1~16.04.1 all Region controller API service for MAAS
ii maas-region-controller 2.0.0+bzr5189-0ubuntu1~16.04.1 all Region Controller for MAAS
un maas-region-controller-min <none> <none> (no description available)
un python-django-maas <none> <none> (no description available)
un python-maas-client <none> <none> (no description available)
un python-maas-provisioningserver <none> <none> (no description available)
ii python3-django-maas 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS server Django web framework (Python 3)
ii python3-maas-client 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS python API client (Python 3)
ii python3-maas-provisioningserver 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS server provisioning libraries (Python 3)

Tags: cloudbase

Related branches

Revision history for this message
Octavian Ciuhandu (ociuhandu) wrote :

This bug affects all deployments based on disk image, not the .tgz ones.

no longer affects: maas/2.2
tags: added: cloudbase
summary: - Deploying servers with multiple disks fails
+ [2.1] Deploying windows servers with multiple disks fails when boot
+ device is different that root
Revision history for this message
Gabriel Samfira (gabriel-samfira) wrote : Re: [2.1] Deploying windows servers with multiple disks fails when boot device is different that root

So the way we "fixed" this for our scenario was to pass the custom storage information in curtin to meta_simple(), and set the target device for the image to the block device that coincides with what curtin gets as grub_device from MAAS. I have attached a diff for curtin.

Note, the custom storage info needs to be exposed for systems other then ubuntu in maasserver/preseed.py.

Changed in curtin:
status: New → Confirmed
Revision history for this message
Andres Rodriguez (andreserl) wrote :

This was "Deploying windows servers with multiple disks fails when boot device is different that root"

summary: - [2.1] Deploying windows servers with multiple disks fails when boot
- device is different that root
+ [2.1] Add ability to select the boot device when deploying Windows.
Revision history for this message
Scott Moser (smoser) wrote :

Gabriel,
can you propose your patch for merge via merge proposal?
It looks like a generally sane path to me, but i think that maas would have to start sending storage config to windows installations and that might cause other issues.

Also, i think choosing to apply the 'wipe' in the simple path is mostly orthogonal to selecting the device. (block.wipe_volume())

Revision history for this message
Andres Rodriguez (andreserl) wrote :

@Scott,

I've put a MP that's the patch that Gabriel attached.

Changed in curtin:
status: Confirmed → In Progress
Revision history for this message
Scott Moser (smoser) wrote :

fixed in trunk at 476

Changed in curtin:
status: In Progress → Fix Committed
importance: Undecided → Medium
Changed in maas:
status: Fix Committed → Fix Released
Revision history for this message
Scott Moser (smoser) wrote : Fixed in Curtin 17.1

This bug is believed to be fixed in curtin in 17.1. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Changed in curtin:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.