Toolbox: Container starten nicht, wenn /etc/localtime ein absoluter symbolischer Link auf dem Host ist (z. B. Arch und Ubuntu)

Erstellt am 9. Nov. 2020  ·  10Kommentare  ·  Quelle: containers/toolbox

Beschreibe den Fehler
Nach dem Upgrade auf Toolbox Version 0.0.97 kann ich keine Toolboxen mehr starten.

Ausgabe von toolbox enter work :

DEBU Running as real user ID 1000                 
DEBU Resolved absolute path to the executable as /usr/bin/toolbox 
DEBU Running on a cgroups v1 host                 
DEBU Checking if /etc/subgid and /etc/subuid have entries for user x 
DEBU TOOLBOX_PATH is /usr/bin/toolbox             
DEBU Toolbox config directory is /home/x/.config/toolbox 
DEBU Current Podman version is 2.1.1              
DEBU Old Podman version is 2.1.1                  
DEBU Migration not needed: Podman version 2.1.1 is unchanged 
DEBU Resolving container and image names          
DEBU Container: 'work'                            
DEBU Image: ''                                    
DEBU Release: ''                                  
DEBU Resolved container and image names           
DEBU Container: 'work'                            
DEBU Image: 'fedora-toolbox:31'                   
DEBU Release: '31'                                
DEBU Checking if container work exists            
DEBU Inspecting mounts of container work          
DEBU Starting container work                      
DEBU Inspecting entry point of container work     
DEBU Entry point PID is a float64                 
DEBU Entry point of container work is toolbox (PID=0) 
Error: invalid entry point PID of container work

Die Ausgabe ist für Container, die vor und nach der Aktualisierung erstellt wurden, gleich. Toolboxen können nach einem Downgrade auf 0.0.96 gestartet und nach dem Start in 0.0.97 eingetragen werden.

Schritte zum Reproduzieren des Verhaltens

  1. Toolbox starten

Erwartetes Verhalten
Toolbox ist gestartet

Tatsächliches Verhalten
Es wird ein Fehler Error: invalid entry point PID of container work ausgegeben und die Toolbox wird nicht gestartet.

Ausgabe von toolbox --version (v0.0.90+)
toolbox version 0.0.97

Toolbox-Paketinformationen ( rpm -q toolbox )
toolbox-0.0.97-1-x86_64 (arch)

Ausgabe von podman version

Version:      2.1.1
API Version:  2.0.0
Go Version:   go1.15.2
Git Commit:   9f6d6ba0b314d86521b66183c9ce48eaa2da1de2
Built:        Sat Sep 26 16:50:37 2020
OS/Arch:      linux/amd64

Podman-Paketinformationen ( rpm -q podman )
podman-2.1.1-1-x86_64 (arch)

Informationen zu Ihrem Betriebssystem
Archlinux

1. Bug

Hilfreichster Kommentar

Ich habe genau das gleiche Problem (auch unter Arch Linux). Ein Downgrade auf 0.0.96 hat mir geholfen.

Dies sind die Podman-Protokolle für eine Fedora 32-Toolbox:

$ podman logs fedora-toolbox-32
level=debug msg="Running as real user ID 0"
level=debug msg="Resolved absolute path to the executable as /usr/bin/toolbox"
level=debug msg="TOOLBOX_PATH is /usr/bin/toolbox"
level=debug msg="XDG_RUNTIME_DIR is unset"
level=debug msg="XDG_RUNTIME_DIR set to /run/user/1000"
level=debug msg="Creating /run/.toolboxenv"
level=debug msg="Monitoring host"
level=debug msg="Path /run/host/etc exists"
level=debug msg="Resolved /etc/localtime to /usr/share/zoneinfo/Europe/Amsterdam"
Error: /etc/localtime points to unknown location

Alle 10 Kommentare

Ich habe genau das gleiche Problem (auch unter Arch Linux). Ein Downgrade auf 0.0.96 hat mir geholfen.

Dies sind die Podman-Protokolle für eine Fedora 32-Toolbox:

$ podman logs fedora-toolbox-32
level=debug msg="Running as real user ID 0"
level=debug msg="Resolved absolute path to the executable as /usr/bin/toolbox"
level=debug msg="TOOLBOX_PATH is /usr/bin/toolbox"
level=debug msg="XDG_RUNTIME_DIR is unset"
level=debug msg="XDG_RUNTIME_DIR set to /run/user/1000"
level=debug msg="Creating /run/.toolboxenv"
level=debug msg="Monitoring host"
level=debug msg="Path /run/host/etc exists"
level=debug msg="Resolved /etc/localtime to /usr/share/zoneinfo/Europe/Amsterdam"
Error: /etc/localtime points to unknown location

ich sehe das gleiche

level=debug msg="Running as real user ID 0"
level=debug msg="Resolved absolute path to the executable as /usr/bin/toolbox"
level=debug msg="TOOLBOX_PATH is /usr/bin/toolbox"
level=debug msg="XDG_RUNTIME_DIR is unset"
level=debug msg="XDG_RUNTIME_DIR set to /run/user/1000"
level=debug msg="Creating /run/.toolboxenv"
level=debug msg="Monitoring host"
level=debug msg="Path /run/host/etc exists"
level=debug msg="Preparing to redirect /etc/localtime to /run/host/etc/localtime"
level=debug msg="/run/host/etc/localtime is a symbolic link"
level=debug msg="Redirecting /etc/localtime to /run/host/etc/localtime"
level=debug msg="Resolved /etc/localtime to /usr/share/zoneinfo/Europe/Copenhagen"
Error: /etc/localtime points to unknown location

Könnte dies durch 4c9b80aee2b2ee3162b82e309718a23792d0e103 verursacht werden?

Ich stoße auf das gleiche Problem auf Manjaro (archbasiert). Als ich Commits durchging, stellte ich fest, dass b9a0bd5f0c2a2421ec15eea286ca20f03b7152d2 der Schuldige ist. 4c9b80aee2b2ee3162b82e309718a23792d0e103 scheint der letzte zu sein, der richtig funktioniert.

Hat jemand 0.0.98.1 unter Arch Linux ausprobiert?

Aus Neugier haben Ihre Arch-Hostsysteme kein /etc/localtime ?

Ja, Arch-Hosts haben /etc/localtime. Es ist ein symbolischer Link zu /usr/share/zoneinfo/.
Das Problem ist, dass die Toolbox Folgendes hat:

        const zoneInfoRoot = "/run/host/usr/share/zoneinfo"

        if !strings.HasPrefix(localTimeEvaled, zoneInfoRoot) {
                return errors.New("/etc/localtime points to unknown location")
        }

Wenn ich zoneInfoRoot in "/usr/share/zoneinfo" ändere, funktioniert die Toolbox gut.

Vor dem Aufrufen von updateTimeZoneFromLocalTime() wird der /etc/localtime-Link so aktualisiert, dass er auf denselben Pfad wie /run/host/etc/localtime zeigt.
Ich kann nicht sehen, wie das /etc/localtime in /run/host zeigen soll, da Hostdateien nichts über Toolbox wissen.

Wenn ich also nichts übersehe, was für andere vielleicht sogar offensichtlich ist, sollte zoneInfoRoot einfach geändert/korrigiert werden. Wenn es beide Anwendungsfälle für /etc/localtime gibt, um auf /run/host/usr/share/zoneinfo/... und /usr/share/zoneinfo/... zu zeigen, können wir beide Möglichkeiten prüfen und lösen timeZone basierend auf dem passenden Präfix auf.

Ja, Arch-Hosts haben /etc/localtime. Es ist ein Symlink in
/usr/share/zoneinfo/.

Ok, es ist also nicht wie die Situation auf Fedora CoreOS.

Dies sollte durch https://github.com/containers/toolbox/pull/634 . behoben werden

Ich muss jedoch erwähnen, dass sowohl Arch als auch Ubuntu relative symbolische Links verwenden sollten. Wenn dies der Fall wäre, würde dies weiterhin funktionieren, da relative Symlinks in der Lage sind, mit chroot-ähnlichen Situationen umzugehen, was besser ist. zB auf der Fedora Workstation haben wir:

$ ls -l /etc/localtime 
lrwxrwxrwx. 1 root root 35 Jan  5 18:20 /etc/localtime -> ../usr/share/zoneinfo/Europe/Prague

Unter Ubuntu 18.04 sehe ich hingegen:

$ ls -l /etc/localtime 
lrwxrwxrwx 1 root root 33 lis 11 16:21 /etc/localtime -> /usr/share/zoneinfo/Europe/Prague

Aber wenn ich timedatectl wird es behoben :

$ timedatectl set-timezone Europe/Prague
$ ls -l /etc/localtime 
lrwxrwxrwx 1 root root 35 led 12 20:29 /etc/localtime -> ../usr/share/zoneinfo/Europe/Prague

Ja, das Ändern des Symlinks /etc/localtime in einen Absolutwert ist eine brauchbare Problemumgehung. Ich werde das jetzt verwenden, danke.

Aber ich denke, #634 sollte zusammengeführt werden. Ich sehe nicht viel Sinn darin, solche absoluten Symlinks nicht zu unterstützen.

Schließen. Fühlen Sie sich, um wieder zu öffnen oder einen Kommentar zu hinterlassen, wenn Sie der Meinung sind, dass dies immer noch nicht behoben ist.

Und vielen Dank für das Testen von Toolbox.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen