Bug 994677
| Summary: | Provisioning RHEL6.5 leaves EFI boot set to Linux instead of network | ||
|---|---|---|---|
| Product: | [Retired] Beaker | Reporter: | Russ Anderson <rja> |
| Component: | lab controller | Assignee: | beaker-dev-list |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | tools-bugs <tools-bugs> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 0.14 | CC: | aigao, asaha, ctatman, dcallagh, gbeshers, gbeshers, jdonohue, llim, loriann, qwan, randerso, rja, rmancy, tee |
| Target Milestone: | 0.14.2 | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-12-19 06:19:33 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 997629 | ||
| Bug Blocks: | 844783 | ||
|
Description
Russ Anderson
2013-08-07 18:36:40 UTC
(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... I think bug 997629 has a neater solution to this. 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 :) 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". (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. Thanks for the explanation. As long as it works I'm happy. :-) Hi Dan, when should this change take effect? The SGI uv2 still hits the problem. Thanks. Russ, the change has been committed for Beaker 0.15, which is still at least a couple of weeks away from release. OK. Thanks for the update. 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. Oops, bug reference in previous comment should be to bug 997629 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. Setting to RELEASE_PENDING pending confirmation that 0.15 addressed the upstream component of this problem :) Changing the target milestone, since the underlying fix should now be included in the upcoming 0.14.2 maintenance release. Nick, can i make #22 visible? George and Russ can't see private comments. Dumb question , but i have to ask.... 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 :( 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? (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... 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 :) Clearing NEEDINFO on a BZ marked CLOSED CURRENTRELEASE. |