CentOS - Jun 2017 - Crazy thought about upgrading to new major release

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?

Thanks,

Jerry

On 6/6/2017 12:38 PM, 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?

the correct method is

1) backup all user files, databases, and settings.

2) clean install c7, configure required packages.

3) restore user files, databases, and settings.

or easier

1) install c7 on new server

2) move over all services, functionality, etc. one by one.


-- 
john r pierce, recycling bits in santa cruz

On 06/06/2017 03:45 PM, John R Pierce wrote:
> On 6/6/2017 12:38 PM, 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?
>
>
> the correct method is
>
> 1) backup all user files, databases, and settings.
>
> 2) clean install c7, configure required packages.
>
> 3) restore user files, databases, and settings.
>
> or easier
>
> 1) install c7 on new server
>
> 2) move over all services, functionality, etc. one by one.
This is how I do it.  I just don't trust updates.  Plus there is all 
sorts of detritus that builds up that you really don't want to drag 
along....

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 LABELThen, 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.

     mark

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?

-- 
Bowie