重新啟動後磁碟分區不會掛載到文件系統

我有一台昨晚重新啟動的 VM 機器，我們無法通過 ssh 連接到它。我使用了控制台，只看到了它，/並swap用lsblk命令安裝：

 NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
 sr0     11:0    1 1024M  0 rom
 sdb      8:16   0    8G  0 disk
 ├─sdb1   8:17   0    2G  0 part 
 └─sdb2   8:18   0    6G  0 part [SWAP]
 sdc      8:32   0   20G  0 disk
 └─sdc1   8:33   0   20G  0 part 
 sde      8:64   0  400M  0 disk
 └─sde1   8:65   0  399M  0 part 
 sda      8:0    0   20G  0 disk
 └─sda1   8:1    0   20G  0 part /
sdd      8:48   0   20G  0 disk
└─sdd1   8:49   0   20G  0 part 
sdf      8:80   0   10G  0 disk
└─sdf1   8:81   0   10G  0 part   

但是當我跑的時候df -h：

 Filesystem      Size  Used Avail Use% Mounted on
 /dev/sda1        20G  1.2G   18G   7% /
 tmpfs           7.8G     0   7.8G   0% /dev/shm
 /dev/sde1        20G    1.2G  18G   7% /boot
 /dev/sdd1        20G    1.2G  18G   7% /data
 /dev/sdc1        20G    1.2G  18G   7% /opt
 /dev/sdb1        20G    1.2G  18G   7% /var
 /dev/sdf1        20G    1.2G  18G   7% /backup

當我在它們上執行ls -hal時，它們都是空的，除了./我試圖解除安裝和掛載分區時出現分區未掛載的錯誤。我再次安裝它們，例如：

mount /dev/sdf1 /backup

和df -h：

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        20G  1.2G   18G   7% /
tmpfs           7.8G     0  7.8G   0% /dev/shm
/dev/sde1       387M   40M  327M  11% /boot
/dev/sdd1        20G   14G  4.9G  75% /data
/dev/sdc1        20G  1.4G   18G   8% /opt
/dev/sdb1       2.0G  155M  1.8G   9% /var
/dev/sdf1       9.9G  2.4G  7.0G  26% /backup  

一切都很好。我重新啟動以測試它。它又發生了。只有/和交換已安裝。blkid輸出：

  /dev/sdb1: UUID="3a11afe1-52d5-4e31-96a0-66da2c8e70eb" TYPE="ext3"
  /dev/sdf1: UUID="0e1f69a7-36d9-4af1-a537-afaa211e87d7" TYPE="ext3"
  /dev/sdb2: UUID="416970f8-c21b-419b-90d5-eb8eabb685a6" TYPE="swap"
  /dev/sdc1: UUID="d380ddf8-3476-46b3-8e80-9dd3b394dd13" TYPE="ext3"
  /dev/sde1: UUID="b224fa8a-e909-432e-927e-4a98fe2d74d0" TYPE="ext3"
  /dev/sda1: UUID="9407e385-168c-4e37-9651-1de04406b620" SEC_TYPE="ext2" 
  TYPE="ext3"
  /dev/sdd1: UUID="e8439366-d29d-43c3-ad5e-635855f4e42e" TYPE="ext3"

部分cat /etc/fstab輸出：

 UUID=9407e385-168c-4e37-9651-1de04406b620 /         ext3    defaults   0 0
 UUID=b224fa8a-e909-432e-927e-4a98fe2d74d0 /boot     ext3    defaults   0 0
 UUID=e8439366-d29d-43c3-ad5e-635855f4e42e /data     ext3    defaults   0 0
 UUID=d380ddf8-3476-46b3-8e80-9dd3b394dd13 /opt      ext3    defaults   0 0
 UUID=3a11afe1-52d5-4e31-96a0-66da2c8e70eb /var      ext3    defaults   0 0
 UUID=416970f8-c21b-419b-90d5-eb8eabb685a6 swap      swap    defaults   0 0
 UUID=0e1f69a7-36d9-4af1-a537-afaa211e87d7 /backup   ext3    defaults   0 0

為什麼會這樣？

也許有人或某事導致/etc/mtab變得不可寫（不可變文件？文件系統錯誤使根文件系統保持只讀狀態？），並且它包含重新啟動之前的舊數據。結果，mountanddf命令認為文件系統已經掛載，即使它們實際上沒有掛載。

檢查處於只讀狀態的文件系統：grep ro, /proc/mounts

檢查不可變/etc/mtab：lsattr /etc/mtab

如有必要，使用該chattr -i /etc/mtab命令刪除i可變標誌。/etc/mtab

在現代系統中，/etc/mtab越來越多地成為指向/proc/mountsor的符號連結/proc/self/mounts。如果您的系統/發行版有舊版本的mount命令，這種連結可能會導致掛載選項user失敗，因為它無法記錄將特定文件系統掛載到/etc/mtab. 如果您不使用usermount 選項，您也可以在舊系統上創建此符號連結。

這種連結的優點是不會發生像您遇到的錯誤，因為/proc/mounts（或/proc/self/mounts在具有命名空間支持的系統上）總是直接從核心本身獲得有關已安裝文件系統的最新資訊。

如果連結到. mount_/run/mount``/etc/mtab``/proc/self/mounts

如果您發現/etc/mtab已設置為不可變，並且找不到其他原因，則您可能已被黑客入侵，因為設置/etc/mtab不可變可能是入侵者隱藏其工具以防止隨意觀察的一種方式…

引用自：https://unix.stackexchange.com/questions/501284