Восстановление работоспособности системы

[demoniqus]

Добрый всем день!
Поставил Ubuntu 18.04, настроил, установил необходимое ПО и вроде как начал спокойную размеренную жизнь. Но вот вдруг зашевелился жареный петух и мне понадобилось научиться клонировать систему на случай, если вдруг понадобится развернуть настроенную копию в случае поломки. В общем-то, начал с задницы и получил задницу - половину задачи я выполнил на ура. Т.е. завалил операционку и теперь не знаю, как ее восстановить. Стандартные способы через gparted, grub-install не помогают.
GParted находит какую-то ошибку, выдает ссылку на лог половины операционки и закрывается. Окна с зеленым значком я так и не добился.
Grub-install меня задолбал сообщением failed to get canonical path of /cow . Никакие флаги --force, root-directory не помогают.

Очень не хочется опять всё делать заново. Помогите, пожалуйста, воскресить труп!

[zg_nico]

demoniqus, давайте будем последовательны: что именно Вы снесли? Есть ли у Вас загрузочная флешка в наличии? Жива ли исходная разметка диска? Живы ли разделы на нем? Как именно была установлена система (UEFI/Legacy)? На каком этапе стопырится загрузка (видно ли меню GRUB2, работает ли доступный там по-умолчанию пункт Ubuntu, прогружается ли система до авторизации пользователя)? Из Вами описанного не понятно ровным счетом ничего. Опишите что именно делали и к каким последствиям это привело, - тогда будет понятно что делать дальше.

[snowin]

Помогите, пожалуйста, воскресить труп!

нет уж, помер так помер

[demoniqus]

zg_nico, отвечаю по пунктам:
1) что именно снес - трудно сказать, т.к. не являюсь ОПЫТНЫМ пользователем linux. В целом могу сказать, что раздел с Linuxой еще на месте, хотя не гарантирую, что в результате всяких манипуляций там не было повреждены/заменены/удалены какие-то важные файлы. Но  загрузочный раздел скорее всего накрылся. В какой-то момент мне пришла в голову идея поставить на второй диск чистую Linuxу и поверх нее скопировать уже работающую систему, как описано в инструкциях по переносу. Я предполагал, что так будет создана корректная разметка разделов. Но к сожалению я не отключил на время установки диск с работоспособной системой, полагая, что по идее она не должна быть затронута, раз установка идет вообще на физически другой диск (да и когда я отключил в прошлый раз диск, на котором ютились сразу две системы, у него тоже напрочь отвалился загрузчик - поэтому я и не рискнул отключить). Потом я пытался выполнять всякие манипуляции типа grub-repair и пр. и даже в итоге пробовал скопировать загрузочный сектор с чистой системы.
2) Загрузочная флешка есть и работает успешно
3, 4) Жива ли исходная разметка диска и разделы на нем - тут лучше судить по сказанному в п. 1. Я бы выложил картинку, но что-то пока не вижу, как это сделать. Сейчас gparted определяет для sda (диск с настроенной ОС) следующие разделы:
sda1 -  fat32, 512M (использовано 7,1), флаги boot, esp
sda2 - ext4, все остальное пространство диска
Также могу сказать следующее - я с этого диска произвел копирование основных папок на чистую систему (за исключением /etc) - с непонятной ошибкой, но всё же эта система запускается.
5) Как была установлена система - сейчас уже не скажу, т.к. не помню, какие именно флаги были у разделов, когда система еще не была в предсмертной агонии (а говорят, что Linux просто так не убьешь - да они просто не умеют!))))))))))) ) Но вообще вроде установка шла через UEFI, хотя вроде как комп может поддерживать и legacy
6) Что до загрузки - при подключенном постороннем работоспособном носителе (Windows (стоит отдельно на hdd), ubuntu или live usb ubuntu) грузится на них. Если нет, кажись вваливается в меню grub и говорит "Догадайся, чё делать дальше"

Если я предоставил не всю информацию, пожалуйста, уточните, что именно еще нужно указать. Спасибо за отклик!

[zg_nico]

Как была установлена система - сейчас уже не скажу

Вы это по сути уже сказали:

sda1 -  fat32, 512M (использовано 7,1), флаги boot, esp
sda2 - ext4, все остальное пространство диска

Рискну предположить, что именно в UEFI. Исходя п.6 Вашего ответа, надо полагать, что grub rescue у Вас запускается. Исходя из п. 4, раз уж Вы копировали оттуда файлы, - стало быть файловая система жива и доступна. Значит по не вполне понятным причинам шваркнулся не столько сам загрузчик, сколько его конфиг (может, конфиг просто более не является корректным). Давайте попробуем проделать такую манипуляцию: долой загрузочные флешки. Все выдергиваем, выключаем ноутбук. Включаем ноутбук, он немного прогружается. Видим командную строку, перед которой написано либо grub либо grub rescue

1. Определяемся где мы. Исходя из того, что у Вас система с высокой долей вероятности в UEFI, то и разметка с высокой долей вероятности в gpt (хоть это вовсе и не обязательно). Проверяем это. Выполняем команду

