Estou usando o Ubuntu (Ubuntu 16.04.4 LTS com um kernel 4.4.113) em um dispositivo embarcado e vejo apenas uma entrada no fstab
/dev/mmcblk0p7 / ext4 errors=remount-ro,noatime,nodiratime 0 1
quando eu verifico as partições montadas usando o comando "mount", vejo muitas partições montadas. Agora, a partição em questão que foi montada automaticamente de alguma forma é
/dev/mmcblk0p5 on /lib/modules type ext4 (ro,relatime,data=ordered)
Não consigo descobrir como foi montado quando não há entrada em / etc / fstab?
O Ubuntu 16.04 usa systemd , que pode montar sistemas de arquivos para você. O Ubuntu atualmente não usa mais /etc/fstab da maneira tradicional, quando o sistema é inicializado systemd verificará cada linha em /etc/fstab e criará um serviço mount systemd para cada entrada.
Você deve ser capaz de executar systemctl status *.mount para ver o status de cada montagem que o systemd está gerenciando.
Então você tem o Ubuntu, mas com algum script de inicialização personalizado.
Eu acho que a montagem provavelmente foi iniciada por algum arquivo .service em /etc/systemd/system/ . (Com base em outros comentários, parece que você não tem um arquivo .mount para ele - ou seja, você não tem nenhum arquivo lib-modules.mount ).
Mas a montaria pode ser iniciada em vários outros lugares. Também poderia estar em um arquivo .service em /lib/systemd/system , que teria muitos arquivos que você teria que examinar. Eles podem executar mount indiretamente executando um script separado, portanto, não é garantido que um grep mount *.service rápido encontre o que você está procurando.
Ou talvez o seu fornecedor tenha documentado suas modificações personalizadas em sua imagem "Ubuntu" incorporada.
Caso contrário, há um conjunto de métodos para pesquisar arquivos modificados / criados que não vieram do Ubuntu.
.deb packages instalados sem uma fonte apt Para procurar pacotes .deb que foram instalados diretamente sem uma fonte, execute aptitude search ?obsolete . (Isso também mostrará se um pacote foi instalado a partir de uma fonte apt, mas não está mais disponível na fonte apt. Esses pacotes seriam considerados "obsoletos").
- link
Se você encontrar alguns nomes de pacotes suspeitos, poderá listar seus arquivos. Por exemplo. para um pacote instalado foo, execute dpkg-query -L foo ). Vice-versa, se você encontrou um arquivo suspeito e deseja inestigar o pacote que o possui, execute dpkg-query -s /path/to/file .
Para procurar pacotes instalados a partir de uma fonte habilitada do apt, que se anuncia como algo diferente do Ubuntu, você pode executar aptitude search '?narrow(?installed, !?origin(Ubuntu))!?obsolete' .
Você também pode verificar a advertência examinando primeiro a lista de suas origens, com apt-cache policy . A origem de uma fonte é mostrada como o=Ubuntu .
- link
Para fins de comparação, em 16.04, fontes oficiais padrão podem ser parecidas com estas:
'' '
Repos principais do Ubuntudeb link xenial principal universo restrito multiverso
Repos de Atualização do Ubuntudeb link xenial-security principal universo restrito multiverso deb link xenial-updates principal universo restrito multiverso '' '
(É difícil encontrar um bom documento para eles, então eu os peguei do popular utilitário, link ).
Ou o contrário: para pesquisar as fontes associadas a um pacote suspeito foo, execute apt-cache policy foo
Para verificar modificações em arquivos de pacotes instalados (existem razões muito boas para não modificá-los, mas é uma possibilidade), instale debsums e execute debsums -c .
- link
É possível fazer o script de uma busca por arquivos que foram criados por algo diferente do pacote apt gerenciado. Isso quase certamente mostrará alguns alarmes falsos. Eu procurei um script de exemplo para esse propósito:
(
export LC_ALL=C
comm -23 <(find /etc /lib /bin /sbin /usr -type f | sort) \
<(sort -u /var/lib/dpkg/info/*.list)
)
Mas se houver muito ruído, talvez seja melhor tentar o comando cruft , que aparentemente faz o mesmo, mas conhece alguns arquivos que podem ser ignorados com segurança. cruft -d "/etc /lib /bin /sbin /usr" --ignore "/usr/local" .
A lista de diretórios pesquisados aqui é um pouco de julgamento. Espera-se que / etc, / usr e / lib cubram os scripts de inicialização na maioria dos sistemas Ubuntu, por exemplo qualquer configuração systemd ou scripts sysvinit. Observe que, no seu caso, você deseja encontrar um script de inicialização muito /lib/modules precisa ser feita muito cedo, então os módulos do kernel podem ser carregados a partir dela. Ele precisa ser montado antes que udev seja iniciado.
(Por outro lado, isso levanta a possibilidade de haver algum hack horrível no initrd. Então, acho que esteja atento a modificações ou substituição do gerador initrd - acho que é chamado initramfs-tools ).
Muito obrigado a Raphaël Hertzog, por escrever a série muito útil de posts que estão ligados nesta resposta.