action #167078
closed[tools][qe-core]powervm-hmc, netboot failed due to wrong server ip configured
0%
Description
Description¶
For redcurrant-1 to redcurrant-8 which are used for openQA tests, seems IP configuration is not correct.
server IP = 10.145.10.21
We may need to change it to server IP = 10.145.10.78
Observation¶
openQA test in scenario sle-15-SP7-Online-ppc64le-default@ppc64le-hmc fails in
bootloader
Test suite description¶
Maintainer: QE Core
The standard scenario where we mainly just follow installation suggestions without any adjustments.
Reproducible¶
Fails since (at least) Build 10.1
Expected result¶
Last good: (unknown) (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by nicksinger about 1 month ago
This might need to be automated by openQA because it doesn't happen for the first time. I noticed that this happens (always?) if a new machine is added into this network. https://gitlab.suse.de/OPS-Service/salt/-/blob/production/pillar/domain/oqa_prg2_suse_org/hosts.yaml#L87 shows that 10.145.10.21
corresponds to bare-metal4-ipmi
and I don't know why redcurrant thinks it can boot from it.
Updated by okurz about 1 month ago
nicksinger wrote in #note-1:
https://gitlab.suse.de/OPS-Service/salt/-/blob/production/pillar/domain/oqa_prg2_suse_org/hosts.yaml#L87 shows that
10.145.10.21
corresponds tobare-metal4-ipmi
and I don't know why redcurrant thinks it can boot from it.
IIRC this IP is the old address of suttner1.
Updated by okurz about 1 month ago
- Priority changed from Normal to High
- Target version set to Ready
Updated by okurz about 1 month ago
- Due date set to 2024-10-04
- Status changed from New to Feedback
- Assignee set to okurz
@rfan1 I think you can change the IP in the SMS of each LPAR. 10.145.10.78 is correct as that is the primary DHCP server in the domain oqa.prg2.suse.org. Can you try yourself?
Updated by rfan1 about 1 month ago
- Assignee changed from okurz to tinawang123
As discussed offline, Yutao will pick up this ticket.
- change the server ip to
10.145.10.78
- run bootp test to make sure pxe request can work
Updated by tinawang123 about 1 month ago
michals wrote in #note-7:
Does it work with server IP 0.0.0.0 ?
I tried it. It cannot work:
BOOTP Parameters: ¶
chosen-network-type = ethernet,auto,rj45,auto
server IP = 0.0.0.0
client IP = 10.145.10.231
gateway IP = 10.145.10.254
device = /vdevice/l-lan@30000002
MAC address = f6 6b 42 ad 2e 02
loc-code = U9008.22L.788201A-V7-C2-T1
BOOTP request retry attempt: 1
BOOTP request retry attempt: 2
BOOTP request retry attempt: 3
BOOTP request retry attempt: 4
....
Updated by tinawang123 about 1 month ago
- Status changed from Feedback to Resolved
Finished update redcurrant-1 to 8
Updated by michals about 1 month ago
With server IP 0.0.0.0 all the parameters should be 0 as well. That should work so long as the server is in the same subnet or there is a DHCP proxy.
Updated by rfan1 about 1 month ago
michals wrote in #note-11:
With server IP 0.0.0.0 all the parameters should be 0 as well. That should work so long as the server is in the same subnet or there is a DHCP proxy.
Seems donen't work:
BOOTP Parameters:
----------------
chosen-network-type = ethernet,auto,rj45,auto
server IP = 0.0.0.0
client IP = 0.0.0.0
gateway IP = 0.0.0.0
device = /vdevice/l-lan@30000002
MAC address = f6 6b 42 ad 2e 02
loc-code = U9008.22L.788201A-V7-C2-T1
BOOTP request retry attempt: 1
BOOTP request retry attempt: 2
Updated by michals about 1 month ago
BOOTP broadcast not working sounds like something that should be debugged, eventually.