Форум русскоязычного сообщества Ubuntu


Хотите сделать посильный вклад в развитие Ubuntu и русскоязычного сообщества?
Помогите нам с документацией!

Автор Тема: Восстановление работоспособности системы  (Прочитано 3786 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн demoniqus

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

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


Оффлайн zg_nico

  • Заслуженный пользователь
  • Почётный модератор
  • Старожил
  • *
  • Сообщений: 3513
  • Nil mortalibus arduum est
    • Просмотр профиля
Re: Восстановление работоспособности системы
« Ответ #1 : 17 Февраля 2019, 20:40:09 »
demoniqus, давайте будем последовательны: что именно Вы снесли? Есть ли у Вас загрузочная флешка в наличии? Жива ли исходная разметка диска? Живы ли разделы на нем? Как именно была установлена система (UEFI/Legacy)? На каком этапе стопырится загрузка (видно ли меню GRUB2, работает ли доступный там по-умолчанию пункт Ubuntu, прогружается ли система до авторизации пользователя)? Из Вами описанного не понятно ровным счетом ничего. Опишите что именно делали и к каким последствиям это привело, - тогда будет понятно что делать дальше.
Thunderobot G150-D2: Intel SkyLake Core i7-6700HQ 2.60GHz, 8Gb DDR4 2133 MHz, Intel HD530, NVidia GeForce GTX 960M 2Gb.  Ubuntu 16.04 64x [Unity], KUbuntu 18.04 64x.

Оффлайн snowin

  • Активист
  • *
  • Сообщений: 883
    • Просмотр профиля
Re: Восстановление работоспособности системы
« Ответ #2 : 17 Февраля 2019, 20:58:49 »
Помогите, пожалуйста, воскресить труп!
нет уж, помер так помер

Оффлайн demoniqus

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

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

Оффлайн zg_nico

  • Заслуженный пользователь
  • Почётный модератор
  • Старожил
  • *
  • Сообщений: 3513
  • Nil mortalibus arduum est
    • Просмотр профиля
Re: Восстановление работоспособности системы
« Ответ #4 : 17 Февраля 2019, 22:14:56 »
Как была установлена система - сейчас уже не скажу
Вы это по сути уже сказали:
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)
(Нажмите, чтобы показать/скрыть)
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

(Нажмите, чтобы показать/скрыть)
После ввода каждой команды давим Enter. Команды выполняются молча. Если на команду посыпались ошибки - что-то делаете не так, и следует перепроверять ввод. Пользуйтесь автодополнением: к примеру, набирая /boot/vmlinuz, если нажать Tab, будет дописано корректное название файла (автодополнение НЕ работает при вводе UUID - его перепечатываем ручками с обязательным учетом регистра). Привожу номер ядра и initrd для дефолтной версии в 18.04.1. В дальнейшем нумерация актуальность потеряет (парадигма - нет!). Есть ли у Вас симлинк - не уверен, поэтому им не пользуюсь тоже (по-умолчанию он есть, но шут его знает). Если после команды boot система успешно загрузилась, и в нее удалось войти, открываем в ней терминал и выполняем sudo update-grubЕсли последнее выполнилось без ошибок - то по идее все, дальше система должна бы загружаться без сбоев.
« Последнее редактирование: 18 Февраля 2019, 10:51:24 от zg_nico »
Thunderobot G150-D2: Intel SkyLake Core i7-6700HQ 2.60GHz, 8Gb DDR4 2133 MHz, Intel HD530, NVidia GeForce GTX 960M 2Gb.  Ubuntu 16.04 64x [Unity], KUbuntu 18.04 64x.

Оффлайн demoniqus

  • Автор темы
  • Новичок
  • *
  • Сообщений: 12
    • Просмотр профиля
Re: Восстановление работоспособности системы
« Ответ #5 : 18 Февраля 2019, 05:41:28 »
Да, именно rescue запускался.
С дисками попробую разобраться. По идее у загрузочного раздела более короткий UUID.
Разметка вроде и правда была в GPT

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

Оффлайн andytux

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 6834
    • Просмотр профиля
Re: Восстановление работоспособности системы
« Ответ #6 : 18 Февраля 2019, 07:40:35 »
Цитировать
По идее у загрузочного раздела более короткий UUID.
У загрузочного - да. Но там нужен как раз УУИД корневого раздела системы.
А чтобы не возиться с УУИД присвой разделу метку тома. Будет проще и удобней ориентироватся и запустить, как в обычном режиме так и аварийном.
Цитировать
именно rescue запускался.
А это значительно хуже. Здесь нужно еще заставить груб работать как следует. В рескуе-режиме он понимает всего несколько команд. Обычно груб-рескуе означает, что груб не находит свои модули, которые по умолчанию должны быть в каталоге /boot/grub/x86_64-efi.
Я бы использовал груб загрузочной флешки, если есть возможность там отредактировать grub.cfg.

