also sprach dann frazier <da...@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 <madd...@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
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
