I would like to upgrade a CentOS-6.5 home server to CentOS-7 on a new partition. What is the simplest way to achieve this? I would like to be able to boot into either version of CentOS until I am sure the new version is running OK.
Incidentally, I think most people today must have enough space on their hard drive to install a new OS on a new partition - it is surprising that this option never seems to be mentioned in upgrade documentation.
On 10/25/2014 09:40 AM, Timothy Murphy wrote:
I would like to upgrade a CentOS-6.5 home server to CentOS-7 on a new partition. What is the simplest way to achieve this? I would like to be able to boot into either version of CentOS until I am sure the new version is running OK.
Incidentally, I think most people today must have enough space on their hard drive to install a new OS on a new partition - it is surprising that this option never seems to be mentioned in upgrade documentation.
A couple of observations after doing this:
1. It requires a custom disk layout, but is not particularly hard. 2. AFAIK, you can share your SWAP partition between the two installations. 3. Centos 7 uses grub2 as its boot loader. It is significantly different from "legacy grub" used in Centos 6 and before. a. It uses a configuration file that is auto-generated, and not supposed to be edited. b. It is capable of finding other installations (including legacy grub and windows), and creating links to them. c. 'b' only seems to work IF the other boot partitions are mounted somewhere in your file tree. What I have done is mount the other partitions (the /boot partition, if it is on a separate partition, otherwise /) under /mnt (e.g. /mnt/C6) when you are doing your custom disk layout. As long as they are mounted somewhere in the file system, grub2 seems to find them OK, and add them to your boot menu. It is apparently incapable of looking on unmounted partitions and finding Operating Systems lurking there. d. grub2 is (theoretically) capable of booting off of LVM (and I have done so successfully), BUT that capability is disabled and unsupported in RHEL/Centos 7. You still have to put /boot on a non-LVM partition.
Ted Miller Elkhart, IN, USA
Ted Miller wrote:
I would like to upgrade a CentOS-6.5 home server to CentOS-7 on a new partition. What is the simplest way to achieve this?
- It requires a custom disk layout, but is not particularly hard.
- AFAIK, you can share your SWAP partition between the two installations.
- Centos 7 uses grub2 as its boot loader. It is significantly different
from "legacy grub" used in Centos 6 and before. a. It uses a configuration file that is auto-generated, and not supposed to be edited. b. It is capable of finding other installations (including legacy grub and windows), and creating links to them. c. 'b' only seems to work IF the other boot partitions are mounted somewhere in your file tree. What I have done is mount the other partitions (the /boot partition, if it is on a separate partition, otherwise /) under /mnt (e.g. /mnt/C6) when you are doing your custom disk layout. As long as they are mounted somewhere in the file system, grub2 seems to find them OK, and add them to your boot menu. It is apparently incapable of looking on unmounted partitions and finding Operating Systems lurking there. d. grub2 is (theoretically) capable of booting off of LVM (and I have done so successfully), BUT that capability is disabled and unsupported in RHEL/Centos 7. You still have to put /boot on a non-LVM partition.
Thanks very much for your response. A couple of comments:
3. Curiously, I see I already have a file /boot/grub2/grub.cfg on my CentOS-6.5 system, though /etc/grub.conf points to /boot/grub/grub.conf . Did I create the grub2 file while experimenting with the system, or is it provided by CentOS-6.5 to simplify upgrading?
3b. When I upgraded another server to CentOS-7 it did not seem to find the old CentOS-6.5, although it found a Windows system OK.
However, I was using the old /boot partition for the new system. I'll try mounting the old boot as /mnt/C6 in the custom setup during the new installation, as you suggest. I shall not give a separate partition for the new /boot - hopefully I shall be able to move /boot to a new partition later.
I had thought, as an alternative method, of cloning the old system to a new partition, and trying the new CentOSUpgradeTool on this. (I'm running a CentOS-6 KDE system, and note that the documentation for the new tool says it will probably not work with KDE or Gnome - which I would have thought would rule out 95% of systems - but it wouldn't matter too much if I still had the old system.)
Timothy Murphy wrote:
- Curiously, I see I already have a file /boot/grub2/grub.cfg
on my CentOS-6.5 system, though /etc/grub.conf points to /boot/grub/grub.conf . Did I create the grub2 file while experimenting with the system, or is it provided by CentOS-6.5 to simplify upgrading?
I should have said that I did run preupg -l after yum install redhat-upgrade-tool preupgrade-assistant-contents as suggested in http://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool. Maybe that creates a test grub2/grub.cfg ?
On 10/26/2014 09:24 AM, Timothy Murphy wrote:
Ted Miller wrote:
I would like to upgrade a CentOS-6.5 home server to CentOS-7 on a new partition. What is the simplest way to achieve this?
- It requires a custom disk layout, but is not particularly hard.
- AFAIK, you can share your SWAP partition between the two installations.
- Centos 7 uses grub2 as its boot loader. It is significantly different
from "legacy grub" used in Centos 6 and before. a. It uses a configuration file that is auto-generated, and not supposed to be edited. b. It is capable of finding other installations (including legacy grub and windows), and creating links to them. c. 'b' only seems to work IF the other boot partitions are mounted somewhere in your file tree. What I have done is mount the other partitions (the /boot partition, if it is on a separate partition, otherwise /) under /mnt (e.g. /mnt/C6) when you are doing your custom disk layout. As long as they are mounted somewhere in the file system, grub2 seems to find them OK, and add them to your boot menu. It is apparently incapable of looking on unmounted partitions and finding Operating Systems lurking there. d. grub2 is (theoretically) capable of booting off of LVM (and I have done so successfully), BUT that capability is disabled and unsupported in RHEL/Centos 7. You still have to put /boot on a non-LVM partition.
Thanks very much for your response. A couple of comments:
- Curiously, I see I already have a file /boot/grub2/grub.cfg
on my CentOS-6.5 system, though /etc/grub.conf points to /boot/grub/grub.conf . Did I create the grub2 file while experimenting with the system, or is it provided by CentOS-6.5 to simplify upgrading?
Never had that happen, so can't comment.
3b. When I upgraded another server to CentOS-7 it did not seem to find the old CentOS-6.5, although it found a Windows system OK.
However, I was using the old /boot partition for the new system.
Sounds like it was looking for /boot/grub, and you over-wrote that when you installed the new system in the old /boot partition.
I have gotten in the habit of either creating or leaving unused some space on any disk that might be used as a boot disk, rather than committing all the space to LVM. That way I have something to work with if I need "yet another" boot partition.
I'll try mounting the old boot as /mnt/C6 in the custom setup during the new installation, as you suggest. I shall not give a separate partition for the new /boot - hopefully I shall be able to move /boot to a new partition later.
I had thought, as an alternative method, of cloning the old system to a new partition, and trying the new CentOSUpgradeTool on this. (I'm running a CentOS-6 KDE system, and note that the documentation for the new tool says it will probably not work with KDE or Gnome - which I would have thought would rule out 95% of systems - but it wouldn't matter too much if I still had the old system.)
I have not tried an upgrade, but it sounds like they put the work into making server upgrades easier, but did not (or could not) make it as easy for desktop installations. Most people paying license fees are covering servers.
Ted Miller Elkhart, IN, USA
Ted Miller wrote:
I have gotten in the habit of either creating or leaving unused some space on any disk that might be used as a boot disk, rather than committing all the space to LVM. That way I have something to work with if I need "yet another" boot partition.
A bit ignorant of me, but is there nowadays any restriction on the choice of boot partition? I don't use LVM (having had some catastrophes several years ago) and always create a small boot partition among the first 3 partitions: sda1 Windows (does MS still require this? sda2 /boot sda3 swap sda4 extended partition I guess this methodology is probably long extinct?
On 10/27/2014 10:31 AM, Timothy Murphy wrote:
Ted Miller wrote:
I have gotten in the habit of either creating or leaving unused some space on any disk that might be used as a boot disk, rather than committing all the space to LVM. That way I have something to work with if I need "yet another" boot partition.
A bit ignorant of me, but is there nowadays any restriction on the choice of boot partition? I don't use LVM (having had some catastrophes several years ago) and always create a small boot partition among the first 3 partitions: sda1 Windows (does MS still require this? sda2 /boot sda3 swap sda4 extended partition I guess this methodology is probably long extinct?
Nothing keeps you from doing it that way, but many of us have gotten used to (and comfortable with) the abstraction layer possible with LVM. Never had any problem with it, and happen to like it.
With grub and grub2, there is no reason to put /boot in a separate partition. That goes back to the days of LILO, when it could only read the first xx megabytes of a disk drive. Both versions of grub are quite comfortable reaching to the back of a big disk to pull up your /boot files.
Ted Miller Elkhart, IN, USA
Ted Miller wrote:
I have not tried an upgrade, but it sounds like they put the work into making server upgrades easier, but did not (or could not) make it as easy for desktop installations. Most people paying license fees are covering servers.
I got the impression that the CentOSUpgradeTool was a CentOS project, rather than an RHEL one?
On 10/27/2014 10:35 AM, Timothy Murphy wrote:
Ted Miller wrote:
I have not tried an upgrade, but it sounds like they put the work into making server upgrades easier, but did not (or could not) make it as easy for desktop installations. Most people paying license fees are covering servers.
I got the impression that the CentOSUpgradeTool was a CentOS project, rather than an RHEL one?
Here is the page describing the RHEL tool they based the Centos tool on: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
I think Centos may have extended it based on their testing, but it is all based on work the RHEL did, so it comes with the same basic structure.
I don't know if there are any tools that would perform this particular upgrade on Gnome or KDE. They have both changed so drastically that translation from old configuration files to new ones would require overwhelming machine intelligence, and it just isn't worth it. In another context, when the new version development of both GUIs wasn't moving so fast, it might work fine. That just isn't this year. If you don't believe me, just go read all the mailing list traffic asking "How do I set ... on Gnome? I used to know exactly what to do, but what I knew doesn't work any more."
Ted Miller Elkhart, IN, USA
On 10/27/2014 09:08 PM, Ted Miller wrote:
On 10/27/2014 10:35 AM, Timothy Murphy wrote:
Ted Miller wrote:
I have not tried an upgrade, but it sounds like they put the work into making server upgrades easier, but did not (or could not) make it as easy for desktop installations. Most people paying license fees are covering servers.
I got the impression that the CentOSUpgradeTool was a CentOS project, rather than an RHEL one?
Here is the page describing the RHEL tool they based the Centos tool on: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
I think Centos may have extended it based on their testing, but it is all based on work the RHEL did, so it comes with the same basic structure.
I don't know if there are any tools that would perform this particular upgrade on Gnome or KDE. They have both changed so drastically that translation from old configuration files to new ones would require overwhelming machine intelligence, and it just isn't worth it. In another context, when the new version development of both GUIs wasn't moving so fast, it might work fine. That just isn't this year. If you don't believe me, just go read all the mailing list traffic asking "How do I set ... on Gnome? I used to know exactly what to do, but what I knew doesn't work any more."
Gnome/KDE can not be upgraded in place, at least not without removing and then reinstalling Gnome/KDE.
Here is the wiki page on the upgrade tool:
http://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool
You can do things like:
yum grouplist
Then remove groups like Gnome and KDE, then upgrade, then groupinstall Gnome or KDE after the upgrade.
I have run upgrades on several test VMs and they did upgrade, but I don't think I would upgrade anything in production in place. And this is not just advise I would give for CentOS .. I would also not upgrade anything in place (Not Windows from XP to Win7 to Win8 .. not any version of Linux from one major version to another, etc.). But thats just me ... I find it much smoother in the long run to reinstall and move data.
Thanks, Johnny hughes
Johnny Hughes wrote:
I have run upgrades on several test VMs and they did upgrade, but I don't think I would upgrade anything in production in place. And this is not just advise I would give for CentOS .. I would also not upgrade anything in place (Not Windows from XP to Win7 to Win8 .. not any version of Linux from one major version to another, etc.). But thats just me ... I find it much smoother in the long run to reinstall and move data.
What about cloning a system to a new partition and then upgrading this?
-
Johnny Hughes -
Ted Miller -
Timothy Murphy -
Timothy Murphy