Zen

Source string Source string

12/10000 · 12

The string is read only.

English Actions
Because of a problem in the computed partition size value, the {saltboot} formula can sometimes fail when it is created on SLE{nbsp}11 SP3 clients, with an error like this:
ID: disk1_partitioned
Function: saltboot.partitioned
Name: disk1
Result: false
Comment: An exception occurred in this state: Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/salt/state.py", line 1767, in call
**cdata['kwargs'])
File "/usr/lib/python2.6/site-packages/salt/loader.py", line 1705, in wrapper
return f(*args, **kwargs)
File "/var/cache/salt/minion/extmods/states/saltboot.py", line 393, in disk_partitioned
existing = __salt__['partition.list'](device, unit='MiB')
File "/usr/lib/python2.6/site-packages/salt/modules/parted.py", line 177, in list_
'Problem encountered while parsing output from parted')
CommandExecutionError: Problem encountered while parsing output from parted
This problem can be resolved by manually configuring the size of the partition containing the operating system. When the size is set correctly, formula creation works as expected.
Procedure: Manually Configuring the Partition Size in the {saltboot} Formula
In the {productname} {webui}, navigate to menu:Systems[System Groups] and select the ``Hardware Type Group`` that contains the SLE{nbsp}11 SP3 client that is causing the error.
In the [guimenu]``Formulas`` tab, navigate to the [guimenu]``Saltboot`` subtab.
Locate the partition that contains the operating system, and in the [guimenu]``Partition Size`` field, type the appropriate size (in MiB).
Click btn:[Save Formula], and apply the highstate to save your changes.
Troubleshooting Schema Upgrade Fails
If the schema upgrade fails, the database version check and all the other spacewalk services do not start. Run [command]``spacewalk-service start`` for more information and hints how to proceed.
You can also run the version check directly:
systemctl status uyuni-check-database.service
journalctl -u uyuni-check-database.service
These commands print debug information if you do not want to run the more general [command]``spacewalk-service`` command.
Setting up SUSE Manager with separate disk for data in Public Cloud (BYOS)
**Issue:**
{productname} setup results with an error while restarting services during setup.
The setup fails on restarting Tomcat.
<img src="../../assets/images/error-1.png">
**Reason:**
When {productname} is set up using separate disks for cache, pgsql and spacewalk, the existing data within these partitions are covered under the new mount point.
<img src="../../assets/images/partitions.png">
Because of this, data for certain services like tomcat go missing due to a broken symbolic link.
<img src="../../assets/images/broken-symlink.png">
As {productname} instance of cloud already has some services set up, when the data is not available during set up it causes the service to not restart as expected. Therefore the setup fails.
<img src="../../assets/images/incomplete-files.png">
Actual data which should be present:
<img src="../../assets/images/actual-files.png">
**How to Recreate:**
{productname} Server provisioned in {aws} uses relevant AMI for {byos}
Separate storage for spacewalk, {postgresql} and cache.

Loading…

No matching activity found.
Browse all string changes

Things to check

Long untranslated

The string has not been translated for a long time

Reset

Glossary

English English
No related strings found in the glossary.

String information

Source string description
type: Plain text
Flags
no-wrap, read-only
Source string location
modules/administration/pages/troubleshooting/tshoot-suma-installation-public-cloud.adoc:2
String age
4 months ago
Last updated
a month ago
Source string age
4 months ago
Translation file
l10n-weblate/administration/administration.pot, string 2661