---

@CanalQb no YouTube

---

Penguin automático no ChromeOS Flex: guia passo a passo

---

Leitura: ~22 min  |  Feito com Master Rules Claude v9.3

TL;DR:

• O Penguin aparece como STOPPED porque a VM Termina e o container só sobem quando o ChromeOS os chama; fora do app Terminal, você liga tudo na mão com vmc start termina e lxc start penguin.
• A automação realmente possível é no login (extensão ChromeOS AutoStart ou Terminal como página inicial) somada a ajustes de energia; sobreviver a logout ou desligamento não existe, por desenho do sistema.
• Para manter serviços vivos, configure systemd dentro do Penguin e deixe o notebook ligado, logado, na tomada e com a tampa configurada para não suspender.

Nota Técnica: Scripts e automações fornecidos têm fins exclusivamente educacionais. Teste sempre em ambiente controlado e faça backup antes de alterar a configuração do container. @CanalQb não se responsabiliza por danos, perdas ou bloqueios decorrentes do uso indevido. Transparência: este conteúdo foi produzido com auxílio de inteligência artificial.

O Penguin não morreu: ele só está parado, e a culpa é do ChromeOS.

Quem vê STOPPED na saída do lxc list costuma achar que perdeu o Linux inteiro. No log que originou este guia, a máquina virtual de 4.485.988.352 bytes estava intacta no disco; faltava apenas ligá-la e depois iniciar o container.

Mais adiante você vê como distinguir uma VM ausente de uma VM desligada, por que um comando sugerido na conversa original não resolve sozinho o que promete, e qual é o único gatilho realmente automático que o ChromeOS Flex permite. Se a sua meta é um notebook que liga e já deixa o Linux de pé, o caminho existe, mas tem fronteiras que convém conhecer antes de começar.

Quais são as soluções rápidas para os problemas mais comuns do Penguin parado?

A maioria dos travamentos vem de uma camada desligada, não de perda de dados. Confira o sintoma abaixo, aplique a correção de uma ou duas linhas e, se persistir, siga para o catálogo completo de erros no fim do post, com causa, solução e prevenção.

• Failed to get VM info for termina: a VM está desligada; rode vmc start termina no Crosh antes de usar o vsh. ver passo completo
• unknown command: lxc no Crosh: o lxc só existe dentro da Termina; entre com vmc start termina e rode lá. ver passo completo
• penguin STOPPED: a VM subiu, o container não; use lxc start penguin e confirme com lxc list. ver passo completo
• no such subcommand: status: o vmc não tem esse subcomando; use vmc list. ver passo completo
• Linux sumiu após reiniciar ou sair da conta: as VMs vivem presas à sessão; entre na conta e abra o Terminal. ver passo completo
• Notebook dorme com a tampa fechada: desligue a opção de suspender ao fechar a tampa nas configurações de energia. ver passo completo

O que são Termina, Penguin e Crosh, e por que o Penguin aparece como STOPPED?

O Linux do ChromeOS funciona em duas camadas: a máquina virtual Termina e, dentro dela, o container Penguin gerenciado pelo LXD. STOPPED significa que a VM já está ligada, mas o container ainda não foi iniciado. Não indica perda de dados, e sim estado desligado, que um único comando corrige.

Pense no sistema como uma boneca russa. A camada externa é o próprio ChromeOS, que executa o monitor de máquinas virtuais crosvm. Dentro dele vive a Termina, uma VM mínima mantida pelo Google. Dentro da Termina, um daemon chamado Tremplin conversa com o LXD, e é o LXD que mantém o container Penguin, o Debian com os pacotes de integração que você usa no app Terminal. Cada camada tem seu próprio estado de ligado ou desligado, e a mensagem de erro que você enxerga depende de qual delas está parada. Entender isso evita o reflexo perigoso de apagar tudo e recomeçar.

As quatro camadas do Linux no ChromeOS e como testar cada uma

Camada	O que é	Como você a enxerga	Teste rápido
ChromeOS / Crosh	Sistema anfitrião e seu shell restrito, aberto com Ctrl + Alt + T	Prompt crosh>	vmc list
Termina	VM Linux mínima que hospeda os containers	Prompt (termina) chronos@localhost	vmc start termina
LXD	Gerenciador de containers dentro da Termina	Tabela com NAME e STATE	lxc list
Penguin	Container Debian que o Terminal abre	STATE igual a RUNNING ou STOPPED	lxc start penguin

Agora releia o log real que originou este guia, porque cada linha dele aponta uma camada. O primeiro vsh termina devolveu Failed to get VM info for termina: o Crosh não achou nenhuma VM em execução com esse nome. Em seguida, lxc list no Crosh devolveu unknown command: lxc, simplesmente porque o binário do LXD não existe no Crosh, só dentro da Termina. Então vmc list mostrou termina (4485988352 bytes, raw, sparse), prova de que o disco da VM existia (cerca de 4,2 GiB aparentes; por ser esparso, o uso real pode ser menor). Depois de vmc start termina, o prompt mudou para (termina) chronos@localhost e o lxc list finalmente listou o penguin como STOPPED.

O ponto que mais confunde é este: ver STOPPED logo após vmc start termina é o comportamento esperado, não um defeito. Esse comando liga apenas a VM. Quem costuma iniciar o container é o app Terminal, ou qualquer aplicativo Linux aberto pelo lançador, ou o acesso a Arquivos do Linux no app Arquivos, conforme a documentação do projeto. Como você ligou a VM pelo Crosh, ninguém chamou o container. A regra de diagnóstico que sai daqui é simples: Failed to get VM info mais um vmc list que mostra o disco significa apenas "VM desligada"; só se o vmc list vier vazio é que a VM realmente não existe. Para mais conteúdo do nicho, veja outros guias sobre Crostini aqui no canal.

Meu ChromeOS Flex consegue rodar o Linux do Penguin?

Depende do modelo. A documentação do Google informa que o suporte ao ambiente de desenvolvimento Linux no ChromeOS Flex varia conforme o aparelho. Além disso, o processador precisa ser Intel ou AMD de 64 bits, e a virtualização por hardware precisa estar ativa no BIOS ou UEFI, senão a opção nem aparece nas configurações.

O ChromeOS Flex herda a base do ChromeOS, mas foi pensado para reaproveitar computadores comuns, e isso explica por que o Linux não é garantido em todos. O Google testa e certifica uma lista de modelos; fora dela, o aparelho pode funcionar, porém sem promessa de desempenho, funcionalidade ou estabilidade. Como o Flex não atualiza o firmware sozinho, uma configuração errada no BIOS fica errada até você corrigi-la manualmente. Se o seu notebook já exibiu o Penguin funcionando, como no caso deste guia, a compatibilidade está confirmada na prática, e o que sobra é automação. Se você ainda está decidindo se vale instalar o Flex num notebook velho, a checagem abaixo economiza uma tarde.

• Abra Configurações, Avançado, Desenvolvedores e confira se a opção "Ambiente de desenvolvimento Linux" aparece e pode ser ativada.
• Entre no BIOS ou UEFI e ative a virtualização (os nomes variam: Intel VT-x, Virtualization Technology, AMD-V ou SVM Mode).
• Consulte a lista de modelos certificados do ChromeOS Flex e leia as observações do seu modelo, que às vezes citam limitações.
• Reserve espaço em disco: o disco da Termina deste caso tinha cerca de 4,2 GiB aparentes antes de qualquer pacote extra.

Uma observação vinda de relatos de comunidade, e por isso tratada aqui como hipótese e não como regra: usuários do ChromeOS Flex em hardware antigo relataram que, mesmo com virtualização ativa, o Linux deixou de ser oferecido em máquinas com processadores muito antigos, e que ligar a virtualização no BIOS resolveu parte dos casos. Se você está nessa situação, teste com a virtualização ativada e, havendo opção, alterne entre modo UEFI e modo legado. Lembre-se também de que o Flex não executa aplicativos Android nem máquinas virtuais do Parallels, então o Linux costuma ser o único caminho para ferramentas além do navegador. Acompanhe também nossos conteúdos sobre ChromeOS Flex.

Como fazer backup do Penguin antes de mexer em qualquer configuração?

Use o backup nativo do ChromeOS nas configurações do Linux ou o comando vmc export no Crosh, que grava a VM Termina em um arquivo. Faça isso antes de qualquer alteração em lxc config ou systemd. Um backup recente transforma um erro grave em apenas uma restauração.

Na conversa que originou este guia, a orientação mais valiosa foi justamente a negativa: não executar vmc destroy termina, lxc delete, reinstalar o Linux nem fazer Powerwash antes de entender o problema. Esses quatro comandos têm em comum o fato de serem irreversíveis para o conteúdo do container. Como o objetivo agora é mexer em configuração e criar serviços, vale tratar o backup como etapa obrigatória e não como sugestão. O ChromeOS oferece o recurso nas configurações do ambiente Linux, na mesma tela que ativa e desativa o Linux, e a documentação oficial lista "backup e restauração fáceis do container" entre os benefícios do recurso.

Há também a rota pelo Crosh, útil quando a interface gráfica não abre. A documentação do projeto descreve a sintaxe vmc export <nome da vm> <nome do arquivo> [nome do armazenamento removível], em que o último argumento é o rótulo do pendrive ou cartão e deve ir entre aspas se tiver espaços. A mesma documentação explica que o arquivo gerado pode ser extraído depois e montado, e que os dados do Penguin ficam dentro dele. Exemplo prático, com um pendrive rotulado PENDRIVE:

# No Crosh (Ctrl + Alt + T)
vmc export termina termina-backup PENDRIVE

Dois cuidados evitam surpresas. Primeiro, o export de uma VM de vários gigabytes demora, e interromper no meio deixa um arquivo incompleto que parece válido; espere o prompt voltar. Segundo, verifique o arquivo no app Arquivos e confira se o tamanho é coerente com o disco da Termina antes de seguir. Se você usa o Linux para guardar projetos importantes, copie também as pastas críticas do Penguin para a pasta Meus Arquivos do ChromeOS ou para a nuvem. Backup que nunca foi aberto é só esperança, então pelo menos uma vez teste a leitura do arquivo.

Como ligar a VM Termina e iniciar o Penguin pelo Crosh, passo a passo?

Abra o Crosh com Ctrl + Alt + T, rode vmc start termina para ligar a VM, depois lxc list para ver o container e lxc start penguin para iniciá-lo. Por fim, lxc exec penguin -- bash abre um shell dentro dele. São cinco comandos, e cada um tem um motivo.

1. Abra o Crosh (1 minuto). Pressione Ctrl + Alt + T e espere o prompt crosh>. Ele é um shell restrito do ChromeOS, por isso comandos comuns como which respondem unknown command; isso é normal e não indica falha.

   crosh> vmc list

   Esse comando lista as VMs que existem no disco. Ele é seguro e serve de teste: se aparecer a linha termina (... bytes, raw, sparse), a VM existe. Se a lista vier vazia, pare aqui, porque o problema passa a ser a ausência da VM, não o estado dela.
2. Ligue a VM Termina (de 5 a 30 segundos). Execute o comando abaixo e aguarde.

   crosh> vmc start termina

   Ele inicializa a VM e entrega um shell interno. O resultado esperado é o prompt mudar para (termina) chronos@localhost ~ $. Sem esse passo, o vsh termina volta com Failed to get VM info for termina. Para sair, use Ctrl + D; evite Ctrl + C, que interrompe a sessão e foi o que aconteceu no log original.
3. Liste os containers (2 segundos). Já dentro da Termina, rode:

   (termina) chronos@localhost ~ $ lxc list

   Você verá uma tabela com NAME, STATE, IPV4, IPV6, TYPE e SNAPSHOTS. No caso real, a linha era penguin | STOPPED, tipo CONTAINER e zero snapshots. Se o comando lxc não for encontrado aqui, você ainda está no Crosh e não na Termina; confira o prompt.
4. Inicie o Penguin (de 5 a 20 segundos).

   lxc start penguin
   lxc list

   O primeiro comando inicia o container sem tocar nos seus arquivos; o segundo confirma. Espere ver RUNNING e, depois de alguns instantes, um endereço IPv4. Se continuar STOPPED, copie a mensagem completa de erro antes de tentar qualquer outra coisa.
5. Entre no container (opcional).

   lxc exec penguin -- bash

   Isso abre um shell como root dentro do Debian. É útil para ajustes de sistema, como os serviços da seção final. No dia a dia, prefira o app Terminal, que entra como o seu usuário comum e já traz a integração com arquivos e janelas.

Depois do passo 4, abra o app Terminal do ChromeOS. Com o container já em execução, ele deve abrir quase instantaneamente. Se abrir lento ou girar sem parar, consulte o catálogo de erros: uma sessão lxc console esquecida aberta é uma causa documentada para o lançador de aplicativos ficar preso. Para outros tutoriais de terminal, veja os guias de Linux no canal.

O comando boot.autostart do LXD resolve a inicialização automática?

Parcialmente, e só depois que a VM já estiver ligada. A chave boot.autostart instrui o LXD a iniciar o container quando o próprio LXD sobe. Se ninguém liga a Termina, o LXD nunca roda, e portanto a chave sozinha não automatiza nada no login.

A conversa original sugeriu rodar lxc config set penguin boot.autostart true. O comando é válido, e a documentação do LXD descreve a chave como a instrução de sempre iniciar a instância quando o LXD inicia; se a chave não estiver definida, o LXD restaura o último estado da instância. Existem ainda boot.autostart.delay e boot.autostart.priority, que controlam espera e ordem quando há vários containers. O problema não está no comando, mas na expectativa em torno dele. No ChromeOS, o caminho Crosh, Termina, LXD, Penguin começa quando algo do lado do ChromeOS liga a VM. Antes disso, não há LXD para ler a chave.

Há ainda uma incerteza que não consegui confirmar nas fontes: a Termina é uma VM gerenciada pelo ChromeOS, e o container é controlado também pelo Tremplin e pelos serviços de integração. Isso significa que o efeito da chave pode variar entre versões do ChromeOS, e que não vale prometer a ninguém que ela "deixa o Penguin 100% automático". Trate-a como um complemento a testar, não como solução. O teste é rápido e fica à sua disposição:

# Dentro da Termina (vmc start termina)
lxc config set penguin boot.autostart true
lxc config get penguin boot.autostart
# Depois, no Crosh:
vmc stop termina
vmc start termina
lxc list

Se, depois de religar a VM, o lxc list já mostrar o Penguin como RUNNING sem você ter rodado lxc start, a chave funciona no seu ChromeOS e o ganho é real: você só precisa de um gatilho que ligue a VM. Se continuar STOPPED, remova a chave com lxc config unset penguin boot.autostart para manter a configuração limpa e parta para o gatilho de login da próxima seção, que inicia o container pelos mesmos caminhos oficiais que o app Terminal usa. Esse é o contraponto deste guia: configuração do LXD sem gatilho de login é meia automação.

Como abrir o Linux automaticamente quando eu entro na conta do ChromeOS?

Duas rotas práticas existem: definir o Terminal como página de inicialização do navegador ou instalar a extensão de código aberto ChromeOS AutoStart, que executa comandos no Crostini quando o ChromeOS inicia. Ambas dependem do login, porque nada do Linux roda antes de a sessão do usuário existir.

O ChromeOS AutoStart é um projeto de código aberto no GitHub descrito como uma extensão para executar comandos Linux no início do ChromeOS, sem exigir o modo desenvolvedor do aparelho. No Crostini, ele roda comandos quando o ChromeOS inicia e pode até iniciar a Termina com kernel e parâmetros personalizados. Por trás, usa uma API de extensões chamada chrome.terminalPrivate e um ouvinte de inicialização, e por isso precisa ser carregado como extensão descompactada. A segunda rota, citada por usuários da comunidade, é abrir chrome-untrusted://terminal como página inicial; como o Terminal liga a VM e o container, o efeito é parecido, ao custo de uma janela aberta.

1. Baixe a extensão (2 minutos). Acesse o repositório do ChromeOS AutoStart no GitHub, baixe o código compactado e extraia a pasta. Isso é necessário porque a extensão não vem de loja; o sinal de sucesso é uma pasta com um arquivo manifest.json.
2. Carregue como descompactada (2 minutos). Abra chrome://extensions, ative o "Modo do desenvolvedor" da página (que é um modo de extensões, não o modo desenvolvedor do aparelho) e use "Carregar sem compactação". Se o botão não aparecer, o modo ainda está desligado.
3. Cadastre o comando de teste (1 minuto). Na janela da extensão, adicione uma entrada para Crostini com o comando abaixo e salve. O sleep dá tempo ao container de terminar de subir, uma prática que usuários do projeto adotam.

   sleep 10 && date >> /tmp/autostart-teste.log

   Depois do próximo login, o arquivo deve conter uma linha com data e hora. Se o arquivo não existir, a extensão não executou ou o container ainda não estava pronto.
4. Troque pelo seu comando real (3 minutos). Só depois de ver o log de teste funcionar, substitua pelo comando ou script que você quer, por exemplo um bash ~/iniciar.sh que sobe seus serviços. Validar com um comando inofensivo primeiro evita misturar falha da extensão com falha do seu script.

Valide sempre a automação em quatro estados, porque cada um se comporta diferente: login logo após ligar o notebook, tela bloqueada e desbloqueada, volta de suspensão e saída da conta seguida de nova entrada. O log de teste mostra qual estado dispara o comando e qual não dispara, e é essa evidência, e não a crença de que "deve funcionar", que sustenta uma automação confiável. Essa é uma dica que não encontrei documentada: manter o arquivo de log por um dia inteiro de uso revela suspensões silenciosas que o terminal sozinho nunca mostra. Veja também os guias de automação no CanalQb.

Por que o Penguin não continua rodando depois de desligar ou sair da conta?

Porque, por desenho, as VMs e containers do Linux no ChromeOS ficam presos à sessão do usuário e são encerrados no logout. A documentação do projeto é direta: os processos não sobrevivem ao logout, já que vivem no armazenamento criptografado do usuário. Não existe método oficial para contornar isso.

Essa fronteira é a informação mais importante deste guia, e a pergunta "como deixar 100% automático" só faz sentido depois dela. O ChromeOS guarda o disco da Termina dentro dos dados criptografados do seu perfil. Sem a senha, esses dados não são abertos, portanto nada do Linux pode iniciar antes do login. Um comentário de usuário na comunidade resume bem: nenhum dado do usuário, Linux incluído, é acessado sem uma sessão ativa. A mesma lógica explica por que desligar o notebook derruba tudo e por que sair da conta mata os serviços, mesmo que o disco da VM permaneça intacto.

O que acontece com o Penguin em cada situação

Situação	Penguin continua rodando?	Observação
Notebook ligado, conta logada, tela ativa	Sim	Fechar todas as janelas de aplicativos não desliga a VM nem o container.
Tela bloqueada	Sim, enquanto o sistema não suspender	Bloquear mantém a sessão; sair da conta não.
Suspensão (tampa fechada ou ociosidade)	Não ativo	Tudo congela; veja a seção de energia.
Sair da conta (logout)	Não	VMs e containers são encerrados.
Reiniciar ou desligar	Não	Exige login; depois, gatilho de início.

Na prática, isso muda como você deve pensar o notebook: ele é um servidor de sessão aberta, não um servidor de boot. O fluxo realista é ligar, entrar na conta uma vez, deixar o gatilho de login subir o Penguin e os serviços, e depois bloquear a tela em vez de sair. Se você precisa de disponibilidade 24 horas, com recuperação sozinha depois de queda de energia, esse perfil de uso não atende, e o melhor caminho é um servidor Linux de verdade, um mini PC ou uma instância em nuvem. Os guias deste canal sobre servidores Linux caseiros cobrem essas alternativas. Para tarefas intermitentes, como scripts agendados enquanto você trabalha, o desenho da sessão aberta funciona bem e custa nada.

Como manter o notebook acordado com a tampa fechada sem estragar a bateria?

Em Configurações, Dispositivo, Energia, desative a opção que faz o sistema dormir ao fechar a tampa, mantenha o carregador conectado e ajuste o comportamento de ociosidade. Desde o ChromeOS M61 essas opções existem nas configurações de energia, e a extensão Keep Awake cobre apenas o caso ocioso.

Sem esse ajuste, todo o esforço de automação perde o sentido: o notebook suspende ao fechar a tampa, a VM congela e os serviços do Penguin ficam inacessíveis até alguém abrir o equipamento. A documentação de gerenciamento de energia do ChromeOS confirma que as opções de ociosidade e de tampa fechada ficam em chrome://settings/power, e que a extensão Keep Awake alterna rapidamente o comportamento de ociosidade pela API chrome.power. O detalhe que costuma enganar é que a extensão não impede a suspensão com a tampa fechada, a menos que exista um monitor externo conectado; para a tampa, o controle correto é o da tela de configurações.

1. Abra as configurações de energia (1 minuto). Clique na bandeja do relógio, abra Configurações e procure por Energia na seção Dispositivo. Como o Flex usa as configurações do ChromeOS, o caminho é o mesmo de um Chromebook, embora o nome exato varie entre versões.
2. Desative "Dormir quando a tampa estiver fechada". A mudança vale na hora e salva sozinha. Teste fechando a tampa por um minuto com um comando ping rodando em outro dispositivo contra o IP do Penguin: se continuar respondendo, funcionou.
3. Revise o modo ocioso. Escolha entre apagar a tela ou mantê-la ligada quando o aparelho está ocioso. Para servidor, o ideal é apagar a tela sem suspender, e as opções disponíveis dependem da versão.

