☰

fat-fs(mmcblk0p1): ボリュームが正しく分離されていません。一部のデータが破損している可能性があります。 fsckを実行してください

tag-icon • tag-icon linux
fat-fs(mmcblk0p1): ボリュームが正しく分離されていません。一部のデータが破損している可能性があります。 fsckを実行してください

このアラームは、カスタマイズされたシステムの起動時に表示され、mmcblk0p1シャットダウン時にパーティションをアンマウントしていないことを示します。/etc/fstab停電時に自動的に削除されるように修正する方法は？

部分印刷dmesg：

...
    [    6.488912] CAN device driver interface
    [    6.502179] f81604_probe: Fintek F81604 driver version: v1.19
    [    6.550910] f81604 1-8:1.0: Channel #0 registered as can0
    [    6.597869] f81604_is_hw_disable: ch: 1, i: 100, r: 100
    [    6.597872] f81604 1-8:1.0: f81604_probe: channel 1 is h/w diabled
    [    6.597905] usbcore: registered new interface driver f81604
    [    6.613718] EXT4-fs (mmcblk0p2): recovery complete
    [    6.614116] EXT4-fs (mmcblk0p2): mounted filesystem fbc7620b-3aec-4ad5-8f01-b1d8f2006a4c r/w with ordered data mode. Quota mode: none.
    [    6.615305] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
    [    6.637649] i2c i2c-0: ioctl, cmd=0x705, arg=0x7ffc39b81308
    [    6.637663] i2c i2c-0: ioctl, cmd=0x703, arg=0x74
    [    6.637667] i2c i2c-0: ioctl, cmd=0x720, arg=0x7ffc39b812d0
...

彫刻：

root@dobot:~# blkid
/dev/mmcblk0p3: UUID="2692a861-c28c-4127-a037-dd1756b28da0" TYPE="ext4"
/dev/mmcblk0p2: UUID="fbc7620b-3aec-4ad5-8f01-b1d8f2006a4c" TYPE="ext4"
/dev/mmcblk0p1: UUID="C377-C6E3" TYPE="vfat"

/etc/fstab:

root@dobot:~# cat /etc/fstab
#device          mount-point            type           options     dump   fsck order
UUID=2692a861-c28c-4127-a037-dd1756b28da0   /                      ext4           defaults    0          1
UUID=fbc7620b-3aec-4ad5-8f01-b1d8f2006a4c   /boot                  ext4           defaults    0          1
UUID=C377-C6E3   /boot/efi              vfat           umask=0077  0          0
proc             /proc                  proc           defaults    0          0
sysfs            /sys                   sysfs          defaults    0          0
tmpfs            /tmp                   tmpfs          defaults    0          0
tmpfs            /var                   tmpfs          defaults    0          0
debugfs          /sys/kernel/debug      debugfs        default     0          0
mdev             /dev                   ramfs          defaults    0          0
devpts           /dev/pts               devpts         defaults    0          0

答え1

市中に予測可能な機器がないためみんな実際に停電が発生する前にこの問題を解決する一般的な方法は、無停電電源装置（UPS）を使用することです。

外部電源装置に障害が発生した場合、UPSはシステムに警告を送信し、UPSバッテリーが消耗する前にシステムを制御された方法でシャットダウンできます。

これらのソリューションを望まない場合は、完全な保護を提供しませんが、十分な解決策があります。

/boot/efi2つの場合にのみ必要です。

  • 起動時（読み取り専用アクセスで十分）
  • ブートローダを更新するとき（読み書きアクセスが必要）

ブートローダアップデートがインストールされたときにマウントされるようにシステムアップデートメカニズムに機能を追加してからマウント解除できる/boot/efi場合は、通常の使用中にアンマウントされたままにすることができます（noautoからマウントオプションを追加するだけです/etc/fstab）。

カスタムシステムにアップデートを提供するためにパッケージマネージャを使用している場合は、ブートローダパッケージにプレインストールスクリプトを追加してインストールされたかどうかをテストします/boot/efi。プレインストールスクリプトがこのフラグを設定すると、インストール後スクリプトはそれを再度削除します。

同様のものがある場合は、grub.cfg必要に応じて自動的にインストールおよび削除されるようにパッチまたは同様の実行構成更新ツールを使用すること/boot/efiもできます。grub2-mkconfig/boot/efi

これにより、ファイルシステムをマウントして書き込む時間が大幅に短縮され、ブートローダまたは/boot/efiその設定の更新中に停電が発生しない限り、このエラーが発生するのを防ぎます。このような状況は非常にまれです。

fsck order数値フィールドを/etc/fstab0から2に変更することもできます/boot/efi。システムにいる場合、/sbin/fsck.vfat停電後に次回起動すると、システムは自動的にこのエラーを修正できます。

関連情報