第639回　Ubuntuに「トラブル時に」ログインするいろいろな方法

第638回ではUbuntuにログインする一般的な方法をいくつか紹介しました。ただしそれらの方法はあくまでUbuntuがきちんと動いていることが前提となっています。今回は不幸にもUbuntuがうまく起動しなくなったときに、ログインできるかもしれない手段を紹介しましょう。

具体的には、今回は次の4パターンを紹介します。

パスワードを忘れたときなどにシングルユーザーモードで「ログインする」方法（このページで解説）
ルートファイルシステムをマウントできなくなったときにInitramfsに「ログインする」方法（2ページ目で解説）
ストレージデバイスを仮想マシン化して「ログインする」方法（3ページ目で解説）
SSHログインできなくなったときのためにIPMIやシリアルコンソールで「ログインする」方法（4ページ目で解説）

リカバリー用にシングルユーザーモードでログインする

人間の記憶はアテになりません。昨日食べたご飯どころか、たったいま何をしようとして立ち上がったのかを思い出せないことすらよくあります。ましてマシンごとのパスワードなんて覚えられるはずがありません。だからのこのポストイットはとても大事なものなんです。剥がさないでくださいお願いします。

そんな涙ながらの主張にも関わらずディスプレイに貼られた紙を廃棄され、パスワードを思い出せずにUbuntuにログインできなくなることもあるでしょう。でもUbuntuなら大丈夫。たとえあらゆるパスワードを思い出せなかったとしても、マシンに物理的にアクセスできる状況であれば、特権モードで起動してパスワードを再設定することが可能なのです。これにはFBIもニッコリです[1]⁠。

Ubuntuは起動時にGRUBメニューを操作することで、シングルユーザーモードで起動することが可能です。ただし通常のインストール設定だとGRUBメニューが表示されない可能性は高いです。そこでGRUBメニューを表示する方法をいくつか紹介しておきましょう。

方法A：電源投入後、PCのロゴが表示される前からESCキー（UEFIの場合）もしくはSHIFTキー（BIOSの場合）を連打する
- 経験的に「押し続ける」よりも「連打する」ほうが確実です
- ESCキーを連打する場合は、GRUBメニューが表示されてすぐにGRUBプロンプト「grub>」に移行してしまうかもしれません
- そのときは「normal」と入力して、画面が消えたらすぐに「1回だけ」ESCキーを押してください
方法B：正しく起動できている状況であれば、/etc/default/grubを次のように変更した上で再起動してください
- 「GRUB_TIMEOUT_STYLE=hidden」を「GRUB_TIMEOUT_STYLE=menu」に変更する
- 「GRUB_TIMEOUT=0」を「GRUB_TIMEOUT=5」に変更する
- 「sudo update-grub」を実行する
- これで起動時は常に5秒間はGRUBメニューが表示されます
- 言い換えると、この変更が有効な間は、起動時間が5秒遅くなります
方法C：キー入力もうまくいかないし設定も変更できない場合は次の方法で強制的にメニューを表示可能です
- 電源投入後、カーネルの起動処理が開始してからsystemdが起動する手前までのタイミングでリセットします
- これによりGRUBはリセット前のエントリーの起動に失敗したと判断し、次回起動時にメニューを表示します

うまくGRUBメニューを表示できたら、シングルユーザーモードに入ります。まず図1にある「Advanced options for Ubuntu」にカーソルを合わせてエンターキーを押してサブメニューに入ってください。すると次のようにカーネルごとのいくつかのオプションエントリが表示されるはずです。

複数のバージョンのカーネルがインストールされている場合は、上記のように複数の「recovery mode」エントリが表示されます。基本は一番上の「recovery mode」を選択すれば大丈夫ですが、もし起動できない場合は他のメニューを選択してください。ここで起動するまでしばらく待ちます。

すると画面下部に次の図のような「Press Enter for maintenance」メッセージが表示されるはずです。ここで単にエンターキーを入力すれば、シングルユーザーモードのシェルに「ログイン」できます。

厳密に言うと一般的な認証を通っていないので、「⁠ログインした」と言ってよいかどうかは疑問ではありますが、正規の手続きでシステム上の管理者にはなれたので大丈夫でしょう[2]⁠。あとはrootユーザーと同じなので、必要に応じてシステム上の設定を変更してください。

