"Redimensione" o .img para um cartão SD menor. Como SHRINK uma imagem de cartão SD inicializável

Este artigo fornece uma solução que resolve meu problema (*). É bem parecido com o outro, mas explica melhor como calcular e qual o significado dos números e das partições.

A informação chave foi o uso do comando truncate. Seguindo a solução completa para não perder a resposta.

Um passo preliminar consiste em clonar o cartão SD no seu PC:

1. use lsblkpara ver quais dispositivos estão disponíveis e se suas partições estão montadas

2. desmonte todas as partições do dispositivo que você deseja copiar no seu PC. Por exemplo:

    umount /dev/sdc1
    umount /dev/sdc2
   

3. crie uma cópia de todo o cartão SD com todas as partições desmontadas

    dd if=/dev/sdc of=/path/to/file/myimage.img
   

Encolher imagens no Linux

Contexto do problema :

Ter um myimage.imgmaior que o suporte de hardware (se for menor não deve haver problema; porém, usando a mesma estratégia, você pode encaixar melhor a imagem no suporte de hardware).

O segredo é usar ferramentas e instrumentos padrão do Linux: GParted fdiske truncate.

Requisitos :

• Um computador Linux
• O .imgque você deseja reduzir ( myimage.imgneste exemplo)

Criando dispositivo de loopback :

GParted é um aplicativo normalmente usado para gerenciar tabelas de partição e sistemas de arquivos. Para reduzir a imagem, o GParted será usado na primeira parte da resposta.

O GParted opera em dispositivos, não em arquivos simples como imagens. É por isso que primeiro precisamos criar um dispositivo para a imagem. Fazemos isso usando a funcionalidade de loopback do Linux.

Vamos habilitar habilitar o loopback:

sudo modprobe loop

Vamos solicitar um novo dispositivo de loopback (gratuito):

sudo losetup -f

O comando retorna o caminho para um dispositivo de loopback livre:

/dev/loop0

Vamos criar um dispositivo da imagem:

sudo losetup /dev/loop0 myimage.img

O dispositivo /dev/loop0representa myimage.img. Queremos acessar as partições que estão na imagem, então precisamos pedir ao kernel para carregá-las também:

sudo partprobe /dev/loop0

Isso deve nos dar o dispositivo /dev/loop0p1, que representa a primeira partição em myimage.img. Não precisamos desse dispositivo diretamente, mas o GParted o exige.

Redimensione a partição usando GParted :

Vamos carregar o novo dispositivo usando o GParted:

sudo gparted /dev/loop0

Quando o aplicativo GParted for aberto, deverá aparecer uma janela semelhante à seguinte:

Agora observe algumas coisas:

• Há uma partição.
• A partição aloca todo o disco/dispositivo/imagem.
• A partição é preenchida parcialmente.

Queremos redimensionar esta partição para que ela se ajuste ao seu conteúdo, mas não mais do que isso.

Selecione a partição e clique em Redimensionar/Mover. Aparecerá uma janela semelhante à seguinte:

Arraste a barra direita para a esquerda o máximo possível.

Observe que às vezes o GParted precisará de alguns MB extras para colocar alguns dados relacionados ao sistema de arquivos. Você pode pressionar a seta para cima na caixa Novo tamanho algumas vezes para fazer isso. Por exemplo, pressionei 10 vezes (= 10MiB) para que o FAT32 funcionasse. Para NTFS, talvez você nem precise.

Por fim, pressione Redimensionar/Mover. Você retornará à janela do GParted. Desta vez, será semelhante ao seguinte:

Observe que há uma parte do disco não alocada. Esta parte do disco não será usada pela partição, então podemos remover esta parte da imagem mais tarde. GParted é uma ferramenta para discos, por isso não encolhe imagens, apenas partições, temos que fazer o encolhimento da imagem nós mesmos.

Pressione Applyno GParted. Ele agora moverá os arquivos e finalmente reduzirá a partição, de modo que pode levar um minuto ou dois, mas na maioria das vezes termina rapidamente. Depois feche o GParted.

Agora não precisamos mais do dispositivo de loopback, então descarregue-o:

sudo losetup -d /dev/loop0

Rasgando a imagem :

Agora que temos todos os dados importantes no início da imagem, é hora de cortar essa parte não alocada. Primeiro precisaremos saber onde nossa partição termina e onde começa a parte não alocada. Fazemos isso usando fdisk:

fdisk -l myimage.img

Aqui veremos uma saída semelhante à seguinte:

Disk myimage.img: 6144 MB, 6144000000 bytes, 12000000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ea37d

      Device Boot      Start         End      Blocks   Id  System
myimage.img1            2048     9181183     4589568    b  W95 FAT32

