Ошибка загрузки после клонирования диска

Question

У меня была следующая конфигурация разделов на старом диске 160 ГБ:

/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

Я использовал GPart для подготовки нового диска емкостью 500 ГБ с идентичным порядком соответствующих разделов, но разным размером (и 1 дополнительным разделом на и) - я намеревался клонировать их один за другим с помощью 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

До сих пор все работало как положено. Я клонировал старый sda1 в новый sda1 , старый sda2 в новый sda2 и старый sda5 в новый sda5 . Он не был клонирован, загружен, и мне пришлось восстанавливать его вручную с помощью некоторых живых CD:

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

Он правильно обнаружил ядра, которые я установил, а также раздел Windows.

Проблема проявлялась, когда я пытался загрузиться в Debian. Загрузка с новейшим ядром застряла при загрузке, Loading please wait... экран. Загрузка в режиме решения проблем застряла в Running /script/local-premount . Аналогичным образом попытка загрузки Windows заканчивается сообщением о поврежденной установке.

Удивительно, но я могу загрузить Debian, используя старое ядро (в настоящее время на Jessie, предыдущее ядро от Wheezy). Однако в этом случае нельзя смонтировать другой раздел, даже тот, который хранится на другом физическом диске, на который процесс не мог повлиять, поскольку он был одновременно удален с компьютера.

Что может быть источником проблемы? Какую информацию я могу предоставить, чтобы понять это?

РЕДАКТИРОВАТЬ:

Мне удалось узнать, что загрузка новейшего ядра без quiet опции показывает те же результаты, что и режим восстановления. Через некоторое время (несколько минут) я получил еще одно сообщение:

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:

После того, как я нажал Enter, система наконец загрузилась. Однако оказывается, что раздел, в котором он отсутствует, является разделом подкачки:

$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

Где я могу убедиться, что этот раздел действительно используется?

Answer 1

После того, как я клонировал разделы, было несколько неправильных вещей, о которых я ничего не знал.

1. в Linux несколько программ используют UUID устройства вместо нотации /dev/sdX . Фактически, например, в /etc/fstab это рекомендуемый способ. В моем случае это были записи, касающиеся раздела подкачки, в результате инициализирующий скрипт застрял на некоторое время при монтировании, прежде чем сдаться и двигаться дальше.

   С помощью grep -r [UUID] / я нашел все места, где использовался старый раздел подкачки. Я заменил значение на один соответствующий sudo blkid в файлах:

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

   Затем я должен был убедиться, что эти значения находятся в скриптах initrc. Это можно сделать, вызвав их вручную или (в моем случае), удалив и снова установив uswsusp (раздел подкачки также используется для хранения данных гибернации).

   После этого раздел подкачки загрузился правильно и загрузка прошла быстро.

2. в Windows System Restore раздел был клонирован, но не помечен как активный - в результате средства восстановления системы не смогли обнаружить его и исправить установку MBR. Мне пришлось:

   • открытая командная строка (для неизвестной системы),
   • запустить diskpart ,
   • найти правильный диск со list disk и выбрать его с помощью select disk [NUMBER] ,
   • найти правильный раздел с разделом list partition и выбрать его с помощью select partition [NUMBER] ,
   • маркировка текущего раздела как активного с active ,
   • перезагрузите компьютер, снова загрузите System Repair Tools и дайте им все исправить (bootrec /fixmbr и bootrec /fixboot могут пригодиться).

3. Конечно, тем временем я должен был восстановить Grub, потому что я не клонировал его:

   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