Оффлайн DimanBG

  • Старожил
  • *
  • Сообщений: 1316
    • Просмотр профиля
Re: Восстановление работоспособности системы
« Ответ #7 : 18 Февраля 2019, 09:38:13 »
В какой-то момент мне пришла в голову идея поставить на второй диск чистую линуху и поверх нее скопировать уже работающую систему, как описано в инструкциях по переносу.
А можно на эту Инструкцию посмотреть?
Вангую - нужно загрузившись в Лайф посмотреть идентификатор раздела / с основной системой и записать это в grub.cfg на esp разделе.
Там типа - search.fs_uuid 1cbf66b1-dcbd-41a5-b263-49b81fc23f11 root hd0,gpt8
Если ОС рабочая, то она и загрузится выбором в Меню Груб. Вроде как из неё только копировали каталоги, файлы, а не переносили.

Оффлайн demoniqus

  • Автор темы
  • Новичок
  • *
  • Сообщений: 12
    • Просмотр профиля
Re: Восстановление работоспособности системы
« Ответ #8 : 18 Февраля 2019, 20:17:43 »
zg_nico, похоже ситуация ухудшилась в результате каких-то моих манипуляций еще до Вашего совета. Я отключил все посторонние носители, загрузил комп в ожидании Grub'a, а получил предложение вставить загрузочный диск...
Вероятно, к этому привело копирование загрузочного раздела с чистой системы

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


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

Оффлайн fdxcd

  • Активист
  • *
  • Сообщений: 320
    • Просмотр профиля
Re: Восстановление работоспособности системы
« Ответ #9 : 18 Февраля 2019, 20:22:57 »
хотелось бы все же получить РАБОТОСПОСОБНУЮ инструкцию по клонированию системы)))

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

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

Оффлайн andytux

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 6834
    • Просмотр профиля
Re: Восстановление работоспособности системы
« Ответ #10 : 19 Февраля 2019, 04:36:40 »
Цитировать
восстановить или поставить и настроить заново.
Вам виднее, а есть-ли что восстанавливать.
Цитировать
РАБОТОСПОСОБНУЮ инструкцию по клонированию системы
РАБОТОСПОСОБНОЙ инструкцию делает голова. Я делаю так. Особенно обрати внимание на второй вариант.

Оффлайн zg_nico

  • Заслуженный пользователь
  • Почётный модератор
  • Старожил
  • *
  • Сообщений: 3513
  • Nil mortalibus arduum est
    • Просмотр профиля
Re: Восстановление работоспособности системы
« Ответ #11 : 19 Февраля 2019, 09:27:23 »
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 (корневом)
« Последнее редактирование: 15 Января 2020, 14:44:57 от zg_nico »
Thunderobot G150-D2: Intel SkyLake Core i7-6700HQ 2.60GHz, 8Gb DDR4 2133 MHz, Intel HD530, NVidia GeForce GTX 960M 2Gb.  Ubuntu 16.04 64x [Unity], KUbuntu 18.04 64x.

Оффлайн demoniqus

  • Автор темы
  • Новичок
  • *
  • Сообщений: 12
    • Просмотр профиля
Re: Восстановление работоспособности системы
« Ответ #12 : 20 Февраля 2019, 08:40:56 »
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

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 6834
    • Просмотр профиля
Re: Восстановление работоспособности системы
« Ответ #13 : 20 Февраля 2019, 09:26:50 »
Цитировать
простой заменой x86_64-efi на i386-pc решить эту ошибку не удалось
Вы пытаетесь смешать несмехуемое. x86_64-efi и i386-pc - это два почти абсолютно разных загрузчика.
Инструкция zg_nico - это для восстановления груб-ефи.
Цитировать
Есть папка i386-pc
А у вас груб-пс.

Оффлайн demoniqus

  • Автор темы
  • Новичок
  • *
  • Сообщений: 12
    • Просмотр профиля
Re: Восстановление работоспособности системы
« Ответ #14 : 20 Февраля 2019, 13:15:35 »
Вы пытаетесь смешать несмехуемое. x86_64-efi и i386-pc - это два почти абсолютно разных загрузчика
Я об этом думал, но всё же надежда умирает последней.  Как вариант, я допускал, что zg_nico указал папку, соответствующую не моей системе.
Закономерно возникает вопрос: на умершей системе папки x86_64-efi нет - что делать в таком случае? Попробовать ее содрать из полуживой системы? Или как-то иначе восстанавливать?

 

Страница сгенерирована за 0.031 секунд. Запросов: 25.