Observe duas coisas na saída:

• A partição termina no bloco 9181183 (mostrado em End)
• O tamanho do bloco é de 512 bytes (mostrados como setores de 1 * 512)

Usaremos esses números no restante do exemplo. O tamanho do bloco (512) geralmente é o mesmo, mas o bloco final (9181183) será diferente para você. Os números significam que a partição termina no byte 9181183 512 do arquivo. Depois desse byte vem a parte não alocada. Apenas os primeiros 9181183 512 bytes serão úteis para nossa imagem.

Em seguida, reduzimos o arquivo de imagem para um tamanho que possa conter apenas a partição. Para isso vamos usar o truncatecomando (obrigado uggla!). Com o comando truncate precisa fornecer o tamanho do arquivo em bytes. O último bloco foi 9181183 e os números de bloco começam em 0. Isso significa que precisamos de (9181183+1)*512 bytes. Isso é importante, caso contrário a partição não caberá na imagem. Então agora usamos truncate com os cálculos:

truncate --size=$[(9181183+1)*512] myimage.img

(*) parece que o post original de FrozenCow foi movido para aqui .

Você pode usar as opções bse countno ddcomando - para limitar o tamanho do arquivo de saída.

Exemplo:

dd if=sdx of=SD.img bs=1G count=4

resultaria em um arquivo de saída com um tamanho de 4 GiB.

Dê uma olhada profunda em man dd.

Você precisaria saber quantos bytes você precisa copiar para que todas as partições sejam totalmente cobertas, então dê uma olhada em sudo fdisk -l /dev/sdxqual setor é o último que você precisa.

As partições precisam estar no início do disco (como na imagem que você forneceu).

Discos com tabela de partição msdos podem ser clonados facilmente desta forma, mas se o disco usa GPT e deve ser clonado em um disco com tamanho diferente, o MBR protetor precisa ser adaptado posteriormente e o backup GPT que reside no próprio final do disco precisa ser recriado, isso pode ser feito com gdisk.

A partir do seu fdisk-output, você pode ver que o último setor da última partição é o setor 8595455, o que significa que você deve copiar pelo menos 8595455+1 setores (o primeiro setor é 0). Com um tamanho de setor de 512 bytes, isso é igual a 4.400.873.472 bytes. bsmultiplicado por counttem que ser maior ou igual a isso.

Talvez isso ainda seja muito grande para um pendrive de 4 GB, você ainda pode reduzir o tamanho do sdc2, há muito espaço não utilizado nele.

Para o exemplo atual que você forneceu,

 dd if=/dev/sdc of=SD.img bs=10M count=420

cobrirá a tabela de partições sdc1e sdc2. Calcular:

10*1024*1024*420 = 4,404,019,200 > 4,400,873,472

resize2fstambém pode ser usado para redimensionar isso.

sudo resize2fs -fp SD.img 4G

Ele também redimensiona o próprio arquivo!

A resposta selecionada se aplica perfeitamente ao tipo disklabel dos . Para o tipo GPT , é preciso considerar a adição de 33 setores, pois o GPT armazena uma tabela também no final do disco.

Portanto, para usuários do GPT, os comandos 'truncate' precisam ser assim:

truncate --size=$[( End_of_last_partition + 1 + 33 )*512] myimage.img

Isso deve produzir um erro GPT em fdisk -l. Para corrigir isso, execute o seguinte:

gdisk myimage.img

Execute o comando para verificar o disco: v. Você deve ver alguns erros encontrados no disco.

"No gdisk, você digitaria x para entrar no menu de especialistas, depois digitaria e para mover os dados da tabela de partição de backup para a nova extremidade do disco e, em seguida, digitaria w para gravar as alterações no disco." [Fonte] como truncar um arquivo de imagem de disco de espaço não utilizado sem corromper a tabela de partição GPT (ponteiro final) - Obrigado!

Examinei muitos dos métodos aqui e entendi todos eles, mas as etapas eram algo que eu não estava ansioso para fazer ao ter que executá-las para simplesmente reduzir um arquivo IMG do Raspberry Pi. Então, procurando, me deparei com esse script Bash de um projeto chamado PiShrink .

Foi bastante trivial de executar e funcionou no meu MacOS M1 Mac Mini para inicializar.

História de fundo

No meu caso particular, eu tinha 2 cartões SD de 32 GB e, por qualquer motivo, 1 era ligeiramente (~ 95 MB) menor que o outro e balenaEtcher se recusou a escrever o IMG do que parecia ser o maior dos 2 cartões SD para o menor.

Eu sabia que estava usando apenas ~ 10 GB dos 32 GB para poder reduzir o arquivo IMG para caber.

Passos

To start I had the following files. The .zip file contained the .img file but I'm showing it unzipped from it below.

$ ls -lh | grep -E 'img|zip'
-rw-r--r--  1 root staff  28G Jan 29 13:16 backup.zip
--w--wx-w-  1 slm  staff  30G Jan  1  1980 disk.img

I then downloaded the PiShrink shell script and made it executable:

$ wget https://raw.githubusercontent.com/Drewsif/PiShrink/master/pishrink.sh
$ chmod +x pishrink.sh

I then ran it like so:

$ sudo pishrink disk.img pi.img
Copying disk.img to pi.img...
e2fsck 1.44.0 (7-Mar-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
STORAGE: 69402/7684096 files (0.2% non-contiguous), 9562823/30732288 blocks
resize2fs 1.44.0 (7-Mar-2018)
resize2fs 1.44.0 (7-Mar-2018)
Resizing the filesystem on /dev/disk4s2 to 9273700 (1k) blocks.
Begin pass 2 (max = 245358)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 3752)
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 3420)
Updating inode references     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/disk4s2 is now 9273700 (1k) blocks long.

"disk4" ejected.
fdisk: could not open MBR file /usr/standalone/i386/boot0: No such file or directory
Enter 'help' for information
fdisk: 1>          Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 2: 83 1023   3  32 - 1023 254   2 [   1056768 -   61464576] Linux files*
Partition id ('0' to disable)  [0 - FF]: [83] (? for help) Do you wish to edit in CHS mode? [n] Partition offset [0 - 62521344]: [1056768] Partition size [1 - 61464576]: [61464576] fdisk:*1> Writing MBR at offset 0.
fdisk: 1> Shrunk pi.img from 30G to 9.3G

The resulting IMG file is now ~9GBs.

$ ls -lh | grep -E 'img|zip'
-rw-r--r--  1 root staff  28G Jan 29 13:16 backup.zip
--w--wx-w-  1 slm  staff  30G Jan  1  1980 disk.img
--w---x---  1 root staff 9.4G Jan 29 17:04 pi.img

I then repackaged it as a ZIP file just so that it was kept in the most efficient size possible while dealing with it on disk.

$ sudo zip pi.zip pi.img

We now have the following set of files kicking around:

$ ls -lh | grep -E 'img|zip'
-rw-r--r--  1 root staff  28G Jan 29 13:16 backup.zip
--w--wx-w-  1 slm  staff  30G Jan  1  1980 disk.img
--w---x---  1 root staff 9.4G Jan 29 17:04 pi.img
-rw-r--r--  1 root staff 8.3G Jan 29 17:08 pi.zip

I can then use balenaEtcher or ApplePi-Baker to burn the ZIP file to the "smaller" SD card.

Poking at the SD card on my Mac I can see it's showing ~10GB.

$ diskutil list /dev/disk4
/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *31.9 GB    disk4
   1:             Windows_FAT_32 LIBREELEC               536.9 MB   disk4s1
   2:                      Linux                         10.0 GB    disk4s2
                    (free space)                         21.3 GB    -

NOTE: I could do the same commands from a Linux system using lsblk etc..

Post Ops

Eu notei depois de usar o método acima que o sistema de arquivos no cartão SD estava com 32 GB completos. Principalmente mostrou assim:

$ df -h | grep -E "File|mmc"
Filesystem                Size      Used Available Use% Mounted on
/dev/mmcblk0p1          511.7M    141.7M    370.0M  28% /flash
/dev/mmcblk0p2            8.6G      8.2G    377.4M  96% /storage

Isso deve ser facilmente resolvido expandindo o sistema de arquivos SD de dentro depois de inicializá-lo.

Para iniciar isso, primeiro uso partedpara estender a partição:

$ parted /dev/mmcblk0 resizepart 2 100%
Warning: Partition /dev/mmcblk0p2 is being used. Are you sure you want to
continue?
Yes/No? yes
yes
Information: You may need to update /etc/fstab.

Então reiniciei o sistema:

$ reboot

Depois que eu online expandi o sistema de arquivos usando resize2fs:

$ resize2fs /dev/mmcblk0p2
resize2fs 1.45.6 (20-Mar-2020)
Filesystem at /dev/mmcblk0p2 is mounted on /storage; on-line resizing required
old_desc_blocks = 71, new_desc_blocks = 234
The filesystem on /dev/mmcblk0p2 is now 30638592 (1k) blocks long.

E agora mostra todo o espaço livre no cartão SD:

$ df -h | grep -E "File|mmc"
Filesystem                Size      Used Available Use% Mounted on
/dev/mmcblk0p1          511.7M    141.7M    370.0M  28% /flash
/dev/mmcblk0p2           28.3G      8.2G     20.1G  29% /storage