MAAS always installs GRUB to /dev/sda, even when that's inappropriate

Bug #1319966 reported by Rod Smith
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
Medium
Blake Rouse

Bug Description

As far as I can tell from my experiments, BIOS-mode MAAS always installs GRUB to the MBR of /dev/sda. This isn't always appropriate, though; if a computer has multiple non-RAID hard disks, and if the BIOS is configured to boot /dev/sdb before /dev/sda (even with PXE-booting before either of those), the result can be an installation that won't boot -- at least, not until the BIOS disk order is reconfigured.

Perhaps having MAAS put GRUB on every hard disk (preferably excluding USB flash drives) would fix this problem with minimal fuss.

Here's my MAAS version information:

$ dpkg -l '*maas*'|cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=====================================================-===================================================-============-===============================================================================
ii maas 1.5+bzr2252-0ubuntu1 all MAAS server all-in-one metapackage
ii maas-cli 1.5+bzr2252-0ubuntu1 all MAAS command line API tool
ii maas-cluster-controller 1.5+bzr2252-0ubuntu1 all MAAS server cluster controller
ii maas-common 1.5+bzr2252-0ubuntu1 all MAAS server common files
ii maas-dhcp 1.5+bzr2252-0ubuntu1 all MAAS DHCP server
ii maas-dns 1.5+bzr2252-0ubuntu1 all MAAS DNS server
ii maas-region-controller 1.5+bzr2252-0ubuntu1 all MAAS server complete region controller
ii maas-region-controller-min 1.5+bzr2252-0ubuntu1 all MAAS Server minimum region controller
ii python-django-maas 1.5+bzr2252-0ubuntu1 all MAAS server Django web framework
ii python-maas-client 1.5+bzr2252-0ubuntu1 all MAAS python API client
ii python-maas-provisioningserver 1.5+bzr2252-0ubuntu1 all MAAS server provisioning libraries

Revision history for this message
Rod Smith (rodsmith) wrote :

Oh, one more thing: I've verified this with both the d-i and fastpath installers, although most of my testing was done with the latter.

Revision history for this message
Jeff Lane  (bladernr) wrote :

This has also been observed on a system up for Certification, an older HP system that has two RAID controllers, one meant for onboard root fs and the other meant to handle data storage.

https://certification.canonical.com/hardware/201209-11794/

tags: added: blocks-hwcert-server
Changed in maas:
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Michael F. Miller (mikem1355) wrote :

I have also encountered this at HP as mentioned above.

Revision history for this message
james beedy (jamesbeedy) wrote :

Is there anything being done about this issue???

Revision history for this message
Blake Rouse (blake-rouse) wrote :

Work needs to be done to identify which storage device the machine will boot from first. This is not an easy task and will at least require a restart during commissioning to identify which device will boot.

I think this is mainly a legacy bios issue not UEFI. As any EFI bios, should search all devices for the EFI partition. @Rodsmith, correct me if I am wrong in this logic.

To detect this on legacy devices every device needs to have grub written to the disk, then have the system reboot. When the system reboots it should load one of the installed grubs, and then grub needs to store into memory exactly which device it booted from. Note: grub at the moment does not do this, and the bios does not provide this information anywhere. The booted kernel then needs to pull this information from grub, or have grub save this information somewhere on the /boot partition for the MAAS commissioning script to read.

Overall its a tough problem that I am looking at to try and figure out exactly how to perform this action proficiently and easily.

Changed in maas:
importance: Low → Medium
Revision history for this message
Rod Smith (rodsmith) wrote :

Blake, I agree that this problem is for BIOS mode only -- or at least, under EFI it would be different. For EFI systems, bug #1311827 means that the system SHOULD be configured to boot correctly from whatever hard disk ends up holding GRUB, although I've done little real testing on EFI-based computers with multiple hard disks. I don't know enough about the MAAS EFI GRUB configuration to know how the system would respond once it's reconfigured to PXE-boot. It's conceivable it could get confused in some situations and fail to locate the local GRUB or configuration files, which would be an analogous, but very different, bug. I have no reason to believe this is the case, though.

Jeff Lane  (bladernr)
tags: added: hwcert-server
removed: blocks-hwcert-server
Revision history for this message
Blake Rouse (blake-rouse) wrote :

In MAAS 1.9 we allow the user to set which block device is the boot disk. This makes sure that grub is installed to that disk, and not to another disk.

http://maas.ubuntu.com/docs/storage.html#set-as-boot-disk

Changed in maas:
status: Triaged → Fix Committed
assignee: nobody → Blake Rouse (blake-rouse)
milestone: none → 1.9.0
Changed in maas:
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.