• [gentoo-user] fsck operational error

    From ralfconn@21:1/5 to All on Sat Sep 21 18:20:02 2024
    Hello,

    Upon boot OpenRc shows this warning:

    fsck: checking local filesystem
    fsck: fsck.ext4 device or resource busy while trying to open /dev/nvme0n1p6 fsck: filesystem mounted or opened exclusively by another program?
    fsck: operational error

    This is the root filesystem, and in fstab it is listed as:

    UUID=xxxx-xxxx-xxxx / ext4 noatime,discard 0 1

    /etc/conf.d/fsck contains only:

    fsck_on_battery="YES"
    fsck_shutdown="NO"
    fsck_abort_on_errors="YES"

    This started a week ago after a system update when I switched from
    kernel 6.10.9 to 6.10.10 (~amd64). That day there was also an update of
    OpenRc to version 0.55.

    Has anybody seen the same?

    thanks,

    raf

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ralfconn@21:1/5 to All on Wed Apr 9 18:40:02 2025
    Il 21/09/24 18:16, ralfconn ha scritto:
    Upon boot OpenRc shows this warning:

    fsck: checking local filesystem
    fsck: fsck.ext4 device or resource busy while trying to open /dev/nvme0n1p6 fsck: filesystem mounted or opened exclusively by another program?
    fsck: operational error

    ...

    This started a week ago after a system update when I switched from
    kernel 6.10.9 to 6.10.10 (~amd64). That day there was also an update of OpenRc to version 0.55.

    Old thread, no answer, but now I get the same message on another box,
    just after I reconfigured the kernel for hardening (https://kspp.github.io/Recommended_Settings), so it was not an OpenRC
    issue.

    I'll update if I find the option that causes the issue, just to close
    the thread for the posterity :-).

    raffaele

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael@21:1/5 to All on Wed Apr 9 23:08:37 2025
    On Wednesday, 9 April 2025 17:38:50 British Summer Time ralfconn wrote:
    Il 21/09/24 18:16, ralfconn ha scritto:
    Upon boot OpenRc shows this warning:

    fsck: checking local filesystem
    fsck: fsck.ext4 device or resource busy while trying to open
    /dev/nvme0n1p6
    fsck: filesystem mounted or opened exclusively by another program?
    fsck: operational error

    ...

    This started a week ago after a system update when I switched from
    kernel 6.10.9 to 6.10.10 (~amd64). That day there was also an update of OpenRc to version 0.55.

    Old thread, no answer, but now I get the same message on another box,
    just after I reconfigured the kernel for hardening (https://kspp.github.io/Recommended_Settings), so it was not an OpenRC
    issue.

    I'll update if I find the option that causes the issue, just to close
    the thread for the posterity :-).

    raffaele

    I don't run a hardened setup and don't have this problem.

    Is your fsck service in boot level?

    ~ # rc-update -s -v | grep fsck
    fsck | boot

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmf27+UACgkQseqq9sKV ZxnABw//QpRChLiuvWGjDk1Gv2TX/ojBT07Cz1jvoyhK3IvYOL+JvRQDmuzU76Os vqna1taLDdL1ENuVlBXcMKSZDppvhJ/B0iwIzyAvhmYCRpCogMUtzQAsX9ZaBa/w QY7CMYleCwhhmLEQVYMtq1ErWkTMnaDsmJPosw0KV2mjf9JGTbLuMG5BC8bTagBx uBmshNa3YLM3SLYVV+XV82ups0vCmj/n8eeo+7B1jjghcPwCbJH13sRsidmUkuuL +YBe5x0ER45q83WuyiSxY1DQzgOyDvkYGactCpc5zMnhV/E8R3kEQr7GzPyyLXdD EgLjaSuJUf126bA1XWX6SLpG+wiRoUllmdEbmBuBteS7kjjXM+8H8E49YrSUEAkI aUdhC/ARaz50jsr35wxJBbcp0qoZiiqeV4CGUtwx3gH5iM5F5VkBVQaqu92yp1YN sC/oUCvnuBSID68NTHbD47qMRbezYoKBaBCoiLvjK9Fk9rOS0d73/yIFXNZhSq7S Uqc4JcRFj7y+Oo+r4bqmyQi7xOYs9YmCy7YgPzH7J5JTvCxCv5tOHD/+LlezKczb SLzi5eKYkfxFHQwhR67Ymup2BmpHTMAoEd7hcG8p/1hxfRCf3G9xNPI745IggTlv 7LBwQ+GuMVO6glhFuDwltBrVYcWQv7miJX8WDSR0QAwVJ11cC50=
    =iRod
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From yahoo@21:1/5 to All on Thu May 22 19:20:01 2025
    Il 09/04/25 18:38, ralfconn ha scritto:
    Il 21/09/24 18:16, ralfconn ha scritto:
    Upon boot OpenRc shows this warning:

    fsck: checking local filesystem
    fsck: fsck.ext4 device or resource busy while trying to open /dev/
    nvme0n1p6
    fsck: filesystem mounted or opened exclusively by another program?
    fsck: operational error

    ...
    Old thread, no answer, but now I get the same message on another box,
    just after I reconfigured the kernel for hardening (https:// kspp.github.io/Recommended_Settings), so it was not an OpenRC issue.

    I'll update if I find the option that causes the issue, just to close
    the thread for the posterity :-).


    I found the kernel option causing the error:

    BLK_DEV_WRITE_MOUNTED

    Re-enabling the option fixes the issue.

    The help says:

    "When a block device is mounted, writing to its buffer cache is very
    likely going to cause filesystem corruption. It is also rather easy to
    crash the kernel in this way since the filesystem has no practical way
    of detecting these writes to buffer cache and verifying its metadata
    integrity. However there are some setups that need this capability like *running fsck on read-only mounted root device*, modifying some features
    on mounted ext4 filesystem, and similar...."

    I can't say they didn't warn me :-)

    The option is on by default, I was directed to switch it off by app-admin/kernel-hardening-checker:

    CONFIG_BLK_DEV_WRITE_MOUNTED |kconfig| is not set |a13xp0p0v |cut_attack_surface| FAIL: "y"

    The fourth column is the source of the recommended setting - a13xp0p0v -
    who is the maintainer of the tool. It's in github, I'll open a ticket there.

    raffaele

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From yahoo@21:1/5 to All on Thu May 22 22:10:01 2025
    Il 22/05/25 20:13, Dale ha scritto:
    yahoo wrote:
    Is this a driver we should all disable or do you have a different use
    case than most?  I ask because mine is on as well.  Given the large

    DON'T DISABLE IT!

    fsck must be executed on unmounted filesystem and for 'root fs' that
    normally happens only during boot. On my system the order of init
    services is:

    - kernel starts and mounts root fs in read only mode
    - OpenRc starts
    ...
    1. fsck service (this checks the root fs)
    2. root service (this remounts the root fs in read/write mode)
    ...

    If you disable that option when the fsck service runs it finds the root
    fs mounted read-only, fails and does not check the root fs _ever_. Not a
    good idea!

    Maybe with different init systems or a different OpenRC configuration
    the two services are executed in the reverse order, I don't know, I have
    the same behavior on two different OpenRc systems. I would not risk if I
    were you. That said, if you want to give it a try, study the logs
    carefully to ensure it doesn't break the fsck service.

    raffaele

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From yahoo@21:1/5 to All on Thu May 22 23:40:01 2025
    Il 22/05/25 22:02, yahoo ha scritto:
    Il 22/05/25 20:13, Dale ha scritto:
    yahoo wrote:
    Is this a driver we should all disable or do you have a different use
    case than most?  I ask because mine is on as well.  Given the large

    DON'T DISABLE IT!


    Sorry, I just re-read what I wrote and the stuff below does not make
    sense, I'm mixing up unmounted and read-write/read-only. I need to
    understand better what's going on.

    "Don't disable it" is the only correct answer.

    raffaele

    fsck must be executed on unmounted filesystem and for 'root fs' that
    normally happens only during boot. On my system the order of init
    services is:

    - kernel starts and mounts root fs in read only mode
    - OpenRc starts
    ...
    1. fsck service (this checks the root fs)
    2. root service (this remounts the root fs in read/write mode)
    ...

    If you disable that option when the fsck service runs it finds the root
    fs mounted read-only, fails and does not check the root fs _ever_. Not a
    good idea!


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)