Linuxのリカバリ：カーネルの問題に関連するブート以外の問題の手動修正

カーネルのアップグレードなどカーネルの変更が最近適用されたLinux VMがあり、起動プロセス中のカーネルエラーのために適切に起動しなくなりました。

カーネルのメッセージはさまざまです。いくつかの例があります：

ルートデバイスが見つかりませんでした。
カーネルのタイムアウト、
ヌルポインタ、
カーネルパニックエラー。

ほとんどの場合、リカバリ手順は類似しているため、新しいカーネルをインストールするか、以前のバージョンに手動でロールバックする必要があります。

あなたが見ることができるエラーメッセージの例

A）ルートデバイスが見つかりません

dracut警告：ルートデバイスがありません "ブロック：/ dev / disk / by-uuid / 6d089360-3e14-401d-91d0-378f3fd09332"が見つかりました
dracut警告：ブートに失敗しました。この問題をデバッグするには、カーネルコマンドラインに "rdshell"を追加します。
dracut警告：シグナルが検出されました！
カーネルパニック - 同期していない：initを強制終了しようとしました！
Pid：1、通信：init汚れていない2.6.32-504.12.2.el6.x86_64＃1
コールトレース：
[<ffffffff8152933c>]？パニック+ 0xa7 / 0x16f
[<ffffffff8107a5f2>]？ do_exit + 0x862 / 0x870
[<ffffffff8118fa25>]？ fput + 0x25 / 0x30
[<ffffffff8107a658>]？ do_group_exit + 0x58 / 0xd0
[<ffffffff8107a6e7>]？ sys_exit_group + 0x17 / 0x20
[<ffffffff8100b072>]？ system_call_fastpath + 0x16 / 0x1b

B）カーネルタイムアウトエラーの例

情報：タスクスワッパー：1は120秒以上ブロックされました。
汚染されていない2.6.32-504.8.1.el6.x86_64＃1
"echo 0> / proc / sys / kernel / hung_task_timeout_secs"はこのメッセージを無効にします。
スワッパD 0000000000000000 0 1 0 0x00000000
ffff88010f64fde0 0000000000000046 ffff88010f64fd50 ffffffff81074f95
0000000000005c2f ffffffff8100bb8e ffff88010f64fe50 0000000000100000
0000000000000002 00000000fffb73e0 ffff88010f64dab8 ffff88010f64ffd8
コールトレース：
[<ffffffff81074f95>]？ __call_console_drivers + 0x75 / 0x90
[<ffffffff8100bb8e>]ですか？ apic_timer_interrupt + 0xe / 0x20
[<ffffffff81075d51>]ですか？ vprintk + 0x251 / 0x560
[<ffffffff8152a862>] schedule_timeout + 0x192 / 0x2e0
[<ffffffff810874f0>]？ process_timeout + 0x0 / 0x10
[<ffffffff8152a9ce>] schedule_timeout_uninterruptible + 0x1e / 0x20
[<ffffffff81089650>] msleep + 0x20 / 0x30
[<ffffffff81c2a571>] prepare_namespace + 0x30 / 0x1a9
[<ffffffff81c2992a>] kernel_init + 0x2e1 / 0x2f7
[<ffffffff8100c20a>] child_rip + 0xa / 0x20
[<ffffffff81c29649>]？ kernel_init + 0x0 / 0x2f7
[<ffffffff8100c200>]？ child_rip + 0x0 / 0x20

C）カーネルのヌルポイントエラーの例

