[BUG] [8.8] [x86_64] Multilingual installers enter the Networking spoke automatically after language selection #185

New Issue

2023-06-01T14:37:17Z

akatch commented

2023-06-01 14:37:17 +00:00

(Migrated from github.com)

Describe the bug
In Rocky 8.8 x86_64, after selecting the specified language on the language selection screen, Anaconda drops the user into the Network and Host Name spoke.

This issue impacts the following test suites:
install_arabic_language
install_asian_language
install_cyrillic_language
install_european_language

To Reproduce
Steps to reproduce the behavior:

POST the following jobs to openQA:

openqa-cli api -X POST isos \
  ISO=Rocky-8.8-x86_64-dvd1.iso \
  ARCH=x86_64 \
  DISTRI=rocky \
  FLAVOR=universal \
  LOCATION=https://download.rockylinux.org/pub/rocky/8.8/BaseOS \
  NICTYPE_USER_OPTIONS=net=172.16.2.0/24 \
  QEMU_HOST_IP=172.16.2.2 \
  VERSION=8.8 \
  CURRREL=8 \
  BUILD=-$(date +%Y%m%d)-main-8.8 \
  TEST=install_arabic_language,install_asian_language,install_european_langua
ge,install_cyrillic_language

On an impacted system, all tests will stall in _boot_to_anaconda at the Network and Host Name spoke

Expected behavior
After language selection, Anaconda should return to the main hub OR if this is expected behavior, we should modify our tests to handle this scenario.

Screenshots
Failing tests may be seen at these links:
https://openqa.rockylinux.org/tests/33418#step/_boot_to_anaconda/12
https://openqa.rockylinux.org/tests/33422#step/_boot_to_anaconda/12
https://openqa.rockylinux.org/tests/33426#step/_boot_to_anaconda/12
https://openqa.rockylinux.org/tests/33425#step/_boot_to_anaconda/12

Additional context
~~Notably, I do NOT see this behavior on my local openQA environment. It only seems to manifest on the public openQA.~~
Update: This is reproducible locally with all of the parameters in the command further up this issue.

**Describe the bug** In Rocky 8.8 x86_64, after selecting the specified language on the language selection screen, Anaconda drops the user into the Network and Host Name spoke. This issue impacts the following test suites: `install_arabic_language` `install_asian_language` `install_cyrillic_language` `install_european_language` **To Reproduce** Steps to reproduce the behavior: 1. POST the following jobs to openQA: ``` openqa-cli api -X POST isos \ ISO=Rocky-8.8-x86_64-dvd1.iso \ ARCH=x86_64 \ DISTRI=rocky \ FLAVOR=universal \ LOCATION=https://download.rockylinux.org/pub/rocky/8.8/BaseOS \ NICTYPE_USER_OPTIONS=net=172.16.2.0/24 \ QEMU_HOST_IP=172.16.2.2 \ VERSION=8.8 \ CURRREL=8 \ BUILD=-$(date +%Y%m%d)-main-8.8 \ TEST=install_arabic_language,install_asian_language,install_european_langua ge,install_cyrillic_language ``` 1. On an impacted system, all tests will stall in `_boot_to_anaconda` at the Network and Host Name spoke **Expected behavior** After language selection, Anaconda should return to the main hub OR if this is expected behavior, we should modify our tests to handle this scenario. **Screenshots** Failing tests may be seen at these links: https://openqa.rockylinux.org/tests/33418#step/_boot_to_anaconda/12 https://openqa.rockylinux.org/tests/33422#step/_boot_to_anaconda/12 https://openqa.rockylinux.org/tests/33426#step/_boot_to_anaconda/12 https://openqa.rockylinux.org/tests/33425#step/_boot_to_anaconda/12 **Additional context** ~~Notably, I do NOT see this behavior on my local openQA environment. It only seems to manifest on the public openQA.~~ Update: This is reproducible locally with all of the parameters in the command further up this issue.

tcooper commented

2023-06-01 15:27:18 +00:00

(Migrated from github.com)

@akatch With respect to replicating these failures outside of the production instance.

The POST you are using is not quite the same as that used in production. The production POST is configured with additional variables to support multi-host tests within FLAVOR=universal and those variables are likely involved in the issue even without multi-host being in the mix directly for the language tests.

The POST for FLAVOR=universal looks like this...

openqa-cli api -X POST isos \
  ISO=Rocky-8.8-x86_64-dvd1.iso \
  ARCH=x86_64 \
  DISTRI=rocky \
  FLAVOR=universal \
  LOCATION=https://download.rockylinux.org/pub/rocky/8.8/BaseOS \
  NICTYPE_USER_OPTIONS=net=172.16.2.0/24 \
  QEMU_HOST_IP=172.16.2.2 \
  VERSION=8.8 \
  CURRREL=8 \
  BUILD=20230601-Rocky-8.8-x86_64.0

Hope that helps.

@akatch With respect to replicating these failures outside of the production instance. The `POST` you are using is not quite the same as that used in production. The production `POST` is configured with additional variables to support multi-host tests within `FLAVOR=universal` and those variables are likely involved in the issue even without multi-host being in the mix directly for the language tests. The `POST` for `FLAVOR=universal` looks like this... ``` openqa-cli api -X POST isos \ ISO=Rocky-8.8-x86_64-dvd1.iso \ ARCH=x86_64 \ DISTRI=rocky \ FLAVOR=universal \ LOCATION=https://download.rockylinux.org/pub/rocky/8.8/BaseOS \ NICTYPE_USER_OPTIONS=net=172.16.2.0/24 \ QEMU_HOST_IP=172.16.2.2 \ VERSION=8.8 \ CURRREL=8 \ BUILD=20230601-Rocky-8.8-x86_64.0 ``` Hope that helps.

akatch commented

2023-06-01 16:07:43 +00:00

(Migrated from github.com)

Thanks Trevor, this is really helpful. I'll do some more digging.

akatch commented

2023-06-01 17:08:20 +00:00

(Migrated from github.com)

Confirmed that I was able to reproduce this locally with the additional parameters. I think the best course of action here is to just hit the "continue" button in the Networking spoke, as the next set of steps will enable networking anyway. I was able to confirm that the workflow continues if I click the Continue button manually, however it fails later at _check_install_source with # Test died: command 'grep "Load metadata for the 'anaconda'" /tmp/anaconda.log' failed at rocky/tests/_check_install_source.pm line 64.. That repository name seems odd, but I'll keep looking. If anyone has a strong preference for how we handle the original problem, let me know either here or in Mattermost, otherwise I'll see how far I can get with just clicking Continue at the Network spoke.

Confirmed that I was able to reproduce this locally with the additional parameters. I think the best course of action here is to just hit the "continue" button in the Networking spoke, as the next set of steps will enable networking anyway. I was able to confirm that the workflow continues if I click the Continue button manually, however it fails later at `_check_install_source` with `# Test died: command 'grep "Load metadata for the 'anaconda'" /tmp/anaconda.log' failed at rocky/tests/_check_install_source.pm line 64.`. That repository name seems odd, but I'll keep looking. If anyone has a strong preference for how we handle the original problem, let me know either here or in Mattermost, otherwise I'll see how far I can get with just clicking Continue at the Network spoke.

Sign in to join this conversation.