Meu Void Linux LXQt parou de carregar o DE

Linux Iniciantes
1

Olá pessoal.

Após instalar alguns apps em formato .deb no meu Void Linux, usando o xdeb (entre eles o Google Chrome do site oficial, e o módulo de segurança da Caixa Econômica), em algum momento (não me recordo o que estava instalando, acho que compilando o Google Chrome do xbps-src), a partição raiz do meu Void lotou e deu erro na compilação.

Ao reiniciar o notebook, o sistema parou de carregar o LXQt.

Pra mim foi um balde de água gelada, pois gastei tempo em pesquisas e tentativas e erros, até conseguir deixar meu Void redondo, com os apps e recursos que eu mais utilizo.

Carreguei outra distro em live USB para acessar e excluir vários arquivos do cache xbps do Void, liberando uns 16 GB de espaço. Porém o sistema não voltou mais ao normal.

O boot é interrompido na seguinte situação:

mount:/ /home: unknown filesystem type ‘ext4’
dmesg(1) may have more information after failed mount system call.
mount:/ /boot/efi: unknown filesystem type ‘vfat’
dmesg(1) may have more information after failed mount system call.
Cannot continue due to errors above, starting emergency shell
When ready type exit to continue booting.
/bin/sh: 0: can’t access tty: job control turned off

Quando dou o comando “exit” ele entra numa pequena tela, pedindo para selecionar o gerenciador de janelas a ser utilizado, porém o mouse e teclado nada respondem.
Quando dou o comando “startx”, exibe 3 janelas em branco e tudo travado.

Se entro com Ctrl+Alt+Del ou digito “reboot”, recebo essa mensagem:

  • runit: warning: signals only work in stage 2.

Só não entrei em desespero, porque minha /home está em partição separada e é acessível pela distro que carreguei em pendrive, até para poder postar essa questão. Se bem que as partições EFI, Void e Devuan (dual boot) tbm são acessíveis.

O Void está num SSD Sandisk X-400 de 256GB, SMART em bom estado, em dual boot com o Devuan daedalus (que pra variar também deu zebra, não inicia mais com meu user, pois recusa a senha, mesmo estando correta).

As UUID’s exibidas no Gparted coincidem com as descritas no GRUB, e a /home está realmente formatada em EXT4, e a /boot/EFI em FAT32.

Disco /dev/sdb: 238,47 GiB, 256060514304 bytes, 500118192 setores
Modelo de disco: Ext. HDD (listei ele conectado como HD externo)
Unidades: setor de 1 * 512 = 512 bytes
Tamanho de setor (lógico/físico): 512 bytes / 512 bytes
Tamanho E/S (mínimo/ótimo): 512 bytes / 512 bytes
Tipo de rótulo do disco: gpt
Identificador do disco: 582D68CC-43EA-455E-BF14-C9F992FCE57D
First usable LBA: 34
Last usable LBA: 500118158
LBA alternativo: 500118191
Partition entries starting LBA: 2
Entradas de partição alocada: 128
Partition entries ending LBA: 33

Dispositivo Início Fim Setores Tamanho Tipo
/dev/sdb1 2048 38911 36864 18M BIOS inicialização
/dev/sdb2 38912 161791 122880 60M Sistema EFI (FAT32)
/dev/sdb3 161792 84047871 83886080 40G Linux sistema de arquivos (Void em BTRFS)
/dev/sdb4 84047872 167995391 83947520 40G Linux sistema de arquivos (Devuan em BTRFS)
/dev/sdb5 167995392 483340287 315344896 150,4G Linux sistema de arquivos (/home em ETX4)
/dev/sdb7 483340288 500117503 16777216 8G Linux swap

Notebook LG A560-T, core i7 3630-QM 3ª geração, GPU dedicada nvidia GT-640M, 16 GB RAM, SSD 256GB.

Não faço a menor ideia se essa situação tem solução.
E não faço ideia se o Void cria automaticamente pontos de restauração do sistema, pois eu mesmo nunca tentei instalar o Timeshift ou algo similar.

No menu de inicialização, quando escolho Void em modo recuperação, mesmo com algum kernel anterior, o boot é interrompido no mesmo ponto descrito acima.

Por isso, conto com o valioso auxílio de vocês.

2

Salve, @Rommulo_Peixoto

O problema é que não consegue concluir o Boot da distro. – O LXQt é só uma das consequências.

Se completasse o Boot, seria simples logar como Root e resolver vários problemas por meio de comandos.

Seria como uma “instalação mínima” (sem DE).

3

FS foi para o saco, e por isso o binário executável TTY não foi encontrado no FS e nem monta mais.
A solução é conseguir montar o FS que deu pau.

4

Saudações!

No fstab, as UUID’s e formato das partições /home e /boot/EFI também estão corretas. Não sei mais onde procurar o erro. O dsmeg emitiu uma lista gigantesca de processos, por isso não postei aqui.

No fórum do Void no reddit, recebi uma mensagem automática (provavelmente de um robô) dizendo o seguinte: “Parece que você mencionou ‘xdeb’; não toleramos o uso desta ferramenta, pois ela provavelmente destruirá o seu sistema.”

Com base no seu comentário e no do robô, presumo que quebrei o sistema.

1 curtida
5

Seu palpite faz sentido. Qual seria o procedimento pra tentar recompor o FS?
O curioso é que, iniciando outra distro via pendrive, ele acessa normalmente todas as partições do meu SSD, inclusive a do Void que crashou, e o gparted exibe todas em perfeito estado, com as UUID’s corretas, estando minha /home realmente formatada em EXT4 e a /booit/EFI em FAT32. Será que foi curpa da mardita pinga, digo, xdeb?

Atualização da informação:
Dei um btrfs check --repair na partição do Void, e não encontrou nenhum erro.

6

O xdeb é realmente perigoso, por isso, só utilizo para aplicações simples, que não vise alterações profundas no sistema como os que visam componentes sensíveis do sistema operacional.

O componente utilizado por banco em xdeb provavelmente foi a causa disto. Entre outras coisas, ele foi projetado pra systemd, o Void utiliza o runit. Este pacote causou uma lambança no seu sistema, difícil saber como resolver…

Na próxima saiba utilizar o Timeshift, que é imprescindível em ambientes como Void.

8

Pois é. Eu vi um artigo sobre a instalação correta do warsaw no Void, mas na pressa e teimosia, tentei instalar o módulo .deb da CEF. Lembrando também que a compilação do Google Chrome (xbps-src) deu pau pq a partição lotou.

1 curtida
9

Então esta tudo certo, boa investigação ai.

10

Um colega aqui do Fórum acaba de se deparar com um problema parecido – faltou espaço na partição-raiz em sistema de arquivos BtrFS durante uma compilação – e é possível que a solução seja a mesma, sugerida para ele:

Já adianto que nunca fiz isso – adicionar uma partição BtrFS a outra. – No caso, você já tem a partição do Devuan, e se quiser esvaziá-la (formatá-la), talvez possa ser usada para isso.

Mas, repito, nunca fiz isso… Talvez o @Deleterium possa dizer como.

Para o futuro… posso recomendar o seguinte:

  1. Monitore sempre o espaço ocupado / espaço restante, em suas partições. – Eu uso o Conky para isso:

2023-09-24_16-46-55_D-Conky-partitions_CROP
2023-09-24_16-46-55_D-Conky-partitions_CROP857×835 166 KB

  1. Tenha sempre uma segunda distro em dualboot, pronta para uso imediato. – Deixar o Devuan fora de combate, é o mesmo que não ter uma segunda distro. – Numa emergência como essa, você não fica sem SO para continuar seu trabalho, acessar Fóruns, pesquisar dicas, pedir ajuda etc. (pois sessão Live é terrível).

  2. Evite fazer experiências com sua distro “principal”. – Use a segunda distro, e veja se dá certo, antes de fazer a mesma coisa na “principal”.

11

mas vc uso btrfs check em uma partição ext4 porque, o fstab seu diz ser ext4, não te entende.

12

Ótimo relato com muitas informações. Embora eu ainda não consiga dar um palpite sobre o problema, tem várias outras coisas que posso ajudar.

  1. 40G para a partição raiz é suficiente para um sistema enxuto, mas se você vai se aventurar em compilar pacotes ou o kernel, já recomendo 80G de espaço
  2. O comando btrfs-check --repair só deve ser usado em último caso, pois o programa pode assumir coisas e tornar um sistema que era possível de ler (quando dá problema o sistema fica somente leitura, com vc podendo salvar os dados) para um sistema totalmente quebrado e arquivos faltando.
  3. O Warsaw não funciona mais se não tiver o sytstemD. Eu tenho o systemV e funcionou até 6 meses atrás, parando de funcionar “do nada”. O pacote deb dele é bem simples, não acredito que seja a causa (mas não descarto).
  4. Pra usar o btrfs e ter vantagens, use snapshots (eu recomendo o snapper, fácil de usar e configurar, além de ter uma boa ajuda no site do opensuse). Se tivesse snapshots vc poderia simplesmente voltar no tempo para un instantâneo anterior e seguir. Porém se for usar esse recurso, já imagine uns 20G a mais para a partição.
  5. Quando entupir o disco, a PIOR coisa a se fazer é desligar o computador sem resolver. Mas a princípio o sistema deveria conseguir se iniciar mesmo em somente leitura mesmo com vários erros na inicialização. Para saber o espaço livre no BRTFS não confie no comando df mas sim no btrfs filesystem usage / Procure os tutoriais sobre como usar o balanceamento do sistema para tentar abrir espaço de arquivos apagados, e alguns casos extremos precisam adicionar mais espaço à partição para poder ter espaço para “adicionar a informação que o arquivo foi apagado”, especialmente se tem subvolumes com snapshots.

Enfim, sempre dou a dica do btrfs ser um simulador de cabine de 747 e o ext4 ser um joguinho de celular. Nos dois vc vai voar, mas em um vc precisa saber o que fazer quando acender uma luz vermelha no painel (senão um simples alarme de tubo de pitot entupido pode causar um trágico acidente).

2 curtidas
13

Mas não pode ser btrfs, o fstab esta como ext4 e ele mesmo disse que é ext4, eu acho que ele fez uma confusão na ferramenta de reparo.
Era para ser e2fsck.

14

Olá amigo.
A partição em que está o Void é btrfs, e foi por isso que usei “btrfs check --repair”. Mas como eu disse, não encontrou nenhum erro.
Apenas minha /home é EXT4, e está em perfeito estado e acessível via sessões live USB.

15

Void em /dev/sda3, BTRFS.

16

O erro diz ext4 é a sua home que não monta, o btrfs é muito mais seguro que o ext4 e o btrfs ainda se autorrepara durante a montagem.
O problema do btrfs é que ele tem algumas tecnologias que são inseguras devido que eles ainda estão inserindo novos recursos para ele ficar ainda mais poderoso, ou seja ele ainda esta em desenvolvimento.

17

Tem um bom tempo que adotei duas SO’s em dual boot.

Só me dá raiva quando instalo uma 2ª distro e ele ignora a 1ª já existente (ex. KDE Neon), ao montar o GRUB, com BIOS em UEFI e SSD em GPT. Com BIOS Legacy e tabela MS-DOS no HD, todas as distros montam de boa o GRUB.

O GRUB-Customizer e Rescatux em live, pra mim só fazem de conta que trabalham… ano passado instalei o Devuan anterior e ele ignorou o Void. Então editei na unha as UUID’s e nomes corretos dos arquivos vmlinuz e initrd no grub.cfg que ainda estavam apontando para a distro anterior (KDE Neon).

Também recorro à tecla Esc assim que ligo meu note LG A560-T, para escolher as entradas de boot diretamente no gestor de inicialização da BIOS.

Agradeço pela dica do Conky e vou passar a usá-lo!

1 curtida
18

Amigo Deleterium.

Agradeço por suas dicas valiosas!
Já tomei nota sobre balanceamento do sistema, e a adoção do snapper.

Com base nos ítens 2, 4 e 5: Seria mais prático eu ter uma partição de pelo menos 80 GB em EXT4 mesmo? Pois não tenho “brevê de pitolo” pro nível 747 (digo, BRTFS) :laughing:
Pelo que li, ele trabalha com compactação de dados, algo mais a complicar quando lota a partição (será?).

Quanto ao warsaw, vejo que é melhor adotar uma distro leve com systemd (“leve” com vistas a sobrar RAM pro navegador, apps de escritório e editores de vídeos e áudios).

19

Estou mais propenso a desistir de tentar recuperar meu Void, por isso peço licença para entrar na questão de reinstalar tudo do zero, pedindo a vcs dicas de distros e de recursos úteis pós-instalação, sem precisar criar outro tópico só pra isso:

Tenho usado o Void-glibc e testado o Devuan 5, por acreditar que o RUNIT tornaria o sistema mais fluido.

Porém a maioria das distros leves vem com X11 e systemd, bootam rápido e abrem os apps num piscar de olhos. Então a vantagem do RUNIT é discutível, se atentarmos apenas para o desempenho, afinal os pesados Deepin e openSUSE TB (mesmo com Gnome 44) também são tão velozes quanto o LXLE (14.04 e 16.04) que já usei como principal.

Meu crashed Void era com glibc, mas se fosse com “musl” e rodasse appimages sem depender de gambiarras, eu colocaria nele o Sway, e assim teria algo leve e fluido, com Wayland e RUNIT.

Com o snapper em ação, eu tentaria reinstalar o warsal. Li relatos de instalação bem sucedida pro Bco do Brasil (.rpm), com pré instalação de python-pip, pyOpenSSL e instalador rpm nativo em xbps). Mas estou mais propenso a seguir acessando os bancos apenas pelo celular.

Comecei a pesquisar sobre o Void musl e vi que roda flatpaks. Acabei de fazer um levantamento com base nos appimages que mais uso, e constatei que tem em flatpak, ótimo caso não tenha no xbps-install ou src. Só sinto falta de um applet para integrar o Google Calendar ao painel do LXQt (que no KDE Plasma tinha como widget). No Sway nem sei se teria opção.

20

Vamos por partes…

Não entendi…

Ao montar meu PC atual, aceitei UEFI BIOS, e criei tabela GPT – e nunca mais mexi.

Não vejo como alterar para Bios Legacy e tabela MS-DOS, só para fazer esse teste… Isso apagaria as partições existentes.

Ou você se refere a uma época anterior?

A propósito… O que existe em /dev/sda? – Seria bom a gente saber mais sobre esse outro dispositivo.

Usei o Grub-Customizer só 1 vez, há muitos anos, e ele deixou problemas, que com o tempo foram se acumulando, e uns 2 ou 3 anos depois, o Grub das minhas distros ficou endoidecido.

Esse embaralhamento do Grub, também pode acabar envolvendo o Debian, que também é “parecido” com os “Buntus”. – Isso poderia ocorrer com o Devuan, que é quase como o próprio Debian.

Nunca mais usei Grub-Customizer!

Já tive problemas de Grub, quando instalei Kubuntu + Mint + KDE Neon, pois são muito parecidas, e às vezes o Grub delas se embaralha. – Isso, em 2016, no meu PC antigo, Bios Legacy / tabela MBR.

No meu PC atual, UEFI Bios / tabela GPT, voltou a acontecer. – Instalei primeiro o KDE Neon, tudo Ok. – Quando instalei o Mint, o Grub dele não carregava ele próprio… Carregava o KDE Neon.

Acabei eliminando o Mint, e continuo com o KDE Neon funcionando até hoje.

Afora isso, é preciso verificar se o Grub está com Os-Prober ativado ou não. – Quando está ativado, detecta as outras distros. – Quando está desativado, detecta só a própria distro onde é executado / atualizado.

Minha experiência com o Grub de várias distros diferentes está aqui.

21

Falando mais uma vez, e é isso que cansa e eu desisto de responder.
O erro é no ext4, o servidor X ou Xorg não carrega sem achar o arquivo “.Xauthority” que fica na pasta do usuário logado.
Arruma o tal do ext4.

O X é um processo de USUARIO.