Risco de colisão? / var / log preenchido pela ferramenta de reparo, mas real / var localizado na partição separada

Question

Algo deu errado no meu sistema, e usei um dos CDs de inicialização para reparar grub e também eliminar alguns erros nas atribuições de dispositivos. Não é grande coisa, e funcionou um tratamento. Bom.

No entanto, o software de reparo neste CD de inicialização adorava escrever em /var/log/* e a "diversão" começou.

Meu /var está em uma partição separada , enquanto essa ferramenta criou com alegria uma nova árvore /var e a preencheu no meu / (uma vez localizada com uma assinatura válida) . Isso não é bom.

Supondo, eu acabei de desligar o PC depois de consertar e (frio) inicializar na minha própria distro novamente. Isso não pode realmente funcionar, pode? Porque estou ciente de que o sistema precisa de um monte de arquivos informativos de /var durante a inicialização. (Não é usado apenas como um "arquivo de log de despejo" como a maioria dos iniciantes pensam.) Em uma VM, eu tentei isso apenas pela diversão disso há dois anos: o resultado foi que é impossível inicializar com um virgem /var diretório. Nem mesmo a reconstrução da árvore inteira (apenas subdiretórios, mas nenhum arquivo dentro dela) funcionará. Parece haver algo realmente importante que as rotinas de inicialização fazem precisam para alcançar com sucesso a tela de login gráfica.

Então, como isso pode ser evitado se alguma ferramenta criar uma árvore /var/* na sua partição / e não muito depois, o UUID da partição /var é lido pelo sistema e ...? Certa vez eu pensei que a partição /var iria sobrepor o "pseudo- / var" na partição / , mas isso não parece ser o caso. Além disso, isso não é o Windows: ele não é transformado em /var.backup ou /var (2) ou qualquer coisa desse tipo.

/ etc / fstab: (UUIDs "normalizados" por questões de legibilidade)

# /boot on /dev/sda1 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee              /boot    ext4  ro        0  1
# /     on /dev/sda2 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee              /        ext4  defaults  0  2
# /var (NEW) on /dev/sda6 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee              /var     ext4  defaults  0  2
# /home on /dev/sda3 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee              /home    ext4  defaults  0  2
# /usr on /dev/sda5 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee              /usr     ext4  defaults  0  2
# /opt on /dev/sda7 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee              /opt     ext4  defaults  0  2

    

Answer 1

Então, você costumava ter um /var vazio em seu sistema de arquivos raiz, que era usado como um ponto de montagem para o "real / var" que estava localizado em um sistema de arquivos diferente? E quando você iniciou a partir de um ISO, de alguma forma conseguiu criar um monte de subdiretórios em sua "raiz" /var então agora você está preocupado que, após a reinicialização, o sistema não será capaz de montar o seu "real / var "porque o ponto de montagem tem alguns arquivos e diretórios nele?

Eu não acho que você deva se preocupar, o processo de montagem funciona muito bem neste caso. Os arquivos localizados dentro do seu ponto de montagem tornam-se inacessíveis (até você desmontar a partição), e todo o conteúdo do ponto de montagem é "substituído" pelo conteúdo da partição montada.

O único efeito colateral negativo que posso imaginar é que algum espaço em disco será desperdiçado pelos logs que você não precisa, mas, novamente, acho que seria seguro excluí-los.