Estou testando um script Python destinado ao uso em sistemas Raspberry Pi para reformatar e copiar informações de partição e dados de partição. Para obter as informações do primeiro dispositivo (geralmente um cartão de memória USB), eu uso:
sfdisk -d /dev/sda >sda_data.txt
Então, para copiar a mesma tabela para a unidade de destino, eu uso:
sfdisk /dev/sdb <sda_data.txt
No geral, funciona como esperado, mas e se eu usá-lo em um disco menor? Por exemplo, digamos que sda1 é uma partição de inicialização no formato msdos e sda2 é uma partição extfs que preenche o restante da unidade. Digamos que o total de dados (exceto comandos e dados de inicialização) seja de cerca de 10 GB em /dev/sda2 e /dev/sda seja de 64 GB.
Meus dados são pequenos o suficiente para que, quando eu copiar os arquivos do dispositivo de 64 GB para um dispositivo menor de 32 GB, haja espaço suficiente no dispositivo menor em /dev/sdb para armazenar todos os dados em um dispositivo menor. Portanto, se o sda for de 64 GB e o sdb for de 32 GB, ainda posso copiar todos os dados que tenho no sda para o sdb.
O problema ou dúvida está na partição do sdb menor.
Quando leio as informações de partição de sda, elas incluem tamanhos de partição e a segunda partição, sda2, será muito maior do que sua nova contraparte, sdb2. Quando uso o despejo de informações em sda_data.txt no sdb, minha experiência é que o sfdisk permite o tamanho menor do dispositivo no sdb e não tenta fazer uma partição muito grande - ele cria uma partição no sdb2 que vai automaticamente para o fim do dispositivo menor.
Esta é a minha experiência. Esse é um comportamento padrão? O sfdisk sempre redimensionará a última partição para o dispositivo menor? Em outras palavras, posso confiar no sfdisk para criar essa partição menor no dispositivo menor? (Isso pressupõe que nenhuma partição seja iniciada após o final do sdb e esteja totalmente fora do espaço nesse dispositivo. Para os propósitos desta discussão, podemos supor que a última partição pode precisar ser reduzida, mas que ainda será será capaz de caber no sdb - só não será em tamanho real.)
A opção dump é mais adequada para replicar exatamente um determinado particionamento.
Não sei dizer o quão confiável é usar o sfdisk com uma receita em que o particionamento não corresponde ao tamanho do dispositivo.
Mas você pode criar facilmente um script sfdisk mais tolerante do zero ou com base em um despejo.
Por exemplo, se eu obtiver o seguinte despejo do sfdisk
Você pode criar um particionamento mais flexível removendo especialmente o caminho do dispositivo, o setor inicial e um dos argumentos de tamanho.
Isso criará quatro partições onde o sfdisk calculará automaticamente as posições iniciais preferidas, expandirá a última partição para preencher o espaço restante (porque não tem tamanho necessário) e criará novos UUIDs para as partições. Se você deseja que as partições tenham os mesmos UUIDs de antes, apenas mantenha o
uuid
argumento do dump.Partes relevantes da página de manual :
Em geral, é possível escrever manualmente scripts sfdisk. Para a configuração de boot + root (observação: qual sistema de arquivos uma partição obterá realmente não importa para o sfdisk), você deve estar bem com algo simples como: