Re: [arch-general] User actions following system package upgrades?
On Thursday 26 Jan 2012 11:26:11 Kevin Chadwick wrote: > Paul Gideon Dann wrote: > > I know that due to the way the kernel is upgraded, it is best to save > > kernel upgrade until the system can be rebooted, > > Surely there is no point upgrading the kernel unless you are going to > reboot thereby loading in the new kernel and you could keep the old > modules. Well, I usually find it a bit of a pain to have to remember to update the kernel before rebooting. Also, since I usually suspend rather than shutting down, I have to actually remember to update the kernel and reboot at some point. I usually do that when a decent number of important packages get updated and I think "I'm probably about due a reboot; I might as well". I wish there were a better metric for this, though. Paul
Re: [arch-general] User actions following system package upgrades?
On Thu, 2012-01-26 at 09:18 -0700, Squall Lionheart wrote: > I always restart applications such as Firefox, Thunderbird, KDE, and xorg > after an update otherwise they act like they have ghosts in them. I would > imagine the major components you mentioned would have the same affect. It's better to close e.g. a MUA before upgrading.
Re: [arch-general] User actions following system package upgrades?
I always restart applications such as Firefox, Thunderbird, KDE, and xorg after an update otherwise they act like they have ghosts in them. I would imagine the major components you mentioned would have the same affect. -- Yesterday is history. Tomorrow is a mystery. Today is a gift. That's why its called the present.
Re: [arch-general] User actions following system package upgrades?
On Thu, 26 Jan 2012 11:11:41 + Paul Gideon Dann wrote: > I know that due to the way the kernel is upgraded, it is best to save kernel > upgrade until the system can be rebooted, Surely there is no point upgrading the kernel unless you are going to reboot thereby loading in the new kernel and you could keep the old modules. I'd be much happier with Linux if there was a security over functionality kernel but then I guess it would get less market share on desktops and wouldn't be Linux anyway. -- Kc
Re: [arch-general] User actions following system package upgrades?
On Thu, Jan 26, 2012 at 12:11 PM, Paul Gideon Dann wrote: > I've looked everywhere, but I can't find any reference to what the accepted > wisdom is: > > I know that due to the way the kernel is upgraded, it is best to save kernel > upgrade until the system can be rebooted, since the running kernel will be > unable to load modules because the modules directory (/lib/modules/) > changes when a new kernel package is installed. > > For this reason, I have the "linux" package in my IgnorePkg line in > pacman.conf, and upgrade it explicitly before a planned reboot. > > However, for what other packages is this true? I also have "udev" in > IgnorePkg, but is this necessary? Is it safe to upgrade udev without > rebooting? I suspect that certain rules may disappear or change, and the > running udev may not be happy about that. > > I'm guessing it's also best to shut down X and restart DBus after a DBus > upgrade too, although in practice a reboot is usually simpler, and that it > would also be sensible to reboot after a "glibc" upgrade too, although that's > rare. Any other thoughts? Are these sorts of considerations documented > anywhere? > > This issue of upgrading system packages while the system is running feels like > a potentially dangerous situation to me. Are we lucky that it doesn't cause > too much trouble, or are in-place upgrades specifically handled gracefully by > core system components such as udev? (I don't see anything special in udev's > install script.) I suspect that most of us shrug it off and reboot only when > we see breakage, but I hope you agree that's not a very safe way to work. The kernel is the only package that we support ignoring on upgrade (though even that within reason). Upgrading udev without restarting it (or better yet, rebooting) is a bad idea. The reason for this is that the default rules might have changed, and they might not be supported in the existing instance running on your machine. An almost seamless stop/upgrade/restart of udev would be possible (fully seamless if we used systemd), but there seems to be resistance to that kind of "magic". Ignoring udev on upgrade is a bad idea as other packages that are being upgraded might depend on changes it introduces (typically udisks et al.). Similar problems probably apply to other packages, but I haven't given it a great deal of thought. Cheers, Tom
[arch-general] User actions following system package upgrades?
I've looked everywhere, but I can't find any reference to what the accepted wisdom is: I know that due to the way the kernel is upgraded, it is best to save kernel upgrade until the system can be rebooted, since the running kernel will be unable to load modules because the modules directory (/lib/modules/) changes when a new kernel package is installed. For this reason, I have the "linux" package in my IgnorePkg line in pacman.conf, and upgrade it explicitly before a planned reboot. However, for what other packages is this true? I also have "udev" in IgnorePkg, but is this necessary? Is it safe to upgrade udev without rebooting? I suspect that certain rules may disappear or change, and the running udev may not be happy about that. I'm guessing it's also best to shut down X and restart DBus after a DBus upgrade too, although in practice a reboot is usually simpler, and that it would also be sensible to reboot after a "glibc" upgrade too, although that's rare. Any other thoughts? Are these sorts of considerations documented anywhere? This issue of upgrading system packages while the system is running feels like a potentially dangerous situation to me. Are we lucky that it doesn't cause too much trouble, or are in-place upgrades specifically handled gracefully by core system components such as udev? (I don't see anything special in udev's install script.) I suspect that most of us shrug it off and reboot only when we see breakage, but I hope you agree that's not a very safe way to work. Paul
