【Linux】VMwareで仮想マシンの保存場所を変更すると起動しなくなる問題の解決方法

# 仮想マシンが起動しなくなった経緯
仮想マシンやスナップショットの容量が大きくなり，仮想マシンを保存しているCドライブの容量が枯渇してきた．そこで，新しく用意したEドライブにVMwareのファイルを移動することにした．自分が行った手順は以下の通り．

1. 仮想マシンをパワーオフ
1. 仮想マシンが含まれるディレクトリ（`C:\Windows\ユーザー\l3ickey\ドキュメント\Virtual Machines\Kali Linux\`）をコピー
1. 新しい保存場所（`E:\Virtual Machines\Kali Linux\`）に貼り付け
1. 仮想マシンをVMwareのライブラリから削除
1. [ファイル] > [開く] で新しい保存場所にある仮想マシン構成ファイル（`E:\Virtual Machines\Kali Linux\Kali Linux.vmx`）を参照して指定
1. 新しい仮想マシンをパワーオン
1. `You are in emergency mode. After logging in, type "Journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.`というエラーが発生

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/8673b06b-23af-fbbe-9058-afeed76034d1.png)

# エラーの原因と解決方法
CドライブからEドライブにディレクトリをコピーした際，仮想マシン設定の共有フォルダが無効になってしまい，共有フォルダのマウントに失敗するためエラーが発生していた．
このエラーを解決するには，単純に [仮想マシン] > [設定] から [オプション] タブの [共有フォルダ] を選択し，[フォルダの共有] を `無効` から `常に有効` に変更する．変更後，仮想マシンを再起動することで正常に起動するようになる．
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/f5960093-c08f-6dc5-a152-fe8158b9972b.png)

# 解決に至るまでの手順
上記の解決方法で解決すると思うが，実際に自分が行った手順も参考程度に書き記しておく．

## /bin/bash にログイン
`emergency mode` は `root` ユーザーのパスワードの再設定などで使われるそうだが，今回は `root` ユーザーのアカウントがロックされているため，シェルにアクセスすることができない．そのため，まずは `/bin/bash` にログインすることから始める．基本的に下記の記事と同じことをした．
[Error “Cannot open access to console, the root account is locked” (SOLVED)](https://suay.site/?p=1681)

1. 仮想マシンを再起動
1. ブートローダーが起動したら `eキー` を押してブート設定の編集に進む
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/27352f33-bb1f-1c41-190b-cc3dc34284cd.png)
1. `linux` から始まる行の末尾に `single init=/bin/bash` を追記
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/4a1112e3-6db4-30fa-ac9c-be130f5f319e.png)
1. `Ctrl+x` または `F10` を押してブート
1. `/bin/bash` が起動
![image (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/76a434b1-c482-d19a-3e62-e677f8e57be8.png)

## /dev/sda1 に読み取り権限を付与
`passwd` コマンドでパスワードを変更しようとすると失敗する．
![image (2).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/42e08aa2-19e0-1576-93bf-677664524ca8.png)
この場合，ルートディレクトリに書き込み権限が無い可能性がある．
`mount` コマンドで権限を確認すると，`/dev/sda1 on /` の権限が `ro` (read-only) になっている．
![image (3).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/5b4024e5-0748-5c51-7aae-e0aa73a1efc0.png)
再マウントすることでルートディレクトリの権限を `rw` (read, write) に変更する．
![image (4).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/051cff7a-857f-7285-bfaf-bf019f989397.png)
もう一度 `passwd` コマンドでパスワードを変更し，書き込み権限があることを確認する．
![image (5).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/9554c836-7951-57dc-4141-5735a4beaf0f.png)

## root ユーザーのアカウントロックをアンロック
アカウントがロックされていることが原因でログインシェルにアクセスできないため，アカウントロックのアンロックを行う．`passwd -u root` コマンドで `root` ユーザーのアカウントロックをアンロックすることができる．
![image (6).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/907afd0f-32d2-585e-5113-1a9ca388fac5.png)
`/etc/passwd` ファイルを確認し，`root` ユーザーのログインシェルが `/usr/sbin/nologin` になっていないことを確認する．（`/usr/sbin/nologin` になっている場合は `/usr/bin/bash` などに変更する必要がある）
![image (7).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/87c9a02f-877e-e900-fcd3-e637ebdc03a0.png)
再起動すると，`Give root password for maintenance` という表示があり，パスワードを入力することでログインシェルにアクセスできるようになる．
![image (8).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/01c4f5e0-9c27-1ad7-cb6a-6c4be3be2611.png)

## ブート時のエラーを解消
上記の画像の一行目を見ると，`SMBus Host Controller not enabled!` というエラーが表示されていることが確認できる．重要ではなさそうだったため，理由までは調べなかったが `i2c_piix4` というモジュールをブラックリストに追加することでエラーを解消することができる．
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/875fad72-6cb5-8222-cca7-397ed087f0f9.png)
再起動すると，`SMBus Host Controller not enabled!` というエラーが消えていることがわかる．
![image (9).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/55eeaeb6-aec8-c9a8-f738-9f72799236c3.png)

## 共有フォルダを有効化
`You are in emergency mode. After logging in, type "Journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.`というエラーはマウントに失敗していると表示されることが多い．`/etc/fstab` を確認し，`UUID` やその他の設定に不備が無いか確認する．
![image (10).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/e874374b-f011-a697-cd57-6c29b2913f01.png)
`lsblk -f` コマンドで `UUID` を確認すると，`UUID` は正しいことがわかる．
![image (11).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/2136fe00-c27d-ee30-8a8c-c55d5582863c.png)
となると怪しいのは `vmhgfs-fuse` で，これは仮想マシンからホストOSにある共有フォルダをマウントするための設定．[仮想マシン] > [設定] から [オプション] タブの [共有フォルダ] を選択すると，[フォルダの共有] が `無効` になっていることに気づく．これを `常に有効` に変更し，仮想マシンを再起動することで正常に起動するようになった．
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/f5960093-c08f-6dc5-a152-fe8158b9972b.png)
おかえりGUI．
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355011/23f85b0d-0076-915e-86b5-fa2345bdd513.png)

# おわりに
ホストOSの共有フォルダ機能は便利なので使っている人が多いと思います，しかし思わぬところで機能が無効になり，ブートに失敗するという罠があるので気づくのに時間がかかりました．この記事が同じ問題で困っている人の役に立てば幸いです．

# 参考文献
- [VMware Docs - 仮想マシンの新しい格納場所またはホストへの移動](https://docs.vmware.com/jp/VMware-Workstation-Pro/17/com.vmware.ws.using.doc/GUID-FCD1EFEE-1E20-4C96-A1F0-BAC53BF728FF.html)
- [Error “Cannot open access to console, the root account is locked” (SOLVED)](https://suay.site/?p=1681)
- [VMware Communities - Errors when booting Ubuntu: SMBus Host Controller not enabled! - Failed to connect to lvmetad - Falling back to internal scanning](https://communities.vmware.com/t5/VMware-Fusion-Discussions/Errors-when-booting-Ubuntu-SMBus-Host-Controller-not-enabled/td-p/450289)
- [SMBus Host Controller not enabled!](https://yvernis.blog.fc2.com/blog-entry-141.html)
- [How to exit emergency mode and boot to default mode?](https://askubuntu.com/questions/685946/how-to-exit-emergency-mode-and-boot-to-default-mode)
- [app-emulation/open-vm-tools: Error -107 cannot open connection!](https://bugs.gentoo.org/646684)