waiting 10s before mounting root filesystem?

waiting 10s before mounting root filesystem?

[William Park]

How do I make the kernel to wait about 10s before attempting to mount
root filesystem?  Is there obscure kernel parameter?

I can load the kernel from /dev/fd0, then mount /dev/hda2 as root
filesystem.  But, I can't seem to mount /dev/sda1 (USB key drive) as
root filesystem.  All relevant USB and SCSI modules are compiled into
the kernel.  I think kernel is too fast in panicking.  I would like the
kernel to wait about 10s until 'usb-storage' and 'sd_mod' work out all
the details.

-- 
William Park <opengeometry@yahoo.ca>
Open Geometry Consulting, Toronto, Canada
Linux solution for data processing. 

Re: waiting 10s before mounting root filesystem?

[Trent Lloyd]

This is really suited to the task of an initrd, then you can spin until
the usb storage device comes up in a bash script or something similar.

Cheers,
Trent

> How do I make the kernel to wait about 10s before attempting to mount
> root filesystem?  Is there obscure kernel parameter?
> 
> I can load the kernel from /dev/fd0, then mount /dev/hda2 as root
> filesystem.  But, I can't seem to mount /dev/sda1 (USB key drive) as
> root filesystem.  All relevant USB and SCSI modules are compiled into
> the kernel.  I think kernel is too fast in panicking.  I would like the
> kernel to wait about 10s until 'usb-storage' and 'sd_mod' work out all
> the details.
> 
> -- 
> William Park <opengeometry@yahoo.ca>
> Open Geometry Consulting, Toronto, Canada
> Linux solution for data processing. 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Trent Lloyd <lathiat@bur.st>
Bur.st Networking Inc.

Re: waiting 10s before mounting root filesystem?

[Andreas Unterkircher]

Or you could try a patch from Randy Dunlap & Eric Lammerts [1] which 
loops around in do_mounts.c
until the root filesystem can be mounted.... not that beautiful - but it 
works :)

[1] http://www.xenotime.net/linux/usb/usbboot-2422.patch

Cheers,
Andreas

PS: In the same manner you can do it with 2.6

Trent Lloyd wrote:

>This is really suited to the task of an initrd, then you can spin until
>the usb storage device comes up in a bash script or something similar.
>
>Cheers,
>Trent
>
>  
>
>>How do I make the kernel to wait about 10s before attempting to mount
>>root filesystem?  Is there obscure kernel parameter?
>>
>>I can load the kernel from /dev/fd0, then mount /dev/hda2 as root
>>filesystem.  But, I can't seem to mount /dev/sda1 (USB key drive) as
>>root filesystem.  All relevant USB and SCSI modules are compiled into
>>the kernel.  I think kernel is too fast in panicking.  I would like the
>>kernel to wait about 10s until 'usb-storage' and 'sd_mod' work out all
>>the details.
>>
>>-- 
>>William Park <opengeometry@yahoo.ca>
>>Open Geometry Consulting, Toronto, Canada
>>Linux solution for data processing. 
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at  http://www.tux.org/lkml/
>>    
>>
>
>  
>

Re: waiting 10s before mounting root filesystem?

[Eric Lammerts]

Andreas Unterkircher wrote:
> Or you could try a patch from Randy Dunlap & Eric Lammerts [1] which 
> loops around in do_mounts.c
> until the root filesystem can be mounted.... not that beautiful - but it 
> works :)

> PS: In the same manner you can do it with 2.6

There's a patch for 2.6 (slightly nicer, with a wait queue), see
http://marc.theaimsgroup.com/?l=linux-kernel&m=109122295308836&w=2

Eric

Re: waiting 10s before mounting root filesystem?

[William Park]

On Mon, Dec 27, 2004 at 10:23:34PM +0100, Andreas Unterkircher wrote:
> >>How do I make the kernel to wait about 10s before attempting to
> >>mount root filesystem?  Is there obscure kernel parameter?
> >>
> >>I can load the kernel from /dev/fd0, then mount /dev/hda2 as root
> >>filesystem.  But, I can't seem to mount /dev/sda1 (USB key drive) as
> >>root filesystem.  All relevant USB and SCSI modules are compiled
> >>into the kernel.  I think kernel is too fast in panicking.  I would
> >>like the kernel to wait about 10s until 'usb-storage' and 'sd_mod'
> >>work out all the details.
> >
> >This is really suited to the task of an initrd, then you can spin
> >until the usb storage device comes up in a bash script or something
> >similar.
>
> Or you could try a patch from Randy Dunlap & Eric Lammerts [1] which 
> loops around in do_mounts.c
> until the root filesystem can be mounted.... not that beautiful - but it 
> works :)
> 
> [1] http://www.xenotime.net/linux/usb/usbboot-2422.patch
> 
> Cheers,
> Andreas
> 
> PS: In the same manner you can do it with 2.6

Thanks Andreas.  I can now boot from my el-cheapo USB key drive (256MB
SanDisk Cruzer Mini).  Since mine takes about 5sec to show up, I decided
to wait 5sec instead of 1sec.  Here is diff for 2.6.10:

--- ./init/do_mounts.c--orig	2004-12-27 17:36:35.000000000 -0500
+++ ./init/do_mounts.c	2004-12-28 17:27:26.000000000 -0500
@@ -301,7 +301,14 @@ retry:
 				root_device_name, b);
 		printk("Please append a correct \"root=\" boot option\n");
 
+#if 0	/* original code */
 		panic("VFS: Unable to mount root fs on %s", b);
+#else
+		printk ("Waiting 5 seconds to try again...\n");
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule_timeout(5 * HZ);
+		goto retry;
+#endif
 	}
 	panic("VFS: Unable to mount root fs on %s", __bdevname(ROOT_DEV, b));
 out:

-- 
William Park <opengeometry@yahoo.ca>
Open Geometry Consulting, Toronto, Canada
Linux solution for data processing. 

Re: waiting 10s before mounting root filesystem?

[Jesper Juhl]

On Tue, 28 Dec 2004, William Park wrote:

> On Mon, Dec 27, 2004 at 10:23:34PM +0100, Andreas Unterkircher wrote:
> > >>How do I make the kernel to wait about 10s before attempting to
> > >>mount root filesystem?  Is there obscure kernel parameter?
> > >>
> > >>I can load the kernel from /dev/fd0, then mount /dev/hda2 as root
> > >>filesystem.  But, I can't seem to mount /dev/sda1 (USB key drive) as
> > >>root filesystem.  All relevant USB and SCSI modules are compiled
> > >>into the kernel.  I think kernel is too fast in panicking.  I would
> > >>like the kernel to wait about 10s until 'usb-storage' and 'sd_mod'
> > >>work out all the details.
> > >
> > >This is really suited to the task of an initrd, then you can spin
> > >until the usb storage device comes up in a bash script or something
> > >similar.
> >
> > Or you could try a patch from Randy Dunlap & Eric Lammerts [1] which 
> > loops around in do_mounts.c
> > until the root filesystem can be mounted.... not that beautiful - but it 
> > works :)
> > 
> > [1] http://www.xenotime.net/linux/usb/usbboot-2422.patch
> > 
> > Cheers,
> > Andreas
> > 
> > PS: In the same manner you can do it with 2.6
> 
> Thanks Andreas.  I can now boot from my el-cheapo USB key drive (256MB
> SanDisk Cruzer Mini).  Since mine takes about 5sec to show up, I decided
> to wait 5sec instead of 1sec.  Here is diff for 2.6.10:
> 
> --- ./init/do_mounts.c--orig	2004-12-27 17:36:35.000000000 -0500
> +++ ./init/do_mounts.c	2004-12-28 17:27:26.000000000 -0500
> @@ -301,7 +301,14 @@ retry:
>  				root_device_name, b);
>  		printk("Please append a correct \"root=\" boot option\n");
>  
How about adding a loglevel to this printk() while you are at it?  like 
this for instance:
	printk(KERN_ERR "Please append a correct \"root=\" boot option\n");

