Project

General

Profile

Actions

action #124655

closed

[openQA][infra][pxe] Physical SUT machine can not boot from pxe and mismatch hostname

Added by waynechen55 almost 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Category:
-
Start date:
2023-02-16
Due date:
% Done:

0%

Estimated time:

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

quinn_pxe_03.png (15.1 KB) quinn_pxe_03.png waynechen55, 2023-02-16 02:43
quinn_bios.png (45.7 KB) quinn_bios.png waynechen55, 2023-02-16 02:43
quinn_sol.png (27.3 KB) quinn_sol.png waynechen55, 2023-02-16 02:46

Related issues 1 (0 open1 closed)

Related to openQA Infrastructure (public) - action #124661: [qe-tools] tftp server and directory mount issue on qanet.qa Resolvedokurz2023-02-16

Actions
Actions #1

Updated by waynechen55 almost 2 years 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
Actions #2

Updated by okurz almost 2 years 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
Actions #3

Updated by jbaier_cz almost 2 years ago

  • Related to action #124661: [qe-tools] tftp server and directory mount issue on qanet.qa added
Actions #4

Updated by okurz almost 2 years 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

Actions #5

Updated by waynechen55 almost 2 years 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
Actions #6

Updated by okurz almost 2 years 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.

Actions #7

Updated by xguo almost 2 years 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.

Actions #8

Updated by openqa_review almost 2 years 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:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
  3. 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.

Actions #9

Updated by okurz almost 2 years 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.

Actions

Also available in: Atom PDF