Linux не загружается после переноса

РЕШЕНО: Не грузится Kubuntu копированный Clonezillo`й с SSD на NVME

Доброго времени суток уважаемому Сообществу. Суть проблемы изложена в сабже. Kubuntu 18.04 была копирована с помощью Clonezilla с SSD на NVME в режиме клонирования диска. Затем исходный SSD был отключен. BIOS увидел новую систему, определил NVME как загрузочный, GRUB показал варианты загрузки. А дальше, после выбора первого варианта в меню GRUB`а — чёрный экран. Никаких сообщений об ошибке или т.п. Просто не происходит загрузка системы. Светодиод активности — тоже молчит. В интернетах покопался, но везде вариант Clonezilla указывается как абсолютно беспроблемный. Кстати, так и было до сих пор. Переношу рабочую, настроенную систему уже не первый раз и всегда всё было просто… А с таким сталкиваюсь впервые. Подскажите где искать проблему. Заранее благодарен. З.Ы. Вопрос решил простой переустановкой системы на свежую версию. С переносом прежней системы — колупался почти до рассвета. Главная проблема — ни один LiveCD не хотел монтировать nvme. Ошибки выдавались самые разнообразные, вплоть до bad option, bad file system и badblock… Поскольку раздел /home сидит на отдельном SSD, после установки свежей системы никаких проблем не возникло. Большое спасибо всем за советы. Узнал для себя много нового. Отдельное спасибо Программисту из Екатеринбурга 🙂 Респектище тебе чувак. Буду в твоих краях — поставлю тебе пивас, или что сам выпить пожелаешь 🙂

А загрузчик переустановить, нет? Поправить /etc/fstab ?

На ноутбуке, кстати, BIOS-CSM или UEFI режим загрузки?

Стационарный комп. Включена UEFI. SSD работал с ней же, поэтому не стал ничего трогать при клонировании. Про переустановку загрузчика и правку /etx/fstab — с чего лучше начать?

Проверь, что в /etc/fstab совпадает UUID разделов.

Через chroot перегененируй конфиг grub.

В случае uefi нужно будет ещё поправить файл конфига рядом с efi образом grub на efi system partition, в котором указывается откуда подгружать основной конфиг.

И возможно, нужно перкгенерировать initramfs, чтобы в нем были драйверы (модули) для доступа к nvme диску.

1. Сверка uuid и правка /etc/rstab;
2. Перегенерации grub.cfg и правка конфига груб, в котором указывается откуда грузить основной конфиг.
3. Переустановка efi образа grub и прописывание его в efivars, либо переименовывание его в bootx64.efi.

Загрузись с флешки и сделай как говорит астронавт.

Если не сможешь самостоятельно, скопируй сюда содержимое fstab и выхлоп sudo fdisk -l . Для начала можешь просто sudo update-grub попробовать, может прокатить (с efi не прокатит, инструкция ниже).

WitcherGeralt ★★ ( 21.08.20 22:45:31 MSK )
Последнее исправление: WitcherGeralt 21.08.20 22:50:20 MSK (всего исправлений: 1)

Сложно это для меня 🙁 Скажите, а есть ли смысл в «переезде» с sATA SSD на NVME?

Вот инструкция по восстановлению grub, смотри секцию «Восстановление используя chroot». Не ссы, ничего сложного.

Спасибо за советы и поддержку 🙂 Ушёл пробовать. Мне, чтобы nvme воткнуть — полкомпа разобрать надо. О результатах отпишусь.

Ты скопировал, не смог загрузиться, вытащил, загрузился с SATA-носителя, написал сюда, а сейчас хочешь по второму кругу?

Немного не так… Сейчас я подключил рабочий SSD, с которого копировал систему, и загрузился с него. Не отключая NVME.

Теперь сперва проверю содержимое fstab

/ was on /dev/sda3 during installation

