EXT4-fs (nvme0n1p2): orphan cleanup on readonly fs - Is This Only A Statuis Message?

[0pLuS0]

Hello,

I'm running Gentoo OpenRC with only i3. On i3 I don't use any login managers, just tty with user/pass then startx.

Everytime I've been rebooting or shuting down, when I log back in, and look at dmesg I always see this;

[ 2.535040] EXT4-fs (nvme0n1p2): orphan cleanup on readonly fs
[ 2.535365] EXT4-fs (nvme0n1p2): mounted filesystem 99bcf0bd-7d3e-4940-8f1a-229efccbcf32 ro with ordered data mode. Quota mode: disabled.
[ 2.544310] dracut: Remounting /dev/disk/by-uuid/99bcf0bd-7d3e-4940-8f1a-229efccbcf32 with -o defaults,noatime,ro
[ 2.555155] EXT4-fs (nvme0n1p2): re-mounted 99bcf0bd-7d3e-4940-8f1a-229efccbcf32.
[ 2.563876] dracut: Mounted root filesystem /dev/nvme0n1p2
[ 2.581385] dracut: Switching root

Is orphan cleanup on readonly fs simply a Status Message, like it's entered/loaded this state is all it's telling us?

Because everywhere I've looked online, if there was a problem, then you do see it showing what it's deleting/cleaning up, and this message is not showing it's deleting/cleaning anything. I've also booted into the Gentoo LiveKDE and ran fsck on two different occassions, and both times it came back showing clean.

THANKS

[pratikrath126]

Hey there! That 'orphan cleanup on readonly fs' message is basically EXT4 telling you it found some orphaned inodes (files that were deleted but still had references) during the initial read-only mount, but since the filesystem was read-only at that moment it couldn't clean them up. It's a status message, not an error per se.

The early boot sequence often mounts the root filesystem as read-only first so fsck can run safely. After fsck completes, dracut should remount it read-write (rw). You can check your current mount status with:

mount | grep ' / '

If you see ro there even after boot, that would be a problem. But if it later shows rw, then everything is fine.

Since you already ran fsck from a LiveCD and it reported clean, your filesystem is healthy. The message is just noise from the initramfs scanning. No action needed unless you're experiencing actual boot issues.

Hope that helps!

[0pLuS0]

Hi @pratikrath126

Yes rw
mount | grep ' / '
/dev/nvme0n1p2 on / type ext4 (rw,noatime)

Well if you are saying it couldn't clean them up, then I'm assuming boot up a Live Medium and run fsck and it shows it cleaning up, not coming back telling you it's clean.

I found the code online;

https://elixir.bootlin.com/linux/v5.15.180/source/fs/ext4/orphan.c#L422

f (s_flags & SB_RDONLY) {
ext4_msg(sb, KERN_INFO, "orphan cleanup on readonly fs");
sb->s_flags &= ~SB_RDONLY;
}

It's my understganding In the Linux kernel, ext4_msg is a wrapper for printk.

sb: The superblock (identifies which drive/partition is talking).

KERN_INFO: The log level. It tells the system this is just an informational message, not an error or a warning.

The String: The actual text that appears in your dmesg or /var/log/messages.

It is the kernel's version of a "print" or "echo" statement.

But looking at this code;

I assumed by doing sb->s_flags &= ~SB_RDONLY;, the kernel temporarily makes the filesystem writable specifically to clear those orphans, even though you requested a read-only mount. Once it finishes the cleanup, it sets it back.

The Reality:
The Message: "I see orphans, and you told me to be Read-Only.

The Action: "I'm going to ignore your Read-Only request for a split second, fix the disk so it's consistent, and then go back to being Read-Only.

I also assume if it truly couldn't clean them up, your filesystem would stay "dirty" forever. I thought by the message appearing it means the kernel handled it.

Thanks

[0pLuS0]

To me this is a problem in OpenRC running a small window manager, without a login manager, gracefully rebooting/shutting down causing this glitch.

As if I need to create a special OpenRC script, because whatever is in Gentoo clearly isn't working.

There is nothing wrong with my filesystem, or hardware.

In i3 I have tried rebooting shutting down as;

sudo openrc-shutdown -r now
sudo openrc-shutdown -p now

I've also done;

sudo --reboot now
sudo --poweroff now

I've also simply logged out of X to the console and did Ctrl Atl Del and still get this.

What I need to know, is if there is anyone else out there running i3 in the same manner, no login manger, just tty with user/pass startx and has seen this, and how to correct this?

THANKS

[0pLuS0]

Oh sorry I overlooked this you mentioned;

Since you already ran fsck from a LiveCD and it reported clean, your filesystem is healthy. The message is just noise from the initramfs scanning. No action needed unless you're experiencing actual boot issues.

So if LiveCD reports clean, then is it possible seeing orphan cleanup on readonly fs is dmesg is simply a Status Message, like hey I've entered this state now, OR it actually thinks there is an orphan issue it's trying to deal with?

This is also not just initramfs scanning I booted the kernel also without using the initramfs. There's a Kernel or OpenRC issue here, not the initramfs.

I just don't want this thing, messing up my FS/NVMe...

THANKS

[0pLuS0]

I think this is a Handoff Quirk...

ext4 driver's internal behavior during the transition from the kernel's initial mount to OpenRC taking control of the real root.

OpenRC can't correct the Kernel Behaviour but it can, I assume handle how it reacts to it.

[0pLuS0]

So is this the reality...

Can OpenRC Handle it better?

OpenRC's mount-ro or checkfs services could be tuned to:

Silence the noise: If OpenRC detects that a cleanup already occurred (by checking the kernel log buffer), it could skip its own redundant checks.

Timing: OpenRC could ensure that the remount-ro transition happens only after the kernel confirms the orphan list is empty.

1. The Real Conflict

The issue is a race of authority:

The User/OpenRC says: Mount this partition Read-Only for safety.

The Kernel (ext4) says: I see a mess. I am ignoring you, making it Writeable, fixing it, and then I'll pretend I was Read-Only the whole time.

Is there a fix on the kernel side?

Patch the kernel source (fs/ext4/orphan.c) to change that ext4_msg to a KERN_DEBUG level so you never see it again. hmm

THANKS

[0pLuS0]

I hope the OpenRC Dev are going to see this, there is also a post over at Gentoo where I have laid out a lot more detail and information.

I feel like at this point, if this is not an issue with OpenRC then there's something maybe that needs to be done on the development side with Gentoo intergration, or the end-user needs to have a certain OpenRC script, especially when using only a WindowManager, without a login manager.

https://forums.gentoo.org/viewtopic-t-1176973.html

THANKS

[navi-desu]

oh okay, i missed this discussion, but let's see

i don't think i follow the whole issue, but it seems like some processes don't die with killall fast enough, and mount-ro fails? a summary would be helpful

though current we're somewhat limited on late-shutdown since gentoo runs openrc via sysvinit -- eventually moving the default to openrc-init would be great and give us the chance to handle those parts better

[0pLuS0]

Hi @navi-desu

So to start, I run this and it shows clean:

sudo tune2fs -l /dev/nvme0n1p2 | grep "Filesystem state"
Filesystem state: clean

But every reboot and shutdown I get:

[ 2.535040] EXT4-fs (nvme0n1p2): orphan cleanup on readonly fs

The tech reality I believe is a race condition during the Unmount/Remount-RO handshake.

In Arch, the systemd integration is tightly coupled with mkinitcpio. When you shut down, systemd pivots back to the initramfs to perform the final unmount. Because Arch's initramfs is pre-configured to handle the filesystem's state, it successfully transitions the NVMe to Read-Only (RO) before the power-off signal. A clean RO mount closes the journal; no orphans are created.

In Gentoo, you are likely hitting a Lazy Unmount or a SIGTERM/SIGKILL lag. Here is the technical breakdown:

The Failed Handshake: Even with quiet, if a process (like Pipewire, a flatpak, or a mount namespace) refuses to die within the shutdown timeout (DefaultTimeoutStopSec in systemd or rc_timeout_stop in OpenRC), the init system eventually moves to the final shutdown stage while the filesystem is still technically Busy.

The Dirty Transition: Because the filesystem is busy, the init system (Systemd or OpenRC) fails to remount / as Read-Only. The kernel then performs a dirty sync and cuts power while the journal is still open.

The Result: This leaves orphan inodes (files that were deleted but still had open handles at the time of the power cut).

The Visibility: On the next boot, Gentoo's dracut (unless manually tuned with the 95fsck module) doesn't have the tools to fix these orphans in the quiet pre-boot phase. Instead, the kernel finds them after it has already initialized the console, forcing a Notice level print to your screen despite the quiet flag, because the kernel considers a Filesystem Modified event a higher priority than a standard boot message.

Summary: Arch successfully kills everything and goes RO before the lights go out; Gentoo is leaving the door cracked, and you're seeing the kernel sweep the floor on the way back in.

THANKS 👍

[0pLuS0]

I went back further testing it, by installing two more times, this time on systemd/desktop profiles.

I also checked and formatted over the partitions in gparted.

These things made no changes...

My hardware is good, for whatever reasons, this just does not work for me in Gentoo using a Samsung 990 Pro 2TB.