Bug#589118: `rdev` setting ignored

2010-07-16 Thread Elliott Mitchell
reopen 589118
quit

From: Ben Hutchings b...@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 (| e...@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-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201007170018.o6h0ifmg076...@m5p.com



Processed: Re: Bug#589118: `rdev` setting ignored

2010-07-16 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 reopen 589118
Bug #589118 {Done: Ben Hutchings b...@decadent.org.uk} [initramfs-tools] 
`rdev` setting ignored
 quit
Stopping processing here.

Please contact me if you need assistance.
-- 
589118: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589118
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.127932593718584.transcr...@bugs.debian.org



Bug#589118: `rdev` setting ignored

2010-07-16 Thread Don Armstrong
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
cont...@bugs.debian.org.


Don Armstrong
(on behalf of ow...@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-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100717020343.gm31...@rzlab.ucr.edu



Processed: Re: Bug#589118: `rdev` setting ignored

2010-07-16 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 close 589118
Bug#589118: `rdev` setting ignored
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to Elliott Mitchell e...@m5p.com

 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
589118: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589118
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.127933224012218.transcr...@bugs.debian.org



Bug#589118: `rdev` setting ignored

2010-07-15 Thread Elliott Mitchell
reopen 589118
quit

From: Ben Hutchings b...@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 (| e...@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-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201007152048.o6fkm7n7071...@m5p.com



Bug#589118: `rdev` setting ignored

2010-07-14 Thread Elliott Mitchell
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 (| e...@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-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201007150111.o6f1byyw068...@m5p.com