Nesse tutorial, mostraremos o procedimento de recuperar o sistema com o chroot executado no Debian para acessar a raiz do openSUSE Leap onde o mesmo encontra-se com problema e assim fazer as devidas alteração e modificação de arquivos de configuração ou até mesmo a remoção e instalação de pacotes para deixar o sistema novamente consistente. Assim, diante do meu relato, saiba como recuperar um sistema Linux com o Chroot.
O problema com o openSUSE Leap ocorreu após a instalação do driver da Nvidia, de modo a não carregar corretamente a tela de login após o boot, ficando apenas uma tela preta com o ponteiro do mouse.
O driver da Nvidia após instalado e funcionando perfeitamente, na atualização do sistema, ocorreu alguma incompatibilidade com a configuração do driver da nvidia e o pacote da interface de login sddm ocasionando o problema.
Pelos relatos que obtive no grupo do Telegram openSUSE Brasil, isso seria um bug com o driver da NVidia e o gerenciador de login sddm (Simple Desktop Display Manager).
Para saber mais sobre o Debian e o openSUSE, acesse a página dos projetos clicando nos botões abaixo.
O fato ocorrido
Depois de alguns dias após deixar o openSUSE Leap atualizado e funcionado perfeitamente, ao retornar a dar boot, para minha surpresa, após o sistema carregar perfeitamente a interface de login sddm não carregou corretamente, ficando apenas com uma tela preta e o ponteiro do mouse.
Com esse problema, sem ter como logar pela interface, com as teclas Ctrl+Alt+F1 mudando para o console tty1, executei o comando para atualização do sistema e assim verificar se o problema seria resolvido. Mesmo após a atualização ter ocorrido sem problemas, nada mudou e o problema persistia.
Na tentativa de carregar a interface com o comando startx o mesmo retornava erro de xinit. Ao perceber que o xorg estava com problema em não carregar, com a tela preta no lugar da tela de login, percebi que o problema era realmente com o driver da Nvidia.
Depois de algumas pesquisas e ajuda no grupo do Telegram openSUSE Brasil, não obtive progresso em relação ao problema, chegando uma hora em que removi o driver Nvidia que acabei de instalar e instalei o driver Nvidia mais antigo para verificar se o sistema iria carregar a tela de login sddm corretamente, mas nada que estivesse ruim não pudesse piorar! Pelo que me foi passado no grupo, o problema é um bug do driver da Nvidia com o sddm assim não carregando corretamente a tela de login, ficando apenas na tela preta e com o ponteiro do mouse.
openSUSE inconsistente
Depois de algumas tentativas de recuperar a interface de login sddm do openSUSE Leap, o que estava ruim ficou ainda pior. Com o problema descrito acima, ainda tinha acesso ao sistema podendo logar no console tty para fazer as devidas modificações na tentativa de sanar o problema, mas depois que removi o driver Nvidia 390.25 e instalei o driver Nvidia 340.106 para testar, ficou a tela do console tty1 inconsistente, piscando como se fosse uma ‘bruxaria’ kkkk, assim tendo reflexo no teclado em não responder adequadamente o que era digitado, assim não tendo êxito ao logar, pois sem saber o que o teclado respondia, sem chance de entrar com a senha correta!
Abaixo, um vídeo curto da ‘bruxaria‘ que ocorreu com o tty1.
Não obtendo êxito a entrar no sistema pelo console, a orientação que tive foi para instalar novamente o sistema. Como no momento não tinha em mãos a mídia de instalação do openSUSE, recordei que tempos atrás aconteceu um problema quando usava o Sabayon e também não tinha em mãos a mídia de instalação, lembrei o procedimento executado com o chroot para entrar no sistema e reparar o mesmo, assim logo dei reboot no sistema.
Para saber mais sobre o Sabayon, acesse a página no projeto clicando no botão abaixo.
Identificando a partição onde o openSUSE está instalado
Ao reiniciar a máquina para a recuperação do sistema openSUSE, escolhi o Debian no Grub pois o mesmo que gerencia o boot-loader e como tenho outros sistemas operacionais em multi-boot com 4 HD’s na máquina, sda (Windows 10 – no sda2), sdb (Debian – no sdb1 / openSUSE – no sdb2), sdc (FreeBSD – no sdc5) e sdd (disco de dados – no sdd1), executei o comando lsblk para listar as partições dos discos, podendo também executar o comando fdisk -l para listar com mais detalhes os discos e partições assim identificando corretamente o device e a partição onde está instalado o sistema alvo da recuperação. Lembrando que o comando fdisk -l deverá ser executado com privilégio de root.
Veja abaixo as imagens com os respectivos comandos lsblk e fdisk -l.
O comando lsblk e sua saida
O comando fdisk -l e sua saída
Pela saída dos comandos acima, foi identificado a partição sdb2 onde esta instalado o openSUSE.
Preparando o terreno para o chroot
Sabendo que o openSUSE está instalado na partição sdb2, para o procedimento com o chroot, devemos montar a partição sdb2, nesse caso será montada no diretório /mnt.
Montada a partição sdb2 onde está o openSUSE, é necessário montar também o /proc, /dev e /sys para o console ter acesso adequado ao sistema e assim poder fazer os devidos reparos para recuperar o sistema.
Veja abaixo a imagem com os respectivos comandos mount.
Os comandos mount
Com tudo preparado, executamos o comando chroot indicando a partição sdb2 onde foi montado o openSUSE, nesse caso o diretório /mnt. Logo após, para ter certeza que já esta dentro da raiz do openSUSE, execute o comando cat /etc/os-release.
O comando chroot e cat com sua saída.
Com a saída do comando cat /etc/release, notamos que já estamos na raiz do sistema openSUSE.
Recuperando a consistência do sistema openSUSE
Com a inconsistência do sistema openSUSE após instalado o driver da Nvidia 340.106, a primeira coisa a fazer é remover tudo do driver da Nvidia. Para remover o driver em questão, executamos o comando zypper rm nvidia*, confirmando a remoção para desinstalar o driver.
O comando zypper rm nvidia* e sua saída
zypper rm nvidia*
Carregando dados do repositório…
Lendo os pacotes instalados…
Resolvendo dependências de pacote…
Os seguintes 4 pacotes serão REMOVIDOS:
nvidia-computeG03 nvidia-gfxG03-kmp-default nvidia-glG03 x11-video-nvidiaG03
4 pacotes para remover.
Após a operação, 362,7 MiB será liberado.
Continuar? s/n/…? exibe todas as opções:Após a remoção, vamos instalar o driver recomendado, executando o comando zypper install-new-recommends, confirmando a instalação para o driver da Nvidia 390.25 e assim verificar a recuperação do sistema openSUSE após reiniciar.
O comando zypper install-new-recommends e sua saída
zypper install-new-recommends
Baixando os metadados do repositório 'PACKMAN' ……………………..[concluído]
Construindo o cache do repositório 'PACKMAN' ……………………….[concluído]
Carregando dados do repositório…
Lendo os pacotes instalados…
Resolvendo dependências de pacote…
Os seguintes 4 pacotes NOVOS serão instalados:
nvidia-computeG04 nvidia-gfxG04-kmp-default nvidia-glG04 x11-video-nvidiaG04
4 novos pacotes a serem instalados.
Tamanho total do download: 77,8 MiB. Já em cache: 0 B. Após a operação, 362,7 MiB
adicionais serão utilizados.
Continuar? s/n/…? exibe todas as opções:Após a instalação do driver da Nvidia 390.25, vamos reiniciar o Debian e dar boot no openSUSE para verificarmos a consistência do sistema se foi resolvido e resolver o problema com o sddm no carregamento da tela de login.
Iniciando o openSUSE e resolvendo o problema da tela de login sddm
Iniciado o openSUSE e já no console tty1, vamos parar o gerenciador de login sddm que está com problema e seguir os passos seguintes.
Comando para parar o gerenciador de login sddm
systemctl stop display-manager.serviceAntes de ocorrer o problema da inconsistência do sistema do openSUSE, fiz a mudança do link do modo gráfico multi-user para o default na tentativa de recuperação da interface de login sddm mas sem sucesso.
Comando da mudança de link do modo gráfico para defualt
ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.targetComo não adiantou fazer tal mudança, retornei para o modo gráfico multi-user, revertendo o link.
Comando de retorno do link para o modo gráfico
systemctl set-default multi-user.targetCom o retorno do link para o modo gráfico, incluiremos o usuário ao grupo video, caso o mesmo não esteja no grupo. Verifique se o usuário está no grupo video com o comando abaixo.
Comando para verificar se o usuário está no grupo video e sua saída
cat /etc/group | grep mcnd2
video:x:33:Pelo retorno da saída do comando, o usuário mcnd2 não está incluso no grupo video, assim deveremos incluir o mesmo ao grupo com o comando abaixo.
Comando para incluir o usuário no grupo video no openSUSE
usermod -G video -a mcnd2Agora, executando o comando de verificação mencionado acima, veja que o usuário mcnd2 foi incluído no grupo video.
at /etc/group | grep mcnd2
video:x:33:mcnd2Após a inclusão do usuário ao grupo video, sabendo que a tela de login não esta carregando corretamente por causa do bug da nvidia com o gerenciador de login sddm, em alternativa ao sddm vamos instalar o gerenciador de login lightdm.
Comando para instalar o lightdm no openSUSE
zypper install lightdmPara trocar o gerenciador de login default sddm para o lightdm e assim o torna padrão, execute o comando abaixo.
Comando para setar o display-manager lightdm no openSUSE e sua saída
yast2 sysconfig set DISPLAYMANAGER=lightdmSetting variable 'DISPLAYMANAGER' to 'lightdm': SuccessApós os procedimentos acima, iniciaremos o gerenciador de login lightdm para podermos logar em modo gráfico.
Comando para iniciar o gerenciador de login lightdm no openSUSE
systemctl start display-manager.serviceVeja a tela de login lightdm carregada corretamente. Agora é só logar e utilizar o sistema openSUSE 42.3 Leap.
Fico por aqui e até a próxima baseado nos problemas reais. Mas, a ideia deste tutorial é mostrar como recuperar qualquer sistema Linux com o chroot.
