目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Linux Enterprise Serverマニュアル / 管理ガイド / トラブルシューティング / 最も頻繁に起こる問題およびその解決方法
適用項目 SUSE Linux Enterprise Server 15 SP6

48 最も頻繁に起こる問題およびその解決方法

 

この章では、一連の潜在的な問題とその解決法について説明します。状況が正確に記載されていなくても、問題解決のヒントになる類似した状況が見つかる場合があります。

48.1 情報の検索と収集

 

Linuxでは、詳細なレポートが提供されます。システムで問題が発生したときに参照すべき場所がいくつかあります。それらのほとんどがLinuxシステムの標準であり、いくつかはSUSE Linux Enterprise Serverシステムに関連しています。大半のログファイルはYaSTを使って表示することができます(その他 › 起動ログを表示)。

YaSTは、サポートチームが必要とするすべてのシステム情報を収集することができます。その他 › サポートの順に選択し、問題のカテゴリを選択します。すべての情報が収集されたら、それをサポートリクエストに添付します。

最も頻繁にチェックされるログファイルのリストの後には、一般的な目的に関する説明があります。~を含むパスは、現在のユーザのホームディレクトリを参照します。

表 48.1: ログファイル
 

ログファイル

説明

~/.xsession-errors

現在実行中のデスクトップアプリケーションからのメッセージです。

/var/log/apparmor/

AppArmorからのログファイル。詳細については、Part V, “Confining privileges with AppArmor”を参照してください。

/var/log/audit/audit.log

システムのファイル、ディレクトリ、またはリソースに対するすべてのアクセスを追跡し、システムコールをトレースする監査からのログファイル。詳細については、Part VII, “The Linux Audit Framework”を参照してください。

/var/log/mail.*

メールシステムから受け取るメッセージです。

/var/log/NetworkManager

NetworkManagerからのログファイルで、ネットワーク接続についての問題を収集します。

/var/log/samba/

Sambaサーバおよびクライアントのログメッセージを含んでいるディレクトリです。

/var/log/warn

カーネルおよびシステムのログデーモンから受け取る、「警告」レベル以上のすべてのメッセージ。

/var/log/wtmp

現在のコンピュータセッションのユーザのログインレコードを含むバイナリファイルです。lastコマンドを使用して表示させます。

/var/log/Xorg.*.log

Xウィンドウシステムからの、起動時およびランタイムのログファイルです。Xの失敗した起動をデバッグするのに役に立ちます。

/var/log/YaST2/

YaSTのアクションおよびその結果を含んでいるディレクトリです。

/var/log/zypper.log

Zypperのログファイル。

ログファイルとは別に、稼働中のシステムの情報も提供されます。表 48.2: /procファイルシステムによるシステム情報を参照してください。

表 48.2: /procファイルシステムによるシステム情報
 

ファイル

説明

/proc/cpuinfo

プロセッサのタイプ、製造元、モデル、およびパフォーマンスなどを含む情報を表示します。

/proc/dma

どのDMAチャネルが現在使用されているかを表示します。

/proc/interrupts

どの割り込みが使用されているか、各割り込みの使用回数を表示します。

/proc/iomem

I/Oメモリの状態を表示します。

/proc/ioports

その時点でどのI/Oポートが使用されているかを表示します。

/proc/meminfo

メモリステータスを表示します。

/proc/modules

個々のモジュールを表示します。

/proc/mounts

現在マウントされているデバイスを表示します。

/proc/partitions

すべてのハードディスクのパーティション設定を表示します。

/proc/version

現在のLinuxバージョンを表示します。

Linuxカーネルは、/procファイルシステムの場合を除いて、メモリ内ファイルシステムであるsysfsモジュールで情報をエクスポートします。このモジュールは、カーネルオブジェクトとその属性および関係を表します。sysfsの詳細については、第29章 「udevによる動的カーネルデバイス管理」でudevのコンテキストを参照してください。表 48.3には、/sysの下にある最も一般的なディレクトリの概要が含まれています。

表 48.3: /sysファイルシステムによるシステム情報
 

ファイル

説明

/sys/block

システム内で検出された各ブロックデバイスのサブディレクトリが含まれています。一般に、これらの大半はディスクタイプのデバイスです。

/sys/bus

各物理バスタイプのサブディレクトリが含まれます。

/sys/class

デバイスの機能タイプとしてグループ化されたサブディレクトリが含まれます(graphics、net、printerなど)。

/sys/device

グローバルなデバイス階層が含まれます。

Linuxには、システム解析とモニタリング用のさまざまなツールが用意されています。システム診断で使用される最も重要なツールの選択については、Chapter 2, System monitoring utilitiesを参照してください。

次の各シナリオは、問題を説明するヘッダに続いて、推奨される解決方法、より詳細な解決方法への利用可能な参照、および関連する他のシナリオへの相互参照が書かれた、1つまたは2つの段落から構成されています。

48.2 ブートの問題

 

ブートの問題とは、システムが適切にブートしないような場合を指します(意図したターゲットおよびログイン画面までブートしない場合)。

48.2.1 GRUB 2ブートローダをロードできない

 

ハードウェアが問題なく機能している場合、ブートローダが壊れてしまってLinuxがコンピュータ上で起動できない可能性があります。このような場合、ブートローダを修復する必要があります。そのためには、48.5.2項 「レスキューシステムの使用」の説明に従ってレスキューシステムを起動し、48.5.2.4項 「ブートローダの変更と再インストール」の手順に従う必要があります。

または、次の手順でレスキューシステムを使用してブートローダを修復できます。インストールメディアからマシンをブートします。ブート画面で、詳細 › Linuxシステムのブートを選択します。インストール済みシステムとカーネルが含まれるディスク、およびデフォルトのカーネルオプションを選択します。