or maybe that should be KERN_CRIT ...


> +#if 0	/* original code */
>  		panic("VFS: Unable to mount root fs on %s", b);
> +#else
> +		printk ("Waiting 5 seconds to try again...\n");

^^^ And here I think a loglevel of KERN_INFO would be resonable :
	printk (KERN_INFO "Waiting 5 seconds to try mounting root fs again...\n");


> +		set_current_state(TASK_INTERRUPTIBLE);
> +		schedule_timeout(5 * HZ);

I could be mistaken, but I would have said that msleep would have been 
better here.???


> +		goto retry;
> +#endif
>  	}
>  	panic("VFS: Unable to mount root fs on %s", __bdevname(ROOT_DEV, b));

^^^ and this one : 
	panic(KERN_CRIT "VFS: Unable to mount root fs on %s", __bdevname(ROOT_DEV, b));


-- 
Jesper Juhl

Re: waiting 10s before mounting root filesystem?

[William Park]

On Wed, Dec 29, 2004 at 02:38:25AM +0100, Jesper Juhl wrote:
> On Tue, 28 Dec 2004, William Park wrote:
> 
> > On Mon, Dec 27, 2004 at 10:23:34PM +0100, Andreas Unterkircher wrote:
> > > [1] http://www.xenotime.net/linux/usb/usbboot-2422.patch

> > Thanks Andreas.  I can now boot from my el-cheapo USB key drive
> > (256MB SanDisk Cruzer Mini).  Since mine takes about 5sec to show
> > up, I decided to wait 5sec instead of 1sec.  Here is diff for
> > 2.6.10:
> > 
> > --- ./init/do_mounts.c--orig	2004-12-27 17:36:35.000000000 -0500
> > +++ ./init/do_mounts.c	2004-12-28 17:27:26.000000000 -0500
> > @@ -301,7 +301,14 @@ retry:
> >  				root_device_name, b);
> >  		printk("Please append a correct \"root=\" boot option\n");
> >  
> How about adding a loglevel to this printk() while you are at it?  like 
> this for instance:
> 	printk(KERN_ERR "Please append a correct \"root=\" boot option\n");
> 
> or maybe that should be KERN_CRIT ...
> 
> 
> > +#if 0	/* original code */
> >  		panic("VFS: Unable to mount root fs on %s", b);
> > +#else
> > +		printk ("Waiting 5 seconds to try again...\n");
> 
> ^^^ And here I think a loglevel of KERN_INFO would be resonable :
> 	printk (KERN_INFO "Waiting 5 seconds to try mounting root fs again...\n");
> 
> 
> > +		set_current_state(TASK_INTERRUPTIBLE);
> > +		schedule_timeout(5 * HZ);
> 
> I could be mistaken, but I would have said that msleep would have been 
> better here.???
> 
> 
> > +		goto retry;
> > +#endif
> >  	}
> >  	panic("VFS: Unable to mount root fs on %s", __bdevname(ROOT_DEV, b));
> 
> ^^^ and this one : 
> 	panic(KERN_CRIT "VFS: Unable to mount root fs on %s", __bdevname(ROOT_DEV, b));
> 
> 
> -- 
> Jesper Juhl

Jesper, I have no idea what I'm doing. :-) I simply adapted the 2.4
patch for 2.6.10 kernel.

Ideally, motherboard should support booting from USB key drive directly.
I'm told that most modern motherboards do support usbboot, but my
machine doesn't.  So, I trying to load the kernel from floppy (harddisk
for testing purpose).  This is part of my attempt to build Linux
thin-client out of mini-ITX type of computer (Via CLE266 chipset, Via C3
cpu).

Now, I need to find a machine that actually can do usbboot...

-- 
William Park <opengeometry@yahoo.ca>
Open Geometry Consulting, Toronto, Canada
Linux solution for data processing. 

Re: waiting 10s before mounting root filesystem?

[Paulo Marques]

William Park wrote:
>[...]
> 
> Ideally, motherboard should support booting from USB key drive directly.
> I'm told that most modern motherboards do support usbboot, but my
> machine doesn't.  So, I trying to load the kernel from floppy (harddisk
> for testing purpose).  This is part of my attempt to build Linux
> thin-client out of mini-ITX type of computer (Via CLE266 chipset, Via C3
> cpu).
> 
> Now, I need to find a machine that actually can do usbboot...

You will have the same problem even if the BIOS supports booting from 
USB. The BIOS will load the bootloader and map the USB drive as if it 
were a regular disk, so that the INTxx calls (can't say the number from 
memory) that LILO (or another bootloader) uses to load the kernel and 
initrd into memory will work.

After that, the kernel boots the same way as if it were loaded from a 
floppy. It still needs to discover the USB drive to mount the root 
filesystem, and that will still take the 5 seconds you were complaining 
about.

As Trent Lloyd already mentioned, you could solve this using a small 
initrd and a "nash" script, instead of patching the kernel, although I'm 
in favor of a patch of this sort getting into mainline.

After all, what is the use of kernel saying "Panic, can not mount the 
root filesystem" instead of saying "humm... no root file system there. 
Let me try again in a second or so and see if anything as come up..."?

-- 
Paulo Marques - www.grupopie.com

"A journey of a thousand miles begins with a single step."
Lao-tzu, The Way of Lao-tzu

Re: waiting 10s before mounting root filesystem?

[William Park]

On Wed, Dec 29, 2004 at 12:49:02PM +0000, Paulo Marques wrote:
> William Park wrote:
> >[...]
> >
> >Ideally, motherboard should support booting from USB key drive
> >directly.  I'm told that most modern motherboards do support usbboot,
> >but my machine doesn't.  So, I trying to load the kernel from floppy
> >(harddisk for testing purpose).  This is part of my attempt to build
> >Linux thin-client out of mini-ITX type of computer (Via CLE266
> >chipset, Via C3 cpu).
> >
> >Now, I need to find a machine that actually can do usbboot...
> 
> You will have the same problem even if the BIOS supports booting from
> USB. The BIOS will load the bootloader and map the USB drive as if it
> were a regular disk, so that the INTxx calls (can't say the number
> from memory) that LILO (or another bootloader) uses to load the kernel
> and initrd into memory will work.
> 
> After that, the kernel boots the same way as if it were loaded from a
> floppy. It still needs to discover the USB drive to mount the root
> filesystem, and that will still take the 5 seconds you were
> complaining about.

Ah, right. 

> 
> As Trent Lloyd already mentioned, you could solve this using a small
> initrd and a "nash" script, instead of patching the kernel, although
> I'm in favor of a patch of this sort getting into mainline.

I read Documentation/initrd.txt and I don't understand it.  If I
understand it right, I have to build a complete root filesystem with all
the stuffs necessary for mounting the second (real) root filesystem.  If
I'm loading the kernel from floppy, then I only have 200k to work with.
I'll try initrd.txt, step by step over the holidays.

> 
> After all, what is the use of kernel saying "Panic, can not mount the
> root filesystem" instead of saying "humm... no root file system there.
> Let me try again in a second or so and see if anything as come up..."?

-- 
William Park <opengeometry@yahoo.ca>
Open Geometry Consulting, Toronto, Canada
Linux solution for data processing. 

Re: waiting 10s before mounting root filesystem?

[Paulo Marques]

William Park wrote:
> [...]
> I read Documentation/initrd.txt and I don't understand it.  If I
> understand it right, I have to build a complete root filesystem with all
> the stuffs necessary for mounting the second (real) root filesystem.  If
> I'm loading the kernel from floppy, then I only have 200k to work with.
> I'll try initrd.txt, step by step over the holidays.

Yes, but if you use "nash" as a script parser and compile everything you 
need static with dietlibc or uClibc (or some other small libc 
replacement), 200k will be plenty to accomplish what you want. You'll 
probably be able to find pre-compiled binaries like these on the net, if 
you search for them.

Of course this is much more work than simply patch the kernel to wait a 
little, but with this training you'll be able to handle similar 
situations in the future were there is no patch to solve them.

-- 
Paulo Marques - www.grupopie.com

"A journey of a thousand miles begins with a single step."
Lao-tzu, The Way of Lao-tzu

Re: waiting 10s before mounting root filesystem?

[William Park]

On Wed, Dec 29, 2004 at 07:34:07PM +0000, Paulo Marques wrote:
> William Park wrote:
> >[...] I read Documentation/initrd.txt and I don't understand it.  If
> >I understand it right, I have to build a complete root filesystem
> >with all the stuffs necessary for mounting the second (real) root
> >filesystem.  If I'm loading the kernel from floppy, then I only have
> >200k to work with.  I'll try initrd.txt, step by step over the
> >holidays.
> 
> Yes, but if you use "nash" as a script parser and compile everything
> you need static with dietlibc or uClibc (or some other small libc
> replacement), 200k will be plenty to accomplish what you want. You'll
> probably be able to find pre-compiled binaries like these on the net,
> if you search for them.
> 
> Of course this is much more work than simply patch the kernel to wait
> a little, but with this training you'll be able to handle similar
> situations in the future were there is no patch to solve them.

I finally wrote a script to build 200MB root filesystem from Slackware
distribution (A, AP, N, X series).  And, now, you're telling me to build
a 200kB root filesystem?  I need beer...

-- 
William Park <opengeometry@yahoo.ca>
Open Geometry Consulting, Toronto, Canada
Linux solution for data processing. 

Re: waiting 10s before mounting root filesystem?

[Andreas Steinmetz]

William Park wrote:
> I finally wrote a script to build 200MB root filesystem from Slackware
> distribution (A, AP, N, X series).  And, now, you're telling me to build
> a 200kB root filesystem?  I need beer...

You don't need beer, you need busybox. The smallest initrd I made with 
busybox is 99kB (finds boot cdrom and sets up a ram disk as rootfs).

-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

Re: waiting 10s before mounting root filesystem?

[Bernd Eckenfels]

In article <20041229205940.GB3024@node1.opengeometry.net> you wrote:
> I finally wrote a script to build 200MB root filesystem from Slackware
> distribution (A, AP, N, X series).  And, now, you're telling me to build
> a 200kB root filesystem?  I need beer...

You only need to have the one executable file and supporting files like
config files, shells or libs. In case of a static compiled script you need
no libs nor shell. You will probably need some mount and usb tools, not more.


Bernd

Re: waiting 10s before mounting root filesystem?

[Jesper Juhl]

On Wed, 29 Dec 2004, Paulo Marques wrote:

> William Park wrote:
> > [...]
> > I read Documentation/initrd.txt and I don't understand it.  If I
> > understand it right, I have to build a complete root filesystem with all
> > the stuffs necessary for mounting the second (real) root filesystem.  If
> > I'm loading the kernel from floppy, then I only have 200k to work with.
> > I'll try initrd.txt, step by step over the holidays.
> 
> Yes, but if you use "nash" as a script parser and compile everything you need
> static with dietlibc or uClibc (or some other small libc replacement), 200k
> will be plenty to accomplish what you want. You'll probably be able to find
> pre-compiled binaries like these on the net, if you search for them.
> 
ash is also a great little shell for stuff like that - it's very close to 
bash syntax (which most people are familliar with) and it's resonably 
small.

Also, busybox is something you want to take a look at, it's a single 
binary that implements tiny versions of a lot of unix utilities - current 
version implements these (note it includes a tiny ash shell as well): 

addgroup, adduser, adjtimex, ar, arping, ash, awk, basename, bunzip2,
busybox, bzcat, cal, cat, chgrp, chmod, chown, chroot, chvt, clear, cmp,
cp, cpio, crond, crontab, cut, date, dc, dd, deallocvt, delgroup, deluser,
devfsd, df, dirname, dmesg, dos2unix, dpkg, dpkg-deb, du, dumpkmap,
dumpleases, echo, egrep, env, expr, false, fbset, fdflush, fdformat, fdisk,
fgrep, find, fold, free, freeramdisk, fsck.minix, ftpget, ftpput, getopt,
getty, grep, gunzip, gzip, halt, hdparm, head, hexdump, hostid, hostname,
httpd, hush, hwclock, id, ifconfig, ifdown, ifup, inetd, init, insmod,
install, ip, ipaddr, ipcalc, iplink, iproute, iptunnel, kill, killall,
klogd, lash, last, length, linuxrc, ln, loadfont, loadkmap, logger, login,
logname, logread, losetup, ls, lsmod, makedevs, md5sum, mesg, mkdir,
mkfifo, mkfs.minix, mknod, mkswap, mktemp, modprobe, more, mount, msh, mt,
mv, nameif, nc, netstat, nslookup, od, openvt, passwd, patch, pidof, ping,
ping6, pipe_progress, pivot_root, poweroff, printf, ps, pwd, rdate,
readlink, realpath, reboot, renice, reset, rm, rmdir, rmmod, route, rpm,
rpm2cpio, run-parts, rx, sed, seq, setkeycodes, sha1sum, sleep, sort,
start-stop-daemon, strings, stty, su, sulogin, swapoff, swapon, sync,
sysctl, syslogd, tail, tar, tee, telnet, telnetd, test, tftp, time, top,
touch, tr, traceroute, true, tty, udhcpc, udhcpd, umount, uname,
uncompress, uniq, unix2dos, unzip, uptime, usleep, uudecode, uuencode,
vconfig, vi, vlock, watch, watchdog, wc, wget, which, who, whoami, xargs,
yes, zcat

Most of these are ofcourse somewhat limited in functionality compared to 
their full-blown cousins, but for use on a initrd busybox can be close to 
the only app you need, and you can build it to include or exclude the 
commands you need/don't need, so it can get quite tiny.
A static build of busybox with just the commands that you need enabled and 
linked against uClibc or similar is what I would use.

Take a look : http://www.busybox.net/


-- 
Jesper Juhl

Re: waiting 10s before mounting root filesystem?

[Marcelo Tosatti]

On Tue, Dec 28, 2004 at 07:59:22PM -0500, William Park wrote:
> On Mon, Dec 27, 2004 at 10:23:34PM +0100, Andreas Unterkircher wrote:
> > >>How do I make the kernel to wait about 10s before attempting to
> > >>mount root filesystem?  Is there obscure kernel parameter?
> > >>
> > >>I can load the kernel from /dev/fd0, then mount /dev/hda2 as root
> > >>filesystem.  But, I can't seem to mount /dev/sda1 (USB key drive) as
> > >>root filesystem.  All relevant USB and SCSI modules are compiled
> > >>into the kernel.  I think kernel is too fast in panicking.  I would
> > >>like the kernel to wait about 10s until 'usb-storage' and 'sd_mod'
> > >>work out all the details.
> > >
> > >This is really suited to the task of an initrd, then you can spin
> > >until the usb storage device comes up in a bash script or something
> > >similar.
> >
> > Or you could try a patch from Randy Dunlap & Eric Lammerts [1] which 
> > loops around in do_mounts.c
> > until the root filesystem can be mounted.... not that beautiful - but it 
> > works :)
> > 
> > [1] http://www.xenotime.net/linux/usb/usbboot-2422.patch
> > 
> > Cheers,
> > Andreas
> > 
> > PS: In the same manner you can do it with 2.6
> 
> Thanks Andreas.  I can now boot from my el-cheapo USB key drive (256MB
> SanDisk Cruzer Mini).  Since mine takes about 5sec to show up, I decided
> to wait 5sec instead of 1sec.  Here is diff for 2.6.10:
> 
> --- ./init/do_mounts.c--orig	2004-12-27 17:36:35.000000000 -0500
> +++ ./init/do_mounts.c	2004-12-28 17:27:26.000000000 -0500
> @@ -301,7 +301,14 @@ retry:
>  				root_device_name, b);
>  		printk("Please append a correct \"root=\" boot option\n");
>  
> +#if 0	/* original code */
>  		panic("VFS: Unable to mount root fs on %s", b);
> +#else
> +		printk ("Waiting 5 seconds to try again...\n");
> +		set_current_state(TASK_INTERRUPTIBLE);
> +		schedule_timeout(5 * HZ);
> +		goto retry;
> +#endif
>  	}
>  	panic("VFS: Unable to mount root fs on %s", __bdevname(ROOT_DEV, b));
>  out:

William,

Solar version which is now merged in v2.4 looks better (5s sleep is too long and only one try) IMO.

It sleeps 1s each time, 10 times. More reliable and faster.

http://linux.bkbits.net:8080/linux-2.4/patch@1.1527.1.20?nav=index.html|ChangeSet@-3w|cset@1.1527.1.20 

Re: waiting 10s before mounting root filesystem?

[Jesper Juhl]

On Thu, 30 Dec 2004, Marcelo Tosatti wrote:

> On Tue, Dec 28, 2004 at 07:59:22PM -0500, William Park wrote:
> > On Mon, Dec 27, 2004 at 10:23:34PM +0100, Andreas Unterkircher wrote:
> > > >>How do I make the kernel to wait about 10s before attempting to
> > > >>mount root filesystem?  Is there obscure kernel parameter?
> > > >>
> > > >>I can load the kernel from /dev/fd0, then mount /dev/hda2 as root
> > > >>filesystem.  But, I can't seem to mount /dev/sda1 (USB key drive) as
> > > >>root filesystem.  All relevant USB and SCSI modules are compiled
> > > >>into the kernel.  I think kernel is too fast in panicking.  I would
> > > >>like the kernel to wait about 10s until 'usb-storage' and 'sd_mod'
> > > >>work out all the details.
> > > >
> > > >This is really suited to the task of an initrd, then you can spin
> > > >until the usb storage device comes up in a bash script or something
> > > >similar.
> > >
> > > Or you could try a patch from Randy Dunlap & Eric Lammerts [1] which 
> > > loops around in do_mounts.c
> > > until the root filesystem can be mounted.... not that beautiful - but it 
> > > works :)
> > > 
> > > [1] http://www.xenotime.net/linux/usb/usbboot-2422.patch
> > > 
> > > Cheers,
> > > Andreas
> > > 
> > > PS: In the same manner you can do it with 2.6
> > 
> > Thanks Andreas.  I can now boot from my el-cheapo USB key drive (256MB
> > SanDisk Cruzer Mini).  Since mine takes about 5sec to show up, I decided
> > to wait 5sec instead of 1sec.  Here is diff for 2.6.10:
> > 
> > --- ./init/do_mounts.c--orig	2004-12-27 17:36:35.000000000 -0500
> > +++ ./init/do_mounts.c	2004-12-28 17:27:26.000000000 -0500
> > @@ -301,7 +301,14 @@ retry:
> >  				root_device_name, b);
> >  		printk("Please append a correct \"root=\" boot option\n");
> >  
> > +#if 0	/* original code */
> >  		panic("VFS: Unable to mount root fs on %s", b);
> > +#else
> > +		printk ("Waiting 5 seconds to try again...\n");
> > +		set_current_state(TASK_INTERRUPTIBLE);
> > +		schedule_timeout(5 * HZ);
> > +		goto retry;
> > +#endif
> >  	}
> >  	panic("VFS: Unable to mount root fs on %s", __bdevname(ROOT_DEV, b));
> >  out:
> 
> William,
> 
> Solar version which is now merged in v2.4 looks better (5s sleep is too long and only one try) IMO.
> 
> It sleeps 1s each time, 10 times. More reliable and faster.
> 
> http://linux.bkbits.net:8080/linux-2.4/patch@1.1527.1.20?nav=index.html|ChangeSet@-3w|cset@1.1527.1.20 

That's a nice patch. Why not make the same change in 2.6?
I forward ported the patch linked above with a few minor changes - my 
version differs from the original in these ways : 
 - use ssleep() instead of schedule_timeout.
 - rename tries to retries and actually retry the specified nr of times 
   ( if (retries--) {...} instead of  if (--tries) {...} ).
 - use a short instead of int to hold the retry count.
 - change the text outputted a little bit.
 - retry a few more times (15 instead of 9) since if we fail here we are 
   going to panic() we might as well try hard, and who knows how slow some 
   devices can be?

Andrew, would you consider including the patch below in 2.6 ?


Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>

diff -up linux-2.6.10-bk2-orig/init/do_mounts.c linux-2.6.10-bk2/init/do_mounts.c
--- linux-2.6.10-bk2-orig/init/do_mounts.c	2004-12-24 22:34:31.000000000 +0100
+++ linux-2.6.10-bk2/init/do_mounts.c	2004-12-31 00:00:37.000000000 +0100
@@ -6,6 +6,7 @@
 #include <linux/suspend.h>
 #include <linux/root_dev.h>
 #include <linux/security.h>
+#include <linux/delay.h>
 
 #include <linux/nfs_fs.h>
 #include <linux/nfs_fs_sb.h>
@@ -278,6 +279,7 @@ void __init mount_block_root(char *name,
 	char *fs_names = __getname();
 	char *p;
 	char b[BDEVNAME_SIZE];
+	short retries = 15;
 
 	get_fs_names(fs_names);
 retry:
@@ -297,9 +299,16 @@ retry:
 		 * and bad superblock on root device.
 		 */
 		__bdevname(ROOT_DEV, b);
-		printk("VFS: Cannot open root device \"%s\" or %s\n",
+		if (retries--) {
+			printk(KERN_WARNING "VFS: Cannot open root device "
+				"\"%s\" or %s, retrying in 1s.\n",
 				root_device_name, b);
-		printk("Please append a correct \"root=\" boot option\n");
+			ssleep(1);
+			goto retry;
+		}
+		printk(KERN_CRIT "VFS: Cannot open root device \"%s\" or %s, giving up.\n",
+				root_device_name, b);
+		printk(KERN_CRIT "Please append a correct \"root=\" boot option\n");
 
 		panic("VFS: Unable to mount root fs on %s", b);
 	}

Re: waiting 10s before mounting root filesystem?

[William Park]

On Thu, Dec 30, 2004 at 01:25:32PM -0200, Marcelo Tosatti wrote:
> On Tue, Dec 28, 2004 at 07:59:22PM -0500, William Park wrote:
> > On Mon, Dec 27, 2004 at 10:23:34PM +0100, Andreas Unterkircher wrote:
> > > [1] http://www.xenotime.net/linux/usb/usbboot-2422.patch
> > 
> > Thanks Andreas.  I can now boot from my el-cheapo USB key drive
> > (256MB SanDisk Cruzer Mini).  Since mine takes about 5sec to show
> > up, I decided to wait 5sec instead of 1sec.  Here is diff for
> > 2.6.10:
> > 
> > --- ./init/do_mounts.c--orig	2004-12-27 17:36:35.000000000 -0500
> > +++ ./init/do_mounts.c	2004-12-28 17:27:26.000000000 -0500
> > @@ -301,7 +301,14 @@ retry:
> >  				root_device_name, b);
> >  		printk("Please append a correct \"root=\" boot option\n");
> >  
> > +#if 0	/* original code */
> >  		panic("VFS: Unable to mount root fs on %s", b);
> > +#else
> > +		printk ("Waiting 5 seconds to try again...\n");
> > +		set_current_state(TASK_INTERRUPTIBLE);
> > +		schedule_timeout(5 * HZ);
> > +		goto retry;
> > +#endif
> >  	}
> >  	panic("VFS: Unable to mount root fs on %s", __bdevname(ROOT_DEV, b));
> >  out:
> 
> William,
> 
> Solar version which is now merged in v2.4 looks better (5s sleep is
> too long and only one try) IMO.
> 
> It sleeps 1s each time, 10 times. More reliable and faster.
> 
> http://linux.bkbits.net:8080/linux-2.4/patch@1.1527.1.20?nav=index.html|ChangeSet@-3w|cset@1.1527.1.20 

Hi Marcelo,

1.  Actually, my patch above loops every 5s to reduce screen clutter,
    whereas the original 2.4 patch (cited by Andreas Unterkircher) loops
    every 1s.  Both loops forever.

    But, if a limit of 10 tries is what you want, then here is a patch
    for 2.6.10:
====================

--- ./init/do_mounts.c--orig	2004-12-27 17:36:35.000000000 -0500
+++ ./init/do_mounts.c	2004-12-30 18:57:46.000000000 -0500
@@ -278,6 +278,7 @@
 	char *fs_names = __getname();
 	char *p;
 	char b[BDEVNAME_SIZE];
+	int tryagain = 10;
 
 	get_fs_names(fs_names);
 retry:
@@ -297,11 +298,16 @@
 		 * and bad superblock on root device.
 		 */
 		__bdevname(ROOT_DEV, b);
+		if (--tryagain) {
+		    printk ("VFS: Waiting %dsec for root device...\n", tryagain);
+		    set_current_state (TASK_INTERRUPTIBLE);
+		    schedule_timeout (HZ);
+		    goto retry;
+		}
 		printk("VFS: Cannot open root device \"%s\" or %s\n",
 				root_device_name, b);
 		printk("Please append a correct \"root=\" boot option\n");
-
-		panic("VFS: Unable to mount root fs on %s", b);
+		break;
 	}
 	panic("VFS: Unable to mount root fs on %s", __bdevname(ROOT_DEV, b));
 out:

====================

    The only difference are
	- using 'tryagain' instead of 'tries' as counter
	- printing countdown of seconds like
	    VFS: Waiting 9sec for root device...
	    VFS: Waiting 8sec for root device...
	    ...
	    VFS: Waiting 1sec for root device...
	  before printing the final error.


2.  I sincerely hope that this patch get included in the main kernel.
    USB boot is very important feature, and will become the standard way
    of booting Linux thin-client as well as other Linux system, embedded
    or not.  It will make Netboot, Etherboot, PXE boot, CF-to-IDE
    adapter, and initrd all obsolete.

-- 
William Park <opengeometry@yahoo.ca>
Open Geometry Consulting, Toronto, Canada
Linux solution for data processing. 

Re: waiting 10s before mounting root filesystem?

[Jesper Juhl]

William Park wrote:
> On Thu, Dec 30, 2004 at 01:25:32PM -0200, Marcelo Tosatti wrote:
> > On Tue, Dec 28, 2004 at 07:59:22PM -0500, William Park wrote:
> > > On Mon, Dec 27, 2004 at 10:23:34PM +0100, Andreas Unterkircher wrote:
> > > > [1] http://www.xenotime.net/linux/usb/usbboot-2422.patch
> > > 
> > > Thanks Andreas.  I can now boot from my el-cheapo USB key drive
> > > (256MB SanDisk Cruzer Mini).  Since mine takes about 5sec to show
> > > up, I decided to wait 5sec instead of 1sec.  Here is diff for
> > > 2.6.10:
> > > 
> > > --- ./init/do_mounts.c--orig	2004-12-27 17:36:35.000000000 -0500
> > > +++ ./init/do_mounts.c	2004-12-28 17:27:26.000000000 -0500
> > > @@ -301,7 +301,14 @@ retry:
> > >  				root_device_name, b);
> > >  		printk("Please append a correct \"root=\" boot option\n");
> > > 
> > > +#if 0	/* original code */
> > >  		panic("VFS: Unable to mount root fs on %s", b);
> > > +#else
> > > +		printk ("Waiting 5 seconds to try again...\n");
> > > +		set_current_state(TASK_INTERRUPTIBLE);
> > > +		schedule_timeout(5 * HZ);
> > > +		goto retry;
> > > +#endif
> > >  	}
> > >  	panic("VFS: Unable to mount root fs on %s", __bdevname(ROOT_DEV, b));
> > >  out:
> > 
> > William,
> > 
> > Solar version which is now merged in v2.4 looks better (5s sleep is
> > too long and only one try) IMO.
> > 
> > It sleeps 1s each time, 10 times. More reliable and faster.
> > 
> > 
> http://linux.bkbits.net:8080/linux-2.4/patch@1.1527.1.20?nav=index.html|ChangeSet@-3w|cset@1.1527.1.20 
> 
> Hi Marcelo,
> 
> 1.  Actually, my patch above loops every 5s to reduce screen clutter,
>     whereas the original 2.4 patch (cited by Andreas Unterkircher) loops
>     every 1s.  Both loops forever.
> 
>     But, if a limit of 10 tries is what you want, then here is a patch
>     for 2.6.10:

I agree with you that reducing screen clutter is a good thing. How about 
something like this that waits for 10+ seconds so even slow devices have a 
chance to get up but also does some primitive ratelimiting on the messages 
by only printing one every 3 seconds (but still attempting to mount every 
1 sec) ? 

This is a small variation on the patch I posted a little while ago.

Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>

diff -up linux-2.6.10-bk2-orig/init/do_mounts.c linux-2.6.10-bk2/init/do_mounts.c
--- linux-2.6.10-bk2-orig/init/do_mounts.c	2004-12-24 22:34:31.000000000 +0100
+++ linux-2.6.10-bk2/init/do_mounts.c	2004-12-31 02:44:13.000000000 +0100
@@ -6,6 +6,7 @@
 #include <linux/suspend.h>
 #include <linux/root_dev.h>
 #include <linux/security.h>
+#include <linux/delay.h>
 
 #include <linux/nfs_fs.h>
 #include <linux/nfs_fs_sb.h>
@@ -278,6 +279,7 @@ void __init mount_block_root(char *name,
 	char *fs_names = __getname();
 	char *p;
 	char b[BDEVNAME_SIZE];
+	short retries = 15;
 
 	get_fs_names(fs_names);
 retry:
@@ -297,9 +299,17 @@ retry:
 		 * and bad superblock on root device.
 		 */
 		__bdevname(ROOT_DEV, b);
-		printk("VFS: Cannot open root device \"%s\" or %s\n",
+		if (retries--) {
+			if (retries % 3 == 0)
+				printk(KERN_WARNING "VFS: Cannot open root device "
+					"\"%s\" or %s, retrying in 1s.\n",
+					root_device_name, b);
+			ssleep(1);
+			goto retry;
+		}
+		printk(KERN_CRIT "VFS: Cannot open root device \"%s\" or %s, giving up.\n",
 				root_device_name, b);
-		printk("Please append a correct \"root=\" boot option\n");
+		printk(KERN_CRIT "Please append a correct \"root=\" boot option\n");
 
 		panic("VFS: Unable to mount root fs on %s", b);
 	}



> 
> 2.  I sincerely hope that this patch get included in the main kernel.
>     USB boot is very important feature, and will become the standard way
>     of booting Linux thin-client as well as other Linux system, embedded
>     or not.  It will make Netboot, Etherboot, PXE boot, CF-to-IDE
>     adapter, and initrd all obsolete.
> 
I agree, some version of this should go into 2.6. If we can successfully 
get the system up and running by retrying the root fs mount a few times 
then that's a lot better than panicking :)


-- 
Jesper Juhl


PS. Sorry if I messed up the thread a bit, but I had some mailserver 
trouble and lost a few LKML mails so I couldn't reply directly to the 
proper mail.

Re: waiting 10s before mounting root filesystem?

[William Park]

On Fri, Dec 31, 2004 at 02:45:53AM +0100, Jesper Juhl wrote:
> William Park wrote:
> > On Thu, Dec 30, 2004 at 01:25:32PM -0200, Marcelo Tosatti wrote:
> > > On Tue, Dec 28, 2004 at 07:59:22PM -0500, William Park wrote:
> > > > On Mon, Dec 27, 2004 at 10:23:34PM +0100, Andreas Unterkircher wrote:
> > > > > [1] http://www.xenotime.net/linux/usb/usbboot-2422.patch
...
> > http://linux.bkbits.net:8080/linux-2.4/patch@1.1527.1.20?nav=index.html|ChangeSet@-3w|cset@1.1527.1.20 
> > 
> > Hi Marcelo,
> > 
> > 1.  Actually, my patch above loops every 5s to reduce screen clutter,
> >     whereas the original 2.4 patch (cited by Andreas Unterkircher) loops
> >     every 1s.  Both loops forever.
> > 
> >     But, if a limit of 10 tries is what you want, then here is a patch
> >     for 2.6.10:
> 
> I agree with you that reducing screen clutter is a good thing. How
> about something like this that waits for 10+ seconds so even slow
> devices have a chance to get up but also does some primitive
> ratelimiting on the messages by only printing one every 3 seconds (but
> still attempting to mount every 1 sec) ? 

Hi Jesper,

I prefer countdown with short message.  The 2.4 messages are too long.
Incorporating your use of ssleep() and printk() loglevel, here is
the latest iteration:

--- ./init/do_mounts.c--orig	2004-12-27 17:36:35.000000000 -0500
+++ ./init/do_mounts.c	2004-12-30 22:43:57.000000000 -0500
@@ -6,6 +6,7 @@
 #include <linux/suspend.h>
 #include <linux/root_dev.h>
 #include <linux/security.h>
+#include <linux/delay.h>
 
 #include <linux/nfs_fs.h>
 #include <linux/nfs_fs_sb.h>
@@ -278,6 +279,7 @@
 	char *fs_names = __getname();
 	char *p;
 	char b[BDEVNAME_SIZE];
+	int tryagain = 20;
 
 	get_fs_names(fs_names);
 retry:
@@ -297,9 +299,13 @@
 		 * and bad superblock on root device.
 		 */
 		__bdevname(ROOT_DEV, b);
-		printk("VFS: Cannot open root device \"%s\" or %s\n",
-				root_device_name, b);
-		printk("Please append a correct \"root=\" boot option\n");
+		if (--tryagain) {
+		    printk (KERN_WARNING "VFS: Waiting %dsec for root device...\n", tryagain);
+		    ssleep (1);
+		    goto retry;
+		}
+		printk (KERN_CRIT "VFS: Cannot open root device \"%s\" or %s\n", root_device_name, b);
+		printk (KERN_CRIT "Please append a correct \"root=\" boot option\n");
 
 		panic("VFS: Unable to mount root fs on %s", b);
 	}

Re: waiting 10s before mounting root filesystem?

[Jesper Juhl]

On Thu, 30 Dec 2004, William Park wrote:

