Bug#540202: include a cron reboot reminder
On Thu, Aug 06, 2009 at 08:35:49PM +0200, martin f krafft wrote:
> also sprach dann frazier <dannf@debian.org> [2009.08.06.1853 +0200]:
> > Any reason this couldn't be fully implemented externally to linux-2.6?
> > The parsing code should be static enough to live outside, I would
> > think.
>
> No reason why it couldn't happen externally. It just seems that the
> linux-image packages are the logical place for it.
To me, it seems more like an external service. Like you mention,
multiple linux-image packages could be installed at one time, so it
would seem like the logic is something we'd want to factor out into a
single standalone package. It is also very difficult to do any amount
of rapid development within the linux-2.6 source package as new
uploads require a lot of resources.
> Otoh, if you have multiple images installed, only the one with the
> highest version should be considered.
True - though, theoretically this could be more complex than that. For
example, just because 2.6.30 is installed doesn't mean that 2.6.26
isn't still configured to be the default. We could play ignorant and
always tell the user that they need to reboot after installing any new
kernel, but it would be cool if we could be more intelligent about
it.
It might make sense to do this as a commandline toolset, and let other
people build tools on top as they wish. e.g.:
$ kernstatus --booted-kernel
UNAME=2.6.26-2-686
PKGVER=2.6.26-18
$ kernstatus --default-kernel
UNAME=2.6.30-1-686
PKGVER=2.6.30-5
I could see using such a tool inside of s2disk to make sure that we
will be booting the same kernel we used to hibernate.
Possibly offtopic, I've also personally always wanted a simple,
bootloader/arch independent tool that knows how to list the available
kernels, and have the option to set a given kernel as the default for
the next boot. e.g.:
$ kerntool --list-images
2.6.30-1-686
2.6.26-2-686
$ kerntool --set-default 2.6.30-1-686
> A better approach would be something like
> /var/lib/debian/reboot-required.d, where packages can drop files
> containing reasons why a reboot is needed.
Yeah, that might make sense - esp if there are other such packages,
but I can't think of any myself (thankfully). But I think for the
kernel case we would probably want that dropped-in file to be managed
by a more intelligent tool rather than trying to figure things out
(only) inside of maintainer scripts.
I do like the idea of a cronjob that checks periodically to see if the
kernel-that-would-be-booted-next is the same kernel that is currently
booted. It would be able to detect a mismatch introduced outside of a
dpkg operation - for example, if the the user reconfigures which
installed kernel is the default.
--
dann frazier
Reply to: