action #124655
closed[openQA][infra][pxe] Physical SUT machine can not boot from pxe and mismatch hostname
0%
Description
Observation¶
All available physical sut machines can not boot from pxe, including openqaipmi5, ix64ph1075 and quinn.
Let us take quinn as example:
Its BIOS setting looks good:
But what is more interesting is booting up quinn shows ix64ph1087. ipmitool -I lanplus -C 3 -H quinn-sp.xxxx -U xxxx -P xxxx sol activate shows:
Steps to reproduce¶
- Open ipmitool sol console
- Wait for boot from pxe and then local disk
Impact¶
No test run can go
Problem¶
Looks networking configuration problem. Maybe something else work is ongoing.
Suggestion¶
- Check DHCP/DNS config
- Check tftp server
Workaround¶
No workaround at the moment
Files
Updated by waynechen55 over 1 year ago
- Subject changed from [openQA][infra[pxe] Physical SUT machine can not boot from pxe to [openQA][infra[pxe] Physical SUT machine can not boot from pxe and mismatch hostname
Updated by okurz over 1 year ago
- Tags set to infra, reactive work
- Subject changed from [openQA][infra[pxe] Physical SUT machine can not boot from pxe and mismatch hostname to [openQA][infra][pxe] Physical SUT machine can not boot from pxe and mismatch hostname
- Priority changed from Normal to Urgent
- Target version set to Ready
Updated by jbaier_cz over 1 year ago
- Related to action #124661: [qe-tools] tftp server and directory mount issue on qanet.qa added
Updated by okurz over 1 year ago
- Status changed from New to In Progress
- Assignee set to okurz
might be related to the problems on qanet and osd. openqaipmi5 is connected to grenache-1:10, openQA worker page https://openqa.suse.de/admin/workers/1207
Updated by waynechen55 over 1 year ago
Update on this at the moment:
pxe hostname ssh
fozzie ok |ok |ok
quinn ok |not ok(ix64ph1087 on system) |ssh to (ix64ph1087 or quinn) ok
ix64ph1075 ok |not ok(susetest on system) |ssh to ix64ph1075 ok, but takes long time
openqaipmi5 ok |ok |ok
Updated by okurz over 1 year ago
- Status changed from In Progress to Resolved
good that you could verify it already. https://openqa.suse.de/tests/10516217#step/boot_from_pxe/4 shows a successful boot from ix64ph1075, https://openqa.suse.de/tests/10516579#step/boot_from_pxe/5 shows a successful boot from openqaipmi5.
Regarding "hostname mismatch": quinn and ix64ph1087 are the very same machine. Also see https://gitlab.suse.de/qa-sle/qanet-configs/-/blob/master/var/lib/named/master/forward/qa.suse.de#L229
We ensured that DHCP/DNS/TFTP is working fine. I assume you are ok with the current state so resolving the ticket.
Updated by xguo over 1 year ago
okurz wrote:
good that you could verify it already. https://openqa.suse.de/tests/10516217#step/boot_from_pxe/4 shows a successful boot from ix64ph1075, https://openqa.suse.de/tests/10516579#step/boot_from_pxe/5 shows a successful boot from openqaipmi5.
Regarding "hostname mismatch": quinn and ix64ph1087 are the very same machine. Also see https://gitlab.suse.de/qa-sle/qanet-configs/-/blob/master/var/lib/named/master/forward/qa.suse.de#L229
We ensured that DHCP/DNS/TFTP is working fine. I assume you are ok with the current state so resolving the ticket.
Yup, confirm that current x86_64 test machine works very well for our OSD build72.1 test runs now. thanks so much for your great help.
Updated by openqa_review over 1 year ago
- Status changed from Resolved to Feedback
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: gi-guest_developing-on-host_sles15sp4-kvm@64bit-ipmi-large-mem
https://openqa.suse.de/tests/10699146#step/boot_from_pxe/1
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- The bugref in the openQA scenario is removed or replaced, e.g.
label:wontfix:boo1234
Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.
Updated by okurz over 1 year ago
- Status changed from Feedback to Resolved
I called openqa-query-for-job-label 124655
3124620|2023-02-17 10:17:24|done|failed|create_hdd_leap_transactional_server_autoyast||openqaworker19
3124620|2023-02-17 10:17:24|done|failed|create_hdd_leap_transactional_server_autoyast||openqaworker19
10707232|2023-03-16 09:51:04|done|failed|gi-guest_win2016-on-host_developing-kvm|backend done: ipmitool -I lanplus -H 10.162.28.200 -U admin -P [masked] chassis power status: Error: Unable to establish IPMI v2 / RMCP+ session at /usr/lib/os-autoinst/backend/ipmi.pm line 45.|grenache-1
10707235|2023-03-16 08:59:24|done|failed|gi-guest_win2019-on-host_developing-kvm||grenache-1
10706670|2023-03-16 08:00:37|done|failed|gi-guest_developing-on-host_sles15sp4-kvm||grenache-1
10706677|2023-03-16 06:42:28|done|failed|gi-guest_win2019-on-host_developing-kvm||grenache-1
10706675|2023-03-16 05:43:56|done|failed|gi-guest_win2016-on-host_developing-kvm||grenache-1
10706671|2023-03-16 05:24:03|done|failed|gi-guest_developing-on-host_sles15sp4-xen||grenache-1
10699146|2023-03-15 16:56:42|done|failed|gi-guest_developing-on-host_sles15sp4-kvm||grenache-1
10697796|2023-03-15 07:46:58|done|failed|gi-guest_developing-on-host_sles15sp4-xen||grenache-1
10697795|2023-03-15 06:45:07|done|failed|gi-guest_developing-on-host_sles15sp4-kvm||grenache-1
10693360|2023-03-15 03:49:45|done|failed|gi-guest_developing-on-host_sles15sp4-xen||grenache-1
I was looking into all jobs that I could access and found that all errors are actually handled in #119551. I followed the test scenarios and found all ended up as ok eventually. I did not remove all references to this ticket as jobs ended up ok. So if the problem reappears this ticket might be reopened and we can check jobs.