UUID=bc214833-d0f3-4849-b7e0-bff3b79f0e82 / btrfs defaults,subvol=@ 0 1

/boot/efi was on /dev/sda1 during installation

UUID=0378-1E80 /boot/efi vfat umask=0077 0 1

/home was on /dev/sdb1 during installation

UUID=bed99606-a0a7-4fcc-81f5-93123dd6dcef /home btrfs defaults,subvol=@home 0 2

swap was on /dev/sda2 during installation

UUID=705936c6-fe57-442e-8f1f-12d0764d80f7 none swap sw 0 0 /dev/sdc1 /media/data btrfs defaults 1 2 /dev/sdd1 /media/multimedia btrfs defaults 1 2

Кстати — вообще божественно получилось: разделы swap и efi подтянулись с nvme, а загрузка произошла с ssd. Я так полагаю, что нужно в fstab таки прописать uuid раздела root на nvme — и будет мне счастье?

Ты же таблицу разделов склонировал? По логике уиды должны быть одинаковые. Это легко проверить с помощью fdisk .

Скорее всего достаточно обновить конфиг grub. UPD. Старый носитель я бы прр этом отключил, ибо при одинаковых уидвх поведение непредсказуемо. По крайней мере я не в курсе, что из этого может получиться.

WitcherGeralt ★★ ( 21.08.20 23:30:13 MSK )
Последнее исправление: WitcherGeralt 21.08.20 23:35:56 MSK (всего исправлений: 2)

Таблица разделов — клонирована. UUID — разные. fstab вообще показывает, что у меня swap и efi на одном устройстве, а root — на другом. Хотя изначально они все втроём на одном сидят. Значит GRUB просто находит root на том устройстве, где ему указано искать в BIOS, а остальные разделы подтаскивает с того устройства, которое установлено в приоритетный для загрузки слот NVME. Следовательно, нужно GRUB`у указать, что ВСЕ разделы нужно искать на одном устройстве. Вообще, как я полагаю, проблема возникла именно из-за того, что устройство, на которое клонирована система, подключено к другому разъёму.

Старый носитель я отключаю при операциях с новым. Обновление конфига GRUB`а — делать по-инструкции выше?

Выхлоп fdisk -l

Диск /dev/nvme0n1: 238,5 GiB, 256060514304 байт, 500118192 секторов Единицы: секторов по 1 * 512 = 512 байт Размер сектора (логический/физический): 512 байт / 512 байт Размер I/O (минимальный/оптимальный): 512 байт / 512 байт Тип метки диска: gpt
Идентификатор диска: DBC2AB35-1E0E-447D-803F-8F0143B5ACF5

Устр-во начало Конец Секторы Размер Тип
/dev/nvme0n1p1 2048 999423 997376 487M EFI
/dev/nvme0n1p2 999424 17000447 16001024 7,6G Linux своп
/dev/nvme0n1p3 17000448 234440703 217440256 103,7G Файловая система Linux

Диск /dev/sda: 111,8 GiB, 120034123776 байт, 234441648 секторов Единицы: секторов по 1 * 512 = 512 байт Размер сектора (логический/физический): 512 байт / 512 байт Размер I/O (минимальный/оптимальный): 512 байт / 512 байт Тип метки диска: gpt Идентификатор диска: DBC2AB35-1E0E-447D-803F-8F0143B5ACF5

Устр-во начало Конец Секторы Размер Тип /dev/sda1 2048 999423 997376 487M EFI /dev/sda2 999424 17000447 16001024 7,6G Linux своп /dev/sda3 17000448 234440703 217440256 103,7G Файловая система Linux

Диск /dev/sdb: 447,1 GiB, 480103981056 байт, 937703088 секторов Единицы: секторов по 1 * 512 = 512 байт Размер сектора (логический/физический): 512 байт / 512 байт Размер I/O (минимальный/оптимальный): 512 байт / 512 байт Тип метки диска: gpt Идентификатор диска: 2BCA24AC-DB24-4996-8AF2-718D96D300CE

