Skip to content

openSUSE Tumbleweed and openSUSE MicroOS for Uyuni

Jump to bottom
Alexander Graul edited this page Dec 6, 2024 · 11 revisions

Intro

Part Hack Weeks 22 and 23

Two PRs produced:

What was tested and works

  • Onboarding via WebUI, bootstrap script as regular Salt minions, and as Salt SSH minions
  • Running Salt Commands as both regular minions and Salt SSH minions (Tested for Hack Week 23, didn't retest for Hack Week 24, but for sure broken for MicroOS, see below)
  • Installing/Removing/Updating packages (Tested for Hack Week 23, didn't retest for Hack Week 24, but for sure broken for MicroOS, see below)
  • Applying formulas (locale formula). Worked only on Tumbleweed (Tested for Hack Week 23, didn't retest for Hack Week 24, but for sure broken for MicroOS, see below)

What does not work

on Tumbleweed and (probably) MicroOS

  • [STILL VALID AS OF HACKWEEK 24] Applying the highstate, as one of the state fails: 
    ----------
          ID: mgr_install_products
    Function: product.installed
        Name: mgr_install_products
      Result: false
     Comment: An error was encountered while installing package(s): Zypper command failure: Loading repository data...
Reading installed packages...
Resolving package dependencies...
2 Problems:
Problem: the to be installed product:openSUSE-20231108-0.x86_64 conflicts with 'distribution-release' provided by the to be installed product:Aeon-20231108-0.x86_64
Problem: the to be installed product:openSUSE-20231108-0.x86_64 requires 'product(openSUSE) = 20231108-0', but this requirement cannot be provided

Problem: the to be installed product:openSUSE-20231108-0.x86_64 conflicts with 'distribution-release' provided by the to be installed product:Aeon-20231108-0.x86_64
 Solution 1: Following actions will be done:
  do not install product:Aeon-20231108-0.x86_64
  deinstallation of product:MicroOS-20231108-0.x86_64
  deinstallation of patterns-microos-base-5.0-80.2.x86_64
  deinstallation of product:MicroOS-20231108-0.x86_64
  deinstallation of patterns-microos-base-zypper-5.0-80.2.x86_64
  deinstallation of patterns-microos-defaults-5.0-80.2.x86_64
 Solution 2: Following actions will be done:
  do not install product:openSUSE-20231108-0.x86_64
  deinstallation of product:MicroOS-20231108-0.x86_64
  deinstallation of patterns-microos-base-5.0-80.2.x86_64
  deinstallation of product:MicroOS-20231108-0.x86_64
  deinstallation of patterns-microos-base-zypper-5.0-80.2.x86_64
  deinstallation of patterns-microos-defaults-5.0-80.2.x86_64

Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): c
     Started: 14:46:19.066941
    Duration: 5788.462
         SLS: packages
     Changed: {}
----------

on MicroOS

  • [VALID AS OF HACKWEEK 24]: The bundle does not start: 
    localhost:/var/log # journalctl -f
Nov 22 14:15:43 localhost.localdomain systemd[1]: venv-salt-minion.service: Main process exited, code=exited, status=203/EXEC
Nov 22 14:15:43 localhost.localdomain systemd[1]: venv-salt-minion.service: Failed with result 'exit-code'.
Nov 22 14:15:43 localhost.localdomain systemd[1]: Failed to start The venvjailed Salt Minion.
Nov 22 14:15:59 localhost.localdomain systemd[1]: venv-salt-minion.service: Scheduled restart job, restart counter is at 12.
Nov 22 14:15:59 localhost.localdomain systemd[1]: Starting The venvjailed Salt Minion...
Nov 22 14:15:59 localhost.localdomain (t-minion)[1275]: venv-salt-minion.service: Failed to execute /usr/lib/venv-salt-minion/bin/salt-minion: Permission denied
Nov 22 14:15:59 localhost.localdomain (t-minion)[1275]: venv-salt-minion.service: Failed at step EXEC spawning /usr/lib/venv-salt-minion/bin/salt-minion: Permission denied
Nov 22 14:15:59 localhost.localdomain systemd[1]: venv-salt-minion.service: Main process exited, code=exited, status=203/EXEC
Nov 22 14:15:59 localhost.localdomain systemd[1]: venv-salt-minion.service: Failed with result 'exit-code'.
Nov 22 14:15:59 localhost.localdomain systemd[1]: Failed to start The venvjailed Salt Minion.
^C

localhost:/var/log # ls -l /usr/lib/venv-salt-minion/bin/salt-minion
-rwxr-xr-x. 1 root root 979 Oct 23 14:46 /usr/lib/venv-salt-minion/bin/salt-minion
    And at audit.log: 
    type=AVC msg=audit(1732285721.541:287): avc:  denied  { entrypoint } for  pid=1523 comm="(t-minion)" path="/usr/lib/venv-salt-minion/bin/salt-minion" dev="sda2" ino=23099 scontext=system_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file permissive=0
type=SERVICE_START msg=audit(1732285721.548:288): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=venv-salt-minion comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
    We need to find out where entrypoint is defined/why it wants to use a tcontect with type lib_t, according to https://suse.slack.com/archives/C02CY2CLLH3/p1732285026395769
  • [WAS VALID AS OF HACKWEEK 23, for 24 I do not know as the bundle does no start] Package operations on Salt SSH Minions, as such minions are not detected as transactional systems.
  • [WAS VALID AS OF HACKWEEK 23, for 24 I do not know as the bundle does no start] Applying formulas or at least the locale formula on regular Salt minions, but I wonder if it's because a reboot was missing, as it worked fine on a Salt SSH minion 
              ID: mgr_timezone_setting
    Function: timezone.system
        Name: MST
      Result: false
     Comment: An exception occurred in this state: Traceback (most recent call last):
  File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/state.py", line 2401, in call
    ret = self.states[cdata["full"]](
  File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 149, in __call__
    return self.loader.run(run_func, *args, **kwargs)
  File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 1234, in run
    return self._last_context.run(self._run_as, _func_or_method, *args, **kwargs)
  File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 1249, in _run_as
    return _func_or_method(*args, **kwargs)
  File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 1282, in wrapper
    return f(*args, **kwargs)
  File "/usr/lib/venv-salt-minion/lib/python3.10/site-packages/salt/states/timezone.py", line 70, in system
    if __salt__["timezone.get_hwclock"]() == "localtime":
  File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 149, in __call__
    return self.loader.run(run_func, *args, **kwargs)
  File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 1234, in run
    return self._last_context.run(self._run_as, _func_or_method, *args, **kwargs)
  File "/usr/lib/venv-salt-minion/lib64/python3.10/site-packages/salt/loader/lazy.py", line 1249, in _run_as
    return _func_or_method(*args, **kwargs)
  File "/usr/lib/venv-salt-minion/lib/python3.10/site-packages/salt/modules/timezone.py", line 400, in get_hwclock
    ret = _timedatectl()
  File "/usr/lib/venv-salt-minion/lib/python3.10/site-packages/salt/modules/timezone.py", line 57, in _timedatectl
    raise CommandExecutionError(msg)
salt.exceptions.CommandExecutionError: timedatectl failed: System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

     Started: 14:46:24.855576
    Duration: 8.386
         SLS: locale
     Changed: {}

Does not work in Tumbleweed

  • [WAS VALID AS OF HACKWEEK 23, not retested for 24] I updated packages, but it seems that after that the package refresh did not happen (as Salt Minion) or it happen but didn't refresh the UI (Salt-SSH minion), so in both cases I still see the warning about pending updates

What else should be needed before a Tech preview

Reposync repository pruning

We should have a way to prune the repositories with reposync. openSUSE Tumbleweeds repositories drop packages regularly, and without this Tumbleweed (and MicroOS updates will grow very quickly very large, and can potentially fill the Uyuni Server Hard disk.

How to test

WARNING: Do not sync the openSUSE Tumbleweed or openSUSE MicroOS in a production Uyuni Server. See the problem described at Reposync repository pruning above. Besides, openSUSE Tumbleweed and openSUSE MicroOS do not fully work, as described above.

If you accept the limitations and want to test, and provided feedback or even fixes, then you need to create a separate Uyuni Server, and then add and sync the channels by running, as root:

For Tumbleweed:

spacewalk-common-channels -a x86_64 opensuse_tumbleweed opensuse_tumbleweed-non-oss opensuse_tumbleweed-openh264 opensuse_tumbleweed-
updates opensuse_tumbleweed-uyuni-client

For MicroOS:

spacewalk-common-channels -a x86_64 opensuse_microos opensuse_microos-non-oss opensuse_microos-openh264 opensuse_microos-update opensuse_microos-uyuni-client

When the sync is complete (spacewalk-common-channels launches it), the bootstrap repositories will be automatically created, and all you need is activation keys, and start bootstrapping normally.

Clone this wiki locally