Pid：242、通信：非同期/ 1汚染されていない2.6.32-504.12.2.el6.x86_64＃1
コールトレース：
[<ffffffff81177468>]？ kmem_cache_create + 0x538 / 0x5a0
[<ffffffff8152aede>]？ mutex_lock + 0x1e / 0x50
[<ffffffff81370424>]？ attribute_container_add_device + 0x104 / 0x150
[<ffffffffa009c1de>]？ storvsc_device_alloc + 0x4e / 0xa0 [hv_storvsc]
[<ffffffff8138a1dc>]？ scsi_alloc_sdev + 0x1fc / 0x280
[<ffffffff8138a739>]？ scsi_probe_and_add_lun + 0x4d9 / 0xe10
[<ffffffff8128e62d>]？ kobject_set_name_vargs + 0x6d / 0x70
[<ffffffff8152aede>]？ mutex_lock + 0x1e / 0x50
[<ffffffff81370424>]？ attribute_container_add_device + 0x104 / 0x150
[<ffffffff81367ae9>]？ get_device + 0x19 / 0x20
[<ffffffff8138b440>]？ scsi_alloc_target + 0x2d0 / 0x300
[<ffffffff8138b661>]？ __scsi_scan_target + 0x121 / 0x740
[<ffffffff8138bd07>]？ scsi_scan_channel + 0x87 / 0xb0
[<ffffffff8138bde0>]？ scsi_scan_host_selected + 0xb0 / 0x190
[<ffffffff8138bf51>]？ do_scsi_scan_host + 0x91 / 0xa0
[<ffffffff8138c13c>]？ do_scan_async + 0x1c / 0x150
[<ffffffff810a7086>]ですか？ async_thread + 0x116 / 0x2e0
[<ffffffff81064b90>]？ default_wake_function + 0x0 / 0x20
[<ffffffff810a6f70>]？ async_thread + 0x0 / 0x2e0
[<ffffffff8109e66e>]？ kthread + 0x9e / 0xc0
[<ffffffff8100c20a>]？ child_rip + 0xa / 0x20
[<ffffffff8109e5d0>]？ kthread + 0x0 / 0xc0
[<ffffffff8100c200>]？ child_rip + 0x0 / 0x20
BUG：0000000000000008でカーネルNULLポインターdereferenceを処理することができません。
IP：[<ffffffffa009c0a0>] storvsc_device_destroy + 0x20 / 0x50 [hv_storvsc]
PGD 0

D）カーネルパニックエラーの例

無効なオペコード：0000 [＃2] [11427.908676] - 終了トレース61a458bb863d7f0f] -
カーネルパニック - 同期していない：アイドルタスクを強制終了しようとしました！

これらの問題からの回復

どのような場合でも、影響を受けるLinux VMを削除し、そのOSDディスクを保持し、影響を受けたVMと同じバージョンを実行する新しいVMにマウントするか、少なくとも同じ配分にしてから、問題に応じて下記の2つの修理オプションがあります。

1）設定ファイルを編集してカーネルをロールバックし、以前の動作設定から起動するだけで、Linuxブートローダは通常、ブートに使用するカーネルを定義する複数のエントリを持ちます。新しいインストールされたカーネル

2）影響を与えるVM OSDiskを一時的な新しいVMに接続し、既知のツール（apt-get / yum / zypper）を実行してカーネルをインストール/再インストールすることで、CHROOTプロセスを実行します。これは、手動でファイルを編集する必要がないので、修復するのが最も簡単で通常は最も速い方法です。

たとえば、CentOS 6.6を実行しているLinux VMは2.6.32-504.16.2.el6.x86_64のカーネル・バージョンをロードしています。これは次のコマンドで確認できます。
uname -a

Linux vfldev 2.6.32-504.16.2.el6.x86_64＃1 SMP Wed Apr 22 06:48:29 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

ロードするカーネルバージョンを知っているブートローダ設定ファイル。CentOSの場合、ファイルは/boot/grub/grub.confで、新しいバージョンは/boot/grub2/grub.cfgです。

grub.confを見ると、現在ロードされているバージョンが青色で強調表示されている最初の4行で参照されていることがわかります。

1）タイトル>単にメニューに表示されるタイトル（クラウド環境には適用されません）
2）ルートディスク
3）ブート時にロードされるカーネルコマンドラインとそのパラメータ
4）ブートにロードされ、通常はカーネルにも一致するinitrdファイルのパス

4つのLinuxバージョンを参照するgrub.confの例：

タイトルCentOS（2.6.32-504.16.2.el6.x86_64）
ルート（hd0,0）
カーネル/boot/vmlinuz-2.6.32-504.16.2.el6.x86_64 roルート= UUID = 6d089360-3e14-401d-91d0-378f3fd09332 rd_NO_LUKS rd_NO_LVM LANG = en_US.UTF-8 rd_NO_MD SYSFONT = latarcyrheb-sun16 KEYBOARDTYPE = pc KEYTABLE = us rd_NO_DM numa = offコンソール= ttyS0 earlyprintk = ttyS0 rootdelay = 300 crashkernel = auto
initrd /boot/initramfs-2.6.32-504.16.2.el6.x86_64.img

タイトルCentOS（2.6.32-504.12.2.el6.x86_64）
ルート（hd0,0）
カーネル/boot/vmlinuz-2.6.32-504.12.2.el6.x86_64 roルート= UUID = 6d089360-3e14-401d-91d0-378f3fd09332 rd_NO_LUKS rd_NO_LVM LANG = en_US.UTF-8 rd_NO_MD SYSFONT = latarcyrheb-sun16 KEYBOARDTYPE = pc KEYTABLE = us rd_NO_DM numa = offコンソール= ttyS0 earlyprintk = ttyS0 rootdelay = 300 crashkernel = auto
initrd /boot/initramfs-2.6.32-504.12.2.el6.x86_64.img

タイトルCentOS（2.6.32-504.8.1.el6.x86_64）
ルート（hd0,0）
カーネル/boot/vmlinuz-2.6.32-504.8.1.el6.x86_64 roルート= UUID = 6d089360-3e14-401d-91d0-378f3fd09332 rd_NO_LUKS rd_NO_LVM LANG = en_US.UTF-8 rd_NO_MD SYSFONT = latarcyrheb-sun16 KEYBOARDTYPE = pc KEYTABLE = us rd_NO_DM numa = offコンソール= ttyS0 earlyprintk = ttyS0 rootdelay = 300 crashkernel = auto
initrd /boot/initramfs-2.6.32-504.8.1.el6.x86_64.img

タイトルCentOS（2.6.32-431.29.2.el6.x86_64）
ルート（hd0,0）
カーネル/boot/vmlinuz-2.6.32-431.29.2.el6.x86_64 roルート= UUID = 6d089360-3e14-401d-91d0-378f3fd09332 rd_NO_LUKS rd_NO_LVM LANG = en_US.UTF-8 rd_NO_MD SYSFONT = latarcyrheb-sun16 KEYBOARDTYPE = pc KEYTABLE = us rd_NO_DM numa = offコンソール= ttyS0 earlyprintk = ttyS0 rootdelay = 300
initrd /boot/initramfs-2.6.32-431.29.2.el6.x86_64.img

ブートローダ（grub.conf）を変更して強制的にLinux VMに別のカーネルをロードさせるには、手動による操作が必要です。その変更を行う手順を以下に示します。

注：回復プロセスの手順を実行する前に、アクセスできないVMからVHDのバックアップを作成することを強くお勧めします。http://storageexplorer.comで入手可能なMicrosoft Storage Explorerを使用してVHDのバックアップを作成できます。

A =元のVM（アクセスできないVM）
B =新しいVM（新しいリカバリVM）

Azure Portal経由でVM Aを停止する
Resource Manager VMでは、削除する前に現在のVM情報を保存することをお勧めします
- Azure CLI：azure vm show ResourceGroupName LinuxVmName> ORIGINAL_VM.txt
- Azure PowerShell：Get-AzureRmVM -ResourceGroupName $ rgName -Name $ vmName
VMを削除するが、「 接続されたディスクを保持する」を選択する
注：アタッチされたディスクを保持するオプションは、従来のデプロイメントでのみ使用できます。リソースマネージャでは、VMを削除するとデフォルトでOSDiskが常に保持されます。
リースがクリアされたら、Azureポータル、仮想マシン、「 B 」、「 ディスクの接続 」を介して、 AからVM Bにデータディスクを接続します
VM " B "では、最終的にディスクが接続され、マウントすることができます。
VM " B "のマウントするドライブ名を探してください。それぞれのLinuxは少し異なります。
- grep SCSI /var/log/kern.log（ubuntu、debian ）
  grep SCSI / var / log / messages （centos、suse、oracle、redhat）
