lddno Linux fornecerá a lista de todas as bibliotecas compartilhadas das quais um determinado binário depende. Geralmente, isso é muito mais extenso do que as bibliotecas listadas na linha de comando do vinculador usada para criar o binário: incluirá a maioria, senão todas, as dependências dessas bibliotecas.
É possível determinar apenas a lista de bibliotecas que foram vinculadas explicitamente (ou seja, as dependências diretas) e, em caso afirmativo, como?
Eu tenho uma instalação root-on-zfs herdada que já foi feita instalando em um ext4 / com /boot em uma partição ext4 separada e, em seguida, movendo o conteúdo de / para um pool ZFS.
Eu tive várias instalações *BSD no mesmo disco, o que nunca causou nenhum problema, mas agora estou pensando em fazer uma instalação do Devuan em uma partição não utilizada. Para ser mais preciso: copie uma instalação já configurada de outra máquina (que usa XFS) para um novo pool na partição em questão.
Vou seguir a abordagem com um /boot em sua própria partição e acho melhor não usar um único /boot para ambas as distros. Então, duas partições /boot.
Nunca fiz isso antes, nem mesmo sem o ZFS na equação. Como isso funcionará com o grub, esp. dado que serão 2 versões diferentes e cada distro em algum momento desejará gerar uma nova configuração do grub? Ele descobrirá qual partição de inicialização combina com qual pool com base na correspondência dos kernels (na inicialização) com os módulos do kernel (no pool) ou terei que verificar a concordância manualmente (em grub.cfg) após cada atualização do grub ? Vejo que grub.cfg apenas faz referência ao UUID da partição que contém/boot, além do nome do pool como argumento do kernel.
FWIW, a máquina em que isso estaria tem suporte UEFI, mas não parece me dar a opção de inicializar a partição EFI (no rEFInd, por exemplo), possivelmente porque o gerenciador de inicialização grub também está instalado.
Eu não teria problemas em ter que passar por alguns obstáculos para inicializar a distribuição secundária.
Tenho rastreado o repositório de firmware upstream do Linux em /lib/firmwarealgumas máquinas, fazendo atualizações periódicas dessa árvore.
Acho que vi um erro de carregamento de firmware ao inicializar um kernel antigo na máquina onde fiz um git-pull na semana passada.
Esse repositório tem uma política sobre compatibilidade retroativa com kernels mais antigos ou isso não é um problema (por exemplo) porque tudo o que o kernel faz é carregar um arquivo binário no dispositivo de destino usando uma interface padrão que provavelmente não mudou desde um longo tempo?
Fiz uma VM TrueOS no VirtualBox, usando um vmdk que virtualiza uma partição física do disco rígido (sda5) como um disco completo. Como resultado, agora tenho uma tabela de partição GPT/GUID nessa partição sda5 (sda possui uma tabela de partição GPT/GUID).
Posso ver essa tabela de partições quando crio um dispositivo de loopback ( losetup /dev/sda5 /dev/loop0) no host, mas ainda não descobri como criar os dispositivos /dev/loop0p1, /dev/loop0p2 etc. para montar as partições em /dev /loop0.
Isso é possível? Poderia estar relacionado ao parâmetro max_part do módulo de dispositivo de loop? FWIW, o módulo de loop está embutido no meu kernel e /sys/module/loop/parameters/max_part retorna 0 ... posso alterar esse valor sem reiniciar?