On Sun, Nov 6, 2011 at 6:42 PM, Yasha Karant <ykar...@csusb.edu> wrote:
> I have been informed that "update" will not work from EL N to EL N+1 for > major releases, only for minor sub-releases (EL 6.0 to EL 6.1, etc.). Major That's odd. I've done it successfully for.... about at least 500 Linux servers in the last 4 years my career. It does take installation media or a good PXE/kickstart setup, because the changes in glibc and RPM itself can wedge things awkwardly without special handling. There are very real risks, which is why you need the backups or good configuration management. > releases require a full install, as though one were using a completely new > hardware system. My personal backup technique these days is simply to buy a > new disk, clone it from a working one using dd, and then if I must install > to overwrite, bring up the backup disk on an unused disk controller > interface connection, and copy (cp -pr, cpio, tar, etc.) files and/or > hierarchies from the archived backup to the production disk. This is > feasible today because of the relatively low price of the bare harddrives, > and necessary in my case from my workstation or laptop because I do not have > access to a high throughput channel to a disk farm server (e.g., a NAS). At > low throughput, the task simply takes too much real time -- what will work > for a few Gbytes in terms of real time is not feasible for a Tbyte or more. Consider using "cp -a" or "rync -avH". Both copy hardlinks as well as file contents very effieiently and are easy to update. It's also handy to use something like "rsnapshot" to a secondary repository, which can be incrementally and efficiently updated before and after the migration. There's nothing quite like accidentally deleting an old file you needed, and being able to hit your snapshot backups for the copy you used to use. > Moreover, during the major release upgrades, my understanding is that / , > /usr, and other systems directories that are the mount points for the > underlying partitions containing file systems are automatically reformatted > (erased) or the upgrade will fail. I believe that I have email from Connie > Sieh on this very point. No, it's an *option* to preserve the old material and update in place. Did this a few days with SL 6.1, quite effectively, from SL 5.4, testing out a kickstart setup. > Do I understand you correctly that LVM works the same as physical > partitions, and that particular logical entities (e.g., the LVM analogue of > physical partitions) can be exempted during the full install of a new major > release? It gets awkward if you do an upgrade: you might have to declare the logical volumes "inactive" to protect them from an "upgrade" operation. If you do an "install", you can select your partitioning manually with arbitrary cunning. Unfortunately, 4096 byte block alignment remains an adventure. The GUI's don't support block-specific partition settings that might benefit performance if the virtualization server hardware is 4096 byte block aligned, and the emulated hardware is not. But bring that up sometime if you need it. Manual partitioning setups are easy to screw up, which is a very powerful reason to do a good backup first.