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@xxxxxxxxx> 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 

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