[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#340759: doesn't honour root=, fails when disk changes from /dev/hda to /dev/hdc



On Sat, Nov 26, 2005 at 09:12:25AM +0100, Jonas Smedegaard wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sat, 26 Nov 2005 08:42:12 +0100
> Sven Luther <sven.luther@wanadoo.fr> wrote:
> 
> > On Fri, Nov 25, 2005 at 11:58:09PM +0100, Jonas Smedegaard wrote:
> 
> > > On Fri, 25 Nov 2005 21:48:52 +0100
> > > Sven Luther <sven.luther@wanadoo.fr> wrote:
> > > 
> > > > On Fri, Nov 25, 2005 at 08:44:38PM +0100, Jonas Smedegaard wrote:
> > > 
> > > > > So, all in all: I agree this is not great, but disagree that the
> > > > > goal of yaird must be to behave exactly like initrd-tools.
> > > > 
> > > > Well, i kind of disagree, if the user provides a root= argument,
> > > > then he probably knows what he does, and if he is wrong, then too
> > > > bad for him, but chances are good that he knows what he was
> > > > doing :)
> > > 
> > > So what is our disagreement?
> > 
> > Mmm, i am confused now, from my understanding i gather that yaird
> > right now doesn't respect the root= argument when explicitly given,
> > and altough you find this problematic, you judge it a minor issue. I
> > (and Martin) argue that it is an important feature to be able to
> > override yaird by setting a root= argument. Important if not
> > critical, as asking people to boot into d-i and do hand-stuff to make
> > it work is hardly nice.
> > 
> > So, our disagreement is mostly in the priority of this.
> 
> Thanks for the clarification. It does seem from a later posting,
> however, that your view is not necessarily shared with Martin.

I don't think so, and Martin will confirm that.

> Correct: I acknowledge that the behaviour of yaird may come as a
> surprise to many, and that it is inconvenient for some kinds of
> operations, but judge that not as a "bug", but a design decision.

Nope, it is a bug.

> > Notice, that one solution would be for yaird to generate a
> > rescue-initramfs which contains itself and all that is needed to run
> > it (mount /sys, include perl and co, etc) and then regenerate the
> > minimal ramdisk, altough this would mostly amount to having a
> > initramfs-tools-like tool.
> 
> If it is a bug to not behave in all areas like (intended for)
> initrd-tools, then there is really no sense in making yaird at all:

Well, the design goal is to behave like a proper non-initrd kernel in most
respect and have the user not really see a difference. In this way, respecting
root= in all case would be similar to having a non-ramdisk kernel with some
modules builtin (the ones in the ramdisk), and will naturally fail if root is
somewhere else, but in all case, the user can set any root= kind argument he
fancies. If the module for his root device is not in the ramdisk, this is
expected behavior if it fails.

> Next compliant will be (and have already been, if I recall correctly)
> that yaird does not support extending by the use of shell snippets.

This is irrelevant to the discussion at hand though.

> Initrd-tools and yaird and initramfs-tools share a common goal of
> creating an initial ramdisk for kernel bootup processes. Lots of other
> goals they do not share.

Exact, so that the user sees no difference from a non-ramdisk kernel, and this
includes a root= argument support.

Friendly,

Sven Luther






Reply to: