On 01/28/2013 06:54 PM, Tim Evans wrote: > It creates one or more "alternate boot environment(s)," then newfs's it, This is redundant on CentOS > mounts it, copies the running system to it, then applies > upgrades/patches to it. It does not touch the running environment not true, you have severe performance loss and no reliable way to measure the impact of what that changeset is going to bring in. Patching the running system, with a failback option is far better. Unless you dont trust the platform at all. Lack of a reasonable manageable and predictable packaging system can cause that lack of trust. > (except to create a housekeeping database for the multiple boot > environments). The target boot environment is made bootable, and the the idea of bootable on Linux is limited to the kernel and the initrd ( which even has a shell ). Unless you installed a kernel in the transactino set, there is no need to update grub, since your existing running boot components are still intact ( if not, you can measure and handle it ). If you do update the kernel, the setup will retain multiple copies and your last running kernel is always retained as an option to boot from next boot cycle > 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. Take a look at the yum lvm plugin, it already does most of this - with some assumptions on what its going to snapshot and how you want to handle that. > 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. This kind of highlights the issue here, you are attempting to look at this with too far a solaris process mindset. Most CentOS best-practises are driven towards keeping a running system up, by not breaking it or needing to do downtime efforts. Some packages due to their nature will enforce this, like glibc; but on the whole, its considered acceptable to patch live and keep going, with the understanding that there is a failover option / failback opton, rather than assume a running system must be taken down for a patch to be applied. There are exceptions, but most of them are niche implementation driven ones, on the whole CentOS is built to be patched in place. Take a look at the yum lvm plugin on how you can fairly-easily implement the extra step you mentioned ( i.e tweak fstab to boot from a diff lv / uuid ). - KB