optional delay after partition detection at boot time

optional delay after partition detection at boot time

[subbie subbie]

Hello,

 I'm sure some of you have come across this annoying
issue, the kernel messages scroll way too fast for a
human to be able to read them (let alone vgrep them).

 I'm proposing two features;

 1. a configurable (boot time, via kernel command
line) delay between each and every print -- kind of
overkill, but may be useful sometimes. 
 
 2. a configurable (boot time, via kernel command
line) delay after partition detection, so that a
humble system administrator would be able to actually
find out which partition he should specify at boot
time in order to boot his system.   This is especially
annoying on newer SATA systems where sometimes disks
are detected as SCSI and sometimes as standard ATA
(depending on BIOS settings), I'm sure though that it
could be useful in a number of other cases.

 Let the flames begin

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: optional delay after partition detection at boot time

[Jan Engelhardt]

>human to be able to read them (let alone vgrep them).

dmesg | grep

> Let the flames begin

/* Write it, it's just a mdelay() or sort of in printk(). */



Jan Engelhardt                                                               
--                                                                            

Re: optional delay after partition detection at boot time

[Willy Tarreau]

On Sat, Jun 11, 2005 at 11:50:50PM -0700, subbie subbie wrote:
> Hello,
> 
>  I'm sure some of you have come across this annoying
> issue, the kernel messages scroll way too fast for a
> human to be able to read them (let alone vgrep them).
> 
>  I'm proposing two features;
> 
>  1. a configurable (boot time, via kernel command
> line) delay between each and every print -- kind of
> overkill, but may be useful sometimes. 
>  
>  2. a configurable (boot time, via kernel command
> line) delay after partition detection, so that a
> humble system administrator would be able to actually
> find out which partition he should specify at boot
> time in order to boot his system.   This is especially
> annoying on newer SATA systems where sometimes disks
> are detected as SCSI and sometimes as standard ATA
> (depending on BIOS settings), I'm sure though that it
> could be useful in a number of other cases.

What's the problem with "cat /proc/partitions" or "dmesg" ?
You seem to want to slow down *every* boot just to identify
a partition you need to find *once*. This seems overkill.

willy

Re: optional delay after partition detection at boot time

[subbie subbie]

Willy,
 
 This is for a one-time use option, when the the admin
is having a hard time finding the root partition, let
alone the device NAME to boot the system ... proc is
not even mounted at that point yet.

 I can try booting ten times finding the correct scsi
device and partition number, but that's hairy
especially in situations where kernel config and BIOS
settings affect device detection.
 
 This is not for slowing everything down, let's say
just until root is mounted from then on, as you say,
dmesg and the system logs are available.

--- Willy Tarreau <willy@w.ods.org> wrote:

> On Sat, Jun 11, 2005 at 11:50:50PM -0700, subbie
> subbie wrote:
> > Hello,
> > 
> >  I'm sure some of you have come across this
> annoying
> > issue, the kernel messages scroll way too fast for
> a
> > human to be able to read them (let alone vgrep
> them).
> > 
> >  I'm proposing two features;
> > 
> >  1. a configurable (boot time, via kernel command
> > line) delay between each and every print -- kind
> of
> > overkill, but may be useful sometimes. 
> >  
> >  2. a configurable (boot time, via kernel command
> > line) delay after partition detection, so that a
> > humble system administrator would be able to
> actually
> > find out which partition he should specify at boot
> > time in order to boot his system.   This is
> especially
> > annoying on newer SATA systems where sometimes
> disks
> > are detected as SCSI and sometimes as standard ATA
> > (depending on BIOS settings), I'm sure though that
> it
> > could be useful in a number of other cases.
> 
> What's the problem with "cat /proc/partitions" or
> "dmesg" ?
> You seem to want to slow down *every* boot just to
> identify
> a partition you need to find *once*. This seems
> overkill.
> 
> willy
> 
> 



		
__________________________________ 
Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html 

Re: optional delay after partition detection at boot time

[Willy Tarreau]

On Sun, Jun 12, 2005 at 03:15:14AM -0700, subbie subbie wrote:
> Willy,
>  
>  This is for a one-time use option, when the the admin
> is having a hard time finding the root partition, let
> alone the device NAME to boot the system ... proc is
> not even mounted at that point yet.

There are two alternatives at boot :

  - either you know the root device, and everything is
    OK (mount /proc; cat /proc/partitions)

  - you don't know the root device, so the kernel will
    panic at boot because it cannot find the root device.
    In this case, you have the partition list still on
    the screen as it's among the latest things in the
    boot order. And if your kernel reboots upon panic,
    just boot it with panic=30 so get 30 seconds to read
    the partition table.

> I can try booting ten times finding the correct scsi
> device and partition number, but that's hairy
> especially in situations where kernel config and BIOS
> settings affect device detection.

I too know that it's sometimes hard to read SCSI devices
names on screen during the boot, but I'm not sure that
introducing a delay will be more useful than the full
pause provided by the panic. I may be wrong, though.
 
> This is not for slowing everything down, let's say
> just until root is mounted from then on, as you say,
> dmesg and the system logs are available.

OK.

Regards,
willy

Re: optional delay after partition detection at boot time

[Jan Engelhardt]

>
>  - you don't know the root device, so the kernel will
>    panic at boot because it cannot find the root device.
>    In this case, you have the partition list still on
>    the screen as it's among the latest things in the
>    boot order. And if your kernel reboots upon panic,
>    just boot it with panic=30 so get 30 seconds to read
>    the partition table.

And, I might add, boot with vga=6 to get a *BIG* screen, so you won't miss any 
messages.



Jan Engelhardt                                                               
--                                                                            
| Gesellschaft fuer Wissenschaftliche Datenverarbeitung Goettingen,
| Am Fassberg, 37077 Goettingen, www.gwdg.de

Re: optional delay after partition detection at boot time

[David Lang]

On Sun, 12 Jun 2005, Willy Tarreau wrote:

>  - you don't know the root device, so the kernel will
>    panic at boot because it cannot find the root device.
>    In this case, you have the partition list still on
>    the screen as it's among the latest things in the
>    boot order. And if your kernel reboots upon panic,
>    just boot it with panic=30 so get 30 seconds to read
>    the partition table.

I have one machine inmy lab that turns out to need to boot from /dev/sdq1

trust me, that partition info has LONG since scrolled off the screen by 
the time it fails to mount and panics.

I ended up setting up a serial console to capture the boot to figure this 
machine out, but that's a pretty extreme measure to have to go to.

David Lang

P.S. I had to do this after grub failed to mount by label (my guess is 
that grub only looks at so many drives before giving up on finding the 
label) so don't tell me that I should just use labels and then I wouldn't 
have to worry about this type of thing

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: optional delay after partition detection at boot time

[Willy Tarreau]

On Sun, Jun 12, 2005 at 07:22:45PM -0700, David Lang wrote:
> On Sun, 12 Jun 2005, Willy Tarreau wrote:
> 
> > - you don't know the root device, so the kernel will
> >   panic at boot because it cannot find the root device.
> >   In this case, you have the partition list still on
> >   the screen as it's among the latest things in the
> >   boot order. And if your kernel reboots upon panic,
> >   just boot it with panic=30 so get 30 seconds to read
> >   the partition table.
> 
> I have one machine inmy lab that turns out to need to boot from /dev/sdq1
> 
> trust me, that partition info has LONG since scrolled off the screen by 
> the time it fails to mount and panics.

Interesting. How many total partitions do you have ? I ask this because
David Alan Gilbert proposed a patch to dump the partition list on the
screen upon panic. Perhaps it's larger than the screen in you case ? If
you have more than 25 partitions, to you think they can fit with 2 or 3
columns ?

> I ended up setting up a serial console to capture the boot to figure this 
> machine out, but that's a pretty extreme measure to have to go to.
> 
> David Lang
> 
> P.S. I had to do this after grub failed to mount by label (my guess is 
> that grub only looks at so many drives before giving up on finding the 
> label) so don't tell me that I should just use labels and then I wouldn't 
> have to worry about this type of thing

I wouldn't tell you that, I *hate* labels. It causes lots of problems
when you simply move some disks between machines.

Regards,
Willy

Re: optional delay after partition detection at boot time

[David Lang]

> Interesting. How many total partitions do you have ? I ask this because
> David Alan Gilbert proposed a patch to dump the partition list on the
> screen upon panic. Perhaps it's larger than the screen in you case ? If
> you have more than 25 partitions, to you think they can fit with 2 or 3
> columns ?

This machine has 16 SATA drives with 1 partition each plus a (hardware) 
mirrored pair of SCSI drives with 4 partions, so only 20 partitions total 
in my config. however there are people who use more drives then this.

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: optional delay after partition detection at boot time

[Geert Uytterhoeven]

On Sun, 12 Jun 2005, Willy Tarreau wrote:
> On Sat, Jun 11, 2005 at 11:50:50PM -0700, subbie subbie wrote:
> >  I'm sure some of you have come across this annoying
> > issue, the kernel messages scroll way too fast for a
> > human to be able to read them (let alone vgrep them).
> > 
> >  I'm proposing two features;
> > 
> >  1. a configurable (boot time, via kernel command
> > line) delay between each and every print -- kind of
> > overkill, but may be useful sometimes. 
> >  
> >  2. a configurable (boot time, via kernel command
> > line) delay after partition detection, so that a
> > humble system administrator would be able to actually
> > find out which partition he should specify at boot
> > time in order to boot his system.   This is especially
> > annoying on newer SATA systems where sometimes disks
> > are detected as SCSI and sometimes as standard ATA
> > (depending on BIOS settings), I'm sure though that it
> > could be useful in a number of other cases.
> 
> What's the problem with "cat /proc/partitions" or "dmesg" ?
> You seem to want to slow down *every* boot just to identify
> a partition you need to find *once*. This seems overkill.

Or make the kernel print /proc/partitions when it is unable to mount root?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: optional delay after partition detection at boot time

[Dr. David Alan Gilbert]

* Geert Uytterhoeven (geert@linux-m68k.org) wrote:

> Or make the kernel print /proc/partitions when it is unable to mount root?

I posted a patch in February to do this:

http://marc.theaimsgroup.com/?l=linux-kernel&m=110946077026065&w=2

Dave
--
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: optional delay after partition detection at boot time

[Willy Tarreau]

On Sun, Jun 12, 2005 at 12:05:39PM +0100, Dr. David Alan Gilbert wrote:
> * Geert Uytterhoeven (geert@linux-m68k.org) wrote:
> 
> > Or make the kernel print /proc/partitions when it is unable to mount root?
> 
> I posted a patch in February to do this:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=110946077026065&w=2

This is even better ! I will probably backport it to 2.4 to merge in my
kernels ;-)

thanks,
Willy

Re: optional delay after partition detection at boot time

[Dr. David Alan Gilbert]

* Willy Tarreau (willy@w.ods.org) wrote:
> On Sun, Jun 12, 2005 at 12:05:39PM +0100, Dr. David Alan Gilbert wrote:
> > * Geert Uytterhoeven (geert@linux-m68k.org) wrote:
> > 
> > > Or make the kernel print /proc/partitions when it is unable to mount root?
> > 
> > I posted a patch in February to do this:
> > 
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=110946077026065&w=2
> 
> This is even better ! I will probably backport it to 2.4 to merge in my
> kernels ;-)

That would be nice (I'd like to see it in 2.6); I wrote it for two reasons:
   1) Because often the info you need has already scrolled off
    and because of the panic you can't scroll back.

   2) When talking to users on help channels the only thing they
     can normally tell you is the last 'failed to mount root' line
     and don't really no what to look back for, by having a
     few line summary you can more easily get someone to type out.

1) could be cured by not actually panic'ing.

Dave
--
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: optional delay after partition detection at boot time

[Andi Kleen]

"Dr. David Alan Gilbert" <dave@treblig.org> writes:
>
> 1) could be cured by not actually panic'ing.

Actually one thing I always wanted was to make sysrq still work 
after panic. Then you could add a key to page through the dmesg
there too and the problem would be solved.

It would be extremly useful to reset remote servers when panic=timeout
is not set, but something went wrong with mounting /.

-Andi

Re: optional delay after partition detection at boot time

[Willy Tarreau]

On Sun, Jun 12, 2005 at 03:10:59PM +0200, Andi Kleen wrote:
> "Dr. David Alan Gilbert" <dave@treblig.org> writes:
> >
> > 1) could be cured by not actually panic'ing.
> 
> Actually one thing I always wanted was to make sysrq still work 
> after panic. Then you could add a key to page through the dmesg
> there too and the problem would be solved.

Well, that's why I wrote kmsgdump several years ago :-) You could even print
the messages on a parallel printer or save them to a floppy disk.

> It would be extremly useful to reset remote servers when panic=timeout
> is not set, but something went wrong with mounting /.

I think that more generally, we should reset if there's no panic=timeout,
because the reasons for a panic are multiple and in case of remote servers,
it's always a nightmare to know that may be you will lose access after one
risky operation.

Willy

Re: optional delay after partition detection at boot time

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

On Sun, 12 Jun 2005 09:12:13 +0200, Willy Tarreau said:
> On Sat, Jun 11, 2005 at 11:50:50PM -0700, subbie subbie wrote:
> > Hello,
> > 
> >  I'm sure some of you have come across this annoying
> > issue, the kernel messages scroll way too fast for a
> > human to be able to read them (let alone vgrep them).
> > 
> >  I'm proposing two features;
> > 
> >  1. a configurable (boot time, via kernel command
> > line) delay between each and every print -- kind of
> > overkill, but may be useful sometimes. 

> What's the problem with "cat /proc/partitions" or "dmesg" ?
> You seem to want to slow down *every* boot just to identify
> a partition you need to find *once*. This seems overkill.

There's been more than once that something's been borked up such that
I can't *GET* to where I can run a cat command or dmesg - and it's not
always a partition problem.

Personally, what I could go for is control-Q/S support for printk output :)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: optional delay after partition detection at boot time

[Jesper Juhl]

On 6/12/05, subbie subbie <subbie_subbie@yahoo.com> wrote:
> Hello,
> 
>  I'm sure some of you have come across this annoying
> issue, the kernel messages scroll way too fast for a
> human to be able to read them (let alone vgrep them).
> 

If you need to pause the messages during boot, just press the  Scroll
Lock  key (or is it the  Pause  key, can't recall, but one of them
works).

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html