> On Fri, Dec 31, 2004 at 02:45:53AM +0100, Jesper Juhl wrote:
> > William Park wrote:
> > > On Thu, Dec 30, 2004 at 01:25:32PM -0200, Marcelo Tosatti wrote:
> > > > On Tue, Dec 28, 2004 at 07:59:22PM -0500, William Park wrote:
> > > > > On Mon, Dec 27, 2004 at 10:23:34PM +0100, Andreas Unterkircher wrote:
> > > > > > [1] http://www.xenotime.net/linux/usb/usbboot-2422.patch
> ...
> > > http://linux.bkbits.net:8080/linux-2.4/patch@1.1527.1.20?nav=index.html|ChangeSet@-3w|cset@1.1527.1.20 
> > > 
> > > Hi Marcelo,
> > > 
> > > 1.  Actually, my patch above loops every 5s to reduce screen clutter,
> > >     whereas the original 2.4 patch (cited by Andreas Unterkircher) loops
> > >     every 1s.  Both loops forever.
> > > 
> > >     But, if a limit of 10 tries is what you want, then here is a patch
> > >     for 2.6.10:
> > 
> > I agree with you that reducing screen clutter is a good thing. How
> > about something like this that waits for 10+ seconds so even slow
> > devices have a chance to get up but also does some primitive
> > ratelimiting on the messages by only printing one every 3 seconds (but
> > still attempting to mount every 1 sec) ? 
> 
> Hi Jesper,
> 
> I prefer countdown with short message.  The 2.4 messages are too long.
> Incorporating your use of ssleep() and printk() loglevel, here is
> the latest iteration:
> 
> --- ./init/do_mounts.c--orig	2004-12-27 17:36:35.000000000 -0500
> +++ ./init/do_mounts.c	2004-12-30 22:43:57.000000000 -0500
> @@ -6,6 +6,7 @@
>  #include <linux/suspend.h>
>  #include <linux/root_dev.h>
>  #include <linux/security.h>
> +#include <linux/delay.h>
>  
>  #include <linux/nfs_fs.h>
>  #include <linux/nfs_fs_sb.h>
> @@ -278,6 +279,7 @@
>  	char *fs_names = __getname();
>  	char *p;
>  	char b[BDEVNAME_SIZE];
> +	int tryagain = 20;
>  
Ok, I'm nitpicking here, but why int and not short? are we likely to ever
want to wait for more than 2 minutes? and if we want to wait ~3min, then
unsigned short should do just fine (and unsigned would even be logical
since negative retry value doesn't make any sense)....


> +		if (--tryagain) {

I think if  (tryagain--)  makes more sense. You set tryagain to 20 thereby 
implying that we will be doing 20 retries, but with --tryagain we will 
only be doing 19 retries, not 20 - with tryagain-- we will be doing the 
nr. of retries that we initially initialize 'tryagain' to.

other than that (and it /is/ nitpicking) the patch looks good to me.


-- 
Jesper Juhl

Re: waiting 10s before mounting root filesystem?

[Marcelo Tosatti]

On Fri, Dec 31, 2004 at 01:49:05AM -0800, Andrew Morton wrote:
> William Park <opengeometry@yahoo.ca> wrote:
> >
> > -		printk("VFS: Cannot open root device \"%s\" or %s\n",
> >  -				root_device_name, b);
> >  -		printk("Please append a correct \"root=\" boot option\n");
> >  +		if (--tryagain) {
> >  +		    printk (KERN_WARNING "VFS: Waiting %dsec for root device...\n", tryagain);
> >  +		    ssleep (1);
> >  +		    goto retry;
> >  +		}
> >  +		printk (KERN_CRIT "VFS: Cannot open root device \"%s\" or %s\n", root_device_name, b);
> >  +		printk (KERN_CRIT "Please append a correct \"root=\" boot option\n");
> 
> Why is this patch needed?  If it is to offer the user a chance to insert
> the correct medium or to connect the correct device, 

The media may take a while to become readable (think of CDROM).

> why not rely upon the user doing that thing and then hitting reset? 

I think this is not the case (only) case the patch covers up.

Yes its ugly.

Re: waiting 10s before mounting root filesystem?

[Marcelo Tosatti]

On Fri, Dec 31, 2004 at 11:26:34AM +0000, Paulo Marques wrote:
> Andrew Morton wrote:
> >William Park <opengeometry@yahoo.ca> wrote:
> >
> >>-		printk("VFS: Cannot open root device \"%s\" or %s\n",
> >>-				root_device_name, b);
> >>-		printk("Please append a correct \"root=\" boot option\n");
> >>+		if (--tryagain) {
> >>+		    printk (KERN_WARNING "VFS: Waiting %dsec for root 
> >>device...\n", tryagain);
> >>+		    ssleep (1);
> >>+		    goto retry;
> >>+		}
> >>+		printk (KERN_CRIT "VFS: Cannot open root device \"%s\" or 
> >>%s\n", root_device_name, b);
> >>+		printk (KERN_CRIT "Please append a correct \"root=\" boot 
> >>option\n");
> >
> >
> >Why is this patch needed?  If it is to offer the user a chance to insert
> >the correct medium or to connect the correct device, why not rely upon the
> >user doing that thing and then hitting reset?
> 
> No, no. The problem is not user interaction.
> 
> The problem is that the USB subsystem takes a lot of time to go through 
> the hostcontrollers -> hubs -> devices. By the time it finds the USB 
> mass storage that is supposed to be used as root filesystem, the kernel 
> had already panic'ed.
> 
> IMHO the kernel should handle this case just fine, without the need for 
> initrd's. After all the user says "my root filesystem is /dev/sda1", and 
> the kernel panic's even though the filesystem is there. This doesn't 
> seem like a correct bahavior.

Well, Paulo's has more of a clue than I do. 

Some CD drives suffer from the same issues.

Re: waiting 10s before mounting root filesystem?

[Andrew Morton]

William Park <opengeometry@yahoo.ca> wrote:
>
> -		printk("VFS: Cannot open root device \"%s\" or %s\n",
>  -				root_device_name, b);
>  -		printk("Please append a correct \"root=\" boot option\n");
>  +		if (--tryagain) {
>  +		    printk (KERN_WARNING "VFS: Waiting %dsec for root device...\n", tryagain);
>  +		    ssleep (1);
>  +		    goto retry;
>  +		}
>  +		printk (KERN_CRIT "VFS: Cannot open root device \"%s\" or %s\n", root_device_name, b);
>  +		printk (KERN_CRIT "Please append a correct \"root=\" boot option\n");

Why is this patch needed?  If it is to offer the user a chance to insert
the correct medium or to connect the correct device, why not rely upon the
user doing that thing and then hitting reset?

Re: waiting 10s before mounting root filesystem?

[Paulo Marques]

Andrew Morton wrote:
> William Park <opengeometry@yahoo.ca> wrote:
> 
>>-		printk("VFS: Cannot open root device \"%s\" or %s\n",
>> -				root_device_name, b);
>> -		printk("Please append a correct \"root=\" boot option\n");
>> +		if (--tryagain) {
>> +		    printk (KERN_WARNING "VFS: Waiting %dsec for root device...\n", tryagain);
>> +		    ssleep (1);
>> +		    goto retry;
>> +		}
>> +		printk (KERN_CRIT "VFS: Cannot open root device \"%s\" or %s\n", root_device_name, b);
>> +		printk (KERN_CRIT "Please append a correct \"root=\" boot option\n");
> 
> 
> Why is this patch needed?  If it is to offer the user a chance to insert
> the correct medium or to connect the correct device, why not rely upon the
> user doing that thing and then hitting reset?

No, no. The problem is not user interaction.

The problem is that the USB subsystem takes a lot of time to go through 
the hostcontrollers -> hubs -> devices. By the time it finds the USB 
mass storage that is supposed to be used as root filesystem, the kernel 
had already panic'ed.

IMHO the kernel should handle this case just fine, without the need for 
initrd's. After all the user says "my root filesystem is /dev/sda1", and 
the kernel panic's even though the filesystem is there. This doesn't 
seem like a correct bahavior.

-- 
Paulo Marques - www.grupopie.com

"A journey of a thousand miles begins with a single step."
Lao-tzu, The Way of Lao-tzu

Re: waiting 10s before mounting root filesystem?

[Paulo Marques]

Jesper Juhl wrote:
> [...]
>> #include <linux/nfs_fs.h>
>> #include <linux/nfs_fs_sb.h>
>>@@ -278,6 +279,7 @@
>> 	char *fs_names = __getname();
>> 	char *p;
>> 	char b[BDEVNAME_SIZE];
>>+	int tryagain = 20;
>> 
> 
> Ok, I'm nitpicking here, but why int and not short? are we likely to ever
> want to wait for more than 2 minutes? and if we want to wait ~3min, then
> unsigned short should do just fine (and unsigned would even be logical
> since negative retry value doesn't make any sense)....

Usually it is better to use int's instead of short's because memory 
accesses for CPU word size data are faster.

With some CPUs, decrementing a short will probably involve reading a int 
from memory, updating only the correct section of it, and then writing 
an int. It is only worth the save if you're trying to make a very used 
struct have a good 2^N size, or something like that.

Of course, things will get more complex with data caches, bus sizes, 
etc., but I think the premise that the CPU will be more confortable 
handling its native data size still holds.

-- 
Paulo Marques - www.grupopie.com

"A journey of a thousand miles begins with a single step."
Lao-tzu, The Way of Lao-tzu

Re: waiting 10s before mounting root filesystem?

[Andrew Morton]

Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
>
> On Fri, Dec 31, 2004 at 01:49:05AM -0800, Andrew Morton wrote:
> > William Park <opengeometry@yahoo.ca> wrote:
> > >
> > > -		printk("VFS: Cannot open root device \"%s\" or %s\n",
> > >  -				root_device_name, b);
> > >  -		printk("Please append a correct \"root=\" boot option\n");
> > >  +		if (--tryagain) {
> > >  +		    printk (KERN_WARNING "VFS: Waiting %dsec for root device...\n", tryagain);
> > >  +		    ssleep (1);
> > >  +		    goto retry;
> > >  +		}
> > >  +		printk (KERN_CRIT "VFS: Cannot open root device \"%s\" or %s\n", root_device_name, b);
> > >  +		printk (KERN_CRIT "Please append a correct \"root=\" boot option\n");
> > 
> > Why is this patch needed?  If it is to offer the user a chance to insert
> > the correct medium or to connect the correct device, 
> 
> The media may take a while to become readable (think of CDROM).
> 

But the device driver should wait while the media spins up.  If it doesn't,
the kernel would get I/O errors all over the place in normal operation.

Re: waiting 10s before mounting root filesystem?

[Andrew Morton]

Paulo Marques <pmarques@grupopie.com> wrote:
>
> Andrew Morton wrote:
> > William Park <opengeometry@yahoo.ca> wrote:
> > 
> >>-		printk("VFS: Cannot open root device \"%s\" or %s\n",
> >> -				root_device_name, b);
> >> -		printk("Please append a correct \"root=\" boot option\n");
> >> +		if (--tryagain) {
> >> +		    printk (KERN_WARNING "VFS: Waiting %dsec for root device...\n", tryagain);
> >> +		    ssleep (1);
> >> +		    goto retry;
> >> +		}
> >> +		printk (KERN_CRIT "VFS: Cannot open root device \"%s\" or %s\n", root_device_name, b);
> >> +		printk (KERN_CRIT "Please append a correct \"root=\" boot option\n");
> > 
> > 
> > Why is this patch needed?  If it is to offer the user a chance to insert
> > the correct medium or to connect the correct device, why not rely upon the
> > user doing that thing and then hitting reset?
> 
> No, no. The problem is not user interaction.
> 
> The problem is that the USB subsystem takes a lot of time to go through 
> the hostcontrollers -> hubs -> devices. By the time it finds the USB 
> mass storage that is supposed to be used as root filesystem, the kernel 
> had already panic'ed.

That would be a USB bug, surely.  If /dev/usb/foo is present and
functioning correctly, and higher-level code tries to access that device,
USB should _not_ error out - it should block the caller until everything is
sorted out.

Re: waiting 10s before mounting root filesystem?

[Paulo Marques]

Andrew Morton wrote:
> Paulo Marques <pmarques@grupopie.com> wrote:
> 
>>Andrew Morton wrote:
>>
>>>William Park <opengeometry@yahoo.ca> wrote:
>>>
>>>
>>>>-		printk("VFS: Cannot open root device \"%s\" or %s\n",
>>>>-				root_device_name, b);
>>>>-		printk("Please append a correct \"root=\" boot option\n");
>>>>+		if (--tryagain) {
>>>>+		    printk (KERN_WARNING "VFS: Waiting %dsec for root device...\n", tryagain);
>>>>+		    ssleep (1);
>>>>+		    goto retry;
>>>>+		}
>>>>+		printk (KERN_CRIT "VFS: Cannot open root device \"%s\" or %s\n", root_device_name, b);
>>>>+		printk (KERN_CRIT "Please append a correct \"root=\" boot option\n");
>>>
>>>
>>>Why is this patch needed?  If it is to offer the user a chance to insert
>>>the correct medium or to connect the correct device, why not rely upon the
>>>user doing that thing and then hitting reset?
>>
>>No, no. The problem is not user interaction.
>>
>>The problem is that the USB subsystem takes a lot of time to go through 
>>the hostcontrollers -> hubs -> devices. By the time it finds the USB 
>>mass storage that is supposed to be used as root filesystem, the kernel 
>>had already panic'ed.
> 
> 
> That would be a USB bug, surely.  If /dev/usb/foo is present and
> functioning correctly, and higher-level code tries to access that device,
> USB should _not_ error out - it should block the caller until everything is
> sorted out.

The problem is that, if you use udev (or iack, iack, cough, cough, 
devfs), the device node is not yet present at the time the kernel tries 
to mount it, although the hardware is physically there. This is because 
the USB subsystem is busy going through all the USB tree, enumerating / 
reseting devices, powering hubs, etc.

I really don't know enough about the internal details, but it seems that 
the USB startup sequence is asynchronous with respect to the rest of the 
boot sequence. This is usually allright (I really don't want the 
detection of my USB scanner to hold back my boot), but in the special 
case where the root filesystem is in a USB mass storage device, it poses 
a real problem.

Maybe someone like Grek Kroah, Alan Stern, etc., can shed some more 
light on this matter.

-- 
Paulo Marques - www.grupopie.com

"A journey of a thousand miles begins with a single step."
Lao-tzu, The Way of Lao-tzu

Re: waiting 10s before mounting root filesystem?

[William Park]

On Fri, Dec 31, 2004 at 03:42:57AM -0800, Andrew Morton wrote:
> Paulo Marques <pmarques@grupopie.com> wrote:
> >
> > Andrew Morton wrote:
> > > Why is this patch needed?  If it is to offer the user a chance to
> > > insert the correct medium or to connect the correct device, why
> > > not rely upon the user doing that thing and then hitting reset?
> > 
> > No, no. The problem is not user interaction.
> > 
> > The problem is that the USB subsystem takes a lot of time to go
> > through the hostcontrollers -> hubs -> devices. By the time it finds
> > the USB mass storage that is supposed to be used as root filesystem,
> > the kernel had already panic'ed.
> 
> That would be a USB bug, surely.  If /dev/usb/foo is present and
> functioning correctly, and higher-level code tries to access that
> device, USB should _not_ error out - it should block the caller until
> everything is sorted out.

My USB key drive takes 5s to show up as SCSI, from the moment 'uhci_hcd'
and 'usb-storage' spit out message.  I don't know why.  Internally, USB
key drive is solid state flash memory, so it should be faster than any
spinning disks.

The USB key drive works when I load the USB/SCSI modules as modules.
But, when I boot all-compiled-in-kernel and try to mount /dev/sda1 as
root device, the kernel panicks before the USB key drive has chance to
register.  This means that in order to do 'usbboot', one must go through
the contorted process of 'initrd' which is advocated only by special
interest group whose embedded world is one patch way from becoming
obsolete.

Re: waiting 10s before mounting root filesystem?

[Tomasz Torcz]

On Fri, Dec 31, 2004 at 12:36:43PM -0500, William Park wrote:
> My USB key drive takes 5s to show up as SCSI, from the moment 'uhci_hcd'
> and 'usb-storage' spit out message.  I don't know why.  Internally, USB
> key drive is solid state flash memory, so it should be faster than any
> spinning disks.

 USB keys driven by UB driver come up instantly.

-- 
Tomasz Torcz               RIP is irrevelant. Spoofing is futile.
zdzichu@irc.-nie.spam-.pl     Your routes will be aggreggated. -- Alex Yuriev

Re: waiting 10s before mounting root filesystem?

[William Park]

On Fri, Dec 31, 2004 at 05:49:34PM +0000, Tomasz Torcz wrote:
> On Fri, Dec 31, 2004 at 12:36:43PM -0500, William Park wrote:
> > My USB key drive takes 5s to show up as SCSI, from the moment 'uhci_hcd'
> > and 'usb-storage' spit out message.  I don't know why.  Internally, USB
> > key drive is solid state flash memory, so it should be faster than any
> > spinning disks.
> 
>  USB keys driven by UB driver come up instantly.

Kernel Helpfile says:

    CONFIG_BLK_DEV_UB:
	This driver supports certain USB attached storage devices
	such as flash keys.
	Warning: Enabling this cripples the usb-storage driver.
	If unsure, say N.

I need 'usb-storage', because USB key drive is supposed to be portable
harddisk.

Re: waiting 10s before mounting root filesystem?

[Willy Tarreau]

On Wed, Dec 29, 2004 at 10:26:11PM +0100, Andreas Steinmetz wrote:
> William Park wrote:
> >I finally wrote a script to build 200MB root filesystem from Slackware
> >distribution (A, AP, N, X series).  And, now, you're telling me to build
> >a 200kB root filesystem?  I need beer...
> 
> You don't need beer, you need busybox. The smallest initrd I made with 
> busybox is 99kB (finds boot cdrom and sets up a ram disk as rootfs).

Hmmm... Since we have the equivalent function in slightly less than 7 kB in
Formilux, I think that I should document a bit more when I have some time so
that others can reuse it... I find it a shame to still need 99 kB to find a
CDROM, particularly when you need to put this on floppies.

Regards,
Willy

Re: waiting 10s before mounting root filesystem?

[Bodo Eggert]

Jesper Juhl wrote:

> I agree with you that reducing screen clutter is a good thing. How about
> something like this that waits for 10+ seconds so even slow devices have a
> chance to get up but also does some primitive ratelimiting on the messages
> by only printing one every 3 seconds (but still attempting to mount every
> 1 sec) ?

a) Print every 4 seconds, this will replace one division by a bit-test:
... int retries = 32 ...
... if (! (retries & 0x3)) /* is a multiple of 4 */ ...

I choose 32 because I saw SCSI controlers taking an enormous amount of time
until detecting all devices. Maybe it's still too low for bus 7 id 15, but
I'd wait for someone to complain.

b) I saw no benefit from using 'short' instead of 'int' when I did a small
test (with uudecoding on i386) some time ago, but I could make the
resulting code be smaller and use less memory accesses by introducing some
temporary ints to hold the chars I was operating upon. Are there contrary
experiences that lead to using 'short' here?

c) This patch will sleep for a second after the last try before it
continues to panic. It's OK for me, but maybe there is a better way of
doing this.

@ Andrew Morton:

The patch with a timeout is needed because the machine might be on a
remote location and rebooted using lilo's once-only feature. An automatic
reset after the panic will bring it back.