システムがブートしたら、YaSTを起動してシステム › ブートローダに切り替えます。MBRに汎用ブートコードを書き込むオプションが有効になっていることを確認して、OKをクリックします。これにより、ブートローダが壊れている場合は上書きして修復し、ブートローダが見つからない場合はインストールします。

コンピュータが起動しない理由は他にBIOS関連のものが考えられます。

BIOS設定

ハードディスクの参照情報については、BIOSを確認してください。ハードディスク自体が現在のBIOS設定に見つからない場合、GRUB 2が単に開始されていない可能性があります。

BIOSブートオーダー

お使いのシステムのブートオーダーがハードディスクを含んでいるか確認します。ハードディスクオプションが有効になっていない場合、システムは適切にインストールされていますが、ハードディスクへのアクセスが要求される際に起動に失敗する可能性があります。

48.2.2 グラフィカルログインがない

 

マシンは起動するものの、グラフィカルログインマネージャがブートしない場合は、デフォルトのsystemdターゲットの選択、またはXウィンドウシステムの設定のいずれかに問題があると考えられます。現在のデフォルトのsystemdターゲットを確認するには、sudo systemctl get-defaultコマンドを実行します。返された値が graphical.targetで「ない」場合、sudo systemctl isolate graphical.targetコマンドを実行します。グラフィカルログイン画面が起動する場合は、ログインして、YaST › システム › サービスマネージャを起動し、デフォルトのシステムターゲットをGraphical Interface (グラフィカルインタフェース)に設定します。今後、システムはグラフィカルログイン画面でブートするようになります。

ブートするかグラフィカルターゲットに切り替わっても、グラフィカルログイン画面が起動しない場合は、ご使用のデスクトップかXウィンドウソフトウェアの設定が間違っているか、破損している可能性があります。/var/log/Xorg.*.logのログファイルで、Xサーバが起動を試みた際にXサーバによって記録された詳細メッセージを調べます。デスクトップの起動に失敗する場合は、システムジャーナルにエラーメッセージが記録されている場合があります。エラーメッセージはjournalctlコマンド(詳細は第21章 「journalctl: systemdジャーナルのクエリ」を参照)で問い合わせることができます。これらのエラーメッセージがXサーバの設定の問題を示唆している場合は、これを直すようにしてください。それでもグラフィカルシステムが起動しない場合は、グラフィカルデスクトップを再インストールすることを考えてください。

48.2.3 ルートBtrfsパーティションをマウントできない

 

btrfsルートパーティションが壊れた場合は、次のオプションを試してみてください。

  • -o recoveryオプションを使用してパーティションをマウントする。

  • これが失敗する場合は、ルートパーティション上でbtrfs-zero-logを実行する。

48.2.4 ルートパーティションを強制的に確認する

 

ルートパーティションが壊れた場合、パラメータforcefsckをブートプロンプトで使用します。これにより、オプション-f(強制)がfsckコマンドに渡されます。

48.2.5 スワップを無効にしてブートを有効にする

 

スワップデバイスが使用できず、システムがブート中に有効にできない場合、ブートは失敗する場合があります。次のオプションをカーネルコマンドラインに追加して、すべてのスワップデバイスを無効にしてみます。 

systemd.device_wants_unit=off systemd.mask=swap.target

特定のスワップデバイスを無効にしてみることもできます。 

systemd.mask=dev-sda1.swap

48.2.6 デュアルブートシステムでの再起動中にGRUB 2が失敗する

 

再起動中にGRUB 2が失敗した場合は、BIOSのFast Boot設定を無効にします。

48.3 ログインの問題

 

ログインの問題は、システムがユーザ名とパスワードを受け入れない場合、またはユーザ名とパスワードは受け入れるがグラフィックデスクトップの起動に失敗する場合、エラーが発生する場合、コマンドラインにドロップする場合などに発生します。

48.3.1 有効なユーザ名とパスワードを使っても失敗する

 

この問題は、多くの場合、システムがネットワーク認証またはディレクトリサービスを使用するように設定されており、設定されたサーバから結果を取得できない場合に発生します。rootユーザは、これらのマシンに引き続きログインできる唯一のローカルユーザです。次に、コンピュータが機能しているように見えるのにログインを正しく処理できない一般的な理由を挙げます。

  • ネットワークが機能していません。この場合の更なる対処方法については、48.4項 「ネットワークの問題」を参照してください

  • 現在、DNSが機能していません(このためGNOMEが動作せず、システムはセキュアサーバに検証済みの要求を送信できません)。すべてのアクションに対して、コンピュータの応答に長い時間かかる場合は、この問題の可能性があります。このトピックの詳細は、48.4項 「ネットワークの問題」を参照してください。

  • システムがKerberosを使用するように設定されている場合、システムのローカルタイムは、Kerberosサーバのタイムとの間で許容される相違を超えてしまっている可能性があります(通常 300秒)。NTP (network time protocol)が適切に動いていない、またはローカルのNTPサーバが動いていない場合、Kerberos の認証は機能しなくなります。その理由は、この認証はネットワーク間の一般的なクロック同期に依存しているからです。

  • システムの認証設定が間違って設定されています。関連するPAM設定ファイルの中に誤字や命令の順序違いがないか確認します。PAMおよび関連する設定ファイルの構文に関する背景情報の詳細については、Chapter 2, Authentication with PAMを参照してください。

  • ホームパーティションが暗号化されています。このトピックの詳細は、48.3.3項 「暗号化されたホームパーティションへのログインが失敗します」を参照してください。

外部ネットワークの問題を伴わない場合、解決策はrootとしてログインし、設定を修復することです。実行中のシステムにログインできない場合は、手順18.3「レスキューモードに入る」で概説されているように、レスキューモードで再起動します。

48.3.2 有効なユーザ名とパスワードが受け付けられない

 

これは、今のところユーザが経験する問題のうち、最も一般的なものです。その理由は、この問題が起こる原因がたくさんあるからです。ローカルのユーザ管理および認証を使用するか、ネットワーク認証を使用するかによって、異なる原因によりログイン失敗が発生します。

ローカルユーザ管理は、次の原因により失敗する可能性があります。

  • 間違ったパスワードを入力した可能性があります。

  • ユーザのホームディレクトリが、破損または書き込み保護されたデスクトップ設定ファイルを含んでいます。

  • この特定のユーザを認証するのに、X Window Systemに何らかの問題があります。特に、ユーザのホームディレクトリが、現在のLinuxをインストールする以前の他のLinuxディストリビューションによって使用されている場合です。

ローカルログイン失敗の原因を発見するには、次の手順に従います。

  1. 認証方式全体をデバッグする前に、ユーザがパスワードを正しく覚えているか確認します。ユーザが正しいパスワードを覚えていない場合は、YaSTユーザ管理モジュールを使用してそのユーザのパスワードを変更します。Caps Lockキーに注意し、必要に応じてそのロックを解除します。

  2. rootユーザでログインし、ログインプロセスおよびPAMのエラーメッセージがないかどうかjournalctl -eでシステムジャーナルを確認します。

  3. コンソールからログインしてみます(Ctrl–Alt–F1キーを使用)。これが成功する場合、PAMには問題はありません。その理由は、そのユーザをそのコンピュータ上で認証可能だからです。XウィンドウシステムまたはGNOMEデスクトップに問題がないか探してみてください。詳細については、48.3.4項 「GNOMEデスクトップに問題があります」を参照してください。

  4. ユーザのホームディレクトリが他のLinuxディストリビューションによって使用されている場合、ユーザのホームにあるXauthorityファイルを削除します。Ctrl–Alt–F1 キーを押してコンソールログインを使用し、rm .Xauthorityをこのユーザとして実行します。これにより、X認証の問題はこのユーザに関してはなくなるはずです。グラフィカルログインを再試行します。

  5. 設定ファイルが壊れていて、デスクトップが開始できなかった場合、48.3.4項 「GNOMEデスクトップに問題があります」に進みます。

次に、特定のマシンで特定のユーザのネットワーク認証が失敗する一般的な理由を示します。

  • 間違ったパスワードを入力した可能性があります。

  • コンピュータのローカル認証ファイルの中に存在し、ネットワーク認証システムからも提供されるユーザ名が競合しています。

  • ホームディレクトリは存在しますが、それが壊れている、または利用不可能です。書き込み保護がされているか、その時点でアクセスできないサーバ上にディレクトリが存在するかのどちらかの可能性があります。

  • 認証システム内で、ユーザがその特定のサーバにログインする権限がありません。

  • コンピュータのホスト名が何らかの理由で変更されていて、そのホストにユーザがログインするパーミッションがありません。

  • コンピュータが、認証サーバまたはそのユーザの情報を含んでいるディレクトリサーバに接続できません。

  • この特定のユーザを認証するのに、X Window Systemに何らかの問題があります。特に、ユーザのホームが、現在のLinuxをインストールする以前に他のLinuxディストリビューションによって使用されている場合です。

ネットワーク認証におけるログイン失敗の原因を突き止めるには、次の手順に従います。

  1. 認証方式全体をデバッグする前に、ユーザがパスワードを正しく覚えているか確認します。

  2. 認証用にマシンが利用するディレクトリサーバを判別し、それがきちんと動作しており、他のマシンと適切に通信していることを確認します。

  3. ユーザのユーザ名およびパスワードが他のマシン上でも使用できるかを判別し、そのユーザの認証データが存在し、適切に配布されていることを確認します。

  4. 別のユーザが、問題のある動きをしているマシンにログインできるかどうかを確認します。別のユーザで問題なくログインできる場合、またはrootでログインできる場合、ログイン後、journalctl -e >ファイルでシステムジャーナルを調べます。ログインの試行に対応するタイムスタンプを見つけ出し、PAMによって、エラーメッセージが生成されていないか判別します。

  5. コンソールからログインしてみます(Ctrl–Alt–F1キーを使用)。これが成功する場合、PAMやユーザのホームがあるディレクトリサーバには問題はありません。その理由は、そのユーザをそのコンピュータ上で認証可能だからです。XウィンドウシステムまたはGNOMEデスクトップに問題がないか探してみてください。詳細については、48.3.4項 「GNOMEデスクトップに問題があります」を参照してください。

  6. ユーザのホームディレクトリが他のLinuxディストリビューションによって使用されている場合、ユーザのホームにあるXauthorityファイルを削除します。Ctrl–Alt–F1 キーを押してコンソールログインを使用し、rm .Xauthorityをこのユーザとして実行します。これにより、X認証の問題はこのユーザに関してはなくなるはずです。グラフィカルログインを再試行します。

  7. 設定ファイルが壊れていて、デスクトップが開始できなかった場合、48.3.4項 「GNOMEデスクトップに問題があります」に進みます。

48.3.3 暗号化されたホームパーティションへのログインが失敗します

 

ラップトップでは暗号化されたホームパーティションの使用が推奨されます。ラップトップにログインできない場合、その理由はパーティションのロックを解除できなかったためである場合があります。

ブート時に、暗号化パーティションのロックを解除するためにパスフレーズを入力する必要があります。パスフレーズを入力しない場合、パーティションがロックしたまま起動プロセスが続行します。

暗号化されたパーティションのロックを解除するには、次の手順に従います。

  1. Ctrl–Alt–F1でテキストコンソールに切り替えます。

  2. rootになります。

  3. 次のコマンドにより、ロックを解除するプロセスを再開します。 

    # systemctl restart home.mount

  4. 暗号化されたパーティションのロックを解除するためのパスフレーズを入力します。

  5. テキストコンソールを終了し、Alt–F7でログイン画面に切り替えます。

  6. 通常通りログインします。

48.3.4 GNOMEデスクトップに問題があります

 

GNOMEデスクトップで問題が発生している場合は、グラフィカルなデスクトップ環境の動作不良をトラブルシューティングするためのいくつかの方法があります。次に説明する推奨手順は、壊れたGNOMEデスクトップを修復するための最も安全なオプションを提供します。

手順 48.1: GNOMEのトラブルシューティング
 

  1. YaSTを起動し、セキュリティとユーザに切り替えます。

  2. ユーザとグループの管理ダイアログを開き、追加をクリックします。

  3. 必須フィールドに入力し、OKをクリックして、新しいユーザを作成します。

  4. ログアウトして、新しいユーザとしてログインします。これにより、新しいGNOME環境が提供されます。

  5. 古いユーザアカウントの~/.local/および~/.config/ディレクトリから個々のサブディレクトリを新しいユーザアカウントのそれぞれのディレクトリにコピーします。

    コピー操作を行うたびにログアウトして、新しいユーザとして再度ログインし、GNOMEが引き続き正常に動作するかどうかを確認します。

  6. GNOMEを壊す設定ファイルが見つかるまで、前の手順を繰り返します。

  7. 古いユーザとしてログインし、問題のある設定ファイルを別の場所に移動します。ログアウトして、古いユーザとして再度ログインします。

  8. 以前に作成したユーザを削除します。

48.4 ネットワークの問題

 

システムの多くの問題は、症状が異なるように見えますが、ネットワーク関連である可能性があります。たとえば、システムにユーザがログインできない理由は、ネットワークの問題であったりします。ここでは、ネットワークの問題に直面した場合の簡単なチェックリストを紹介します。

手順 48.2: ネットワークの問題を識別する方法
 

コンピュータとネットワークの接続の確認をする場合、以下の手順に従ってください。

  1. Ethernet接続を使用する場合、はじめにハードウェアを確認します。ネットワークケーブルがコンピュータおよびルータ(またはハブなど)にしっかり差し込まれていることを確認してください。Ethernetコネクタの横に制御ランプがある場合、通常はその両方がアクティブになります。

    接続に失敗する場合、お使いのネットワークケーブルが他のコンピュータでは使用可能かどうか確認します。使用可能な場合、ネットワークカードに問題の原因があります。ネットワークのセットアップにハブやスイッチを使用している場合は、それらが誤っている可能性もあります。

  2. 無線接続を使用する場合、他のコンピュータからワイヤレスリンクが確立できるかどうか確認します。そうでない場合は、無線ネットワークの管理者にお問い合わせください。

  3. 基本的なネットワーク接続を確認し終わったら、どのサービスが応答していないかを探します。お使いの構成上のすべてのネットワークサーバのアドレス情報を集めます。適切なYaSTモジュール内で探すか、システム管理者に問い合わせてください。次のリストには、セットアップにかかわる一般的なネットワークサーバを、それらの故障の兆候とともに表わしています。

    DNS (ネームサービス)

    壊れた、あるいは誤作動しているネームサービスは、ネットワークの機能にさまざまな形で影響を与えます。ローカルマシンの認証をネットワークサーバで行っている場合、名前解決に問題があるためにそれらのサーバが見つからないと、ユーザはログインすることもできません。壊れたネームサーバが管理するネットワーク内のマシンは、お互いを「認識」できないため通信できません。

    NTP (タイムサービス)

    誤作動している、または壊れたNTPサービスは、Kerberosの認証およびXサーバの機能に影響を与える可能性があります。

    NFS (ファイルサービス)

    NFSマウントされたディレクトリに保存されたデータを必要とするアプリケーションがあった場合、このサービスがダウンしてるか、間違って設定されていると、そのアプリケーションは起動できないか、正しく機能しません。最悪のケースとしては、.gconfサブディレクトリを含んでいる、あるユーザのホームディレクトリが、NFSサーバの故障のために検出されなかった場合、そのユーザ個人のデスクトップ設定が起動しません。

    Samba (ファイルサービス)

    故障したSambaサーバ上のディレクトリに保存されたデータを必要とするアプリケーションがある場合、そのアプリケーションは起動できないか、正しく機能しません。

    NIS (ユーザ管理)

    SUSE Linux Enterprise Serverシステムがユーザデータを提供するために故障したNISサーバを使用している場合、ユーザはマシンにログインできません。

    LDAP (ユーザ管理)

    SUSE Linux Enterprise Serverシステムがユーザデータを提供するために故障したLDAPサーバを使用している場合、ユーザはマシンにログインできません。

    Kerberos (認証)

    認証が機能せず、すべてのマシンへのログインが失敗します。

    CUPS (ネットワーク印刷)

    ユーザが印刷できません。

  4. ネットワークサーバが起動しているか、ネットワーク上で接続を確立できる設定になっているか、を確認します。

    重要
    重要: 制限

    次で説明するデバッグの手順は、内部ルーティングを必要としない、簡単なネットワークサーバ/クライアント設定にのみ適用されます。サーバとクライアントの両方が、追加でルーティングする必要のない同じサブネットのメンバーであることが前提です。

    1. ping IP_ADDRESS/HOSTNAME (サーバのホスト名またはIPアドレスで置き換えます)を使用して、各サーバが起動中で、ネットワークに反応するかどうか確認します。このコマンドが成功する場合は、目的のホストは起動しており、ネットワークのネームサービスは正しく設定されていることがわかります。

      pingが「destination host unreachable」というメッセージで失敗する場合、お使いのシステムまたは宛先のサーバが正しく設定されていないか、ダウンしています。その場合、他のコンピュータからping IP addressまたはYOUR_HOSTNAMEを実行して、お使いのシステムに到達可能か確認してください。他のマシンからお使いのコンピュータに接続可能な場合には、宛先のサーバが動作していないか、正しく設定されていません。

      pingが「unknown host」というメッセージで失敗する場合、ネームサービスが正しく設定されていないか、使用したホスト名が正しくありません。この問題を詳細に調べるには、ステップ 4.bを参照してください。それでもpingが失敗する場合は、ネットワークカードが正しく設定されていないか、ネットワークのハードウェアに障害があります。

    2. host HOSTNAMEを使用して、接続しようとしているサーバのホスト名が適切なIPアドレスに変換され、またその逆も問題ないか確認します。このコマンドによって、このホストのIPアドレスが返される場合、ネームサービスは起動中です。このhostコマンドが失敗する場合、お使いのホスト上の名前とアドレス解決に関係するすべてのネットワーク設定ファイルを確認します。

      /var/run/netconfig/resolv.conf

      このファイルは、ネームサーバおよび現在使用中のドメインを管理するために使用されます。これは/run/netconfig/resolv.confへのシンボリックリンクであり、通常、YaSTまたはDHCPによって自動的に調整されます。ただし、このファイルが以下のような構造およびネットワークアドレスを含んでいること、さらにドメイン名が正しいことを確認してください。 

      search FULLY_QUALIFIED_DOMAIN_NAME
nameserver IPADDRESS_OF_NAMESERVER

      このファイルには1つ以上のネームサーバのアドレスを含むことができますが、その中の少なくとも1つは、お使いのホストの名前解決が正しくできる必要があります。必要に応じて、YaSTネットワーク設定モジュール(［ホスト名/DNS］タブ)を使用してこのファイルを修正します。

      ネットワーク接続をDHCPで処理している場合は、DHCPでホスト名とネームサービスの情報を変更できるようにします。このためには、YaSTネットワーク設定モジュール(［ホスト名/DNS］タブ)で、DHCPでホスト名を設定 (すべてのインタフェースに対してグローバルに設定することも、インタフェースごとに設定することもできます)、およびUpdate Name Servers and Search List via DHCP (DHCPでネームサーバと検索リストを更新)を選択します。

      /etc/nsswitch.conf

      このファイルは、Linuxがネームサービス情報を探す場所を示します。このようになります。 

       ...
hosts: files dns
networks: files dns
...

      dnsエントリは必須です。これにより、Linuxは外部のネームサーバを使用するようになります。通常、これらのエントリはYaSTにより自動的に管理されますが、慎重にチェックする必要があります。

      ホスト上で、すべての関連エントリが正しい場合は、システム管理者に依頼して、正しいゾーン情報に関するDNSサーバの設定を確認してもらいます。DNSの詳細については、第39章 「ドメインネームシステム」を参照してください。お使いのホストのDNS設定およびDNSサーバが正しいことが確認できた場合、ネットワークおよびネットワークデバイス設定の確認に進みます。

    3. お使いのシステムがネットワークサーバに接続できない状況で、ネームサービスの問題を障害原因の可能性リストから除外した場合は、ネットワークカードの設定を確認します。

      ip addr show NETWORK_DEVICEコマンドを使用して、このデバイスが適切に設定されているか確認します。inet addressがネットマスク(/MASK)を使用して正しく設定されていることを確認します。IPアドレス内に間違いがある場合、またはネットワークマスク内で不明のビットがある場合は、ネットワーク設定が使用不可能になります。必要であれば、サーバ上でもこの確認をしてください。

    4. ネームサービスおよびネットワークハードウェアが正しく設定され起動している場合でも、特定の外部のネットワーク接続がタイムアウトするのに時間がかかったり、完全に失敗する場合は、traceroute FULLY_QUALIFIED_DOMAIN_NAME (rootユーザで実行)コマンドを使用して、リクエストがネットワーク上でどのルートを使用するか追跡します。このコマンドは、お使いのコンピュータのリクエストが宛先に到達するまでに経由するゲートウェイ(ホップ)をリストします。各ホップの応答時間およびこのホップに到達可能かどうかをリストします。tracerouteおよびpingコマンドを組み合わせて原因を追究し、管理者に知らせてください。

ネットワーク障害の原因を突き止めたら、自身でそれを解決するか(自分のコンピュータ上に問題がある場合)、お使いのネットワークのシステム管理者に原因について報告し、サービスを再設定するか、必要なシステムを修理してもらってください。

48.4.1 NetworkManagerの問題

 

ネットワーク接続に問題がある場合は、手順48.2「ネットワークの問題を識別する方法」の説明に従って原因を絞り込んでください。NetworkManagerが疑わしい場合は、次の手順に従って、NetworkManagerに障害が発生した原因に関するヒントとなるログを取得してください。

  1. シェルを開いて、rootとしてログインします。

  2. NetworkManagerを再起動します。 

    > sudo systemctl restart NetworkManager

  3. 一般ユーザとしてhttps://www.opensuse.orgなどのWebページを開いて、正常に接続できているかどうかを確認します。

  4. /var/log/NetworkManagerにある、NetworkManagerの状態に関する情報を収集します。

NetworkManagerについての詳細は、第31章 「NetworkManagerの使用」を参照してください。

48.5 データの問題

 

データの問題とは、コンピュータが正常に起動するかしないかに関係なく、システム上でデータが壊れており、システムの修復が必要な場合を言います。このような状況では、システムに障害が発生する前の状態にシステムを復元するために、重要なデータをバックアップする必要があります。

48.5.1 パーティションイメージの管理

 

パーティション全体、さらにはハードディスク全体からバックアップを実行することが必要になる場合があります。Linuxには、ディスクの正確なコピーを作成できるddツールが付属しています。gzipと組み合わせることで、領域の節約になります。

手順 48.3: ハードディスクのバックアップと復元
 

  1. rootユーザとしてシェルを起動します。

  2. ソースデバイスを選択します。これは、/dev/sdaなどが一般的です(SOURCEというラベルが付きます)。

  3. イメージを保存する場所を決めます(BACKUP_PATHというラベルが付きます)。これは、ソースデバイスとは異なる場所にする必要があります。つまり、/dev/sdaからバックアップを作成する場合、イメージファイルは/dev/sdaに保存しないでください。

  4. コマンドを実行して圧縮イメージファイルを作成します。 

    # dd if=/dev/SOURCE | gzip > /BACKUP_PATH/image.gz

  5. 次のコマンドによりハードディスクを復元します。 

    # gzip -dc /BACKUP_PATH/image.gz | dd of=/dev/SOURCE

パーティションをバックアップするだけでよい場合は、SOURCEプレースホルダを各パーティションに置き換えます。この場合、イメージファイルを同じハードディスクにおくことができます。ただし、パーティションは異なります。

48.5.2 レスキューシステムの使用

 

システムが起動し正常に稼動するのに失敗する理由はいくつか考えられます。最も一般的な理由としては、システムクラッシュによるファイルシステムの破損や、ブートローダ設定の破損があります。

このような状況の解決を支援するため、SUSE Linux Enterprise Serverには、ブート可能なレスキューシステムが含まれています。レスキューシステムは、RAMディスクにロードして、ルートファイルシステムとしてマウントできる小さなLinuxシステムで、これを利用して外部からLinuxパーティションにアクセスすることができます。レスキューシステムを使用して、システムの重要な部分を復元したり、適切な変更を行ったりできます。

  • 任意の種類の設定ファイルを操作できます。

  • ファイルシステムの欠陥をチェックして、自動修復プロセスを開始することができます。

  • インストールされているシステムを、「他のルート」環境内からアクセスすることができます。

  • ブートローダの設定を確認、変更、および再インストールできます。

  • 正常にインストールされていないデバイスドライバや使用不能なカーネルを修復できます。

  • partedコマンドを使って、パーティションサイズを変更できます。このツールの詳細については、GNU PartedのWebサイト(https://www.gnu.org/software/parted/parted.html)を参照してください。

レスキューシステムは、さまざまなソースや場所からロードすることができます。一番簡単な方法は、オリジナルのインストールメディアからレスキューシステムをブートすることです。

注記
注記: IBM Z: レスキューシステムの起動

IBM Zでは、レスキュー目的でインストールシステムを使用することができます。レスキューシステムを起動するには、48.6項 「IBM Z: initrdのレスキューシステムとしての使用」の指示に従ってください。

  1. インストールメディアをDVDドライブに挿入します。

  2. システムを再起動します。

  3. ブート画面で、F4を押し、DVD-ROMを選択します。次に、メインメニューからレスキューシステムを選択します。

  4. Rescue:プロンプトで「root」と入力します。パスワードは必要ありません。

ハードウェア設定にDVDドライブが含まれていない場合は、ネットワークソースからレスキューシステムをブートできます。次の例は、リモートブートの場合のシナリオです。DVDなど、他のブートメディアを使用する場合は、infoファイルを適宜変更し、通常のインストールと同様にブートします。

  1. PXEブートセットアップの設定を入力し、install=PROTOCOL://INSTSOURCEとrescue=1の行を追加します。修復システムを起動する必要がある場合は、代わりにrepair=1を使用します。通常のインストールと同様に、PROTOCOLはサポートする任意のネットワークプロトコル(NFS、HTTP、FTPなど)を表しています。また、INSTSOURCEは、ネットワークインストールソースへのパスを表します。

  2. に説明したように、「Wake on LAN」を使用してシステムをブートします。18.5項 「Wake-on-LANを利用したリモート起動」

  3. Rescue:プロンプトで「root」と入力します。パスワードは必要ありません。

レスキューシステムが起動したら、Alt–F1～Alt–F6キーを使って、仮想コンソールを使用することができます。

シェルおよび他の便利なユーティリティ(マウントプログラムなど)は、/binディレクトリにあります。/sbinディレクトリには、ファイルシステムを確認して修復するための重要なファイルおよびネットワークユーティリティが入っています。このディレクトリには、最も重要なバイナリも入っています。たとえばシステム保守用にはfdisk、mkfs、mkswap、mount、およびshutdownがあり、ネットワーク保守用にはipおよびssがあります。/usr/binディレクトリには、vi editor、find、less、およびSSHがあります。

システムメッセージを表示するには、dmesgコマンドを使用するか、またはjournalctlを使用してシステムログを参照してください。

48.5.2.1 環境設定ファイルの確認と修正

 

レスキューシステムを使った環境設定情報の修正例として、環境設定ファイルが壊れたためシステムが正常にブートできなくなった場合を考えてみましょう。このような場合は、レスキューシステムを使って設定ファイルを修復します。

環境設定ファイルを修正するには、以下の手順に従ってください。

  1. 前述のいずれかの方法を使って、レスキューシステムを起動します。

  2. /dev/sda6下にあるルートファイルシステムをレスキューシステムにマウントするには、以下のコマンドを使用します。 

    > sudo mount /dev/sda6 /mnt

    システム中のすべてのディレクトリが、/mnt下に配置されます。

  3. マウントしたルートファイルシステムのディレクトリに移動します。 

    > sudo cd /mnt

  4. 問題の発生している設定ファイルを、viエディタで開きます。次に、設定内容を修正して、ファイルを保存します。

  5. レスキューシステムから、ルートファイルシステムをアンマウントします。 

    > sudo umount /mnt

  6. マシンを再起動します。

48.5.2.2 ファイルシステムの修復と確認

 

一般的に、稼動システムではファイルシステムを修復できません。重大な問題が見つかった場合、ルートファイルシステムをブートできなくなることさえあります。この場合、システムブートは「カーネルパニック」で終了します。この場合、外部からシステムを修復するしか方法はありません。このシステムには、ext2、ext3、ext4、msdos、vfatなど、複数のファイルシステムタイプを確認し、修復するfsckユーティリティが含まれています。-tオプションを使用して、確認するファイルシステムを指定します。

次のコマンドは、/etc/fstab仕様にあるすべてのext4ファイルシステムを確認します。 

> sudo fsck -t ext4 -A
ヒント
ヒント

Btrfsの場合は、btrfsprogsパッケージにあるbtrfs checkコマンドを使用できます。

次の場所にあるBtrfsファイルシステムに関するトピックを参照してください。

48.5.2.3 インストール済みシステムへのアクセス

 

レスキューシステムからインストール済みのシステムにアクセスする必要がある場合は、それをchange root(ルート変更)環境で行う必要があります。これは、たとえば、ブートローダの設定を変更したり、ハードウェア設定ユーティリティを実行するために行います。

インストール済みシステムに基づいたchange root(ルート変更)環境を設定するには、以下の手順に従ってください。

  1. ヒント
    ヒント: LVMボリュームグループのインポート

    LVMセットアップを使用している場合は(詳細については、パートII「論理ボリューム(LVM)」を参照)、既存のボリュームグループをすべてインポートし、デバイスを検索してマウントできます。 

    rootvgimport -a

    lsblkを実行して、ルートパーティションに対応するノードを確認します。ここの例では/dev/sda2です。 

    > lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda           8:0    0 149,1G  0 disk
├─sda1        8:1    0     2G  0 part  [SWAP]
├─sda2        8:2    0    20G  0 part  /
└─sda3        8:3    0   127G  0 part
  └─cr_home 254:0    0   127G  0 crypt /home

  2. インストール済みシステムからルートパーティションをマウントします。 

    > sudo mount /dev/sda2 /mnt

  3. /proc、/dev、および/sysパーティションをマウントします。 

    > sudo mount -t proc none /mnt/proc
> sudo mount --rbind /dev /mnt/dev
> sudo mount --rbind /sys /mnt/sys

  4. これで、bashシェルを維持したまま、新規の環境に「ルートを変更」できます。 

    > chroot /mnt /bin/bash

  5. 最後に、インストール済みシステムから、残りのパーティションをマウントします。 

    > mount -a

  6. これで、インストール済みシステムにアクセスできるようになります。システムを再起動する前に、umount -aを使ってパーティションをアンマウントし、exitコマンドを実行して「change root」 (ルート変更)環境を終了してください。

警告
警告: 制限

インストール済みシステムのファイルやアプリケーションにフルアクセスできますが、いくつかの制限事項もあります。実行中のカーネルは、レスキューシステムでブートされたカーネルであり、ルート変更環境でブートされたカーネルではありません。このカーネルは、必要最低限のハードウェアしかサポートしておらず、カーネルのバージョンが同一でない限り、インストール済みシステムからカーネルモジュールを追加することはできません。常に、現在実行中の(レスキュー)カーネルのバージョンをuname -rでチェックし、次に、一致するサブディレクトリがchange root環境の/lib/modulesディレクトリに存在するかどうか調べてください。存在する場合は、インストールされたモジュールを使用できます。そうでない場合は、フラッシュディスクなど、他のメディアにある正しいバージョンを提供する必要があります。多くの場合、レスキューカーネルのバージョンは、インストールされているバージョンと異なります。その場合は、たとえば、サウンドカードなどに簡単にアクセスすることはできません。また、GUIも利用できません。

また、Alt–F1からAlt–F6>を使ってコンソールを切り替えると、「change root」(ルート変更)環境は終了することに注意してください。

48.5.2.4 ブートローダの変更と再インストール

 

場合によっては、ブートローダが壊れてしまい、システムをブートできなくなることもあります。たとえば、ブートローダが正常に機能しないと、起動ルーチンは物理ドライブとそのLinuxファイルシステム中の場所とを関連付けられず、正常な処理を行うことができません。

ブートローダの設定を確認し、ブートローダを再インストールするには、次の手順に従います。

  1. 48.5.2.3項 「インストール済みシステムへのアクセス」の説明に従って、インストール済みシステムにアクセスするために必要な作業を行います。

  2. GRUB 2ブートローダがシステムにインストールされていることを確認します。インストールされていない場合、grub2パッケージをインストールして実行します。 

    > sudo grub2-install /dev/sda

  3. 次のファイルが第18章 「ブートローダGRUB 2」に示されているGRUB 2の設定ルールに従って正しく設定されているかどうかチェックし、必要に応じて修正します。

    • /etc/default/grub

    • /boot/grub2/device.map

    • /boot/grub2/grub.cfg(このファイルが生成されます。編集しないでください。)

    • /etc/sysconfig/bootloader

  4. 次のコマンドシーケンスを使って、ブートローダを再インストールします。 

    > sudo grub2-mkconfig -o /boot/grub2/grub.cfg

  5. パーティションをアンマウントして、「change root」 (ルート変更)環境からログアウトします。次に、システムを再起動します。 

    > umount -a
exit
reboot

48.5.2.5 カーネルインストールの修復

 

カーネルアップデートによって、システムの操作に影響する可能性のある新しいバグが導入される場合があります。たとえば、一部のシステムハードウェアのドライバに障害が発生し、そのハードウェアのアクセスや使用ができなくなることがあります。その場合は、機能した最後のカーネルに戻すか(システムで使用可能な場合)、インストールメディアから元のカーネルをインストールします。

ヒント
ヒント: 更新後も最後のカーネルを保持する方法

正常でないカーネルアップデート後にブートできなくなることを防ぐには、カーネルの複数バージョン機能を使用して、更新後にどのカーネルを保持するかlibzyppに指示します。

たとえば、最後の2つのカーネルと現在実行中のカーネルを常に保持するには、次のコードを、 

multiversion.kernels = latest,latest-1,running

この内容は、/etc/zypp/zypp.confファイルに保存されます。詳細については、第27章 「複数バージョンのカーネルのインストール」を参照してください。

また、SUSE Linux Enterprise Serverでサポートされていないデバイスのドライバが破損し、その再インストールまたはアップデートが必要な場合があります。たとえば、ハードウェアベンダが、ハードウェアRAIDコントローラなどの特定のデバイスを使用している場合は、オペレーティングシステムによって認識されるバイナリドライバが必要です。ベンダは、通常、要求されたドライバの修正または更新バージョンを含むドライバアップデートディスク(DUD)をリリースします。

両方のケースで、レスキューモードでインストールされているシステムにアクセスし、カーネル関係の問題を修正する必要があります。さもないと、システムが正しくブートしないことがあります。

  1. SUSE Linux Enterprise Serverメディアからのブート

  2. 正常でないカーネルアップデート後に修復を行っている場合、次のステップはスキップしてください。DUD(ドライバアップデートディスク)を使用する必要がある場合は、F6を押して、ブートメニューの表示後にドライバアップデートをロードし、 ドライバアップデートへのパスまたはURLを選択して、はいをクリックして確認します。

  3. ブートメニューからレスキューシステムを選択し、Enterを押します。DUDの使用を選択した場合は、ドライバアップデートの保存先を指定するように要求されます。

  4. Rescue:プロンプトで「root」と入力します。パスワードは必要ありません。

  5. ターゲットシステムを手動でマウントし、新しい環境に「change root」(ルート変更)します。詳細については、48.5.2.3項 「インストール済みシステムへのアクセス」を参照してください。

  6. DUDを使用する場合は、障害のあるデバイスドライバパッケージのインストール/再インストール/アップデートを行います。インストールされたカーネルバージョンがインストールするドライバのバージョンと正確に一致することを常に確認してください。

    障害のあるカーネルアップデートのインストールを修復する場合は、次の手順で、インストールメディアから元のカーネルをインストールできます。

    1. hwinfo --cdromでDVDデバイスを識別し、mount /dev/sr0 /mntでマウントします。

    2. DVD上のカーネルファイルが保存されているディレクトリにナビゲートします(たとえば、cd /mnt/suse/x86_64/)。

    3. 必要なパッケージkernel-*、kernel-*-base、およびkernel-*-extraのカスタマイズしたバージョンを、rpm -iコマンドでインストールします。

  7. 設定ファイルを更新し、必要に応じてブートローダを再初期化します。詳細については、48.5.2.4項 「ブートローダの変更と再インストール」を参照してください。

  8. システムドライブからブート可能なメディアをすべて除去し、再起動します。

48.6 IBM Z: initrdのレスキューシステムとしての使用

 

SUSE® Linux Enterprise Server for IBM Zのカーネルをアップグレードまたは変更した場合、何らかの原因でシステムが不整合な状態で再起動されると、インストールされているシステムのIPL標準処理が失敗する可能性があります。このような場合は、インストールシステムをレスキューのために使用できます。

SUSE Linux Enterprise Server for IBM ZのインストールシステムをIPL(再起動)します(5.3項 「インストールの準備」を参照)。Start Installation (インストールの開始)を選択し、必要なパラメータをすべて入力します。インストールシステムがロードされて、インストールの制御にどの表示タイプを使用するか尋ねられたら、［SSH］を選択します。これで、パスワードを使用せずに、rootとしてSSHを使用してシステムにログインできるようになります。

この状態では、設定されているディスクはありません。作業を続行する前に、ディスクを設定する必要があります。

手順 48.4: DASDの設定
 

  1. DASDを設定するには、以下のコマンドを使用します。 

    dasd_configure 0.0.0150 1 0

    ここで、「0.0.0150」は、DASDが接続されているチャネルを表します。1は、ディスクをアクティブにすることを表しています(ここに0を指定すると、ディスクが無効になる)。0は、ディスクに「DIAGモード」でアクセスしないことを表します(ここに1を指定すると、ディスクへのDAIGアクセスが有効になります)。

  2. DASDがオンラインになり(cat /proc/partitionsで確認)、コマンドを使用できるようになります。

手順 48.5: zFCPディスクの設定
 

  1. zFCPディスクを設定するには、まずzFCPアダプタを設定する必要があります。そのためには次のコマンドを使用します。 

    zfcp_host_configure 0.0.4000 1

    0.0.4000はアダプタが接続されているチャネルを、1 (ここに0を指定するとアダプタが無効になる)はアクティブにすることを示します。

  2. アダプタをアクティブにしたら、ディスクを設定することができます。そのためには次のコマンドを使用します。 

    zfcp_disk_configure 0.0.4000 1234567887654321 8765432100000000  1

    0.0.4000は前に使われていたチャネルIDを、1234567887654321はWWPN (World wide Port Number)を、そして8765432100000000はLUN(論理ユニット番号)を表しています。1(ここに0を指定するとディスクが無効になる)は、ディスクをアクティブにすることを表しています。

  3. zFCPディスクがオンラインになり(cat /proc/partitionsで確認)、コマンドを使用できるようになります。

これで、レスキューシステムが完全に設定され、インストールされたシステムの修復を開始できます。最も一般的な問題の修復方法については、48.5.2項 「レスキューシステムの使用」を参照してください。

48.7 IBM Z: カーネルの更新後、システムは以前のカーネルで起動する

 

IBM Zシステムに新しいカーネルバージョンをインストールしても、stage 1のziplローダは自動的に更新されません。これは、再起動後にシステムが古いカーネルで起動することを意味します。また、セキュアブートが有効になっている場合、古いカーネルがshimの更新などによって同時に撤回された署名キーで署名されていると、ブートは失敗します。

この問題を解決するには、ziplを更新して新しいカーネルバージョンを認識させます。これを行うには、新しいカーネルをインストールした後で次のコマンドを実行します。 

grub2-emu --kexec

grub2ブートメニューで、リブートする新しいカーネルを選択します。変更を有効にするには、上記のコマンドを再度実行します。最後に、次のコマンドを実行して、ブートローダを再インストールします。 

update-bootloader --reinit