[lkml]   [2010]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux mdadm superblock question.
On 22:06 Tue 16 Feb     , Volker Armin Hemmann wrote:
> On Dienstag 16 Februar 2010, Bill Davidsen wrote:
> > Volker Armin Hemmann wrote:
> > > On Sonntag 14 Februar 2010, you wrote:
> > >> In other words, 'auto-detection' for 1.x format devices is using an
> > >> initrd/initramfs.
> > >
> > > which makes 1.x format useless for everybody who does not want to deal
> > > with initrd/initramfs.
> >
> > You make this sound like some major big deal. are you running your own
> > distribution? In most cases mkinitrd does the right thing when you "make
> > install" the kernel, and if you are doing something in the build so
> > complex that it needs options, you really should understand the options
> > and be sure you're doing what you want.
> >
> > Generally this involves preloading a module or two, and if you need it
> > every time you probably should have built it in, anyway.
> >
> > My opinion...
> I am running my own kernels - and of course everything that is needed to boot
> and get the basic system up is built in. Why should I make the disk drivers
> modules?
> That does not make sense.

I agree that it makes little sense to make something a module when you
can't unload it anyway, but...

> And the reason is simple: even when the system is completely fucked up, I want
> a kernel that is able to boot until init=/bin/bb takes over.

I put a complete set of recovery tools into my initramfses so that when
the system is completely fucked up, I have a kernel that is able to boot
until rdinit=/bin/zsh (or /bin/bb, if you prefer) takes over.

This has the added advantage of working when the root filesystem cannot
be mounted at all: a scenario which does not seem too far-fetched when
the filesystem is located on a raid array.

Nick Bowler, Elliptic Technologies (

 \ /
  Last update: 2010-02-16 23:03    [W:0.087 / U:17.324 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site