Is there any command available to initiate an ext4 filesystem check on next boot?

  • Hi folks

    I want to force a check of the Ext4 boot partition. That´s only possible, when device is unmounted. Like during system boot....

    Does anybody knows an easy way for this or do i have to create a Linux live boot USB stick?

    Any suggestions?


    Thanks for your help and

    best regards

    prtigger

    Old (2011) Supermicro 1U Rackserver X7SPA-HF, Intel Atom D510, 4GB RAM (maximum) | System: Supermicro SATA DOM 64GB SSD | Data: 3*Samsung 870 QVO 4TB SATA (Btrfs Raid1) | OMV 8.x services: SSH, SMB, NFS, MiniDLNA | 6.12.x kernel | Bare-metal

  • raulfg3

    Hi, that´s what i found with Google, too...

    Did you every try this with OMV? Is the output of filecheck going into bootlog (journalctl -b)?


    Thanks for quick response!

    prtigger

    Old (2011) Supermicro 1U Rackserver X7SPA-HF, Intel Atom D510, 4GB RAM (maximum) | System: Supermicro SATA DOM 64GB SSD | Data: 3*Samsung 870 QVO 4TB SATA (Btrfs Raid1) | OMV 8.x services: SSH, SMB, NFS, MiniDLNA | 6.12.x kernel | Bare-metal

  • Thanks!

    I'll try it...


    Best regards

    prtigger

    Old (2011) Supermicro 1U Rackserver X7SPA-HF, Intel Atom D510, 4GB RAM (maximum) | System: Supermicro SATA DOM 64GB SSD | Data: 3*Samsung 870 QVO 4TB SATA (Btrfs Raid1) | OMV 8.x services: SSH, SMB, NFS, MiniDLNA | 6.12.x kernel | Bare-metal

  • You'll get a message saying that /forcefsck is deprecated, but I've been seeing that for many years and it still works.

    --
    Google is your friend and Bob's your uncle!


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • You'll get a message saying that /forcefsck is deprecated, but I've been seeing that for many years and it still works.

    I´m thinking, i´m a little bit stupid!


    I had done with root account:

    touch /forcefsck

    (no output from command)

    reboot


    I can´t see anything of a forced filecheck in bootlogs (journalctl)...

    My boot device (sda1) is coming up 'clean' like every boot....

    My intention was to force a check..


    May be, it´s not working anymore....


    Best regards

    prtigger

    Old (2011) Supermicro 1U Rackserver X7SPA-HF, Intel Atom D510, 4GB RAM (maximum) | System: Supermicro SATA DOM 64GB SSD | Data: 3*Samsung 870 QVO 4TB SATA (Btrfs Raid1) | OMV 8.x services: SSH, SMB, NFS, MiniDLNA | 6.12.x kernel | Bare-metal

  • Still works for me. I see the checks being performed in the console and below is a snip of a few of them found in the journal:


    Code
    Mar 18 16:17:33 omv systemd[1]: Starting systemd-fsck@dev-disk-by\x2duuid-13aac774\x2d7c10\x2d4725\x2dae0a\x2d744f45aabf69.service - File System Check on /dev/disk/by-uuid/13aac774-7c10-4725-ae0a-744f45aabf69...
    Mar 18 16:17:33 omv systemd[1]: Started systemd-fsckd.service - File System Check Daemon to report status.
    Mar 18 16:17:34 omv systemd[1]: Starting systemd-fsck@dev-disk-by\x2duuid-dd8ff6bf\x2d6680\x2d470f\x2db67c\x2d26401b436fda.service - File System Check on /dev/disk/by-uuid/dd8ff6bf-6680-470f-b67c-26401b436fda...
    Mar 18 16:17:34 omv systemd[1]: Starting systemd-fsck@dev-disk-by\x2duuid-b06f946f\x2d2818\x2d4cd7\x2da7f3\x2d1340b2b25fe0.service - File System Check on /dev/disk/by-uuid/b06f946f-2818-4cd7-a7f3-1340b2b25fe0...

    --
    Google is your friend and Bob's your uncle!


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • Soma

    Hi, i´m getting this:


    root@pr-srv-01:~# dmesg|grep fsck

    [ 11.777267] systemd[1]: Listening on systemd-fsckd.socket - fsck to fsckd communication Socket.

    [ 11.905445] systemd[1]: systemd-fsck-root.service - File System Check on Root Device was skipped because of an unmet condition check (ConditionPathExists=!/run/initramfs/fsck-root).

    root@pr-srv-01:~#


    I installed the system new from latest iso. yesterday. All updates installed, to... But not completly configured.


    Best regards folks

    prtigger

    Old (2011) Supermicro 1U Rackserver X7SPA-HF, Intel Atom D510, 4GB RAM (maximum) | System: Supermicro SATA DOM 64GB SSD | Data: 3*Samsung 870 QVO 4TB SATA (Btrfs Raid1) | OMV 8.x services: SSH, SMB, NFS, MiniDLNA | 6.12.x kernel | Bare-metal

  • [ 11.905445] systemd[1]: systemd-fsck-root.service - File System Check on Root Device was skipped because of an unmet condition check (ConditionPathExists=!/run/initramfs/fsck-root).

    This is what copilot says:

    Quote

    This message indicates that the File System Check on Root Device was skipped because the condition ConditionPathExists=!/run/initramfs/fsck-root was not met. The ! symbol means "not," so the check is skipped if the file /run/initramfs/fsck-root exists.


    This file is typically created during the boot process to indicate that the root filesystem has already been checked. If the file exists, it means the check has already been performed earlier in the boot sequence.


    If you want to force a filesystem check on boot, you might need to modify your boot parameters or ensure that the file /run/initramfs/fsck-root does not exist before the check is supposed to run. You can try updating the initramfs or adjusting the boot configuration to achieve this.


    It means the fsck was run before the systemd-fsck started and the system was clean.


    If it's clean, why do you want to force a fsck?

    If you really want to, just use the SystemRescueCD on the kernel plugin and run it while the disks are unmounted.

  • It means the fsck was run before the systemd-fsck started and the system was clean.

    prtigger1


    If you want to check the last fsck, just run:

    sudo cat /run/initramfs/fsck.log


    My last boot ---^^^^

  • Soma


    Hi Soma

    Thanks for all this informations!

    I'll try it again, if i've got time.


    I guess, deleting


    /run/initramfs/fsck-root


    and doing


    touch /forcefsck

    reboot


    may work?!


    Best regards

    prtigger

    Old (2011) Supermicro 1U Rackserver X7SPA-HF, Intel Atom D510, 4GB RAM (maximum) | System: Supermicro SATA DOM 64GB SSD | Data: 3*Samsung 870 QVO 4TB SATA (Btrfs Raid1) | OMV 8.x services: SSH, SMB, NFS, MiniDLNA | 6.12.x kernel | Bare-metal

    Edited once, last by prtigger1 ().

  • Don't think so.

    That file is created as a sanity check IIRC.


    You need to find info on how to configure initramfs to force the fsck before the sanity check.


    I read somewhere this is a feature from Debian 12.

    On Debian<=11, the touch /forcefsck always worked without issues

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!