Skip to main content

Installation failure of cPanel - Ubuntu & MariaDB 10.6



  • cPRex Jurassic Moderator

    Hey there!  Can you let me know what you mean when you say you "installed" MariaDB on the server?  Nothing should be installed on the system before the cPanel installation runs or you will experience issues.

    If you want to install MariaDB on a new installation you'll need to follow the details outlined here:

  • alfasoft

    The server contains a clean installation of Ubuntu 20.04. I created the file cpanel.config inside the folder /root/cpanel_profile with the content "mysql-version=10.5". I run the installation script and got the above messages.

    Thank you.

  • cPRex Jurassic Moderator

    Thanks for the confirmation about that configuration.  It looks like there may be other issues with the system then, since the server isn't able to download the repo files at all.  I'd recommend speaking to the host about this problem and having them check the network settings on the machine.

  • alfasoft

    A network issue would not return 403 error. The machine is an EC2 instance. I am able to access the instance via SSH without any issues, and numerous other packages have been installed successfully. Only MariaDB has encountered failures. Therefore, network problems should be ruled out.


  • cPRex Jurassic Moderator

    I suppose that's true!

    The error almost reads like your IP is specifically being blocked from the MariaDB mirrors, which would be odd as well.

    As a test, can you run this command from your server?

  • alfasoft

    It runs without problemas

    root@ip-172-31-1-219:/home# wget
    --2024-06-10 16:18:05--
    Resolving (,, 2606:4700::6811:bf0e, ...
    Connecting to (||:443... connected.
    HTTP request sent, awaiting response... 302 Found
    Location: [following]
    --2024-06-10 16:18:06--
    Resolving (,,, ...
    Connecting to (||:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 4036 (3.9K) [application/x-debian-package]
    Saving to: ‘mariadb-common_10.6.18+maria~ubu2004_all.deb.1’

    mariadb-common_10.6.18+maria~ubu2004_all.deb.1                                 100%[====================================================================================================================================================================================================>]   3.94K  --.-KB/s    in 0s      

    2024-06-10 16:18:06 (49.2 MB/s) - ‘mariadb-common_10.6.18+maria~ubu2004_all.deb.1’ saved [4036/4036]
  • cPRex Jurassic Moderator

    Interesting - what about curl instead?

    curl -v
  • alfasoft
    root@ip-172-31-1-219:/home# curl -v 
    *   Trying
    * TCP_NODELAY set
    * Connected to ( port 443 (#0)
    * ALPN, offering h2
    * ALPN, offering http/1.1
    * successfully set certificate verify locations:
    *   CAfile: /etc/ssl/certs/ca-certificates.crt
     CApath: /etc/ssl/certs
    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
    * TLSv1.3 (IN), TLS handshake, Server hello (2):
    * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
    * TLSv1.3 (IN), TLS handshake, Certificate (11):
    * TLSv1.3 (IN), TLS handshake, CERT verify (15):
    * TLSv1.3 (IN), TLS handshake, Finished (20):
    * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
    * TLSv1.3 (OUT), TLS handshake, Finished (20):
    * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
    * ALPN, server accepted to use h2
    * Server certificate:
    *  subject:
    *  start date: Jun  8 17:49:20 2024 GMT
    *  expire date: Sep  6 17:49:19 2024 GMT
    *  subjectAltName: host "" matched cert's "*"
    *  issuer: C=US; O=Google Trust Services; CN=WE1
    *  SSL certificate verify ok.
    * Using HTTP2, server supports multi-use
    * Connection state changed (HTTP/2 confirmed)
    * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
    * Using Stream ID: 1 (easy handle 0x5599deae2910)
    > GET /repo/mariadb-server/10.6/repo/ubuntu/pool/main/m/mariadb-10.6/mariadb-common_10.6.18+maria~ubu2004_all.deb HTTP/2
    > Host:
    > user-agent: curl/7.68.0
    > accept: */*
    * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
    * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
    * old SSL session ID is stale, removing
    * Connection state changed (MAX_CONCURRENT_STREAMS == 100)!

    < HTTP/2 302  
    < date: Mon, 10 Jun 2024 16:42:43 GMT
    < content-type: text/html; charset=utf-8
    < content-length: 0
    < location:
    < x-frame-options: SAMEORIGIN
    < vary: Cookie, Origin
    < via: 1.1 google
    < cf-cache-status: DYNAMIC
    < server: cloudflare
    < cf-ray: 891ad0f1bc6d6985-CDG
    * Connection #0 to host left intact
  • cPRex Jurassic Moderator

    It's interesting that works well when your other connection is blocked over port 443.  I really don't have a good explanation for this one, so reaching out to the host would be best as we don't have any control over those mirrors.

  • alfasoft

    I resolved my issue by cloning another instance. However, I believe this might affect other users.

    Thank you.

  • cPRex Jurassic Moderator

    It's completely possible it will, but we'd likely need access to an affected system to confirm if there is a deeper issue.

  • alfasoft

    Sorry for the delay. But if you wrant, I can provide access to EC2 for testing.

  • cPRex Jurassic Moderator

    If you can create a ticket with our team we'd be happy to check!


Please sign in to leave a comment.