ubuntu 2004 server on-boarded to uyuni but unable to subscribe to channel

[jawahk]

Problem description

we are able to on-board ubuntu 2004 server to uyuni successfully with saltminion but unable to subscribe to channels, need help to sort thatup

Steps to reproduce

1.on-board the server and try to subscribe the channel via uyuni it throws error

error message : Failed to apply state: channels. "Passed invalid arguments to state.apply: can not serialize 'PosixPath' object\n\n .. versionadded:: 2015.5.0\n\n This function will call :mod:state.highstate\n\ \ <salt.modules.state.highstate> or :mod:state.sls\n <salt.modules.state.sls> based on the arguments passed to this function.\n It exists
\ as a more intuitive way of applying states.\n\n .. rubric:: APPLYING ALL STATES CONFIGURED IN TOP.SLS (A.K.A. :ref:HIGHSTATE <running-highstate>)\n
\n To apply all configured states, simply run state.apply with no SLS\n targets, like so:\n\n .. code-block:: bash\n\n salt ''
\ state.apply\n\n The following additional arguments are also accepted when applying all\n states configured in top.sls:\n\n test\n
\ Run states in test-only (dry-run) mode\n\n mock\n The mock option allows for the state run to execute without actually\n calling
\ any states. This then returns a mocked return which will show\n the requisite ordering as well as fully validate the state run.\n\n
\ .. versionadded:: 2015.8.4\n\n pillar\n Custom Pillar values, passed as a dictionary of key-value pairs\n\n .. code-block:: bash\n
\n salt '' state.apply stuff pillar='{"foo": "bar"}'\n\n .. note::\n Values passed this way will override Pillar values
\ set via\n pillar_roots or an external Pillar source.\n\n exclude\n Exclude specific states from execution. Accepts a list
\ of sls names, a\n comma-separated string of sls names, or a list of dictionaries\n containing sls or id keys. Glob-patterns
\ may be used to match\n multiple states.\n\n .. code-block:: bash\n\n salt '' state.apply exclude=bar,baz\n salt
\ '' state.apply exclude=foo*\n salt '' state.apply exclude="[{'id': 'id_to_exclude'}, {'sls': 'sls_to_exclude'}]"\n\n queue : False\n
\ Instead of failing immediately when another state run is in progress,\n a value of True will queue the new state run to begin running
\ once\n the other has finished.\n\n This option starts a new thread for each queued state run, so use this\n option sparingly.\n
\n .. versionchanged:: 3006.0\n This parameter can also be set via the state_queue configuration\n option. Additionally,
\ it can now be set to an integer representing\n the maximum queue size which can be attained before the state runs\n will fail
\ to be queued. This can prevent runaway conditions where\n new threads are started until system performance is hampered.\n\n localconfig\n
\ Optionally, instead of using the minion config, load minion opts from\n the file specified by this argument, and then merge them with
\ the\n options from the minion config. This functionality allows for specific\n states to be run with their own custom minion configuration,
\ including\n different pillars, file_roots, etc.\n\n .. code-block:: bash\n\n salt '' state.apply localconfig=/path/to/minion.yml\n
\n state_events\n The state_events option sends progress events as each function in\n a state run completes execution.\n\n ..
\ versionadded:: 3006.0\n\n\n .. rubric:: APPLYING INDIVIDUAL SLS FILES (A.K.A. :py:func:STATE.SLS <salt.modules.state.sls>)\n\n To apply individual
\ SLS files, pass them as a comma-separated list:\n\n .. code-block:: bash\n\n # Run the states configured in salt://stuff.sls (or salt://stuff/init.sls)\n
\ salt '' state.apply stuff\n\n # Run the states configured in salt://stuff.sls (or salt://stuff/init.sls)\n # and salt://pkgs.sls
\ (or salt://pkgs/init.sls).\n salt '' state.apply stuff,pkgs\n\n # Run the states configured in a more deeply nested directory such
\ as salt://my/organized/stuff.sls (or salt://my/organized/stuff/init.sls)\n salt '' state.apply my.organized.stuff\n\n The following additional
\ arguments are also accepted when applying\n individual SLS files:\n\n test\n Run states in test-only (dry-run) mode\n\n mock\n
\ The mock option allows for the state run to execute without actually\n calling any states. This then returns a mocked return which will
\ show\n the requisite ordering as well as fully validate the state run.\n\n .. versionadded:: 2015.8.4\n\n pillar\n Custom
\ Pillar values, passed as a dictionary of key-value pairs\n\n .. code-block:: bash\n\n salt '' state.apply stuff pillar='{"foo"
: "bar"}'\n\n .. note::\n Values passed this way will override Pillar values set via\n pillar_roots or an external
\ Pillar source.\n\n queue : False\n Instead of failing immediately when another state run is in progress,\n a value of True will
\ queue the new state run to begin running once\n the other has finished.\n\n This option starts a new thread for each queued state run,
\ so use this\n option sparingly.\n\n .. versionchanged:: 3006.0\n This parameter can also be set via the state_queue configuration\n
\ option. Additionally, it can now be set to an integer representing\n the maximum queue size which can be attained before the
\ state runs\n will fail to be queued. This can prevent runaway conditions where\n new threads are started until system performance
\ is hampered.\n\n concurrent : False\n Execute state runs concurrently instead of serially\n\n .. warning::\n\n This flag
\ is potentially dangerous. It is designed for use when\n multiple state runs can safely be run at the same time. Do not\n use
\ this flag for performance optimization.\n\n saltenv\n Specify a salt fileserver environment to be used when applying states\n\n ..
\ versionchanged:: 0.17.0\n Argument name changed from env to saltenv\n\n .. versionchanged:: 2014.7.0\n If no
\ saltenv is specified, the minion config will be checked for an\n environment parameter and if found, it will be used. If none is\n
\ found, base will be used. In prior releases, the minion config\n was not checked and base would always be assumed when
\ the\n saltenv was not explicitly set.\n\n pillarenv\n Specify a Pillar environment to be used when applying states. This\n
\ can also be set in the minion config file using the\n :conf_minion:pillarenv option. When neither the\n :conf_minion:pillarenv
\ minion config option nor this CLI argument is\n used, all Pillar environments will be merged together.\n\n localconfig\n Optionally,
\ instead of using the minion config, load minion opts from\n the file specified by this argument, and then merge them with the\n options
\ from the minion config. This functionality allows for specific\n states to be run with their own custom minion configuration, including\n
\ different pillars, file_roots, etc.\n\n .. code-block:: bash\n\n salt '' state.apply stuff localconfig=/path/to/minion.yml\n
\n sync_mods\n If specified, the desired custom module types will be synced prior to\n running the SLS files:\n\n .. code-block::
\ bash\n\n salt '' state.apply stuff sync_mods=states,modules\n salt '*' state.apply stuff sync_mods=all\n\n .. note::\n
\ This option is ignored when no SLS files are specified, as a\n :ref:highstate <running-highstate> automatically syncs all
\ custom\n module types.\n\n .. versionadded:: 2017.7.8,2018.3.3,2019.2.0\n\n state_events\n The state_events option sends
\ progress events as each function in\n a state run completes execution.\n\n .. versionadded:: 3006.0\n "

Uyuni version

Reading installed packages...


Information for package Uyuni-Server-release:
---------------------------------------------
Repository     : uyuni-server-stable
Name           : Uyuni-Server-release
Version        : 2023.09-230900.207.8.uyuni3
Arch           : x86_64
Vendor         : obs://build.opensuse.org/systemsmanagement:Uyuni
Support Level  : Level 3
Installed Size : 1.4 KiB
Installed      : Yes (automatically)
Status         : out-of-date (version 2023.04-220400.204.2.uyuni2 installed)
Source package : Uyuni-Server-release-2023.09-230900.207.8.uyuni3.src
Summary        : Uyuni Server
Description    :
    Uyuni lets you efficiently manage physical, virtual,
    and cloud-based Linux systems. It provides automated and cost-effective
    configuration and software management, asset management, and system
    provisioning.

Uyuni proxy version (if used)

No response

Useful logs

No response

Additional information

No response

[avshiliaev]

Hey @jawahk would you consider first upgrading your uyuni to the newest version? Also make sure you're onboarding your clients the right way. Either use the WebUI, or refer to this part of the docs: https://www.uyuni-project.org/uyuni-docs/en/uyuni/client-configuration/registration-cli.html