Восстановить kali linux после неудачного обновления

Обновлено: 04.07.2024

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

Для начала стоит рассмотреть, какие вообще бывают нештатные ситуации, после которых система не грузится. Условно их можно разделить на четыре вида:

  1. Сбой файловой системы
  2. Некорректное обновление дистрибутива. Конечно, именитые компании, такие как Canonical или Red Hat, очень стараются не допускать подобных ситуаций, но ведь и на старуху бывает проруха.
  3. Некорректно сконфигурированная графическая подсистема и/или кривые драйверы, чаще всего проприетарные.
  4. Невнимательность пользователя. О, чего тут только нет! Перечислю основные возможности сломать систему:
    • забыть пароль root (как вариант — свой собственный) или загрузчика;
    • перезаписать таблицу разделов;
    • удалить какой-нибудь крайне важный файл;
    • установить программу из неизвестного источника. Справедливости ради надо сказать, что если пользователь компилирует из-под своей учетной записи и ставит программы исключительно в свой домашний каталог (что, впрочем, бывает крайне редко), то максимум, что сможет сделать эта программа, — занять все ресурсы и/или запороть конфиги в домашнем каталоге (необходимо отметить, что это верно именно для криво написанных программ, не для зловредов).

Это, пожалуй, самые распространенные варианты сбоя, после которого может понадобиться реанимировать систему. Рассмотрим теперь, как это делать.

Для Linux способы сброса паролей пользователей разнятся от дистрибутива к дистрибутиву. Далее я опишу самый универсальный метод.

В загрузочном меню GRUB выдели дистрибутив и нажми клавишу . Затем выбери строку, начинающуюся с kernel, и снова нажми (в случае с GRUB2 — linux и повторно нажимать не надо). В конце строки допиши init=/bin/sh . Эта команда запускает вместо init/systemd процесс оболочки, в котором ты можешь изменить пароль. Но перед этим тебе необходимо перемонтировать ФС в режиме чтения/записи, для чего выполни следующую команду:

Уже после этого ты можешь выполнить команду passwd или ее же, но с именем пользователя в качестве аргумента. После этого нужно перезагрузиться — но команды shutdown / reboot в этом режиме не всегда работают. Выход есть: используй клавишу , Люк! А именно — зажимая клавиши и , с интервалом в 3–4 секунды нажми следующие буквы: R E I S S U B. Итогом будет перезагрузка, и после нее ты сможешь заходить под новым паролем.

В FreeBSD ситуация сложнее. Обычно советуют грузиться в однопользовательском режиме и оттуда уже менять пароль. Однако если в файле /etc/ttys консоль отмечена как insecure, то этот метод, очевидно, не подходит, и тут не обойтись без LiveCD (в параметрах ядра, которые могут быть установлены в загрузчике, есть переменная kern.init_path, но сброс, а затем присвоение этой переменной пути к какой-либо оболочке ни на что не влияет). Рассмотрим, как именно сбросить пароль с его помощью.

  • Качаем (и записываем) Frenzy и грузимся с него.
  • Подключаем разделы FreeBSD в режиме чтение/запись.
  • Делаем chroot на подмонтированную ФС.
  • Делаем резервные копии файлов passwd , master.passwd , pwd.db и spwd.db .
  • Задаем команду passwd и ставим пароль.
  • Выходим из chroot, задаем команду sync , отмонтируем и перезагружаемся.

В случае с потерей пароля на GRUB/GRUB2 тебе необходимо загрузиться с LiveCD и поставить другой пароль. Для GRUB2 это делается путем редактирования файла /boot/grub/grub.cfg (после перезагрузки не забудь поставить новый зашифрованный пароль в соответствующий файл в /etc/grub.d/ ):

Для старого GRUB достаточно заменить в файле /boot/grub/menu.lst строку password --md5 password_hash на password newpass.

Та самая строчка, которая влияет на ввод пароля в однопользовательском режиме в FreeBSD

Та самая строчка, которая влияет на ввод пароля в однопользовательском режиме в FreeBSD

В случае порчи загрузчика сперва нужно определить, какой из них используется в твоей системе. Как правило, в Ubuntu, начиная с версии 9.10, используется вторая версия GRUB. Однако проверить это нетрудно. Прежде всего загрузись с LiveCD и пробрось chroot. О том, как это сделать, написано в одном из следующих разделов. Помни, что в случае, если /boot находится на отдельном разделе, его также необходимо подмонтировать. Наиболее ярким индикатором, что установлен GRUB2, служит присутствие каталога /etc/grub.d/ . Для полной же уверенности проверь также наличие файла grub-mkpasswd-pbkdf2 и отсутствие grub-crypt с помощью команды whereis .

В случае если в качестве загрузчика используется вторая версия GRUB и ты точно уверен, что он установлен, к примеру на /dev/sda , набирай следующую команду:

Если возникли ошибки, могут помочь опции проверки device map '--recheck' и отключения проверки наличия флоппи-дисковода '--no-floppy'.

Для установки GRUB Legacy используй ту же самую команду. Замечу, что опция '--recheck' в версии программы для grub-legacy недоступна.

В системах, основанных на RHEL, даунгрейд можно осуществить сразу несколькими путями. Самый древний метод — использовать опцию '--rollback' RPM. Например, для отката изменений на неделю назад необходимо выполнить следующую команду:

Этот метод, однако, по современным меркам весьма неудобен, особенно если учитывать, что сейчас все пользуются yum . Для даунгрейда пакета с помощью yum можно использовать команду yum downgrade . Например, так:

Замечу, что зависимости не даунгрейдятся, и их нужно указывать вместе с пакетом, который подвергается этой операции.

В системах новее RHEL6 есть еще один метод, основанный на истории действий yum . Для его применения нужно прежде всего задать следующую команду:

Затем посмотреть номер действия, убедиться, что это именно то действие, и откатиться:

История действий yum

История действий yum

Для Ubuntu (и других систем, использующих apt-get ) нужно сначала удалить пакет, а затем установить нужную версию (перед этим обязательно сохраняй конфиги!):

Нужно учесть, что для ядер это не подходит — новые ядра именно устанавливаются, а не обновляются.

В случае с портами FreeBSD существует утилита portdowngrade , которая, впрочем, сейчас служит в качестве фронтенда к subversion , то есть для ее использования необходимо, чтобы svn был установлен. Использовать ее очень просто — сперва мы ищем ту ревизию, к которой нужно откатиться, затем откатываемся и ставим этот порт:

Откат порта в FreeBSD

Откат порта в FreeBSD

Восстановление удаленных файлов сильно зависит от файловой системы, и гарантии, что ты их восстановишь, нет никакой. Вначале опишу восстановление данных с ext2/3/4 под Ubuntu. Первым делом, если ты обнаружил, что какой-то файл удален, сразу насильно выключай компьютер - и чем раньше ты обнаружишь это, тем лучше. Затем грузись с LiveCD и установи программу extundelete :

Если у тебя есть раздел, куда восстанавливать, подмонтируй его, перейди в соответствующий каталог и набери следующую команду:

Если же у тебя нет раздела, в который можно помещать восстанавливаемые файлы… тогда вместо --restore-all напиши --restore-file. Например, так:

Отмечу, что путь к файлу задается относительно его корня — то есть если у тебя отдельный раздел /boot и ты случайно удалил файл /boot/grub/grub.cfg , то в качестве восстанавливаемого файла будет фигурировать /grub/grub.cfg .

В случае с Btrfs в версиях выше, чем 0.20, имеется команда btrfs restore . К сожалению, по умолчанию она не может восстанавливать конкретные файлы – для этого необходима сборка btrfs-progs от josefbacik. Пример использования:

Что до FreeBSD, то ситуация с ней сложнее. Для восстановления удаленных данных в стандартной поставке ничего нет, поэтому берем какой-нибудь LiveCD — да тот же Ubuntu — и ставим пакет testdisk , в составе которого имеется photorec . К сожалению, эта программа (пока?) не понимает формата разделов и слайсов FreeBSD и его файловую систему. Тем не менее это не мешает им пользоваться. Запустим ее для раздела sda3:

В появившемся меню нажмем — поскольку мы уже выбрали раздел — и затем выберем Options". Там включаем опции по вкусу, выйдем из меню и вперед — жмем Search. Перед поиском photorec попросит указать каталог, куда сохранять. Разумеется, процесс это небыстрый, поэтому запасись терпением.


В пакет testdisk, помимо photorec, входит собственно сам testdisk — утилита, позволяющая восстанавливать случайно удаленные разделы из таблицы разделов.
Помимо этих методов, есть еще один метод, почти универсальный для *nix-систем. Этот метод не требует немедленного отключения питания. Но не спеши радоваться, он доступен только в том случае, если ты удалил файл, открытый в другом приложении. Для восстановления файла тебе нужно узнать PID приложения, перейти в каталог /proc/<PID>/fd , найти ссылку на удаленный файл и с помощью cat его восстановить.

Photorec в работе

Photorec в работе

В случае работы с поврежденными ФС необходимо быть чрезвычайно осторожным. Трижды убедись, что ты понимаешь, что делаешь.

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

Рассмотрим первую ситуацию (сбой питания) для ext4. В общем-то, эти методы работают при любой вышеперечисленной ситуации. Если система вообще не стартует, нужно загрузиться с LiveCD и по возможности скопировать образ раздела. Затем набираем в консоли следующую команду (предполагается, что ФС находится на sda7):

Если все хорошо, то fsck будет задавать вопросы. Все нормально. Главное, чтобы их не было слишком много. Но если fsck ругается на некорректный суперблок… то и тут не стоит отчаиваться. Для начала узнаем, в каких блоках находятся резервные суперблоки, для чего используем стандартную команду mkfs.ext4 :

Команда эта, как правило, создает новую файловую систему и во время этой процедуры пишет местонахождение резервных суперблоков. Нам, разумеетcя, не надо создавать ФС. Но запуск с опцией -n ее и не создает, а всего лишь показывает процесс создания — а заодно и выводит список резервных суперблоков (он, в свою очередь, зависит от размера блока). Допустим, размер блока у нас равен 4 Кб. Тогда мы снова задаем команду fsck.ext4 :

Опция -b указывает резервный суперблок, список которых мы получили из вывода предыдущей команды.

Просмотр списка резервных суперблоков с помощью mkfs

Просмотр списка резервных суперблоков с помощью mkfs

Если же и это не помогает (или хочется ручками попробовать восстановить), тогда пришло время для тяжелой артиллерии. В качестве таковой выступает связка утилит dumpe2fs , tune2fs и debugfs . Их описание выходит за рамки данной статьи, но не упомянуть их я не могу. Кроме того, у команды mkfs.ext4 есть ключ '-S', который инициализирует только суперблок и группы блоков, но не таблицы инодов. После этого нужно запустить fsck . При использовании этого способа помни — размер блока должен совпадать со старым, иначе шансы на восстановление значительно уменьшатся.

В случае с Btrfs набор утилит для восстановления очень и очень скуден. Тем не менее некоторые средства все же имеются. Опишу опции монтирования, относящиеся к восстановлению:

  • опция монтирования recovery (доступна начиная с ядра 3.2) позволяет Btrfs при сбое сканировать предыдущие корни бинарных деревьев и по возможности использовать первый неповрежденный;
  • degraded — для систем на нескольких устройствах (RAID-массив средствами Btrfs). Если одно устройство по каким-то причинам недоступно, эта опция позволяет смонтировать ФС и добавить новое устройство;
  • skip_balance (доступна с ядра 3.4) отключает балансировку данных и метаданных. Использование этой опции имеет смысл, если питание было отключено внезапно и у тебя опять же ФС на нескольких устройствах — для ФС на одном устройстве операция балансировки не имеет смысла.

В FreeBSD fsck_ufs для указания резервного суперблока принимает тот же параметр -b', что и в Linux. А вот у утилиты newfs , в отличие от ее аналога mkfs.ext4 , для просмотра информации о создаваемой ФС без фактического ее создания используется ключ '-N'. Ключа, аналогичного описанному выше '-S', нет вообще. Для ручного восстановления используй аналогичную связку из утилит dumpfs , tunefs и fsdb .

Для ZFS ситуация с утилитами восстановления хотя и более печальная, чем в случае с классическими ФС, но с Btrfs несравнима. И это при том, что субъективно Btrfs куда более сырая. Команды fsck в ней нет, но ее ближайшим аналогом служит команда zpool scrub , которая проверяет контрольные суммы всех занятых блоков пула. Для просмотра информации в уберблоке (примерном аналоге суперблока) используется утилита zdb . В случае критического повреждения пула используй команду zpool clear -F .

Просмотр возможностей файловой системы с помощью debugfs Аналог debugfs в FreeBSD

Действия в этой ситуации зависят от того, как именно ты ставил это ПО и загружается ли система вообще. Если система не загружается, в случае Ubuntu имеет смысл загрузиться с LiveCD и, подмонтировав корневую ФС, сделать chroot:

Затем просмотреть, если ты ставил это неизвестное ПО с репозитория, список пакетов, которые недавно были установлены, для чего открыть файл /var/log/apt/history.log и с помощью apt-get удалить данный пакет. Если же ты устанавливал из исходных кодов, а система не загружается даже в однопользовательском режиме, скорее всего, ты установил какой-то модуль ядра, который прописался в initramfs . Чтобы от него избавиться, посмотри каталог /etc/initramfs-tools/ , в частности файл modules . После устранения подозрительных строк обнови initramfs :

Если система все же загружается в однопользовательском режиме, значит, дело в каком-то init-скрипте. Для просмотра свежесозданных файлов в каталоге /etc/init.d/ используй команду ls -t , затем, после обнаружения службы, отключи ее с помощью команды update-rc.d имя_службы purge . Затем перейди в каталог сборки и попробуй дать команду make uninstall . Не факт, что сработает, но попытаться стоит.

Эти проблемы относятся к проприетарным драйверам. Разумеется, сейчас они возникают довольно редко, но все же возникают. Рассмотрю, например, ситуацию, когда вместо нормального изображения драйвер NVIDIA после запуска показывает по центру монитора полосу примерно в половину ширины экрана с прерывистыми диагональными линиями на ней. Если после ее появления переключиться на консоль и обратно, изображение нормализуется. Для исправления этой ситуации нужно принудительно выставить графический режим путем добавления параметра ядра. В файле /etc/default/grub добавляем в переменную GRUBCMDLINELINUX_DEFAULT параметр vga=0x314. Должна получиться следующая строка:

Не забываем перегенерировать грабовский конфиг:

Еще одна проблемная ситуация может возникнуть, если драйвер неверно определяет разрешение монитора. Для ее решения есть два пути. Первый — добавить следующие строчки в файл /etc/X11/xorg.conf в секцию Screen:

Разрешение, естественно, нужно подставить желаемое. Но файл xorg.conf считается устаревшим, поэтому рекомендую использовать комбинацию

/.xprofile и команды xrandr . Создай файл

/.xprofile со следующим содержимым:

Конечно, в твоем случае опция --output (как и разрешение) может отличаться. Чтобы узнать точно, куда подключен монитор, набери xrandr без параметров.

LiveCD для восстановления системы

Cуществует несколько LiveCD-дистрибутивов для восстановления системы. Кратко опишу два из них.

Grml — LiveCD, основанный на Debian. Поддерживает как x86-, так и x64-системы. Может быть установлен на флешку. Из особенностей:

  • По умолчанию в качестве оболочки используется ZSH, а в качестве WM — Fluxbox.
  • USB-установка поддерживает сохранение конфигов (на флешке при этом нужно создать два раздела).
  • Есть пакет sleuthkit, предназначенный как для восстановления данных, так и для компьютерных криминалистов.

SystemRescueCD основан на Gentoo. Последняя его версия, 3.8.0, выпущенная в сентябре этого года, имеет следующие особенности:

  • Ядра как x86, так и x64, причем двух версий — Standard (3.4.62) и Alternative (3.10.12).
  • В качестве рабочего стола используется Xfce.
  • Помимо Linux, в меню загрузки имеются также некоторые образы дискет, например MHDD.

Все это добро умещается на 420 Мб.

В этой статье я попытался описать самые частые и наиболее пугающие проблемы, которые могут возникнуть при работе в современных дистрибутивах Linux и FreeBSD. По сравнению с тем, что было раньше, этот список заметно поубавился. Тем не менее я не описал проблем, связанных с железом (видеодрайверы не в счет), — во-первых, потому, что оно у всех разное, а во-вторых — их нужно по возможности предотвращать, иначе, когда они себя проявят, уже будет поздно.

Всем привет, после обращений пользователей описываю пару вероятных решений проблем о том, как быстро восстановить загрузчик Кали Линукс без переустановки системы. Один из описанных способов пригодится вам, даже если вы просто решили ПЕРЕУСТАНОВИТЬ Windows.

error: no such partition.

ЧТО ИСПОЛЬЗУЕТСЯ ДЛЯ ВОССТАНОВЛЕНИЯ?

  • битый загрузчик от Кали Линукс Rolling с Windows 7
  • диск liveDVD с Кали Линукс (на всякий случай)
  • загрузочный Windows 7 (вообще просто лежит)

Как восстановить файлы?

вариант второй позволит восстановить загрузчик Кали Линукс в любом случае

Если вы решите пойти этим путём (или что-то уже пошло не так), стоит лишь:

  • загрузиться с диска с Windows 7 (8/10) подходящей версии
  • выйти в консоль Восстановления системы

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

  • вызвать командную строку и выбрать букву диска, где лежит Windows. Сделать это просто: сама Windows присваивает им буквы C или D. Почти всегда это D. Так в консоли и наберите:
  • проверьте командой

есть ли на диске папки Windows. Их вы ни с чем не перепутаете. Если всё на месте, вводим финишную команду:

Windows появится после перезагрузки. Можно будет скачать недостающий образ Кали и после этого перейти к варианту 2 . Но это путь через Китай.

Как восстановить загрузчик Кали Линукс? Вариант первый.

Что понадобится для первого варианта?

Диски ждут очереди, а мы начинаем работу с терминалом. Прямо из терминала grub rescue Проверьте список видимых разделов командой:

Терминал выдаст всё, что обнаружил в виде списка в одной строке типа:

(hd0) (hd0,msdos3) (hd0,msdos2) (hd0,msdos1)

Мол, три раздела ( msdosX ) на одном ( hd0 ) винчестере. Пробуем каждый из них по порядку командами:

Если терминал возвращает ошибку о том, что тип файловой системы загрузчику неизвестен (в силу исторических обстоятельств понимает в типах файловых структур он до сих пор немного):

Переходим к следующему разделу, пока не увидите:

Ставим триггер описателя:

И попробуем загрузчик сразу проявить себя:

Появилось? Должно. Загрузитесь в Кали, минуя Windows, и введите команды, которые проверят и сохранят новый загрузчик:

Если после перезагрузки вас снова выбрасывает в ремонтный терминал, повторите описанные шаги, добавив туда команды

Таким образом можно восстановить загрузчик Линукс не прибегая ни к каким инструментам вообще.

Как восстановить загрузчик Кали Линукс? Вариант 2.

Что понадобится для второго варианта?

  • прямые руки
  • загрузочный диск с Кали Линукс

Я пошёл другой проторенной тропинкой и воспользовался по старинке загрузочным liveDVD с Кали. Она сохранилась на виртуальном дисководе в числе других (флешка Кали Persistance не прокатила). Как уже отмечалось, такой способ восстановления загрузчика универсален, так как позволяет вернуть загрузчик Линукс при переустановке Windows (впоследствии я этим и воспользовался, окончательно перейдя на Windows 10 с Windows 7).

Для начала (уже из-под живой Кали) я загрузил утилиту по работе с разделами (проверил наименование разделов):

gparted в линукс

А теперь в терминале вот эти команды; по порядку или в строку через && :

Посматривайте на терминал, он должен обнаружить и входную точку в Windows записью (по-русски или на английском):

Найден Windows 7 на /dev/sdaX

Перезагружаемся, LiveDVD с Кали вынимаем.

После внезапного отключения электричества, неудачного обновления или добавления нового диска в /etc/fstab вы можете столкнуться с проблемой, что ваша система не загружается, а точнее говоря, загружается в консоль или в чёрный экран. Иногда проблема усугубляется тем, что системный администратор не может попасть даже в аварийную консоль. Рассмотрим, как решить следующую ошибку:


После нажатия Enter всё может повториться.

Как разблокировать пользователя root в аварийном режиме

Тем не менее, выход из данной ситуации есть. Начните с того, что загрузитесь в однопользовательский режим — это тот же самый режим, который используется для сброса пароля Linux. Ниже приведена обобщённая инструкция, если у вас что-то не получается, то отдельные инструкции для разных дистрибутивов по загрузке в однопользовательский режим вы найдёте здесь.

Остановите загрузку удерживая клавишу SHIFT при запуске компьютера, вы увидите:


Нажмите клавишу «e» и вы перейдёте к редактированию настроек загрузки:

Найдите строку, начинающуюся с linux.


Перейдите в конец этой строки, поставьте пробел и допишите:

Должно получиться примерно так (номер ядра может отличаться):


Когда всё готово нажмите Ctrl+x или F10, чтобы загрузка продолжилась с установленными опциями.

Вы увидите приглашение оболочки, также обратите внимание, что мы вошли как root, т.е. у нас имеются повышенные привилегии, в том числе на использование команды passwd:

устанавливаем пароль пользователя root.

Если команда passwd завершилась ошибкой:

то скорее всего файловая система смонтирована только для чтения. Чтобы в этом убедиться введите команду:

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

После этого смена пароля должна пройти успешно.

Снимаем блокировку с входа по паролю для пользователя root:

Если пользователь root заблокирован, то этого может быть недостаточно. Проверьте, какая оболочка установлена для root:

Если для root в качестве оболочки указана строка «/usr/sbin/nologin», то выполните одну из следующих команд.

  • Чтобы назначить пользователю root оболочку Bash:
  • Чтобы назначить пользователю root оболочку ZSH:

Для выхода наберите:

Чтобы выключить компьютер выполните:

Или перезагрузите компьютер командой:

Если после перезагрузки вы увидели «Give root password for maintenance», то это означает, что первый этап восстановления прошёл успешно — мы активировали пользователя root и теперь может приступить к восстановлению системы.


Как восстановить компьютер, попавший в аварийном режиме

Теперь у нас появилась возможность восстановить систему. Если у вас нет идей, что именно вызвало ошибку, то выполните команду

и попробуйте найти причину проблемы там.

Проверка дисков на ошибки

Если вы считаете, что причиной ошибки являются неполадки жёстких дисков, то используйте команды следующего вида для проверки разделов:

Номер раздела и имя диска могут отличаться от «sda2», чтобы узнать точное имя, используйте команду

Неудачное обновление

Если система не загружается из-за прерванного обновления, то попробуйте следующие команды:

Если вы считаете, что причиной проблемы стало неудачное обновление конкретного пакета, то используйте команду вида:

Эта команда проведёт повторную конфигурацию уже установленного пакета.

Например, следующая команда выполнит повторную конфигурацию ядра Linux:

Система не загружается из-за неправильной записи в /etc/fstab

Закомментируйте или удалите проблемную строчку. Сохраните файл (Ctrl+o), закройте его (Ctrl+x) и перезагрузитесь:

Важно, чтобы там была строка:

Причём эта строка должна быть единственной незакомментирвоанной.

Строка может быть такой:

Дополнительную информацию об обновлении Kali Linux, какие ещё есть команды и вопросы, связанные с обновлением, смотрите в справочной статье « Как обновить Kali Linux ».

Ниже задавайте ваши вопросы о возникающих проблемах при обновлении системы.

Ошибка «E: Не удалось получить . Соединение разорвано [IP:»

Часть выводимой при неудачном обновлении информации:

Ключевой здесь является информация:

Ошибка «E: Не удалось получить . Соединение разорвано [IP:»

То есть не удалось получить некоторые файлы пакетов.

  • у вас нестабильное Интернет-подключение и некоторые файлы не были загружены из-за разрывов подключения
  • между обновлением кэша приложений и загрузкой файлов прошло некоторое время, в течении которого пакеты в репозитории успели обновиться — то есть вы пытаетесь загрузить старые пакеты, а на сервере они больше недоступны, так как заменены новыми версиями. Такая ситуация вполне вероятно, особенно если вам необходимо обновиться много пакетов, а ваше Интернет-подключение является медленным.

Для решение проблемы — просто заново перезапустите обновление командами:

Во время обновления появляется окно или запрос, на которое не реагирует на клики.

Во время обновления появляется окно или запрос, на которое не реагирует на клики.

Иногда при обновлении появляются запросы к пользователю, которые могут выглядеть примерно так:



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

TAB — для перехода по пунктам меню

Пробел или Enter — для выбора или отмены выбора

С помощью клавиши TAB перейдите на кнопку «ОК» и клавишей Enter нажмите её для продолжения обновления.

Что делать если программа спрашивает про обновление конфигурационного файла.

При некоторых обновлениях некоторых пакетов меняется структура конфигурационного файла. Как правило, в новом файле содержаться директивы и настройки, которые необходимы для новой версии программы, без которых она не может работать.

Настройка программы — это в почти всегда изменение конфигурационных файлов. Конечный результат может быть результатом длительной работы с конфигурацией и множества тестов. На это могут быть потрачены часы или даже дни.

Поэтому при необходимости обновить конфигурацию, возникает дилемма:

  • не обновлять конфиг, в результате чего новая версия не будет нормально работать
  • обновить конфиг и стереть результаты настройки пользователя

Именно по этой причине система спрашивает у вас каждый раз, что нужно сделать, если с обновлением программы обновляется и конфигурационный файл?

Если в действительности вы не пользовались этой программой, либо сделанные настройки не представляют для вас ценности, то всегда соглашайтесь на обновление конфигурационного файла. Если сделанные настройки для вас важны, то:

  • отказывайтесь от обновления конфигурационного файла
  • сделайте резервную копию вашего конфига, обновите конфигурационный файл, а затем сделайте в нём необходимые настройки

Для некоторых пакетов, например Tor, конфигурационный файл представляет собой просто набор комментариев, в котором не активна ни одна настройка — для таких файлов (если вы их не меняли), обновление является чистой формальностью.

Ошб:1 404 Not Found [IP:

При обновлении может возникнуть следующая ошибка:

Ключевой здесь является строка Ошб:1 404 Not Found — то есть файл пакета не найден. Самой частой причиной этого является устаревший кэш с информацией о пакетах и ссылками на их загрузку.

Поэтому перед обновлением пакетов обновите кэш:

Либо используйте такую комбинированную команду, которая обновит кэш и сразу запустит загрузку и установку обновлённых версий пакетов:

E: Не удалось получить доступ к файлу блокировки /var/lib/dpkg/lock

Пожалуй, самая частая ошибка при попытке обновления или установки нового пакета:

E: Не удалось получить доступ к файлу блокировки /var/lib/dpkg/lock

W: Произошла ошибка при проверке подписи. Репозиторий не обновлён и будут использованы предыдущие индексные файлы. Ошибка GPG

Процесс обновления пакетов, кроме их скачивания и распаковки, включает в себя также проверку их цифровой подписи. Эта проверка гарантирует:

  • целостность пакетов (что они не были повреждены при скачивании)
  • получение их из надёжного источника (эти пакеты не были модифицированные или созданы неуполномоченными лицами

Цифровая подпись поставляется в систему также упакованной в пакет, который обновляется вместе с другими пакетами системы. Если прошло слишком много времени и файлы для проверки цифровой подписи устарели, то возникает замкнутый круг: вы не можете обновить пакеты в системе, поскольку они проходят проверку цифровой подписи. Вы не можете обновить файлы для проверки цифровой подписи, поскольку они поставляются как пакет, а пакеты не могут быть обновлены, поскольку…

Обновление Kali Linux затягивается на целый день

В виртуальной машине я сталкиваюсь с замедлением обновления пакетов в Kali Linux. В результате большое обновление может затянуться в буквальном смысле на целый день. Причём, больше всего времени занимает процесс распаковки скаченных обновлённых пакетов. Распаковка exploitdb или metasploit-framework может затянуться просто на часы!

Это ненормально — видимо, какой-то баг.

Лично я выбрал для себя довольно нестандартное решение — у меня Kali Linux установлена на настоящем (а не виртуальном) внешнем USB диске, который я подключаю к VirtualBox и загружаюсь с него в виртуальной машине. То есть я не выходя из основной системы загружаюсь с внешнего диска. Это отличное решение — процесс распаковки пакетов стал занимать считанные минуты, но это чуть усложнённый способ и он подходит не всем.

Если вы хотите работать исключительно в VirtualBox и не подключать внешний USB диск, то в качестве варианта можно удалить два пакета, которые занимают больше всего времени на распаковку, это exploitdb и metasploit-framework. Причём пакет metasploit-framework является зависимостью для таких инструментов как: armitage, commix, ghost-phisher, jboss-autopwn, maltego-teeth, msfpc, set, u3-pwn, unicorn-magic. Если вы используете какой-либо из этих пакетов, то этот способ вам не подойдёт. Если вам эти пакеты не нужны, то их можно удалить командой:

В результате процесс обновления не будет зависать на целый день, если вышла новая версия exploitdb или metasploit-framework.

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

Здесь тоже есть свой аналог безопасного режима. В этой статье мы рассмотрим как выполняется восстановление Ubuntu 16.04, как открыть меню восстановления и как подготовить систему и выполнить необходимые действия для возвращения рабочего состояния.

Восстановление Ubuntu

Если ваша система не загружается, и выдает какую-либо ошибку во время загрузки, вы все еще можете кое-что сделать. Разработчики добавили такую возможность, как Recovery Mode. Вы можете загрузиться в этом режиме через загрузчик Grub. В меню Grub выберите пункт "Дополнительные параметры для Ubuntu"


Затем выберите "Ubuntu . (recovery mode)":


Дальше загрузится меню режим восстановления ubuntu в котором вы можете выбрать один из доступных вариантов:

  • resume - продолжить нормальную загрузку системы;
  • clean - попытаться освободить место на диске;
  • dpkg - восстановление поврежденных пакетов;
  • failsafeX - запустить графический безопасный режим;
  • fsck - проверить все файловые системы на ошибки;
  • grub - обновить настройки загрузчика Grub;
  • network - Включить поддержку сети;
  • root - войти в консоль от имени суперпользователя;
  • system-summary - информация о системе.


Как видите, здесь есть достаточно возможностей которые позволяют выполнить восстановление Ubuntu 16.04 от различных проблем.

Пункт "clean" позволяет вам очистить лишние пакеты:


С помощью пункта "dpkg" вы можете попытаться восстановить поврежденные пакеты и выполнить обновление системы, если оно было внезапно прервано:


Следующий пункт - "failsafeX" позволяет запустить графическую оболочку в безопасном режиме. На первом шаге программа нас предупредит, что используются минимальные графические настройки:


В следующем окне можно выбрать несколько вариантов для исправления системы. При выборе "Troubleshoting" вы можете просмотреть логи загрузки, X сервера или отредактировать конфигурационный файл X.




С помощью опции "Reconfigure graphics" вы можете сбросить настройки X сервера если они были изменены до параметров по умолчанию.

Самый первый пункт в списке - "Try running with default graphics mode", позволяет попробовать загрузить графический режим по умолчанию.

Дальше возвращаемся к главному меню режима восстановления. Пункт "fsck" позволяет вам проверить файловую систему на ошибки для всех подключенных к системе разделов:



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


С помощью опции "network" вы можете подключить текущее окружение к сети.

И последний, и один из самых полезных пунктов - это "root". Он позволяет получить доступ к консоли операционной системы с правами пользователя root.


Здесь будет доступна для вас привычная командная среда, где вы можете выполнять различные команды Bash чтобы починить свою систему. Но нужно обратить внимание на то, что корневая файловая система смонтирована в режиме только для чтения.

Поэтому, если вы хотите вносить какие-либо правки, кроме проверки диска на ошибки в fsck, то вам придется сделать ее доступной для записи:

sudo mount -o remount,rw /


Также заметьте, что ваша домашняя папка и папка /boot не смонтированы, если они вам нужны, то для монтирования выполните:

Если вы хотите обновлять систему, то вам понадобиться интернет. Его лучше настроить на предыдущем этапе. Но если вы этого не сделали, то NetworkManager можно запустить и сейчас для этого выполните:

Затем останется только создать файл /etc/resolv.conf для правильного разрешения доменных имен:

echo "nameserver 8.8.8.8" > /etc/resolv.conf


Теперь в вашем терминале есть сеть и вы можете делать все, что вам нужно, например, обновить систему, удалить драйвера, сбросить пароль и многое другое. Чтобы вернуться в главное меню просто нажмите сочетание клавиш Ctrl+D.

После того как вы все настроите, можно попытаться снова загрузить систему в нормальном режиме. Для этого используйте команду resume. Только лучше перезагрузить систему, потому что некоторые видео драйвера могут некорректно работать:



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


Выводы

В этой статье мы рассмотрели как выполняется восстановление системы Ubuntu, что такое режим восстановления ubuntu, а также как с ним работать. Если ваша система сломалась в результате удаления какого-либо пакета, установки драйверов или неудачного обновления - этот режим может спасти ситуацию. Если у вас остались вопросы, спрашивайте в комментариях!

На завершение видео о том, как восстановить загрузчик Grub:


Оцените статью:

(31 оценок, среднее: 4,87 из 5)

Об авторе

19 комментариев

Есть у меня черта такая, люблю пользоваться свежим софтом. Постоянно обновляю Убунту до беты, посмотреть, потестировать, делаю это на живой системе, без виртуальных машин; пользуюсь девелоперской сборкой оперы, инсайдерскими сборками десятки.
Обновился до 17.04 в первую альфу.
Хочу заметить, что при сбоях очень удобно пользоваться консолью под суперпользователем, в ней нет ничего страшного.
В пятницу, после очередной порции утренних обновлений поймал сбой. Система не загружалась, показывала чёрный экран, а на нём курсор мышки. Загрузка с предыдущим ядром результата не дала. В режиме восстановления использовал clean, dpkg, fsck. Включил поддержку сети (network), в консоли под суперпользователем обновил систему (sudo apt update && sudo apt upgrade). На всякий случай переустановил Unity командами
sudo apt-get install --reinstall ubuntu-desktop;
sudo apt-get install unity;
sudo apt-get install --reinstall xserver-xorg.
Перезагрузился (sudo reboot) и победа?
Теперь я вижу приглашение залогиниться под собой или под гостем, но меня под собой не пускают, снова и снова возвращая на окно авторизации. А под гостем пожалуйста, заходи, работай. Вот только я не хочу. Другой бы давно уже опустил руки, удалил и переустановил всю систему полностью, но любители сырого софта сделаны из другого теста:)
Ухожу из жестокого мира графики к предтечям через Ctrl+Alt+F1, туплю, вспоминая логин:), но, всё-таки, авторизуюсь.
Чтобы понять почему не пускают меня подо мной в графическом режиме командую sudo startx. Идут секунды, потом пичалька:
timeout in locking authority file /home/alex/.Xauthority
Думаю, что прожжёные консольщики смогли бы добраться до него из терминала и переименовать или удалить.
Я выкачал из под десятки образ 17.04, записал на флешку через unetbootin и загрузился. Подмонтировал логический диск с установленной Убунту, запустил наутилус с правами суперпользователя (sudo nautilus), добрался до .Xauthority. По умолчанию он скрыт, поэтому в Nautilus нажимаем Ctrl+h, переименовал в .Xauthority123, сохранил и. уже в который раз перезагрузился.
Вот теперь всё, система загрузилась подо мной.
Надо сказать, что толковых форумов для решения вопроса я так и не нашёл, почти везде либо издёвки, (хомячок не осилил), либо имбецильные ответы, копипасты не пойми откуда. Вопрошающие просто исчезали, вопрос решали как-то ещё. Хочется, чтобы ребята, получившие сложность, могли воспользоваться этой простенькой инструкцией.

Такая трабла с окном авторизации часто бывает.
Я лечю её всегда так:
Вариант №1
В загрузчике GRUB выбираем Другие параметры для Ubuntu -> выбираем Режим восстановления (Recovery mode), грузимся, выбираем root, вводим:
rm

/.Xauthority
Жмём на Enter
пишем reboot и жмём на Enter
Система грузиться в стандартном режиме.

Вариант №2
В окне авторизации жмём на Ctrl+Alt+F1
попадаем в консоль, логинимся, а остальное всё то же, что и в первом случае, только подставляем sudo в начале команд.

А зачем так сложно удалять/переименовывать файл? Когда достаточно rm

/ file (если файл в домашней папке) Да и вообще есть достаточно удобный консольный файловый менеджер mc.

Статья хорошая, но по моему вы усложняете. Как мне кажется, достаточно сделать несколько точек восстановления, а для полной уверенности backup всей системы, с установленными программами на флэшку. Хотя и это вряд ли понадобится, Ubuntu достаточно надежна, в отличие от Fedora и если туда не лезть кривыми руками, то будет служить годами без ошибок и сбоев.

Про Ubuntu я б так не сказал.. Вот Debian да, надёжный, как АК))

Мое почтение! Благодарю за полезную статью-очень познавательно и практично. У меня в ноутбуке и дэсктопе установлено три Системы одна из которых Вин 7. Конечно же всеми ими я не пользуюсь ежедневно- для работы в основном использую Линукс Минт. Иногда нужно ,в силу ряда причин использовать Виндовс. В этом ничего плохого не вижу. Это как у вас в гараже стоят две машины-одна для ежедневных поездок ну а другая для поездок на рыбалку или пикник. Ну я о другом. Конечно же иногда возникают некоторые проблемы с Линуксом после обновлений или какими то моими неумелыми действиями с Системой. В таких случаях всегда пользуюсь загрузочным образом на флэшке програмы Clonezilla. Аналог Акрониса но с текстовым интерфейсом. Понятно, что перед восстановлением нужно создать сам образ настроенной под себя Системы но потом в случае чего за 7-8 минут вы будете иметь работоспособную Систему без переустановки на момент создания образа. Очень удобно и быстро!
Всем добра!

Респект за статью! UBUNTU сбоила после мгновенного отключения эл.питания. Восстановил по Вашим рекомендациям через dpkg и grub. Затем вошел в режим resume - загрузилась (правда кривоватое изображение). НО: после перезагрузки опять тоже самое - не грузится, входит в режим проверки диска C и т.д. Может еще какая "приблуда" нужна ?

Читайте также: