LXC "apt update" Probleme unter 9.0.6

antonio66

New Member
Sep 3, 2025
5
0
1
Hallo,

habe nun endlich auf 9.0.6 umgestellt und die "alten" LXContainer via backup/restore (meistens bookworm basiert) umgezogen. Funktionieren soweit fast alle. Ausser Kleinigkeiten, die wohl eher andere Ursachen haben.

ABER, beim Versuch neue Container (bookworm) zu installieren, findet danach "apt update" kein Zugang zu den deb-Sourcen/Server, obwohl ein ping funktioniert.
root@wiki:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0@if32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether bc:24:11:1e:36:1b brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.178.33/24 brd 192.168.178.255 scope global eth0
valid_lft forever preferred_lft forever
root@wiki:~# apt update
Ign:1 http://ftp.de.debian.org/debian bookworm InRelease
Ign:2 http://ftp.de.debian.org/debian bookworm-updates InRelease
Ign:1 http://ftp.de.debian.org/debian bookworm InRelease
Ign:2 http://ftp.de.debian.org/debian bookworm-updates InRelease
Ign:1 http://ftp.de.debian.org/debian bookworm InRelease
Ign:2 http://ftp.de.debian.org/debian bookworm-updates InRelease
Err:1 http://ftp.de.debian.org/debian bookworm InRelease
Could not connect to ftp.de.debian.org:80 (141.76.2.4), connection timed out
Err:2 http://ftp.de.debian.org/debian bookworm-updates InRelease
Unable to connect to ftp.de.debian.org:http:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
W: Failed to fetch http://ftp.de.debian.org/debian/dists/bookworm/InRelease Could not connect to ftp.de.debian.org:80 (141.76.2.4), connection timed out
W: Failed to fetch http://ftp.de.debian.org/debian/dists/bookworm-updates/InRelease Unable to connect to ftp.de.debian.org:http:
W: Some index files failed to download. They have been ignored, or old ones used instead.

Alle anderen Alt-Container haben damit überhaupt kein Problem, nur Neuinstallationen unter proxmox 9.0.6.

Proxmox ist auf einen mini Fujitsu (a la heise-ct-Vorschlag) eingerichtet und läuft hinter einer Fritzbox und stellt quasi einige private html-Seiten zur Verfügung. Die vmbr0 ist als linux-bridge aufgesetzt und besitzt eine statische IP. Für pfsense ist noch eine zweite Netzwerkkarte vorhanden, spielt aber hier eigentlich keine Rolle.
root@pve:~# pct config 107
arch: amd64
cores: 1
description:
features: keyctl=1,nesting=1
hostname: wiki
memory: 512
net0: name=eth0,bridge=vmbr0,gw=192.168.178.200,hwaddr=BC:24:11:1E:36:1B,ip=192.168.178.33/24,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-107-disk-0,size=4G
swap: 512
tags: community-scrips
unprivileged: 1

Hat jemand eine Idee?
gruss
 
Hm, in dem Zusammenhang funktioniert vermutlich ein API-Aufruf nach "Aussen" nicht, allerdings in einem anderen LXContainer... vielleicht doch proxmox (9.0.6) selber als Ursache? Die Installation war aber gleich aus einer ISO heraus samt dem Starter-Script aus der VE-Community...
 
einen mini Fujitsu (a la heise-ct-Vorschlag)
Auf welchen Artikel beziehst Du dich?


ISO heraus samt dem Starter-Script aus der VE-Community..
Das könnte das Problem liegen.
Mit den Scripten gibt es oft Probleme.
Welche LXC Container ist es?
 
Last edited:
  • Like
Reactions: Johannes S
Auf welchen Artikel beziehst Du dich?



Das könnte das Problem liegen.
Mit den Scripten gibt es oft Probleme.
Welche LXC Container ist es?
hallo,

alter Artikel, da ging es mehr um den ThinClient und wozu dieser alles taugt: heise

den aktuellen debian 12 - wohl gemerkt: aus der alten Konfig 8.4.12 importiert; allerdings bringt auch eine "manuelle" Installation ohne Script das gleiche Ergebnis...

Nachtrag: in 8.4.12 funktioniert alles wie es soll: mit und ohne die helper-VE-scripte. Aus energie- und leistungsgründe habe ich den kleinen Fujitsu S740 mit dem aktuellsten proxmox aufgesetzt und die meisten Container via backup+restore erfolgreich rübergeschaufelt. Nur jetzt stimmt was nicht mit den "netzwerk" oder Berechtigungen nicht.

U.a. wegen solarkram läuft auf einen anderen Container ein script noah_mqtt das auf eine API einer externen Quelle zugreifen will, auch da ein "timeout"...
 
Last edited:
Hat sich erstmal erledigt, hab jetzt wieder auf 8.4.12 umgesattelt, bis trixie zumindestens für meine verwendete Hardware gereifter zur Verfügung steht...

never change a running system,
oder so...:confused: