[PATCH] init: Handle bootloader head in kernel parameters

[PATCH] init: Handle bootloader head in kernel parameters

[Huacai Chen]

BootLoader may pass a head such as "BOOT_IMAGE=/boot/vmlinuz-x.y.z" to
kernel parameters. But this head is not recognized by the kernel so will
be passed to user space. However, user space init program also doesn't
recognized it.

KEXEC may also pass a head such as "kexec" on some architectures.

So the the best way is handle it by the kernel itself, which can avoid
such boot warnings:

Kernel command line: BOOT_IMAGE=(hd0,1)/vmlinuz-6.x root=/dev/sda3 ro console=tty
Unknown kernel command line parameters "BOOT_IMAGE=(hd0,1)/vmlinuz-6.x", will be passed to user space.

Cc: stable@vger.kernel.org
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
---
 init/main.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/init/main.c b/init/main.c
index 225a58279acd..9e0a7e8913c0 100644
--- a/init/main.c
+++ b/init/main.c
@@ -545,6 +545,7 @@ static int __init unknown_bootoption(char *param, char *val,
 				     const char *unused, void *arg)
 {
 	size_t len = strlen(param);
+	const char *bootloader[] = { "BOOT_IMAGE", "kexec", NULL };
 
 	/* Handle params aliased to sysctls */
 	if (sysctl_is_alias(param))
@@ -552,6 +553,12 @@ static int __init unknown_bootoption(char *param, char *val,
 
 	repair_env_string(param, val);
 
+	/* Handle bootloader head */
+	for (int i = 0; bootloader[i]; i++) {
+		if (!strncmp(param, bootloader[i], strlen(bootloader[i])))
+			return 0;
+	}
+
 	/* Handle obsolete-style parameters */
 	if (obsolete_checksetup(param))
 		return 0;
-- 
2.47.1

Re: [PATCH] init: Handle bootloader head in kernel parameters

[Greg KH]

On Fri, Jul 11, 2025 at 06:24:55PM +0800, Huacai Chen wrote:
> BootLoader may pass a head such as "BOOT_IMAGE=/boot/vmlinuz-x.y.z" to
> kernel parameters. But this head is not recognized by the kernel so will
> be passed to user space. However, user space init program also doesn't
> recognized it.

Then why is it on the kernel command line if it is not recognized?

> KEXEC may also pass a head such as "kexec" on some architectures.

That's fine, kexec needs this.

> So the the best way is handle it by the kernel itself, which can avoid
> such boot warnings:
> 
> Kernel command line: BOOT_IMAGE=(hd0,1)/vmlinuz-6.x root=/dev/sda3 ro console=tty
> Unknown kernel command line parameters "BOOT_IMAGE=(hd0,1)/vmlinuz-6.x", will be passed to user space.

Why is this a problem?  Don't put stuff that is not needed on the kernel
command line :)

> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> ---
>  init/main.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/init/main.c b/init/main.c
> index 225a58279acd..9e0a7e8913c0 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -545,6 +545,7 @@ static int __init unknown_bootoption(char *param, char *val,
>  				     const char *unused, void *arg)
>  {
>  	size_t len = strlen(param);
> +	const char *bootloader[] = { "BOOT_IMAGE", "kexec", NULL };

You need to document why these are ok to "swallow" and not warn for.


>  
>  	/* Handle params aliased to sysctls */
>  	if (sysctl_is_alias(param))
> @@ -552,6 +553,12 @@ static int __init unknown_bootoption(char *param, char *val,
>  
>  	repair_env_string(param, val);
>  
> +	/* Handle bootloader head */

Handle it how?

confused,

greg k-h

Re: [PATCH] init: Handle bootloader head in kernel parameters

[Huacai Chen]

Hi, Greg,

On Fri, Jul 11, 2025 at 7:06 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Jul 11, 2025 at 06:24:55PM +0800, Huacai Chen wrote:
> > BootLoader may pass a head such as "BOOT_IMAGE=/boot/vmlinuz-x.y.z" to
> > kernel parameters. But this head is not recognized by the kernel so will
> > be passed to user space. However, user space init program also doesn't
> > recognized it.
>
> Then why is it on the kernel command line if it is not recognized?
UEFI put it at the beginning of the command line, you can see it from
/proc/cmdline, both on x86 and LoongArch.

>
> > KEXEC may also pass a head such as "kexec" on some architectures.
>
> That's fine, kexec needs this.
>
> > So the the best way is handle it by the kernel itself, which can avoid
> > such boot warnings:
> >
> > Kernel command line: BOOT_IMAGE=(hd0,1)/vmlinuz-6.x root=/dev/sda3 ro console=tty
> > Unknown kernel command line parameters "BOOT_IMAGE=(hd0,1)/vmlinuz-6.x", will be passed to user space.
>
> Why is this a problem?  Don't put stuff that is not needed on the kernel
> command line :)
Both kernel and user space don't need it, and if it is passed to user
space then may cause some problems. For example, if there is
init=/bin/bash, then bash will crash with this parameter.

>
> >
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > ---
> >  init/main.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/init/main.c b/init/main.c
> > index 225a58279acd..9e0a7e8913c0 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -545,6 +545,7 @@ static int __init unknown_bootoption(char *param, char *val,
> >                                    const char *unused, void *arg)
> >  {
> >       size_t len = strlen(param);
> > +     const char *bootloader[] = { "BOOT_IMAGE", "kexec", NULL };
>
> You need to document why these are ok to "swallow" and not warn for.
Because they are bootloader heads, not really a wrong parameter. We
only need a warning if there is a wrong parameter.

>
>
> >
> >       /* Handle params aliased to sysctls */
> >       if (sysctl_is_alias(param))
> > @@ -552,6 +553,12 @@ static int __init unknown_bootoption(char *param, char *val,
> >
> >       repair_env_string(param, val);
> >
> > +     /* Handle bootloader head */
>
> Handle it how?
argv_init and envp_init arrays will be passed to userspace, so just
return early (before argv_init and envp_init handling) can avoid it
being passed.

Huacai

>
> confused,
>
> greg k-h

Re: [PATCH] init: Handle bootloader head in kernel parameters

[Greg KH]

On Fri, Jul 11, 2025 at 08:34:25PM +0800, Huacai Chen wrote:
> Hi, Greg,
> 
> On Fri, Jul 11, 2025 at 7:06 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Jul 11, 2025 at 06:24:55PM +0800, Huacai Chen wrote:
> > > BootLoader may pass a head such as "BOOT_IMAGE=/boot/vmlinuz-x.y.z" to
> > > kernel parameters. But this head is not recognized by the kernel so will
> > > be passed to user space. However, user space init program also doesn't
> > > recognized it.
> >
> > Then why is it on the kernel command line if it is not recognized?
> UEFI put it at the beginning of the command line, you can see it from
> /proc/cmdline, both on x86 and LoongArch.

Then fix UEFI :)

My boot command line doesn't have that on x86, perhaps you need to fix
your bootloader?

> > > KEXEC may also pass a head such as "kexec" on some architectures.
> >
> > That's fine, kexec needs this.
> >
> > > So the the best way is handle it by the kernel itself, which can avoid
> > > such boot warnings:
> > >
> > > Kernel command line: BOOT_IMAGE=(hd0,1)/vmlinuz-6.x root=/dev/sda3 ro console=tty
> > > Unknown kernel command line parameters "BOOT_IMAGE=(hd0,1)/vmlinuz-6.x", will be passed to user space.
> >
> > Why is this a problem?  Don't put stuff that is not needed on the kernel
> > command line :)
> Both kernel and user space don't need it, and if it is passed to user
> space then may cause some problems. For example, if there is
> init=/bin/bash, then bash will crash with this parameter.

Again, fix the bootloader to not do this, why is the kernel responsible
for this?

What has suddenly changed to now require this when we never have needed
it before?

> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > ---
> > >  init/main.c | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/init/main.c b/init/main.c
> > > index 225a58279acd..9e0a7e8913c0 100644
> > > --- a/init/main.c
> > > +++ b/init/main.c
> > > @@ -545,6 +545,7 @@ static int __init unknown_bootoption(char *param, char *val,
> > >                                    const char *unused, void *arg)
> > >  {
> > >       size_t len = strlen(param);
> > > +     const char *bootloader[] = { "BOOT_IMAGE", "kexec", NULL };
> >
> > You need to document why these are ok to "swallow" and not warn for.
> Because they are bootloader heads, not really a wrong parameter. We
> only need a warning if there is a wrong parameter.

Again, fix the bootloader.

> > >
> > >       /* Handle params aliased to sysctls */
> > >       if (sysctl_is_alias(param))
> > > @@ -552,6 +553,12 @@ static int __init unknown_bootoption(char *param, char *val,
> > >
> > >       repair_env_string(param, val);
> > >
> > > +     /* Handle bootloader head */
> >
> > Handle it how?
> argv_init and envp_init arrays will be passed to userspace, so just
> return early (before argv_init and envp_init handling) can avoid it
> being passed.

You need to document this way better.

But again, please just fix your bootloader to not pass on lines to the
kernel that it can not parse.

thanks,

greg k-h

Re: [PATCH] init: Handle bootloader head in kernel parameters

[Huacai Chen]

On Fri, Jul 11, 2025 at 8:41 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Jul 11, 2025 at 08:34:25PM +0800, Huacai Chen wrote:
> > Hi, Greg,
> >
> > On Fri, Jul 11, 2025 at 7:06 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Fri, Jul 11, 2025 at 06:24:55PM +0800, Huacai Chen wrote:
> > > > BootLoader may pass a head such as "BOOT_IMAGE=/boot/vmlinuz-x.y.z" to
> > > > kernel parameters. But this head is not recognized by the kernel so will
> > > > be passed to user space. However, user space init program also doesn't
> > > > recognized it.
> > >
> > > Then why is it on the kernel command line if it is not recognized?
> > UEFI put it at the beginning of the command line, you can see it from
> > /proc/cmdline, both on x86 and LoongArch.
>
> Then fix UEFI :)
>
> My boot command line doesn't have that on x86, perhaps you need to fix
> your bootloader?
Not only UEFI, Grub also do this, for many years, not now. I don't
know why they do this, but I think at least it is not a bug. For
example, maybe it just tells user the path of kernel image via
/proc/cmdline.

[chenhuacai@kernelserver linux-official.git]$ uname -a
Linux kernelserver 6.12.0-84.el10.x86_64 #1 SMP PREEMPT_DYNAMIC Tue
May 13 13:39:02 UTC 2025 x86_64 GNU/Linux
[chenhuacai@kernelserver linux-official.git]$ cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.12.0-84.el10.x86_64
root=UUID=c8fcb11a-0f2f-48e5-a067-4cec1d18a721 ro
crashkernel=2G-64G:256M,64G-:512M
resume=UUID=1c320fec-3274-4b5b-9adf-a06
42e7943c0 rhgb quiet

>
> > > > KEXEC may also pass a head such as "kexec" on some architectures.
> > >
> > > That's fine, kexec needs this.
> > >
> > > > So the the best way is handle it by the kernel itself, which can avoid
> > > > such boot warnings:
> > > >
> > > > Kernel command line: BOOT_IMAGE=(hd0,1)/vmlinuz-6.x root=/dev/sda3 ro console=tty
> > > > Unknown kernel command line parameters "BOOT_IMAGE=(hd0,1)/vmlinuz-6.x", will be passed to user space.
> > >
> > > Why is this a problem?  Don't put stuff that is not needed on the kernel
> > > command line :)
> > Both kernel and user space don't need it, and if it is passed to user
> > space then may cause some problems. For example, if there is
> > init=/bin/bash, then bash will crash with this parameter.
>
> Again, fix the bootloader to not do this, why is the kernel responsible
> for this?
>
> What has suddenly changed to now require this when we never have needed
> it before?
Because init=/bin/bash is not a usual use case, so in most cases it is
just a warning in dmesg. But once we see it, we need to fix it.

>
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > > ---
> > > >  init/main.c | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/init/main.c b/init/main.c
> > > > index 225a58279acd..9e0a7e8913c0 100644
> > > > --- a/init/main.c
> > > > +++ b/init/main.c
> > > > @@ -545,6 +545,7 @@ static int __init unknown_bootoption(char *param, char *val,
> > > >                                    const char *unused, void *arg)
> > > >  {
> > > >       size_t len = strlen(param);
> > > > +     const char *bootloader[] = { "BOOT_IMAGE", "kexec", NULL };
> > >
> > > You need to document why these are ok to "swallow" and not warn for.
> > Because they are bootloader heads, not really a wrong parameter. We
> > only need a warning if there is a wrong parameter.
>
> Again, fix the bootloader.
But I don't think this is a bootloader bug.

>
> > > >
> > > >       /* Handle params aliased to sysctls */
> > > >       if (sysctl_is_alias(param))
> > > > @@ -552,6 +553,12 @@ static int __init unknown_bootoption(char *param, char *val,
> > > >
> > > >       repair_env_string(param, val);
> > > >
> > > > +     /* Handle bootloader head */
> > >
> > > Handle it how?
> > argv_init and envp_init arrays will be passed to userspace, so just
> > return early (before argv_init and envp_init handling) can avoid it
> > being passed.
>
> You need to document this way better.
>
> But again, please just fix your bootloader to not pass on lines to the
> kernel that it can not parse.
OK, I will update the document, but again, I don't think this is a
bootloader bug.

Huacai

>
> thanks,
>
> greg k-h

Re: [PATCH] init: Handle bootloader head in kernel parameters

[Greg KH]

On Fri, Jul 11, 2025 at 08:51:28PM +0800, Huacai Chen wrote:
> On Fri, Jul 11, 2025 at 8:41 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Jul 11, 2025 at 08:34:25PM +0800, Huacai Chen wrote:
> > > Hi, Greg,
> > >
> > > On Fri, Jul 11, 2025 at 7:06 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Fri, Jul 11, 2025 at 06:24:55PM +0800, Huacai Chen wrote:
> > > > > BootLoader may pass a head such as "BOOT_IMAGE=/boot/vmlinuz-x.y.z" to
> > > > > kernel parameters. But this head is not recognized by the kernel so will
> > > > > be passed to user space. However, user space init program also doesn't
> > > > > recognized it.
> > > >
> > > > Then why is it on the kernel command line if it is not recognized?
> > > UEFI put it at the beginning of the command line, you can see it from
> > > /proc/cmdline, both on x86 and LoongArch.
> >
> > Then fix UEFI :)
> >
> > My boot command line doesn't have that on x86, perhaps you need to fix
> > your bootloader?
> Not only UEFI, Grub also do this, for many years, not now. I don't
> know why they do this, but I think at least it is not a bug. For
> example, maybe it just tells user the path of kernel image via
> /proc/cmdline.
> 
> [chenhuacai@kernelserver linux-official.git]$ uname -a
> Linux kernelserver 6.12.0-84.el10.x86_64 #1 SMP PREEMPT_DYNAMIC Tue
> May 13 13:39:02 UTC 2025 x86_64 GNU/Linux
> [chenhuacai@kernelserver linux-official.git]$ cat /proc/cmdline
> BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.12.0-84.el10.x86_64
> root=UUID=c8fcb11a-0f2f-48e5-a067-4cec1d18a721 ro
> crashkernel=2G-64G:256M,64G-:512M
> resume=UUID=1c320fec-3274-4b5b-9adf-a06
> 42e7943c0 rhgb quiet

Sounds like a bootloader bug:

$ cat /proc/cmdline
root=/dev/sda2 rw

I suggest fixing the issue there, at the root please.

> > > > > KEXEC may also pass a head such as "kexec" on some architectures.
> > > >
> > > > That's fine, kexec needs this.
> > > >
> > > > > So the the best way is handle it by the kernel itself, which can avoid
> > > > > such boot warnings:
> > > > >
> > > > > Kernel command line: BOOT_IMAGE=(hd0,1)/vmlinuz-6.x root=/dev/sda3 ro console=tty
> > > > > Unknown kernel command line parameters "BOOT_IMAGE=(hd0,1)/vmlinuz-6.x", will be passed to user space.
> > > >
> > > > Why is this a problem?  Don't put stuff that is not needed on the kernel
> > > > command line :)
> > > Both kernel and user space don't need it, and if it is passed to user
> > > space then may cause some problems. For example, if there is
> > > init=/bin/bash, then bash will crash with this parameter.
> >
> > Again, fix the bootloader to not do this, why is the kernel responsible
> > for this?
> >
> > What has suddenly changed to now require this when we never have needed
> > it before?
> Because init=/bin/bash is not a usual use case, so in most cases it is
> just a warning in dmesg. But once we see it, we need to fix it.

Why is this the kernel's fault?

Again, what changed in the kernel to cause this to happen?  I think you
are seeing bugs in bootloaders, NOT in the kernel.  Fix the issue at the
root, don't paper over the problem in the kernel for something that is
NOT the kernel's fault.

> > > > > Cc: stable@vger.kernel.org
> > > > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > > > ---
> > > > >  init/main.c | 7 +++++++
> > > > >  1 file changed, 7 insertions(+)
> > > > >
> > > > > diff --git a/init/main.c b/init/main.c
> > > > > index 225a58279acd..9e0a7e8913c0 100644
> > > > > --- a/init/main.c
> > > > > +++ b/init/main.c
> > > > > @@ -545,6 +545,7 @@ static int __init unknown_bootoption(char *param, char *val,
> > > > >                                    const char *unused, void *arg)
> > > > >  {
> > > > >       size_t len = strlen(param);
> > > > > +     const char *bootloader[] = { "BOOT_IMAGE", "kexec", NULL };
> > > >
> > > > You need to document why these are ok to "swallow" and not warn for.
> > > Because they are bootloader heads, not really a wrong parameter. We
> > > only need a warning if there is a wrong parameter.
> >
> > Again, fix the bootloader.
> But I don't think this is a bootloader bug.

Seems like it is if nothing changed in the kernel and this just started
showing up now :)

Unless you can find a kernel commit that caused this issue?

thanks,

greg k-h

Re: [PATCH] init: Handle bootloader head in kernel parameters

[Huacai Chen]

On Fri, Jul 11, 2025 at 9:04 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Jul 11, 2025 at 08:51:28PM +0800, Huacai Chen wrote:
> > On Fri, Jul 11, 2025 at 8:41 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Fri, Jul 11, 2025 at 08:34:25PM +0800, Huacai Chen wrote:
> > > > Hi, Greg,
> > > >
> > > > On Fri, Jul 11, 2025 at 7:06 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Fri, Jul 11, 2025 at 06:24:55PM +0800, Huacai Chen wrote:
> > > > > > BootLoader may pass a head such as "BOOT_IMAGE=/boot/vmlinuz-x.y.z" to
> > > > > > kernel parameters. But this head is not recognized by the kernel so will
> > > > > > be passed to user space. However, user space init program also doesn't
> > > > > > recognized it.
> > > > >
> > > > > Then why is it on the kernel command line if it is not recognized?
> > > > UEFI put it at the beginning of the command line, you can see it from
> > > > /proc/cmdline, both on x86 and LoongArch.
> > >
> > > Then fix UEFI :)
> > >
> > > My boot command line doesn't have that on x86, perhaps you need to fix
> > > your bootloader?
> > Not only UEFI, Grub also do this, for many years, not now. I don't
> > know why they do this, but I think at least it is not a bug. For
> > example, maybe it just tells user the path of kernel image via
> > /proc/cmdline.
> >
> > [chenhuacai@kernelserver linux-official.git]$ uname -a
> > Linux kernelserver 6.12.0-84.el10.x86_64 #1 SMP PREEMPT_DYNAMIC Tue
> > May 13 13:39:02 UTC 2025 x86_64 GNU/Linux
> > [chenhuacai@kernelserver linux-official.git]$ cat /proc/cmdline
> > BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.12.0-84.el10.x86_64
> > root=UUID=c8fcb11a-0f2f-48e5-a067-4cec1d18a721 ro
> > crashkernel=2G-64G:256M,64G-:512M
> > resume=UUID=1c320fec-3274-4b5b-9adf-a06
> > 42e7943c0 rhgb quiet
>
> Sounds like a bootloader bug:
>
> $ cat /proc/cmdline
> root=/dev/sda2 rw
>
> I suggest fixing the issue there, at the root please.
Grub pass BOOT_IMAGE for all EFI-based implementations, related commits of Grub:
https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=16ccb8b138218d56875051d547af84410d18f9aa
https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=25953e10553dad2e378541a68686fc094603ec54

Linux kernel treats BOOT_IMAGE as an "offender" of unknown command
line parameters, related commits of kernel:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=86d1919a4fb0d9c115dd1d3b969f5d1650e45408

There are user space projects that search BOOT_IMAGE from /proc/cmdline:
https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/util.go
(search getBootOptions)
https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/main.go
(search getKernelReleaseWithBootOption)

So, we can say Grub pass BOOT_IMAGE is reasonable and there are user
space programs that hope it be in /proc/cmdline.

But BOOT_IMAGE should not be passed to the init program. Strings in
cmdline contain 4 types: BootLoader head (BOOT_IMAGE, kexec, etc.),
kernel parameters, init parameters, wrong parameters.

The first type is handled (ignored) by this patch, the second type is
handled (consumed) by the kernel, and the last two types are passed to
user space.

If the first type is also passed to user space, there are meaningless
warnings, and (maybe) cause problems with the init program.


Huacai

>
> > > > > > KEXEC may also pass a head such as "kexec" on some architectures.
> > > > >
> > > > > That's fine, kexec needs this.
> > > > >
> > > > > > So the the best way is handle it by the kernel itself, which can avoid
> > > > > > such boot warnings:
> > > > > >
> > > > > > Kernel command line: BOOT_IMAGE=(hd0,1)/vmlinuz-6.x root=/dev/sda3 ro console=tty
> > > > > > Unknown kernel command line parameters "BOOT_IMAGE=(hd0,1)/vmlinuz-6.x", will be passed to user space.
> > > > >
> > > > > Why is this a problem?  Don't put stuff that is not needed on the kernel
> > > > > command line :)
> > > > Both kernel and user space don't need it, and if it is passed to user
> > > > space then may cause some problems. For example, if there is
> > > > init=/bin/bash, then bash will crash with this parameter.
> > >
> > > Again, fix the bootloader to not do this, why is the kernel responsible
> > > for this?
> > >
> > > What has suddenly changed to now require this when we never have needed
> > > it before?
> > Because init=/bin/bash is not a usual use case, so in most cases it is
> > just a warning in dmesg. But once we see it, we need to fix it.
>
> Why is this the kernel's fault?
>
> Again, what changed in the kernel to cause this to happen?  I think you
> are seeing bugs in bootloaders, NOT in the kernel.  Fix the issue at the
> root, don't paper over the problem in the kernel for something that is
> NOT the kernel's fault.
>
> > > > > > Cc: stable@vger.kernel.org
> > > > > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > > > > ---
> > > > > >  init/main.c | 7 +++++++
> > > > > >  1 file changed, 7 insertions(+)
> > > > > >
> > > > > > diff --git a/init/main.c b/init/main.c
> > > > > > index 225a58279acd..9e0a7e8913c0 100644
> > > > > > --- a/init/main.c
> > > > > > +++ b/init/main.c
> > > > > > @@ -545,6 +545,7 @@ static int __init unknown_bootoption(char *param, char *val,
> > > > > >                                    const char *unused, void *arg)
> > > > > >  {
> > > > > >       size_t len = strlen(param);
> > > > > > +     const char *bootloader[] = { "BOOT_IMAGE", "kexec", NULL };
> > > > >
> > > > > You need to document why these are ok to "swallow" and not warn for.
> > > > Because they are bootloader heads, not really a wrong parameter. We
> > > > only need a warning if there is a wrong parameter.
> > >
> > > Again, fix the bootloader.
> > But I don't think this is a bootloader bug.
>
> Seems like it is if nothing changed in the kernel and this just started
> showing up now :)
>
> Unless you can find a kernel commit that caused this issue?
>
> thanks,
>
> greg k-h

Re: [PATCH] init: Handle bootloader head in kernel parameters

[Greg KH]

On Sat, Jul 12, 2025 at 11:18:44PM +0800, Huacai Chen wrote:
> On Fri, Jul 11, 2025 at 9:04 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Jul 11, 2025 at 08:51:28PM +0800, Huacai Chen wrote:
> > > On Fri, Jul 11, 2025 at 8:41 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Fri, Jul 11, 2025 at 08:34:25PM +0800, Huacai Chen wrote:
> > > > > Hi, Greg,
> > > > >
> > > > > On Fri, Jul 11, 2025 at 7:06 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Fri, Jul 11, 2025 at 06:24:55PM +0800, Huacai Chen wrote:
> > > > > > > BootLoader may pass a head such as "BOOT_IMAGE=/boot/vmlinuz-x.y.z" to
> > > > > > > kernel parameters. But this head is not recognized by the kernel so will
> > > > > > > be passed to user space. However, user space init program also doesn't
> > > > > > > recognized it.
> > > > > >
> > > > > > Then why is it on the kernel command line if it is not recognized?
> > > > > UEFI put it at the beginning of the command line, you can see it from
> > > > > /proc/cmdline, both on x86 and LoongArch.
> > > >
> > > > Then fix UEFI :)
> > > >
> > > > My boot command line doesn't have that on x86, perhaps you need to fix
> > > > your bootloader?
> > > Not only UEFI, Grub also do this, for many years, not now. I don't
> > > know why they do this, but I think at least it is not a bug. For
> > > example, maybe it just tells user the path of kernel image via
> > > /proc/cmdline.
> > >
> > > [chenhuacai@kernelserver linux-official.git]$ uname -a
> > > Linux kernelserver 6.12.0-84.el10.x86_64 #1 SMP PREEMPT_DYNAMIC Tue
> > > May 13 13:39:02 UTC 2025 x86_64 GNU/Linux
> > > [chenhuacai@kernelserver linux-official.git]$ cat /proc/cmdline
> > > BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.12.0-84.el10.x86_64
> > > root=UUID=c8fcb11a-0f2f-48e5-a067-4cec1d18a721 ro
> > > crashkernel=2G-64G:256M,64G-:512M
> > > resume=UUID=1c320fec-3274-4b5b-9adf-a06
> > > 42e7943c0 rhgb quiet
> >
> > Sounds like a bootloader bug:
> >
> > $ cat /proc/cmdline
> > root=/dev/sda2 rw
> >
> > I suggest fixing the issue there, at the root please.
> Grub pass BOOT_IMAGE for all EFI-based implementations, related commits of Grub:
> https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=16ccb8b138218d56875051d547af84410d18f9aa
> https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=25953e10553dad2e378541a68686fc094603ec54

From 2005 and 2011?  Why have we not had any reports of this being an
issue before now?  What changed in the kernel recently?

> Linux kernel treats BOOT_IMAGE as an "offender" of unknown command
> line parameters, related commits of kernel:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=86d1919a4fb0d9c115dd1d3b969f5d1650e45408

So in 2021 we started printing out command line arguments that were
"wrong", so is this when everyone noticed that grub was wrong?

> There are user space projects that search BOOT_IMAGE from /proc/cmdline:
> https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/util.go
> (search getBootOptions)
> https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/main.go
> (search getKernelReleaseWithBootOption)

What does it use these options for that it can't get from the valid ones
instead?

> So, we can say Grub pass BOOT_IMAGE is reasonable and there are user
> space programs that hope it be in /proc/cmdline.

But who relies on this that never noticed the kernel complaining about
it for the past 4 years?

> But BOOT_IMAGE should not be passed to the init program. Strings in
> cmdline contain 4 types: BootLoader head (BOOT_IMAGE, kexec, etc.),
> kernel parameters, init parameters, wrong parameters.

Then fix grub to not do this.

> The first type is handled (ignored) by this patch, the second type is
> handled (consumed) by the kernel, and the last two types are passed to
> user space.

That's not obvious in this patch at all.  If you are doing different
things, make it separate patches.

And again, fix grub.

> If the first type is also passed to user space, there are meaningless
> warnings, and (maybe) cause problems with the init program.

So it's been causing problems for all these years (i.e. since 2005)?

What changed that is causing this to be an issue now, and again, why not
just fix grub?

thanks,

greg k-h

Re: [PATCH] init: Handle bootloader head in kernel parameters

[Huacai Chen]

On Sun, Jul 13, 2025 at 4:30 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Sat, Jul 12, 2025 at 11:18:44PM +0800, Huacai Chen wrote:
> > On Fri, Jul 11, 2025 at 9:04 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Fri, Jul 11, 2025 at 08:51:28PM +0800, Huacai Chen wrote:
> > > > On Fri, Jul 11, 2025 at 8:41 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Fri, Jul 11, 2025 at 08:34:25PM +0800, Huacai Chen wrote:
> > > > > > Hi, Greg,
> > > > > >
> > > > > > On Fri, Jul 11, 2025 at 7:06 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > On Fri, Jul 11, 2025 at 06:24:55PM +0800, Huacai Chen wrote:
> > > > > > > > BootLoader may pass a head such as "BOOT_IMAGE=/boot/vmlinuz-x.y.z" to
> > > > > > > > kernel parameters. But this head is not recognized by the kernel so will
> > > > > > > > be passed to user space. However, user space init program also doesn't
> > > > > > > > recognized it.
> > > > > > >
> > > > > > > Then why is it on the kernel command line if it is not recognized?
> > > > > > UEFI put it at the beginning of the command line, you can see it from
> > > > > > /proc/cmdline, both on x86 and LoongArch.
> > > > >
> > > > > Then fix UEFI :)
> > > > >
> > > > > My boot command line doesn't have that on x86, perhaps you need to fix
> > > > > your bootloader?
> > > > Not only UEFI, Grub also do this, for many years, not now. I don't
> > > > know why they do this, but I think at least it is not a bug. For
> > > > example, maybe it just tells user the path of kernel image via
> > > > /proc/cmdline.
> > > >
> > > > [chenhuacai@kernelserver linux-official.git]$ uname -a
> > > > Linux kernelserver 6.12.0-84.el10.x86_64 #1 SMP PREEMPT_DYNAMIC Tue
> > > > May 13 13:39:02 UTC 2025 x86_64 GNU/Linux
> > > > [chenhuacai@kernelserver linux-official.git]$ cat /proc/cmdline
> > > > BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.12.0-84.el10.x86_64
> > > > root=UUID=c8fcb11a-0f2f-48e5-a067-4cec1d18a721 ro
> > > > crashkernel=2G-64G:256M,64G-:512M
> > > > resume=UUID=1c320fec-3274-4b5b-9adf-a06
> > > > 42e7943c0 rhgb quiet
> > >
> > > Sounds like a bootloader bug:
> > >
> > > $ cat /proc/cmdline
> > > root=/dev/sda2 rw
> > >
> > > I suggest fixing the issue there, at the root please.
> > Grub pass BOOT_IMAGE for all EFI-based implementations, related commits of Grub:
> > https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=16ccb8b138218d56875051d547af84410d18f9aa
> > https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=25953e10553dad2e378541a68686fc094603ec54
>
> From 2005 and 2011?  Why have we not had any reports of this being an
> issue before now?  What changed in the kernel recently?
As said before, just in some corner cases it causes problems, but
corner case doesn't means nothing.

>
> > Linux kernel treats BOOT_IMAGE as an "offender" of unknown command
> > line parameters, related commits of kernel:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=86d1919a4fb0d9c115dd1d3b969f5d1650e45408
>
> So in 2021 we started printing out command line arguments that were
> "wrong", so is this when everyone noticed that grub was wrong?
Somebody may think a warning is harmless, somebody thinks a warning
means a problem needs to fix.
>
> > There are user space projects that search BOOT_IMAGE from /proc/cmdline:
> > https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/util.go
> > (search getBootOptions)
> > https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/main.go
> > (search getKernelReleaseWithBootOption)
>
> What does it use these options for that it can't get from the valid ones
> instead?
Some projects have fallback methods, some projects don't work, but at
least this means some user space programs depend on it already.

>
> > So, we can say Grub pass BOOT_IMAGE is reasonable and there are user
> > space programs that hope it be in /proc/cmdline.
>
> But who relies on this that never noticed the kernel complaining about
> it for the past 4 years?
So If I'm the first man who notices this and wants to improve
something, then it is my mistake?

>
> > But BOOT_IMAGE should not be passed to the init program. Strings in
> > cmdline contain 4 types: BootLoader head (BOOT_IMAGE, kexec, etc.),
> > kernel parameters, init parameters, wrong parameters.
>
> Then fix grub to not do this.
>
> > The first type is handled (ignored) by this patch, the second type is
> > handled (consumed) by the kernel, and the last two types are passed to
> > user space.
>
> That's not obvious in this patch at all.  If you are doing different
> things, make it separate patches.
>
> And again, fix grub.
>
> > If the first type is also passed to user space, there are meaningless
> > warnings, and (maybe) cause problems with the init program.
>
> So it's been causing problems for all these years (i.e. since 2005)?
>
> What changed that is causing this to be an issue now, and again, why not
> just fix grub?
Corner cases have had problems since 2005, and just because they are
corner cases, they are not noticed by everyone. But once they are
noticed, they need to be fixed. We cannot change Grub (LILO do the
same thing) now, because user space relies on it already.

Huacai

>
> thanks,
>
> greg k-h

Re: [PATCH] init: Handle bootloader head in kernel parameters

[Greg KH]

On Sun, Jul 13, 2025 at 05:11:20PM +0800, Huacai Chen wrote:
> On Sun, Jul 13, 2025 at 4:30 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Sat, Jul 12, 2025 at 11:18:44PM +0800, Huacai Chen wrote:
> > > On Fri, Jul 11, 2025 at 9:04 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Fri, Jul 11, 2025 at 08:51:28PM +0800, Huacai Chen wrote:
> > > > > On Fri, Jul 11, 2025 at 8:41 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Fri, Jul 11, 2025 at 08:34:25PM +0800, Huacai Chen wrote:
> > > > > > > Hi, Greg,
> > > > > > >
> > > > > > > On Fri, Jul 11, 2025 at 7:06 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > > > >
> > > > > > > > On Fri, Jul 11, 2025 at 06:24:55PM +0800, Huacai Chen wrote:
> > > > > > > > > BootLoader may pass a head such as "BOOT_IMAGE=/boot/vmlinuz-x.y.z" to
> > > > > > > > > kernel parameters. But this head is not recognized by the kernel so will
> > > > > > > > > be passed to user space. However, user space init program also doesn't
> > > > > > > > > recognized it.
> > > > > > > >
> > > > > > > > Then why is it on the kernel command line if it is not recognized?
> > > > > > > UEFI put it at the beginning of the command line, you can see it from
> > > > > > > /proc/cmdline, both on x86 and LoongArch.
> > > > > >
> > > > > > Then fix UEFI :)
> > > > > >
> > > > > > My boot command line doesn't have that on x86, perhaps you need to fix
> > > > > > your bootloader?
> > > > > Not only UEFI, Grub also do this, for many years, not now. I don't
> > > > > know why they do this, but I think at least it is not a bug. For
> > > > > example, maybe it just tells user the path of kernel image via
> > > > > /proc/cmdline.
> > > > >
> > > > > [chenhuacai@kernelserver linux-official.git]$ uname -a
> > > > > Linux kernelserver 6.12.0-84.el10.x86_64 #1 SMP PREEMPT_DYNAMIC Tue
> > > > > May 13 13:39:02 UTC 2025 x86_64 GNU/Linux
> > > > > [chenhuacai@kernelserver linux-official.git]$ cat /proc/cmdline
> > > > > BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.12.0-84.el10.x86_64
> > > > > root=UUID=c8fcb11a-0f2f-48e5-a067-4cec1d18a721 ro
> > > > > crashkernel=2G-64G:256M,64G-:512M
> > > > > resume=UUID=1c320fec-3274-4b5b-9adf-a06
> > > > > 42e7943c0 rhgb quiet
> > > >
> > > > Sounds like a bootloader bug:
> > > >
> > > > $ cat /proc/cmdline
> > > > root=/dev/sda2 rw
> > > >
> > > > I suggest fixing the issue there, at the root please.
> > > Grub pass BOOT_IMAGE for all EFI-based implementations, related commits of Grub:
> > > https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=16ccb8b138218d56875051d547af84410d18f9aa
> > > https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=25953e10553dad2e378541a68686fc094603ec54
> >
> > From 2005 and 2011?  Why have we not had any reports of this being an
> > issue before now?  What changed in the kernel recently?
> As said before, just in some corner cases it causes problems, but
> corner case doesn't means nothing.
> 
> >
> > > Linux kernel treats BOOT_IMAGE as an "offender" of unknown command
> > > line parameters, related commits of kernel:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=86d1919a4fb0d9c115dd1d3b969f5d1650e45408
> >
> > So in 2021 we started printing out command line arguments that were
> > "wrong", so is this when everyone noticed that grub was wrong?
> Somebody may think a warning is harmless, somebody thinks a warning
> means a problem needs to fix.

Great, then fix it in grub to not do this :)

Are we supposed to paper over the bugs in all bootloaders?  Especially
for ones that we have the source to?

> > > There are user space projects that search BOOT_IMAGE from /proc/cmdline:
> > > https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/util.go
> > > (search getBootOptions)
> > > https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/main.go
> > > (search getKernelReleaseWithBootOption)
> >
> > What does it use these options for that it can't get from the valid ones
> > instead?
> Some projects have fallback methods, some projects don't work, but at
> least this means some user space programs depend on it already.
> 
> >
> > > So, we can say Grub pass BOOT_IMAGE is reasonable and there are user
> > > space programs that hope it be in /proc/cmdline.
> >
> > But who relies on this that never noticed the kernel complaining about
> > it for the past 4 years?
> So If I'm the first man who notices this and wants to improve
> something, then it is my mistake?

No, not at all, I'm saying to fix the root problem here please.  And
that root problem is grub adding stuff that causes warnings in Linux to
happen.  Why is this Linux's issue to handle?

thanks,

greg k-h

Re: [PATCH] init: Handle bootloader head in kernel parameters

[Huacai Chen]

On Sun, Jul 13, 2025 at 5:35 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Sun, Jul 13, 2025 at 05:11:20PM +0800, Huacai Chen wrote:
> > On Sun, Jul 13, 2025 at 4:30 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Sat, Jul 12, 2025 at 11:18:44PM +0800, Huacai Chen wrote:
> > > > On Fri, Jul 11, 2025 at 9:04 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Fri, Jul 11, 2025 at 08:51:28PM +0800, Huacai Chen wrote:
> > > > > > On Fri, Jul 11, 2025 at 8:41 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > On Fri, Jul 11, 2025 at 08:34:25PM +0800, Huacai Chen wrote:
> > > > > > > > Hi, Greg,
> > > > > > > >
> > > > > > > > On Fri, Jul 11, 2025 at 7:06 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Jul 11, 2025 at 06:24:55PM +0800, Huacai Chen wrote:
> > > > > > > > > > BootLoader may pass a head such as "BOOT_IMAGE=/boot/vmlinuz-x.y.z" to
> > > > > > > > > > kernel parameters. But this head is not recognized by the kernel so will
> > > > > > > > > > be passed to user space. However, user space init program also doesn't
> > > > > > > > > > recognized it.
> > > > > > > > >
> > > > > > > > > Then why is it on the kernel command line if it is not recognized?
> > > > > > > > UEFI put it at the beginning of the command line, you can see it from
> > > > > > > > /proc/cmdline, both on x86 and LoongArch.
> > > > > > >
> > > > > > > Then fix UEFI :)
> > > > > > >
> > > > > > > My boot command line doesn't have that on x86, perhaps you need to fix
> > > > > > > your bootloader?
> > > > > > Not only UEFI, Grub also do this, for many years, not now. I don't
> > > > > > know why they do this, but I think at least it is not a bug. For
> > > > > > example, maybe it just tells user the path of kernel image via
> > > > > > /proc/cmdline.
> > > > > >
> > > > > > [chenhuacai@kernelserver linux-official.git]$ uname -a
> > > > > > Linux kernelserver 6.12.0-84.el10.x86_64 #1 SMP PREEMPT_DYNAMIC Tue
> > > > > > May 13 13:39:02 UTC 2025 x86_64 GNU/Linux
> > > > > > [chenhuacai@kernelserver linux-official.git]$ cat /proc/cmdline
> > > > > > BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.12.0-84.el10.x86_64
> > > > > > root=UUID=c8fcb11a-0f2f-48e5-a067-4cec1d18a721 ro
> > > > > > crashkernel=2G-64G:256M,64G-:512M
> > > > > > resume=UUID=1c320fec-3274-4b5b-9adf-a06
> > > > > > 42e7943c0 rhgb quiet
> > > > >
> > > > > Sounds like a bootloader bug:
> > > > >
> > > > > $ cat /proc/cmdline
> > > > > root=/dev/sda2 rw
> > > > >
> > > > > I suggest fixing the issue there, at the root please.
> > > > Grub pass BOOT_IMAGE for all EFI-based implementations, related commits of Grub:
> > > > https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=16ccb8b138218d56875051d547af84410d18f9aa
> > > > https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=25953e10553dad2e378541a68686fc094603ec54
> > >
> > > From 2005 and 2011?  Why have we not had any reports of this being an
> > > issue before now?  What changed in the kernel recently?
> > As said before, just in some corner cases it causes problems, but
> > corner case doesn't means nothing.
> >
> > >
> > > > Linux kernel treats BOOT_IMAGE as an "offender" of unknown command
> > > > line parameters, related commits of kernel:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=86d1919a4fb0d9c115dd1d3b969f5d1650e45408
> > >
> > > So in 2021 we started printing out command line arguments that were
> > > "wrong", so is this when everyone noticed that grub was wrong?
> > Somebody may think a warning is harmless, somebody thinks a warning
> > means a problem needs to fix.
>
> Great, then fix it in grub to not do this :)
>
> Are we supposed to paper over the bugs in all bootloaders?  Especially
> for ones that we have the source to?
>
> > > > There are user space projects that search BOOT_IMAGE from /proc/cmdline:
> > > > https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/util.go
> > > > (search getBootOptions)
> > > > https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/main.go
> > > > (search getKernelReleaseWithBootOption)
> > >
> > > What does it use these options for that it can't get from the valid ones
> > > instead?
> > Some projects have fallback methods, some projects don't work, but at
> > least this means some user space programs depend on it already.
> >
> > >
> > > > So, we can say Grub pass BOOT_IMAGE is reasonable and there are user
> > > > space programs that hope it be in /proc/cmdline.
> > >
> > > But who relies on this that never noticed the kernel complaining about
> > > it for the past 4 years?
> > So If I'm the first man who notices this and wants to improve
> > something, then it is my mistake?
>
> No, not at all, I'm saying to fix the root problem here please.  And
> that root problem is grub adding stuff that causes warnings in Linux to
> happen.  Why is this Linux's issue to handle?
As I said before:

Corner cases have had problems since 2005, and just because they are
corner cases, they are not noticed by everyone. But once they are
noticed, they need to be fixed. And we cannot change Grub (LILO do the
same thing) now, because user space relies on it already.

>
> thanks,
>
> greg k-h