☰

ドライバのマウントにより Ubuntu システムが再起動しません。

tag-icon • tag-icon ubuntu mount reboot
ドライバのマウントにより Ubuntu システムが再起動しません。

一般化する

AzureでホストされているUbuntu VMがあります.約8時間前に私は走り、apt-get updateそれapt-get upgradeからreboot。それ以来、緊急モードでのみデバイスにアクセスできます。再起動された出力に表示される唯一のエラーは次のとおりです。

[FAILED] Failed to mount /mnt/sdc.

トラブルシューティング手順

手動でインストールしようとしましたが、エラーメッセージが表示されます/mnt/sdc: /dev/sdc already mounted or mount point busy。

私は実行しps aux | grep sdc、次のような結果を得ます。

root       390  0.0  0.0      0     0 ?        S    12:34   0:00 [jbd2/sdc1-8]
root      1519  0.0  0.0  14860  1016 ttyS0    R+   14:13   0:00 grep --color=auto sdc

だからプロセスを終了しようとしましたが失敗しました。

質問

このような状況にあったり、何が起こっているのかを知っていれば、私が何をすべきかを理解するのに役立ちますか？私はこのドライブを約10ヶ月間インストールしてきましたが、それ以降は問題がなかったので、ここで迷子になりました。

cat /etc/fstab

# CLOUD_IMG: This file was created/modified by the Cloud Image build process
UUID=d22737df-af8f-43b8-8146-90f8eb34d05f       /        ext4   defaults,discard        0 0
UUID=5E59-638A  /boot/efi       vfat    defaults,discard        0 0
/dev/sdc        /mnt/sdc        ext4    defaults        0       0
/dev/disk/cloud/azure_resource-part1    /mnt    auto    defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig       0       2
//sihstaffstor.file.core.windows.net/sih-workspace /mnt/sih-workspace cifs nofail,vers=3.0,credentials=/etc/smbcredentials/sihstaffstor.cred,dir_mode=0777,file_mode=0777,serverino
UUID=1a3bed40-91a8-4e2a-8092-8ddfe3dcb60b /mnt/sdc1 ext4 defaults,nofail 1 2

lsblk -f

NAME    FSTYPE LABEL           UUID                                 MOUNTPOINT
sda     ext4                   d80521c3-0fac-4228-aa39-c2a8db512c72
sdb
└─sdb1  ext4                   1a3bed40-91a8-4e2a-8092-8ddfe3dcb60b /mnt/sdc1
sdc
├─sdc1  ext4   cloudimg-rootfs d22737df-af8f-43b8-8146-90f8eb34d05f /
├─sdc14
└─sdc15 vfat   UEFI            5E59-638A                            /boot/efi

df -h

Filesystem                                          Size  Used Avail Use% Mounted on
udev                                                7.9G     0  7.9G   0% /dev
tmpfs                                               1.6G  608K  1.6G   1% /run
/dev/sdc1                                            29G   25G  4.3G  86% /
tmpfs                                               7.9G     0  7.9G   0% /dev/shm
tmpfs                                               5.0M     0  5.0M   0% /run/lock
tmpfs                                               7.9G     0  7.9G   0% /sys/fs/cgroup
/dev/sdc15                                          105M  3.6M  101M   4% /boot/efi
/dev/sdb1                                            32G   49M   30G   1% /mnt
//sihstaffstor.file.core.windows.net/sih-workspace 1000G  635G  366G  64% /mnt/sih-workspace

答え1

おそらくアップデートパッケージに問題があるでしょう（おそらくデバイスサービスがあるすべて)または実際、このパーティションとの不幸な偶然の一致またはアクセス違反。ただし、これは追加情報のない推測にすぎません。

考えられる問題についてアップデートのアップグレードこの/ eseログを最初に見ないと推測することはできません。/var/log/apt/term.log & 必要なら /var/log/apt/term.log.N.gz （ここで「N」はカウンターです）。

blkidまた、/dev/sdc がマウントされているように見えるので、lsblkの出力が手がかりを提供できます。fdisk -l /dev/sdc

マウントしようとすると、アクセス違反が発生する可能性があります。仮想FS（たとえば、vmdk) VM ゲストでは、物理パーティションはホストによってマウントされます。たとえば、Windowsは常にすべてをマウント（再接続）するため、Windowsホストでは見えない、または意図しないようにこれが発生する可能性があります。したがって、各ディスクをマウント解除する必要があります。ホストからゲストで使用したいパーティション - 複数のパーティションの1つです。

ディスクは死ぬ可能性があります。不可能だと確信しているときはいつもそうです。だから試してみてください！まず、SMARTデータ（gsmartmontools、GSmartControlなど）を確認してください。まだ明確ではない場合 —fsによって異なります。–、実行chkdskまたはfsck そして表面試験（後者のコマンドは確かにNTFSには役立ちません！）。しかし、少し時間がかかります。

要点は、破損が発生した場合、最悪の場合、ディスクにアクセスしようとする追加の試みは、ディスクに深刻な損傷をもたらし、データを保存できない可能性があることです。したがって、他のオプション（更新など）を排除できると確信するまでインストールしないでください。

トラブルシューティングに役立つことを願っています。

答え2

これはAzureの問題かもしれません。今朝はトラブルシューティングを続けましたが、再起動後に設定が機能せず、ディスクがマウントされました。

関連情報