OpenSUSE Partição Root cheia. Sistema não inicia boot

battlestoriesfan · Setembro 21, 2023, 2:16pm

Bom dia, pessoal.
Eu encontrei um problema que essencialmente matou meu sistema. Meu computador tem 2 drives e, portando, duas partições: uma partição root em um SSD NVME de 240 gb para o sistema e uma partição home em um HD de 3 TB para meus arquivos. Mas ontem, quando estava jogando, eu comecei a receber notificações que algumas pastas estavam ficando cheias (Pastas como root, boot, var, usr). Eu imediatamente reconheci estas pastas como pastas de sistema, mas achei que isso não fazia sentido, porque eu não instalo programas ou coloco arquivos nas pastas do sistema. Na verdade, eu basicamente deixei a partição do root em paz desde que instalamos a distro, e coloco meus arquivos apenas na partição home, que ainda tem 1 TB sobrando, então eu assumi que estes eram arquivos temporários e que seriam deletados depois de eu reiniciar o computador. Mas ele parou de dar boot, e fica sempre numa tela preta de console.

Fizemos o boot usando uma pendrive Ubuntu e, sim, a partição root Está cheia! Mas não conseguimos saber O QUE Está dando bloat porque o Ubuntu não nos mostra todos os arquivos. Apenas conseguimos saber que o SSD Está cheio porque checamos a partição, pois se checarmos as propriedades das pastas que o ubuntu mostra, ele diz que temos apenas 9 gb de arquivos, não 200 gb. A pasta var, onde em teoria os arquivos de log ficam salvos, Está completamente vazia, e com o boot impossibilitado, não podemos usar o YAST para procurar os logs ou configurar o sistema. Se isto for importante a partição de root Está em 3 pedaços: um pedaço de 629 mb para booting, um pedaço de 34 gb para swap memory e o resto é para o sistema usando BTRFS, que Está 99.8% cheio.

Por que não consigo acessar todos os arquivos root usando o Ubuntu? Isso é um problema do Ubuntu ou da partição usar BTRFS? Onde fica o arquivo de log, uma vez que a pasta var Está vazia? Por que não consigo ver quais arquivos que estão dando bloat? (E QUAIS arquivos de sistema que encheriam 200 gb em uma distro linux??) Não consigo usar o YAST, então O que posso usar? Dá pra resolver este problema?

Captura de tela de 2023-09-21 13-13-04

frc_kde · Setembro 21, 2023, 5:41pm

Rapaz… Você conseguiu!

Esse é motivo pelo qual uso partição BtrFS (com snapshots) unicamente no openSUSE – e mantenho minhas outras distros em partições ext4. – Nunca tive problema com partição BtrFS (desde Janeiro 2017)… mas quando a gente olha “de fora” (a partir de outra distro), não encontra quase nada.

Exemplo: – Partição BtrFS do openSUSE, visto a partir do Arch Linux – pelo Dolphin, como usuário comum:

… ou pelo Midnight-Commander (mc), como super-usuário:

Sei que quase tudo está na pasta /.snapshots (oculta, devido ao ponto no início do nome) – mas o Arch diz que não existe nada por ali. – Só quando carrego o openSUSE, é que as subpastas (instantâneos, ou snapshots) são montadas e aparecem.

Estou aqui tentando imaginar um modo de você contornar esse problema, mas sinceramente, ainda não consegui ter nenhuma ideia luminosa.

Por enquanto, só nos resta aguardar que outros colegas apresentem uma solução.

Enquanto isso…

Esta é uma boa hora, para você ver a importância de configurar algumas coisas e fazer alguma “manutenção regular” – depois que seu openSUSE estiver funcionando outra vez.

Eu costumo usar partições de 30 GiB para cada distro – mas para o openSUSE, fiz uma partição de 50 GiB – o que é apenas 1/5 da sua partição de 240 GB.

A primeira coisa que faço, é monitorar a ocupação das minhas partições, o tempo todo – pelo Conky:

(A partição do Redcore também é maior que as outras. – Aumentei para 60 GiB).

Domingo passado, após minha atualização semanal, a partição do openSUSE estava com 36,1 GiB ocupados – e aproveitei para deletar todos os snapshots de até 7 dias antes (Domingo anterior):

Com isso, a ocupação caiu para 23,3 GiB:

Para facilitar a leitura do que fiz:

# date; snapper ls
Sun 17 Sep 11:47:36 -03 2023
    # | Type   | Pre # | Date                         | User | Cleanup  | Description            | Userdata
------+--------+-------+------------------------------+------+----------+------------------------+--------------
   0  | single |       |                              | root |          | current                |
3747* | single |       | Sun 02 Apr 2023 01:13:59 -03 | root |          | writable copy of #3745 |
3861  | pre    |       | Sun 20 Aug 2023 06:58:39 -03 | root | number   | zypp(zypper)           | important=yes
3862  | post   |  3861 | Sun 20 Aug 2023 06:59:13 -03 | root | number   |                        | important=yes
3864  | pre    |       | Sun 20 Aug 2023 07:09:24 -03 | root | number   | zypp(zypper)           | important=yes
3866  | post   |  3864 | Sun 20 Aug 2023 08:19:20 -03 | root | number   |                        | important=yes
3867  | pre    |       | Sun 27 Aug 2023 20:05:08 -03 | root | number   | zypp(zypper)           | important=yes
3868  | post   |  3867 | Sun 27 Aug 2023 20:05:41 -03 | root | number   |                        | important=yes
3869  | pre    |       | Sun 27 Aug 2023 20:14:05 -03 | root | number   | zypp(zypper)           | important=yes
3870  | post   |  3869 | Sun 27 Aug 2023 20:22:37 -03 | root | number   |                        | important=yes
3871  | pre    |       | Sat 02 Sep 2023 16:52:53 -03 | root | number   | zypp(zypper)           | important=yes
3872  | post   |  3871 | Sat 02 Sep 2023 16:54:35 -03 | root | number   |                        | important=yes
3874  | pre    |       | Sun 03 Sep 2023 13:27:51 -03 | root | number   | zypp(zypper)           | important=yes
3875  | post   |  3874 | Sun 03 Sep 2023 13:40:26 -03 | root | number   |                        | important=yes
3876  | single |       | Sun 03 Sep 2023 14:00:17 -03 | root | timeline | timeline               |
3877  | pre    |       | Sun 10 Sep 2023 12:56:40 -03 | root | number   | zypp(zypper)           | important=yes
3878  | post   |  3877 | Sun 10 Sep 2023 12:57:09 -03 | root | number   |                        | important=yes
3879  | single |       | Sun 10 Sep 2023 13:00:00 -03 | root | timeline | timeline               |
3880  | pre    |       | Sun 10 Sep 2023 13:15:13 -03 | root | number   | zypp(zypper)           | important=no
3881  | post   |  3880 | Sun 10 Sep 2023 13:21:21 -03 | root | number   |                        | important=no
3882  | single |       | Sun 17 Sep 2023 11:00:06 -03 | root | timeline | timeline               |
3883  | pre    |       | Sun 17 Sep 2023 11:19:14 -03 | root | number   | zypp(zypper)           | important=yes
3884  | post   |  3883 | Sun 17 Sep 2023 11:33:06 -03 | root | number   |                        | important=yes
3885  | pre    |       | Sun 17 Sep 2023 11:40:14 -03 | root | number   | zypp(zypper)           | important=yes
3886  | post   |  3885 | Sun 17 Sep 2023 11:40:49 -03 | root | number   |                        | important=yes

# snapper delete --sync 3861 3862 3864 3866 3867 3868 3869 3870 3871 3872 3874 3875 3876 3877 3878 3879 3880 3881
Snapshot '3876' not found.

# snapper delete --sync 3861 3862 3864 3866 3867 3868 3869 3870 3871 3872 3874 3875 3877 3878 3879 3880 3881

(caiu de 36,1 GiB para 23,3 GiB)