マウントされたディスクをmountpoint / rescueにマウントする
df -h
mkdir /レスキュー
Red Hat 7.2+の場合
mount -o nouuid / dev / sdc2 / rescue
CentOS 7.2以降
mount -o nouuid / dev / sdc1 / rescue
Debian 8.2+、Ubuntu 16.04+、SUSE 12 SP4 +
mount / dev / sdc1 / rescue
VM Bの / rescueにOSディスクをマウントし、/rescue/boot/grub.confファイルを変更します。 grub.confの変更

#title CentOS（2.6.32-504.16.2.el6.x86_64）
#root（hd0,0）
#kernel /boot/vmlinuz-2.6.32-504.16.2.el6.x86_64 roルート= UUID = 6d089360-3e14-401d-91d0-378f3fd09332 rd_NO_LUKS rd_NO_LVM LANG = en_US.UTF-8 rd_NO_MD SYSFONT = latarcyrheb-sun16 KEYBOARDTYPE = pc KEYTABLE = us rd_NO_DM numa = offコンソール= ttyS0 earlyprintk = ttyS0 rootdelay = 300 crashkernel = auto
#initrd /boot/initramfs-2.6.32-504.16.2.el6.x86_64.img

チェックする別の項目は、ブートローダーファイルのgrub.confにあるUUID値で指定されたデバイスが存在するかどうかです。

/ rescueにマウントされたOSディスクの例を見て/ rescue / dev / disk / by-uuidを見てください

grub.confファイルで参照されている対応するUUIDファイルがディスク上にピンク色で強調表示されていることがわかります

このファイルは実際には属性lrwxrwxrwxの先頭でlで示され、OSDisk sda1を指しているシンボリックリンクです

このファイルがない場合でも、システムの起動時にシンボリックリンクの削除のテストが再作成されます。

シンボリックリンクを手動で作成して、sda1がブートデバイスであるかどうか、および対応するUUIDを知る必要があります。

cd / rescue / dev / disk / by-uuid
ln -s ../../sda1 6d089360-3e14-401d-91d0-378f3fd09332

sda1ファイルはls出力で見られるLinuxではブロックデバイスと呼ばれ、 brw-rw--属性でabで示されるか、fileコマンドを実行することで知られています。

また、このファイルがcentos 6.5でテストされていることを確認することもできます。このファイルは、見つからない場合に再作成されます。

cd / rescue / dev / disk / by-uuid
ls -ltr ../../da1
brw-rw-- 1ルートディスク8、1 Apr 30 14:37 ../../sda1

ファイル../../sda1
../../sda1：ブロックスペシャル

2）前回のカーネルからブートしようとしたが、VMが起動しなかった場合、initramfsを再構築し、Linuxカーネルの新しい圧縮イメージをコピーしようとする可能性があります。これはgrubファイルの例にあります。

Initramfsファイル
initrd /boot/initramfs-2.6.32-504.16.2.el6.x86_64.img

カーネルファイル
/boot/vmlinuz-2.6.32-504.16.2.el6.x86_64

通常、オンプレミス環境では、リカバリCDからシステムをブートします。クラウド環境では、起動しないシナリオでシステムファイルを回復または操作するために、同じOSとバージョンの一時的なVMにOSディスクを接続する必要があります。これは、initramfsのコピーまたは再作成を試みる場合にはさらに強化されます。カーネルファイル

OSディスクが一時的なVM on / rescueに接続されると（最初にOSディスクをコピーしてデータを保護する）

最初のカーネルを参照してエントリをコメントアウトして、それらを再起動する場合は、以前に行ったgrub.confへの変更を元に戻してください。

次に、initramfsを再構築します。

mv /rescue/boot/initramfs-2.6.32-504.8.1.el6.x86_64.img /rescue/boot/initramfs-2.6.32-504.8.1.el6.x86_64.old-img

一時的なCentOS 6.6 Linux VMでは、正確に同じinitramfsを見つけることができなかったため、一時的な最新バージョンのビルドと使用ができませんでした。

dracut /rescue/boot/initramfs-2.6.32-504.8.1.el6.x86_64.img 2.6.32-504.8.1.el6.x86_64

次に、関連するvmlinuzファイルを安全にコピーし、最後にgrub.confを更新して新しいカーネル値を反映させます。
ls -ltr / lib / modules /

drwxr-xr-xです。 7ルートルート4096年4月14日2014 2.6.32-431.11.2.el6.x86_64
drwxr-xr-xです。 7ルートルート4096 6月4日2014 2.6.32-431.17.1.el6.x86_64
drwxr-xr-xです。 7ルートルート4096 2014年9月25日2.6.32-431.29.2.el6.x86_64
drwxr-xr-xです。 7ルートルート4096 Nov 18 18:54 2.6.32-504.1.3.el6.x86_64
drwxr-xr-xです。 7根根4096 Mar 25 19:28 2.6.32-504.12.2.el6.x86_64

dracut /rescue/boot/initramfs-2.6.32-504.12.2.el6.x86_64.img 2.6.32-504.12.2.el6.x86_64

ls -ltr /rescue/boot/initramfs-2.6.32-504.12.2.el6.x86_64.img
-rw --- 1ルートルート19354168 5月6日15:39 /rescue/boot/initramfs-2.6.32-504.12.2.el6.x86_64.img

cp /boot/vmlinuz-2.6.32-504.12.2.el6.x86_64 / rescue / boot /

ls -ltr / rescue / boot / vmlinuz *

-rwxr-xr-x。 1ルートルート4128368 Nov 22 2013 /rescue/boot/vmlinuz-2.6.32-431.el6.x86_64
-rwxr-xr-x。 1ルートルート4128688 2013年1月3日/rescue/boot/vmlinuz-2.6.32-431.3.1.el6.x86_64
-rwxr-xr-x。 1ルートルート4129872 2014年5月7日/rescue/boot/vmlinuz-2.6.32-431.17.1.el6.x86_64
-rwxr-xr-x。 1ルートルート4131984 2014年9月9日/rescue/boot/vmlinuz-2.6.32-431.29.2.el6.x86_64
-rwxr-xr-x。 1ルートルート4153008 Jan 28 21:40 /rescue/boot/vmlinuz-2.6.32-504.8.1.el6.x86_64
-rwxr-xr-x。 1ルートルート4152720 5月6日15:44 /rescue/boot/vmlinuz-2.6.32-504.12.2.el6.x86_64

vi /rescue/boot/grub/grub.conf

タイトルCentOS（2.6.32-504.12.2.el6.x86_64）
ルート（hd0,0）
カーネル/boot/vmlinuz-2.6.32-504.12.2.el6.x86_64 roルート= UUID = 6d089360-3e14-401d-91d0-378f3fd09332 rd_NO_LUKS rd_NO_LVM LANG = en_US.UTF-8 rd_NO_MD SYSFONT = latarcyrheb-sun16 crashkernel = auto KEYBOARDTYPE = pc KEYTABLE = us rd_NO_DM rhgb quiet numa =オフconsole = ttyS0 earlyprintk = ttyS0 rootdelay = 300
initrd /boot/initramfs-2.6.32-504.12.2.el6.x86_64.img

cd /
umount / rescue

Azureポータル経由でVM Bからディスクを切り離す
修復されたVHDから元のVM Aを再作成する

クラシックVMの場合：

オリジナルのVM A （ ギャラリーを作成し、[ マイディスクを選択]）を再作成すると、VM Aを参照するディスクが表示されます。元のクラウドサービス名を選択します。

Resource Manager VMの場合、PowershellまたはAzure CLIツールを使用する必要があります。以下の記事では、元のVHDからVMを再作成する手順を示しています。

Azure PowerShell：VHDからVMを削除して再展開する方法
Azure CLI：VHDからVMを削除して再展開する方法

Cancel reply