Код: [Выделить]

lsВ ответ видим свою разбивку. В Вашем случае будет что-то вроде:

Код: [Выделить]

(hd0) (hd0,gpt2) (hd0,gpt1)

(Нажмите, чтобы показать/скрыть)

Если видим ответ вида

Код: [Выделить]

(hd0) (hd0,msdos1) (hd0,msdos2)то разметка у Вас MBR, - и синтаксис выполняемых команд будет иной (при сохранении общей парадигмы).

2. Исходя из приведенных Вами ранее данных, Вы имеете 2 диска. Один из них (с флагом efp) - это раздел для хранения бинарных загрузочных конфигов. Другой (тот что ext4) - это Ваш корневой раздел. Наша задача определить что есть что. Выполняем:

Код: [Выделить]

ls (hd0,2)Видим в ответе

Partition hd0,2: Filesystem type ext* - Last modofication time 2019-02-17 18:00:00 Sunday, UUID e2dd4c3f-2d74-4901-be08-32a8fc7c6caf - Partition start at 525312KiB - Total size 30930664.5KiB

Значит попали мы по адресу. Раздел определили, и более того, знаем его UUID. Предполагаю, что Вы имя разделу не давали, поэтому отталкиваюсь от того, что есть всегда, - т.е. от UUID. У Вас он будет свой.  Тогда печатаем далее по одной следующие команды (вместо e2dd4c3f-2d74-4901-be08-32a8fc7c6caf вводим руками тот UUID, который имеет раздел, на котором у Вас стоит система в Вашем случае - т.е. то, что было получено из вывода команды ls в примере выше):

Код: [Выделить]

insmod part_gpt
insmod ext2
set root='hd0,2'
linux /boot/vmlinuz-4.15.0-29 root=UUID=e2dd4c3f-2d74-4901-be08-32a8fc7c6caf ro 
initrd /boot/initrd-4.15.0-29-generic
boot

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

insmod part_msdos
insmod ext2
set root='hd0,2'
linux /boot/vmlinuz-4.15.0-29 root=UUID=e2dd4c3f-2d74-4901-be08-32a8fc7c6caf ro
initrd /boot/initrd-4.15.0-29-generic
boot

После ввода каждой команды давим Enter. Команды выполняются молча. Если на команду посыпались ошибки - что-то делаете не так, и следует перепроверять ввод. Пользуйтесь автодополнением: к примеру, набирая /boot/vmlinuz, если нажать Tab, будет дописано корректное название файла (автодополнение НЕ работает при вводе UUID - его перепечатываем ручками с обязательным учетом регистра). Привожу номер ядра и initrd для дефолтной версии в 18.04.1. В дальнейшем нумерация актуальность потеряет (парадигма - нет!). Есть ли у Вас симлинк - не уверен, поэтому им не пользуюсь тоже (по-умолчанию он есть, но шут его знает). Если после команды boot система успешно загрузилась, и в нее удалось войти, открываем в ней терминал и выполняем

Код: [Выделить]

sudo update-grubЕсли последнее выполнилось без ошибок - то по идее все, дальше система должна бы загружаться без сбоев.

[demoniqus]

Да, именно rescue запускался.
С дисками попробую разобраться. По идее у загрузочного раздела более короткий UUID.
Разметка вроде и правда была в GPT

Спасибо за помощь, вечером попробую всё провернуть и отпишусь о результатах!)))

[andytux]

По идее у загрузочного раздела более короткий UUID.

У загрузочного - да. Но там нужен как раз УУИД корневого раздела системы.
А чтобы не возиться с УУИД присвой разделу метку тома. Будет проще и удобней ориентироватся и запустить, как в обычном режиме так и аварийном.

именно rescue запускался.

А это значительно хуже. Здесь нужно еще заставить груб работать как следует. В рескуе-режиме он понимает всего несколько команд. Обычно груб-рескуе означает, что груб не находит свои модули, которые по умолчанию должны быть в каталоге /boot/grub/x86_64-efi.
Я бы использовал груб загрузочной флешки, если есть возможность там отредактировать grub.cfg.

[DimanBG]

В какой-то момент мне пришла в голову идея поставить на второй диск чистую Linuxу и поверх нее скопировать уже работающую систему, как описано в инструкциях по переносу.

А можно на эту Инструкцию посмотреть?
Вангую - нужно загрузившись в Лайф посмотреть идентификатор раздела / с основной системой и записать это в grub.cfg на esp разделе.
Там типа - search.fs_uuid 1cbf66b1-dcbd-41a5-b263-49b81fc23f11 root hd0,gpt8
Если ОС рабочая, то она и загрузится выбором в Меню Груб. Вроде как из неё только копировали каталоги, файлы, а не переносили.

[demoniqus]

zg_nico, похоже ситуация ухудшилась в результате каких-то моих манипуляций еще до Вашего совета. Я отключил все посторонние носители, загрузил комп в ожидании Grub'a, а получил предложение вставить загрузочный диск...
Вероятно, к этому привело копирование загрузочного раздела с чистой системы

Всё больше начинаю задумываться о том, что проще - восстановить или поставить и настроить заново. Тем более, что вроде можно забрать с диска историю команд (благо большинство пакетов ставилось через консоль). В случае чистой установки хотелось бы все же получить РАБОТОСПОСОБНУЮ инструкцию по клонированию системы)))

А можно на эту Инструкцию посмотреть?

Не факт, что это та самая инструкция, но ее я тоже пытался провернуть
https://ixnfo.com/perenos-rabotayushhey-sistemyi-ubuntu-na-drugoy-disk.html

[fdxcd]

хотелось бы все же получить РАБОТОСПОСОБНУЮ инструкцию по клонированию системы)))

Вот: Тема: FSArchiver и Boot-Repair, сборка LiveCD Backup/Restore

(Нажмите, чтобы показать/скрыть)

В последних версиях установлено:
        fsarchiver 0.6.19 (2014-03-01) и qt4-fsarchiver 0.6.19-2 (2014-04-23)
Утилита для клонирования диска под Linux, имеется графический интерфейс. Сохраняет разделы диска в образ диска (*.fsa), только занятое пространство, использует несколько алгоритмов сжатия. При восстановлении из образа - создает заново FS, восстанавливает uuid, не зависит от размера раздела(больше, меньше, такого же размера, как исходный).

[andytux]

восстановить или поставить и настроить заново.

Вам виднее, а есть-ли что восстанавливать.

РАБОТОСПОСОБНУЮ инструкцию по клонированию системы

РАБОТОСПОСОБНОЙ инструкцию делает голова. Я делаю так. Особенно обрати внимание на второй вариант.

[zg_nico]

demoniqus, можно попробовать восстановление через chroot. Загружаемся с загрузочной флешки в LiveUSB (режим UEFI). Определяемся с диском, на котором стоит система. Допустим, встроенный диск ноутбука определен ядром как sda, он имеет 2 раздела:
sda1 [boot, esp] 512 Гб FAT32 - раздел для хранения конфигов EFI
sda2 всё_остальное_место EXT4 - корневой раздел системы (он же root раздел, он же "/" с точки зрения установленной на диск системы)
Определить это можно любым удобным способом. Через тот же gparted или disks, или же через консольную lsblk. В сущности, это Вы должны знать, т.к. систему ставили Вы.
Исходя из этих условий, открываем терминал (Ctrl+Alt+T) и начинаем вводить по одной команде (если ошибка на каком-либо этапе возникает - то останавливаем процесс, и спрашиваем что происходит, демонстрируя вывод ошибки на форуме, или рыская по ней в гугле):

Код: (bash) [Выделить]

sudo mount /dev/sda2 /mnt                                           #если у Вас не sda2 - подставляем свои данные вместо sda2!!!
sudo mount /dev/sda1 /mnt/boot/efi                                  #если у Вас не sda1 - подставляем свои данные вместо sda1!!!
for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
sudo cp /etc/resolv.conf /mnt/etc/                                  #это чтобы сеть была доступна после выполнения chroot'a
modprobe efivars                                                    # убеждаемся что подгружен модуль ядра для работы с EFI
sudo chroot /mnt
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi
exit
for i in /sys /proc /dev/pts /dev; do sudo umount /mnt$i; done
sudo umount /mnt/boot/efi                                           #размонтируем ESP-раздел (чтобы не повредить)
sudo umount /mnt
sudo rebootПо идее всё. После перезагрузки грузитесь не с флешки, а с встроенного диска ноутбука, - система должна стартовать. Примечание: если по каким-то причинам раздел sda1 у Вас сейчас не существует - создайте его средствами gparted. Основная ценность у Вас на разделе sda2 (корневом)

[demoniqus]

zg_nico, попробовал вчера Вашу последнюю инструкцию, но на команде

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi

свалился с сообщением /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exists
Такой папки /usr/lib/grub/x86_64-efi нет. Как и на рабочем компе (в смысле на работе, где ось работает), впрочем. Есть папка i386-pc, в которой как раз-таки есть необходимый файл, но простой заменой x86_64-efi на i386-pc решить эту ошибку не удалось. Первые попавшиеся статьи в гугле тоже ясности не внесли.
Попробую еще порешать эту ошибку.

[andytux]

простой заменой x86_64-efi на i386-pc решить эту ошибку не удалось

Вы пытаетесь смешать несмехуемое. x86_64-efi и i386-pc - это два почти абсолютно разных загрузчика.
Инструкция zg_nico - это для восстановления груб-ефи.

Есть папка i386-pc

А у вас груб-пс.

[demoniqus]

Вы пытаетесь смешать несмехуемое. x86_64-efi и i386-pc - это два почти абсолютно разных загрузчика

Я об этом думал, но всё же надежда умирает последней.  Как вариант, я допускал, что zg_nico указал папку, соответствующую не моей системе.
Закономерно возникает вопрос: на умершей системе папки x86_64-efi нет - что делать в таком случае? Попробовать ее содрать из полуживой системы? Или как-то иначе восстанавливать?