[Rolling up multiple replies into one to keep the ticket to what it is.
Thanks for the very quick replies and keep up the good job! ]
On 2013-05-15 20:29 , Axel Beckert wrote:
Control: severity -1 important
Hi Jeroen,
Jeroen Massar wrote:
Package: apache2
Severity: grave
When upgrading to Debian stable (the one that is stable today, released
recently ;) and when one still has an older kernel (2.6.26-2-686,
linux-image-2.6.26-2-686 2.6.26-26lenny2) Apache fails to start
mysteriously with:
I'm sorry, but this is not of RC severity. Debian doesn't support
dist-upgrades with skipping one release inbetween (at least not
officially) and hence upgrading with kernels from oldoldstable isn't
really supported either.
Nevertheless thanks for reporting this issue.
Understandable. I primarily filed this bug so that people can be aware
of this situation when they google for this.
Btw: I have a p200mmx that I once installed as Debian Bo and upgraded
all the way up to the current unstable... yes, that box has been
rebooted in the mean time a few times ;) I guess that truely
demonstrates the power of Debian (dpkg/apt, and of course the many
developers delivering high quality packages!)
Please make Apache depend on a 'new' kernel. Apparently that is 2.6.30+
or better 3.2+ that provides a certain syscall that is being used.
This will make the situation worse for many virtual machines where the
kernel is hosted outside the virtual machine, namely on Xen DomUs
which don't use pygrub or inside VServers as you cited yourself in the
second mail:
http://serverfault.com/questions/496989/apache-in-linux-vserver-wont-start-cant-create-socket
seems such a case.
And no, I don't have a better solution for that at the moment.
udev for instance warns about this that one should reboot (which indeed
I ignored). Apache did not warn.
$ uptime
16:20:46 up 912 days, 3:38, 2 users, load average: 3.83, 2.59, 1.33
:-)
Regards, Axel (sitting only a few kilometers away from you ;-)
Are you sure about that? :) It depends on your definition of 'few', if
'few is 2000km, assuming you mean that you are in .ch, then it is few,
otherwise it is not few :)
On 2013-05-15 21:37 , Arno Töll wrote: Hi,
On 15.05.2013 18:23, Jeroen Massar wrote:
Package: apache2
Severity: grave
sorry. No.
I thought it was appropriate as:
grave
makes the package in question unusable or mostly so, or causes data
loss, or introduces a security hole allowing access to the accounts of
users who use the package.
As it does not start, does not have proper explanation why, I thought
that correct.
[..]
this is bad luck, but expected. We do not support upgrades skipping a
version in any way. If you are running a kernel from Lenny, you cannot
(and should not) expect it is being able to run a much newer user land.
I half-expected this (as it happened with a lot of other stuff before),
but as apt/dpkg do not notify one that one has to reboot and the binary
starts it is not expected.
You noticed this problem for Apache, but in reality there are plenty of
packages making use of syscalls introduced in later kernel versions.
Some random examples include, but are not limited to lvm, udev, libc6
and by chance many, many more.
Oh yes.
Linux andromeda 2.6.26-2-686 #1 SMP Thu Sep 16 19:35:51 UTC 2010 i686
GNU/Linux
$ uptime
16:20:46 up 912 days, 3:38, 2 users, load average: 3.83, 2.59, 1.33
I am not sure this is something to be proud of, or even more so telling
to the public that you are running a kernel which saw no security
upgrades for 3 years (and yes, there are issues).
That would be proud of Debian allowing user-space upgrades to go forward
and keep the box up and running all the way ;)
There are definitely issues, but a box that works great typically does
not get a reboot. It did so now though, and indeed it was about time.
Note that that box is in an environment that it is really not reachable
from the outside or anything untrusted, thus the risk of a remote or
even local (if one could get access to it) kernel exploit was/is very low.
There is also consensus in Debian not do depend on any particular kernel
version.
[That kind of contradicts the 'don't use an old kernel' version ;)
but I assume you mean no particular semi-current version ]
There is no reliable way to please everyone running Debian in
every setup. Just to note some random examples, where dependencies
against a kernel package would break:
- chroots
- virtual machine environments
- self-built kernels
And finally, as you noted yourself: Having a kernel INSTALLED and having
that kernel BOOTED is a different kind of story.
I fully agree, it is a very difficult thing to resolve properly.
If you still believe this is something which should be addressed, try
to
find project-wide consensus. For example, I could imagine that libc6
maintainers provide a runtime check running in their maintainer
scripts
testing the
