0% found this document useful (0 votes)
15 views7 pages

Fixing Yum Repository Errors in Oracle DB

The document outlines various errors encountered during patching processes on multiple Oracle Linux servers, primarily due to HTTP 503 Service Unavailable errors from the yum repository URLs. It details the commands executed and the subsequent failures, including issues with stopping database instances and downloading packages. A solution is provided by disabling unnecessary yum repositories that were causing the errors, allowing the patching process to continue successfully.

Uploaded by

karthik
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views7 pages

Fixing Yum Repository Errors in Oracle DB

The document outlines various errors encountered during patching processes on multiple Oracle Linux servers, primarily due to HTTP 503 Service Unavailable errors from the yum repository URLs. It details the commands executed and the subsequent failures, including issues with stopping database instances and downloading packages. A solution is provided by disabling unnecessary yum repositories that were causing the errors, allowing the patching process to continue successfully.

Uploaded by

karthik
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd

Failed

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
rsysdev3 bi db
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

721 vmbmospatch_bi_rsysdev3_JAN2025_20250430_094120vmospatch_req
541 2025-04-30 09:43:04 UN 10

python owfe_req_details_v1.py -reqid 721

nohup python [Link] -wfid 541 -reqid 721 &

python owfe_force_comp_task.py 1616

nohup python [Link] -wfid 541 -reqid 721 -resume </dev/null >/dev/null 2>&1
&
+++++
Error
++++++

[Link]
repodata/[Link]: [Errno 14] curl#22 - "The requested URL returned error: 503"
Trying other mirror.

failure: repodata/[Link] from ol7_ociyum_config: [Errno 256] No more mirrors to


try.
[Link]
repodata/[Link]: [Errno 14] curl#22 - "The requested URL returned error: 503"

2025-04-30 09:50:21 [ERROR] (root) <MainThread> - STDOUT:

-phx
Loaded plugins: ulninfo, versionlock

2025-04-30 09:50:21 [ERROR] (root) <MainThread> - EXITED:

2025-04-30 09:50:21 [ERROR] (root) <MainThread> - <[Link] exited: "1" cmd:


"sudo grep phx /etc/yum/vars/oc ...">

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
rsysdev3 rman db
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

722 vmbmospatch_rc_rsysdev3_JAN2025_20250430_094120vmospatch_req
541 2025-04-30 09:57:50 FA 10

python owfe_req_details_v1.py -reqid 722


nohup python [Link] -wfid 541 -reqid 722 &

python owfe_force_comp_task.py 7211

nohup python [Link] -wfid 541 -reqid 722 -resume </dev/null >/dev/null 2>&1
&

+++++
Error
++++++

[Link]
[Link]: [Errno 14] curl#22 - "The requested URL returned error: 503"
Trying other mirror.
[Link]
repodata/[Link]: [Errno 14] curl#22 - "The requested URL returned error: 503"
Trying other mirror.
[Link]
repodata/[Link]: [Errno 14] curl#22 - "The requested URL returned error: 503"
Trying other mirror.
Excluding 2 updates due to versionlock (use "yum versionlock status" to show them)
Resolving Dependencies

Transaction Summary
===================================================================================
===================================================================================
=======
Install 3 Packages
Upgrade 157 Packages
Remove 3 Packages

Total size: 644 M


Total download size: 74 M
Is this ok [y/d/N]: y
Downloading packages:
No Presto metadata available for ol7_ociyum_config
[Link] FAILED
[Link]
getPackage/[Link]: [Errno 14] curl#22 - "The requested URL
returned error: 503"
Trying other mirror.

Error downloading packages:


jre1.8-1.8.0_361-fcs.x86_64: [Errno 256] No more mirrors to try.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
rsysdev3 AQ db
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[root@rijms-aq11 tmp]# curl -I


[Link]
[Link]
HTTP/1.1 503 Service Unavailable
Server: squid/4.6
Mime-Version: 1.0
Date: Wed, 30 Apr 2025 10:42:09 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 1961
X-Squid-Error: ERR_DNS_FAIL 0
Vary: Accept-Language
Content-Language: en

curl: (56) Received HTTP code 503 from proxy after CONNECT
[root@rijms-aq11 tmp]#

looks like the yum repo url is not reachable from all of the rsysdev3 servers

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
rsysdev1 BI db
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1141 vmbmospatch_bi_rsysdev1_JAN2025_20250430_105730vmospatch_req
1001 2025-04-30 11:00:36 IN 10

---same 503 error

********** COMPLETED BY IMPLEMENTING THE BELOW FIX ON BOTH THE NODES **************

sudo yum-config-manager --disable ol7_UEKR5 ol7_addons ol7_ociyum_config


ol7_optional_latest

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
rsysdev1 AQ db
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

issue 1
+++++++++

2025-04-30 12:44:55 [ERROR] (shutdown_inst.[Link]-


[Link].d101003x_phx1mg.rijms-
[Link]) - Cannot run command
/u01/app/oracle/product/[Link]/dbhome_1/bin/srvctl stop instance -db
d101003x_phx1mg -instance d101003x1 -o "NORMAL" -failover

2025-04-30 12:44:55 [ERROR] (shutdown_inst.[Link]-


[Link].d101003x_phx1mg.rijms-
[Link]) - STDERR:
2025-04-30 12:44:55 [ERROR] (shutdown_inst.[Link]-
[Link].d101003x_phx1mg.rijms-
[Link]) - STDOUT:
PRCD-1131 : Failed to stop database d101003x_phx1mg and its services on nodes
rijms-aq11
PRCR-1133 : Failed to stop database d101003x_phx1mg and its running services
PRCR-1132 : Failed to stop resources using a filter
CRS-2974: unable to act on resource 'ora.d101003x_phx1mg.db' on server 'rijms-aq11'
because that would require stopping or relocating resource
'ora.d101003x_phx1mg.d101003x_d101003aq1.[Link]' but the appropriate
force flag was not specified

oracle@rijms-aq11 ~ d101003x1 >$srvctl status service -d $ORACLE_UNQNAME


Service d101003aq1_001_01 is running on instance(s) d101003x2
Service d101003aq1_admin is running on instance(s) d101003x2
Service d101003x_admin is running on instance(s) d101003x2
Service d101003x_d101003aq1.[Link] is running on instance(s)
d101003x1,d101003x2

ora.d101003x_phx1mg.d101003x_d101003aq1.[Link] --> This service is


running in both the nodes and the automation failed to stop the instance

srvctl stop instance -d $ORACLE_UNQNAME -i $ORACLE_SID -failover

****** STOPPED THE SERVICE d101003x_d101003aq1.[Link] ON BOTH THE NODES


AND CONTINUED *********

issue 2
+++++++++

failure: repodata/[Link] from ol7_addons: [Errno 256] No more mirrors to try.


[Link]
[Link]: [Errno 14] curl#22 - "The requested URL returned error: 503"

2025-04-30 01:21:37 [ERROR] (root) <MainThread> - STDOUT:

-phx
Loaded plugins: ulninfo, versionlock

2025-04-30 01:21:37 [ERROR] (root) <MainThread> - EXITED:

2025-04-30 01:21:37 [ERROR] (root) <MainThread> - <[Link] exited: "1" cmd:


"sudo grep phx /etc/yum/vars/oc ...">

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++

Fixes
+++++++++++

sudo yum-config-manager --disable ol7_UEKR5


yum repolist enabled | grep ol7_UEKR5

sudo yum-config-manager --disable ol7_addons


yum repolist enabled | grep ol7_addons

sudo yum-config-manager --disable ol7_ociyum_config


yum repolist enabled | grep ol7_ociyum_config

sudo yum-config-manager --disable ol7_optional_latest


yum repolist enabled | grep ol7_optional_latest

sudo yum-config-manager --disable ol7_UEKR5 ol7_addons ol7_ociyum_config


ol7_optional_latest
yum repolist enabled

yum-config-manager ol7_UEKR5 | grep enabled


yum-config-manager --disable ol7_UEKR5

yum-config-manager ol7_addons | grep enabled


yum-config-manager --disable ol7_addons

yum-config-manager ol7_ociyum_config | grep enabled


yum-config-manager --disable ol7_ociyum_config

yum-config-manager ol7_optional_latest | grep enabled


yum-config-manager --disable ol7_optional_latest

These repos were causing repeated HTTP 503 - Service Unavailable errors during
patching
These repos were not required for the kernel version or the current patch scope on
our servers.
kernel version - 4.12

• ol7_UEKR5 is used only if we’re running or upgrading to UEK5, but we’re


on UEK4.
• ol7_ociyum_config and ol7_optional_latest are for OCI-specific or
optional components not relevant to our current patch cycle.

Repository ol7_UEKR4_archive is listed more than once in the configuration


Repository ol7_security_validation is listed more than once in the configuration
[Link]
[Link]: [Errno 14] HTTP Error 503 - Service Unavailable
Trying other mirror.
[Link]
[Link]: [Errno 14] curl#22 - "The requested URL returned error: 503"
Trying other mirror.
[Link]
repodata/[Link]: [Errno 14] curl#22 - "The requested URL returned error: 503"
Trying other mirror.
[Link]
repodata/[Link]: [Errno 14] curl#22 - "The requested URL returned error: 503"
Trying other mirror.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++

[root@ridb-yymby1 dbserver_patch_250417]# ./patchmgr -dbnodes ../dbs_group -


precheck -iso_repo /u01/patching/[Link].0.250213/p37471710_251000_Linux-x86-
[Link] -target_version [Link].0.250213.1 -nomodify_at_prereq -
allow_non_signed_repo

***********************************************************************************
*************************
NOTE patchmgr release: 25.250417 (always check MOS 1553103.1 for the latest
release of [Link])
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
***********************************************************************************
*************************
2025-05-02 09:58:17 +0000 :INFO : Checking hosts connectivity via
ICMP/ping
2025-05-02 09:58:18 +0000 :INFO : Hosts Reachable: [ridb-yymby2]
2025-05-02 09:58:18 +0000 :INFO : All hosts are reachable via ICMP/ping
2025-05-02 09:58:19 +0000 :Working: Verify SSH equivalence for the root user
to ridb-yymby2
2025-05-02 09:58:19 +0000 :SUCCESS: Verify SSH equivalence for the root user
to ridb-yymby2
2025-05-02 09:58:22 +0000 :Working: Initiate precheck on 1 node(s)
2025-05-02 09:58:24 +0000 :INFO : Preparing nodes: ridb-yymby2
2025-05-02 09:58:24 +0000 :Working: Check for enough free space on ridb-
yymby2 to transfer and unzip files.
2025-05-02 09:58:28 +0000 :SUCCESS: Check for enough free space on ridb-
yymby2 to transfer and unzip files.
2025-05-02 09:58:50 +0000 :Working: [Link] running a precheck for
the conventional update on node(s).
2025-05-02 10:01:43 +0000 :INFO : Node ridb-yymby2 will not be Live
Updated.
2025-05-02 10:01:54 +0000 :SUCCESS: Initiate precheck on node(s).

2025-05-02 10:01:56 +0000 :SUCCESS: Completed run of command: ./patchmgr -


dbnodes ../dbs_group -precheck -iso_repo
/u01/patching/[Link].0.250213/p37471710_251000_Linux-[Link] -target_version
[Link].0.250213.1 -nomodify_at_prereq -allow_non_signed_repo
2025-05-02 10:01:56 +0000 :INFO : Precheck performed on dbnode(s) in
file ../dbs_group: [ridb-yymby2]
2025-05-02 10:01:56 +0000 :INFO : Current image version on dbnode(s) is:
2025-05-02 10:01:56 +0000 :INFO : ridb-yymby2: [Link].0.240809.1
2025-05-02 10:01:56 +0000 :INFO : For details, check the following files
in /u01/patching/[Link].0.250205/dbserver_patch_250417:
2025-05-02 10:01:56 +0000 :INFO : - <dbnode_name>_dbnodeupdate.log
2025-05-02 10:01:56 +0000 :INFO : - [Link]
2025-05-02 10:01:56 +0000 :INFO : - [Link]
2025-05-02 10:01:56 +0000 :INFO : Exit status:0
2025-05-02 10:01:56 +0000 :INFO : Exiting.
[root@ridb-yymby1 dbserver_patch_250417]#

Common questions

Powered by AI

The specific issue encountered was the failure to stop the database instance due to the need for a force flag, as stopping certain resources depended on relocating others, which was not initially handled. This indicates a need for improving automation scripts to include conditional checks for dependencies and proper usage of force flags to handle such conflicts automatically .

The automation system's failure to stop a database service highlights the importance of operational flags such as the force flag, which was not specified. The failure stemmed from the need to relocate dependent resources before stopping a service, demonstrating the need for precise automation commands that account for service dependencies. The solution proposed was manual intervention to stop the services before resuming automation .

The repeated HTTP 503 errors during the patching process were caused by the unavailability of required yum repository mirrors. This issue was compounded by unnecessary repositories being enabled, which were not required for the current kernel version or patch scope. Specifically, repos such as ol7_UEKR5, ol7_ociyum_config, and ol7_optional_latest were contributing to the errors .

Certain repositories such as ol7_UEKR5, ol7_addons, ol7_ociyum_config, and ol7_optional_latest were disabled because they caused HTTP 503 errors and were not required for the targeted kernel version or current patching scope. The system was not using UEK5, but UEK4, and the OCI-specific and optional components were irrelevant for the current patch cycle .

The current kernel version, being UEK4, made certain repositories such as ol7_UEKR5 unnecessary, as they were only relevant when running or upgrading to UEK5 . The decision to disable these repositories was to avoid unnecessary HTTP 503 errors that plagued the patching process, optimizing the update path for the actual server configuration requirements .

The issue of failing database instance stop actions on rsysdev1 was addressed by manually stopping the service d101003x_d101003aq1.paas.oracle.com on both nodes . This manual intervention allowed automation to continue after it initially failed to stop the instance due to a missing force flag .

The document highlights successful pings and SSH verification as pre-requisites for continuing the patching process. The success in verifying SSH equivalence for root users and confirming host reachability via ICMP/ping were necessary steps ensuring network accessibility, which is crucial for transferring files and executing remote commands reliably during updates .

When using patch manager tools, it is advised not to interrupt the session, resize the screen, reboot database nodes, or open log files in write mode, as these actions could disrupt the patching process and potentially lead to data corruption or system instability . These precautions ensure that the patching process runs smoothly without intervention or unintended data loss.

The precheck processes, as seen in the document, verified host connectivity, SSH equivalence, and ensured there was enough free space to transfer and unzip files on the node ridb-yymby2. The precheck was successful, indicating readiness for the conventional update without live updates . It provided assurance that the nodes were properly prepared for the update, thus minimizing the risk of errors during patching.

To handle the failure of accessing specific URLs which returned HTTP 503 errors, the strategy involved manually disabling problematic repositories with yum-config-manager, thereby preventing repeated request errors linked to mirror availability . This adjustment helped streamline the update process by removing irrelevant and error-prone repositories from the configuration.

You might also like