Toolbox: Os contêineres não iniciam quando / etc / localtime é um link simbólico absoluto no host (por exemplo, Arch e Ubuntu)

Criado em 9 nov. 2020  ·  10Comentários  ·  Fonte: containers/toolbox

Descreva o bug
Depois de atualizar para a versão 0.0.97 da caixa de ferramentas, não consigo mais iniciar nenhuma caixa de ferramentas.

Resultado 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

A saída é a mesma para contêineres criados antes e depois da atualização. As caixas de ferramentas podem ser iniciadas após o downgrade para 0.0.96 e podem ser inseridas em 0.0.97 assim que forem iniciadas.

Passos para reproduzir o comportamento

  1. Iniciar caixa de ferramentas

Comportamento esperado
Caixa de ferramentas iniciada

Comportamento real
Um erro é lançado Error: invalid entry point PID of container work e a caixa de ferramentas não é iniciada.

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

Informações do pacote da caixa de ferramentas ( rpm -q toolbox )
toolbox-0.0.97-1-x86_64 (arch)

Resultado 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

Informações do pacote Podman ( rpm -q podman )
podman-2.1.1-1-x86_64 (arch)

Informações sobre o seu sistema operacional
Archlinux

1. Bug

Comentários muito úteis

Estou tendo exatamente o mesmo problema (no Arch Linux também). O downgrade para 0.0.96 funcionou para mim.

Estes são os registros do Podman para uma caixa de ferramentas do 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 comentários

Estou tendo exatamente o mesmo problema (no Arch Linux também). O downgrade para 0.0.96 funcionou para mim.

Estes são os registros do Podman para uma caixa de ferramentas do 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

Eu vejo o mesmo

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

Isso poderia ser causado por 4c9b80aee2b2ee3162b82e309718a23792d0e103?

Estou tendo o mesmo problema em Manjaro (baseado em arco). Passando por commits, descobri que b9a0bd5f0c2a2421ec15eea286ca20f03b7152d2 é o culpado. 4c9b80aee2b2ee3162b82e309718a23792d0e103 parece ser o último a funcionar corretamente.

Alguém tentou 0.0.98.1 no Arch Linux?

Por curiosidade, seus sistemas host Arch não possuem um /etc/localtime ?

Sim, os hosts Arch têm / etc / localtime. É um link simbólico para / usr / share / zoneinfo /.
O problema é que a caixa de ferramentas tem:

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

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

Se eu mudar zoneInfoRoot para "/usr/share/zoneinfo" , a caixa de ferramentas funcionará bem.

Antes de chamar updateTimeZoneFromLocalTime() , o link / etc / localtime é atualizado para apontar para o mesmo caminho que / run / host / etc / localtime aponta.
Não consigo ver como isso deve fazer / etc / localtime apontar para / run / host, já que os arquivos host não sabem nada sobre a caixa de ferramentas.

Portanto, a menos que eu perca algo, talvez até óbvio para qualquer outra pessoa, zoneInfoRoot deve simplesmente ser alterado / consertado. Se houver ambos os casos de uso para / etc / localtime para apontar para / run / host / usr / share / zoneinfo / ... e / usr / share / zoneinfo / ... Acho que podemos verificar as duas possibilidades, e resolva timeZone base no prefixo correspondente.

Sim, os hosts Arch têm / etc / localtime. É um link simbólico para
/ usr / share / zoneinfo /.

Ok, então não é como a situação no Fedora CoreOS.

Isso deve ser resolvido por https://github.com/containers/toolbox/pull/634

No entanto, devo mencionar que tanto o Arch quanto o Ubuntu devem usar links simbólicos relativos. Se o fizessem, isso continuaria a funcionar, porque os links simbólicos relativos são capazes de lidar com situações do tipo chroot, o que é melhor. por exemplo, na estação de trabalho Fedora temos:

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

Considerando que, no Ubuntu 18.04, vejo:

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

Mas, se eu usar timedatectl , ele será corrigido :

$ 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

Sim, alterar o link simbólico / etc / localtime para absoluto é uma solução alternativa utilizável. Vou usar isso por agora, obrigado.

Mas acho que # 634 deve ser mesclado. Não vejo muito sentido em não apoiar tais links simbólicos absolutos.

Fechando. Sinta-se a reabrir ou deixar um comentário se você acha que isso ainda não foi corrigido.

E obrigado por testar o Toolbox.

Esta página foi útil?
0 / 5 - 0 avaliações