pivot_root()? [LWN.net]

pivot_root()?

Posted Mar 13, 2026 20:49 UTC (Fri) by jbroadus (subscriber, #115605)
In reply to: pivot_root()? by pabs
Parent article: Practical uses for a null filesystem

Brief explanation in the patch cover letter:

"Currently pivot_root() doesn't work on the real rootfs because it cannot be unmounted. Userspace has to do a recursive removal of the
initramfs contents manually before continuing the boot."

So maybe picot_root() could be modified but wouldn't know how to clean up the old filesystem?

to post comments

pivot_root()?

Posted Mar 13, 2026 22:26 UTC (Fri) by Nikratio (subscriber, #71966) [Link] (6 responses)

I'm confused by this as well. The manpage quote says "The rootfs (initial ramfs) cannot be pivot_root()ed" and the cover letter says that "pivot_root() doesn't work on the real rootfs". So it seems there are cases where pivot_root does work - namely when the root filesystem is not of type rootfs but something like ext3. Is that true? If so, then what makes rootfs so different that pivot_root can't work there? And wouldn't it be easier to just fix that instead of them nullfs workaround?

pivot_root()?

Posted Mar 14, 2026 0:06 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (3 responses)

My (possibly wrong) interpretation is that this is not a filesystem-level restriction, but a mounting restriction. In other words, the problem is not that there's some specific "rootfs" filesystem that is unable to be pivoted. Rather, the problem is that, post-boot, the mount system is unable to represent a state where nothing is mounted. Presumably, the pivot_root() syscall would need to transition through such a state, and working around this limitation is either impossible or not worth the complexity.

But this is pure guesswork on my part.

pivot_root()?

Posted Mar 14, 2026 5:07 UTC (Sat) by intelfx (subscriber, #130118) [Link]

Another guesswork-grade interpretation is that the "real rootfs" is declared and/or constructed statically somewhere within Linux, and simply cannot be destroyed as a conseqence of that.

But I am indeed confused as well by this limitation. Surely removing the underlying cause would have been easier than switching the entire mechanism to use nullfs.

pivot_root()?

Posted Mar 14, 2026 13:54 UTC (Sat) by Nikratio (subscriber, #71966) [Link] (1 responses)

> My (possibly wrong) interpretation is that this is not a filesystem-level restriction, but a mounting restriction. In other words, the problem is not that there's some specific "rootfs" filesystem that is unable to be pivoted. Rather, the problem is that, post-boot, the mount system is unable to represent a state where nothing is mounted. Presumably, the pivot_root() syscall would need to transition through such a state, and working around this limitation is either impossible or not worth the complexity.

I think that interpretation boils down to "the pivot _root system call fundamentally does not work", since pivoting ing the root filesystem is the one and only thing this system call is supposed to do. I highly doubt this would have been added if it never works.

pivot_root()?

Posted Mar 16, 2026 17:41 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

Per the man page, it changes the root filesystem *for the current mount namespace.* As described under NOTES, this is primarily useful for setting up containers. It was at one point also used during boot, but this is (apparently) no longer possible.

pivot_root()?

Posted Mar 16, 2026 13:55 UTC (Mon) by abatters (✭ supporter ✭, #6932) [Link] (1 responses)

I believe pivot_root() was used with the old-style initrd, but it doesn't work with the new-style initramfs. See initrd(4). Note that the old initrd code is being removed: https://lwn.net/Articles/1057769/

pivot_root()?

Posted Jun 15, 2026 7:06 UTC (Mon) by maxfragg (subscriber, #122266) [Link]

that is correct.
the central issue is, that initramfs isn't truly a filesystem, but rather a way to populate the fs-cache without underlying backing filesystem/blockdevice.
Its an elegant hack that doesn't create a real mountpoint, so you can't pivot it out of the way.
initrd was actually creating a filesystem, but needed way more code to support it, so you could pivot away from it.
The issue isn't about the first real filesystem, but about the fact that initramfs creates a world before, without any true filesystem/mountpoint.