Hi everyone,
I hope this is the best place to post this question.
I was wondering how can one upgrade from CentOS 6.7 to CentOS 7.x using redhat-upgrade-tool-cli in a scenario where you're upgrading an Hyper-V based VM.
These are the errors I am getting:
[root@apssopenvas /]# /usr/bin/redhat-upgrade-tool-cli --network 7 --instrepo=http://mirror.centos.org/centos/7/os/x86_64 setting up repos... Could not retrieve mirrorlist http://updates.atomicorp.com/channels/mirrorlist/atomic/centos-7.0-x86_64 error was 14: PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Could not retrieve mirrorlist http://updates.atomicorp.com/channels/mirrorlist/atomic-testing/centos-7.0-x... error was 14: PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. 7.0 is not a valid and current release or hasnt been released yet/ removing mirrorlist with no valid mirrors: /var/tmp/system-upgrade/base/mirrorlist.txt YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. 7.0 is not a valid and current release or hasnt been released yet/ removing mirrorlist with no valid mirrors: /var/tmp/system-upgrade/extras/mirrorlist.txt YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. 7.0 is not a valid and current release or hasnt been released yet/ removing mirrorlist with no valid mirrors: /var/tmp/system-upgrade/updates/mirrorlist.txt No upgrade available for the following repos: atomic atomic-testing base extras updates .treeinfo | 1.1 kB 00:00 preupgrade-assistant risk check found EXTREME risks for this upgrade. Run preupg --riskcheck --verbose to view these risks. Continuing with this upgrade is not recommended.
And this is the reason for the risk:
[root@apssopenvas /]# preupg --riskcheck --verbose INPLACERISK: EXTREME: This machine seems to run on a Microsoft hypervisor.
Thank you!
Cheers,
Bruno Martins
Il 06/Gen/2016 11:27, "Bruno Martins" bruno.martins@rumos.pt ha scritto:
Hi everyone,
I hope this is the best place to post this question.
I was wondering how can one upgrade from CentOS 6.7 to CentOS 7.x using
redhat-upgrade-tool-cli in a scenario where you're upgrading an Hyper-V based VM.
These are the errors I am getting:
[root@apssopenvas /]# /usr/bin/redhat-upgrade-tool-cli --network 7
--instrepo=http://mirror.centos.org/centos/7/os/x86_64
setting up repos... Could not retrieve mirrorlist
http://updates.atomicorp.com/channels/mirrorlist/atomic/centos-7.0-x86_64 error was
14: PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Could not retrieve mirrorlist
http://updates.atomicorp.com/channels/mirrorlist/atomic-testing/centos-7.0-x... error was
14: PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. 7.0 is not a valid and current release or hasnt been released yet/ removing mirrorlist with no valid mirrors:
/var/tmp/system-upgrade/base/mirrorlist.txt
YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. 7.0 is not a valid and current release or hasnt been released yet/ removing mirrorlist with no valid mirrors:
/var/tmp/system-upgrade/extras/mirrorlist.txt
YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. 7.0 is not a valid and current release or hasnt been released yet/ removing mirrorlist with no valid mirrors:
/var/tmp/system-upgrade/updates/mirrorlist.txt
No upgrade available for the following repos: atomic atomic-testing base
extras updates
.treeinfo
| 1.1 kB 00:00
preupgrade-assistant risk check found EXTREME risks for this upgrade. Run preupg --riskcheck --verbose to view these risks. Continuing with this upgrade is not recommended.
And this is the reason for the risk:
[root@apssopenvas /]# preupg --riskcheck --verbose INPLACERISK: EXTREME: This machine seems to run on a Microsoft hypervisor.
Thank you!
Cheers,
Bruno Martins _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Hello, I'm not an expert, but did you follow this link? https://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool Because for CentOS I see that the command name begins with centos and not redhat. Also, the main error seems related to "not found" and indeed the mirrorlist path with "7.0" doesn't exist. But it does exist instead the path with http://updates.atomicorp.com/channels/mirrorlist/atomic/centos-7-x86_64 Perhaps a "yum clean all" and then follow the tips page could also resolve the repo mismatch problem. For the hypervisor problem I think it depends on the fact that cpuinfo is that of the hypervisor itself and not a real problem. Just my opinion. Hih, Gianluca
Please note THIS TOOL IS BROKEN and should NOT be used.
On 06/01/16 11:52, Gianluca Cecchi wrote:
Il 06/Gen/2016 11:27, "Bruno Martins" <bruno.martins@rumos.pt mailto:bruno.martins@rumos.pt> ha scritto:
Hi everyone,
I hope this is the best place to post this question.
I was wondering how can one upgrade from CentOS 6.7 to CentOS 7.x
using redhat-upgrade-tool-cli in a scenario where you're upgrading an Hyper-V based VM.
These are the errors I am getting:
[root@apssopenvas /]# /usr/bin/redhat-upgrade-tool-cli --network 7
--instrepo=http://mirror.centos.org/centos/7/os/x86_64
setting up repos... Could not retrieve mirrorlist
http://updates.atomicorp.com/channels/mirrorlist/atomic/centos-7.0-x86_64 error was
14: PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Could not retrieve mirrorlist
http://updates.atomicorp.com/channels/mirrorlist/atomic-testing/centos-7.0-x... error was
14: PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. 7.0 is not a valid and current release or hasnt been released yet/ removing mirrorlist with no valid mirrors:
/var/tmp/system-upgrade/base/mirrorlist.txt
YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. 7.0 is not a valid and current release or hasnt been released yet/ removing mirrorlist with no valid mirrors:
/var/tmp/system-upgrade/extras/mirrorlist.txt
YumRepo Error: All mirror URLs are not using ftp, http[s] or file. Eg. 7.0 is not a valid and current release or hasnt been released yet/ removing mirrorlist with no valid mirrors:
/var/tmp/system-upgrade/updates/mirrorlist.txt
No upgrade available for the following repos: atomic atomic-testing
base extras updates
.treeinfo
| 1.1 kB 00:00preupgrade-assistant risk check found EXTREME risks for this upgrade. Run preupg --riskcheck --verbose to view these risks. Continuing with this upgrade is not recommended.
And this is the reason for the risk:
[root@apssopenvas /]# preupg --riskcheck --verbose INPLACERISK: EXTREME: This machine seems to run on a Microsoft
hypervisor.
Thank you!
Cheers,
Bruno Martins _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org mailto:CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Hello, I'm not an expert, but did you follow this link? https://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool Because for CentOS I see that the command name begins with centos and not redhat. Also, the main error seems related to "not found" and indeed the mirrorlist path with "7.0" doesn't exist. But it does exist instead the path with http://updates.atomicorp.com/channels/mirrorlist/atomic/centos-7-x86_64 Perhaps a "yum clean all" and then follow the tips page could also resolve the repo mismatch problem. For the hypervisor problem I think it depends on the fact that cpuinfo is that of the hypervisor itself and not a real problem. Just my opinion. Hih, Gianluca
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 06/01/16 11:53, Trevor Hemsley wrote:
Please note THIS TOOL IS BROKEN and should NOT be used.
can we quantify this a bit ?
On 06/01/16 13:02, Karanbir Singh wrote:
On 06/01/16 11:53, Trevor Hemsley wrote:
Please note THIS TOOL IS BROKEN and should NOT be used.
can we quantify this a bit ?
The issues have been discussed before but there are many critical packages in CentOS 6 that are already at a higher version than the equivalent ones in CentOS 7. These do not get upgraded and because they do not, various little things like yum itself do not work at all but bail out with missing libs, missing symbols etc. Hughesjr put out a call on the mailing list for volunteers to help fix it but the silence has been deafening and no work has been done.
Last time I looked a sample of the packages concerned were openldap*, nss* and several others that are used by just about everything. Any attempt to use the tool on a CentOS 6.6/6.7 and maybe 6.5 system is pretty much doomed to fail and even if the upgrade is "successful" it's likely the system will either refuse to boot or that many things will just not run afterwards.
There is (was?) also a bug in grubby that failed to deal with grub legacy on el7 so any future kernel updates added a new kernel to the system that would not boot.
Trevor
On Wed, Jan 6, 2016 at 3:31 PM, Trevor Hemsley trevor.hemsley@ntlworld.com wrote:
On 06/01/16 13:02, Karanbir Singh wrote:
On 06/01/16 11:53, Trevor Hemsley wrote:
Please note THIS TOOL IS BROKEN and should NOT be used.
can we quantify this a bit ?
The issues have been discussed before but there are many critical packages in CentOS 6 that are already at a higher version than the equivalent ones in CentOS 7. These do not get upgraded and because they do not, various little things like yum itself do not work at all but bail out with missing libs, missing symbols etc. Hughesjr put out a call on the mailing list for volunteers to help fix it but the silence has been deafening and no work has been done.
Last time I looked a sample of the packages concerned were openldap*, nss* and several others that are used by just about everything. Any attempt to use the tool on a CentOS 6.6/6.7 and maybe 6.5 system is pretty much doomed to fail and even if the upgrade is "successful" it's likely the system will either refuse to boot or that many things will just not run afterwards.
There is (was?) also a bug in grubby that failed to deal with grub legacy on el7 so any future kernel updates added a new kernel to the system that would not boot.
Trevor _______________________________________________
Hello, I think CentOS should concentrate on only what supported in Red Hat too. So we should focus on these two solutions: https://access.redhat.com/solutions/637583 and https://access.redhat.com/solutions/799813
and the equivalent CentOS packages and groups, inherited by related RH channels In particular this would mean only > 6.5 Server based installations on x86_64 and:
OK for Minimal (@minimal) Base (@base) Web Server (@web-server) DHCP Server File Server (@nfs-server) Print Server
KO for All others
Gianluca
On 06/01/16 10:27, Bruno Martins wrote:
Hi everyone,
I hope this is the best place to post this question.
I was wondering how can one upgrade from CentOS 6.7 to CentOS 7.x using redhat-upgrade-tool-cli in a scenario where you're upgrading an Hyper-V based VM.
step1 would be to yum erase anything that didnt come from CentOS-6 itself, you clearly have external repos on there. And I mean not just remove the repos, but actually remove all the content that came from other places. Leave only content from base + updates for CentOS-6 itself.
secondly you need to use the centos tools from the centos repos
Am 06.01.2016 um 14:03 schrieb Karanbir Singh mail-lists@karan.org:
On 06/01/16 10:27, Bruno Martins wrote:
Hi everyone,
I hope this is the best place to post this question.
I was wondering how can one upgrade from CentOS 6.7 to CentOS 7.x using redhat-upgrade-tool-cli in a scenario where you're upgrading an Hyper-V based VM.
step1 would be to yum erase anything that didnt come from CentOS-6 itself, you clearly have external repos on there. And I mean not just remove the repos, but actually remove all the content that came from other places. Leave only content from base + updates for CentOS-6 itself.
secondly you need to use the centos tools from the centos repos
IMHO, I would put this effort (the above, and post activities like verify everything e.g. sanity-checks etc.) into a new setup + service migration. A more clean procedure and better reproducible ...
-- LF
On 06/01/16 13:08, Leon Fauster wrote:
Am 06.01.2016 um 14:03 schrieb Karanbir Singh mail-lists@karan.org:
On 06/01/16 10:27, Bruno Martins wrote:
Hi everyone,
I hope this is the best place to post this question.
I was wondering how can one upgrade from CentOS 6.7 to CentOS 7.x using redhat-upgrade-tool-cli in a scenario where you're upgrading an Hyper-V based VM.
step1 would be to yum erase anything that didnt come from CentOS-6 itself, you clearly have external repos on there. And I mean not just remove the repos, but actually remove all the content that came from other places. Leave only content from base + updates for CentOS-6 itself.
secondly you need to use the centos tools from the centos repos
IMHO, I would put this effort (the above, and post activities like verify everything e.g. sanity-checks etc.) into a new setup + service migration. A more clean procedure and better reproducible ...
yeah, I cant agree more.
The only time the migration process worked for me was on a freshly installed centos6 box, with a minimal install and then upgraded immediately. Admittedly, the only time I ran this was about 6 to 8 months back.
When third party repos get involved, all bets are all. Similarly when desktop components and lots of user data is involved, many bets are also off.
regards
Hi everyone,
Thanks for all your opinions.
I've used the tool with '--force' parameter and it upgraded just fine. Now I'm having some side effects like: "grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory"
Also, OpenVAS does not boot yet.
I'll try a clean install and forget all application-related history.
Cheers, Bruno Martins Rumos Services IT Consultant
Tel. (+351) 808 100 012
Campo Grande, 56, 1700-093 LISBOA www.rumos.pt
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel-bounces@centos.org] On Behalf Of Karanbir Singh Sent: 6 de janeiro de 2016 13:25 To: centos-devel@centos.org Subject: Re: [CentOS-devel] CentOS Upgrade Tool
On 06/01/16 13:08, Leon Fauster wrote:
Am 06.01.2016 um 14:03 schrieb Karanbir Singh mail-lists@karan.org:
On 06/01/16 10:27, Bruno Martins wrote:
Hi everyone,
I hope this is the best place to post this question.
I was wondering how can one upgrade from CentOS 6.7 to CentOS 7.x using redhat-upgrade-tool-cli in a scenario where you're upgrading an Hyper-V based VM.
step1 would be to yum erase anything that didnt come from CentOS-6 itself, you clearly have external repos on there. And I mean not just remove the repos, but actually remove all the content that came from other places. Leave only content from base + updates for CentOS-6 itself.
secondly you need to use the centos tools from the centos repos
IMHO, I would put this effort (the above, and post activities like verify everything e.g. sanity-checks etc.) into a new setup + service migration. A more clean procedure and better reproducible ...
yeah, I cant agree more.
The only time the migration process worked for me was on a freshly installed centos6 box, with a minimal install and then upgraded immediately. Admittedly, the only time I ran this was about 6 to 8 months back.
When third party repos get involved, all bets are all. Similarly when desktop components and lots of user data is involved, many bets are also off.
regards
On 01/06/2016 04:24 PM, Bruno Martins wrote:
Hi everyone,
Thanks for all your opinions.
I've used the tool with '--force' parameter and it upgraded just fine. Now I'm having some side effects like: "grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory"
Also, OpenVAS does not boot yet.
"libpcre.so.0: cannot open shared object file: No such file or directory"" + "does not boot yet" are the exact opposite of "upgraded just fine"
Upgraded just fine means it completed the upgrade process and system booted without any major issue. ;-)
I'll just try a more clean approach like some of you have suggested, in order to avoid future problems. Bruno Martins Rumos Services IT Consultant
Tel. (+351) 808 100 012
Campo Grande, 56, 1700-093 LISBOA www.rumos.pt
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel-bounces@centos.org] On Behalf Of Manuel Wolfshant Sent: 6 de janeiro de 2016 14:27 To: The CentOS developers mailing list. centos-devel@centos.org Subject: Re: [CentOS-devel] CentOS Upgrade Tool
On 01/06/2016 04:24 PM, Bruno Martins wrote:
Hi everyone,
Thanks for all your opinions.
I've used the tool with '--force' parameter and it upgraded just fine. Now I'm having some side effects like: "grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory"
Also, OpenVAS does not boot yet.
"libpcre.so.0: cannot open shared object file: No such file or directory"" + "does not boot yet" are the exact opposite of "upgraded just fine"
_______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Jan 6, 2016 at 7:24 AM, Bruno Martins bruno.martins@rumos.pt wrote:
I've used the tool with '--force' parameter and it upgraded just fine. Now I'm having some side effects like: "grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory"
I had a similar issue with grep when I upgraded my CentOS 6 home server to CentOS 7 last week. As explained elsewhere, the issue is that not all .el6 packages get upgraded.
To fix it, after I did the OS upgrade to CentOS 7:
- Generate a list of all packages with "rpm -qa", - Note each of the ".el6" ones, - Download the ".el7" equivalents from a CentOS mirror by hand, - Install the .el7 versions with "rpm --force" (so RPM thinks you have both versions installed) - Use yum to remove the ".el6" versions.
There are some packages like python-argparse that don't have a direct equivalent in CentOS 7 (the argparse library is provided by the core python-2.7 package), so those are simply safe to remove outright. You might find that there's other crufty el6 packages left behind on your server that you don't need.
I host my OS (/boot and /) on software RAID1 (with mdadm), and for a while, the first el7 kernel I installed didn't add both drives to the array devices during boots, which made me wonder if the drives were dying. But it just turned out to be a software issue (maybe something in the very first initrd generation went awry?), because after I ran "yum update" to get the latest el7 kernel, it worked fine.
Once you finish the OS upgrade, if you see problems during operation, start with checking "rpm -qa" for "el6" and then working through the individual packages one-by-one. (you'll probably want to start with fixing "grep", since it's tedious to work without it :)
- Ken
On 6 ianuarie 2016 18:49:32 EET, Ken Dreyer kdreyer@redhat.com wrote:
On Wed, Jan 6, 2016 at 7:24 AM, Bruno Martins bruno.martins@rumos.pt wrote:
I've used the tool with '--force' parameter and it upgraded just
fine. Now I'm having some side effects like:
"grep: error while loading shared libraries: libpcre.so.0: cannot
open shared object file: No such file or directory"
I had a similar issue with grep when I upgraded my CentOS 6 home server to CentOS 7 last week. As explained elsewhere, the issue is that not all .el6 packages get upgraded.
To fix it, after I did the OS upgrade to CentOS 7:
- Generate a list of all packages with "rpm -qa",
- Note each of the ".el6" ones,
- Download the ".el7" equivalents from a CentOS mirror by hand,
- Install the .el7 versions with "rpm --force" (so RPM thinks you have
both versions installed)
- Use yum to remove the ".el6" versions.
There are some packages like python-argparse that don't have a direct equivalent in CentOS 7 (the argparse library is provided by the core python-2.7 package), so those are simply safe to remove outright. You might find that there's other crufty el6 packages left behind on your server that you don't need.
I host my OS (/boot and /) on software RAID1 (with mdadm), and for a while, the first el7 kernel I installed didn't add both drives to the array devices during boots, which made me wonder if the drives were dying. But it just turned out to be a software issue (maybe something in the very first initrd generation went awry?), because after I ran "yum update" to get the latest el7 kernel, it worked fine.
Once you finish the OS upgrade, if you see problems during operation, start with checking "rpm -qa" for "el6" and then working through the individual packages one-by-one. (you'll probably want to start with fixing "grep", since it's tedious to work without it :)
And once you find out that you have to do all those manually, you might as well ditch the upgrade tool altogether.
Hi,
Ken Dreyer kdreyer@redhat.com hat am 6. Januar 2016 um 17:49 geschrieben:
On Wed, Jan 6, 2016 at 7:24 AM, Bruno Martins bruno.martins@rumos.pt wrote:
I've used the tool with '--force' parameter and it upgraded just fine. Now I'm having some side effects like: "grep: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory"
I had a similar issue with grep when I upgraded my CentOS 6 home server to CentOS 7 last week. As explained elsewhere, the issue is that not all .el6 packages get upgraded.
I have upgraded a couple of C6 machines last weeks, it works much better with 7.2 now, at least the system boots and ssh works :)
The grep issue can be fixed after upgrade very simply:
$ yum downgrade grep
BR Ulrich
On 12/01/16 21:20, Ulrich Leodolter wrote:
I have upgraded a couple of C6 machines last weeks, it works much better with 7.2 now, at least the system boots and ssh works :)
The grep issue can be fixed after upgrade very simply:
$ yum downgrade grep
First off I *do not* support the use of the upgrade tool under any circumstances, just in case I haven't made my position clear in the past. That said, you'll probably do a more thorough job of fixing all the mistakes made by the upgrade too if you follow it up with:
yum distro-sync
This should fix grep and any other package that is still left on the el6 version.
Peter
-
Bruno Martins -
Gianluca Cecchi -
Karanbir Singh -
Ken Dreyer -
Leon Fauster -
Manuel Wolfshant -
Peter -
Trevor Hemsley -
Ulrich Leodolter