ハードウエアが正しく動作している場合、ブートローダが壊れていて Linux が起動できなくなっていることが考えられます。この場合は、ブートローダの修復作業が必要となります。これを行うには、 21.5.2項 「レスキューシステムの使用」 の手順に従ってレスキューシステムを起動したあと、 21.5.2.4項 「ブートローダの修正と再インストール」 の手順に従ってブートローダを修復してください。

また、下記の手順に従ってレスキューシステムを利用し、ブートローダを修復する方法もあります。まずはインストールメディアを利用してマシンを起動してください。起動画面では 詳細 › Linux システムの起動 を選択します。あとはインストール済みのシステムが含まれるディスクを選択して、既定のカーネルオプションで起動を行ってください。

図 21.1: ディスクの選択 #

システムが起動したら、 YaST を起動して システム › ブートローダ を選択します。 MBR に汎用ブートコードを書き込む が選択されていることを確認して、 OK を押します。これで壊れているブートローダを上書きするか、失われたブートローダをインストールし直すことができます。

これでもマシンが起動しない場合は、 BIOS 関連の問題であることが考えられます:

この問題は、カーネルのアップグレード後などに発生することがあり、 カーネルパニック としても知られている問題で発生します。この場合、システムコンソール内に、直近の処理で発生したエラーメッセージが表示されるようになります。そのため、ソフトウエアの更新に従って再起動を行った場合は、問題なく動作していた古いバージョンのカーネルと関連のファイルに戻すことで、問題を解決することができます。カーネルを古いバージョンに戻すには、 GRUB 2 のブートローダの画面を利用して下記の手順に従って作業を行います:

これでも問題が解決しない場合は、インストールメディアを利用してコンピュータを起動してください。コンピュータが起動したら、 ステップ 3 の手順に従って作業を行ってください。

コンピュータは問題なく起動するものの、グラフィカルなログインマネージャが起動しない場合は、まず既定の systemd ターゲットの問題なのか、 X Window System の設定の問題なのかを切り分ける必要があります。まず現在の systemd ターゲットを確認するには、 sudo systemctl get-default を実行してください。表示された値が graphical.target 以外の ものであった場合は、 sudo systemctl isolate graphical.target を実行してください。これでグラフィカルな画面が表示されるようになったら、ログインを行って YaST › システム › サービスマネージャ を選択し、 既定のシステムターゲット で グラフィカルインターフェイス を選択してください。これでシステム起動時にグラフィカルなログインマネージャが動作するようになります。

上記の手順でグラフィカルインターフェイスのターゲットに切り替えても、グラフィカルなログインマネージャが表示されない場合は、デスクトップ環境もしくは X Window System のソフトウエアの設定が間違っているか、もしくは壊れてしまっていることが考えられます。まずは /var/log/Xorg.*.log にあるログファイル内の詳細なメッセージを確認して、 X サーバの起動ができているかどうかを確認してください。デスクトップの起動が失敗している場合は、 journalctl (詳しい手順は 第11章 「journalctl : systemd ジャーナルへの問い合わせコマンド」 をお読みください) でシステムジャーナルを調査し、エラーメッセージが記録されていないかどうかを確認してください。なお、ジャーナル内に X サーバの設定の問題を表すヒントがあった場合は、まずそれらを修正してみてください。 X サーバの設定を修正してもデスクトップが起動しない場合は、デスクトップ環境をインストールし直してください。

btrfs のルートパーティションが壊れてしまった場合、下記の方法で解決するかどうか試してみてください:

ルートパーティションが壊れてしまった場合は、起動画面で forcefsck オプションを指定してみてください。これにより、 fsck に対して -f (force; 強制) オプションが追加されるようになります。

起動の時点でスワップデバイスが利用できず、システムが有効化できない場合には、起動が失敗してしまいます。このような場合は、カーネルのコマンドラインに下記の内容を追加して、全てのスワップデバイスを無効化してみてください:

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

特定のスワップデバイスだけを無効化するには、下記のように指定します:

systemd.mask=dev-sda1.swap

再起動時に GRUB 2 が正しく動作しない場合は、 BIOS 設定で Fast Boot (高速起動) 機能を無効化してください。

この問題は、お使いのシステムがネットワーク認証やディレクトリサービスの認証を使用するように設定されていて、何らかの理由で設定されているサーバから応答を得られない場合に発生します。これに該当する場合は、 root だけがローカルユーザとして設定されていることが多く、このユーザだけがログインできることになります。システムは問題なく動作しているものの、ログインができない場合は、下記のような原因が考えられます:

ネットワーク以外の原因である場合、 root でログインして設定を修正して解決することになります。なお、 root でもログインができないような場合は、 手順12.3「レスキューモードへの突入」 で示されている手順に従って、レスキューモードで起動して修復する必要があります。

この問題には数多くの原因が考えられることから、ユーザが直面する最もよくある問題です。ローカルでユーザを作成しているかネットワーク側で認証を行うよう設定しているかによって異なりますが、ログインの問題は様々な理由で発生します。

ローカルでのユーザ管理の場合は、下記の原因が考えられます:

ローカルのログイン問題について原因を調べるには、下記の手順で行います:

ネットワーク認証を設定している環境で、特定のユーザがログインできない場合は、一般的には下記のような理由が考えられます:

ネットワーク認証でログイン失敗の原因を探るには、下記の手順で行います:

ラップトップマシンの場合、ホームディレクトリを暗号化しておくことが推奨されます。ホームディレクトリを暗号化していてログインが失敗する場合、パーティションの暗号解除ができていない可能性が考えられます。

暗号化されたパーティションが存在する場合、起動時にパスフレーズを入力して暗号を解除します。パスワードの入力を行わないと、起動処理はそのまま続行されますが、パーティションの暗号化は解除されなくなります。

パーティションの暗号化を解除するには、下記の手順で行います:

GNOME デスクトップを利用している際に問題が発生した場合は、グラフィカルなデスクトップ環境の誤動作を調べるための方法がいくつか用意されています。具体的には下記の手順を実施することで、最も安全に GNOME デスクトップを修復することができます。

ネットワークの接続に関して問題がある場合は、まず 手順21.2「ネットワーク関連の問題の識別方法」 の手順で原因を調査してください。 NetworkManager が原因であることが判明した場合は、下記の手順に従って、なぜ NetworkManager がうまく動作していないのかを示すログを採取してください:

NetworkManager について、詳しくは 第28章 「NetworkManager の使用」 をお読みください。

パーティション全体やディスク全体のバックアップを採取することで、様々なトラブルを事前に回避することができるようになります。 Linux には dd というツールが用意されていて、このツールを利用すればディスク全体の正確なコピーを作成することができます。さらに gzip を併用すれば、データを圧縮することもできます。

パーティション単体でバックアップを採取したい場合は、 バックアップ元 の部分をパーティションのデバイス名にしてください。この場合は、 バックアップ先パス の指定で異なるディスクだけでなく、同じディスクの異なるパーティションを指定することができるようになります。

様々な理由から、システムは起動しなくなってしまったり、正しく動作しなくなってしまったりすることがあります。たとえばシステムがクラッシュしてファイルシステムが壊れてしまったり、設定ファイルやブートローダが壊れてしまったり、などの問題が発生することがあります。

このような問題を解決するための支援として、 openSUSE Leap にはレスキューシステムと呼ばれる仕組みが用意されています。レスキューシステムは小さな Linux システムで、 RAM ディスク内に読み込まれてルートファイルシステムとなることができるものであるため、 Linux のパーティションをインストール済みの Linux の外側からアクセスすることができるようになります。レスキューシステムを使用すれば、お使いのシステム内の主要な要素を復元し、修復することができるようになります。

レスキューシステムは様々なメディアや場所から読み込むことができます。最もシンプルな方法は、インストールに使用したメディアから起動することです。

レスキューシステムに入ったあとは、複数の仮想コンソールを使用できるようになります。それぞれ Alt–F1 から Alt–F6 までを押してアクセスしてください。

シェルや mount プログラムなどのユーティリティ類が、 /bin ディレクトリ内に配置されています。また、 /sbin ディレクトリには、重要なファイルユーティリティやネットワークユーティリティが配置されています。ファイルユーティリティには、たとえばファイルシステムの確認や修復などのコマンドが含まれます。また、このディレクトリにはシステムをメンテナンスするための様々なプログラムも用意されています。具体的には、 fdisk , mkfs , mkswap , mount , and shutdown , ip , ss などがあります。さらに、 /usr/bin ディレクトリには、 vi エディタや find, less, SSH などの各プログラムも用意されています。

システムからのメッセージを読みたい場合は dmesg コマンドを、システムログを読みたい場合は journalctl をそれぞれお使いください。

21.5.2.2 ファイルシステムの修復とチェック #Edit source

一般的には、システムが動作している場合はファイルシステムの修復を行うことができません。また重大な問題が発生した場合は、ルートファイルシステムのマウントを行うことができず、起動時に 「カーネルパニック」 の状態で停止してしまうことがあります。この場合は、システムの外部からファイルシステムを修復するしか手段がなくなってしまいます。レスキューシステムには ext2 , ext3 , ext4 , msdos , vfat の各ファイルシステムに対応した、チェックと修復のためのプログラムが含まれていますので、 -t オプションを指定して、チェックしたいファイルシステムを指定してください。

たとえば下記のようなコマンドを実行すると、 /etc/fstab ファイル内に指定された全ての ext4 ファイルシステムをチェックします:

> sudo fsck -t ext4 -A

ヒント

btrfs の場合は、 btrfsprogs パッケージに含まれる btrfs check コマンドを使用してください。

btrfs ファイルシステムに関する詳細は、下記をお読みください:

• ストレージ管理ガイド内の https://documentation.suse.com/sles/html/SLES-all/cha-filesystems.html#sec-filesystems-major-btrfs および https://documentation.suse.com/sles/html/SLES-all/cha-resize-fs.html#sec-resize-fs-btrfs の各章にも説明があります。

• btrfs ファイルシステムのエラー修復に関しては、 https://www.suse.com/support/kb/doc/?id=000018769 (英語) に記事が書かれています。

• その他の様々な btrfs ファイルシステムに関する記事は、 https://www.suse.com/support/kb/doc/?id=000018779 (英語) にも情報があります。

• btrfs check コマンドで利用できる全てのオプションについては、 man 8 btrfs-check のマニュアルページをお読みください。

21.5.2.3 インストール済みシステムへのアクセス #Edit source

レスキューシステムからインストール済みのシステムにアクセスする必要がある場合は、 change root という仕組みを利用します。たとえばブートローダの設定を修正する場合や、ハードウエアの設定ユーティリティを実行するような場合がそれにあたります。

インストール済みのシステムに対して、 change root 環境を構築するには、下記の手順で行います:

1. 

   ヒント: LVM ボリュームグループの取り込み

   LVM を使用している場合 (詳しくは 5.2項 「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. これで 「change root」 を行うだけの環境が揃いました。実際に 「change root」 を行い、その中で bash を起動します。

   > chroot /mnt /bin/bash

5. 最後に、インストール済みのシステムに設定されている残りのパーティションをマウントします:

   > mount -a

6. これでインストール済みのシステムにアクセスできるようになりました。なお、作業が終わったら、再起動を行う前に umount -a コマンドでパーティションのマウントを解除し、 exit で 「change root」 を抜けてください。

警告: 制限事項について

change root 環境では、インストール済みのシステム内にある全てのファイルやアプリケーションにアクセスすることができますが、いくつかの制限もあります。レスキューシステムでは、カーネルはレスキューシステムのバージョンになり、 change root 環境内にインストールされているカーネルにはなりません。また、ハードウエアへの対応も最小限に限られ、レスキューシステムとカーネルバージョンが全く同じである場合を除いて、カーネルモジュールを追加することもできません。現在実行中のカーネルのバージョンは、 uname -r コマンドで確認できるほか、インストール済みのカーネルのバージョンは、 change root 環境下の /lib/modules ディレクトリ以下のサブディレクトリで判断することができます。全く同じバージョンである場合は、カーネルモジュールを読み込むことができますが、そうでない場合は USB メモリなどからカーネルモジュールを読み込まなければならなくなります。一般的にはレスキューシステムのカーネルとインストール済みのカーネルのバージョンは異なりますので、サウンドカードへのアクセスなども行うことができません。また、グラフィカルユーザインターフェイスの起動もできません。

また、 Alt–F1 から Alt–F6 までのキーを押してコンソールを切り替えても、 「change root」 からは抜けてしまうことにも注意してください。

21.5.2.5 カーネルのインストールの修正 #Edit source

カーネルの更新内容によっては、お使いのシステムに影響があるような新しいバグを起こしてしまうことがあります。たとえば、お使いのハードウエアのデバイスドライバに問題があって、必要なアクセスができなくなってしまう、などの問題が考えられます。この場合は、直前まで問題なく動作していた古いカーネルに戻す (ただしシステム内に残っていれば) か、インストールメディアから元のカーネルをインストールし直すことで、対応することができます。

ヒント: 更新後の最新カーネルの維持方法について

カーネルの更新失敗時に起動ができなくなってしまう問題を避けるため、カーネルのマルチバージョン機能を有効にし、更新後も古いカーネルを保存し続けるよう、 libzypp に設定しておくことをお勧めします。

たとえば最近の 2 つのカーネルと、現在動作中のカーネルをそれぞれ保持しておきたい場合は、 /etc/zypp/zypp.conf 内に下記のように設定します:

multiversion.kernels = latest,latest-1,running

詳しくは 第6章 「複数バージョンのカーネルのインストール」 をお読みください。

似たようなケースとして、 openSUSE Leap でサポートされていないデバイスに対して、うまく動作しないドライバを再インストールしたり、更新したりする必要に迫られる場合があります。たとえばハードウエアの製造元が、ハードウエア RAID コントローラなどの特殊なデバイスを使用していて、バイナリドライバが必要となる場合です。この場合、製造元は、ドライバ更新ディスク (DUD) を作成して、ドライバの修正版や更新版を提供することがあります。

いずれの場合であっても、まずはレスキューモードでインストール済みのシステムにアクセスして、カーネル関連の問題を修正しておかないと、システムの起動ができないままになってしまいます:

1. まずは openSUSE Leap のインストールメディアから起動します。

2. カーネルの更新で問題が発生している場合は、この手順は飛ばしてください。ドライバ更新ディスク (DUD) を使用する必要がある場合は、 F6 を押して起動メニューの表示後にドライバ更新を適用する指定をし、ドライバ更新のパスや URL を指定して はい で確認を行ってください。

3. 起動メニューで レスキューシステム を選択して Enter を押します。 DUD を選択している場合は、ドライバ更新の場所を尋ねられます。

4. Rescue: のプロンプトが表示されたら、 root と入力します。パスワードは不要です。

5. 修復するシステムを手作業でマウントし、その環境内に 「change root」 で入ります。詳しくは 21.5.2.3項 「インストール済みシステムへのアクセス」 をお読みください。

6. DUD を使用している場合は、デバイスドライバのパッケージをインストール／再インストール／更新します。ただし、インストールしようとしているドライバが、お使いのカーネルのバージョンと正確に一致していることを確認してください。

   もしもカーネルの更新時に問題が発生しているような場合は、インストールメディアにあるオリジナルのカーネルに入れ替えることもできます。この場合は、下記の手順を実施してください:

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

   2. DVD 内のカーネルファイルが保存されているディレクトリまで移動します。たとえば cd /mnt/suse/x86_64/ のように実行します。

   3. rpm -i コマンドを利用して、お使いのフレーバーに対応した kernel-* , kernel-*-base , kernel-*-extra の各パッケージをインストールします。

7. 必要に応じてブートローダの設定ファイルを更新し、ブートローダを再設定します。詳しくは 21.5.2.4項 「ブートローダの修正と再インストール」 をお読みください。

8. あとはシステムから起動メディアを取り出して、再起動します。