☰

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/efi仅在两种情况下需要：

  • 启动时（只读访问权限就足够了）
  • 更新引导加载程序时（需要读写访问权限）

如果您可以向系统更新机制添加功能，/boot/efi以便在安装引导加载程序更新时进行挂载，然后卸载它，则可以在正常使用中将其保留为卸载状态（只需noauto在 中为其添加一个挂载选项/etc/fstab）。

如果您使用包管理器向自定义系统提供更新，则只需将预安装脚本添加到引导加载程序包中以测试是否/boot/efi已安装，如果没有，则安装它并设置一个标志以记住它已这样做;如果预安装脚本设置了该标志，则安装后脚本将再次卸载它。

如果您有类似的内容grub.cfg，/boot/efi您可能还需要修补grub2-mkconfig或类似的启动配置更新工具，以便/boot/efi在需要时自动安装和卸载。

这应该大大减少文件系统需要安装和写入的时间/boot/efi，从而阻止此错误的发生，除非在更新引导加载程序或其配置期间断电。这种情况应该是极其罕见的。

您可能还想将 的fsck order数字字段/etc/fstab从 0 更改为 2 /boot/efi。如果您的系统上有/sbin/fsck.vfat，这可能允许系统在断电后下次启动时自动修复此错误。

相关内容