Fechar a tampa com o notebook ligado traz riscos físicos que valem atenção: o calor acumula porque a ventilação do teclado fica abafada, e uma bateria mantida em carga total por meses envelhece mais rápido. Deixe o aparelho em superfície dura e ventilada, nunca dentro de mochila, e observe a temperatura nos primeiros dias. Se o equipamento esquentar demais, aceite a tampa aberta e a tela apagada, que é o compromisso mais seguro. Se a bateria estiver inchada ou muito antiga, não use o notebook como servidor ligado direto na tomada. Também desative o suspender na tela de bloqueio e mantenha o Wi-Fi em um ponto de acesso estável, porque quedas de rede costumam parecer travamentos do container.

Como manter serviços rodando dentro do Penguin com systemd?

O Penguin usa systemd, então você cria um arquivo de serviço em /etc/systemd/system, habilita com systemctl enable --now e o container passa a subir e reiniciar o programa sozinho. Isso resolve o "depois que o Penguin sobe" da automação, não o "antes".

O container padrão do ChromeOS é um Debian com systemd, e os pacotes de integração do Crostini dependem dele. Isso significa que você tem um gerenciador de serviços completo: quem inicia, em que ordem, o que fazer em caso de falha e onde ficam os logs. Sem ele, qualquer script que você roda à mão morre quando fecha o terminal; com ele, o serviço é iniciado quando o container sobe e é reiniciado automaticamente se cair. Abaixo, um modelo comentado de serviço para um script Python; troque o usuário e os caminhos pelos seus.

# Arquivo: /etc/systemd/system/meu-servico.service
[Unit]
Description=Meu servico no Penguin
After=network.target

[Service]
Type=simple
User=SEU_USUARIO
WorkingDirectory=/home/SEU_USUARIO/app
ExecStart=/usr/bin/python3 /home/SEU_USUARIO/app/servidor.py
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now meu-servico
systemctl status meu-servico
journalctl -u meu-servico -n 50

Cada linha tem uma função. After=network.target pede que o serviço espere a rede básica; Restart=on-failure com RestartSec=5 reinicia o programa cinco segundos depois de uma falha, o que cobre quedas ocasionais; WantedBy=multi-user.target faz o enable ligar o serviço ao arranque do container. O comando enable --now ativa no próximo boot e inicia imediatamente, e o journalctl mostra o log, que é o primeiro lugar a olhar quando o serviço não sobe. O resultado esperado do status é active (running); se aparecer failed, leia as últimas linhas do journal.

Duas ressalvas de segurança fecham o assunto. Primeiro, o Penguin tem rede própria dentro do ChromeOS, e expor uma porta para a sua rede local exige o encaminhamento de portas nas configurações do Linux; abra só o necessário e nunca coloque serviço sem senha numa porta aberta. Segundo, não aplique as configurações avançadas que circulam em guias da internet, como tornar o container privilegiado com security.privileged true ou desativar bloqueios de chamadas de sistema, a menos que você entenda o que está desligando: essas mudanças reduzem o isolamento e só se justificam em casos específicos, como acesso a dispositivos. Para quem quer ir além, o canal tem material sobre serviços com systemd.

Qual é o plano final de automação que realmente funciona no ChromeOS Flex?

O plano que funciona combina cinco peças: backup, gatilho de login, container iniciado pelos caminhos oficiais, serviços sob systemd e energia ajustada. Ele entrega um notebook que, depois de você entrar na conta, sobe o Penguin e os serviços sozinho, e que continua útil com a tampa fechada.

Juntando o que as seções anteriores mostraram, a sequência de decisões fica curta. Antes de tudo, o backup, porque as etapas seguintes mexem em configuração. Depois, confirmar que o Linux existe e liga pelo Crosh, usando vmc list e vmc start termina, para saber em qual camada você está. O terceiro passo é escolher o gatilho de login: a extensão ChromeOS AutoStart, que roda comandos no Crostini, ou o Terminal como página inicial. O quarto passo é fazer o gatilho iniciar o que interessa, o container e, dentro dele, os serviços do systemd. O último é ajustar a energia para que a sessão aberta não seja suspensa.

