* Roger Luedecke <roger.luedecke@gmail.com> [2011-11-21 22:18]:
On Monday, November 21, 2011 12:44:25 PM Lars Müller wrote:
On Mon, Nov 21, 2011 at 09:26:47AM +0100, Tim Edwards wrote:
On Monday, November 21, 2011 7:19 AM, "Stefan Seyfried"
<stefan.seyfried@googlemail.com> wrote:
On 21.11.2011 00:51, Patrick Shanahan wrote:
it is possible to alter /etc/zypp/zypp.conf to set this as default, download in advance.
Actually this is default for quite some time IIUC.
I don't have the netbook with me now to check what was set but it doesn't protect you if you restart the machine in the middle of it *installing* the updates, which as far as I can tell is what I did (unknowingly).
That's not the only issue.
Consider you have a X11 session running and then parts of your desktop environment get upgraded. I've seen this causing hanging KDE sessions several times.
Microsoft Windows does it the right way. They download in background (even slowing the speed down if the link is congested) and with the next shutdown they apply the updates.
Yes, even this approach has disadvantages. But to me it sounds like the most safest one.
At least we have to lock the system agains reboots while updates are applied.
The alternative is to apply updates if available before we allow the login from the display manager.
It would be nice if the admin is able to decide between apply updates on shutdown, apply them on boot up, or apply them only on request.
Lars Actually, I think we cuold have a more elegant solution than either. Similar to the new kernel backup thingamajig scheme we just implemented, we could have it check during boot to make sure there wasn't an interruption in the updates and if so have it roll back those changes. This would mean having to keep copies of the packages changed; but in the back of my mind I think we could do it in a way that wouldn't require keeping every RPM ever DL'd.
That's basically reinventing Solaris boot environments which might become possible with btrfs. The basic idea is to snapshot the current root fs, clone it, mount the clone and apply the updates within the context of the clone. Then offer both the updated clone and the original environment in the grub boot menu, if everything went ok you boot into the updated clone and eventually promote it, otherwise you boot back into the original fs and destroy the clone again. To me the only sane way of applying package updates and an area where Linux is sorely lacking. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org