[FUG-BR] Cuidado na atualização no/pro FreeBSD 12 (problema, descrição e solução)

[Otacílio]

Em 05/06/2017 11:23, Joao Rocha Braga Filho escreveu:
> Em 5 de jun de 2017 11:03 AM, "Paulo Henrique" <paulo.rddck em bsd.com.br>
> escreveu:
>
> Em 5 de junho de 2017 10:37, Joao Rocha Braga Filho <goffredo em gmail.com>
> escreveu:
>
>> Em 5 de jun de 2017 2:17 AM, "Paulo Henrique" <paulo.rddck em bsd.com.br>
>> escreveu:
>>
>> Em 5 de junho de 2017 00:01, Joao Rocha Braga Filho <goffredo em gmail.com>
>> escreveu:
>>
>>> Oi pessoal.
>>>
>>> Eu uso no meu desktop o FreeBSD 12 e tive um problema para atualizar
> ele.
>>> Depois que subi o kernel em monousuário para instalar o resto do sistema
>>> tudo
>>> o que eu fazia dava chamada ilegal de system call. Até o /bin/sh dava
>> este
>>> erro.
>>> Fiquei meio empacado.
>>>
>>> Dei boot com o kernel anterior e fui fazer um make installworld, e mesma
>>> coisa.
>>>
>>> Alguma coisa importante mudou nas system calls.
>>>
>>> Depois de ficar empacado, e um pouco de RTFM, achei o que era e como
>>> contornar.
>>>
>>> O que aconteceu, e a solução, estão descritos no arquivo
>> /usr/src/UPDATING,
>>> na anotação feita em 20170523 (23/05/2017). O FreeBSD aumentou o limite
>>> de arquivos e diretórios que um sistema de arquivo poderia ter, de um
>>> número
>>> muito grande para um número grande para ca... ca... caramba, trocando a
>>> representação de i-nodos para 64 bits, o que teve que mudar algumas
>> system
>>> calls, gerando uma incompatibilidade.
>>>
>>> Para contornar, e poder fazer a atualização do sistema, foi criada a
>> opção
>>> de
>>> kernel COMPAT_FREEBSD11 que tem que ser colocada no seu arquivo de
>>> configuração do kernel antes de compilar ele.
>>>
>>> options COMPAT_FREEBSD11
>>>
>>> Ela faz com que os formatos de chamada de system calls que envolvam
>> i-nodos
>>> sejam aceitas no formato de i-nodo anterior.
>>>
>>> Aparentemente, depois do sistema instalado, ela possa ser eliminada, mas
>>> não
>>> quero experimentar isto agora.
>>>
>>> Um efeito colateral é que agora o meu kernel antigo, o que usei para me
>>> salvar
>>> quando deu problema, não deve mais aceitar todo o resto que está
>> instalado.
>>> É uma forte suspeita, e não estou afim de testar isto agora.
>>>
>>> Achei que é uma mudança importante, que afetará quem faz atualização, e
>> que
>>> me fez penar, então resolvi compartilhar para que outros não penem.
>>>
>>> E acho que ter mais de 4 bilhões de arquivos e diretórios em um sistema
>> de
>>> arquivos algo extraordinariamente difícil, mas quem sabe no futuro,
> daqui
>> a
>>> 10 anos. Eu comparo com UFS2, que superou o limite de 2 TB de um sistema
>>> de aquivos. Isto faz mais de 10 anos, creio eu, e agora tenho discos de
> 4
>>> TB
>>> no meu desktop e de backup.
>>>
>>>
>>> Abraços a todos,
>>>      João Rocha.
>>>
>>> --
>>> "Sempre se apanha mais com as menores besteiras. Experiência própria."
>>>
>>> http://jgoffredo.blogspot.com
>>> goffredo em gmail.com
>>> -------------------------
>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>>
>> Agradecemos a dica João !!
>>
>> O lance de arquivos em um unico diretório não é com relação a arquivos de
>>
>>
>> Em único sistemas de arquivos.
>>
>> usuários, mais sim arquivos de configurações e dependências de aplicações.
>>
>> o ~/.cache por exemplo é facil ter ele com mais de 1G de arquivos.
>>
>>
>> Faz sentido. E cache de squid, por exemplo.
>>
>>
>>
> Não é o cache do Squid, embora realmente ele pode chegar a isso fácil,
> coloco com relação ao cache do KDE, Firefox, que costumam manter muito
> cache de navegação.
>
>
> Tenho a impressão que o Chrome é por. Se tiver problema no sistema de
> arquivos ele pode causar um Panic.
>
>
> João.
>
>
> Att.
>


Rolou este e-mail sobre este assunto na lista current tem pouco tempo.

https://lists.freebsd.org/pipermail/freebsd-current/2017-May/066136.html

[]'s
-Otacilio