Bowie Bailey wrote: > On 6/6/2017 5:29 PM, m.roth at 5-cent.us wrote: >> Jerry Geis wrote: >>> I have older systems out there that work fine, just for what ever >>> reason >>> would be great to upgrade from a C5 -> C7 (due to no longer supported) >>> or >>> C6 > C7 (for updated packages). >>> >>> Sounds like the upgrade tool is not quite an option... >>> I was thinking... >>> >>> What would be wrong with any "easy" script that did the following: >>> >>> 1) Removed all packages with the --justdb option. >>> 2) Import the RPM-GPG-KEY-CentOS-7 >>> 3) install the centos-release-7.3.1611 ... rpm >>> 4) yum -y upgrade >>> 5) yum groupinstall "GNOME Desktop" (for example) >>> >>> and reboot of course. >>> >>> Does that have any chance or working and be valid? >>> >> I know I've posted what we do here to upgrade one system from another >> before, but not in a few years. >> >> mkdir /new >> mkdir /boot/new >> rsync -HPavzx --exclude=/old --exclude=/var/log/wtmp >> --exclude=/var/log/lastlog $machine:/. /new/. >> rsync -HPavzx $machine:/boot/. /boot/new/. >> rsync -HPavzx /etc/sysconfig/network-scripts/ifcfg-eth* >> /new/etc/sysconfig/network-scripts >> rsync -HPavzx /etc/sysconfig/hwconf /new/etc/sysconfig >> rsync -HPavzx /boot/grub/device.map /boot/new/grub/ >> rsync -HPavzx /etc/udev/rules.d/70-persistent-net.rules >> /new/etc/udev/rules.d/ >> find /new/var/log/ -type f -exec cp /dev/null {} \; >> >> Fix /new/etc/fstab, ESP if you use UUID. I *strongly* prefer LABEL= >> Then, any webserver stuff if the old was running it. >> If this system is using Linux RAID, >> >> rsync -HPavx /old/etc/md.conf /etc/ >> >> If yuo want to, copy the original SSH keys: >> >> rsync -HPavzx /etc/ssh/ssh_host* /new/etc/ssh >> >> Don't forget /boot/grub/device.map, and for C6, /new/boot/grub/grub.conf >> is right, or for C7, /new/boot/grub2/grub.conf is good. >> >> NOTE this will work for identical machines. Otherwise, BEFORE you rotate >> ou may need to run "mkinitrd" for the latest kernel if the hardware is >> different between the machine you are upgrading and the machine you made >> the copy. >> >> mount --bind /dev /new/dev >> mount --bind /sys /new/sys >> mount --bind /proc /new/proc >> mount --bind /boot/new /new/boot >> chroot /new >> cd /lib/modules >> VER=$(ls -rt1 | tail -1) >> echo $VER >> mkinitrd X $VER >> mv X /boot/initrd-$VER.img >> exit >> umount /new/dev /new/sys /new/proc /new/boot >> >> >> Then rotate: >> >> zsh >> zmodload zsh/files >> >> cd /boot >> mkdir old >> mv * old >> mv old/lost+found . >> mv old/new/* . >> >> # Root partition. >> cd / >> mkdir old >> mv * old >> mv old/lost+found . >> #mv old/root . -- WHY? >> mv old/scratch . >> mv old/new/* . >> >> sync >> sync >> >> And reboot. If there are issues with grub, get it up from the grub >> shell, >> then grub-install or grub2-install as appropriate. > > Interesting process. As far as I can tell, this keeps very little of > the configuration from the old system. You would still have to > re-install and copy the configurations for any necessary packages along > with any crontab entries that were on the old system. > > Other than reducing downtime, what are the advantages of doing this > rather than just building the new OS onto a new hard drive and then > copying things over? About the configurations, yep. Apache, heartbeat, any of that. Advantages? Let's see... the bleeding edge (as of last summer) boxes we have won't work with our setup of PXEboot builds, and if you're updating a cluster (say, 23 or 24 boxes), it goes very quickly, and they're identical. Actually, any time you want the machine to be updated to be identical to the one you're copying from, it's nice. And quick. mark