Home apt linux ubuntu virtual machines

Ubuntu APT Issues? Troubleshoot Common Problems on Virtual Machines

Updated: • 0 • min read
Table of Contents

Applies to: Linux VMs

This article discusses common issues you might encounter when using the apt command-line tool to install or update applications on Microsoft Azure virtual machines (VMs) and provides solutions to address them. Understanding the underlying causes of these problems can help you efficiently diagnose and resolve package management difficulties in your Azure environment.

Ubuntu APT Troubleshooting Azure VM

Overview

The apt (Advanced Package Tool) command is a fundamental utility on Ubuntu systems for managing software packages. It facilitates the installation, removal, updating, and overall management of applications. apt simplifies the software management process by offering a command-line interface to interact with the APT libraries, making it easier to search for packages, install specific versions, and handle complex dependencies. This powerful tool is essential for maintaining a healthy and up-to-date Ubuntu environment.

Prerequisites

To effectively troubleshoot the issues discussed in this article, familiarity with the following tools and concepts is helpful:

  • Advanced Packaging Tool (apt)
  • curl
  • GNU Privacy Guard (GPG)
  • tee
  • Basic understanding of networking concepts (IP addresses, ports, firewalls, DNS)
  • Basic understanding of Azure networking components (VMs, Network Interfaces, Subnets, Load Balancers, NAT Gateway, Network Security Groups, Azure Firewall, User-Defined Routes).

Scenario 1: Connection timed out on azure.archive.ubuntu.com

Scenario 1 Details

When attempting an apt update, upgrade, or installation operation, the connection to the Ubuntu repositories eventually times out. This failure is often accompanied by error messages indicating an inability to connect or a connection timeout. The error outputs typically point to azure.archive.ubuntu.com as the unreachable host.

Here are examples of the error messages you might see:

Output 1

Err:2 http://azure.archive.ubuntu.com/ubuntu jammy-updates/main amd64 dns-root-data all 2023112702~ubuntu0.22.04.1
  Unable to connect to azure.archive.ubuntu.com:http:
Ign:3 http://azure.archive.ubuntu.com/ubuntu jammy-updates/main amd64 bind9 amd64 1:9.18.18-0ubuntu0.22.04.2
Err:1 http://azure.archive.ubuntu.com/ubuntu jammy-updates/main amd64 bind9-utils amd64 1:9.18.18-0ubuntu0.22.04.2
  Could not connect to azure.archive.ubuntu.com:80 (52.147.219.192), connection timed out
Err:3 http://azure.archive.ubuntu.com/ubuntu jammy-updates/main amd64 bind9 amd64 1:9.18.18-0ubuntu0.22.04.2
  Unable to connect to azure.archive.ubuntu.com:http:
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/b/bind9/bind9-utils_9.18.18-0ubuntu0.22.04.2_amd64.deb  Could not connect to azure.archive.ubuntu.com:80 (52.147.219.192), connection timed out
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/d/dns-root-data/dns-root-data_2023112702%7eubuntu0.22.04.1_all.deb  Unable to connect to azure.archive.ubuntu.com:http:
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/b/bind9/bind9_9.18.18-0ubuntu0.22.04.2_amd64.deb  Unable to connect to azure.archive.ubuntu.com:http:
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

Output 2

W: Tried to start delayed item http://azure.archive.ubuntu.com/ubuntu jammy-updates/main amd64 distro-info-data all 0.52ubuntu0.7, but failed
W: Tried to start delayed item http://azure.archive.ubuntu.com/ubuntu jammy-updates/main amd64 distro-info-data all 0.52ubuntu0.7, but failed
W: Tried to start delayed item http://azure.archive.ubuntu.com/ubuntu jammy-updates/main amd64 distro-info-data all 0.52ubuntu0.7, but failed
W: Tried to start delayed item http://azure.archive.ubuntu.com/ubuntu jammy-updates/main amd64 distro-info-data all 0.52ubuntu0.7, but failed
W: Tried to start delayed item http://azure.archive.ubuntu.com/ubuntu jammy-updates/main amd64 distro-info-data all 0.52ubuntu0.7, but failed

These errors indicate a network connectivity problem preventing the VM from reaching the Ubuntu package repositories hosted on Azure. The following sections explore potential causes for these failures and provide solutions to restore connectivity.

Cause 1: VMs are configured to use an internal load balancer

An Azure internal load balancer is designed to distribute incoming network traffic among resources within a virtual network. By default, it does not provide outbound internet connectivity for the VMs behind it. If your VMs rely solely on an internal load balancer for their network configuration, they will not be able to initiate connections to external resources like the Ubuntu repositories.

Solution 1a: Add a public IP address

Attaching a public IP address directly to the network interface of the VM provides it with direct outbound internet access. This allows the VM to bypass the internal load balancer’s limitation for outbound connections and reach the Ubuntu repositories. This approach grants granular control over outbound access for individual VMs.

Solution 1b: Use an external load balancer

Using an external Azure load balancer instead of an internal one can provide outbound connectivity. An external load balancer has a public IP address and can be configured with outbound rules to allow VMs in the backend pool to connect to the internet. This is suitable if you need load balancing for inbound traffic and outbound access for the same set of VMs.

Solution 1c: Use a NAT gateway on the subnet

Azure NAT Gateway is a highly scalable and resilient service that provides outbound internet connectivity for resources in a subnet. By configuring a NAT gateway on the VM’s subnet, all outbound traffic from VMs in that subnet is routed through the NAT gateway’s public IP address(es). This is a recommended approach for providing secure and scalable outbound access for multiple VMs.

Solution 1d: Use an internal basic load balancer

Downgrading from a standard internal load balancer to a basic internal load balancer can provide outbound connectivity by default through implicit SNAT.

Note: This solution is considered temporary. The basic version of the load balancer is scheduled for retirement on 30 September 2025. It is strongly recommended to upgrade to a standard load balancer or use a NAT Gateway for future-proof configurations.

Solution 1e: Use SNAT rules

With a standard load balancer (internal or external), outbound connectivity can be explicitly configured using Source Network Address Translation (SNAT) rules or outbound rules. Configuring explicit SNAT rules or outbound rules on the load balancer allows VMs in the backend pool to initiate connections to the internet. This provides more control over how outbound connections are established and managed.

Cause 2: External load balancer doesn’t have outbound rules and disables outbound SNAT

While an external load balancer has a public IP and can provide outbound connectivity, it requires proper configuration, especially when using the Standard SKU. If outbound rules are not configured, or if outbound SNAT is explicitly disabled without an alternative like NAT Gateway, the VMs behind the load balancer will lack internet access. The external load balancer needs defined rules to know how to translate private IP addresses of VMs to its public IP for outbound traffic.

Solution 2: Configure outbound rule or verify that outbound SNAT is enabled

To enable outbound connectivity for VMs behind an external load balancer, you must either:

  • Set up an explicit outbound rule: Configure a rule on the load balancer that defines how outbound traffic from the backend pool is handled, typically allowing connections to the internet on required ports (like 80 and 443).
  • Ensure outbound SNAT is enabled: If using a Basic SKU, ensure that implicit SNAT is not disabled. If using a Standard SKU without explicit outbound rules, verify that a NAT Gateway is associated with the subnet for outbound traffic, as Standard load balancers have no default implicit outbound connectivity.

Refer to Azure documentation on Configuring outbound rules and Using SNAT for outbound connections for detailed guidance.

Cause 3: An Azure firewall or virtual appliance is between your virtual network and the internet

Deploying an Azure Firewall or a third-party virtual network appliance (like an NGFW) in your virtual network acts as a central point for inspecting and controlling network traffic. When configured to route all internet-bound traffic through it, the firewall/appliance enforces security policies. If these policies are too restrictive, they can block communication to specific external endpoints, including the Ubuntu package repositories.

Solution 3: Make sure that the Ubuntu address is allowed

To resolve this, ensure that the necessary URLs and IP addresses for the Ubuntu repositories are explicitly permitted by your firewall or virtual appliance policies. Specifically, azure.archive.ubuntu.com, security.ubuntu.com, and potentially other mirror URLs or third-party repository addresses must be allowed.

Take the following steps:
1. Firewall Policy Verification: Review your Azure Firewall or virtual appliance rules. Confirm that outbound connections to the domain names (*.ubuntu.com, packages.microsoft.com if applicable, etc.) and their corresponding IP addresses on ports 80 (HTTP) and 443 (HTTPS) are allowed.
2. SSL Inspection: If SSL/TLS inspection is active on your firewall, ensure that the inspection process does not interfere with the connection to the repository URLs or that these specific endpoints are bypassed if necessary.
3. Network Security Group (NSG) Rules: If NSGs are applied to the VM’s network interface or subnet, verify that outbound rules permit traffic to the required Ubuntu repository IP addresses and ports 80/443. These custom allow rules should be prioritized higher than any default Deny rules or broad Block_Internet_Access_outbound rules. Utilize Azure Network Watcher’s IP flow verify or Connection troubleshoot features to diagnose traffic flow and check effective security rules.

Properly configuring your firewall or virtual appliance is crucial for balancing security requirements with the need for VMs to access external resources like software repositories.

Cause 4: VM is connected to a private subnet

A private subnet in Azure Virtual Network is configured without a default route to the internet. This configuration enhances security by ensuring that resources within the subnet cannot directly initiate outbound connections to the public internet unless explicitly provided with a mechanism to do so. Therefore, a VM placed in a private subnet will, by default, fail to reach external package repositories.

Solution 4: Provide outbound connectivity for the subnet

To enable outbound internet access for VMs residing in a private subnet, you must explicitly configure an outbound path. The recommended and most scalable approach is to use an Azure NAT Gateway. By associating a NAT gateway with the private subnet, all VMs within that subnet automatically gain outbound internet connectivity through the public IP address(es) assigned to the NAT gateway.

Alternatively, you could route traffic through a firewall/NVA or use a public load balancer, but NAT Gateway is generally the simplest and most cost-effective solution specifically for providing outbound access from private subnets. Consult the Azure NAT Gateway overview for more details.

Cause 5: A proxy is used for communication

In some enterprise environments or specific network configurations within Azure, internet communication is routed through a customer-managed proxy server. If this proxy server is misconfigured, unreachable, or blocks traffic to the Ubuntu repositories, it will prevent the apt command from fetching necessary package information. The apt tool respects proxy settings configured on the system.

Solution 5: Fix the proxy configuration settings

If your network environment requires traffic to pass through a proxy server, ensure that the proxy settings on the Ubuntu VM are correctly configured. The primary location for APT’s proxy settings is the /etc/apt/apt.conf file.

You can set HTTP and HTTPS proxy settings using lines like these:

Acquire::http::Proxy "http://[username]:[password]@[proxy-web-or-IP-address]:[port-number]";
Acquire::https::Proxy "http://[username]:[password]@[proxy-web-or-IP-address]:[port-number]";

Replace the bracketed placeholders with your actual proxy details. Ensure the proxy server is accessible from the VM (especially if it’s within your Azure VNet). If the proxy has a private IP, verify connectivity within your network.

Additionally, proxy settings can be set via environment variables (http_proxy, https_proxy, ftp_proxy, no_proxy). These variables might override settings in apt.conf depending on the context. You can check for environment proxy settings using:

env | grep -i proxy

Important: If no proxy server is intended to be used for direct internet access to the Ubuntu repositories, meticulously check /etc/apt/apt.conf and any environment variables for incorrect proxy configurations and remove them.

Correct proxy configuration is vital for successful communication with external package repositories when a proxy is in place.

Scenario 2: A firewall or an NSG blocks the required URLs (Status Code 470)

Scenario 2 Details

When attempting to run apt update, the command fails with error messages indicating a “status code 470”. This status code is not a standard HTTP code and often signifies a rejection or blockage by an intermediate network device, such as a firewall or proxy, rather than a server-side error or simple timeout. The errors show failures fetching data from various sources, potentially including azure.archive.ubuntu.com, packages.microsoft.com, and security.ubuntu.com.

Example output:

Err: 3 http://azure.archive.ubuntu.com/ubuntu focal-updates InRelease
  470  status code 470[IP: 23.101.248.31 80]
Err: 4 http://azure.archive.ubuntu.com/ubuntu focal-backports InRelease
  470  status code 470[IP: 23.101.248.31 80]
Ign:5 https://packages.microsoft.com/ubuntu/20.04/prod focal InRelease
Err:6 https://packages.microsoft.com/ubuntu/20.04/prod focal Release
  Could not handshake: The TLS connection was not properly terminated. [IP: 52.230.121.169  443]
Reading package lists...

[stderr]
E: The repository 'http://security.ubuntu.com/ubuntu focal-security InRelease' is no longer signed.
E: Failed to fetch http://security.ubuntu.com/ubuntu/dists/focal-security/InRelease 470 status code 470 [IP: 91.189.91.82 80]
E: The repository 'http://security.ubuntu.com/ubuntu focal InRelease' is no longer signed.
E: Failed to fetch http://security.ubuntu.com/ubuntu/dists/focal/InRelease 470 status code 470 [IP: 23.101.248.31 80

The “status code 470” strongly suggests that a security appliance or rule between the VM and the internet is actively blocking the connection. The TLS handshake error on the Microsoft repository also points to potential interference, possibly from SSL inspection or blockage on port 443.

Cause: A firewall or an NSG blocks the required URLs

The most likely cause for status code 470 errors is an intermediate network device—like an Azure Firewall, a Network Virtual Appliance, or even restrictive Network Security Group (NSG) rules—explicitly blocking or rejecting the connection attempts to the specified repository URLs. Unlike a timeout (Scenario 1), which implies a failure to establish a connection, a 470 error suggests the connection was reached but denied based on a policy.

An NSG applied to the VM’s network interface or the subnet could also be blocking outbound traffic on ports 80 (HTTP) or 443 (HTTPS) to the repository IP addresses. Default NSG rules often permit outbound internet access, but custom rules can override this.

Solution: Allow required URLs on your firewall configuration

To resolve status code 470 errors, you must identify the network security control point (firewall, NVA, or NSG) that is intercepting the traffic and configure it to explicitly allow access to the required repository URLs and IPs on the necessary ports.

  • Firewall/NVA Configuration: If using Azure Firewall or an NVA, review their logs and policies. Create or modify rules to permit outbound traffic from your VM’s IP address or subnet to the domain names (*.ubuntu.com, *.microsoft.com, etc.) or specific IP addresses of the Ubuntu and Microsoft repositories on TCP ports 80 and 443. If TLS inspection is enabled, ensure these domains are whitelisted or handled correctly.
  • NSG Configuration: If NSGs are in place, examine the effective security rules for the VM’s network interface and subnet. Add or adjust outbound security rules to allow traffic to the relevant IP addresses or Service Tags (if available for Azure/Ubuntu mirrors) on ports 80 and 443. Remember that NSG rules are processed in priority order, so ensure your allow rules have a higher priority (lower number) than any potentially conflicting deny rules. Use Network Watcher tools to diagnose effective rules.

Ensuring that your security devices and NSGs are configured to allow access to necessary external package repositories is critical for the proper functioning of apt update and package installations.

Scenario 3: An error occurred during the signature verification

Scenario 3 Details

When running apt update, the process fetches package information from various sources. While some repositories (like the official Ubuntu ones) might update successfully, others, particularly third-party repositories, report signature verification errors. The error message typically includes “The following signatures couldn’t be verified because the public key is not available” and provides a key ID (e.g., NO_PUBKEY 4D64390375060AA4).

Example console output:

