From: "Boyd Stephen Smith Jr." <bss03@volumehost.net>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] When to reboot after updates to the system
Date: Fri, 28 Apr 2006 20:37:31 -0500 [thread overview]
Message-ID: <200604282037.36660.bss03@volumehost.net> (raw)
In-Reply-To: <4452BB8F.5010300@infoave.net>
[-- Attachment #1: Type: text/plain, Size: 2215 bytes --]
On Friday 28 April 2006 20:04, Phil Sexton <philsexton@infoave.net> wrote
about 'Re: [gentoo-user] When to reboot after updates to the system':
> Kevin wrote:
> > Hi All-
> >
> > I've read the portage documentation at
> > http://www.gentoo.org/doc/en/index.xml?catid=gentoo and I've searched
> > and browsed the gentoo-user mailing list archive, but I have a
> > question that I don't see answered anywhere.
> >
> > It seems to me that it must be true that sometimes, after a system
> > upgrade done with:
> >
> > emerge -uD system
> > or
> > emerge -uD world
> >
> > I must reboot the computer for the changes to take effect.
>
> I reboot if I need to install or change hardware. As far as
> updates go, you may have to reboot after compiling a new kernel.
>
> I think that I may have read somewhere how to change kernels
> without rebooting, so you may not even need to reboot for any
> software.
Theoretically it's possible just by writing to /proc/kmem -- IIRC, that was
one of the reasons it was writable: so you could apply (binary) patches
against a running kernel.
I've never seen any non-malware that does so. There is a GPL'd
proof-of-concept rootkit that will hide its existence by
modifying /proc/kmem. (The rootkit doesn't actually do anything malicious
and you have to have root access to modify /proc/kmem; the rootkit was
just showing how to do this trickery without loading a module)
There's also the new kexec feature option in mm kernels (and it might have
come mainline) that allows the kernel to start another kernel instead of
rebooting your hardware. That's basically as bad as a reboot anyway,
because all services come down and all users are kicked out -- it is
faster though, because you don't go down to the bootloader/BIOS level.
I found it (or my hardware) was a little bit buggy. My USB drivers would
only work every other kexec. Since I use a USB keyboard, this wasn't a
workable solution.
--
"If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest
clue what's best for them in terms of package stability."
-- Gentoo Developer Ciaran McCreesh
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2006-04-29 1:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-29 0:42 [gentoo-user] When to reboot after updates to the system Kevin
2006-04-29 0:52 ` Brett I. Holcomb
2006-04-29 0:55 ` Kevin
2006-04-29 1:20 ` Brett I. Holcomb
2006-04-29 0:58 ` Jeremy Olexa
2006-04-29 1:04 ` Phil Sexton
2006-04-29 1:37 ` Boyd Stephen Smith Jr. [this message]
2006-04-29 1:27 ` Hemmann, Volker Armin
2006-04-29 1:51 ` Phil Sexton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200604282037.36660.bss03@volumehost.net \
--to=bss03@volumehost.net \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox