Falha ao inicializar após a clonagem de disco

Question

Eu tinha a seguinte configuração de partições no antigo disco de 160 GB:

/sda
  /sda1 - 100MB  - NTFS - System Recovery (hidden Windows partition)
  /sda2 - 75GB   - NTFS - Windows
  /sda3 - extended partition
    /sda5 - 75GB - EXT4 - Debian
    /sda6 - 8GB  - swap - swap partition

Eu usei o GPart para preparar um novo disco de 500 GB com ordem idêntica de partições correspondentes, mas tamanho diferente (e uma partição adicional na e) - Eu pretendia cloná-las uma a uma com o Clonezilla:

/sda
  /sda1 - 100MB   - NTFS - System Recovery (hidden Windows partition)
  /sda2 - 160GB   - NTFS - Windows
  /sda3 - extended partition
    /sda5 - 160GB - EXT4 - Debian
    /sda6 - 32GB  - swap - swap partition
    /sda7 - 110GB - NTFS - additional partition

Até agora tudo funcionou como esperado. Eu clonei o antigo sda1 no novo sda1 , o antigo sda2 no novo sda2 e o antigo sda5 no novo sda5 . Não foi clonado bootloaded e eu tive que restaurá-lo manualmente com algum CD ao vivo:

mount /devsda5 /mnt
--bind /dev /mnt/dev
--bind /proc /mnt/proc
--bind /sys /mnt/sys
chroot /mnt
grub-install /dev/sda5
update-grub

Detectou corretamente os kernels que eu havia instalado, bem como a partição do Windows.

Problema manifestado quando tentei inicializar no Debian. A inicialização com o kernel mais recente ficou presa na tela Loading please wait... . A inicialização no modo de resolução de problemas ficou travada em Running /script/local-premount . Da mesma forma, tentar inicializar o Windows termina com uma mensagem sobre a instalação corrompida.

Surpreendentemente eu sou capaz de inicializar no Debian usando o kernel antigo (atualmente no kernel anterior do Jessie do Wheezy). No entanto, neste caso, nenhuma outra partição pode ser montada, mesmo aquelas que são armazenadas em outra unidade física, que não poderiam ser afetadas pelo processo, uma vez que foram removidas do computador por vez.

Qual poderia ser a fonte do problema? Quais informações eu poderia fornecer para ajudar a descobrir?

EDITAR:

Eu consegui aprender que a inicialização do kernel mais novo sem a opção quiet mostra os mesmos resultados que o modo de recuperação. Depois de esperar algum tempo (vários minutos), recebi outra mensagem:

Begin: Running /scripts/local-premount ... resume: Could not stat the resume device file: '/dev/disk/by-uuid/[uuid]'
        Please type in the full path name to try again
        or press ENTER to boot the system:

Depois que eu apertei enter entrou finalmente no sistema. No entanto, a partição que falta é a partição swap:

$cat /proc/meminfo | grep Mem # I have 8GBs of RAM
MemTotal:        8154632 kB
MemFree:         1367032 kB
MemAvailable:    4750344 kB
$ cat /proc/swaps
Filename                Type        Size    Used    Priority
/dev/sda6                               partition   33554428    0   -1

Onde posso ter certeza de que a partição é realmente usada?

    

Answer 1

Houve várias coisas erradas depois que eu clonei partições, nenhuma das quais eu sabia.

1. no Linux, vários programas dependem do UUID do dispositivo em vez da notação /dev/sdX . Como uma questão de facto em p. /etc/fstab é o caminho recomendado. No meu caso, que eram entradas relativas à partição swap, como resultado, o script de inicialização ficou preso na montagem por um tempo antes de desistir e seguir em frente.

   Com grep -r [UUID] / , encontrei todos os locais em que a partição swap antiga era usada. Eu substituí o valor por um sudo blkid em arquivos:

   /etc/blkid.tab                # swap partition
   /etc/uswsusp.conf             # hibernation device
   /var/cache/debconf/config.dat
   /etc/initramfs-tools/conf.d/resume
   

   Então eu tive que me certificar de que esses valores caíssem em scripts initrc. Isso pode ser feito chamando-os manualmente ou (no meu caso) desinstalando e instalando uswsusp novamente (a partição swap também é usada para armazenar dados de hibernação).

   Depois que a partição swap foi carregada corretamente e a inicialização foi rápida.

2. na partição Windows System Restore foi clonada mas não está marcada como ativa - como resultado, as Ferramentas de Reparo do Sistema não puderam detectá-la e corrigir a configuração do MBR. Eu tive que:

   • abrir linha de comando (para sistema desconhecido),
   • executar diskpart ,
   • calcule o disco direito com list disk e selecione-o com select disk [NUMBER]
   • descubra a partição correta com list partition e selecione-a com select partition [NUMBER]
   • marcando a partição atual como ativa com active ,
   • reinicie, carregue novamente as ferramentas de reparo do sistema e deixe que elas corrijam tudo ( bootrec /fixmbr e bootrec /fixboot podem ser úteis).

3. Claro que tive que restaurar o Grub porque não o copiei:

   mount /dev/sda5 /mnt
   mount --bind /dev /mnt/dev
   mount --bind /proc /mnt/proc
   mount --bind /sys /mnt/sys
   chroot /mnt
   grup-install /dev/sda5
   update-grub