Hi again,
I played around a little and it seems like the following patch fixes the
issue. It may be related to the following series, marking some of these
functions __init:
https://patchwork.kernel.org/project/linux-fsdevel/list/?series=325591=%2A=both
diff --git a/init/main.c b/init/main.c
index f141c69186bf..13df9fb8855e 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1573,14 +1573,13 @@ static int __ref kernel_init(void *unused)
void __init console_on_rootfs(void)
{
#ifndef CONFIG_BLK_DEV_INITRD
- /*
-* Use /dev/console to infer if the rootfs is setup properly.
-* In case of initrd or initramfs /dev/console might be instantiated
-* later by /init so don't do this check for CONFIG_BLK_DEV_INITRD
-*/
- struct kstat console_stat;
- if (vfs_lstat((char __user *) "/dev/console", (struct kstat __user *)
_stat)
- || !S_ISCHR(console_stat.mode)) {
+ /*
+* Use /dev/console to infer if the rootfs is setup properly.
+* In case of initrd or initramfs /dev/console might be instantiated
+* later by /init so don't do this check for CONFIG_BLK_DEV_INITRD
+*/
+ struct kstat stat;
+ if (init_stat("/dev/console", , 0) || !S_ISCHR(stat.mode)) {
panic("/dev/console is missing or not a character device!\nPlease
ensure your rootfs is properly configured\n");
}
#endif
On 11/4/22 14:22, Bruce Ashfield wrote:
On Fri, Nov 4, 2022 at 6:30 AM Sven Schwermer > wrote:
Hi,
We're in the process of migrating from dunfell to kirkstone and noticed
a regression with the Linux kernel (branch: v5.15/standard/base). The
boot panics with
[ 1.038015] Kernel panic - not syncing: /dev/console is missing!
[ 1.038015] Please ensure your rootfs is properly configured
I have bisected the revisions between the good dunfell one and the bad
kirkstone one and the offending commit is:
0d7260ad7106 check console device file on fs when booting
the commit itself hasn't changed between those releases and kernel
versions, so it very well could be something else in the kernel or in
the generation of the rootfs that is now triggering the commit to change.
The logic for the change is documented in the patch itself. We were
getting a lot (5 or more a week) questions (and blaming of the
kernel) when badly created rootfs were being booted. They all had
mangled /dev/console devices, and fixing that, fixed the boot. It was
much easier to just check and fail with a clearer message than the
other issues that happen down the boot process and that are much
more cryptic to debug.
The weird thing is that vfs_lstat() fails while the subsequent
filp_open() in on the same file succeeds. I'm booting without
initramfs/initrd and with automounted devtmpfs:
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_BLK_DEV_INITRD is not set
Since this commit is not part of upstream Linux, I thought I'd ask for
help here. What's the purpose of this extra check and why is it failing
even though /dev/console exists (filp_open("dev/console") works)?
That same check isn't failing in anything I've run, or the release process
has run (but a non initrd boot isn't as common, so it isn't impossible that
something slipped through).
If there's a set of public layers that I can use to reproduce the problem,
I can have a closer look. But it will be just me digging into the vfs_lstat
call to see if we are now misinterpreting the return from the routine, etc.
Bruce
Best regards,
Sven
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11846):
https://lists.yoctoproject.org/g/linux-yocto/message/11846
Mute This Topic: https://lists.yoctoproject.org/mt/94802745/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
