Tenho cerca de 40 Dell Latitude E6410s que mantenho em minha sala de aula para uso dos alunos. Eu configurei com sucesso e usei contas 'guest' especiais para que os diretórios fossem limpos entre os usos. Este esquema funcionou bem para 14.04 LTS. Eu apenas tentei uma configuração de teste de 16.04 LTS (que em outros ambientes de teste resolve um problema incômodo não relacionado com algum software que gostaríamos de executar).
O problema é que depois da atualização eu não consigo mais entrar na conta "guest". Todas as contas de administrador e usuário padrão funcionam bem, mas o login "convidado" automático entra em loop ( como descrito em outras questões, * login a tela limpa e o sistema inicia a configuração mas falha em de alguma forma eu não posso determinar e retorna para a tela de login ).
O que torna isso diferente é que o diretório 'guest' é criado em tempo real. Arquivos de log locais e de autoridade não são visíveis para mim. Não consigo obter muita informação nem aplicar algumas das correções propostas nos sites referenciados para mais contas permanentes.
Eu alterei o arquivo 50-unity-greeter.conf para permitir logins de convidados removendo quaisquer arquivos que possam impedir logins de convidados.
UPDATE: encontrei a causa do loop, mas não as respostas para as perguntas postas. A fonte do problema no meu caso, que postula outro mais geral, está na a execução nos scripts auto.sh e prefs.sh no diretório / etc / guest-session. Esses scripts devem ser executados antes do login, de modo a fazer configurações de última hora. Eu tenho um de cada um que correu bem em 14.04. A instrução incorreta é um comando usermod:
usermod -a -G dialout $USER
que uso para permitir que os convidados usem dispositivos conectados à porta USB. Este comando funcionou bem no estágio auto.sh do script em 14.04.
Em 16.04, se eu colocar este comando em prefs.sh (onde parece que deve pertencer), recebo o problema do loop infinito. Se eu colocá-lo no auto.sh, o script é executado normalmente, mas é ineficiente (provavelmente porque ele precisa de privilégios de root para alterar grupos.
Eu encontrei isso por tentativa e erro. Ainda não sei onde a sequência de login está sendo registrada. Eu tentei verificar / var / log / lightdm / logs e os outros problemas menores revelados, mas nada sobre o modo de falha desses scripts.