Re: [PATCH] init: make init failures more explicit
From: Janne Karhunen
Date: Fri Oct 18 2013 - 05:38:46 EST
On Fri, Oct 18, 2013 at 11:47 AM, Michael Opdenacker
<michael.opdenacker@xxxxxxxxxxxxxxxxxx> wrote:
> This patch proposes to make init failures more explicit.
>
> Before this, the "No init found" message didn't help much.
> It could sometimes be misleading and actually mean
> "No *working* init found".
Heh, I was just looking at similar thing, except in my case dumping
out the execve error code would be the key (now I'm getting -ENOEXEC
back from init exec for no obvious reason). In case something like
this is getting merged I'd appreciate -errno dump as well.
diff --git a/init/main.c b/init/main.c
index 63d3e8f..56fb84a 100644
--- a/init/main.c
+++ b/init/main.c
@@ -815,6 +815,8 @@ static noinline void __init kernel_init_freeable(void);
static int __ref kernel_init(void *unused)
{
+ int err;
+
kernel_init_freeable();
/* need to finish all async __init code before freeing the memory */
async_synchronize_full();
@@ -826,9 +828,11 @@ static int __ref kernel_init(void *unused)
flush_delayed_fput();
if (ramdisk_execute_command) {
- if (!run_init_process(ramdisk_execute_command))
+ err = run_init_process(ramdisk_execute_command);
+ if (!err)
return 0;
- pr_err("Failed to execute %s\n", ramdisk_execute_command);
+ pr_err("Failed to execute %s, error: %d\n",
+ ramdisk_execute_command, err);
}
/*
@@ -838,10 +842,12 @@ static int __ref kernel_init(void *unused)
* trying to recover a really broken machine.
*/
if (execute_command) {
- if (!run_init_process(execute_command))
+ err = run_init_process(execute_command);
+ if (!err)
return 0;
- pr_err("Failed to execute %s. Attempting defaults...\n",
- execute_command);
+ pr_err("Failed to execute %s, error: %d\n",
+ execute_command, err);
+ pr_err("Attempting defaults...\n");
}
if (!run_init_process("/sbin/init") ||
!run_init_process("/etc/init") ||
--
Janne
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/