Configurando o CentOS 7, ParaView e Oracle VM VirtualBox no Windows 7

0

Estou tentando executar o OpenFOAM 2.3.1 em uma instalação do CentOS 7, executada dentro de uma máquina virtual hospedada pelo Oracle VM VirtualBox em uma máquina com Windows 7. Eu não estou tentando usar qualquer tunelamento remoto, SSH etc, é tudo local. O exercício está se mostrando desastroso.

startx começa a mostrar a interface do gnome, com a janela 'instalar pela primeira vez'. No entanto, na máquina virtual, a GUI ignora todas as entradas e, efetivamente, tudo que posso fazer é eliminar e reiniciar a VM. Nem mesmo o Ctrl + Alt + F2 etc mudará para outros terminais.

Com Paraview ou xhost ou qualquer outra coisa na linha de comando, não importa o que eu exportar a variável DISPLAY , o resultado é:

xhost: unable to open display "localhost:0.0"

ou

xhost: unable to open display

ou o que for que $DISPLAY retorne.

O que eu gostaria de saber é efetivamente quais são as maneiras pelas quais o sistema pode ser quebrado, o que exatamente procurar na pilha de tecnologias como evidência de falhas, onde qualquer configuração é armazenada, e quais coisas podem ser a chave para conseguir isso funcionar.

  • Sistema operacional da máquina: Windows 7 Professional
  • Gerenciador de máquinas virtuais: Oracle VM VirtualBox Manager 5.2.18
  • Sistema operacional virtualizado: CentOS 7 3.10.0-862.14.4.el7.x86_64
  • Versão do OpenFOAM: 2.3.1

Atualização 1:

Acontece que o xterm não foi instalado. Eu executei yum install xterm em uma tentativa de executar xinit . Existe um novo comportamento, uma janela GUI com apenas xterm visível. Mais uma vez, nenhuma entrada está sendo aceita. Agora terei que reiniciar a máquina.

Atualização 2:

Tentando reinstalar o VBoxLinuxAdditions.run, a compilação do kernel revela "ERRO: a configuração do kernel é inválida."

    
por J Collins 16.10.2018 / 15:29

1 resposta

1

O problema de "sem entrada" pode ser tão simples quanto não ter os drivers corretos para o mouse instalado. O VirtualBox lança um pouco de curva de bola aqui, pois pode estar representando o mouse para a VM como um dispositivo de mesa de desenho, para lidar melhor com situações como quando você move o cursor do mouse para fora do lado esquerdo da janela do console da VM, mova-o ao redor da janela e depois de volta no lado direito. Um mouse normal não pode "pular" assim, mas um dispositivo tablet pode. Acho que isso é tratado pelo pacote xorg-x11-drv-evdev RPM.

Se você não tiver o driver do mouse X11 em ordem, o cursor do mouse pode estar preso em seu local padrão. Se você usar xinit , você deve pelo menos colocar o cursor do mouse em uma janela para focá-lo: se você não puder fazer isso, a situação pode parecer que todas as entradas são ignoradas.

O problema de o Control-Alt-F1 não funcionar pode ser tão simples quanto o Windows roubar todos os pressionamentos de tecla que incluem Alt como atalhos de menu, para que seu pressionamento de tecla não atinja o VirtualBox intacto, sem falar na VM. Com uma VM, pode ser mais fácil estabelecer uma rede básica, para que você possa ter uma conexão SSH com sua VM em outra janela ao tentar fazer com que os gráficos do console X11 funcionem.

Na sua outra pergunta, você disse que não há nada nos registros - realmente? O arquivo de log principal no X11 da GUI seria /var/log/Xorg.0.log . Se não houver nada lá, verifique se o seu sistema de arquivos tem algum espaço livre restante. O sistema X11 GUI precisa escrever alguns arquivos minúsculos ao inicializar o servidor X e mais alguns ao iniciar uma sessão do usuário, e se não puder fazer isso, normalmente se comportará muito mal.

Paraview - ou qualquer outro aplicativo X11 GUI para esse assunto - tentará se conectar ao servidor X conforme especificado pela variável DISPLAY . Se houver um nome de host antes do caractere de dois pontos, essa conexão será estabelecida como uma conexão TCP em um número de porta calculado como (número de exibição + 6000). Portanto, se você especificar DISPLAY=localhost:0.0 e não houver nenhum servidor X em escuta na porta TCP local 6000, isso não funcionará.

Os servidores modernos Linux X geralmente não escutam as portas TCP, a menos que você habilite especificamente aquele acesso X11 remoto antigo, terrivelmente inseguro. Você não quer fazer isso.

Em vez disso, quando você especifica DISPLAY=:0.0 sem nenhum nome de host, um soquete UNIX é usado para se comunicar com um servidor X local: especificamente, espera-se que o soquete para exibição 0 esteja em /tmp/.X11-unix/X0 . Isso é inerentemente protegido contra ataques remotos e permite várias extensões de protocolo X11 somente locais que, por sua vez, permitem uma renderização de gráficos muito mais eficiente.

xinit é a ferramenta absoluta de nível mais baixo para iniciar uma sessão real do X11. Como você viu, seus padrões são de tal ordem que inicia uma sessão X11 absoluta com um único buraco para claridade que é boa apenas para diagnósticos e não muito mais. startx é um wrapper em torno de xinit que fornece uma sessão de usuário muito mais significativa por padrão: ele usa o que estiver configurado como o ambiente da área de trabalho da GUI padrão ou o gerenciador de janelas. No CentOS, o padrão é provavelmente o GNOME ... supondo que você o tenha instalado. Você deve ter o gnome-session RPM e suas dependências instaladas.

    
por 18.10.2018 / 23:47