QA » openQA Project » openQA Tests

@JRivrain if you decide to exclude the complete call in case of live media – which kinda makes sense – we should still review the decision to install a lot of packages within the test module at all as we should not use "zypper" but "yast" here. You can extract that in a separate ticket of course.

Treating live envs specially is the wrong approach anyway - this call needs to be dropped completely in its current form.

It's only a workaround for openQA not expecting hardware supplements anyway. Dominique suggested to call "zypper inr --no-recommends" instead.

@favogt thanks for clarifying, "zypper inr --no-recommends" seems the better way to go then. I'm currently testing it.

It also fails with --no-recommends in various ways...

One is this http://amazing.suse.cz/tests/3973#step/yast2_i/27 :
2019-03-13 09:33:16 susetest(5213) [zypp] Exception.cc(log):166 RpmDb.cc(doInstallPackage):2117 THROW: Subprocess failed. Error: RPM failed: Can't fork (Cannot allocate memory).

Another is this, on leap 15.0 amd sle 12 :
Unknown option : --no-recommends

I can't reach amazing.suse.de from here.

That "--no-recommends" does not exist on SLE 12 and Leap 15.0 should not matter, the zypper call shouldn't be needed there at all.

It looks indeed like that zypper_call is completely useless.
But, we still may run out of memory as in http://amazing.suse.cz/tests/3994#step/yast2_i/24

2019-03-13 12:33:02 <1> susetest(4866) [zypp::exec++] ExternalProgram.cc(start_program):259 Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--noglob' '--force' '--nodeps' '--' '/var/cache/zypp/packages/repo-oss/noarch/desktop-translations-84.87.20190131.bc9de591-1.1.noarch.rpm'
2019-03-13 12:33:02 <3> susetest(4866) [zypp::exec] ExternalProgram.cc(start_program):395 Can't fork (Cannot allocate memory).

This particular SUT (rescue) uses only 1534 MB of ram, though. I propose that we just increase this value, or remove one of the modules that install packages for that SUT.

JRivrain wrote:

This particular SUT (rescue) uses only 1534 MB of ram, though. I propose that we just increase this value, or remove one of the modules that install packages for that SUT.

1.5GB of RAM to run a rescue system is definitively already MORE than I'd expect to be useful. Installing all kind of packages into a live system is in any case not the scope of the live environment. More RAM won't solve the problem

JRivrain wrote:

Another is this, on leap 15.0 amd sle 12 :
Unknown option : --no-recommends

This is a problem - a nasty one even.

Maybe it's better to just detect the 'recommended packages to be installed' by yast2_i and handle it form within there - not with an explicit zypper inr call. Old distros don't show it (libzypp did not have the feature) - and new ones would handle it gracefully without this zypper inr hack

dimstar wrote:

JRivrain wrote:

Another is this, on leap 15.0 amd sle 12 :
Unknown option : --no-recommends

This is a problem - a nasty one even.

Maybe it's better to just detect the 'recommended packages to be installed' by yast2_i and handle it form within there - not with an explicit zypper inr call. Old distros don't show it (libzypp did not have the feature) - and new ones would handle it gracefully without this zypper inr hack

It's not a problem because only those distros with support for --no-recommends actually need the call.

So I don't see any problem here.

I'd prefer it as well though if openQA could handle yast2 sw_single not being empty on the first start properly though.

I'd prefer it as well though if openQA could handle yast2 sw_single not being empty on the first start properly though.

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6876 ?

From the test runs I have been doing, it works.

JRivrain wrote:

I'd prefer it as well though if openQA could handle yast2 sw_single not being empty on the first start properly though.

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6876 ?

From the test runs I have been doing, it works.

Ok, so the zypper call can just be removed now?

It seems like. I cannot check the VRs mentioned in the PR, mloviska's laptop being off right now. So I am doing some more on mine, then we may merge this https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/7048

EDIT : Second thought, mloviska tested this thoroughly already, and in his version the zypper call was not present. So I'll just go ahead and remove [WIP] froom the PR.

jrivrain Hi, I am trying to figure out the motivation for this change https://github.com/DimStar77/os-autoinst-distri-opensuse/commit/03afc4a2a177d3abdda35f14d64c401b1d7f9954#diff-ddd6b723cde394cb699d7dca93e05d2e
jrivrain Is it that you need a specific driver for jeOS ?
ccret the test looks for an empty list of packages when it checks the yast screen
jrivrain ok, so it seems we do not need this anymore, thanks to https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6876

PR : https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/7048

Still some issues in Live cd in TW, i.e.: https://openqa.opensuse.org/tests/885558

JERiveraMoya wrote:

Still some issues in Live cd in TW, i.e.: https://openqa.opensuse.org/tests/885558

Looks like a missing needle - I'll try with a new one.

favogt wrote:

JERiveraMoya wrote:

Still some issues in Live cd in TW, i.e.: https://openqa.opensuse.org/tests/885558

Looks like a missing needle - I'll try with a new one.

Almost - it installed the packages but apparently ran out of disk space.

@favogt To me https://openqa.opensuse.org/tests/885558 looks like a needle issue, could you show the logs you found that indicate lack of memory ? If so I assume we should see something as I mentioned above. Or have you seen a memory failure in another test run ?

JRivrain wrote:

@favogt To me https://openqa.opensuse.org/tests/885558 looks like a needle issue, could you show the logs you found that indicate lack of memory ? If so I assume we should see something as I mentioned above. Or have you seen a memory failure in another test run ?

My comment was referring to the next run, after I added the needle.

I used developer mode to debug https://openqa.opensuse.org/tests/886182#live, the reason it runs out of memory (= disk space, as tmpfs is used) is that salt-master/salt-minion and "libc.so.6" are not uninstalled, leaving ~500MiB of binaries behind.

JRivrain wrote:

Ok, it was hard to test until we have those needles fixed. I put this ticket back to in-progress, we have to find a consensus on which test to disable in all those "live" tests. Too many packages are installed, obviously.

I'll do a PR which adds "zypper rm -u" calls to salt and libc tests - that should work fine.

It makes sense, I thought also of using the rollback flag at the end of salt module if LIVETEST=1.
EDIT : but we have to take care not to break something else later that would require some packages installed. Rodion thinks this should be adressed in another ticket

JRivrain wrote:

It makes sense, I thought also of using the rollback flag at the end of salt module if LIVETEST=1.
EDIT : but we have to take care not to break something else later that would require some packages installed. Rodion thinks this should be adressed in another ticket

Apparently uninstalling the unneeded packages is not enough - YaST's use of ruby needs so much memory that the kernel's overcommit policy forbids forking.
I'll send a PR to disable yast2_i on livetest instead.

Merged, please @JRivrain, check VR and resolve this ticket.
For the follow-up ticket we need to create it and link to this one to not forget.