also sprach dann frazier <dannf@debian.org> [2009.08.06.2118 +0200]:
> 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.
Good point.
> 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
This all sounds too nice. Otoh, I am sure grub2 people will play
along, and it shoud be trivial to do for grub1 too.
> > 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.
Ha! When I teach sysadmining courses, my students get to reboot
their machines *all* *the* *time* (and they have to do exercises and
brainstorming in the mean time). The reason is simply that anything
could break, and if the next boot will fail, then I'd like to know
*now*, not then.
> 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.
This is a twist on my proposal. All I wanted is a tool that knocks
me over the head like "hey, you installed a new 2.6.30 last week and
were to tired or unable to drive to the colo centre, or you were too
much of a chicken to do a remote reboot. But you still have to do
it. And till then, I'll mail you every day!"
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"my father, a good man, told me:
'never lose your ignorance; you cannot replace it.'"
-- erich maria remarque
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)