.../driver-api/early-userspace/buffer-format.rst | 60 +++++++++++++- fs/init.c | 23 +++++- include/linux/init_syscalls.h | 3 +- init/do_mounts.c | 17 +--- init/initramfs.c | 95 +++++++++++++++++++++- 5 files changed, 175 insertions(+), 23 deletions(-)
At Plumber's 2024, Lennart Poettering of the systemd project requested
the ability to overmount the rootfs with a separate tmpfs before
initramfs expansion, so the populated tmpfs can be unmounted.
This patchset takes this request and goes one step further: it allows
(mostly) arbitrary filesystems mounts during initramfs processing.
This is done by having the initramfs expansion code detect the special
filename "!!!MOUNT!!!" which is then parsed into a simplified
fstab-type mount specification and the directory in which the
!!!MOUNT!!! entry is used as the mount point.
This specific method was chosen for the following reasons:
1. This information is specific to the expectations of the initramfs;
therefore using kernel command line options is not
appropriate. This way the information is fully contained within the
initramfs itself.
2. The sequence !!! is already special in cpio, due to the "TRAILER!!!"
entries.
3. The filename "!!!MOUNT!!!" will typically be sorted first, which
means using standard find+cpio tools to create the initramfs still
work.
4. Similarly, standard cpio can still expand the initramfs.
5. If run on a legacy kernel, the !!!MOUNT!!! file is created, which
is easy to detect in the initramfs code which can then activate
some fallback code.
6. It allows for multiple filesystems to be mounted, possibly of
different types and in different locations, e.g. the initramfs can
get started with /dev, /proc, and /sys already booted.
The patches are:
1/3: fs/init: move creating the mount data_page into init_mount()
2/3: initramfs: support mounting filesystems during initramfs expansion
3/3: Documentation/initramfs: document mount points in initramfs
---
.../driver-api/early-userspace/buffer-format.rst | 60 +++++++++++++-
fs/init.c | 23 +++++-
include/linux/init_syscalls.h | 3 +-
init/do_mounts.c | 17 +---
init/initramfs.c | 95 +++++++++++++++++++++-
5 files changed, 175 insertions(+), 23 deletions(-)
Hi! I wonder: wouldn't it be nicer to use a subdirectory like ".systemd-magic" to place such magic files there that are interpreted by systemd? Then "!!!MOUNT!!!" would become a simple "mount" or maybe "fstab" or "mountttab", ... Kind regards, Ulrich Windl > -----Original Message----- > From: systemd-devel <systemd-devel-bounces@lists.freedesktop.org> On > Behalf Of H. Peter Anvin > Sent: Saturday, January 24, 2026 1:40 AM > To: Alexander Viro <viro@zeniv.linux.org.uk>; Christian Brauner > <brauner@kernel.org>; Jan Kara <jack@suse.cz>; Jonathan Corbet > <corbet@lwn.net>; H. Peter Anvin <hpa@zytor.com> > Cc: linux-fsdevel@vger.kernel.org; linux-doc@vger.kernel.org; linux- > kernel@vger.kernel.org; Lennart Poettering <lennart@poettering.net>; > systemd-devel@lists.freedesktop.org > Subject: [EXT] [systemd-devel] [PATCH 0/3] Add the ability to mount > filesystems during initramfs expansion > > > At Plumber's 2024, Lennart Poettering of the systemd project requested > the ability to overmount the rootfs with a separate tmpfs before > initramfs expansion, so the populated tmpfs can be unmounted. > > This patchset takes this request and goes one step further: it allows > (mostly) arbitrary filesystems mounts during initramfs processing. > > This is done by having the initramfs expansion code detect the special > filename "!!!MOUNT!!!" which is then parsed into a simplified > fstab-type mount specification and the directory in which the > !!!MOUNT!!! entry is used as the mount point. > > This specific method was chosen for the following reasons: > > 1. This information is specific to the expectations of the initramfs; > therefore using kernel command line options is not > appropriate. This way the information is fully contained within the > initramfs itself. > 2. The sequence !!! is already special in cpio, due to the "TRAILER!!!" > entries. > 3. The filename "!!!MOUNT!!!" will typically be sorted first, which > means using standard find+cpio tools to create the initramfs still > work. > 4. Similarly, standard cpio can still expand the initramfs. > 5. If run on a legacy kernel, the !!!MOUNT!!! file is created, which > is easy to detect in the initramfs code which can then activate > some fallback code. > 6. It allows for multiple filesystems to be mounted, possibly of > different types and in different locations, e.g. the initramfs can > get started with /dev, /proc, and /sys already booted. > > The patches are: > > 1/3: fs/init: move creating the mount data_page into init_mount() > 2/3: initramfs: support mounting filesystems during initramfs expansion > 3/3: Documentation/initramfs: document mount points in initramfs > > --- > .../driver-api/early-userspace/buffer-format.rst | 60 +++++++++++++- > fs/init.c | 23 +++++- > include/linux/init_syscalls.h | 3 +- > init/do_mounts.c | 17 +--- > init/initramfs.c | 95 +++++++++++++++++++++- > 5 files changed, 175 insertions(+), 23 deletions(-)
On February 1, 2026 11:38:23 PM PST, "Windl, Ulrich" <u.windl@ukr.de> wrote: >Hi! > >I wonder: wouldn't it be nicer to use a subdirectory like ".systemd-magic" to place such magic files there that are interpreted by systemd? Then "!!!MOUNT!!!" would become a simple "mount" or maybe "fstab" or "mountttab", ... > >Kind regards, >Ulrich Windl > >> -----Original Message----- >> From: systemd-devel <systemd-devel-bounces@lists.freedesktop.org> On >> Behalf Of H. Peter Anvin >> Sent: Saturday, January 24, 2026 1:40 AM >> To: Alexander Viro <viro@zeniv.linux.org.uk>; Christian Brauner >> <brauner@kernel.org>; Jan Kara <jack@suse.cz>; Jonathan Corbet >> <corbet@lwn.net>; H. Peter Anvin <hpa@zytor.com> >> Cc: linux-fsdevel@vger.kernel.org; linux-doc@vger.kernel.org; linux- >> kernel@vger.kernel.org; Lennart Poettering <lennart@poettering.net>; >> systemd-devel@lists.freedesktop.org >> Subject: [EXT] [systemd-devel] [PATCH 0/3] Add the ability to mount >> filesystems during initramfs expansion >> >> >> At Plumber's 2024, Lennart Poettering of the systemd project requested >> the ability to overmount the rootfs with a separate tmpfs before >> initramfs expansion, so the populated tmpfs can be unmounted. >> >> This patchset takes this request and goes one step further: it allows >> (mostly) arbitrary filesystems mounts during initramfs processing. >> >> This is done by having the initramfs expansion code detect the special >> filename "!!!MOUNT!!!" which is then parsed into a simplified >> fstab-type mount specification and the directory in which the >> !!!MOUNT!!! entry is used as the mount point. >> >> This specific method was chosen for the following reasons: >> >> 1. This information is specific to the expectations of the initramfs; >> therefore using kernel command line options is not >> appropriate. This way the information is fully contained within the >> initramfs itself. >> 2. The sequence !!! is already special in cpio, due to the "TRAILER!!!" >> entries. >> 3. The filename "!!!MOUNT!!!" will typically be sorted first, which >> means using standard find+cpio tools to create the initramfs still >> work. >> 4. Similarly, standard cpio can still expand the initramfs. >> 5. If run on a legacy kernel, the !!!MOUNT!!! file is created, which >> is easy to detect in the initramfs code which can then activate >> some fallback code. >> 6. It allows for multiple filesystems to be mounted, possibly of >> different types and in different locations, e.g. the initramfs can >> get started with /dev, /proc, and /sys already booted. >> >> The patches are: >> >> 1/3: fs/init: move creating the mount data_page into init_mount() >> 2/3: initramfs: support mounting filesystems during initramfs expansion >> 3/3: Documentation/initramfs: document mount points in initramfs >> >> --- >> .../driver-api/early-userspace/buffer-format.rst | 60 +++++++++++++- >> fs/init.c | 23 +++++- >> include/linux/init_syscalls.h | 3 +- >> init/do_mounts.c | 17 +--- >> init/initramfs.c | 95 +++++++++++++++++++++- >> 5 files changed, 175 insertions(+), 23 deletions(-) > The point is that this is done during initramfs deencapsulation. Either way, it doesn't seem like there is interest.
"H. Peter Anvin" <hpa@zytor.com>: > At Plumber's 2024, Lennart Poettering of the systemd project requested > the ability to overmount the rootfs with a separate tmpfs before > initramfs expansion, so the populated tmpfs can be unmounted. This is already solved by [1] and [2]. They are in next. [1] https://lore.kernel.org/all/20251229-work-empty-namespace-v1-0-bfb24c7b061f@kernel.org/ [2] https://lore.kernel.org/all/20260112-work-immutable-rootfs-v2-0-88dd1c34a204@kernel.org/ -- Askar Safin
On 2026-01-24 09:41, Askar Safin wrote: > "H. Peter Anvin" <hpa@zytor.com>: >> At Plumber's 2024, Lennart Poettering of the systemd project requested >> the ability to overmount the rootfs with a separate tmpfs before >> initramfs expansion, so the populated tmpfs can be unmounted. > > This is already solved by [1] and [2]. They are in next. > > [1] https://lore.kernel.org/all/20251229-work-empty-namespace-v1-0-bfb24c7b061f@kernel.org/ > [2] https://lore.kernel.org/all/20260112-work-immutable-rootfs-v2-0-88dd1c34a204@kernel.org/ > Just to make it clear: unless someone feels there is value in this feature regardless of the above, there is no need for this patchset. -hpa
On January 24, 2026 9:41:50 AM PST, Askar Safin <safinaskar@gmail.com> wrote: >"H. Peter Anvin" <hpa@zytor.com>: >> At Plumber's 2024, Lennart Poettering of the systemd project requested >> the ability to overmount the rootfs with a separate tmpfs before >> initramfs expansion, so the populated tmpfs can be unmounted. > >This is already solved by [1] and [2]. They are in next. > >[1] https://lore.kernel.org/all/20251229-work-empty-namespace-v1-0-bfb24c7b061f@kernel.org/ >[2] https://lore.kernel.org/all/20260112-work-immutable-rootfs-v2-0-88dd1c34a204@kernel.org/ > Well, all right then :)
© 2016 - 2026 Red Hat, Inc.