[CentOS-devel] Reminder: CentOS 6 EOL on 30 November 2020

On 12/2/20 11:36 PM, Phelps, Matthew wrote:
>
>
> On Wed, Dec 2, 2020 at 4:17 PM Stephen John Smoogen <smooge at gmail.com 
> <mailto:smooge at gmail.com>> wrote:
>
>
>
>     On Wed, 2 Dec 2020 at 16:09, Phelps, Matthew
>     <mphelps at cfa.harvard.edu <mailto:mphelps at cfa.harvard.edu>> wrote:
>
>
>
>
>         On Wed, Dec 2, 2020 at 3:43 PM Patrick Riehecky
>         <riehecky at fnal.gov <mailto:riehecky at fnal.gov>> wrote:
>
>             Some folks may continue running EL6 based systems, but we
>             need to make
>             sure it is obvious that we're not providing any security
>             updates.
>             Moving the repos off the mirror network will provide a
>             hint to folks
>             doing a simple 'yum update' that something is not the way
>             it once was.
>
>
>             Pat
>
>
>         Whoa!
>
>         What will happen if I run a "yum update" on a CO6 machine? We
>         have it run automatically at reboot and I need to know what
>         will happen so I can see if the rest of the scripts we run at
>         startup will be OK.
>
>         Yes we are updating them, but it's hard to do when you can't
>         go onsite due to COVID.
>
>
>     You will get every system running through messages like this
>
>
>     [root at linode01 ~]# yum update
>     Loaded plugins: etckeeper, fastestmirror
>     Setting up Update Process
>     Loading mirror speeds from cached hostfile
>     epel/metalink  | 2.5 kB     00:00
>     epel-testing/metalink  | 2.6 kB     00:00
>      * base: mirror.dal10.us.leaseweb.net
>     <http://mirror.dal10.us.leaseweb.net>
>      * epel: d2lzkl7pfhq30w.cloudfront.net
>     <http://d2lzkl7pfhq30w.cloudfront.net>
>      * epel-testing: d2lzkl7pfhq30w.cloudfront.net
>     <http://d2lzkl7pfhq30w.cloudfront.net>
>      * extras: mirror.netdepot.com <http://mirror.netdepot.com>
>      * updates: mirrors.usinternet.com <http://mirrors.usinternet.com>
>     http://mirror.dal10.us.leaseweb.net/centos/6.10/os/i386/repodata/repomd.xml:
>     [Errno 14] PYCURL ERROR 22 - "The requested URL returned error:
>     404 Not Found"
>     Trying other mirror.
>     To address this issue please refer to the below wiki article
>
>     https://wiki.centos.org/yum-errors
>
>     If above article doesn't help to resolve this issue please use
>     https://bugs.centos.org/.
>     http://bay.uchicago.edu/centos/6.10/extras/i386/repodata/repomd.xml:
>     [Errno 14] PYCURL ERROR 22 - "The requested URL returned error:
>     404 Not Found"
>     Trying other mirror.
>
>     until it finds some mirror which will work (that one mirror seems
>     to be updating for everyone in the world so is very slow).
>
>     or it will do the following:
>
>     [root at linode01 ~]# yum clean all
>     Loaded plugins: etckeeper, fastestmirror
>     Cleaning repos: base cr epel epel-testing extras updates
>     Cleaning up Everything
>     Cleaning up list of fastest mirrors
>     [root at linode01 ~]# yum update
>     Loaded plugins: etckeeper, fastestmirror
>     Setting up Update Process
>     Determining fastest mirrors
>     YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
>      Eg. Invalid release/repo/arch combination/
>     removing mirrorlist with no valid mirrors:
>     /var/cache/yum/i386/6/base/mirrorlist.txt
>     Error: Cannot find a valid baseurl for repo: base
>     [root at linode01 ~]# echo $?
>     1
>     [root at linode01 ~]# yum list all
>     Loaded plugins: etckeeper, fastestmirror
>     Loading mirror speeds from cached hostfile
>     YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
>      Eg. Invalid release/repo/arch combination/
>     removing mirrorlist with no valid mirrors:
>     /var/cache/yum/i386/6/base/mirrorlist.txt
>     Error: Cannot find a valid baseurl for repo: base
>
>     so basically the system can not find anything/do anything until a
>     working mirror is there.
>
>
> I'm not really very happy with this throwing an error.
>
> I get it. People need to upgrade. But breaking things that are part of 
> automated processes is a crappy way to get the message across.
>
> As I mentioned, upgrades will take some time still, and now I have 
> more work to deal with our unupgraded systems, so now it will take 
> even longer to upgrade.
>
> Thanks a bunch.
>
> (Sorry for the sarcasm, but this is not a nice way to deal with the 
> situation).


Welcome to the club. Now wait for the free membership to the " You had 
_years_ advanced notice." to come, it's on its way.


wolfy "I still have a few hundred remote desktops to upgrade ( and could 
not do that due to remote access restrictions collateral to Covid moving 
around restrictions )"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20201203/ce6141af/attachment-0002.html>