ちなみにUbuntuはrootアカウントを無効化しているために、この手順においてパスワードは問われません。もし何らかの理由でrootのパスワードを設定している場合、「⁠Give root password for maintenance」と表示されrootのパスワードを入力しないとログインできません。現在のUbuntuシステムにおいて、rootパスワードを設定する意味はあまりないため、もし誤って設定してしまった場合は「sudo passwd -l root」しておくと良いでしょう。逆に言うと、十分に強いrootのパスワードを設定しておけば、この手順によるログインを無効化できます[3]⁠。

インターネット接続は有効化されていません。もし有効化したい場合は、一旦「exit」コマンドでログアウトしたあと、再度表示されたリカバリーメニューから「network Enable networking」を選択してください。「⁠ファイルシステムを変更するために書き込み可能状態でマウントするが良いか？」と聞かれるので「Yes」と答えます[4]⁠。自動的にリカバリーメニューに戻るので、もう一度「root Drop to root shell prompt」を選択すればネットワークに繋がっているはずです。

リカバリーメニューには他にもシステムを回復するために必要な手段が一通り存在するので、何か問題が発生して起動できなくなったときには役に立つでしょう。

最近のUbuntuだとシングルユーザーモードに入った時点でルートファイルシステムは読み書き可能な状態でマウントされています。もし何らかの理由で読み込み専用でマウントされていて、なおかつ、システム設定を変更するなどルートファイルシステムに書き込みたい場合は、次のコマンドで再マウントしてください。

# mount -o remount,rw /

どうしても再マウントできない場合は、ストレージが壊れている可能性があります。別途対応方法を検討しましょう。まずは後述のInitramfsを利用したログイン方法で言及している「ストレージのバックアップを取る方法」を実施することになるでしょう。

ちなみにシングルユーザーモードにおいて、特定のユーザーのパスワードは次の方法で再設定できます。

# passwd （ユーザー名）
New password: （新しいパスワードを入力）
Retype new password: （上記と同じパスワードを再度入力）
passwd: password updated successfully

うまく設定を変更できたなら、「⁠reboot」コマンドを実行して再起動しましょう。

もし再起動せずに継続して起動処理を続けて欲しい場合は、「⁠exit」コマンドでシングルユーザーモードを終了し、リカバリーメニューが表示されたら、今度は「resume Resume normal boot」を選択してください。ただしこの場合は、各種ドライバがロードされないなど「リカバリーモード」のまま起動します。正しい起動を行うためには再起動が必要なので注意してください。

ディスクをマウントせずにログインする

ストレージは消耗品です。近い将来、必ず壊れます。一番壊れてほしくないタイミングで壊れます。それはUbuntuがインストールされているHDD/SSD/eMMC/microSDであっても例外ではありません。

しかしながら前述のシングルユーザーモードでログインする方法は、必ずルートファイルシステムをマウントする必要があります。たとえストレージが壊れていなかったとしてもマウントできなければ、やはりシステムは起動できません。

そこでストレージ上のルートファイルシステムをマウントせずにシステムにログインする方法を考えてみましょう。

Initramfsに「ログイン」する

第384回でも紹介したように、Ubuntuは最初にブートローダーであるGRUBが、ストレージからカーネルと「Initramfs」を探しだし、そのふたつをメモリー上にロードした上で、システムを起動します。Initramfsにはストレージやネットワークのドライバーが同梱されているため、カーネルはこれらのドライバーをロードしつつ、システムがインストールされているストレージデバイスをマウントします。

Initramfsは「小さなUbuntu」とも言うべき簡易的なシステムです。サイズを小さく保つためにaptコマンドなどは使えませんがそれでも必要最低限のUnixライクな環境として使えます。

なお、Initramfsは一般的にカーネルと一緒に起動ディレクトリに保存されています。UEFI対応マシンならESP（EFI System Partition）と呼ばれるFAT領域となります。よってストレージそのものが動かない場合は、この方法は使えません。そもそもGRUBも起動しない状態なので注意してください。本項の手順では、あくまでESPは見えている状態（ストレージが完全に壊れているわけではない状態）を想定しています。

Initramfsは大抵の場合、なんらかの理由でルートファイルシステムをマウントできなかったときに表示されます。また、それとは別にGRUBのメニュー画面でカーネルの起動パラメーターを変更すると、InitramfsはルートファイルシステムをマウントすることなくBusyBox環境に「ログイン」します。具体的にはGRUBメニューの一番上のメニュー上で「e」を押します。

上記のようにメニューエントリの編集画面になるので、画像のように「linux」で始まる行の最後に「break」を追加してください。基本はカーソルキーで該当する行に移動し、「⁠Ctrl-e」で行末にジャンプ、その後にスペース＋「break」と入力すれば良いはずです。

編集できたら、「⁠Ctrl-x」でこのメニューエントリを実行します。なお、この編集結果は保存されませんので安心してください。キャンセルしたい場合は、Ctrl-c」を押します。

前述のとおり、このプロンプトはルートファイルシステムをマウントできなかったときにも表示されるため、過去に遭遇した人もいるかもしれません。特にRAIDを組んでいたり、特殊なドライバーが必要なストレージデバイスを使っている人は遭遇しやすいかもしれません。

さて、このBusyBoxは組み込み向けにも使われる一般的なユーティリティコマンド群をひとつのバイナリファイルにまとめたものです。端末ソフトウェアで使うコマンドのうち、一般的に頻度の高いコマンドはひととおり存在するものの、サポートしているオプション等は通常のUbuntu環境における同名のコマンドと大きく異なります。とりあえずコマンド一覧を知りたい場合は「help」と入力してください。

試しにルートファイルシステムをマウントしてみましょう。

上図ではルートファイルシステムのマウントに成功していますが、意図せずInitramfs環境にログインするということは、ルートファイルシステムをマウントできないケースが大半です。実際に手作業でマウントし、出てきたエラーメッセージから原因を推測する流れになるでしょう。もし運が良ければ、fsckするだけで解決する場合もあります。「⁠blkid」や「fdisk -l」でストレージデバイスの名前を推量し、「⁠fsck デバイスファイル名」してみるだけでも良いかもしれません。

ただしfsckコマンドの実行が瀕死のルートファイルシステムにとどめを刺すという可能性も否めません。どうしても重要な情報が含まれるストレージデバイスだということであれば、先にddコマンドなどでディスクイメージ化し、適当な別のストレージにバックアップを取るべきです。

一応udevが動いているので、上記のようなストレージデバイスや、他にもUSBストレージなどを接続してマウントすることも可能です。ただしInitramfsに含まれているカーネルモジュールはルートファイルシステムのそれに比べて少なめになっているので注意してください。可能であれば簡単なファイルシステム経由でコピーすれば、modprobeでロードすることも可能です。

ストレージのバックアップを取る

バックアップ用の別のストレージを用意できるなら、次の手順でルートファイルシステムがインストールされたストレージを保存できます。一般的にバックアップ用にはルートファイルシステムと同サイズのストレージを接続するのが理想的ではありますが、必ずしも準備できるとは限りません。そこである程度圧縮すれば収まることを期待して、次のように実行すると良いでしょう。

# mount /dev/sdb1 /mnt
# dd if=/dev/sda conv=sync,noerror bs=65536 | gzip -c > /mnt/host-sda.img.gz
327600+0 records in
327600+0 records out
21474836480 bytes (21 GB, 20 GiB) copied, 373.366 s 57.5 MB/s

# file /mnt/host-sdaimg.gz
/mnt/host-sda.img.gz: gzip compressed data, from Unix, original size module 2^32 0
# ls -sh /mnt/host-sda.img.gz
4.4G /mnt/host-sda.img.gz

# umount /mnt

まず「/dev/sdb1」は十分に容量があり、きちんと動くストレージデバイスのパーティションのファイル名です。環境によって異なるので注意してください。USBストレージなら接続した直後に「dmesg | tail」すれば、デバイスファイル名がわかるはずです。前述のとおり「blkid」を実行し、ディスクラベルから推定するという方法もあります。

「/dev/sda」がバックアップを取りたいストレージデバイスそのものです。「⁠/dev/sda2」のようにパーティション単位で保存しても良いですし、「⁠/dev/sda」と全体を取ってしまうという方法もあるでしょう。ddコマンドでは「conv=sync,noerror」によりディスクキャッシュを使わずにきちんと保存しつつ、読み込みエラーに遭遇しても継続して読み出すようにしています。

gzipコマンドによってイメージを圧縮しています。ゼロで埋められた空き領域が多いと圧縮率はあがるものの、空き領域にランダムな値が入っているとするとそこまで圧縮されません。結果的に保存先は保存元と同程度の容量のものを選んでおいたほうが安全ではあります。

