Re: Bug#561099: initramfs-tools: determination of "newest kernel" in update-initramfs -u uses improper sorting
On Fri, May 07, 2010 at 11:50:39AM -0400, Jeffrey B. Green wrote:
> Allow me this little statement since opening a new bug appears to be
> fruitless.
>
> > > Let me try: "The program's behaviour differs from the description in
> > > the manpage." Doesn't sound like a bug to you?
> > >
> > > Of course, the issue can be fixed a) in the program or b) in the man
> > > page, but in my opinion, it definitely should be fixed.
> > >
> > > Cheers!
> > >
> > > Thiemo
>
> It has been a somewhat prolonged irritant for me, mainly due to lack of
> time in tracking down each and every oddity that comes along. Testing
> (squeeze) at some point put out a 2.6.32-trunk kernel that sorts after
> any 2.6.32-n kernel and consequently always is the newest if it still is
> around. Mind you, the user didn't build and install or even install
> outside normal update procedures. Therefore, the point that these kernel
> "tangents" are due to "expert-level" user actions is wrong in this case.
> The argument that the onus is on the user may apply in unstable however
> not for "testing" since that codename refers to testing the potential
> release and not to testing the potential user. (Obciously, that argument
> implies the naming problem "should" have been caught in unstable...oh well.)
>
> Even so, the confusion caused by the unusually numbered kernel would
> have been lessened considerably if the manpage had actually defined the
> term "newest kernel" so that at least the user could understand what was
> happening with the "update-initramfs -u" action. I might be overstepping
> here but I would think that most people would consider the word "newest"
> to refer to a temporal order and not a lexical. As it was with the
> confusion of thinking that it should be updating the newest but for some
> reason just isn't, I, and possibly others, had to go along behind
> updates and redo that command with a -k option in order to get the
> proper initrd.img updated, or find some other less tedious workaround.
>
> In the end, I agree with Thiemo in that the manpage and the program's
> behaviour are at odds.
just nuke the trunk linux-image, it is severely outdated.
kind regards
Reply to: