☰

ext4启动时检查文件系统

tag-icon • tag-icon linux ext4 fsck
ext4启动时检查文件系统

昨天，我们的一台计算机掉壳了grub，或者老实说，当我们打开机器时，我不确定它是什么壳。

它表明由于不一致，它无法挂载根文件系统或某种意义上的东西。

我跑了，我相信：

fsck -fy /dev/sda2

重新启动，问题就消失了。

提问部分来了：

我已经在她的 root 的 crontab 中：

@reboot /home/ruzena/Development/bash/fs-check.sh

而脚本包含：

#!/bin/bash
touch /forcefsck

想一想，我不知道为什么我为这么短的命令创建脚本文件，但无论如何......

此外，在文件中：

/etc/default/rcS

我已经定义：

FSCKFIX=yes

所以我不明白。怎么会出现这样的情况呢？

我应该怎么做才能在启动时强制进行根文件系统检查（以及可选的修复）？

或者这两件事是我能做的最大的事情？

操作系统：Linux Mint 18.x 肉桂 64 位。

fstab：

cat /etc/fstab | grep ext4

显示：

UUID=a121371e-eb12-43a0-a5ae-11af58ad09f4    /    ext4    errors=remount-ro    0    1

grub：

fsck.mode=force

已经添加到grub配置中。

答案1

ext4启动时检查文件系统

测试操作系统：虚拟机中的 Linux Mint 18.x

基本信息

/etc/fstab顺序fsck为最后（第六）列，例如：

<file system>    <mount point>    <type>    <options>    <dump>    <fsck>
UUID=2fbcf5e7-1234-abcd-88e8-a72d15580c99 / ext4 errors=remount-ro 0 1

FSCKFIX=yes变量在/etc/default/rcS

这会将 fsck 更改为自动修复，但是不是强制进行 fsck 检查。

从man rcS：

FSCKFIX
    When  the  root  and all other file systems are checked, fsck is
    invoked with the -a option which means "autorepair".   If  there
    are  major  inconsistencies then the fsck process will bail out.
    The system will print a  message  asking  the  administrator  to
    repair  the  file  system manually and will present a root shell
    prompt (actually a sulogin prompt) on the console.  Setting this
    option  to  yes  causes  the fsck commands to be run with the -y
    option instead of the -a option.  This will tell fsck always  to
    repair the file systems without asking for permission.

从man tune2fs

If you are using journaling on your filesystem, your filesystem
will never be marked dirty, so it will not normally be checked.

从...开始

设置以下内容

FSCKFIX=yes

在文件中

/etc/default/rcS

检查并记下上次检查 fs 的时间：

sudo tune2fs -l /dev/sda1 | grep "Last checked"

这两个选项不起作用

  1. 将-F（强制fsck重新启动）参数传递给shutdown：

    shutdown -rF now

    没有;看：man shutdown。

  2. 添加/forcefsck空文件：

    touch /forcefsck

    这些脚本似乎使用了这个：

    /etc/init.d/checkfs.sh
/etc/init.d/checkroot.sh

    做过不是重新启动后可以工作，但文件已被删除。

    经核实：

    sudo tune2fs -l /dev/sda1 | grep "Last checked"
sudo less /var/log/fsck/checkfs
sudo less /var/log/fsck/checkroot

    这些似乎是脚本的日志init。

我再说一遍，这两个选项都不起作用！

这两种方法都有效

  1. systemd-fsck内核启动开关

    编辑主grub配置文件：

    sudoedit /etc/default/grub

    GRUB_CMDLINE_LINUX="fsck.mode=force"

    sudo update-grub
sudo reboot

    这确实进行了文件系统检查，并通过以下方式进行了验证：

    sudo tune2fs -l /dev/sda1 | grep "Last checked"

    注：这个做过检查，但要强制修复，您需要指定fsck.repair="preen", 或fsck.repair="yes"。

  2. 用于tune2fs在执行之前设置文件系统挂载的数量fsck，man tune2fs

    tune2fs' info is kept in the file system superblock

    -cswitch 设置在检查 fs 之前挂载 fs 的次数。

    sudo tune2fs -c 1 /dev/sda1

    验证：

    sudo tune2fs -l /dev/sda1

    这做过工作经验证：

    sudo tune2fs -l /dev/sda1 | grep "Last checked"

概括

要fsck在 Linux Mint 18.x 上的每次启动时强制执行 a，请使用tune2fs、 或fsck.mode=force，以及可选的fsck.repair=preen/fsck.repair=yes内核命令行开关。

答案2

对现有答案的进一步调查和更新

我现在只是想检查一下上面的内容是否仍然有效基于 Ubuntu 20.04/22.04-LTS 的系统（直接在 Linux Mint 20/21 Cinnamon amd64 桌面和 Ubuntu MATE 20.04/22.04 amd64 桌面上测试），我发现了一些事情，让我们从文件系统检查间隔开始（我以 root 身份运行所有命令（你可能会注意到）~#命令前面）：

文件系统检查间隔

~# LC_ALL=C tune2fs -l /dev/nvme0n1p2 | grep 'Check interval'

Check interval:           0 (<none>)

嗯，这是出乎意料的。我以为我们已经解决了这个问题，但修复起来很容易。请注意，它作为参数的数字默认以天为单位，因此请务必使用 1s（1 秒）而不是 1，这意味着 1 天（86400 秒）：

~# LC_ALL=C tune2fs -i 1s /dev/nvme0n1p2

tune2fs 1.45.5 (07-Jan-2020)
Setting interval between checks to 1 seconds

现在，如果我们重复上述检查，我们会得到：

Check interval:           1 (0:00:01)

当然，这并不意味着每秒都会检查文件系统。相反，实际上它将强制对每个文件系统挂载进行文件系统检查。 （因为没有办法在一秒钟内两次启动任何系统

相关内容