Устр-во начало Конец Секторы Размер Тип /dev/sdb1 2048 937701375 937699328 447,1G Файловая система Linux

Диск /dev/sdd: 3,7 TiB, 4000787030016 байт, 7814037168 секторов Единицы: секторов по 1 * 512 = 512 байт Размер сектора (логический/физический): 512 байт / 4096 байт Размер I/O (минимальный/оптимальный): 4096 байт / 4096 байт Тип метки диска: gpt Идентификатор диска: 16325560-A4C7-4FF1-8319-FE61335E1BAD

Устр-во начало Конец Секторы Размер Тип /dev/sdd1 2048 7814037134 7814035087 3,7T Файловая система Linux

Диск /dev/sdc: 3,7 TiB, 4000787030016 байт, 7814037168 секторов Единицы: секторов по 1 * 512 = 512 байт Размер сектора (логический/физический): 512 байт / 4096 байт Размер I/O (минимальный/оптимальный): 4096 байт / 4096 байт Тип метки диска: gpt Идентификатор диска: 4671995E-9596-4867-8F57-7252758DE349

Устр-во начало Конец Секторы Размер Тип /dev/sdc1 2048 7814037134 7814035087 3,7T Файловая система Linux

Вот глупый вопрос: а как из загрузочного меню GRUB a попасть в командную строку? При нажатии кнопки «c» появляется командная строка самого GRUB a, в которой не работают обычные команды. Или я что-то не так делаю?

Не, не, это не так работает. Загрузчик знает только про ядро, а ядро уже само монтирует всё нужное как указано в fstab.

Ну так у меня в FSTAB почему-то именно так и прописано. Думаю — надо переписать по-нормальному.

Только вот с командной строкой грабовской — не понятно.

Источник

Не хочет грузиться с клонированного диска

склонировал с помощью док-станции диск с обычного hdd на ssd, получил точную копию, со всеми разделами и uuid, но с клона убунту грузиться не хочет, вылетает grub rescue>, ищет normal.mod в i386-pc, вместо x86_64-efi, т.е. грузится в legacy mode вместо efi, если в биосе отключить legacy, то выдаёт, что нет загрузочного раздела, что может быть и как лечить?
ubuntu 22.04, ноут hp не сильно новый, года 3-4

Физически включить новый диск в тот разъем, где был старый.

Очень полюбляют HP делать из BIOS огрызки. Попробуй впрочем такую штукенцию , вдруг поможет загрузится , а дальше как пойдёт. https://www.supergrubdisk.org/super-grub2-disk/

Кек. А у меня ubuntu нормально запускается после клонирования, а вот дебиан — вообще никак. Но у меня и хост и виртуалки на uefi

targitaj ★★★★★ ( 16.03.23 23:09:22 MSK )
Последнее исправление: targitaj 16.03.23 23:09:48 MSK (всего исправлений: 1)

Ткну пальцем в небо — включить UEFI и отключить Secure Boot

отключал legacy и secure boot, не грузится
ноут hp 15-bs595ur

Кек. А у меня ubuntu нормально запускается после клонирования, а вот дебиан — вообще никак. Но у меня и хост и виртуалки на uefi

может ubuntu установлена как legacy, а debian как efi?

то выдаёт, что нет загрузочного раздела

Подключить диск к работающей системе и смотреть, что там с разделами.

А тот диск, с которого клонировали грузится в legacy mode?

У вас размеры дисков точно совпадали, байт в байт? Может ssd чуть меньше или больше, копия GPT ведь хранится в конце диска, она у ssd точно есть в нужном месте? Может вам bios не хочет видеть вашу GPT таблицу разделов, а в MBR нет Efi boot-раздела.

Подключить диск к работающей системе и смотреть, что там с разделами.

точная копия, оба диска одинакового размера, всё полностью совпадает, таблица разделов на месте, но hdd грузится в efi, а ssd только legacy

