Bug#380028: closed by Bastian Blank <waldi@debian.org> (Re: Bug#380028: mkvmlinuz requires -fno-stack-protector with gcc-4.1)
> The ubuntu kernel maintainers removed the mkvmlinuz support i provided to
> their kernel package with a "nobody should be using oldworld [pmacs]" kind
> of clueless message, and provided insulting when i subsequently complained
> about this fact.
I know, that sucks... but that's the way it is (was?). Now we need to aim for
the future.
> As such, mkvmlinuz 23 added a copy of the mkvmlinuz support files, taken
> from the 2.6.17 debian kernel (mostly upstream though), which may or not
> work for ubuntu kernels, but are a best effort solution.
>
> In any case, if you want to use mkvmlinuz with ubuntu kernels, it is
> recomended that you rebuild the mkvmlinuz package on an ubuntu system,
> which would take care of this problem.
I recompiled mkvmlinuz with -fno-stack-protector and it worked. The new kernel
booted just fine and everything seems good.
But the fact is that mkvmlinuz in Ubuntu is a plain copy from Debian, so I
figured that it would be wise to fix it "upstream". The thing is that I saw
that gcc-4.1 had stack-protector enabled by default but gcc-4.0 didn't (in
Ubuntu that is). I just assumed that was a change upstream in the gcc tree,
but seems I was wrong about that.
I don't know about the current version of gcc in Debian, I just have a server
using Debian which I haven't updated in a while so it doesn't have the latest
version of all packages - I just works ;)
But after Martin Michlmayr comment that Debians gcc didn't have
stack-protector enabled I updated and checked my Debian system and saw I was
wrong.
Didn't want to create any Ubuntu vs Debian stuff, just thought it would be
better for the greater good to change it in Debian too. Anyway, sorry about
that.
> But it is clear that it would be best to educate the ubuntu speople so they
> are more clueless about this issues. I think i can say that the debian
> kernel team at large regret the times when Fabbionne was the ubuntu kernel
> maintainer, and useed to cooperate more actively with the debian kernel
> team, rather than the void that is the current communication situation. And
> then they make noise at conferences about ways to unifying the debian based
> kernels.
Yeah, but I'm not that involved in the kernel team and don't know anyone
there... but we will see in the future.
// Emanuel
Reply to: