Skip to contentSkip to conversation

mount_root: clarify error messages for when no rootfs found (V2)

PATCH In review Darren Hart 3 participants 8 messages Nov 15, 2011 – Nov 16, 2011 VFS

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 mount_root: clarify error messages for when no rootfs found (V2)

The following is a modified version the patch at:

meta/cfg/kernel-cache/patches/boot/mount_root-clarify-error-messages-for-when-no-rootfs.patch

in the linux-yocto-3.0 git repository. This version adds KERN_EMERG so that even using loglevel=1 at boot, the end user will see:

[    0.217462] VFS: Unable to mount root fs on unknown-block(8,2)
[    0.223457] User configuration error - no valid root filesystem found
[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg
[    0.238992] Pid: 1, comm: swapper Not tainted 3.0.4-yocto-standard+ #2
[    0.245691] Call Trace:                                                         
[    0.248218]  [<c04eddbc>] ? 0xc04eddbc                                          
[    0.252071]  [<c05549ad>] ? 0xc05549ad                                          
[    0.255928]  [<c05549fa>] ? 0xc05549fa                                          
[    0.259790]  [<c0554623>] ? 0xc0554623                                          
[    0.263650]  [<c0554b1c>] ? 0xc0554b1c                                          
[    0.267497]  [<c055472a>] ? 0xc055472a                                          
[    0.271344]  [<c04f0df6>] ? 0xc04f0df6                                          

Instead of just:

[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg

...

Which is arguably no better than what this patch originally attempted to address.

Paul, has this patch been sent upstream for inclusion? I don't see it in Linus' tree.

Thanks,

Darren

----------------------

To an end user who doesn't really know linux that well, a message like:

  Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

may just look like cryptic computer speak indicating some deep and complex problem, instead of the reality that they have a simple local configuration problem. Ideally it would be nice to not use the misleading "panic" at all, but since various panic notifiers are historically expecting to be called when there is no valid rootfs, we can't change that.

So instead, this tries to make it 100% clear to folks of any background that it is an end user configuration issue.

V2: Use KERN_EMERG so the printk context isn't lost when using loglevel

---
 init/do_mounts.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)
init/do_mounts.c +6 -2
index bb008d0..d24b8c7 100644
@@ -270,7 +270,9 @@ retry:
 		printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
 		       "explicit textual name for \"root=\" boot option.\n");
 #endif
-		panic("VFS: Unable to mount root fs on %s", b);
+		printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+		printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+		panic("Invalid configuration from end user prevents continuing");
 	}
 
 	printk("List of all partitions:\n");
@@ -282,7 +284,9 @@ retry:
 #ifdef CONFIG_BLOCK
 	__bdevname(ROOT_DEV, b);
 #endif
-	panic("VFS: Unable to mount root fs on %s", b);
+	printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+	printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+	panic("Invalid configuration from end user prevents continuing");
 out:
 	putname(fs_names);
 }
Signature · 5 lines
1.6.5.2
-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
#1 lore raw
Quoted 20 lines · Darren Hart

The following is a modified version the patch at:

meta/cfg/kernel-cache/patches/boot/mount_root-clarify-error-messages-for-when-no-rootfs.patch

in the linux-yocto-3.0 git repository. This version adds KERN_EMERG so that even using loglevel=1 at boot, the end user will see:

[    0.217462] VFS: Unable to mount root fs on unknown-block(8,2)
[    0.223457] User configuration error - no valid root filesystem found
[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg
[    0.238992] Pid: 1, comm: swapper Not tainted 3.0.4-yocto-standard+ #2
[    0.245691] Call Trace:                                                         
[    0.248218]  [<c04eddbc>] ? 0xc04eddbc                                          
[    0.252071]  [<c05549ad>] ? 0xc05549ad                                          
[    0.255928]  [<c05549fa>] ? 0xc05549fa                                          
[    0.259790]  [<c0554623>] ? 0xc0554623                                          
[    0.263650]  [<c0554b1c>] ? 0xc0554b1c                                          
[    0.267497]  [<c055472a>] ? 0xc055472a                                          
[    0.271344]  [<c04f0df6>] ? 0xc04f0df6                                          
Quoted 8 lines

Instead of just:

[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg

...

Which is arguably no better than what this patch originally attempted to address.

Paul, has this patch been sent upstream for inclusion? I don't see it in Linus' tree.

No, I never sent it upstream. It seemed like such a trivial and cosmetic change. If you want to put the V2 comment below the --- and send it upstream, feel free to do so.

P.

Quoted 56 lines

Thanks,

Darren

----------------------

To an end user who doesn't really know linux that well, a message like:

  Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

may just look like cryptic computer speak indicating some deep and complex problem, instead of the reality that they have a simple local configuration problem. Ideally it would be nice to not use the misleading "panic" at all, but since various panic notifiers are historically expecting to be called when there is no valid rootfs, we can't change that.

So instead, this tries to make it 100% clear to folks of any background that it is an end user configuration issue.

V2: Use KERN_EMERG so the printk context isn't lost when using loglevel

---
 init/do_mounts.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)
init/do_mounts.c +6 -2
index bb008d0..d24b8c7 100644
@@ -270,7 +270,9 @@ retry:
 		printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
 		       "explicit textual name for \"root=\" boot option.\n");
 #endif
-		panic("VFS: Unable to mount root fs on %s", b);
+		printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+		printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+		panic("Invalid configuration from end user prevents continuing");
 	}
 
 	printk("List of all partitions:\n");
@@ -282,7 +284,9 @@ retry:
 #ifdef CONFIG_BLOCK
 	__bdevname(ROOT_DEV, b);
 #endif
-	panic("VFS: Unable to mount root fs on %s", b);
+	printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+	printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+	panic("Invalid configuration from end user prevents continuing");
 out:
 	putname(fs_names);
 }
#2 lore raw
Quoted 26 lines · Paul Gortmaker
Quoted 25 lines · Darren Hart

The following is a modified version the patch at:

meta/cfg/kernel-cache/patches/boot/mount_root-clarify-error-messages-for-when-no-rootfs.patch

in the linux-yocto-3.0 git repository. This version adds KERN_EMERG so that even using loglevel=1 at boot, the end user will see:

[    0.217462] VFS: Unable to mount root fs on unknown-block(8,2)
[    0.223457] User configuration error - no valid root filesystem found
[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg
[    0.238992] Pid: 1, comm: swapper Not tainted 3.0.4-yocto-standard+ #2
[    0.245691] Call Trace:                                                         
[    0.248218]  [<c04eddbc>] ? 0xc04eddbc                                          
[    0.252071]  [<c05549ad>] ? 0xc05549ad                                          
[    0.255928]  [<c05549fa>] ? 0xc05549fa                                          
[    0.259790]  [<c0554623>] ? 0xc0554623                                          
[    0.263650]  [<c0554b1c>] ? 0xc0554b1c                                          
[    0.267497]  [<c055472a>] ? 0xc055472a                                          
[    0.271344]  [<c04f0df6>] ? 0xc04f0df6                                          

Instead of just:

[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg

...

Quoted 8 lines
Quoted 3 lines

Which is arguably no better than what this patch originally attempted to address.

Paul, has this patch been sent upstream for inclusion? I don't see it in Linus' tree.

No, I never sent it upstream. It seemed like such a trivial and cosmetic change. If you want to put the V2 comment below the --- and send it upstream, feel free to do so.

OK. We really shouldn't be holding on to patches like these. If they are good for us, they should be good for upstream. If they are not good for upstream, then we don't want to differ in such a way that causes confusion for people trying to debug.

For example, I saw the latter message, thought it was due to the new bootloader I was trying, and the bootloader author couldn't find that string in the upstream kernel sources he develops with.

--
Darren

Quoted 58 lines

P.

Quoted 56 lines

Thanks,

Darren

----------------------

To an end user who doesn't really know linux that well, a message like:

  Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

may just look like cryptic computer speak indicating some deep and complex problem, instead of the reality that they have a simple local configuration problem. Ideally it would be nice to not use the misleading "panic" at all, but since various panic notifiers are historically expecting to be called when there is no valid rootfs, we can't change that.

So instead, this tries to make it 100% clear to folks of any background that it is an end user configuration issue.

V2: Use KERN_EMERG so the printk context isn't lost when using loglevel

---
 init/do_mounts.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)
init/do_mounts.c +6 -2
index bb008d0..d24b8c7 100644
@@ -270,7 +270,9 @@ retry:
 		printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
 		       "explicit textual name for \"root=\" boot option.\n");
 #endif
-		panic("VFS: Unable to mount root fs on %s", b);
+		printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+		printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+		panic("Invalid configuration from end user prevents continuing");
 	}
 
 	printk("List of all partitions:\n");
@@ -282,7 +284,9 @@ retry:
 #ifdef CONFIG_BLOCK
 	__bdevname(ROOT_DEV, b);
 #endif
-	panic("VFS: Unable to mount root fs on %s", b);
+	printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+	printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+	panic("Invalid configuration from end user prevents continuing");
 out:
 	putname(fs_names);
 }
Signature · 3 lines
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
#3 lore raw
In reply to Darren Hart
Quoted 1 line · Darren Hart

The following is a modified version the patch at:

Works for me as well, I'll update the variant in the yocto kernel trees, while we wait to see if anyone upstream has any interest.

Bruce

Quoted 83 lines

meta/cfg/kernel-cache/patches/boot/mount_root-clarify-error-messages-for-when-no-rootfs.patch

in the linux-yocto-3.0 git repository. This version adds KERN_EMERG so that even using loglevel=1 at boot, the end user will see:

[    0.217462] VFS: Unable to mount root fs on unknown-block(8,2)
[    0.223457] User configuration error - no valid root filesystem found
[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg
[    0.238992] Pid: 1, comm: swapper Not tainted 3.0.4-yocto-standard+ #2
[    0.245691] Call Trace:
[    0.248218]  [<c04eddbc>] ? 0xc04eddbc
[    0.252071]  [<c05549ad>] ? 0xc05549ad
[    0.255928]  [<c05549fa>] ? 0xc05549fa
[    0.259790]  [<c0554623>] ? 0xc0554623
[    0.263650]  [<c0554b1c>] ? 0xc0554b1c
[    0.267497]  [<c055472a>] ? 0xc055472a
[    0.271344]  [<c04f0df6>] ? 0xc04f0df6

Instead of just:

[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg

...

Which is arguably no better than what this patch originally attempted to address.

Paul, has this patch been sent upstream for inclusion? I don't see it in Linus' tree.

Thanks,

Darren

----------------------

To an end user who doesn't really know linux that well, a message like:

   Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

may just look like cryptic computer speak indicating some deep and complex problem, instead of the reality that they have a simple local configuration problem. Ideally it would be nice to not use the misleading "panic" at all, but since various panic notifiers are historically expecting to be called when there is no valid rootfs, we can't change that.

So instead, this tries to make it 100% clear to folks of any background that it is an end user configuration issue.

V2: Use KERN_EMERG so the printk context isn't lost when using loglevel

---
  init/do_mounts.c |    8 ++++++--
  1 files changed, 6 insertions(+), 2 deletions(-)
init/do_mounts.c +6 -2
index bb008d0..d24b8c7 100644
@@ -270,7 +270,9 @@ retry:
  		printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
  		       "explicit textual name for \"root=\" boot option.\n");
  #endif
-		panic("VFS: Unable to mount root fs on %s", b);
+		printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+		printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+		panic("Invalid configuration from end user prevents continuing");
  	}
 
  	printk("List of all partitions:\n");
@@ -282,7 +284,9 @@ retry:
  #ifdef CONFIG_BLOCK
  	__bdevname(ROOT_DEV, b);
  #endif
-	panic("VFS: Unable to mount root fs on %s", b);
+	printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+	printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+	panic("Invalid configuration from end user prevents continuing");
  out:
  	putname(fs_names);
  }
#4 lore raw
Quoted 5 lines · Bruce Ashfield
Quoted 1 line · Darren Hart

The following is a modified version the patch at:

Works for me as well, I'll update the variant in the yocto kernel trees, while we wait to see if anyone upstream has any interest.

I we can't get it upstream, I'd argue we drop this. As Paul said, it is cosmetic. When people see this error, the only place they'll find help is here on the yocto list. They should be able to debug the kernel with all the Linux Kernel resources out there. Having custom kernel messages for Yocto prevents that.

--
Darren

Quoted 87 lines

Bruce

Quoted 83 lines

meta/cfg/kernel-cache/patches/boot/mount_root-clarify-error-messages-for-when-no-rootfs.patch

in the linux-yocto-3.0 git repository. This version adds KERN_EMERG so that even using loglevel=1 at boot, the end user will see:

[    0.217462] VFS: Unable to mount root fs on unknown-block(8,2)
[    0.223457] User configuration error - no valid root filesystem found
[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg
[    0.238992] Pid: 1, comm: swapper Not tainted 3.0.4-yocto-standard+ #2
[    0.245691] Call Trace:
[    0.248218]  [<c04eddbc>] ? 0xc04eddbc
[    0.252071]  [<c05549ad>] ? 0xc05549ad
[    0.255928]  [<c05549fa>] ? 0xc05549fa
[    0.259790]  [<c0554623>] ? 0xc0554623
[    0.263650]  [<c0554b1c>] ? 0xc0554b1c
[    0.267497]  [<c055472a>] ? 0xc055472a
[    0.271344]  [<c04f0df6>] ? 0xc04f0df6

Instead of just:

[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg

...

Which is arguably no better than what this patch originally attempted to address.

Paul, has this patch been sent upstream for inclusion? I don't see it in Linus' tree.

Thanks,

Darren

----------------------

To an end user who doesn't really know linux that well, a message like:

   Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

may just look like cryptic computer speak indicating some deep and complex problem, instead of the reality that they have a simple local configuration problem. Ideally it would be nice to not use the misleading "panic" at all, but since various panic notifiers are historically expecting to be called when there is no valid rootfs, we can't change that.

So instead, this tries to make it 100% clear to folks of any background that it is an end user configuration issue.

V2: Use KERN_EMERG so the printk context isn't lost when using loglevel

---
  init/do_mounts.c |    8 ++++++--
  1 files changed, 6 insertions(+), 2 deletions(-)
init/do_mounts.c +6 -2
index bb008d0..d24b8c7 100644
@@ -270,7 +270,9 @@ retry:
  		printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
  		       "explicit textual name for \"root=\" boot option.\n");
  #endif
-		panic("VFS: Unable to mount root fs on %s", b);
+		printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+		printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+		panic("Invalid configuration from end user prevents continuing");
  	}
 
  	printk("List of all partitions:\n");
@@ -282,7 +284,9 @@ retry:
  #ifdef CONFIG_BLOCK
  	__bdevname(ROOT_DEV, b);
  #endif
-	panic("VFS: Unable to mount root fs on %s", b);
+	printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+	printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+	panic("Invalid configuration from end user prevents continuing");
  out:
  	putname(fs_names);
  }
Signature · 3 lines
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
#5 lore raw
Quoted 11 lines · Darren Hart
Quoted 5 lines · Bruce Ashfield
Quoted 1 line · Darren Hart

The following is a modified version the patch at:

Works for me as well, I'll update the variant in the yocto kernel trees, while we wait to see if anyone upstream has any interest.

I we can't get it upstream, I'd argue we drop this. As Paul said, it is cosmetic. When people see this error, the only place they'll find help

I have no plans to drop this. It's a value add, and simply because not everyone wants it, doesn't mean we let it go.

We can carry it and try again if it doesn't make it upstream.

Quoted 3 lines

is here on the yocto list. They should be able to debug the kernel with all the Linux Kernel resources out there. Having custom kernel messages for Yocto prevents that.

I disagree.

Bruce

Quoted 92 lines

--
Darren

Quoted 87 lines

Bruce

Quoted 83 lines

meta/cfg/kernel-cache/patches/boot/mount_root-clarify-error-messages-for-when-no-rootfs.patch

in the linux-yocto-3.0 git repository. This version adds KERN_EMERG so that even using loglevel=1 at boot, the end user will see:

[    0.217462] VFS: Unable to mount root fs on unknown-block(8,2)
[    0.223457] User configuration error - no valid root filesystem found
[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg
[    0.238992] Pid: 1, comm: swapper Not tainted 3.0.4-yocto-standard+ #2
[    0.245691] Call Trace:
[    0.248218]  [<c04eddbc>] ? 0xc04eddbc
[    0.252071]  [<c05549ad>] ? 0xc05549ad
[    0.255928]  [<c05549fa>] ? 0xc05549fa
[    0.259790]  [<c0554623>] ? 0xc0554623
[    0.263650]  [<c0554b1c>] ? 0xc0554b1c
[    0.267497]  [<c055472a>] ? 0xc055472a
[    0.271344]  [<c04f0df6>] ? 0xc04f0df6

Instead of just:

[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg

...

Which is arguably no better than what this patch originally attempted to address.

Paul, has this patch been sent upstream for inclusion? I don't see it in Linus' tree.

Thanks,

Darren

----------------------

To an end user who doesn't really know linux that well, a message like:

    Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

may just look like cryptic computer speak indicating some deep and complex problem, instead of the reality that they have a simple local configuration problem. Ideally it would be nice to not use the misleading "panic" at all, but since various panic notifiers are historically expecting to be called when there is no valid rootfs, we can't change that.

So instead, this tries to make it 100% clear to folks of any background that it is an end user configuration issue.

V2: Use KERN_EMERG so the printk context isn't lost when using loglevel

---
   init/do_mounts.c |    8 ++++++--
   1 files changed, 6 insertions(+), 2 deletions(-)
init/do_mounts.c +6 -2
index bb008d0..d24b8c7 100644
@@ -270,7 +270,9 @@ retry:
   		printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
   		       "explicit textual name for \"root=\" boot option.\n");
   #endif
-		panic("VFS: Unable to mount root fs on %s", b);
+		printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+		printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+		panic("Invalid configuration from end user prevents continuing");
   	}
 
   	printk("List of all partitions:\n");
@@ -282,7 +284,9 @@ retry:
   #ifdef CONFIG_BLOCK
   	__bdevname(ROOT_DEV, b);
   #endif
-	panic("VFS: Unable to mount root fs on %s", b);
+	printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+	printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+	panic("Invalid configuration from end user prevents continuing");
   out:
   	putname(fs_names);
   }
#6 lore raw
Quoted 16 lines · Bruce Ashfield
Quoted 11 lines · Darren Hart
Quoted 5 lines · Bruce Ashfield
Quoted 1 line · Darren Hart

The following is a modified version the patch at:

Works for me as well, I'll update the variant in the yocto kernel trees, while we wait to see if anyone upstream has any interest.

I we can't get it upstream, I'd argue we drop this. As Paul said, it is cosmetic. When people see this error, the only place they'll find help

I have no plans to drop this. It's a value add, and simply because not everyone wants it, doesn't mean we let it go.

Quoted 7 lines

We can carry it and try again if it doesn't make it upstream.

Quoted 3 lines

is here on the yocto list. They should be able to debug the kernel with all the Linux Kernel resources out there. Having custom kernel messages for Yocto prevents that.

I disagree.

With which part? That they should be able to use all the available resources? Or that custom kernel messages restrict where they can get help? I don't see how you can really argue against either of those...

--
Darren

Quoted 96 lines

Bruce

Quoted 92 lines

--
Darren

Quoted 87 lines

Bruce

Quoted 83 lines

meta/cfg/kernel-cache/patches/boot/mount_root-clarify-error-messages-for-when-no-rootfs.patch

in the linux-yocto-3.0 git repository. This version adds KERN_EMERG so that even using loglevel=1 at boot, the end user will see:

[    0.217462] VFS: Unable to mount root fs on unknown-block(8,2)
[    0.223457] User configuration error - no valid root filesystem found
[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg
[    0.238992] Pid: 1, comm: swapper Not tainted 3.0.4-yocto-standard+ #2
[    0.245691] Call Trace:
[    0.248218]  [<c04eddbc>] ? 0xc04eddbc
[    0.252071]  [<c05549ad>] ? 0xc05549ad
[    0.255928]  [<c05549fa>] ? 0xc05549fa
[    0.259790]  [<c0554623>] ? 0xc0554623
[    0.263650]  [<c0554b1c>] ? 0xc0554b1c
[    0.267497]  [<c055472a>] ? 0xc055472a
[    0.271344]  [<c04f0df6>] ? 0xc04f0df6

Instead of just:

[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg

...

Which is arguably no better than what this patch originally attempted to address.

Paul, has this patch been sent upstream for inclusion? I don't see it in Linus' tree.

Thanks,

Darren

----------------------

To an end user who doesn't really know linux that well, a message like:

    Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

may just look like cryptic computer speak indicating some deep and complex problem, instead of the reality that they have a simple local configuration problem. Ideally it would be nice to not use the misleading "panic" at all, but since various panic notifiers are historically expecting to be called when there is no valid rootfs, we can't change that.

So instead, this tries to make it 100% clear to folks of any background that it is an end user configuration issue.

V2: Use KERN_EMERG so the printk context isn't lost when using loglevel

---
   init/do_mounts.c |    8 ++++++--
   1 files changed, 6 insertions(+), 2 deletions(-)
init/do_mounts.c +6 -2
index bb008d0..d24b8c7 100644
@@ -270,7 +270,9 @@ retry:
   		printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
   		       "explicit textual name for \"root=\" boot option.\n");
   #endif
-		panic("VFS: Unable to mount root fs on %s", b);
+		printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+		printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+		panic("Invalid configuration from end user prevents continuing");
   	}
 
   	printk("List of all partitions:\n");
@@ -282,7 +284,9 @@ retry:
   #ifdef CONFIG_BLOCK
   	__bdevname(ROOT_DEV, b);
   #endif
-	panic("VFS: Unable to mount root fs on %s", b);
+	printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+	printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+	panic("Invalid configuration from end user prevents continuing");
   out:
   	putname(fs_names);
   }
Signature · 3 lines
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
#7 lore raw
Quoted 25 lines · Darren Hart
Quoted 22 lines · Bruce Ashfield
Quoted 11 lines · Darren Hart
Quoted 5 lines · Bruce Ashfield
Quoted 1 line · Darren Hart

The following is a modified version the patch at:

Works for me as well, I'll update the variant in the yocto kernel trees, while we wait to see if anyone upstream has any interest.

I we can't get it upstream, I'd argue we drop this. As Paul said, it is cosmetic. When people see this error, the only place they'll find help

I have no plans to drop this. It's a value add, and simply because not everyone wants it, doesn't mean we let it go.

We can carry it and try again if it doesn't make it upstream.

Quoted 3 lines

is here on the yocto list. They should be able to debug the kernel with all the Linux Kernel resources out there. Having custom kernel messages for Yocto prevents that.

Quoted 5 lines
Quoted 1 line

I disagree.

With which part? That they should be able to use all the available resources? Or that custom kernel messages restrict where they can get help? I don't see how you can really argue against either of those...

Sorry for the short reply, I was being pulled away and couldn't elaborate.

I don't see the two issues as being tied together or at least not signifcantly. If two people are debugging a kernel issue, it is incumbent that they know the trees they are using and to ensure that they are at least somewhat in sync. The changes aren't hidden in any way, so it's easy to know what is in play.

It's no different than using a arch/vendor tree versus mainline or linux-next, or even two different mainline trees where one has a changed strings. A grep or search will fail, and at that point we sync on the tree versions and make sure they match.

There's plenty of other bigger issues that a few different messages coming out of the kernel that can prevent people from using resources. So I'm not arguing that it isn't a factor, I'm just saying that it (a custom message) isn't a significant one.

Obviously we want the patch to be upstream, that's a baseline goal for any change and I understand frustration and losing some time during debug. But that particular message has been proven to save lots of time in many other situations, so I wouldn't shoot myself in the foot by dropping it based solely on it not being upstream.

I'd modify it to meet comments, make it optional, prepend [yocto], dropping it would be last resort.

I'm heading AFK again, but will be back later today.

Cheers,

Bruce

Quoted 101 lines

--
Darren

Quoted 96 lines

Bruce

Quoted 92 lines

--
Darren

Quoted 87 lines

Bruce

Quoted 83 lines

meta/cfg/kernel-cache/patches/boot/mount_root-clarify-error-messages-for-when-no-rootfs.patch

in the linux-yocto-3.0 git repository. This version adds KERN_EMERG so that even using loglevel=1 at boot, the end user will see:

[    0.217462] VFS: Unable to mount root fs on unknown-block(8,2)
[    0.223457] User configuration error - no valid root filesystem found
[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg
[    0.238992] Pid: 1, comm: swapper Not tainted 3.0.4-yocto-standard+ #2
[    0.245691] Call Trace:
[    0.248218]  [<c04eddbc>] ? 0xc04eddbc
[    0.252071]  [<c05549ad>] ? 0xc05549ad
[    0.255928]  [<c05549fa>] ? 0xc05549fa
[    0.259790]  [<c0554623>] ? 0xc0554623
[    0.263650]  [<c0554b1c>] ? 0xc0554b1c
[    0.267497]  [<c055472a>] ? 0xc055472a
[    0.271344]  [<c04f0df6>] ? 0xc04f0df6

Instead of just:

[    0.230057] Kernel panic - not syncing: Invalid configuration from end user preg

...

Which is arguably no better than what this patch originally attempted to address.

Paul, has this patch been sent upstream for inclusion? I don't see it in Linus' tree.

Thanks,

Darren

----------------------

To an end user who doesn't really know linux that well, a message like:

     Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

may just look like cryptic computer speak indicating some deep and complex problem, instead of the reality that they have a simple local configuration problem. Ideally it would be nice to not use the misleading "panic" at all, but since various panic notifiers are historically expecting to be called when there is no valid rootfs, we can't change that.

So instead, this tries to make it 100% clear to folks of any background that it is an end user configuration issue.

V2: Use KERN_EMERG so the printk context isn't lost when using loglevel

---
    init/do_mounts.c |    8 ++++++--
    1 files changed, 6 insertions(+), 2 deletions(-)
init/do_mounts.c +6 -2
index bb008d0..d24b8c7 100644
@@ -270,7 +270,9 @@ retry:
    		printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
    		       "explicit textual name for \"root=\" boot option.\n");
    #endif
-		panic("VFS: Unable to mount root fs on %s", b);
+		printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+		printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+		panic("Invalid configuration from end user prevents continuing");
    	}
 
    	printk("List of all partitions:\n");
@@ -282,7 +284,9 @@ retry:
    #ifdef CONFIG_BLOCK
    	__bdevname(ROOT_DEV, b);
    #endif
-	panic("VFS: Unable to mount root fs on %s", b);
+	printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+	printk(KERN_EMERG "User configuration error - no valid root filesystem found\n");
+	panic("Invalid configuration from end user prevents continuing");
    out:
    	putname(fs_names);
    }