На первый вопрос не отвечаете, темните. Непонятно откуда у вас вобще взялся grub в MBR и почему он битый, что вываливается в rescue mode.

Когда клонировали, efi раздел не был смонтирован? А то может там «dirty bit» установлен.

И первый вопрос в этой теме. Вы SSD втыкаете в тот разъём (порт, где HDD был. Убунта ведь записывает grub в EFI/ubuntu/grubx64.efi и создаёт запись в efivars. Можете попробовать на SSD скропировать этот файл в EFI/Boot/bootx64.efi

после копирования надо efi тот же гроб переустанавливать либо добавлять запись через efibootmgr.

uwuwuu ( 17.03.23 08:34:59 MSK )
Последнее исправление: uwuwuu 17.03.23 08:35:54 MSK (всего исправлений: 1)

1. Речь идёт про один и тот же компьютер?
2. Просто хотели заменить HDD на SSD, именно заменить, а не добавить?

3.1. ls для общего списка дисков видимых в GRUB;

3.2. Потом ls (. )/ каждого из обнаруженных дисков, чтобы проверить что именно лежит на каждом из дисков (на случай если их нумерация изменилась);

3.3. И вывод команды set , чтобы посмотреть где GRUB ищет свою конфигурацию (на случай если имя диска изменилось, всё таки был HDD, а стал SSD).

Похожие темы

• Форум переустановить grub после клонирования (2023)
• Форум Поломался Grub (2022)
• Форум GRUB мультибут на внешнем SSD (2021)
• Форум Перестал грузиться линукс с диска с GPT (2020)
• Форум Создание загрузочной флешки в ubuntu. (2022)

• Форум UEFI Magic (2014)
• Форум что не так с Grub? (2021)
• Форум Как разметить «универсальную» флешку с арчем? (2017)
• Форум Мультизагрузочная флешка и непонимание grub.cfg (2022)
• Форум Перенос Линукс на другой диск и запуск оттуда (2017)

Источник

Не загружается ОС после переноса VM (qemu/KVM) c одного хоста на другой

Имеется физический сервер с установленным qemu-kvm и libvirt-bin. На сервере настроен RAID1+LVM, виртуальные машины используют тома LVM в качестве дисков (у каждой ВМ свой том).

При переносе ВМ другой физический сервер с аналогичной конфигурацией часть машин не запустилась после перезагрузки. Перенос выполнялся следующим образом:

server1# virsh dumpxml virtual > virtual.xml server1# virsh save virtual virtual.state server1# lvcreate --snapshot -L10G -n virtual-snap /dev/vg0/virtual server1# virsh restore virtual.state server1# dd if=/dev/vg0/virtual-snap bs=1M | gzip -c | pv -ptrb | ssh me@server2 "gunzip -c | dd of=/dev/vg0/virtual" server1# scp virtual.xml me@server2:~/ server1# scp virtual.state me@server2:~/ server1# lvremove /dev/vg0/virtual-snap server2# virsh define virtual.xml server2# virsh restore virtual.state 

У проблемных машин при перезагрузке происходит зависание Booting from hard disk.

Контрольные суммы (md5sum) у /dev/vg0/virtual на обоих физ.серверах совпадают.

Пробовал переносить другим способом:

#On source host. qemu-img convert -p -O qcow2 /dev/vg0/my-vm-disk my-vm-disk.qcow2 scp my-vm-disk.qcow2 target.example.org:/home/myuser/ #On target host. qemu-img convert -p -O raw my-vm-disk.qcow2 /dev/vg0/my-vm-disk 

Часть машин перенеслась без проблем обоими способами, другая часть не запускается после переноса обоими способами. Разницу между нормальными и проблемными ВМ определить не удалось, все ВМ создавались одинаковым способом.

Подскажите в чем может быть проблема. Заранее спасибо!

Источник