On 01/28/2013 01:20 PM, xrx wrote:
> On 01/28/13 22:14, Tim Evans wrote:
>> On 01/28/2013 01:05 PM, xrx wrote:
>>> On 01/28/13 21:27, James A. Peltier wrote:
>>>> ----- Original Message -----
>>>> | Does anyone know of any sort of Linux utility that does something
>>>> | like
>>>> | what Solaris' Live Upgrade
>>>> | (http://docs.oracle.com/cd/E19455-01/806-7933/index.html) does?
>>>> |
>>>> | In my past life as a Solaris sys-admin, I found this an extremely
>>>> | useful
>>>> | tool for upgrading and patching running systems, as well as for
>>>> | maintaining redundant boot environments on separate system disks for
>>>> | disaster situations.
>>>>
>>>> Nothing really until BTRFS comes of age. I suppose you could snapshot your LVM volumes before performing the upgrade but to my knowledge there is nothing similar to Live Upgrade for CentOS
>>>>
>>> It does sound like you can do the roughly the same with LVM snapshots.
>>> Reading the introduction of the solaris document you linked; it seems as
>>> if the solaris upgrade is applied on say a snapshot; and then the system
>>> is rebooted into the upgraded environment; and if it works, great, if
>>> not you need a reboot back into the original state.
>>>
>>> Wheras with CentOS 6; you take a snapshot of the root partition (easy as
>>> "lvcreate --snapshot --name RootSnapshot --size 2G /dev/VolGroup/Root"),
>>> and then do an upgrade with a reboot. If it works; you're set, if not,
>>> just revert back to the snapshot (lvconvert --merge
>>> VolGroup/RootSnapshot) and reboot; you'd be back to the state before the
>>> upgrade.
>> Thanks. You also need to manage the grub and fstab configurations to
>> allow the second boot environment to be visible, bootable, and mountable.
>>
>>
> Are you talking about CentOS? There is no need to change the fstab or
> grub; the upgrade gets applied on the main volume (where the OS can be
> upgraded on the fly without a reboot if it works out; or optionally with
> a reboot if you want to be extra sure). The snapshot is only there if
> the update goes bad; in which case you'd run the merge command to revert
> back to the original state.
Thanks, again. What you've described is sort of the bass-ackward to
what LU does.
It creates one or more "alternate boot environment(s)," then newfs's it,
mounts it, copies the running system to it, then applies
upgrades/patches to it. It does not touch the running environment
(except to create a housekeeping database for the multiple boot
environments). The target boot environment is made bootable, and the
grub configuration is updated to include the second bootable
environment, and the /etc/fstab file on the second environment is
modified to reflect the disks/LV's it uses.
The whole idea is not to touch the running system, apply changes to the
alternate system, then boot to the alternate when change is done. Once
the reboot to the new environment is done, you can further use LU to
replace the un-upgraded/un-patched original environment with a copy of
the new one.
--
Tim Evans | 5 Chestnut Court
Linux/UNIX Consulting | Owings Mills, MD 21117
http://www.tkevans.com/ | 443-394-3864
http://www.come-here.com/News/ | tkevans@xxxxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
