適用項目 SUSE Linux Enterprise Server 15 SP6

3 アップグレードの準備 #

アップグレード手順を開始する前に、システムが正しく準備されていることを確認します。準備内容には、データのバックアップとリリースノートの確認などがあります。以下の章では、順を追って手順を説明します。

3.1 システムが最新であることを確認する #

システムのアップグレードは、最新のパッチレベルからのみサポートされます。zypper patchを実行するか、YaSTモジュールオンライン更新を実行して、最新のシステムの更新がインストールされていることを確認します。

注記: SUSE Linux Enterprise 15用の新しい4096ビット署名キー

2023年半ばに、SUSE Linux Enterprise 15製品ファミリは、RSA 2048ビット署名キーから新しいRSA 4096ビットキーに切り替わりました。この変更はRPMパッケージ、パッケージリポジトリ、およびISO署名を対象としています。更新されなくなった古いリポジトリや、切り替え日までにリリースされたRPMは、古い2048ビットキーで署名されたままになります。

システムを更新すると、SLE 15 SP 4とSP5、およびLTSSバージョンのSLE 15 SP1、SP2、SP3のsuse-build-keyパッケージから、新しいキーがRPMキーリングに自動的にインポートされます。

キーがまだインポートされていない場合は、次のコマンドを使用して手動でインポートできます。

> sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-3fa1d6ce-63c9481c.asc

古いバージョンのSLEを実行している場合、または新しいキーをインポートしていない場合は、アップグレード中にキーを信頼するよう求められます。指紋が一致していることを確認します。

pub   rsa4096/0xF74F09BC3FA1D6CE 2023-01-19 [SC] [expires: 2027-01-18]
Key fingerprint = 7F00 9157 B127 B994 D5CF  BE76 F74F 09BC 3FA1 D6CE
uid           SUSE Package Signing Key <build@suse.de>

さらに、障害復旧用の予備の4096ビットRSAキーがインポートされました。

pub   rsa4096/0xA1BFC02BD588DC46 2023-01-19 [SC] [expires: 2033-01-16]
Key fingerprint = B56E 5601 41D8 F654 2DFF  3BF9 A1BF C02B D588 DC46
uid           SUSE Package Signing Key (reserve key) <build@suse.de>

このキーは次のコマンドを使用して手動でインポートできます。

> sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-d588dc46-63c939db.asc

両方のキーについては、インストールメディアおよびSUSEのWebサイト(https://www.suse.com/support/security/keys/)にも記載されています。

3.2 リリースノートの確認 #

release notesですべての変更点、新機能、および既知の問題のリストを確認してください。docuディレクトリのインストールメディアからもリリースノートを確認できます。

通常、リリースノートにはそれに続く2つのリリースの変更しか記載されていません。サービスパックを1つ以上スキップする場合は、スキップするサービスパックのリリースノートも確認します。

リリースノートを参照して、以下が当てはまるかどうかを確認してください。

使用しているハードウェアに特別な配慮が必要かどうか
現在使用しているソフトウェアパッケージに大幅な変更があるかどうか
インストールには特別な注意が必要

3.3 バックアップの作成 #

アップグレードの前に、既存の設定ファイルを別のメディア(テープデバイスやリムーバブルハードディスクなど)にコピーして、データをバックアップしてください。主に、/etcに保存されているファイル、および/varと/optのディレクトリとファイルの一部に当てはまります。さらに、/home(HOMEディレクトリ)下のユーザデータをバックアップメディアに書き込むようにします。

すべてのデータは、rootユーザでバックアップします。rootのみに、すべてのローカルファイルに関する十分なパーミッションがあります。

YaSTのインストールモードとして既存システムの更新を選択している場合は、もっと後の時点で(システム)バックアップを実行することができます。変更されたすべてのファイルと/etc/sysconfigディレクトリにあるファイルを含めることができます。ただし、これは完全なバックアップではありません。前述したその他の重要なディレクトリがすべて含まれていないからです。/var/adm/backupディレクトリでバックアップを見つけます。

3.4 使用可能なディスク容量の確認 #

ソフトウェアは、バージョンが上がるたびに増加する傾向があります。そのため、更新する前に、使用可能名パーティションの容量を調べてください。ディスク容量が不足する可能性がある場合は、データをバックアップしてから、パーティションのサイズを変更するなどして、使用可能な容量を増やしてください。各パーティションに必要な容量を決定する一般的なルールはありません。必要な容量は、特定のパーティションプロファイルおよび選択したソフトウェアによって異なります。

注記: YaSTでの十分な容量の自動確認

更新手順の実行中に、YaSTは空きディスク容量を確認し、インストールで使用可能な容量を超える可能性がある場合は、ユーザに警告を表示します。その場合、更新を実行すると、システムが使用できなくなることがあります。操作の内容を(事前のテストによって)確実に把握している場合にのみ、この警告をスキップして更新を続行できます。

3.4.1 Btrfs以外のファイルシステムにおける空きディスク容量の確認 #

dfコマンドを使用して、使用可能なディスク容量を表示できます。たとえば、例3.1「df -hによるリスト」では、ルートパーティションは/dev/sda3です(/としてマウントされています)。

例 3.1: df -hによるリスト #

Filesystem     Size  Used Avail Use% Mounted on
     /dev/sda3       74G   22G   53G  29% /
     tmpfs          506M     0  506M   0% /dev/shm
     /dev/sda5      116G  5.8G  111G   5% /home
     /dev/sda1       44G    4G   40G   9% /data

3.4.2 Btrfsファイルシステムの空きディスク容量の確認 #

Btrfsファイルシステムでは、dfの出力は誤解を招く可能性があります。生データが割り当てる領域とは別に、Btrfsファイルシステムもメタデータ用の領域を割り当てて使用するからです。

その結果、まだ大量の領域を使用できるように見えても、Btrfsファイルシステムによって領域不足がレポートされることがあります。その場合、メタデータ用に割り当てられた領域はすべて使用されています。Btrfsファイルシステムで使用済みスペースと使用可能スペースを確認する方法の詳細については、1.2.2.3項「空き領域の確認」を参照してください。詳細については、man 8 btrfs-filesystemとhttps://btrfs.wiki.kernel.org/index.php/FAQを参照してください。

マシンでBtrfsをルートファイルシステムとして使用している場合、十分な空き容量があることを確認します。すべてのマウント済みパーティションの使用可能なスペースを確認します。最悪の場合、アップグレードには、新しいスナップショット用に、現在のルートファイルシステムと同じディスク容量が必要になります(/.snapshotがない場合)。

効果が実証されている推奨事項は次のとおりです。

Btrfsを含めてすべてのファイルシステムで、大きなRPMをダウンロードし、インストールできるだけの空きディスク容量が必要です。古いRPMが使用している容量は、新しいRPMのインストール後にのみ解放されます。
スナップショットがあるBtrfsの場合、現在のインストールで使用している容量と同じだけの空き容量が最低でも必要です。現在のインストール環境の2倍の空き容量を確保することを推奨します。
十分な空き容量がない場合、snapperを使用して古いスナップショットを削除することができます。
```
# snapper list
      # snapper delete NUMBER
```
しかし、すべてのケースでこの方法が役立つとは限りません。マイグレーションの前には、大半のスナップショットが占めている容量はごくわずかです。

3.5 インストール済みパッケージとリポジトリの一覧 #

インストール済みパッケージのリストを記録できます。たとえば、新しいメジャーSLEリリースを新規インストールする場合や、旧バージョンに戻す場合などです。

注記

インストール済みパッケージまたは使用中のリポジトリの中にはSUSE Linux Enterpriseの最新リリースで利用できないものもあることに注意してください。名前が変更されていたり、ほかのパッケージやリリースに置き換えられていたりすることもあります。また、レガシ目的で引き続き提供されていても、デフォルトでは別のパッケージが使用されるパッケージもあります。したがって、ファイルを多少手動で編集しなければならない場合があります。これはテキストエディタで実行できます。

使用中のすべてのリポジトリのリストを記述したrepositories.bak.repoという名前のファイルを作成します:
```
# zypper lr -e repositories.bak
```
さらに、すべてのインストール済みパッケージのリストを記述したinstalled-software.bakという名前のファイルも作成します。
```
# rpm -qa --queryformat '%{NAME}\n' >
     installed-software.bak
```
両方のファイルをバックアップします。これらのリポジトリとインストール済みパッケージは、次のコマンドで復元できます。
```
# zypper ar repositories.bak.repo
# zypper install $(cat installed-software.bak)
```
注記: 新しいメジャーリリースへの更新によりパッケージ数が増える
新しいメジャーバージョン(SLE X+1)にアップグレードされるシステムには、最初のシステム(SLE X)より多くのパッケージが含まれる場合があります。同じパターンを選択したSLE X+1の新規インストールよりも多くのパッケージが含まれる場合もあります。その理由は次のとおりです。
- パッケージをより細かく選択できるように、パッケージが分割されています。例: SLE 11の37個のtexliveパッケージは、SLE 15では3000個のパッケージに分割されました。
- パッケージが分割された際、以前のバージョンと同じ機能を保つために、新しいパッケージはすべて、アップグレードとしてインストールされるようになりました。ただし、SLE X+1の新規インストールの新しいデフォルトでは、すべてのパッケージをインストールしない場合があります。
- SLE Xからの古いパッケージが、互換性の理由で保持されている可能性があります。
- パッケージの依存関係およびパターンの範囲が変更されている可能性があります。

3.6 LTSS拡張機能を無効にする #

長期サービスパックサポート(LTSS)を備えたSUSE Linux Enterprise Serverシステムを、まだ一般的なサポート下にあるバージョンにアップグレードすると、No migration available (利用可能なマイグレーションはありません)というエラーでアップグレードが失敗します。このエラーは、zypper migrationが「すべての」リポジトリをマイグレートしようとするが、まだ新しいバージョンのLTSSリポジトリが存在しないため発生します。

この問題を解決するには、アップグレードする前にLTSS拡張機能を無効にします。

LTSS拡張機能が有効になっているかどうかを確認します。

> sudo SUSEConnect --list-extensions | grep LTSS
SUSE Linux Enterprise Server LTSS 12 SP4 x86_64 (Installed)
Deactivate with: SUSEConnect -d -p SLES-LTSS/12.4/x86_64

先に述べたSUSEConnect出力からのコマンドを使用して、LTSS拡張機能を無効にします。

> sudo SUSEConnect -d -p SLES-LTSS/12.4/x86_64
Deregistered SUSE Linux Enterprise Server LTSS 12 SP4 x86_64
To server: https://scc.suse.com/

zypper lrでLTSSリポジトリが存在していないことを確認します。

3.7 PostgreSQLデータベースのマイグレート #

SUSE Linux Enterprise Server 15 SP6は、PostgreSQLデータベースのバージョン14、15とともに出荷されます。デフォルトはバージョン15です。ただし、古いバージョンのSUSE Linux Enterprise ServerからアップグレードするためのLegacyモジュールにはバージョン14が含まれます。

データベースのマイグレーション作業が必要であることから、自動アップグレードプロセスはありません。そのため、あるバージョンから別のバージョンへの切り替えは手動で行う必要があります。

マイグレーションプロセスは、pg_upgradeコマンドで行います。このコマンドは、従来のdumpとreloadコマンドに代わる方式です。「dump & reload」方式と比べてpg_upgradeの方がマイグレーション時間が短くなります。

各PostgreSQLバージョンのプログラムファイルは、異なる、バージョン依存のディレクトリに格納されます。たとえば、バージョン9.6は/usr/lib/postgresql96/、バージョン10は/usr/lib/postgresql10/、バージョン13は/usr/lib/postgres13/に格納されます。PostgreSQLのバージョニングポリシーが、メジャーバージョン9.6と10の間で変更されていることに注意してください。詳細については、https://www.postgresql.org/support/versioning/を参照してください。

重要: SLE 11からのアップグレード

SLE 11からアップグレードする場合、postgresql94がアンインストールされ、PostgreSQLのより高いバージョンにデータベースをマイグレーションするために使用できません。したがって、この場合、システムをアップグレードする前にPostgreSQLデータベースをマイグレートしてください。

以下の手順は、バージョン12から13へのデータベースマイグレーションについて説明しています。スタートまたはターゲットとして異なるバージョンを使用する場合は、それに応じてバージョン番号を置き換えます。

データベースマイグレーションを実行するには、次の手順を実行します。

以下の前提条件が満たされていることを確認します。
- 満たされていない場合、保守アップデートで、古いPostgreSQLバージョンを最新リリースにアップグレードします。
- 既存のデータベースのバックアップを作成します。
- 新規のPostgreSQLのメジャーバージョンのパッケージをインストールします。SLE 15 SP6の場合、これは、postgresql13-serverおよびそのパッケージが依存するすべてのパッケージをインストールすることを意味します。
- コマンドpg_upgradeを含むパッケージpostgresql13-contribをインストールします。
- ご使用のPostgreSQLデータ領域(デフォルトでは/var/lib/pgsql/data)に十分な空き容量があることを確認します。容量が厳しい場合、次のSQLコマンドをデータベースごとに実行して、サイズを縮小します(長時間要する場合があります)。
```
VACUUM FULL
```
以下のいずれかでPostgreSQLサーバを停止します。
```
# /usr/sbin/rcpostgresql stop
```
あるいは、
```
# systemctl stop postgresql.service
```
(アップグレードのスタートバージョンとして使用しているSLEバージョンによって異なる)。
古いデータディレクトリの名前を変更します。
```
# mv /var/lib/pgsql/data /var/lib/pgsql/data.old
```
新規のデータベースインスタンスを初期化します。initdbを使用して手動で実行するか、PostgreSQLを起動、停止することで自動的に実行します。
```
# /usr/sbin/rcpostgresql start
# /usr/sbin/rcpostgresql stop
```
あるいは、
```
# systemctl start postgresql.service
# systemctl stop postgresql.service
```
(アップグレードのスタートバージョンとして使用しているSLEバージョンによって異なる)。
古いバージョンの設定ファイルを変更している場合は、これらの変更を新しい設定ファイルに転送することを検討します。これは、ファイルpostgresql.auto.conf、postgresql.conf、pg_hba.confおよびpg_ident.confに影響する場合があります。これらのファイルの古いバージョンは/var/lib/pgsql/data.old/にあり、新しいバージョンは/var/lib/pgsql/dataにあります。
古い設定ファイルをコピーすることは推奨されないことに注意してください。コピーすることにより、新しいオプション、新しいデフォルト、および変更されたコメントが上書きされる場合があるためです。

ユーザのpostgresとしてマイグレーションプロセスを開始します。

# su - postgres
postgres > pg_upgrade \
 --old-datadir "/var/lib/pgsql/data.old" \
 --new-datadir "/var/lib/pgsql/data" \
 --old-bindir "/usr/lib/postgresql12/bin/" \
 --new-bindir "/usr/lib/postgresql13/bin/"

新しいデータベースインスタンスを次のいずれかを使用して開始します。
```
# /usr/sbin/rcpostgresql start
```
あるいは、
```
# systemctl start postgresql.service
```
(アップグレードのスタートバージョンとして使用しているSLEバージョンによって異なる)。
マイグレーションが成功したかどうか確認します。テスト範囲はユースケースによって異なり、このステップを自動化する汎用ツールはありません。
すべての古いPostgreSQLパッケージと古いデータディレクトリを削除します。
```
# zypper search -s postgresql12| xargs zypper rm -u
# rm -rf /var/lib/pgsql/data.old
```

データベースのアップグレード、または論理レプリケーションなどの代替方法の使用の詳細については、PostgreSQLの公式ドキュメント(https://www.postgresql.org/docs/13/upgrading.html)を参照してください。

3.8 MySQLまたはMariaDBデータベースのマイグレート #

SUSE Linux Enterprise 12では、SUSEは、MySQLからMariaDBに切り替えました。アップグレードを開始する前に、データベースのバックアップを取得することを強くお勧めします。

データベースマイグレーションを実行するには、次の手順を実行します。

ダンプファイルを作成します。
```
# mysqldump -u root -p --all-databases --add-drop-database > mysql_backup.sql
```
デフォルトでは、mysqldumpは、INFORMATION_SCHEMA、またはperformance_schemaデータベースをダンプしません。詳細については、https://mariadb.com/kb/en/mariadb-dumpmysqldump/を参照してください。
ダンプファイル、環境設定ファイル、/etc/my.cnfおよびディレクトリ/etc/mysql/を後で調べることができるように(インストールのためではありません)安全な場所に保存します。
SUSE Linux Enterprise Serverのアップグレードを実行します。アップグレードが終わっても、前の環境設定ファイル/etc/my.cnfは前のままです。新しい設定は、/etc/my.cnf.rpmnewファイルで確認できます。
必要に応じて、MariaDBデータベースを設定します。以前の環境設定ファイルとディレクトリを使わないでください。これらは、リマインダとして使用し、活用するだけです。
MariaDBサーバを起動して確認してください。
```
# systemctl start mariadb
```
ブートのたびにMariaDBサーバを起動する場合は、そのサービスを有効にします。
```
# systemctl enable mariadb
```
MariaDBが適切に稼働していることを、データベースに接続して確認します。
```
# mariadb -u root -p
```

3.9 JavaアプリケーションのMD5以外のサーバ証明書の作成 #

セキュリティ対策として、MD5ベースの証明書はJavaでサポートされなくなりました。MD5として作成された証明書を持っている場合、次の手順で証明書を再作成してください。

端末を開いて、rootとしてログインします。
秘密鍵を作成します。
```
# openssl genrsa -out server.key 1024
```
より強力な鍵が必要な場合、1024を4096などの大きい数に置き換えます。

証明書署名要求(CSR)を作成します。

# openssl req -new -key server.key -out server.csr

証明書を自己署名します。

# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

PEMファイルを作成します。

# cat server.key server.crt > server.pem

ファイルserver.key、server.crt、server.csrおよびserver.pemを鍵が見つかったそれぞれのディレクトリに配置します。たとえばTomcatの場合、このディレクトリは/etc/tomcat/ssl/です。

3.10 仮想マシンゲストのシャットダウン #

お使いのマシンがKVMまたはXenのVMホストサーバとして機能している場合、アップデートの前には、実行中のすべてのVMゲストを正しくシャットダウンするようにします。そうでないと、更新後にゲストにアクセスできなくなる可能性があります。

3.11 SMTクライアントセットアップの調整 #

アップグレードするマシンがSMTサーバに対してクライアントとして登録されている場合は、次の手順を実行してください。

ホストのclientSetup4SMT.shスクリプトのバージョンが最新であるかどうかを確認します。古いバージョンのSMTのclientSetup4SMT.shはSMT 12クライアントを管理できません。SMTサーバにソフトウェアパッチを定期的に適用している場合、常に最新バージョンのclientSetup4SMT.shを<SMT_HOSTNAME>/repo/tools/clientSetup4SMT.shで見つけることができます。

新しいバージョンのSUSE Linux Enterprise Serverへのマシンのアップグレードが失敗する場合は、手順 3.1の説明に従って、SMTサーバからマシンの登録を解除します。その後、アップグレードプロセスを再開します。

手順 3.1: SMTサーバからSUSE Linux Enterpriseクライアントの登録を解除する #

クライアントマシンにログインします。

次のステップは、クライアントの現在のオペレーティングシステムによって異なります。

SUSE Linux Enterprise 11の場合、次のコマンドを実行します。

> sudo suse_register -E
> sudo rm -f /etc/SUSEConnect
> sudo rm -rf /etc/zypp/credentials.d/*
> sudo rm -rf /etc/zypp/repos.d/*
> sudo rm -f /etc/zypp/services.d/*
> sudo rm -f /var/cache/SuseRegister/*
> sudo rm -f /etc/suseRegister*
> sudo rm -f /var/cache/SuseRegister/lastzmdconfig.cache
> sudo rm -f /etc/zmd/deviceid
> sudo rm -f /etc/zmd/secret

SUSE Linux Enterprise 12の場合、次のコマンドを実行します。

> sudo SUSEConnect --de-register
> sudo SUSEConnect --cleanup
> sudo rm -f /etc/SUSEConnect
> sudo rm -rf /etc/zypp/credentials.d/*
> sudo rm -rf /etc/zypp/repos.d/*
> sudo rm -f /etc/zypp/services.d/*

SMTサーバにログインします。
すべてのクライアントの登録を一覧にして、クライアントが正常に登録解除されているかどうかを確認します。
```
> sudo smt-list-registrations
```
クライアントのホスト名がまだこのコマンドの出力に一覧表示されている場合は、最初の列からクライアントのUnique IDを取得します。(クライアントは複数のIDで一覧表示されている場合があります。)
このクライアントの登録を削除します。
```
> sudo smt-delete-registration -g UNIQUE_ID
```
クライアントが複数のIDで一覧表示されている場合は、その固有のIDのそれぞれについてこのステップを繰り返します。
次のコマンドを再実行して、クライアントが正常に登録解除されているかどうかを確認します。
```
> sudo smt-list-registrations
```

3.12 SLE 12から15へAutoYaSTプロファイルの変更 #

AutoYaSTプロファイルのマイグレート方法については、Appendix D, Differences between AutoYaST profiles in SLE 12 and 15を参照してください。

3.13 登録管理ツール(SMT)サーバのアップグレード #

SMTを実行しているサーバには特別なアップグレード手順が必要です。『Repository Mirroring Tool Guide』のChapter 3, Migrate from SMT to RMTを参照してください。

3.14 カーネルのマルチバージョンサポートの一時的な無効化 #

SUSE Linux Enterprise Serverでは、/etc/zypp/zypp.confの各設定を有効にすることで、複数のカーネルバージョンをインストールできます。特定のサービスパックにアップグレードする場合、この機能のサポートを一時的に無効化する必要があります。更新が正常に完了したら、マルチバージョンサポートを再び有効にできます。マルチバージョンサポートを無効にするには、/etc/zypp/zypp.confの各行をコメント化します。結果は次のようになります。

#multiversion = provides:multiversion(kernel)
#multiversion.kernels = latest,running

更新が正常に完了した後にこの機能を再アクティブ化するには、コメント記号を削除します。マルチバージョンサポートの詳細については、27.1項「マルチバージョンサポートの有効化と設定」を参照してください。

3.15 `resume`ブートパラメータの調整 #

SUSE Linux Enterprise Server 12以前のバージョンがインストールされているシステムでは、/etc/default/grubのデフォルトのカーネルコマンドラインには、ハイバネーション(suspend-to-disk)デバイスを参照するために/dev/sda1などのデバイスノード名を使用するresumeパラメータが含まれている場合があります。デバイスノード名は永続的ではなく、再起動時に変更される可能性があるため、これを修正することを強くお勧めします。修正しない場合、アップグレードされたシステムが再起動時にハングする可能性があります。

ハイバネーションデバイスを検索します。
```
> sudo grep resume /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sda1 splash=silent quiet showopts"
```
ハイバネーションデバイスは/dev/sda1です。コマンドが何も返さない場合、ハイバネーションは設定されていません。

/dev/sda1のUUIDを取得します。

> sudo blkid /dev/vda1
/dev/vda1: UUID="a1d1f2e0-b0ee-4be2-83d5-78a98c585827" TYPE="swap" PARTUUID="000134b5-01"

/dev/sda1のUUIDはa1d1f2e0-b0ee-4be2-83d5-78a98c585827です。

/etc/default/grubを編集し、resumeパラメータを調整します。/dev/sda1をUUID=a1d1f2e0-b0ee-4be2-83d5-78a98c585827に置き換えます。結果は次のようになります。
```
GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=a1d1f2e0-b0ee-4be2-83d5-78a98c585827 splash=silent quiet showopts"
```
grubブートマネージャの設定を更新します。
```
> sudo grub2-mkconfig -o /boot/grub2/grub.cfg
```

システムがハイバネーションを使用しない場合は、resumeパラメータを削除して、ブート設定を更新するだけです。

3.16 IBM Zでのアップグレード #

IBM ZにインストールされたSUSE Linux Enterpriseをアップグレードするには、parmfileなどでカーネルパラメータUpgrade=1を使用する必要があります。5.5項「parmfile: システム設定の自動化」を参照してください。

3.17 IBM POWER: Xサーバの起動 #

SLES 12 for IBM POWERでは、ディスプレイマネージャがローカルのXサーバを起動しないように、デフォルトで設定されています。SLES 12 SP1ではこの設定は逆になっています。今は、ディスプレイマネージャはXサーバを起動します。

アップグレード時に問題が発生するのを避けるため、SUSE Linux Enterprise Serverの設定は自動的には変更されません。アップグレード後にディスプレイマネージャにXサーバを起動させたい場合は、/etc/sysconfig/displaymanagerでDISPLAYMANAGER_STARTS_XSERVERの設定を次のように変更します。

DISPLAYMANAGER_STARTS_XSERVER="yes"