Bug#589118: `rdev` setting ignored
 

Package: initramfs-tools
Version: 0.92o

Subject tells the story. Appears the images generated by initramfs-tools
completely ignore the `rdev` setting that the kernel was given to the
kernel. While 99% of users may be explicitly passing the root device via
passing "root=/dev/foo" through the bootloader, if that is absent one
would think the value from `rdev` would be honored.

(yeah, it's an ancient method, but not officially deprecated)


--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
BS ( | EHeM@gremlin.m5p.com PGP F6B23DE0 | ) /
\_CS | _____ -O #include <stddisclaimer.h> O- _____ | / _/
2477\___\_|_/DC21 03A0 5D61 985B <-PGP-> F2BE 6526 ABD2 F6B2\_|_/___/3DE0





--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201007150111.o6F1BYYw068091@m5p.com">http://lists.debian.org/201007150111.o6F1BYYw068091@m5p.com

Bug#589118: `rdev` setting ignored
 

reopen 589118
quit

>From: Ben Hutchings <ben@decadent.org.uk>
> On Wed, 2010-07-14 at 18:11 -0700, Elliott Mitchell wrote:
> > Package: initramfs-tools
> > Version: 0.92o
> >
> > Subject tells the story. Appears the images generated by initramfs-tools
> > completely ignore the `rdev` setting that the kernel was given to the
> > kernel. While 99% of users may be explicitly passing the root device via
> > passing "root=/dev/foo" through the bootloader, if that is absent one
> > would think the value from `rdev` would be honored.
> >
> > (yeah, it's an ancient method, but not officially deprecated)
>
> If the bootloader passes an initramfs to the kernel, that overrides any
> rdev parameter. This is nothing to do with the contents of the
> initramfs.

Bzzzt! While the "initrd=" kernel command-line option and `rdev` kernel
settings are not completely orthogonal, they are mostly unrelated. The
"initrd=" option overrides the `rdev` setting in the same fashion the
"initrd=" option overrides the "root=" and all other kernel command-line
options. Mainly, the initramfs can ignore any and all options and use
ones built in, or it can implement all those options. It is the "root="
option that is directly related to `rdev`.

Unlike the kernel command-line, I don't know how the `rdev` (and
accompanying) setting is passed along to initial ram disks, but I do know
it is (or was). I'm unsure whether Debian 4.0/Etch honored the `rdev`
setting, but I am pretty certain initial ram disks generated with Debian
3.1/Sage did honor the `rdev` setting unless overridden by the "root="
option.


--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
BS ( | EHeM@gremlin.m5p.com PGP F6B23DE0 | ) /
\_CS | _____ -O #include <stddisclaimer.h> O- _____ | / _/
2477\___\_|_/DC21 03A0 5D61 985B <-PGP-> F2BE 6526 ABD2 F6B2\_|_/___/3DE0





--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201007152048.o6FKm7N7071394@m5p.com">http://lists.debian.org/201007152048.o6FKm7N7071394@m5p.com

Bug#589118: `rdev` setting ignored
 

reopen 589118
quit

>From: Ben Hutchings <ben@decadent.org.uk>
> On Thu, 2010-07-15 at 13:48 -0700, Elliott Mitchell wrote:
> > Bzzzt! While the "initrd=" kernel command-line option and `rdev` kernel
> > settings are not completely orthogonal, they are mostly unrelated.
>
> You obviously haven't read the code. I have.

This is in fact true. An unrelated project may cause me to do so.

> > Unlike the kernel command-line, I don't know how the `rdev` (and
> > accompanying) setting is passed along to initial ram disks, but I do know
> > it is (or was).
>
> It isn't.

Reeeaaally? Sorry to be speculating outside my area of firm knowledge,
but I'm noting that the rdev setting was honored all the way through
Debian 3.1/Sarge, which was a 2.4 kernel. Was the rdev setting really
available to initial ramdisks all the way through 2.4, yet lost with 2.6
kernels?

> > I'm unsure whether Debian 4.0/Etch honored the `rdev`
> > setting, but I am pretty certain initial ram disks generated with Debian
> > 3.1/Sage did honor the `rdev` setting unless overridden by the "root="
> > option.
>
> That's nice, but this feature isn't coming back.

That sounds suspiciously like "wontfix", not "done".


--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
BS ( | EHeM@gremlin.m5p.com PGP F6B23DE0 | ) /
\_CS | _____ -O #include <stddisclaimer.h> O- _____ | / _/
2477\___\_|_/DC21 03A0 5D61 985B <-PGP-> F2BE 6526 ABD2 F6B2\_|_/___/3DE0





--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201007170018.o6H0Ifmg076196@m5p.com">http://lists.debian.org/201007170018.o6H0Ifmg076196@m5p.com

Bug#589118: `rdev` setting ignored
 

close 589118
thanks

On Fri, 16 Jul 2010, Elliott Mitchell wrote:
> reopen 589118
> quit

If a maintainer closes a bug, and after a single round of explanation,
still does not agree with reopening the bug, the bug should stay
closed.

If you disagree with the maintainer, then your choices are to either
attempt to:

1) convince the maintainer that your viewpoint is correct, preferably
by submitting a patch which fixes the perceived problem, along with
rationale as to why the patch is correct.

2) attempt to convince the technical committee that the maintainer is
incorrect, and should be overridden. This necessitates a patch as
required for #1.

In neither case should you reopen bugs that a maintainer has
closed.[1] Continuing to do so will result in restricting your use of
control@bugs.debian.org.


Don Armstrong
(on behalf of owner@bugs.debian.org)

1: It is of course acceptable to reopen a bug in cases when the
maintainer is likely to agree with you, but that is clearly not the
case here.
--
"There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself."
-- Bach

http://www.donarmstrong.com http://rzlab.ucr.edu



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100717020343.GM31014@rzlab.ucr.edu">http://lists.debian.org/20100717020343.GM31014@rzlab.ucr.edu