On 01/28/2013 07:55 PM, Karanbir Singh wrote: > 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 ). > Thanks to everyone for their replies. I suppose it's not possible in this forum to ask such a question and not get into religion. Kinda like the U.S. Congress. No one has yet shown how a byte-for-byte, fully redundant, bootable disk(set) can be created and kept up to date that will allow immediate recovery from a catastrophic failure of the primary disk(set) with nothing more than a reboot. FWIW, Solaris' problems are not technical. Rather, they're Oracle's licensing and support policies that have essentially fired all its small system customers. -- 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 at tkevans.com