# date; snapper ls
Sun 17 Sep 11:54:35 -03 2023
    # | Type   | Pre # | Date                         | User | Cleanup  | Description            | Userdata
------+--------+-------+------------------------------+------+----------+------------------------+--------------
   0  | single |       |                              | root |          | current                |
3747* | single |       | Sun 02 Apr 2023 01:13:59 -03 | root |          | writable copy of #3745 |
3882  | single |       | Sun 17 Sep 2023 11:00:06 -03 | root | timeline | timeline               |
3883  | pre    |       | Sun 17 Sep 2023 11:19:14 -03 | root | number   | zypp(zypper)           | important=yes
3884  | post   |  3883 | Sun 17 Sep 2023 11:33:06 -03 | root | number   |                        | important=yes
3885  | pre    |       | Sun 17 Sep 2023 11:40:14 -03 | root | number   | zypp(zypper)           | important=yes
3886  | post   |  3885 | Sun 17 Sep 2023 11:40:49 -03 | root | number   |                        | important=yes

Mas esta limpeza “manual”, é apenas um “complemento”, que faço de vez em quando, para me sentir confortável.

O principal, é que configurei o snapper para manter o menor número possível de “instantâneos” (snapshots). – Minha configuração atual – arquivo /etc/snapper/configs/root:

# cat /run/media/flavio/Linux1/etc/snapper/configs/root

# subvolume to snapshot
SUBVOLUME="/"

# filesystem type
FSTYPE="btrfs"

# btrfs qgroup for space aware cleanup algorithms
QGROUP=""

# fraction of the filesystems space the snapshots may use
SPACE_LIMIT="0.5"

# fraction of the filesystems space that should be free
FREE_LIMIT="0.2"

# users and groups allowed to work with config
ALLOW_USERS=""
ALLOW_GROUPS=""

# sync users and groups from ALLOW_USERS and ALLOW_GROUPS to .snapshots
# directory
SYNC_ACL="no"

# start comparing pre- and post-snapshot in background after creating
# post-snapshot
BACKGROUND_COMPARISON="yes"

# run daily number cleanup
NUMBER_CLEANUP="yes"

# limit for number cleanup
NUMBER_MIN_AGE="1800"
NUMBER_LIMIT="20"
NUMBER_LIMIT_IMPORTANT="10"

# create hourly snapshots
TIMELINE_CREATE="yes"

# cleanup hourly snapshots after some time
TIMELINE_CLEANUP="yes"

# limits for timeline cleanup
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="2"
TIMELINE_LIMIT_DAILY="1"
TIMELINE_LIMIT_WEEKLY="0"
TIMELINE_LIMIT_MONTHLY="0"
TIMELINE_LIMIT_YEARLY="0"

# cleanup empty pre-post-pairs
EMPTY_PRE_POST_CLEANUP="yes"

# limits for empty pre-post-pair cleanup
EMPTY_PRE_POST_MIN_AGE="1800"

Este bloco limita o número de “snapshots” – e acho que ainda poderar limitar mais um pouco:

# limit for number cleanup
NUMBER_MIN_AGE="1800"
NUMBER_LIMIT="20"
NUMBER_LIMIT_IMPORTANT="10"

Este outro bloco limita o número de outro tipo de “snapshots”:

# limits for timeline cleanup
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="2"
TIMELINE_LIMIT_DAILY="1"
TIMELINE_LIMIT_WEEKLY="0"
TIMELINE_LIMIT_MONTHLY="0"
TIMELINE_LIMIT_YEARLY="0"

Não sou “especialista”, por isso, é provável que eu ainda não esteja fazendo a coisa certa.

Execute man snapper para entender seu funcionamento, ou acesse o Manual aqui.

Veja também o Tutorial.

Deleterium · Setembro 22, 2023, 2:11am

BTRFS é amigão e superpoderoso, menos quando fica lotado… Aí meu amigo, é fogo.

Primeira dica é verificar todos os subvolumes. Verfique quais subvolumes são de snapshots e apague algum, de preferência o mais antigo. Tem um comando para além de apagar o subvolume, aguardar a sincronização (se não usar, o comando será instantâneo mas vc não vai saber quando terminou, a menos que fique monitorando o I/O de disco). Reze para conseguir. Caso consiga, continue até conseguir liberar uns 30% do espaço em disco, reinicie no Suse e configure o snapper adequadamente.

Caso não consiga apagar o subvolume, é porque o sistema entupiu de tão cheio. Nesse caso vc vai precisar aumentar o tamanho do sistema de arquivos adicionando uma segunda partição a ele (btrfs device add). Depois de adicionar mais alguns gigas, siga apagando snapshots até liberar uns 30%. Remova a partição temporária. reinicie no Suse e configure o snapper adequadamente.

BTRFS é muito bom, mas se não estiver bem configurado é chatinho. Pessoalmente eu acho que o padrão pra usuário comum deveria continuar ext4, e deixar btrfs só pra quem quer snapshots, sabe que precisa, monitora e tá disposto a mexer nisso caso dê algum problema.

Luiz_Fernando · Setembro 22, 2023, 3:12am

caraca 12 distros kkkkkkkkj,isso seria um twelve-boot?

anon18465395 · Setembro 22, 2023, 9:31pm

Até porque o ext4 funciona bem com snapshots rsync.

frc_kde · Setembro 22, 2023, 11:36pm

Eu tinha esquecido esta solução:

Ou seja, criar outra partição BtrFS com vários GB, e “adicionar”. – Com isso, o openSUSE volta a ter espaço para carregar.

Então, comece imediatamente a deletar snapshots antigos.

aguamole · Setembro 22, 2023, 11:47pm

Para verificar abrir pastas e arquivos bloqueados tem que ser como root. Você esta tentando fazer tarefas com o file-manager com usuário comum.
O sistema sobe o que não sobe é a DE, pelo console você pode dar a manutenção necessária para liberar espaço se é que é falta de espaço.
E tem quem diz que 30GB é mais que suficiente, estou penando aqui com 90GB.

battlestoriesfan · Setembro 23, 2023, 2:13pm

Não sei ainda como atualizo este tópico, então fica aqui. Eu também postei isso nos forums do OpenSUSE, e ontem me ajudaram a descobrir.

Era um problema de kernel. O kernel que a minha distro estava usando está bichado, e fica criando arquivos de log GIGANTESCOS. Eu tenho 2 arquivos de log (“messages” and “warn”), e ambos juntos tem mais de 100 gb de tamanho. E o sistema ficava criando arquivos de log a uma velocidade ridiculamente rápida. Depois de mudar qual kernel a máquina da boot, o espaço parou de diminuir. Mas agora tenho que tentar remover os dois arquivos gigantes, e o sistema não aparenta que vai permitir.

Rommulo_Peixoto · Setembro 26, 2023, 10:20pm

Olá amigo.
Pode me informar qual é o kernel? Pois estou querendo adotar o openSUSE como minha segunda (ou mesmo primeira) distro, em dual boot com o Void. Meu foco é no desempenho do openSUSE, que lidera em alguns testes aqui do Diolinux.

battlestoriesfan · Setembro 28, 2023, 8:34pm

O kernel que parece estar dando problema é o kernel 5.14.21-150400.24.84.1. Eu estou usando o 5.14.21-150400.24.81.1, e os logos pararam que ficar giantescos.

Rommulo_Peixoto · Outubro 4, 2023, 8:25pm

O openSUSE Tumbleweed Gnome 45, que estou testando, no momento está com kernel 6.5.4-1-default.
Abri o nautilus em modo super-user, habilitei mostrar arquivos ocultos e pesquisei por “messages” e “warn” a partir da raiz “/”. Nenhum dos dois apareceu, e o maior arquivo de log que encontrei foi o zypper.log com 11,1 MB.
Então, parece-me que só o kernel 5.14.21-150400.24.84.1 apresenta essa anomalia.

thespation · Abril 12, 2025, 8:29pm

Este tópico foi fechado automaticamente. Novas respostas não são mais permitidas.