Logs de uma Inicialização totalmente falha

Pretendo pular a conversa pretenciosa e ir direto ao assunto : Sou usuário do Linux há bem uns 20 anos, mas nunca tive um diploma bonitinho da área de TI, ou seja, o típico usuário "prego", zoado pelos entendidos mais arrogantes. Pelo meu tempo de experiência é de se esperar que eu já tenha aprendido alguma coisa da vida, e do Linux, mas calhou que desde o meu início tive o azar de só pegar problemas de nível avançado, ao invés dos típicos problemas de newbee -- já comecei tendo que aprender à particionar disco manualmente, consertar fstab, dmrc bugado, aprender à instalar pacote à unha... quando problema de newbee é grub, reparar boot, aprender à usar apt, e não chamar Jesus de "Jenésio", algo assim. Então, assim por conta dessa "formação" pouco ortodoxa, nunca aprendi coisas básicas, como abrir logs, e é esta a razão dessa postagem. Creio que meio de repente "amadureci" -- se isso for lá possível, tem alguém aqui do lado rindo, não vou nem perguntar do quê -- e resolvi por essa parte em dia, e já achei algo por onde começar.

Quando uma inicialização qualquer da vida falha, com o F, o A, o L, e o H e o A maiúsculos, aparece aquela telinha de console com aqueles temíveis avisos de sempre -- e que pra mim até hj não fazem sentido, se não for fsck ou fstab -- e uma dessas diz que para ver os logs ( que eu sempre ignoro, porque considero inútil e que não resolve nada -- pra mim, nunca resolveu -- e perco a paciência e reinstalo, sem medo de ter que fazer mesmo do jeito mais difícil ) e ali no console, sempre diz que eu devo teclar journalctl -xb para ver os tais logs, e outras opções de jornalctl tipo "journalctl reboot", mas nunca consegui fazer essa maldita estrovenga funcionar, mas fé tive que a reinstalação resolve e ponto final, e fiz isso mesmo. Ou mando o timeshift ( quando funciona ) e restauro tudo. Mas aprendi à dar valor aos tais logs, quando consigo acesso à um . Eu bem gostaria que houvesse um bom Navegador de Logs, mas na falha de um, aceito fazer do jeito mais difícil, porque é meio que a minha filosofia de vida e tal ( e eu falando no início que iria pular o papo pretencioso... vc acreditou nisso ? ). Então, Foco : No meu último crash, antes de passar com o timeshift por cima de tudo ( funcionou ), copiei todo o conteúdo da pasta logs ( /var/log/ e tal... ) para a minha pasta documentos, e agora rogo aqui, nas sandálias da humildade, que os veteranos me iniciem na misteriosa arte cabalística de achar logs do evento. Porque o problema, vamos assumir, não é LER os logs, e mesmo quando os sacaninhas não fazem nenhum sentido para o leigo lesado, sempre dá para copiar e colar num google da vida e ver o que aparece -- é como eu fiz durante 20 anos -- Mas o problema é sempre achar o log relevante, já que aquilo que deveria fazer sentido se perde naquela barafunda de logs de todos os tipos.

Bom, veteranos do VOL, se eu supostamente copiei e salvei os logs antes de tratorar com o timeshift a bagaça micada toda, onde neles eu encontro o tal journaling da inicialização falida ? Durante anos procurei em fóruns e googles da vida ( e nos yahoos e bings também ) onde posso encontrar esse tipo de coisa, mas sem resultados visíveis ou mesmo imaginários, nem nos meus sonhos encontro uma dica do Senhor. Só leio veterano dizendo para mandar um dmesg no terminal, mas essa possibilidade se perdeu... Porque nas duas tentativas o shell não iniciou e ficou travado no console, que aliás, como sempre não funcionou ( o tal rescue mode é sem dúvida, propaganda enganosa ) e tive mesmo que "timeshiftizar" a encrenca, para economizar o estresse, que sai caro. Como faço então para acessar o log certo ?

Em tempo : Raciocinei que o timeshift reverte mudanças mas que talvez se omitisse de fazer isso nos logs ou pelo menos ignorasse acréscimos, então acabei de mandar # dmesg de qualquer jeito mesmo, assim que recuperei a inicialização. Tive uma resposta, curta e grossa : "dmesg: leitura de buffer de kernel falhou: Operação não permitida", tentei com sudo ( "sudo dmesg" ), e obtive um relatório quilométrico. Mas é o que eu estava procurando ? ( o journaling da incialização falhada ). Como eu disse, tem muita dica de veterano por aí, mas nenhuminha que diga como acessar log e journaling de sessões idas e perdidas. Então eu gostaria de uma resposta que seja útil não só para mim ( já resolvi o meu problema mesmo... ) mas também para outros com o mesmo problema, porque senti que é algo que está faltando à muito...

Não sei se entendi direito a pergunta, mas os logs do journald ficam em /var/log/journal. Vai ter um diretório com nome cabeludo e dentro dele vários arquivos .journal. Se vc quiser ler os logs rode
journalctl --file system.journal
dentro desse diretório.

Quero agradecer ao Leandro-san, pela boa-vontade de responder à pergunta; e peço desculpas por um texto tão elíptico, mas ocorre que essa pergunta já foi feita por aí, pelos fóruns da vida por outras pessoas durante anos à fio, no mundo todo, e em variados idiomas, mas em geral, os veteranos respondem apenas o problema presente. Falta uma resposta que sirva à todos, iluminando caminhos, e não receita de bolo.

O que sinto falta é de conhecimento geral de como acessar um log, e dentre esses, como garimpo os mais recentes. Leandro-san respondeu de cara metade da pergunta, mostrando um comando simples para pelo menos acessar o journal ( o "diário" que registra os eventos, para quem não sabe ) Então, tem um comando simples para exibir os logs no terminal mesmo, o que não é tão óbvio para o newbee quanto pode-se supor. No Ruinwindows, existia um aplicativo ( pago, é claro ) chamado "Navegador de Logs", ou uma bagaça do tipo, que localizava todos os arquivos de logs, feito uma espécie de nemo ou nautilus de logs, e expunha eles por categorias : Log disso, log daquilo, crashes, eventos recentes... Muito prático, e sinto uma certa vergonha ( antes, sinto-me inferiorizado... ) porque um SO ruim de uma empresa papa-níquel tinha algo assim ( digo sempre me referindo ao passado, porque não sei se ainda tem, na atual série Vista do Ruinwindows ). É meio que tradição do mundo Linux esnobar as aplicações de GUI e preferir o Terminal, em parte por pura falta de consciência sobre porque e pra que uma Gui serve. Falo disso depois.

Mas, voltando ao que interessa, o comando especificado retornou um decepcionante "Failed to add paths: Arquivo ou diretório inexistente", ou seja, talvez por ser linux Mint ( 20.4 Una, baseado no Ubuntu Focal Fossa ), ele não reconheceu o comando, supostamente por exigir um caminho para aplicar o comando. Fiquei boiando. Eu poderia pesquisar sobre os paths apropriados nos fóruns próprios da minha distribuição, então, foi realmente de grande ajuda... Assim, fica pouca coisa pendente. Então, para resumir as pendências que podem ser úteis para o peregrino na estrada de pedras dos logs :

1> Quais são os comandos de terminal para exibir os diversos logs ?
2> Como adiciono um path à esses comandos, caso a minha distribuição refugar ?
3> Como imprimo a saída do terminal para obter um arquivinho txt que eu possa examinar com calma ?
4> Pergunta estúpida mas necessária : As saídas de log pelo terminal estão organizadas por data e evento ? Há exceções ?
5> Pergunta de um milhão de dólares : Como se aplica um grep nessas saídas para buscar só uma específica ?
6> e não menos importante : Quais são as categorias de logs existentes, e qual sua função ? ( o que equivale à responder onde eu posso achar o log relevante para determinado problema, mesmo que eu tenha que garimpar entre MIL linhas dele -- ou até mais -- o que não é raro, e é a razão desse post -- Orientar newbees perdidos em mar aberto para não ficarem procurando entre mil linhas no lugar errado, para depois irem procurar entre mais mil linhas em outro lugar errado... ).

Digo tudo isso, porque não vale à pena escrever uma solução que não seja geral para orientar todos os newbees. Minha consciência social me diz que se for para perguntar algo, deve-se buscar uma pergunta e uma resposta que fique como um farol para iluminar o caminho dos próximos que vierem com problema semelhante. Menos soluções à vezes é mais solução. É a minha noção pessoal de "trabalho bem-feito", aquele que serve para todo mundo, e que continua contribuindo durante anos. Nos fóruns do Linux Mint, pelo menos, há tópicos sobre o Pulseaudio que são mantidos há 10 anos ! No VOL também !

E por fim, para não deixar pontas soltas, nem deixar ratos de terminal bolados pelo o que eu disse sobre GUIs, vale um esclarecimento que faz falta : "GUI" não é algo criado para preguiçosos ou para usuários de Ruindows, aqueles que só sabem usar google e facebook, e acham que "terminal" é algum tipo de monstro para nerds de nível crânio. Não. As GUI existem para que usuários não tenham que decorar centenas de comandos de terminal, com seus atributos, e suas sintaxes às vezes indigestas. Alguns comandos são bem simples, como o top ou o ls, mas há tranqueiras como ffmpeg, com mais de 30 atributos e uma sintaxe barroca e muito difícil -- os atributos devem ser escritos em determinada ordem ( isso não consta no manual ), ou ele simplesmente não faz nada... Fora que tem muito manual meia-boca que não se dá o mero trabalho de orientar como se deve configurar os atributos ( exemplo para verem que falo sério: o manual do hdparm, um comando considerado bem simples, cita atributos -c, -d, -a, -I, e que diz que os valores para -c pode ser c0, c1, c2, mas não se dá ao trabalho de dizer que c1 é configuração de saída de 16 bits, c2 é 32 bits; e c0 é padrão definido pela fábrica e não pode ser mudado, como no caso dos HDs Seagate Barracuda. Então, GUI é uma maravilha e serve para que ninguém se perca, digite besteira ou fique deservido sem saber o que fazer. São frontends de terminal para inserir automaticamente comandos de forma segura. Isso não diz respeito ao atual tópico, mas sempre bato nessa tecla porque falta conscientização da comunidade que presta assistência nos fóruns; então, se há um tópico com respostas que dizem que "o terminal faz tudo", ou quase isso, me sinto na obrigação de conscientizar. Afinal, todos aqui são unidos e fazem um trabalho tão bonito ! ( o tópico do suexec que o diga ! ) Mas dá para melhorar. Acredite na sua comunidade ! A liberdade é nossa !

Ei, veteranos, valeu à pena choramingar : Alguém me passou ( por e-meio ) que dentro do Mint, existe um aplicativo chamado "Logs" ( gnome-logs ) que já está na versão 3.4, mas é pouco conhecido; e é bem tipo Navegador de Logs, como eu havia mencionado. E parece que ele pode ser instalado em qualquer desktop Gnome ou descendente do tipo ( como o Cinnamongo ou o Budgie ). Parece que existe também um "activity-log-manager", para fazer manutenção e gerenciamento dos logs ( tipo, limpar, configurar logrotate ou configurar o envio automático para os desenvolvedores -- no caso, a Canonical ), mas há um problema nesse activity-log-manager : todinho em inglês, e inglês coloquial, ainda por cima, que é ambiguo e não se traduz fácil -- não dá para copiar e colar, vc tem que escrever letra por letra num google translate da vida, que vai responder besteira, porque linguagem coloquial ( informal, do dia-à-dia ) em inglês, é o inferno dos tradutores, pela ambiguidade. É onde o google translate tem mais dificuldades e as mais baixas taxas de acerto. Mas o "Logs" tá todinho em português e bem traduzido. Acrescentei à minha doca para ficar sempre à mão.

Uso Linux desde 2009... Também não sou da área de TI... Sou usuário comum... Internet, músicas, vídeos, fotos, documentos... Mas ao contrário de você nunca tive "problemas avançados"... No máximo um Apt corrompido por um PPA... Ou um Grub perdido após instalar outra distribuição... Ou quando eu me metia a fuçar demais e detonava meu sistema... Mas só faço isso na minha partição de testes... Como diria meu amigo da IBM... Cuidado com o que digita no terminal... Fuçando, corrompendo e aprendendo... Essa é a "vida de linuxer"... Kkkk