sudo apt update
Hit:1 http://azure.archive.ubuntu.com/ubuntu jammy InRelease
Hit:2 http://azure.archive.ubuntu.com/ubuntu jammy-updates InRelease
Hit:3 http://azure.archive.ubuntu.com/ubuntu jammy-backports InRelease
Hit:4 http://azure.archive.ubuntu.com/ubuntu jammy-security InRelease
Get:5 http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/unstable/xUbuntu_22.04  InRelease [1262 B]
Err:5 http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/unstable/xUbuntu_22.04  InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4D64390375060AA4
Fetched 1262 B in 1s (1142 B/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
16 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/unstable/xUbuntu_22.04  InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4D64390375060AA4
W: Failed to fetch http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/unstable/xUbuntu_22.04/InRelease  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4D64390375060AA4
W: Some index files failed to download. They have been ignored, or old ones used instead.
root@ubu24vmlbe:/etc/apt#

This error indicates that apt successfully connected to the repository and downloaded the release file, but it could not verify the digital signature of that file. APT uses GPG signatures to ensure that the package lists and packages you download are authentic and haven’t been tampered with since they were signed by the repository maintainer.

Cause: GPG key is missing for third-party repositories

When you add a new third-party repository to your system by adding a line to /etc/apt/sources.list or placing a file in /etc/apt/sources.list.d/, apt needs a corresponding GPG public key to verify the integrity and authenticity of the packages downloaded from that source. If this key is missing from your system’s trusted key store, apt cannot verify the signatures, leading to the NO_PUBKEY error and refusing to use the repository.

Solution: Add the GPG key for the third-party repositories

To resolve signature verification errors for third-party repositories, you must import the missing GPG public key into your system’s APT trusted key store. The key ID mentioned in the error message (4D64390375060AA4 in the example) helps identify which key is needed. Repository providers usually provide instructions on how to obtain and add their GPG key.

A common method is to download the key (often available via HTTP/HTTPS) and add it to the /etc/apt/trusted.gpg.d/ directory. This directory is the preferred location for storing keys for individual repositories.

Here’s an example command using curl to download the key and tee to save it to a file in the trusted directory (using the example URL and key filename from the scenario):

sudo curl -fsSL https://download.opensuse.org/repositories/devel:kubic:libcontainers:unstable/xUbuntu_22.04/Release.key | sudo tee /etc/apt/trusted.gpg.d/devel_kubic_libcontainers_unstable.gpg > /dev/null

This command fetches the key securely (-fsSL) and pipes it through tee to write it to the specified file, requiring sudo because the destination directory is system-protected. The > /dev/null suppresses tee’s standard output.

Alternatively, using gpg --dearmor is a more modern and recommended way to process downloaded keys before placing them in trusted.gpg.d/, as apt-key is deprecated.

curl -fsSL https://download.opensuse.org/repositories/devel:kubic:libcontainers:unstable/xUbuntu_22.04/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/devel_kubic_libcontainers_unstable.gpg > /dev/null

This version uses gpg --dearmor to convert the key into the correct binary format before saving it.

Important: Always obtain GPG keys from the official source of the third-party repository. Using keys from untrusted sources is a security risk. Verify the source’s documentation for the correct procedure and URL for their GPG key.

After successfully adding the key, run sudo apt update again. The signature verification error for that repository should now be resolved.

Note: If you cannot find the correct GPG key or are unsure about the source’s trustworthiness, it is safer to remove the entry for that third-party repository from /etc/apt/sources.list or /etc/apt/sources.list.d/. This prevents the error and ensures apt update works correctly for your other repositories, while mitigating security risks from untrusted sources.

Scenario 4: A "Temporary failure resolving ‘azure.archive.ubuntu.com’" error message occurs

Scenario 4 Details

When executing the apt update command, the system fails to resolve the hostname azure.archive.ubuntu.com, resulting in “Temporary failure resolving” errors for multiple repository entries pointing to this domain.

Example output:

Ign:4 http://azure.archive.ubuntu.com/ubuntu jammy-security InRelease
Err:1 http://azure.archive.ubuntu.com/ubuntu jammy InRelease
  Temporary failure resolving 'azure.archive.ubuntu.com'
Err:2 http://azure.archive.ubuntu.com/ubuntu jammy-updates InRelease
  Temporary failure resolving 'azure.archive.ubuntu.com'
Err:3 http://azure.archive.ubuntu.com/ubuntu jammy-backports InRelease
  Temporary failure resolving 'azure.archive.ubuntu.com'
Err:4 http://azure.archive.ubuntu.com/ubuntu jammy-security InRelease
  Temporary failure resolving 'azure.archive.ubuntu.com'
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
16 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/dists/jammy/InRelease  Temporary failure resolving 'azure.archive.ubuntu.com'
W: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/dists/jammy-updates/InRelease  Temporary failure resolving 'azure.archive.ubuntu.com'
W: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/dists/jammy-backports/InRelease  Temporary failure resolving 'azure.archive.ubuntu.com'
W: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/dists/jammy-backports/InRelease  Temporary failure resolving 'azure.archive.ubuntu.com'
W: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/dists/jammy-security/InRelease  Temporary failure resolving 'azure.archive.ubuntu.com'
W: Some index files failed to download. They have been ignored, or old ones used instead.

This error explicitly states that the VM’s DNS resolver is unable to translate the hostname azure.archive.ubuntu.com into an IP address. DNS resolution is a prerequisite for any network connection; if it fails, the system doesn’t know where to send the request to fetch package data.

Cause: Custom DNS can’t resolve Ubuntu repositories

The most common reason for a “Temporary failure resolving” error is an issue with the Domain Name System (DNS) configuration or the reachability of the configured DNS server. If your Azure VM is configured to use a custom DNS server (either one hosted in Azure, on-premises, or a third-party public DNS service) instead of Azure’s default DNS, and that custom server is unable to resolve public internet hostnames like azure.archive.ubuntu.com, DNS resolution will fail.

Potential issues with custom DNS include:
* The DNS server itself is down or misconfigured.
* Network connectivity problems prevent the VM from reaching the DNS server (e.g., firewall rules blocking port 53 UDP/TCP, routing issues).
* If the DNS server is another VM in a different subnet, there might be missing or incorrect User-Defined Routes (UDRs) preventing communication between the subnets.

Solution: Verify and fix DNS configuration

  1. Check DNS Configuration: Identify which DNS servers your VM is configured to use. This is typically set at the network interface level in the Azure portal or via DNS settings on the VM itself (e.g., /etc/resolv.conf, though Azure VM’s /etc/resolv.conf is usually managed by cloud-init and points to an internal Azure IP 168.63.129.16 by default unless custom DNS is configured at the VNet/NIC level).
  2. Test Resolution: From the problematic VM, try to resolve the hostname manually using tools like nslookup or dig:
    nslookup azure.archive.ubuntu.com
dig azure.archive.ubuntu.com

    See if these commands successfully return an IP address.
  3. Verify Connectivity to DNS Server: If using a custom DNS server, verify that the VM can reach the DNS server’s IP address on port 53 (UDP and TCP). Use tools like nc or telnet:
    nc -vz <DNS_Server_IP> 53
  4. Check Azure DNS: If you suspect the issue is with your custom DNS, temporarily switch the network interface’s DNS setting back to “Azure DNS” in the Azure portal. After the change applies (requires a brief network restart or VM reboot sometimes), try apt update again. If it works, the problem lies with your custom DNS setup. You can change DNS settings for a virtual network or specific network interface in the Azure portal under “DNS servers”.
  5. Review Network Path: If using a custom DNS server hosted in Azure, especially in a different subnet, check NSGs and UDRs. Ensure there are no NSG rules blocking traffic to the DNS server’s IP on port 53. If UDRs are used, verify that a route exists allowing traffic from the VM’s subnet to the DNS server’s subnet.
  6. Firewall/NVA: If a firewall or NVA handles DNS forwarding or acts as the DNS server, ensure it is configured correctly and allows queries for public hostnames.

Correct DNS resolution is a fundamental requirement for accessing internet resources, including software repositories. Diagnosing and fixing DNS issues is often the first step when facing hostname resolution failures.

Scenario 5: A "dpkg: error processing package" error message appears during a kernel installation

Scenario 5 Details

During the installation or upgrade of a Linux kernel package via apt, the process fails with a dpkg: error processing package message. The detailed output shows that a post-installation script (/etc/kernel/postinst.d/zz-update-grub) associated with the kernel package failed to execute, specifically mentioning a syntax error within the /etc/default/grub file while running grub-mkconfig.

Example output:

Processing triggers for linux-image-5.4.0-1051-azure (5.4.0-1051.53) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.4.0-1051-azure
/etc/kernel/postinst.d/zz-update-grub:
Sourcing file `/etc/default/grub'
/usr/sbin/grub-mkconfig: 34: /etc/default/grub: Syntax error: EOF in backquote substitution
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 2
dpkg: error processing package linux-image-5.4.0-1051-azure (--configure):
 installed linux-image-5.4.0-1051-azure package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 linux-image-5.4.0-1051-azure
E: Sub-process /usr/bin/dpkg returned an error code (1)

This specific error indicates that the dpkg package manager failed to complete the installation of the kernel package because a script that runs after the package files are placed (postinst script) failed. The error message clearly points to a syntax problem in /etc/default/grub during the execution of the update-grub command (which is part of the zz-update-grub script).

Cause: A syntax error exists in /etc/default/grub

The update-grub command (or grub-mkconfig) reads the /etc/default/grub file and other script snippets to generate the final /boot/grub/grub.cfg bootloader configuration file. This file uses a shell-like syntax. If there is a syntax error in /etc/default/grub – such as mismatched quotes, incorrect variable assignments, or improper command substitutions – grub-mkconfig will fail when it tries to parse it. The kernel package installation’s post-installation script depends on this command succeeding to update the boot configuration, hence the dpkg error.

An example of a syntax error:

# cat /etc/default/grub
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'\n
GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX="    # <--- Missing closing quote here

In this example, the line defining GRUB_CMDLINE_LINUX is missing its closing double quotation mark ("), which is a critical syntax error for the shell script parser used by grub-mkconfig.

Solution: Fix the syntax error in /etc/default/grub

To resolve this, you need to edit the /etc/default/grub file and correct the syntax error.

  1. Edit the file: Open /etc/default/grub using a text editor with root privileges:
    sudo nano /etc/default/grub
# or
sudo vim /etc/default/grub
  2. Identify the error: Carefully examine the file, paying close attention to the line number mentioned in the error output (e.g., line 34 in the example). Look for common shell syntax errors like missing quotes (" or '), unescaped special characters, or incorrect command substitutions (`` or $(...)).
  3. Correct the syntax: Fix the identified error. In the example shown above, you would add the missing closing double quote:
    GRUB_CMDLINE_LINUX=""

    or if you intended to have options:
    GRUB_CMDLINE_LINUX="console=tty1 console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=30"
  4. Save the file: Save the changes and exit the editor.
  5. Test update-grub: Manually run update-grub to ensure the syntax is now correct and the GRUB configuration file can be generated without errors:
    sudo update-grub

    If this command runs successfully without syntax errors, you have fixed the problem.
  6. Retry package installation: Now that the syntax error is resolved, retry configuring the kernel package that failed:
    sudo apt --fix-broken install

    Or retry the original installation/upgrade command. dpkg should now be able to run the post-installation script successfully.

Ensuring the integrity of system configuration files like /etc/default/grub is essential for the correct functioning of system utilities and package installations that interact with them.

Scenario 6: "The repository ‘http://archive.ubuntu.com/ubuntu/dists/focal/main/binary-armhf/Packages focal Release’ does not have a Release file"

Scenario 6 Details

When running apt update, the command checks various configured repositories. For one or more repositories, it fails with an error stating “does not have a Release file” and indicates a 404 Not Found error for the Release file within a specific architecture’s directory (e.g., binary-armhf).

Example output:

Ign:1 http://archive.ubuntu.com/ubuntu/dists/focal/main/binary-armhf/Packages focal InRelease
Hit:2 http://azure.archive.ubuntu.com/ubuntu focal InRelease
Hit:3 http://azure.archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:4 http://azure.archive.ubuntu.com/ubuntu focal-backports InRelease
Hit:5 http://azure.archive.ubuntu.com/ubuntu focal-security InRelease
Hit:6 https://packages.microsoft.com/ubuntu/20.04/prod focal InRelease
Err:7 http://archive.ubuntu.com/ubuntu/dists/focal/main/binary-armhf/Packages focal Release
  404  Not Found [IP: 91.189.91.83 80]
Reading package lists... Done
E: The repository 'http://archive.ubuntu.com/ubuntu/dists/focal/main/binary-armhf/Packages focal Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

This error occurs when apt attempts to retrieve the Release file for a specific component and architecture within a repository, but the server returns a 404 Not Found error. The Release file contains metadata about the packages available in that repository section, and its absence prevents apt from processing that repository securely.

Cause: The apt tool points to ARM processor architecture package on an x86_64 virtual machine

The apt system is aware of different processor architectures. By default, a standard Ubuntu installation on an x86_64 (64-bit Intel/AMD) VM is configured to look for amd64 packages. However, APT allows adding support for multiple architectures. If an entry in the sources list (/etc/apt/sources.list or files in /etc/apt/sources.list.d/) specifically references packages for a different architecture that is not available in that specific repository path (like armhf on a path that only hosts amd64), apt will look for the Release file in the non-existent directory path, resulting in a 404 error.

This scenario is common if repository lines intended for a different architecture system were accidentally added, or if a script/application incorrectly modified the sources list to include architectures not offered by the repository mirror for those specific distribution/component combinations.

You can check for lines referencing armhf (or other unintended architectures) in your sources list files:

sudo cat /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null | grep -i armhf

If this command returns lines like:

deb http://archive.ubuntu.com/ubuntu/dists/focal/main/binary-armhf/Packages focal main
deb-src  http://archive.ubuntu.com/ubuntu/dists/focal/main/binary-armhf/Packages focal main

This confirms that your apt configuration is trying to fetch package lists for the armhf architecture from a location where they don’t exist on the archive.ubuntu.com mirror for the focal distribution’s main component.

Solution: Remove or comment out incorrect architecture entries

To fix this, edit the sources list files (/etc/apt/sources.list and files in /etc/apt/sources.list.d/) and remove or comment out the lines that reference architectures (like armhf) that you do not need and that cause the 404 error.

  1. Identify the file(s): Use the grep command from the “Cause” section to see which file(s) contain the problematic lines.
  2. Edit the file(s): Open the identified file(s) using a text editor with root privileges:
    sudo nano /etc/apt/sources.list
# Check files in /etc/apt/sources.list.d/ as well
# sudo nano /etc/apt/sources.list.d/some-file.list
  3. Comment or remove lines: Find the lines referencing the incorrect architecture (e.g., binary-armhf) and either delete them entirely or add a # at the beginning of the line to comment them out.
    For example, change:
    deb http://archive.ubuntu.com/ubuntu/dists/focal/main/binary-armhf/Packages focal main

    to:
    # deb http://archive.ubuntu.com/ubuntu/dists/focal/main/binary-armhf/Packages focal main
  4. Save and close: Save the changes to the file(s) and exit the editor.
  5. Run apt update: Execute sudo apt update again. The error related to the missing Release file for the incorrect architecture should now be gone, and apt should proceed to update the lists for the correctly configured repositories and architectures (like amd64).

Ensuring that your apt sources list correctly reflects the available architectures and components for your system’s architecture is key to avoiding these types of errors during repository updates.

Have you encountered other APT issues on Azure VMs? Share your experiences and solutions in the comments below!

Post a Comment