Восстановление системы после сбоя
23.1. Локализация причины сбоя
Всему есть своя причина — сбой не происходит сам по себе. Причиной может стать либо ошибка программного обеспечения, либо отказ «железа». Исходя из этого, различают программные и аппаратные сбои. Последние можно смело назвать аппаратно-программными, поскольку из-за отказа аппаратуры довольно часто происходят программные сбои. Самый простой пример — отказ винчестера, вследствие которого программа не может записать или прочитать данные, и происходит программный сбой. При некорректной работе оперативной памяти происходят порой сложнообъяснимые ошибки программного обеспечения.
23.2. Программный сбой
Прежде всего, нужно выяснить и по возможности устранить причину сбоя. Если это сугубо программный сбой, то причины две: неправильная настройка программы (или системы) и ошибка программы.
23.2.1. Неправильная настройка программы или системы
Как работала система до сбоя? Встречался ли подобный сбой раньше? Если ничего такого ранее вы не наблюдали и система работала как швейцарские часики, значит, скорее всего, причина в неправильной ее настройке. Вспомните, какие файлы конфигурации вы изменяли (или какие параметры устанавливали с помощью графических конфигураторов). Просто по памяти восстановите исходные значения и перезапустите сервис или службу, ставшую причиной сбоя, — возможно, проблема решится. Рекомендуется перед каким-либо изменением, вносимым в файл конфигурации системы, делать его резервную копию. Потом вам же будет проще восстановить исходные значения. Можно рекомендовать и другой подход — закомментировать прежние директивы/значения файла конфигурации, а новые писать под ними. В случае вашей ошибки вы всегда сможете восстановить исходные значения.
23.2.2. Ошибка программы. Журналы системы
Когда причина ошибки в ваших действиях — это самый простой случай. Иногда бывает так, что система работала-работала, а на следующий день половина служб не запускается. В чем же причина? Тут вам поможет только чтение журналов системы, находящихся в каталоге /var/log:
□ /apache2/ — журналы Web-сервера Apache2;
□ /apt/ — журналы системы установки пакетов APT;
□ /clamav/ — журналы антивируса ClamAV;
□ /cups/ — журналы системы печати;
□ /gdm/ — журналы менеджера дисплея;
□ /installer/ — журналы программы установки;
□ /news/ — журналы NNTP-сервера и NNTP-клиентов;
□ /proftpd/ — журналы FTP-сервера;
□ /samba/ — протоколы Samba;
□ auth.log — журналы аутентификации (кто и когда входил в систему);
□ daemon.log — журналы для разных демонов (служб);
□ dmesg — загрузочные сообщения ядра;
□ dpkg.log — журналы программы dpkg;
□ kern.log — журналы сообщений ядра;
□ mail* — журналы почтовой службы;
□ messages — различные сообщения ядра (и в некоторых случаях — обычных программ);
□ mysql.log — протокол MySQL-сервера;
□ secure — журнал службы безопасности;
□ syslog — журнал демона syslog;
□ Xorg.0.log — журнал системы XFree86 (дисплей 0);
□ user.log — различные сообщения программ пользовательского уровня.
Протоколирование сообщений системы и программ ранее выполнялось двумя демонами: klogd и syslogd. В современных дистрибутивах (Ubuntu — не исключение) используется всего один демон протоколирования — rsyslogd.
Имена файлов журналов могут немного отличаться от перечисленных здесь, поскольку они зависят от настроек системы, в том числе и от настроек демона rsyslogd. Кроме того, в системе могут создаваться дополнительные файлы протоколов или даже каталоги, содержащие файлы протоколов, — повторюсь, все зависит от настроек системы. Чтобы узнать, какие файлы протоколов имеются в вашей системе, какие из них являются основными и для чего используются, откройте и изучите файлы конфигурации rsyslogd: /etc/rsyslog.conf и /etc/rsyslog.d/50-default.conf.
Однако в файлах конфигурации демона rsyslogd перечислены далеко не все файлы протоколов. Многие серверы ведут свои журналы, имена файлов которых вы можете узнать в файлах конфигурации того или иного сервера. Так, сообщения различных программ пользовательского уровня, т. е. обычных программ, возможно, запущенных с привилегиями root, протоколируются в файле /var/log/user.log.
В каком же журнале искать ошибку? Тут нужно исходить из принципа взаимоисключения: если у вас не работает Web-сервер Apache, то искать причину нужно в каталоге /var/log/apache2/, но никак не в файле /var/log/user.log.
23.3. Аппаратный сбой
Причиной аппаратного сбоя, как мы знаем, может стать или полный отказ устройства, или частичный отказ одного из его модулей, что свидетельствует о необходимости замены всего устройства. При полном отказе устройства результат виден невооруженным взглядом. Наиболее часто отказывают жесткие диски и оптические приводы (поскольку в их конструкции есть движущиеся механические детали), на втором месте — оперативная память, далее — видеокарты и прочие карты расширения. Самыми надежными остаются процессор и материнская плата. Хотя все относительно и определяется качеством устройства, которое напрямую зависит от производителя «железа». Не секрет, что вероятность отказа у «чистокровных» компьютеров от Intel и HP намного меньше, чем у собранного в подвале неизвестной компьютерной фирмой из тайваньских комплектующих.
Да, так я и думал до того, как у меня появился «чистокровный» HP 6735s, у которого спустя полгода после покупки отказал правый динамик. В сервис я его так и не отнес, потому что ноутбук нужен каждый день, но где же хваленое качество HP?
23.3.1. Отказы жесткого диска
Причина отказа жесткого диска кроется в ненадежной электронике или некачественном носителе (магнитных дисках, на которых, собственно, и хранится информация). На самом деле, что конкретно в винчестере вышло из строя, — не так важно, все равно придется покупать новый, ведь неисправные практически не поддаются ремонту, особенно в кустарных условиях. Иногда можно еще восстановить информацию, но это нужно делать в лабораториях, оснащенных специальным оборудованием. Фирм, занимающихся восстановлением информации с винчестеров, немного, а их услуги стоят довольно дорого, поэтому, чтобы не пришлось платить двойную плату (за новый жесткий диск и за восстановление информации со старого), периодически делайте резервные копии. Для этого просто записывайте важные для вас данные на CD или DVD, а еще лучше — на внешние винчестеры USB (последние пока дорогие, но они и наболее удобные). Потом резервные копии лучше всего хранить в безопасном месте, скажем, в сейфе, если он есть.
Жесткий диск может портиться постепенно. Как правило, предшественниками полного отказа становятся «битые» блоки, что проявляется блокированием записи или чтения данных. Если система не может прочитать информацию из такого сектора, вы увидите на консоли соответствующее сообщение. Если вы подозреваете, что причина именно в наличии «битых» секторов, проверьте ваш жесткий диск с помощью программы badblocks. Если ваши опасения подтвердились, немедленно сделайте резервную копию всех данных, которые еще можно прочитать с диска, поскольку сейчас ваш жесткий диск непредсказуем, — он может еще проработать с полгода или год, а может отказать уже завтра или даже через час. После этого купите новый жесткий диск (именно новый, а не другой б/у) и восстановите информацию с резервной копии, а старый винчестер постарайтесь продать, пока он еще работает.
23.3.2. Отказы памяти
При полном отказе оперативной памяти в процессе запуска системы (именно компьютера, а не Linux, поскольку до загрузки Linux дело не дойдет) вы услышите один длинный гудок системного динамика. Это сигнал о том, что пора менять модуль ОЗУ, но пока не спешите это делать сразу. Возможно, вы затронули модуль при разборке/сборке системного блока — вытащите его, протрите пыль, почистите контактные группы стирательной резинкой, стряхните катышки и установите обратно. Если это не поможет, попробуйте поставить модуль в другой слот. В случае окончательной неудачи у вас появится новый брелок (вы уже догадались какой). Если вы особо не разбираетесь в «железе», то, чтобы не ошибиться, выбирайте новый модуль «по образу и подобию» старого, прихватив его в магазин с собою.
Загрузившись с дистрибутивного диска Ubuntu, который прилагается к книге, вы можете вызвать программу memtest86 (рис. 23.1) для проверки модулей памяти компьютера — вдруг уже их пора менять?
На рис. 23.1 имеются некоторые несоответствия — например, показано, что в тестируемой системе процессор AMD — и это при чипсете Intel 440 BX! Но не подумайте, что это «глюк» программы. Просто у меня memtest86 запущен в виртуальной машине VMware, поскольку без этого не сделать скриншот окна программы.
Пусть система пройдет тест памяти до конца (да, придется подождать). Но впоследствии это может сэкономить вам очень много времени. Помню, знакомые принесли мне ноутбук с предустановленной Vista (кстати, тоже HP) — после загрузки компьютер отображал «синий экран». Попытки восстановления системы результата не дали, и я попытался установить на эту машину RTM-версию Windows 7. Однако система устанавливаться никак не хотела — в процессе копирования файлов появлялось сообщение об ошибке, связанной с повреждением носителя дистрибутива. Но на других-то компьютерах система с этого диска устанавливалась нормально! С дистрибутивом Windows XP — ситуация аналогичная. Провозился я с этми ноутбуком целый день, но так ничего и не добился. На следующий день решил попробовать на нем Linux. LiveCD запустился без проблем. Начал копирование содержимого всего LiveCD на жесткий диск полностью — ошибка копирования. Стал уже подозревать неисправность привода DVD или даже жесткого диска… А потом запустил memtest. И обнаружил, что один модуль оперативной памяти оказался «битым». Так что, если бы я запустил memtest в самом начале и потратил пару часов на проверку памяти, не пришлось бы мне сносить «родную» Vista, а просто заменить модуль памяти.
23.3.3. Отказ видеокарты
При отказе видеокарты звуковой сигнал BIOS (фирмы AWARD) будет таким — один длинный и два коротких. Если у вас BIOS другой фирмы, то самое время прочитать о его звуковых сигналах в руководстве к материнской плате. Полный отказ видеокарты встречается редко и как правило из-за перегрева при «разгоне» видео, в чем виноват обычно сам пользователь.
В большинстве случаев причиной сбоя может быть неполный контакт видеоплаты со слотом шины AGP или PCI-Express (полагаю, что у вас уже давно не «просто» PCI-видео). Вытащите карту из разъема, почистите контакты и аккуратно установите обратно. То же самое нужно сделать со штекером монитора. Теперь включите компьютер. Все нормально? В противном случае вам придется покупать новую видеокарту.
23.3.4. Отказ материнской платы и процессора
Обычно отказ одного из этих компонентов влечет повреждение второго, но бывают исключения, поэтому нужно отнести компьютер в мастерскую для диагностики. Конечно, если у вас есть подобная материнская плата и такой же процессор, можете все проверить и сами. Хотя я бы на вашем месте так делать не стал — вдруг у вас неисправна материнская плата и из-за нее вышел из строя процессор? Тогда вы рискуете испортить еще один.
Причиной аппаратного отказа материнской платы и/или процессора может быть скачок напряжения или банальный перегрев, когда электроника не успела выключить питание компьютера.
Но в случае с материнской платой возможен и программный отказ — выход из строя BIOS. Тогда поможет перезапись BIOS с помощью программатора. Такая процедура стоит недорого, обратитесь в магазин, в котором вы покупали компьютер, — вам обязательно помогут. «Лечение» подобной неисправности гораздо дешевле, чем покупка новой материнской платы.
В большинстве случаев отказа материнской платы и/или процессора система вообще не подает никаких звуковых сигналов — это верный признак подобной неисправности.
23.3.5. Диагностика аппаратного сбоя с помощью ядра
Если во время загрузки или работы Linux произошел серьезный аппаратный сбой (кроме сбоев видеоподсистемы), ядро «впадает в панику» (это режим работы ядра — режим паники, когда работа всей системы останавливается), а на дисплее вы увидите сообщение о вероятной причине сбоя.
Когда сбой некритичный, и работу можно продолжать, сообщение об ошибке также будет выведено на консоль и записано в журнал /var/log/messages. В некоторых дистрибутивах оно может быть записано в один из файлов в каталоге /var/log/kern.log (в зависимости от типа сообщения: предупреждение, ошибка и т. д.).
Во время загрузки сообщения ядра так быстро выводятся на экран, что не всегда успеваешь их просмотреть, однако это можно сделать и после загрузки командой:
# dmesg | less
А можно просто открыть в любом текстовом редакторе файл /var/log/dmesg и просмотреть его содержимое.
23.4. Режим восстановления
Режим восстановления позволяет получить права root без входа в систему. Просто выберите в меню GRUB2 (рис. 23.2) пункт:
Ubuntu, kernel 2.6.32-16-generic (режим восстановления)
Если вы вообще не видите меню загрузчика GRUB2, тогда вернитесь к главе 19, в которой описан процесс настройки этого загрузчика, который по умолчанию отказывается показывать меню.
Далее вы увидите меню режима восстановления (рис. 23.3).
Рассмотрим команды этого меню:
□ resume — продолжить нормальную загрузку. Эту команду следует выбрать, если вы ошибочно запустили режим восстановления;
Любопытно, что вместо загрузки графического интерфейса (чего и следовало ожидать, судя по описанию команды) в результате ее выполнения загружается командная строка. Далее придется ввести имя пользователя, пароль, а затем — команду sudo reboot для перезагрузки системы.
□ clean — система попытается освободить свободное место. Эту команду следует выбрать, если Ubuntu отказывается запускаться из-за нехватки места на диске;
□ dpkg — «отремонтировать» «сломанные» пакеты;
□ grub — обновить загрузчик GRUB2;
□ netroot — командная строка root c поддержкой сети;
□ root — обычная командная строка root (без поддержки сети).
Если ваша неполадка не связана с отсутствием свободного места на диске, «сломанными» пакетами или настройками GRUB2, выбирайте команду root — вы получите root-доступ к системе. Что делать дальше? Все зависит от характера неисправности — можно, например, запустить программу fsck для проверки файловой системы или программу badblocks для проверки поверхности жесткого диска. Можно анализировать журналы системы и т. п.
23.5. Создание резервной копии с помощью программы remastersys
Для Windows существует множество инструментов, позволяющих создать образ диска. Использовать их очень легко. Сначала вы устанавливаете Windows, потом — все необходимые драйверы и приложения, а затем — создаете образ диска. Этот образ можно использовать или для клонирования системы (установки на компьютеры подобной конфигурации), или для восстановления системы, когда она в очередной раз «упадет». Причем восстановление занимает около 15 минут, а это намного меньше, чем новая установка Windows со всеми программами и драйверами.
Для Linux я нашел подобный инструмент — программу remastersys. Она позволяет создать образ вашей системы на LiveCD. Если потребуется переустановить Ubuntu, вы загрузитесь с этого диска и восстановите свою систему. И вам не придется ни настраивать ее, ни устанавливать заново пакеты. Вы также сможете без проблем использовать этот образ для установки системы на другие компьютеры, причем необязательно, чтобы конфигурация этих компьютеров совпадала с конфигурацией компьютера, на котором создавался образ.
Несомненно, программу оценят администраторы (им часто приходится устанавливать/переустанавливать систему), экспериментаторы (которые часто переустанавливают Ubuntu — а эксперименты требуют жертв) и пользователи медленных интернет-соединений (вы только представьте, что выкачивали сутки все необходимое программное обеспечение и еще сутки все настраивали, а через неделю система почему-то «рухнула» — придется все качать заново).
Установим программу. Для этого запустите текстовый редактор с правами root:
gksudo gedit /etc/apt/sources.list
Добавьте в конец файла следующую строку:
deb http://www.geekconnection.org/remastersys/repository karmic/
Сохраните файл и введите команды:
sudo apt-get update
sudo apt-get install remastersys
На рис. 23.4 изображен процесс выполнения команды apt-get update, а на рис. 23.5 — команды apt-get install remastersys.
Понимаю, что вас смущает название каталога в репозитории — karmic, что соответствует версии Ubuntu 9.10. Действительно, на момент написания этих строк на сервере www.geekconnection.org еще не было каталога lucid (хотя Ubuntu 10.04 уже вышла). Надеюсь, скоро такой каталог появится, и тогда вместо karmic в строке обращения к репозиторию нужно будет указать lucid. Впрочем, при установке пакета remastersys производится разрешение зависимостей из источника пакетов для lucid, поэтому программа будет работать без проблем.
Запустите remastersys командой Система | Администрирование | Remastersys Backup. Программа предложит вам закрыть все окна и размонтировать все общие сетевые ресурсы (рис. 23.6) — во время резервного копирования программе ничего не должно мешать.
Далее вы увидите меню программы (рис. 23.7):
□ Backup — полная резервная копия вместе с пользовательскими данными (оптимальный вариант для резервного копирования);
□ Dist — создание дистрибутива. Удобно, если вы хотите поделиться настроенной системой с друзьями. При этом в образ не будут помещены ваши пользовательские данные;
□ Distcdfs, Distiso — создают «полуфабрикаты». Если вы не разработчик собственного дистрибутива, эти команды вам ни к чему;
□ Modify — изменяет параметры remastersys;
□ Clean — удаляет временные файлы. Каждый раз после выполнения команд Dist или Backup выполняйте команду Clean, чтобы очистить место на диске. Только не забудьте перед этим скопировать куда-то полученный ISO-файл (он будет находиться в каталоге /home/remastersys), иначе он будет удален вместе с временными файлами;
□ Info — информация о программе;
□ Quit — выход.
Выберите команду Modify и нажмите OK.
В открывшемся окне (рис. 23.8) вы сможете изменить параметры программы remastersys:
□ Username — имя пользователя LiveCD. Можно не изменять, а можно подставить свое имя;
□ Title — метка для LiveCD;
□ Filename — имя файла образа LiveCD;
□ Working Directory — рабочий каталог. По возможности не изменяйте его;
□ Files to Exclude — список файлов, которые не нужно помещать в LiveCD. Например, вашу коллекцию видеофильмов, которые занимают несколько гигабайтов;
□ URL for USB Creator — здесь можете указать адрес вашего сайта.
Установив параметры, вернитесь в главное меню программы (командой Go back to main menu), выберите команду Backup или Dist и нажмите OK. Процесс создания LiveCD довольно долог (все зависит от размера файловой системы) и его нельзя прерывать. Помните, что максимальный размер образа, который может создать remastersys — 4 Гбайт. Поэтому если ваша файловая система содержит большие файлы (например, фильмы, музыку), то их нужно перенести на другой раздел жесткого диска (после этого не забудьте размонтировать этот раздел) или указать их список в параметре Files to Exclude.
По окончании процесса создания образа в каталоге /home/remastersys будет создан файл custom.iso (если вы предварительно не изменили его имени). Осталось записать его на «болванку» (см. главу 12). Перед записью убедитесь, что размер образа соответствует типу используемой «болванки», — нередко образ превышает 700 Мбайт, и в этом случае для его записи следует использовать DVD, а не CD.