☰

再起動後、ディスクパーティションはファイルシステムにマウントされません。

tag-icon • tag-icon centos filesystems mount virtual-machine
再起動後、ディスクパーティションはファイルシステムにマウントされません。

昨夜再起動した仮想マシンがあり、SSH経由で接続できません。私はコンソールを使ってそれを見て、次のコマンドを使ってインストール/します。 swaplsblk

  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

実行すると、.ils -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

なぜこれが起こるのですか？

ベストアンサー1

誰かまたは何かが原因/etc/mtabで書き込めなくなった（不変ファイル？ルートファイルシステムを読み取り専用として残すファイルシステムのバグ？）、再起動前の古いデータが含まれている可能性があります。したがって、コマンドはmount、dfファイルシステムが実際にマウントされていなくてもマウントされていると見なします。

ファイルシステムが読み取り専用状態であることを確認してください。grep ro, /proc/mounts

不変性を確認してください/etc/mtab。lsattr /etc/mtab

必要に応じて、このコマンドを使用して変更可能なフラグをchattr -i /etc/mtab削除します。i/etc/mtab

/etc/mtab現代のシステムでは、シンボリックリンクがまたはになることがますます増えています。システム/ディストリビューションに以前のバージョンのコマンドがある場合、これらの接続によって特定のファイルシステムをマウントするユーザー名が記録されないため、マウントオプションが失敗する可能性があります。マウントオプションを使用していない場合は、古いシステムでこのシンボリックリンクを作成することもできます。/proc/mounts/proc/self/mountsmountuser/etc/mtabuser

この種の接続の利点は、カーネル自体から直接マウントされたファイルシステムに関する最新の情報を常に持っているため/proc/mounts（または名前空間サポートを持つシステムで）、発生したエラーなどのエラーが発生しないことです。/proc/self/mounts

に接続する代わりに、最新バージョンのコマンドがこの目的mountに使用されます。/run/mount/etc/mtab/proc/self/mounts

不変に設定されていて他の理由が見つからない場合は、ハッキングされている可能性が/etc/mtabあります。/etc/mtab不変に設定すると、侵入者が自分のツールを誤って観察しないように隠すことができるためです。

おすすめ記事