Unable to update Ubuntu container

I have installed lxd using snap on an Ubuntu 14.04 LTS host with extended support. After installing a container like Ubuntu 18.04 LTS, I am unable to update sources or packages on the device even though I can ping and resolve internet sites.

Output from lxc exec climbing-hamster – /bin/bash -c ‘apt update -y’:

Err:5 Index of /ubuntu bionic Release
404 [IP: 185.125.190.39 80]
Err:6 Index of /ubuntu bionic-updates Release
404 [IP: 185.125.190.39 80]
Reading package lists… Done
E: The repository ‘Index of /ubuntu bionic-security Release’ no longer has a Release file.

I had to truncate the output due to new users not being able to post too many web addresses (silly IMO).

lxc network list shows:

±-------±---------±--------±----------------±-----±------------------±--------±--------+
| NAME | TYPE | MANAGED | IPV4 | IPV6 | DESCRIPTION | USED BY | STATE |
±-------±---------±--------±----------------±-----±------------------±--------±--------+
| eth0 | physical | NO | | | | 0 | |
±-------±---------±--------±----------------±-----±------------------±--------±--------+
| eth1 | physical | NO | | | | 0 | |
±-------±---------±--------±----------------±-----±------------------±--------±--------+
| eth2 | physical | NO | | | | 0 | |
±-------±---------±--------±----------------±-----±------------------±--------±--------+
| eth3 | physical | NO | | | | 0 | |
±-------±---------±--------±----------------±-----±------------------±--------±--------+
| eth4 | physical | NO | | | | 0 | |
±-------±---------±--------±----------------±-----±------------------±--------±--------+
| eth5 | physical | NO | | | | 0 | |
±-------±---------±--------±----------------±-----±------------------±--------±--------+
| lxdbr0 | bridge | YES | 10.160.188.1/24 | none | Edited by Michael | 2 | CREATED |
±-------±---------±--------±----------------±-----±------------------±--------±--------+

lxc network show lxdbr0
config:
ipv4.address: 10.160.188.1/24
ipv4.firewall: “false”
ipv4.nat: “true”
ipv6.address: none
ipv6.firewall: “false”
description: Edited by Michael
name: lxdbr0
type: bridge
used_by:

  • /1.0/instances/climbing-hamster

  • /1.0/profiles/default
    managed: true
    status: Created
    locations:

  • none

I can run apt-get update and upgrade from the Ubuntu 14.04 LTS host just fine.

I had similar results when trying a Ubuntu 20.04 container. I turned off IPv6 in the lxc network configuration without success. Does anyone have suggestions on what to try next? I have a separate test server on a different network also configured with Ubuntu 14.04 LTS and did not encounter any problems like this. Thank you.

Michael

Ubuntu 18.04 LTS is past the end of standard support since 31 May 2023. To receive updates today, you need to enable the extended support.

The container needs to have ESM enabled. It is not enough if the host system has extended support, as the container has its own filesystem and won’t know about the host setup.

David,

I appreciate the reply. To clarify, I have a test server setup that is running on one network and a production server is being used by my client on a different network (networks are unrelated and geographically isolated). I am able to update the 18.04 container on a 14.04 host on my test system just fine, but not on the production system. I may need to perform a tcpdump of the bridge interface on two systems and compare to find a difference.

Michael

Everyone,

I tried setting up a 22.04 instance on the same host and receive exactly the same errors. So, the host is interfering with the containers in some way (I think). On an apt-get update, I will get 404 errors even though I can take the same HTTP request message on resolve it just fine from another system. Attempts to reference an https address will result in connection refused error messages (for example, using the pro status command or when apt-get update reaches out to motd.ubuntu.com). It is not a DNS issue as all tcpdump files show DNS resolving addresses just fine and it doesn’t seem like a routing issue. I even tried flushing the iptables without it changing anything.

If anyone has any thoughts on what else to try, I’m all ears. Thanks.