ライブラリも最低限のものは用意されているので、例えばGo言語のプログラムであればバイナリ一個持ってきて実行することは可能ですし、ルートファイルシステムをマウントできるなら環境変数LD_LIBRARY_PATHにマウントしたディレクトリの共有ライブラリが存在するディレクトリを指定する方法も使えるでしょう。

ネットワークへの接続も、リカバリーモードと異なりひと手間必要です。具体的には「ip link」コマンドを使ってインターフェイスをupし、「⁠dhclient」コマンドを使ってIPアドレスを取得します。

wgetコマンドがあるのでネットワーク越しのファイルの取得ぐらいならできるはずです。またNFSマウントするという手もあります。固定IPアドレスを割り当てたいなら、dhclientの代わりに次のコマンドを実行することになるでしょう。

# ip addr add <IPアドレス> dev <ネットワークインターフェース>

ここでの「<IPアドレス>」はCIDR形式で記述可能です。その他の詳細は「ip -h」を実行してください。残念ながらUbuntu標準のInitramfsでは、WiFiに接続する簡単な方法は用意されていません。どうしても必要ならwpa_supplicantなどをInitramfsに用意する必要があります。

exitコマンドを実行すると、Initramfs環境を抜けて通常の起動を行います。単に電源を切りたいだけならpoweroffコマンドを使ってください。

Initramfs環境は上記で指定した「break」以外にもさまざまなカーネルの起動パラメーターを設定することで挙動を変更できます。詳しいことは「man initramfs-tools」を実行して表示される情報を参照してください。

USBデバイスからブートし、ストレージ領域にログインする

前項とは逆にブート領域（ESPやその上のカーネルなど）のデータがおかしくなり、ルートファイルシステムは無事な状況を考えてみましょう。独自ビルドのカーネルやサードパーティのカーネルモジュールを使用した結果、起動途中にカーネルパニックするケースも該当します。もしくはWindowsとデュアルブートしているときにGRUB領域を書き潰してしまうこともあるかもしれません。他にもUEFIなシステムでインストールしたストレージをそのままレガシーBIOSで起動しようとしたり、その逆だったりすると、同じように起動できません[5]⁠。

このような状況においては、UbuntuのライブインストーラーをインストールしたUSBデバイスで起動し、そこからもともとのストレージ領域をマウントし、リカバリーを試みるのが一番簡単です。最近ではデスクトップ版だけでなくサーバー版のインストーラーもライブ環境に対応しています。CLIの操作に慣れているのであれば、サーバー版のインストーラーで起動し、「⁠Ctrl-Alt-Fx」で別の仮想コンソールに切り替えた上で、操作すると良いでしょう。

一般的なリカバリー手順に従えば回復できる場合は、UbuntuのライブインストーラーよりはSystemRescueのようなリカバリーに特化したイメージを使ったほうが楽な場合も多いです。やりたいことがはっきりしている場合はまずはSystemRescueの利用を検討してください。

手元にUbuntuのライブインストーラーがあってそれをそのまま使いたいとか、ストレージの中身を取り出したいだけなら、Ubuntuのライブインストーラーでも良いでしょう。特に後者であれば、ライブインストーラーで起動し、外部ストレージをマウントしたら、あとは前項の「ストレージのバックアップを取る」と手順は一緒です。デスクトップ版のUbuntuを使っているなら、イメージバックアップに対応したGUIツールをインストールして使うという手もあります。本連載を「バックアップ」で検索すればいろいろでてきますので、使い方にあわせて好みのものを選ぶと良いでしょう。

ストレージから仮想マシンイメージを構築しログインする

PCのうちストレージと同じくらい壊れる印象の強いパーツが電源です。実際に壊れやすいかどうかの統計的なものは不明ですが、とにかく壊れてしまうとPCはまさに「うんともすんとも、ぶぉんとも、ぴっとも」言わなくなってしまいます。他にもCPUやメモリーが壊れた場合も、同様でしょう。こうなってくるともうGRUBがどうのこうのInitramfsがどうのこうの以前の問題です。

この状態でストレージ上のUbuntuに「ログインしたい」となると、電源を取り替えるか、ストレージを取り出して別のPCに繋ぐしかありません。最近の一般的なPCだと、使われているストレージは次のいずれかでしょう。

3.5インチ/2.5インチのSATA HDD/SSD: 近くにHDD用スロットの空いているデスクトップPCがないのであれば、USB接続の外付けHDDケースを買ってくるのが一番楽です。
M.2 SATA/NVMe SSD: 「⁠M.2 エンクロージャー」などで検索すると外付け用のデバイスがいくつも見つかります。M.2 SATAタイプとM.2 NVMeタイプに分かれているので、使っているものに合わせて買うように注意してください。自作ユーザーだと、M.2接続のストレージは余る傾向にあるので、エンクロージャーを1台持っておくと「サイズの大きな小型USBストレージ」として使えるので便利です[6]⁠。
eMMC: UMPCと呼ばれる超小型PCに多いタイプです。マザーボードに直付けされているので、はんだごてマイスターでもない限り諦めてください。

単にデータを取り出したいだけであれば、あとは普通にファイルをコピーするだけです[7]⁠。しかしながらストレージを使ってUbuntuに「ログインしたい」となると、何か方法を考えなくてはなりません。

できれば「別のPC」もUbuntuのほうが作業は楽になります。Ubuntuがインストールされたマシンがないのであれば、前項と同じように、Ubuntuをライブインストーラーで起動すると良いでしょう。リカバリしたいストレージを接続してUbuntuを起動したあとは、次の手順になります。

ストレージ全体のバックアップを取る（前述の「ストレージのバックアップを取る」などを参照）
ストレージを仮想マシンイメージ化する
仮想マシンでそのイメージを起動する

手順1は手順2以降でトラブルが起きた時の安全策です。バックアップ用の十分容量のあるストレージがなく、なおかつ手順2以降で失敗してデータを失うことになってもかまわないというのであれば、手順1を飛ばしてもかまわないでしょう。

この方法のメリットは、仮想マシンの中でデスクトップを立ち上げられる可能性があるということです。Firefoxのパスワードマネージャーなど、CLIからだと操作が難しいものをリストアしたい場合に便利です。

本記事ではUbuntuでの手順を紹介していますが、別にWindowsマシンで同じことができないというわけではありません。Windowsの場合、OSにインストールされた標準のツールだけでは難しく、今だとWSL2なども含めた、なにがしかのソフトウェアをインストールすることになります。ただしそのソフトウェアは千差万別であり、手順が複雑になりがちです。どうしてもWindows上で作業したいということであれば、いっそのことVirtualBoxのVBoxManageコマンドを使って、ディスク全体を仮想マシンで解釈可能なイメージファイルに変更してしまうのが一番楽かもしれません。

ここではQEMUを使うケースと、VirtualBoxを使うケースを考えましょう。このうちVirtualBox版はWindowsでも利用可能です。またストレージデバイス全体を保存できる程度に十分な空き容量があるものとします。

ストレージを仮想マシンイメージ化する（QEMU版）

QEMUそのものについては第441回などを参照してください。とりあえず次の手順で必要なパッケージをインストールしておきましょう。

$ sudo apt install qemu-kvm qemu-utils ovmf

イメージ化したいストレージが「/dev/sdb」だとすると、次の方法で変更可能です。

$ sudo qemu-img convert -c /dev/sdb -O qcow2 old-sda.qcow2

別の方法でバックアップ済みのイメージであれば、gunzipで展開した上で、/dev/sdbの代わりに展開したファイル名を指定してください。

あとはQEMUでこのイメージを指定して起動するだけです。

$ cp /usr/share/OVMF/OVMF_VARS.fd .
$ sudo qemu-system-x86_64 \
    -m 2G -enable-kvm \
    -net user,hostfwd=tcp::2222-:22 \
    -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \
    -drive if=pflash,format=raw,file=OVMF_VARS.fd \
    -drive file=old-sda.img,format=qcow2

体感的に普通に起動するよりもそれなりに時間がかかるため、気長に待つようにしてください。ストレージに余裕があるならqemu-img実行時に「-c」オプションを省いて、イメージを圧縮しないという手もあるでしょう。

ストレージを仮想マシンイメージ化する（VirutalBox版）

VirtualBoxをインストール済みの環境であれば、convertfromrawサブコマンド使ってVDIに変換できます。

$ sudo VBoxManage convertfromraw /dev/sda old-sda.vdi --format VDI
$ sudo chown $USER: old-sda.vdi

VBoxManageの場合、標準入力からの変換もサポートしているので、既存のバックアップからの変換も簡単です。

$ gunzip -c host-sda.img.gz | VBoxManage convertfromraw stdin old-sda.vdi --format VDI

VBoxManageでは、Windowsでも使用できます。ただしストレージデバイスの指定方法がUbuntuと異なる点に注意してください。VirtualBoxのドキュメントの「9.7.1.1. Access to Entire Physical Hard Disk」によると、Windowsの場合は「\\.\PhysicalDrive0」のような指定の仕方になるようです。たとえば次の方法で、パーティションの中身を確認できるので、どのディスクが該当するか0から順番に確認していくと良いでしょう。

Windows> VBoxManage internalcommands listpartitions -rawdisk \\.\PhysicalDrive0
Number  Type   StartCHS       EndCHS     Size (MiB)  Start (Sect)
1       0x00  0   /0  /0   0   /0  /0          512          2048
2       0x00  0   /0  /0   0   /0  /0        19966       1050624

あとは前述の「VBoxManage convertfromraw」の「/dev/sda」を「\\.\PhysicalDriveX」に置き換えれば同じです。

VDIファイルは仮想マシン作成時に「ハードディスク」の画面で、「⁠すでにある仮想ハードディスクファイルを使用する」にチェックを入れて、フォルダアイコンをクリックします。すると表示される「ハードディスク選択」ダイアログで「追加」ボタンを押し、作成したVDIファイルを選択します。結果、次の画像のようになっていれば問題ありません。

UEFIシステムのイメージは、作成後に設定の「システム」から「マザーボード」タブの「EFIを有効化」にチェックを入れるのを忘れないでください。そうしないと「FATAL: No bootable medium found! System halted.」のエラーメッセージが出てしまいます。

あとは普通の仮想マシンと同じで、起動すればログイン画面が表示されるはずです。前述したとおり、QEMUやVirtualBoxを使うと、デスクトップ環境をそのまま起動できるというメリットがあります。どうしてもデスクトップ環境をそのままリカバリーして利用したい際は、強力な選択肢となるでしょう。

今回利用したVBoxManageコマンドは他にもいろいろ便利なサブコマンドが存在します。その一部は「ざっクリわかるVirtualBox 6.1対応版」でも解説されているので、気になる人はチェックしてみてください。

障害が発生したリモートのマシンにログインする

ここまでの手順はマシンに物理的にアクセスできることが前提でした。たとえばシングルユーザーモードやInitramfsは、マシンにディスプレイやキーボードが繋がっていないと使えませんし、ライブインストーラーを使用したり仮想マシンイメージを構築する方法は、USBデバイスを接続したりストレージデバイスを取り外す必要があります。

サーバーのようにリモートにあるマシンにトラブルが発生し、どうしても正規の方法以外でログインしたい場合はどうするのが良いでしょうか。この手のものは重要度が高いと冗長化されており、たとえ何かが故障したとしても待機系に自動的に切り替わってそのまま接続できたりします[8]⁠。

待機系を用意する余力も、「⁠どこでもドア」を用意できる運も備えていない場合は、「⁠何らかの方法でリモートからGRUBやInitramfsの画面に到達する」しかありません[9]⁠。

機材を問わず実現できる可能性が高いのは、「⁠シリアルコンソールを別のマシンにつないでおく」方法です。前回の記事の最後の「シリアルコンソールからログインする」では、UbuntuのGRUBとログインプロンプトをシリアルコンソールに出力する方法を紹介しました。この方法を使えば常にシリアルコンソールから操作できるようになっているので、あとはそれを別のマシンから操作できるようにしておくのです。

最近だとシリアルポートのないマシンは多いですが、USBシリアル変換ケーブルを使えば比較的簡単に増設できます。たとえばRaspberry Piか何かを起動しておいて、マシンがうまく起動できなくなったらRaspberry Pi経由でシリアルコンソールを見る、といった使い方が考えられるでしょう。Wake on LANも合わせて設定しておけば、「⁠不意に電源が切れた時の暫定リカバリー策」ぐらいにはなるはずです[10]⁠。

リモートのマシンがサーバースペックであれば、BMC（Baseboard Management Controller）が載っていることも多いでしょう。これはCPUとは独立して動くコントローラーで、サーバーが通電していれば（≒電源ケーブルが繋がっていれば⁠）⁠、CPU的には電源断状態であってもサーバーをネットワーク経由でコントロールできる仕組みです。

BMCがあればシリアルコンソール経由の操作、BIOSメニューの操作、サーバーの電源管理、温度などセンサーの確認などもCPUの状態とは独立してネットワーク経由で操作できます。

BMCはIPMI（Intelligent Platform Management Interface）の仕様に基づいてコントロールできることが一般的です。よってBMCとIPMIはあまり区別なく言及されますし、DellならiDRAC、HPならiLOみたいなブランド名で説明されることもあります。

BMC/IPMI経由でマシンをコントロールするための口は大抵の場合は、いわゆる「LANケーブル」がつながるようになっていることでしょう。接続口そのものは、BMC/IPMI専用だったり、通常のネットワークインターフェースと共用だったりとサーバーマシンや購入オプションによってまちまちです。後者の場合、BMC用のIPアドレスとCPUから見えるネットワークのIPアドレスは異なるアドレスを独立して設定できます。ただしBMC/IPMI専用の口と比べて、ネットワークケーブルやその先にトラブルが発生した場合に対応できないという問題はあります。

Ubuntuの場合、IPMIの操作にはipmitoolコマンドを利用できます[11]⁠。

$ sudo apt install ipmitool

テストには電源状態の確認コマンドを使うと良いでしょう。

$ ipmitool -I lanplus -H <BMC/IPMIのIPアドレス> -U <ユーザー名> power status

「-I lanplus」はどのようにBMC/IPMIにアクセスするかを指定します。ネットワーク経由ならlanplus（IPMI v2.0）かlan（IPMI v1.5）になるでしょう。指定しない場合、「⁠-H」が使われていたらlanが、そうでなければopenが指定されたものとします。openの場合、/dev/ipmi0経由でローカルマシンのBMCにアクセスするため、管理者権限が必要です。

ネットワーク経由だとアクセス時にBMC/IPMIのパスワードが問われます。「⁠-P <パスワード>」で指定も可能ですがコマンド履歴に残るためあまりおすすめはしません。

これで電源のオン/オフがわかりますし、statusの代わりにonやoff、resetなどを指定することで電源を操作することも可能です。

IPMIで運用上おそらく一番よく使うのがシリアルコンソールへのログインです（SOL：Serial Over LAN⁠）⁠。

$ ipmitool -I lanplus -H <BMC/IPMIのIPアドレス> -U <ユーザー名> sol activate

solがSerial Over LAN関連の設定であることを意味し、activateによって実際にSerial Over LANを有効化します。Ubuntu側が正しく起動していて、なおかつシリアルコンソールが有効化されていたらログインプロンプトが表示されるはずです。表示されなかったら、何回かエンターキーを押してみてください。それでも表示されないなら何らかの設定に問題があります。

シリアルコンソールから抜けるのは「~.」（⁠チルダドット）を入力します。ただしSSH経由でipmitoolを実行していると、SSH側をログアウトしてしまいます。SSHの先のIPMIのシリアルコンソールを抜けたい場合は、SSHの段数の数だけチルダを入力しましょう。たとえばSSHでリモートマシンにログインし、その上でipmitoolでさらに先のリモートサーバーにコンソールログインしているとき、コンソールを抜けるには「~~.」（⁠チルダチルダドット）と入力することになります。

サーバー側のBIOS設定で「シリアルコンソールリダイレクト」を有効化しておけば、本来VGAに表示されるデータがアスキー文字に変換されてシリアルコンソールにも出力されます。つまりBMC/IPMIのSOLとシリアルコンソールリダイレクトを組み合わせれば、リモートからBIOSメニューを操作することも可能です。

ちなみにBMC/IPMIのIPアドレスやパスワードは、BIOSメニューや起動時に選択できるサーバー固有の管理インターフェース、サーバーマシンによってはウェブブラウザー経由で設定可能です。通常は物理的にアクセス可能な、サーバーの設置時に設定することになります。しかしながらローカルマシンからのipmitoolコマンドによってコマンド経由でも設定できるのが一般的です。つまりサーバーマシンそのものにipmitoolコマンドをインストールしておけば、Ansibleなどの構成管理システムからサーバーごとのBMC/IPMI設定も管理できるのです。

他にもいろいろなことができるので、一度はipmitoolのmanページを読んでおくと良いでしょう。