Toolbox: Los contenedores no se inician cuando / etc / localtime es un enlace simbólico absoluto en el host (por ejemplo, Arch y Ubuntu)

Creado en 9 nov. 2020  ·  10Comentarios  ·  Fuente: containers/toolbox

Describe el error
Después de actualizar a la versión 0.0.97 de la caja de herramientas, ya no puedo iniciar ninguna caja de herramientas.

Salida de 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

El resultado es el mismo para los contenedores creados antes y después de la actualización. Las cajas de herramientas se pueden iniciar después de degradar a 0.0.96 y se pueden ingresar en 0.0.97 una vez que se hayan iniciado.

Pasos de cómo reproducir el comportamiento.

  1. Iniciar caja de herramientas

Comportamiento esperado
Se inicia la caja de herramientas

Comportamiento real
Se genera un error Error: invalid entry point PID of container work y la caja de herramientas no se inicia.

Salida de toolbox --version (v0.0.90 +)
toolbox version 0.0.97

Información del paquete de la caja de herramientas ( rpm -q toolbox )
toolbox-0.0.97-1-x86_64 (arch)

Salida de 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

Información del paquete Podman ( rpm -q podman )
podman-2.1.1-1-x86_64 (arch)

Información sobre su sistema operativo
Archlinux

1. Bug

Comentario más útil

Tengo exactamente el mismo problema (también en Arch Linux). Bajar la calificación a 0.0.96 funcionó para mí.

Estos son los registros de Podman para una caja de herramientas de Fedora 32:

$ 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

Todos 10 comentarios

Tengo exactamente el mismo problema (también en Arch Linux). Bajar la calificación a 0.0.96 funcionó para mí.

Estos son los registros de Podman para una caja de herramientas de Fedora 32:

$ 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

Veo lo mismo

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

¿Podría ser causado por 4c9b80aee2b2ee3162b82e309718a23792d0e103?

Me encuentro con el mismo problema en Manjaro (basado en arco). Al revisar las confirmaciones, encontré que b9a0bd5f0c2a2421ec15eea286ca20f03b7152d2 era el culpable. 4c9b80aee2b2ee3162b82e309718a23792d0e103 parece ser el último que funciona correctamente.

¿Alguien ha probado 0.0.98.1 en Arch Linux?

Por curiosidad, sus sistemas de host Arch no tienen un /etc/localtime ?

Sí, los hosts de Arch tienen / etc / localtime. Es un enlace simbólico a / usr / share / zoneinfo /.
El problema es que la caja de herramientas tiene:

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

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

Si cambio zoneInfoRoot a "/usr/share/zoneinfo" , la caja de herramientas funciona bien.

Antes de llamar a updateTimeZoneFromLocalTime() , el enlace / etc / localtime se actualiza para apuntar a la misma ruta a la que apunta / run / host / etc / localtime.
No veo cómo eso debería hacer que / etc / localtime apunte a / run / host, ya que los archivos de host no saben nada sobre la caja de herramientas.

Entonces, a menos que me pierda algo, tal vez incluso obvio para cualquier otra persona, zoneInfoRoot simplemente debería cambiarse / arreglarse. Si hay ambos casos de uso para que / etc / localtime apunte a / run / host / usr / share / zoneinfo / ... y / usr / share / zoneinfo / ... supongo que podemos verificar ambas posibilidades, y resuelve timeZone según el prefijo coincidente.

Sí, los hosts de Arch tienen / etc / localtime. Es un enlace simbólico a
/ usr / share / zoneinfo /.

Ok, entonces no es como la situación en Fedora CoreOS.

Esto debe ser abordado por https://github.com/containers/toolbox/pull/634

Sin embargo, debo mencionar que tanto Arch como Ubuntu deberían usar enlaces simbólicos relativos. Si lo hicieran, esto seguiría funcionando, porque los enlaces simbólicos relativos pueden manejar situaciones similares a chroot, que es mejor. por ejemplo, en Fedora Workstation tenemos:

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

Considerando que, en Ubuntu 18.04, veo:

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

Pero, si uso timedatectl entonces se arregla :

$ 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

Sí, cambiar el enlace simbólico / etc / localtime a un valor absoluto es una solución alternativa. Usaré esto por ahora, gracias.

Pero creo que el # 634 debería fusionarse. No veo mucho sentido en no admitir enlaces simbólicos tan absolutos.

Clausura. Siéntase para volver a abrir o dejar un comentario si cree que esto aún no se ha solucionado.

Y gracias por probar Toolbox.

¿Fue útil esta página
0 / 5 - 0 calificaciones