[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20251203182639.3037-3-mrocha@turretllc.us>
Date: Wed, 3 Dec 2025 12:26:41 -0600
From: Mason Rocha <mrocha@...retllc.us>
To: linux-fsdevel@...r.kernel.org,
torvalds@...ux-foundation.org
Cc: viro@...iv.linux.org.uk,
brauner@...nel.org,
linux-kernel@...r.kernel.org,
jack@...e.cz,
Mason Rocha <mrocha@...retllc.us>
Subject: [RFC PATCH] init/mount: allow searching initramfs for init process
Currently, we initiate a kernal panic if the initramfs does not have /init and
if root= is either not specified or does not equal a valid specifier. If root=
is specified and initramfs' /init is missing, provided rdinit or init is not
set, we check and try to execute /sbin/init, /etc/init, /bin/init, and then
finally /bin/sh.
The original functionality of initiating a kernel panic was v0 linux, a time
when we had no initramfs. This has since become outdated as it is possible for
us to, for instance, embed busybox into a kernel so if a userspace process fails
in generating the initramfs and the user fails to catch this error there is
still a way for the recovery of the system without the use of install media.
Unfortunately, this means that even if the initramfs holds some valid init
process (such as /sbin/init, or even /bin/sh) and the kernel isn't able to mount
root, instead of trying to run these processes, for the same reason why we try
to run /bin/sh in the above scenario, in which to allow for the user to recover,
the kernel simply panics. This, in my experience, is a headache and a half as
you have to perform a system reset alongside changing the kernel command line
(which could be an issue in some embedded systems or with a unified kernel image).
Below is an incredibly elementary patch simply changing the panics to printks.
This is not the best course of action, as this change leads to the following in
the klog, which could be changed to reflect the new state more accurately:
[ 2.946841] /dev/root: Can't open blockdev
[ 2.949068] VFS: Cannot open root device "" or unknown-block(0,0): error -6
[ 2.949626] Please append a correct "root=" boot option; here are the available partitions:
[ 2.951352] 0b00 1048575 sr0
[ 2.951639] driver: sr
[ 2.952573] List of all bdev filesystems:
[ 2.953063] ext3
[ 2.953125] ext2
[ 2.953302] ext4
[ 2.953493]
[ 2.953797] VFS: Unable to mount root fs on unknown-block(0,0)
[ 3.450296] Run /sbin/init as init process
[ 3.452139] Run /etc/init as init process
[ 3.452728] Run /bin/init as init process
[ 3.453529] Run /bin/sh as init process
I think it would be beneficial if we were to remove the messages printed for
root not being specified on the kernel command line if we were to allow
continuing the boot process with root not specified, and maintain the messages
if root is specified but cannot be found (ie, if a disk is loaded into a
different system and root=sda instead of root=UUID=), to make obvious the error.
Comments?
Signed-off-by: Mason Rocha <mrocha@...retllc.us>
---
init/do_mounts.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 64d5e25a2..6234c4a2c 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -234,7 +234,8 @@ void __init mount_root_generic(char *name, char *pretty_name, int flags)
pr_err("\n");
}
- panic("VFS: Unable to mount root fs on %s", b);
+ printk("VFS: Unable to mount root fs on %s", b);
+ goto out;
}
if (!(flags & SB_RDONLY)) {
flags |= SB_RDONLY;
@@ -247,7 +248,7 @@ void __init mount_root_generic(char *name, char *pretty_name, int flags)
for (i = 0, p = fs_names; i < num_fs; i++, p += strlen(p)+1)
printk(" %s", p);
printk("\n");
- panic("VFS: Unable to mount root fs on \"%s\" or %s", pretty_name, b);
+ printk("VFS: Unable to mount root fs on \"%s\" or %s", pretty_name, b);
out:
put_page(page);
}
--
2.51.0
Powered by blists - more mailing lists