• Backup do Linux feito e arquivo aberto ao menos uma vez para conferência.
• vmc list mostra a VM e lxc list mostra o Penguin.
• Gatilho de login testado com o log de teste nos quatro estados.
• Serviços habilitados com systemctl enable --now e status active (running).
• Opção de dormir ao fechar a tampa desativada, notebook na tomada e bem ventilado.

O que esse plano não entrega é igualmente importante: continuidade depois de queda de energia, disponibilidade antes do login e imunidade a atualizações do ChromeOS, que podem trazer uma nova versão da Termina e mudar o comportamento de containers personalizados. Documentos do projeto e da comunidade registram casos em que atualizações do ChromeOS quebraram containers customizados, sempre com correção possível, o que reforça o valor do backup. A decisão prática é esta: se a sua necessidade é um serviço que precisa estar no ar a qualquer hora, use hardware dedicado; se a necessidade é um ambiente Linux que acompanha seu trabalho e sobe sozinho quando você senta, o plano acima resolve com custo zero. Registre a data da última validação e revalide depois de cada grande atualização do ChromeOS Flex.

Perguntas frequentes sobre Penguin automático no ChromeOS Flex

O Penguin STOPPED significa que perdi meus arquivos do Linux?

Não. STOPPED é apenas o estado desligado do container; os arquivos permanecem no disco da VM Termina. Se o vmc list mostra o disco da Termina e o lxc list mostra o Penguin, os dados estão preservados e basta iniciar o container com lxc start penguin. Só apague algo se um backup recente existir e se você tiver certeza do que faz. Veja mais em nossos guias de Crostini.

Posso rodar o comando lxc direto no Crosh?

Não, porque o Crosh é um shell restrito do ChromeOS e não inclui o LXD. O comando lxc existe somente dentro da VM Termina. Primeiro rode vmc start termina, espere o prompt mudar para (termina) chronos@localhost e só então use lxc list, lxc start penguin e os demais. Comandos comuns como which também não existem no Crosh; teste dentro da Termina. Mais explicações nos tutoriais de terminal.

É possível deixar o Penguin rodando mesmo depois de desligar o notebook?

Não existe método oficial. A documentação do projeto afirma que VMs e containers são presos à sessão do usuário e encerrados no logout, porque o disco fica dentro dos dados criptografados do perfil. Desligar ou reiniciar exige novo login antes de qualquer serviço voltar. O máximo possível é automatizar o início logo após o login, com a extensão ChromeOS AutoStart. Alternativas para operação 24 horas aparecem em servidores Linux caseiros.

O ChromeOS AutoStart exige ativar o modo desenvolvedor do aparelho?

Não. O projeto afirma funcionar sem o modo desenvolvedor do aparelho quando você usa Crostini. O que você ativa é o modo do desenvolvedor da página de extensões em chrome://extensions, necessário para carregar a extensão descompactada. Os comandos cadastrados rodam dentro do Linux no início do ChromeOS, e o recomendado é validar primeiro com um comando de teste que grava um log. Veja outras ideias em automação no CanalQb.

O boot.autostart true basta para o Penguin iniciar sozinho?

Sozinho, não. A chave faz o LXD iniciar o container quando o próprio LXD sobe, mas a VM Termina só liga quando o ChromeOS a chama, por exemplo ao abrir o Terminal. Você ainda precisa de um gatilho de login. Vale testar a chave, pois ela pode ajudar, e conferir o resultado com lxc list depois de religar a VM. Se não funcionar na sua versão, remova com lxc config unset penguin boot.autostart. Outros testes estão em serviços com systemd.

Meu ChromeOS Flex pode usar o Linux em qualquer notebook?

Nem sempre. O Google informa que o suporte ao ambiente Linux no ChromeOS Flex varia conforme o modelo, e só os modelos certificados têm garantia. O aparelho precisa ter processador Intel ou AMD de 64 bits e virtualização habilitada no BIOS ou UEFI. Se a opção "Ambiente de desenvolvimento Linux" não aparece nas configurações, comece pela virtualização no BIOS e depois confira a lista de certificados. Mais em conteúdos sobre ChromeOS Flex.

Erros e Soluções

Os erros abaixo cobrem o caminho completo do Crosh até o container, incluindo os três que apareceram no log real deste guia. Para cada um há a mensagem ou sintoma, a causa técnica, a correção copiável e a forma de prevenir a repetição, sempre sem apagar a VM nem o container.

ERROR vsh: Failed to get VM info for termina

Causa: a VM Termina não está em execução, então o vsh não encontra informações dela. Não significa que a VM foi apagada.

Solução: no Crosh rode vmc list para confirmar que o disco existe e depois vmc start termina. Com o prompt (termina) chronos@localhost, o ambiente está de pé.

Prevenção: sempre comece pelo vmc start termina e só use vsh depois; se a lista de vmc list vier vazia, o diagnóstico é outro e merece pesquisa antes de qualquer ação.

ERROR - ERROR: unknown command: lxc

Causa: você digitou lxc no Crosh. O shell restrito do ChromeOS não inclui o LXD, que existe somente dentro da Termina.

Solução: execute vmc start termina e rode lxc list no prompt (termina) chronos@localhost. Para confirmar o caminho do binário, which lxc dentro da Termina deve responder /usr/bin/lxc.

Prevenção: olhe o prompt antes de digitar: crosh> não tem lxc; (termina) tem.

Error: no such subcommand: `status`

Causa: o vmc não possui o subcomando status; a sugestão de usar vmc status termina estava incorreta.

Solução: use vmc list para ver as VMs existentes e vmc start termina para ligar. Para desligar, use vmc stop termina.

Prevenção: confira a sintaxe na documentação do projeto antes de repetir um comando que apareceu em resposta de IA, inclusive em respostas minhas.

penguin com STATE igual a STOPPED, e lxc exec falhando

Causa: a VM foi ligada pelo Crosh, mas ninguém iniciou o container. O texto exato da falha do lxc exec em container parado varia com a versão do LXD, mas o sintoma é sempre o mesmo: o shell não abre.

Solução: rode lxc start penguin, depois lxc list até ver RUNNING, e só então lxc exec penguin -- bash. Se continuar parado, guarde a mensagem completa de erro e o resultado de lxc info penguin --show-log antes de tentar outra coisa.

Prevenção: abra o app Terminal em vez de iniciar o container na mão, ou use o gatilho de login da seção 6.

Aplicativos Linux giram sem abrir depois de iniciar o container na mão

Causa: documentação da comunidade registra que uma sessão lxc console penguin deixada aberta pode impedir o lançador de iniciar aplicativos, com o ícone girando indefinidamente.

Solução: feche a sessão de console, rode lxc stop penguin e depois lxc start penguin. Prefira o app Terminal do ChromeOS em vez de lxc console no uso diário.

Prevenção: use lxc exec penguin -- bash para ajustes pontuais e saia com exit.

O Linux sumiu depois de reiniciar ou de sair da conta

Causa: VMs e containers do ChromeOS são presos à sessão do usuário e encerrados no logout; ao reiniciar, ninguém os ligou de novo. Os dados continuam no disco.

Solução: entre na conta, abra o app Terminal e, se ele não abrir, repita a sequência vmc start termina e lxc start penguin.

Prevenção: configure o gatilho de login e use bloqueio de tela em vez de sair da conta.

Serviço some quando a tampa é fechada

Causa: o notebook suspendeu, o que congela a VM e todos os processos do container.

Solução: em Configurações, Dispositivo, Energia, desative a opção de dormir ao fechar a tampa e mantenha o carregador conectado.

Prevenção: teste com ping de outro dispositivo por alguns minutos com a tampa fechada, e monitore a temperatura do aparelho.

Gostou deste guia? Veja os testes em vídeo no canal @CanalQb no YouTube, deixe sua dúvida e conte nos comentários qual modelo de notebook você usa com o ChromeOS Flex.

Fontes e Referências

Fontes consultadas em 02/11/2026. Confirme versões e procedimentos nelas antes de publicar mudanças em produção.

• Running Custom Containers Under ChromeOS (Chromium OS Docs): arquitetura Termina, Tremplin, Garcon, comando vmc export e persistência.
• Linux on ChromeOS FAQ (chromeos.dev): inicialização do container e encerramento no logout.
• Differences between ChromeOS Flex and ChromeOS (Google): suporte ao Linux conforme o modelo.
• LXD instance options (Canonical): chaves boot.autostart.
• ChromeOS AutoStart (GitHub): extensão para executar comandos Linux ao iniciar o ChromeOS.
• Chrome OS Power Management FAQ (Chromium): opções de ociosidade e tampa fechada.
• Chrome OS devices/Crostini (ArchWiki): problemas conhecidos com containers e console.

Feito com Master Rules Claude v9.3

Aviso: ID de vídeo padrão (DUDla8Bya8M) usado. Substitua pelo vídeo real antes de publicar.