Re: Possible to delay boot process to boot from USB subsystem?

[Bill Catlan]

Randy,

Thanks for the patch, but it does not work for 2.4.26.  The kernel panic I get
("Kernel panic: No init found. Try passing init= option to kernel.")  is
generated by the init() function in init/main.c.  Willy's patch applies to
init/main.c, perhaps yours should now as well (i.e., in later kernels)?  (I have
not tested Willy's patch, but he claims success with a 2.4.23 kernel.)

I like your approach better because I do not have to set a time, it just keeps
trying in a loop.  Since mounting the rootfs is a critical step, I don't mind
the infinite looping until success - especially with hot swappable devices.  I
had nice functionality on a 2.4.18 kernel, but would rather keep current with
the kernel.

Hope this helps.  Please let me know what you think might be possible, as well
as a timeframe, if at all possible.  Thanks.

Bill

----- Original Message ----- 
From: "Randy.Dunlap" <rddunlap@xxxxxxxx>
To: "Bill Catlan" <wcatlan@xxxxxxxxx>
Cc: <linux-kernel@xxxxxxxxxxxxxxx>
Sent: Sunday, May 02, 2004 9:27 PM
Subject: Re: Possible to delay boot process to boot from USB subsystem?


> On Sun, 2 May 2004 19:27:08 -0400 "Bill Catlan" <wcatlan@xxxxxxxxx> wrote:
>
> | Hello,
> |
> | The below message appeared on linux-kernel in June 2002.  The patch allows
> | booting from a USB harddrive and was designed for the 2.4.14-pre8-ext3
kernel,
> | but I was able to manually apply it to a Debian 2.4.18 kernel.
> |
> | I am now trying to upgrade to a 2.4.26 kernel, and I am unable to create the
> | same "boot from floppy with rootfs on a USB drive" scenario that I created
with
> | the modified 2.4.18 kernel.  I believe my current issue with the 2.4.26
kernel
> | is the same race condition as on the 2.4.18 kernel since I get the
"Initializing
> | USB Mass Storage driver..." notice, but then i get "Kernel panic: No init
found.
> | Try passing init= option to kernel."  Given time, I suspect that the USB
storage
> | subsystem would come online and the kernel would be able to mount the rootfs
on
> | it.
> |
> | fs/super.c has change dramatically and the below patch now seems obsolete.
> |
> | Is there a similar patch for newer kernels - or any other way to cause the
boot
> | process to pause between loading the kernel and modules and running
/sbin/init?
> |
> | TIA.
> |
> | Bill
> |
> | On Sun, Jun 02, 2002 at 10:13:22PM +0200, Paul Stoeber wrote:
> | > It simply sleeps 10 seconds before mount_block_root().
> | >
> | > I get an 'Unable to mount root' panic if I don't apply it,
> | > because the attached device rolls in too late.
> |
> | A while ago I made the patch below. I retries every second until the root
> | device appears. Advantages:
> | - no delay when the device is already there
> | - it also works if it takes longer than 10s to find the harddisk
> |   (for example, if you plug it in later)
> |
> | I don't know if it applies cleanly to current kernels.
> |
> | Eric
> |
> | --- linux-2.4.14-pre8-ext3/fs/super.c.orig Fri Nov 16 00:59:18 2001
> | +++ linux-2.4.14-pre8-ext3/fs/super.c Fri Nov 16 01:07:26 2001
> | @@ -1009,11 +1009,13 @@
> |  * Allow the user to distinguish between failed open
> |  * and bad superblock on root device.
> |  */
> | - printk ("VFS: Cannot open root device \"%s\" or %s\n",
> | + printk ("VFS: Cannot open root device \"%s\" or %s, retrying in 1s.\n",
> |  root_device_name, kdevname (ROOT_DEV));
> | - printk ("Please append a correct \"root=\" boot option\n");
> | - panic("VFS: Unable to mount root fs on %s",
> | - kdevname(ROOT_DEV));
> | +
> | + /* wait 1 second and try again */
> | + current->state = TASK_INTERRUPTIBLE;
> | + schedule_timeout(HZ);
> | + goto retry;
> |  }
> |
> |  check_disk_change(ROOT_DEV);
> | -
>
> I updated that patch to 2.4.22 but haven't checked it since then.
> I can't test it... if you can, that would be great.
> If it doesn't apply cleanly to 2.4.26, let me know and I'll work
> on it.
>
> Patch is here:
>   http://www.xenotime.net/linux/usb/usbboot-2422.patch
>
> --
> ~Randy

-
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/