Bug 1156036 - RFE: per-distro bootloader support for netbooting
Summary: RFE: per-distro bootloader support for netbooting
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Beaker
Classification: Retired
Component: lab controller
Version: 0.18
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: 20.0
Assignee: Amit Saha
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks: 1156201
TreeView+ depends on / blocked
 
Reported: 2014-10-23 12:47 UTC by Martin Banas
Modified: 2018-02-06 00:41 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Cause: Consequence: Fix: Result:
Clone Of:
Environment:
Last Closed: 2015-04-20 02:22:56 UTC
Embargoed:


Attachments (Terms of Use)

Description Martin Banas 2014-10-23 12:47:19 UTC
Description of problem:
We need to do testing with specific bootloaders from specific distros.
Currently this is problem with PPC64, where we need to boot RHEL7.1 with grub2, but older releases (RHEL-7.0, RHEL6, RHEL5) with yaboot. It would be also good to test current yaboot when testing RHEL6.6, I suppose we now use something much older (from RHEL6.0?).

This is not just about ppc64 though, we should also test current syslinux/pxelinux.

Version-Release number of selected component (if applicable):
Beaker 0.18.3 

Actual results:
Bootloader can't be specified per distro. All POWER7 ppc64 machines use yaboot for booting and therefore testing on RHEL-7.1 on PPC64 is blocked (bug 1140758)

Expected results:
PPC64 machines should use:
* GRUB2 for RHEL-7.1 and newer
* yaboot for RHEL7.0, RHEL6 and older
x86_64 machines should also use current bootloaders for specific distros.

Comment 1 Dan Callaghan 2014-10-23 22:25:38 UTC
The biggest problem is that Beaker does not control the DHCP config for the systems it manages. So the only way Beaker can do this is to swap symlinks from a dummy boot loader name to point at the actual desired boot loader binary.

Comment 2 Nick Coghlan 2014-10-24 03:11:50 UTC
Well, it's the only way without a network service API that would allow Beaker to dynamically update DHCP entries in the labs. That would be a big new capability, but it's one that would at least be worth considering further.

Comment 3 andrew 2014-10-27 16:36:15 UTC
(In reply to Nick Coghlan from comment #2)
> Well, it's the only way without a network service API that would allow
> Beaker to dynamically update DHCP entries in the labs. That would be a big
> new capability, but it's one that would at least be worth considering
> further.


Another idea is to have a the dhcp file name entry point at a generic hexip file name .That way beaker can change the symlink to some other boot loader. Example If rhel6 is chosen to install then use yaboot. If rhel 7 is being provisioned then use grub2. But the biggest thing would be from a jobs xml perspective to call out yaboot or grub2 so you could force the change. I don't think beaker needs to control dhcp just which boot loader is getting called.

Comment 4 Bill Peck 2014-10-27 17:33:36 UTC
Andrew's suggestion could be in addition to what beaker is configuring right now.  That way this feature could be implemented without breaking the existing systems.  Just the SGI systems could be updated to point to the hex ip filename entry and verified to work.

Comment 5 Nick Coghlan 2014-10-28 05:16:00 UTC
There's actually two aspects to the problem here:

1. With a couple of exceptions, Beaker currently writes out *all* the bootloader config files for every architecture, so it doesn't need to worry about mapping architecture -> bootloader. Implementing this change would likely mean moving that logic to the main server and making the "arch + distro -> bootloader path" mapping configurable by administrators (with a default arch -> bootloader path fallback mapping if there's no distro specific setting to be maintained). (As Andrew notes, this also opens up the possibility of making the bootloader used configurable in the job XML)

2. Even with the bootloader path to use being specified in the provisioning command from the server, there still needs to be a way to tell the DHCP server to use that particular bootloader. Andrew's suggestion of a machine specific hexip based symlink makes sense to me.

It also occurs to me that this approach potentially offers a nicer failure mode when a bootloader is missing: the Beaker lab controller could stat the given bootloader path, and fail the provision attempt if its missing.

Comment 6 Dan Callaghan 2014-10-31 04:29:20 UTC
Plan of attack:

* Beaker will write a symlink to /bootloader/<fqdn> under the TFTP root. This will be a symlink to the "chosen" boot loader image for the current provision. DHCP filename for a system can be set to this value to use the new boot loader siwtching mechanism.

* Server needs to tell LC the desired boot loader in configure_netboot. For now, server will pass it as a fake extra kernel option, which beaker-provision will need to parse out. netbootloader=/path/to/loader/image

* On the server in default_install_options(), populate netbootloader accroding to the various rules. x86 = /pxelinux.0, ppc64 RHEL<7 = /ppc/yaboot.elf or whatever it is, etc...

* Netboot *config* files will continue to be written for all arches/loaders always.

* Systems can have a specific boot loader path set in their install options (e.g. when a system needs a weird version of pxelinux) HOWEVER this precludes them from using a different boot loader per OS major, because the system-specific install option will always override. This will just have to be a known limitation for now.

* Dealing with the BIOS vs. EFI distinction for x86 is a whole other kettle of fish that will be dealt with under bug 1156201.

* Write docs :-)

Comment 7 Dan Callaghan 2014-10-31 05:58:02 UTC
(In reply to Dan Callaghan from comment #6)
> * Beaker will write a symlink to /bootloader/<fqdn> under the TFTP root.

I just remembered the extra complication with this... most of the boot loaders look for their config files relative to the path they were loaded from.

Comment 8 Amit Saha 2014-11-12 02:29:39 UTC
http://gerrit.beaker-project.org/#/c/3465/

Comment 15 Dan Callaghan 2015-04-20 02:22:56 UTC
Beaker 20.0 has been released.


Note You need to log in before you can comment on or make changes to this bug.