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.
© 2016 - 2026 Red Hat, Inc.