Um sistema operacional Ubuntu 14.04 funcionará com um Kernel 3.10.3?

Question

Como o sistema de arquivos e o kernel são componentes separados para um sistema embarcado, estou querendo saber se o sistema de arquivos pode ser substituído sem modificar a imagem do kernel? Claro, eu gostaria de nada mais do que atualizar o kernel, mas infelizmente não tem a fonte do kernel e seria muito mais simples se eu pudesse fazer o flash do dispositivo com um novo sistema de arquivos. Eu tenho um sistema de arquivos 14.04 com o qual eu posso fazer o flash do dispositivo e inicializar, mas alguns arquivos precisam ser modificados para nosso caso de uso e toda vez que tento alterar alguma coisa no sistema de arquivos, fico com um kernel panic. Eu suspeito que isso poderia ser um problema introduzido com o un-tarring e tarring do sistema de arquivos (permissões ou propriedade estão sendo alteradas) e eu tentei fazer isso como root e também com o sinalizador de permissões preserve (-p) como sugerido em vários outros Postagens. Eu estou querendo saber se o que estou tentando fazer é mesmo um caminho viável para continuar? O kernel 3.10.3 é compatível com o sistema operacional 14.04.5_LTS?

    

Answer 1

Esta não é a maneira recomendada de lidar com a atualização do sistema operacional, mas às vezes estamos sujeitos a certas restrições que exigem que o façamos. A atualização do sistema de arquivos sem atualizar o kernel funciona nesta instância. Versões posteriores do Ubuntu podem nem sempre ser compatíveis com versões mais antigas do kernel, no entanto. Para verificar a compatibilidade das versões do kernel e do SO, confira o Cronograma de Suporte do Ubuntu .

Como não tenho o sistema de arquivos original usado e nosso hardware é personalizado, criar um sistema de arquivos do zero certamente não é o caminho de menor resistência. Em vez disso, realizei uma atualização de atualização apt-get do dispositivo in-loco e também fiz alterações no arquivo personalizado (algumas correções relacionadas à segurança). Esse método preservou todos os drivers personalizados específicos da nossa placa e componentes.

O sistema de arquivos funcional foi então banido e usado no servidor intermitente. Como o @Amias mencionou, existem algumas configurações específicas do dispositivo que podem causar confusão ao fazer as coisas dessa maneira, então você terá que estar ciente disso. No meu caso, havia um arquivo relacionado à rede gerado após a atualização, que armazenava alguns endereços específicos de hardware para as interfaces de rede. Este arquivo foi /etc/udev/rules.d/70-persistent-net. O resultado do flash de um dispositivo com este arquivo presente no sistema de arquivos era que as interfaces de rede não apareceriam devido a um erro de "dispositivo não encontrado". Os endereços de hardware estavam incorretos no arquivo de configuração. Consegui remover esse arquivo completamente e resolver esse problema.

Também descobri que preservar as permissões e a propriedade dos arquivos originais em todo o processo de transferência de arquivos e tarts era crucial. Certifique-se de executar o comando tar como sudo para preservar a propriedade e usar o sinalizador -p para preservar as permissões. Além disso, se você estiver manipulando o sistema de arquivos em um computador host, o host também deverá ter os mesmos usuários que a máquina de destino para preservar a propriedade dos arquivos.

A solução é um pouco hacky, mas funciona.

    

Answer 2

O sistema de arquivos conterá bibliotecas e configurações necessárias para fazer um dispositivo funcionar. Em um sistema embarcado, isso geralmente é muito limitado por causa de recursos limitados e requisitos de desempenho. Isso significa que eles normalmente têm ferramentas limitadas e esperam layouts de dispositivos e armazenamento muito específicos sem autodetecção.

Às vezes, o sistema embarcado contém drivers não-livres e códigos que são criados apenas para um kernel específico, pois são distribuídos apenas como binários ou de outra forma restrita.

Parte do meu trabalho envolve o teste de dispositivos linux embarcados e ainda não encontrei um que pudesse lidar com kernels de comutação sem acesso ao ambiente de desenvolvimento que o criou e a alguns arranhões de cabeça.

Este é, naturalmente, um grande problema para a segurança e muitos fabricantes se esquecem de sua responsabilidade de continuar atualizando, por isso, tente encontrar dispositivos com toolchains de desenvolvimento aberto e você verá que isso é feito para você.