Bug 994677 - Provisioning RHEL6.5 leaves EFI boot set to Linux instead of network
Provisioning RHEL6.5 leaves EFI boot set to Linux instead of network
Status: CLOSED CURRENTRELEASE
Product: Beaker
Classification: Community
Component: lab controller (Show other bugs)
0.14
x86_64 Linux
unspecified Severity urgent (vote)
: 0.14.2
: ---
Assigned To: beaker-dev-list
tools-bugs
: Triaged
Depends On: 997629
Blocks: 844783
  Show dependency treegraph
 
Reported: 2013-08-07 14:36 EDT by Russ Anderson
Modified: 2018-02-05 19:41 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-19 01:19:33 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Russ Anderson 2013-08-07 14:36:40 EDT
Description of problem:  When RHEL6.5 is provisioned on an EFI based system (ie SGI UV) Anaconda sets the EFI boot default to Linux (boot from hard drive).  This prevents Beaker from re-provisioning the system, since Beaker needs the system set to netboot.  Beaker then things the test system is broken since provisioning fails.


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


How reproducible: 100%


Steps to Reproduce:
1. Provision RHEL6.5 on an EFI based system.
2. Check the EFI boot order.


Actual results:  EFI boot set to Linux.


Expected results:  EFI boot set to network.
sgi-uv1

Additional info:  Not sure if this is a Beaker or Anaconda issue or other issue.

This is reproducible in RH on Beaker systems sgi-uv1.rhts.eng.bos.redhat.com, sgi-uv1000-sys.rhts.eng.bos.redhat.com, and sgi-uv2-01.rhts.eng.bos.redhat.com.


--------------------------------
[root@sgi-uv2-01 ~]# efibootmgr
efibootmgr
BootCurrent: 0003
BootOrder: 0003,0000,0001,0002
Boot0000* EFI Internal Shell
Boot0001* EFI Network
Boot0002* EFI Network 1
Boot0003* Red Hat Enterprise Linux
[root@sgi-uv2-01 ~]#
Comment 2 Russ Anderson 2013-08-07 17:42:27 EDT
I wonder if a fix similar to BZ 794543 is needed.
Comment 3 Dan Callaghan 2013-08-15 09:27:16 EDT
(In reply to Russ Anderson from comment #2)
> I wonder if a fix similar to BZ 794543 is needed.

Yes it looks like you're right, Russ. The regexp is currently:

grep -Ei '(netboot|pxe)'

I wonder if it would be too broad if we made it:

grep -Ei '(net|pxe)'

Otherwise we could just do:

grep -Ei '(netboot|network|pxe)'

It would have been nice if EFI had standardised this somehow, but I guess that's too much to hope for...
Comment 4 Dan Callaghan 2013-08-15 19:10:23 EDT
I think bug 997629 has a neater solution to this.
Comment 5 Nick Coghlan 2013-08-27 03:45:04 EDT
In theory, implementing bug 997629 should fix this. Once that has landed, we can recheck this one, and if theory turns out to match reality, close this as a duplicate :)
Comment 6 Russ Anderson 2013-08-27 17:50:40 EDT
I must be missing something because I don't see how the change in bug 997629 will fix this problem.  The key point is "and subsequent installs will keep it first."  The problem is Anaconda does not "keep it first".
Comment 7 Dan Callaghan 2013-08-27 18:34:55 EDT
(In reply to Russ Anderson from comment #6)
> I must be missing something because I don't see how the change in bug 997629
> will fix this problem.  The key point is "and subsequent installs will keep
> it first."  The problem is Anaconda does not "keep it first".

Beaker already has a hack in kickstart %post to undo the boot order changes made by Anaconda. That is how Beaker is able to deal with existing EFI-based systems. The problem here is just that the hack does not correctly handle the different boot entry names on these SGI systems.

The reason why bug 997629 should fix this is that it changes Beaker's hack to not rely on any particular naming for the entries.
Comment 8 Russ Anderson 2013-08-27 21:52:39 EDT
Thanks for the explanation.  As long as it works I'm happy.  :-)
Comment 12 Russ Anderson 2013-08-29 23:47:29 EDT
Hi Dan, when should this change take effect?  The SGI uv2 still hits the problem.
Thanks.
Comment 13 Nick Coghlan 2013-08-29 23:51:18 EDT
Russ, the change has been committed for Beaker 0.15, which is still at least a couple of weeks away from release.
Comment 14 Russ Anderson 2013-08-30 10:34:56 EDT
OK.  Thanks for the update.
Comment 15 Nick Coghlan 2013-09-16 03:41:51 EDT
Moving this to MODIFIED to better reflect the fact that it *should* already be fixed for 0.15 (since bug 997269 is at VERIFIED), but we don't have the hardware to verify it in our test environment.
Comment 16 Nick Coghlan 2013-09-16 03:42:46 EDT
Oops, bug reference in previous comment should be to bug 997629
Comment 17 Russ Anderson 2013-09-20 16:25:55 EDT
George and Jeff Burke tracked down a problem in the power-cmc expect script, so the EFI boot option was not getting set to EFI netboot.  The modified script now works when run by hand.  Hopefully when the updated expect script is integrated into Beaker this problem will be solved.
Comment 19 Nick Coghlan 2013-10-02 22:36:29 EDT
Setting to RELEASE_PENDING pending confirmation that 0.15 addressed the upstream component of this problem :)
Comment 21 Nick Coghlan 2013-10-16 04:25:44 EDT
Changing the target milestone, since the underlying fix should now be included in the upcoming 0.14.2 maintenance release.
Comment 23 Joe Donohue 2013-11-19 13:45:30 EST
Nick, can i make #22 visible? George and Russ can't see private comments. Dumb question , but i have to ask....
Comment 24 Nick Coghlan 2013-11-19 23:56:05 EST
Russ, George - the fix for bug 997629 was include in the recently deployed 0.14.2 maintenance release. If the SGI systems are behaving themselves completely now, we can finally close the upstream component of this.

However, if we still see problems with these systems, then bug 1031876 may be relevant. The approach used to resolve bug 997629 assumes BootCurrent is always defined, but it turns out that's actually a grey area in the EFI spec and so not all EFI firmware will set it :(
Comment 25 Russ Anderson 2013-11-20 18:49:56 EST
Relying on the EFI spec is always asking for trouble.

Maybe this is too obvious, but why not use BootOrder and set it to the netboot entry?
Comment 26 Dan Callaghan 2013-11-20 19:56:27 EST
(In reply to Russ Anderson from comment #25)
> Maybe this is too obvious, but why not use BootOrder and set it to the
> netboot entry?

Can you give us a reliable way to pick which entry is "the" netboot entry? :-)

We have seen various combinations of "Netboot", "PXE", and "Network". Previously we had a regexp (pxe|net) although one user reported that he needed to add ipv4 to the regex for his system. But we have some IBM x Series systems which have both "PXE Network" and "Netboot" where the former fails with no explanation but the latter works, so the regexp is not a good solution.

Bill's solution in bug 997629 was to use BootCurrent, but it turns out those same IBM x Series systems also fail to provide the BootCurrent variable so that doesn't work either.

The approach which I'm currently testing is to just assume that Anaconda created a new boot entry, and to assume that nothing else screwed with the boot order, so it just pops the first entry off the front:

http://gerrit.beaker-project.org/2519

I'm cautiously optimistic that this will cover all cases...
Comment 27 Nick Coghlan 2013-12-19 01:19:33 EST
This should be covered by the EFI handling fixes in Beaker 0.14.4. If not, feel free to reopen and we'll see if we can get some affected hardware added to our devel environment :)
Comment 28 Russ Anderson 2014-06-09 11:05:49 EDT
Clearing NEEDINFO on a BZ marked CLOSED CURRENTRELEASE.

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