Project

General

Profile

Actions

action #134042

closed

auto-update on OSD does not install updates due to "Problem: nothing provides 'libwebkit2gtk3 ..." but service does not fail and we do not get an alert size:M

Added by okurz 9 months ago. Updated 8 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
Start date:
2023-08-09
Due date:
2023-09-12
% Done:

0%

Estimated time:

Description

Observation

From OSD:

$ sudo systemctl status auto-update
○ auto-update.service - Automatically patch system packages.
     Loaded: loaded (/etc/systemd/system/auto-update.service; static)
     Active: inactive (dead) since Wed 2023-08-09 02:38:25 CEST; 13h ago
TriggeredBy: ● auto-update.timer
   Main PID: 19349 (code=exited, status=0/SUCCESS)

Aug 09 02:37:37 openqa sh[19351]: Building repository 'Update repository with updates from SUSE Linux Enterprise 15' cache [....done]
Aug 09 02:37:37 openqa sh[19351]: Loading repository data...
Aug 09 02:37:46 openqa sh[19351]: Reading installed packages...
Aug 09 02:38:23 openqa sh[19351]: Resolving package dependencies...
Aug 09 02:38:24 openqa sh[19351]: Problem: nothing provides 'libwebkit2gtk3 = 2.40.5' needed by the to be installed libwebkit2gtk3-lang-2.4>
Aug 09 02:38:24 openqa sh[19351]:  Solution 1: deinstallation of libwebkit2gtk3-lang-2.38.6-150200.75.2.noarch
Aug 09 02:38:24 openqa sh[19351]:  Solution 2: do not install patch:openSUSE-SLE-15.4-2023-3233-1.noarch
Aug 09 02:38:24 openqa sh[19351]:  Solution 3: break libwebkit2gtk3-lang-2.40.5-150200.78.1.noarch by ignoring some of its dependencies
Aug 09 02:38:24 openqa sh[19351]: Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c
Aug 09 02:38:25 openqa systemd[1]: auto-update.service: Deactivated successfully.

Acceptance criteria

  • AC1: auto-update.service fails when not all updates can be applied (so that our monitoring will alert on it)
  • AC2: All current updates are applied cleanly on OSD
  • AC3: All other salt controlled hosts have current updates applied

Suggestions

  • Ensure that the command we use in auto-update.service fails the service
  • Make sure that patches+updates are applied for all salt controlled machines

Related issues 2 (1 open1 closed)

Related to openQA Infrastructure - action #134852: gitlab CI job fails in telegraf check with unsupported option since telegraf package on monitor.qa.suse.de was downgraded due to invalid repo metadataNew2023-08-30

Actions
Related to openQA Infrastructure - action #134282: [tools] network protocols failures on multimachine tests on HA/SAP size:S auto_review:"no candidate.*iscsi-target-overview-service-tab|yast2.+firewall.+services.+add.+zone":retryResolvednicksinger2023-08-15

Actions
Actions #1

Updated by mkittler 9 months ago

  • Subject changed from auto-update on OSD does not install updates due to "Problem: nothing provides 'libwebkit2gtk3 ..." but service does not fail and we do not get an alert to auto-update on OSD does not install updates due to "Problem: nothing provides 'libwebkit2gtk3 ..." but service does not fail and we do not get an alert size:M
  • Status changed from New to Workable
Actions #2

Updated by osukup 8 months ago

  • Status changed from Workable to In Progress
  • Assignee set to osukup
Actions #3

Updated by openqa_review 8 months ago

  • Due date set to 2023-09-12

Setting due date based on mean cycle time of SUSE QE Tools

Actions #4

Updated by osukup 8 months ago

https://gitlab.suse.de/openqa/salt-states-openqa/-/merge_requests/951/diffs

this will in this situation deinstall lang file and install updated libwebkit2gtk3 2.40.5 ..

Actions #5

Updated by okurz 8 months ago

  • Related to action #134852: gitlab CI job fails in telegraf check with unsupported option since telegraf package on monitor.qa.suse.de was downgraded due to invalid repo metadata added
Actions #6

Updated by okurz 8 months ago

I think we need to make an explicit "zypper ref" call and check for the result before trying the upgrade, compare to https://github.com/os-autoinst/openQA/blob/master/script/openqa-continuous-update#L32.

Or is it possible to ask zypper to only conduct a command if zypper ref actually succeeds?

Actions #7

Updated by livdywan 8 months ago

  • Related to action #134282: [tools] network protocols failures on multimachine tests on HA/SAP size:S auto_review:"no candidate.*iscsi-target-overview-service-tab|yast2.+firewall.+services.+add.+zone":retry added
Actions #8

Updated by tinita 8 months ago

An alternative: https://gitlab.suse.de/openqa/salt-states-openqa/-/merge_requests/978 Do a zypper ref before the actual update

Actions #10

Updated by livdywan 8 months ago

  • Status changed from In Progress to Feedback
  • Assignee changed from osukup to livdywan

I think this should be in Feedback at this point. Things are looking good... although I'm not sure how to easily prove that? sudo salt -C 'worker*' cmd.run 'needs-restarting -r' tells us there's no outstanding changes?

Actions #11

Updated by livdywan 8 months ago

  • Status changed from Feedback to Resolved

livdywan wrote in #note-10:

I think this should be in Feedback at this point. Things are looking good... although I'm not sure how to easily prove that? sudo salt -C 'worker*' cmd.run 'needs-restarting -r' tells us there's no outstanding changes?

Better in fact: zypper -dD up and journalctl -e -u autoupdate (Locks on salt packages are still there, different issue)

Actions

Also available in: Atom PDF